Who should own architecture documentation?

The Data team changes an event schema, the Billing team consumes it, and the shared diagram still shows the old contract. Who should notice and propose the correction? “The architecture team” is too distant from the change; “everyone” often means nobody. Good documentation ownership separates the person who changes the system, the steward who keeps a view useful, and the reviewers who can verify its edges. The goal is not an owner name in metadata. It is a short, visible path from a real change to a corrected artifact.

Direct answer: Give every architecture artifact one named steward, the person accountable for its scope, accuracy, and retirement, and make whoever changes the system responsible for proposing the diagram update. The steward reviews and accepts changes. They do not do all the drawing. Choose stewards close to the system, name a backup for critical diagrams, and write the arrangement down.

Accountability is not authorship

Two different questions need answering:

• The steward: Is this artifact still useful? Is its scope clear? Who can approve changes? When should it be archived?
• The change author: Did my change alter anything this diagram shows, and have I proposed the update?

Separating the two spreads the work without losing responsibility.

A responsibility model you can copy

Activity	Change author	Steward	Affected team	Engineering lead
Propose an update after a change	Responsible	Informed	Consulted
Review and accept the update	Consulted	Accountable	Consulted
Define scope and audience		Accountable	Consulted	Consulted
Periodic review		Responsible	Consulted	Informed
Archive or retire the artifact		Responsible	Informed	Accountable
Assign or transfer stewardship		Consulted		Accountable

Adapt the columns to your organization. The important part is that every row has exactly one accountable role.

Choose owners close to the system

Ownership should follow the ability to check reality:

• a platform team owns the platform diagram;
• a service team owns critical flows inside its boundary;
• an architecture group or principal engineer owns standards and the top-level context map.

Do not assign an artifact to someone without access to the implementation or the design discussions. They will approve changes they cannot verify. In repositories, CODEOWNERS can route diagram files to their stewards for review automatically.

The steward's job description

• Keep the artifact's purpose and audience explicit.
• Review, accept, or delegate proposed updates.
• Run the periodic review (how often to update architecture diagrams).
• Resolve conflicting versions.
• Label historical material, and retire the artifact when maintaining it no longer pays off.
• Check whether people actually use it.

Make contributing cheap

Engineers will not propose updates that need specialist software, special permissions, or an hour of manual layout. Let them propose changes where they already discuss the design, in text. Text-based diagrams remove the "only one person can edit this file" problem.

Handovers and departures

Rotating review duty spreads knowledge, but frequent steward changes without a handover recreate "nobody owns it". For critical diagrams, name a primary and a backup. When a steward leaves, hand over: open proposals, known inaccuracies, the review schedule, and where the source lives. Never tie an artifact to one person's account.

Assign work when the system crosses a team boundary

Suppose the Data team changes an event schema that the Billing team consumes. Data owns the schema and proposes the diagram edit because it changed the producer. The named diagram steward checks whether the shared view still answers its question, and Billing reviews the consumer edge. If one person is merely listed as “owner” but no one responds to a change request, the label has not solved the maintenance problem.

Use Arialine for the shared diagram when the discussion is in Slack: the change request can stay in the board thread and the accepted version identifies its source. Keep a backup steward for critical views and point to the owning code or schema repository from the diagram. Test the arrangement after a real change: can a reviewer find the proposer, the person who accepted the view and the evidence that the event contract changed? Do not treat a name in metadata as a substitute for that chain.

Where Arialine fits

Every Arialine board has an owner, usually its creator. Ownership can be handed over with a request such as @arialine make @dana the owner. Anyone in the channel can propose a change by addressing the board in its thread. In proposal mode, the channel default, the change waits for Apply, Edit proposal, or Dismiss. When someone other than the owner applies an edit, in either mode, Arialine sends the owner a DM with the change and version. The owner can mute alerts for that board or for all boards.

Agree as a team on who accepts changes to which board; Arialine's proposal mode then makes each accepted change visible in the thread.

Measure ownership by response, not by a name in a table

An owner is useful when they can answer scope questions, route corrections and decide whether an artifact is current, historical or draft. DORA's documentation research connects good internal documentation with effective technical work, but ownership still has to fit the organisation's actual service boundaries.

Test ownership with three events: a dependency changes, an incident exposes a missing path and an owner leaves. Record who notices, who verifies the update and how responsibility transfers. A central steward can maintain standards and discovery without becoming the author of every diagram.

Next step: choose one high-use diagram, send a correction to its listed owner and fix the handoff if nobody can act within the team's expected review window.

FAQ

Should the engineering manager own architecture docs?

They can own the process. Technical stewardship should sit with someone who can verify the architecture. In small teams those can be the same person.

Can ownership be automated?

Automation can route reviews and flag inactive artifacts. It cannot decide what matters or settle architectural disagreements.

What if the owner leaves the company?

Use shared access, versioned source, a named backup, and a handover checklist, so the artifact survives the departure.