Skip to content

Chapter 6 — Governance and provenance architecture

Chapter 5's stage 6 showed governance in motion inside one engagement. This chapter describes the machinery as a system: the pipeline, the taxonomies, the namespaces, the lanes, and the property that makes the whole thing credible — the project runs itself on it.

6.1 The three-gate pipeline

Rosetta's governance is one pattern applied everywhere: raw decisions are captured cheaply, then promoted through progressively stricter review until they become authoritative — and nothing becomes authoritative any other way.

flowchart TB
    DT["DecisionTrace<br/><i>captured at the moment of decision:<br/>state, alternatives, reasons, evidence</i>"]
    G1{"Gate 1 — ingestion validation<br/>completeness + coherence scores"}
    PC["PromotionCandidate<br/><i>traces grouped by decision point</i>"]
    G2{"Gate 2 — promotion evaluation<br/>volume · coverage · consensus"}
    GR["GovernanceReview"]
    G3{"Gate 3 — human review<br/>approve / reject / request revision"}
    ADR["ADR — accepted, authoritative,<br/>GOVERNS its patterns"]
    DT --> G1 --> PC --> G2 --> GR --> G3 --> ADR

Three properties matter more than the mechanics:

  • Capture is cheap and agent-native. A DecisionTrace costs one idempotent write (rosetta_record), so the honest path — record the decision when it happens, with its alternatives — is the easy path. The v1.3 trace shape requires the state at decision time and the alternatives considered, which is what makes the record useful at review rather than ceremonial.
  • Promotion is earned, not declared. The gates score real attributes (Gate 1: is the trace complete and coherent; Gate 2: do enough traces, covering enough outcomes, agree). QualityFlag nodes attach at any gate to track issues.
  • The terminal act is human. Gate 3 is a recorded review with three outcomes, and the agent write-safety contract makes the agent's role explicit: it executes operator decisions on the review surface; it never approves its own promotions.

The same three-gate shape runs in parallel for other artifact families (spec manifests through their own draft → pending → approved ladder; source documents through the document-lifecycle state machine with tag proposals), so a reviewer learns one pattern and reads the whole system.

6.2 ADRs are never born "Proposed"

The rule that gives the pipeline its bite: no one authors an ADR directly. ADRs are promoted from ratified DecisionTraces, in every repository, at every altitude. The producer repo's constitution states it as an operating instruction to every agent session ("Do not author new ADR-PL files"); the umbrella states it as constellation invariant X-5. The one recorded exception proves the rule: the seven genesis ADRs of the constellation layer itself were bootstrapped alongside their DTs in a simulated compile, are stamped PROPOSED/SIMULATED on their face, and carry a standing, written obligation (ADR-RX-007) to re-compile for real and reconcile the diff to zero. An honest IOU in the middle of the governance record is itself evidence the record means something.

A complementary taxonomy governs how work lands: every PR is gated Pass / Revise / Abort / Escalate (ADR-PL-014). "Abort" is reserved for constitutional violations — close the PR and amend the manifest through a PromotionCandidate before respawning the work. "Escalate" means the agent wrote a DecisionTrace and stopped. Silent quarantines (a disabled CI job, a continue-on-error) are named violations of this taxonomy — the gate discipline extends to the build system itself.

6.3 The namespace map

Decisions live where their blast radius lives, and the prefix says which court you are in:

Series Scope Count at snapshot
ADR-PL-* / platform DTs Producer repo 22 ADRs
ADR-GO-* App server 21 ADRs
ADR-PA-* / dt-pa-* Plugin family 11 ADRs (+2 pending)
ADR-RCP-* rosetta-agent plugin lineage folded into the platform manifest's Epic E7
DT-D360-* Advisory framework 5 DTs
DT-RX-* → ADR-RX-* Cross-repo (≥2 repos, or any X-contract) 33 DTs; 24 promoted ADRs

The escalation rule is mechanical: a decision local to one repo gets that repo's prefix; a decision touching two repos or a §2 contract must be authored in the umbrella as a DT-RX. In practice the record shows the rule being followed — the metamodel bumps, the canvas contract, the ratification lane, the docs platform, and the org boundary are all RX-series with their member-repo implementation halves cross-referenced.

6.4 The provenance substrate

Underneath the decision pipeline sits the evidence layer, and it is unusually complete:

  • Evidence tethering. Canonical content cites its sources: SourceArtifact nodes with CITED_BY edges to every node they support, seeded from a corpus whose membership is itself a governed manifest. The research pipeline refuses to author nodes without tethers, and the validation stage gates on it.
  • ProvenanceEvents. Schema mutations, twin applies, compiles, ratifications, and production migrations each record a provenance event with actor and mode. The master manifest's own compile event — actor, date, mode: SIMULATED — is in the graph seed.
  • The per-node lanes (Chapter 2 §2.5): provenance separates confirmed from simulated content; reviewStatus separates agent authorship from human ratification, with terminal states and a server-enforced one-way state machine.
  • The consumption side. These labels do things: the codex customer tone hard-fails on unconfirmed content; renders segregate or strip simulated nodes by default in customer and leadership tones while audit tone shows them with visible chrome; the rehearsal lane can only mint simulated content; and ratification — the one act that flips content to confirmed — is structurally human (three independent enforcement layers, per Chapter 5 stage 6).

6.5 Self-application, and what it proves

The strongest credibility claim available to a governance system is that its authors submit to it, and here the record is unambiguous: the constellation's own development runs on its own machinery. The project is modeled as an engagement of itself (DT-RX-003); its master manifest is compiled by its own codex; its cross-repo decisions ride the same DT → PC → ADR ladder it sells; its remediation work traces from ledgered run findings through ratified DTs to shipped releases (Chapter 9); and its most recent open decision at snapshot — fact-level bitemporality — is the governance system metabolizing a weakness its own evaluation lane discovered.

The honest caveat, which Chapter 10 weighs: self-application currently has a single ratifier. Every RATIFIED in the record is one person's signature, which makes the process disciplined but not yet independent — a bus-factor observation about the organization, not a defect in the machinery.

Operations next: Chapter 7. The measurement system the governance loop feeds on: Chapter 9.