iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
In Anton Brilliantov’s proposal, a service owner belongs in the service declaration—not only in a wiki, ticket, or verbal agreement. The owner field identifies who accepts decisions at defined delivery gates; changing it requires a reviewed commit. It is not, by itself, an on-call assignment or a promise that the named person will repair every incident.
What “ownership is a field” means
In his September 28, 2026 essay, “Ownership Is a Field, Not an Agreement”, software engineer Anton Brilliantov argues that service ownership should be recorded alongside the service name and team in its declaration. In the workflow he describes, that declaration is the basis from which runtime and deployment details are derived.
The practical idea is to make the decision-maker visible where the service is defined. A verbal agreement can be difficult for a newcomer to discover, cannot be checked by a build, and may leave no durable record of who accepted a change. With an owner field, changing the decision-maker becomes an edit that can be reviewed and committed. The commit history can then show when the change happened and preserve its discussion.
This is Brilliantov’s engineering position, not a demonstrated industry-wide result. The essay does not report a controlled comparison showing that a declaration field outperforms other ways of recording responsibility.
#1 Best Overall
What the owner is—and is not—responsible for
Brilliantov uses “owner” to mean the person who holds acceptance gates and has authority to accept or refuse work at those transitions. That role is about decisions: whether requirements, a contract, a specification, execution, acceptance, or release meet the conditions to proceed.
It does not necessarily identify the person who will respond first to an outage or fix a live failure. As the essay puts it, “The field says who decides. It does not say who will fix the thing that is broken right now.” Teams should therefore avoid treating the owner field as a substitute for a separate operational or on-call assignment.
How the proposed gates work
The essay connects ownership to a sequence of acceptance gates. At each transition, the owner is expected to make a decision based on evidence rather than an informal status claim. These are the controls Brilliantov prescribes; the essay does not establish their effectiveness through measured results.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstall- Requirements to contract: check that measurable non-functional requirements are present.
- Contract to specification: use a compatibility check to assess whether the contract and specification align.
- Specification to execution: require an executable specification as the basis for implementation.
- Execution to acceptance: use an acceptance command to test whether the work meets its acceptance conditions.
- Acceptance to release: examine build, test, structure, or drift checks before release.
For this approach, saying “finished, all green” is not the evidence itself. The relevant evidence is the output of the run that supports the decision. The owner is the person with authority to act on that evidence at the gate.
Rank #3
Why a declaration instead of a wiki, ticket, or ownership file?
Brilliantov contrasts the declaration field with three other records. His concern is that each may describe a different relationship from the one he wants the owner field to capture.
- A wiki table can name a team or contact, but may be separate from the deployed service and its change history.
- A ticket assignment identifies responsibility for a particular item of work, not necessarily the person authorized to make decisions about the service over time.
- A repository ownership file can govern code review or file-level responsibility, which may not be the same as accepting service-level decisions.
His alternative is to put the owner beside the service name and team in the declaration, so the record is tied to the service definition and changes through review. This is a design rationale, not evidence that the other records are always disconnected or unsuitable; a team’s existing systems may already link them effectively.
Costs and cases where a single owner is a poor fit
A committed field improves discoverability only while it stays accurate. Brilliantov identifies several limits that teams need to account for:
- It can lag behind organizational change. A person’s role may change before anyone updates and reviews the declaration.
- A required name creates a commitment. If an empty value is disallowed, someone must agree in writing to make the relevant decisions.
- It does not assign incident repair. A decision-maker field does not answer who will respond to or fix a live failure.
- It can misrepresent collective authority. If decisions are genuinely made collectively, naming one person falsely implies individual authority. The author advises against using a single-name field in that case.
- It may add little in a very small setup. For one person and one service, the essay says the field offers little additional value.
The proposal also remains a direction rather than a finished catalog product: Brilliantov notes that the service card with owners and commitments does not yet exist as a web interface. He describes a declaration, the resulting deployment, and checks around them.
Best Value
Questions to settle before adopting the field
Before adding a required owner to a service declaration, a team can make the proposal concrete by answering:
- Does “owner” mean decision authority at acceptance gates, operational repair responsibility, or both?
- What evidence must be available at each gate, and where will the decision record live?
- Who updates the declaration when roles change, and how will the team notice stale ownership?
- Is decision authority actually held by one person, or is it collective?
- What separate record identifies incident responders or on-call responsibility?
Those answers determine whether a single owner field accurately reflects the team’s process, or whether it would conceal an important distinction.
Quick Recap
Discussion prompts
- Where does the owner of a service live in your organization, and what changes that record?
- What has an unowned acceptance gate cost your team?
- Where would a declared owner be worse than a standing agreement?
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →
