Governance approves evidence, not provenance

A Build Studio draft advances through a phase when the evidence required by the gate is present and passes review — regardless of whether Build Studio dispatched the specialists that produced the evidence, whether the operator hand-coded the change, whether the work came through an external branch, or whether a different coworker produced the artifact. Governance evaluates evidence quality, not producer identity.

Operator-ratified 2026-05-18 in the PR #761 discussion, when evaluating how to handle a draft stuck in ideate after the implementation PR had already landed independently. The principle-based answer: use the gates with the available evidence; never mark complete to bypass the gates.

The rule

When a phase gate is invoked:

1. Read the evidence fields the gate requires (designDoc, buildPlan, verificationOut, acceptanceMet, phaseHandoff, etc.).
2. Run the gate’s evaluation against that evidence — does it pass on quality, completeness, and the gate’s specific predicates?
3. Advance if the evaluation passes; block if it fails. The decision is identical regardless of who or what produced the evidence.

Producer identity is a useful audit field, not a gate input.

Two ways this gets violated

Path A — bypassing the gate. “The PR already landed; just mark the draft complete.” This skips review entirely. The draft moves to complete without the gate’s evidence checks ever firing. Future audits cannot reconstruct whether the work actually met the gate’s quality bar — only that someone clicked a button.

Path B — gating on producer. Gate logic that contains if (producerAgent === "AGT-ORCH-300") { allow } or if (sourceBranch.startsWith("claude/")) { require extra review }. This makes the gate brittle (new producers need code changes), discriminatory (identical evidence quality, different gate decision), and unable to handle the legitimate case of an external producer with strong evidence.

Both paths reach the same failure mode: governance signal degrades because the gate stops being a function of evidence.

How to apply

• When a draft is stuck behind a gate but external evidence satisfies the gate’s requirements, seed the evidence fields (saveBuildEvidence for each missing field, or save_phase_handoff for cross-phase transitions) and advance through the existing gate. Each transition still runs checkPhaseGate — nothing is rubber-stamped.
• When designing a new lifecycle gate, the gate’s input shape must be the evidence the gate needs, not the identity of the actor or the path that produced it. No “did Build Studio dispatch this” checks. No “is the author the spec owner” checks. Only evidence-quality checks.
• When reviewing a PR that adds a gate, look for producer-conditional logic and reject it. The reviewer’s question is “does this gate pass identical evidence identically?” — if not, it is a provenance gate masquerading as an evidence gate.

When this principle conflicts with others

It can appear to conflict with destructive-actions-require-explicit-go (some destructive actions do require fresh operator approval per call) and with HITL gates that require human acknowledgement. The resolution: those principles add additional requirements on top of evidence quality (a fresh approval is itself evidence the gate requires), they do not subtract the evidence requirement. A destructive action with operator approval but no evidence still does not advance; an action with strong evidence but no fresh approval still does not advance. Both fire when both apply.

Anti-pattern

• “Mark complete and skip the gates” as a shortcut. This is the standing operator-forbidden move, no matter how strong the external evidence appears. The principle is to use the gates with the available evidence, not bypass them.
• Gate logic that branches on producer / dispatcher / sourceAgent fields. Audit log, yes. Gate input, no.
• Asymmetric trust by author identity (“Mark’s commits skip review; coworker commits get full review”). This compounds in two directions: the platform stops detecting Mark’s mistakes, and the coworker can never accumulate trust. Both erode the autonomy ladder.

Additivity to Never Fabricate

The 2026-05-26 mechanical overlap scan (principle_decide, ring scope [ring-2-workflow, ring-4-sandbox-prod]) returned a 0.74 dimension-vector alignment against never-fabricate, crossing the §4.3 ship-freely threshold of 0.70 and triggering the additivity-paragraph requirement.

The alignment is dimension-driven, not decision-moment-driven. Both principles score high on governance_compliance and evidence_density because both protect the truth substrate the platform depends on. But they bind different decision moments:

• Never Fabricate binds the producer moment: “do not invent facts, results, or capabilities you did not actually observe.” It governs what a coworker is allowed to say.
• Governance-approves-evidence-not-provenance binds the gate-evaluator moment: “when a phase gate fires, evaluate the evidence presented, not who or what produced it.” It governs how a gate is allowed to decide.

A coworker that fabricates evidence violates Never Fabricate (the producer rule). A gate that branches on producer === "AGT-ORCH-300" violates this principle (the evaluator rule). The two failures occur at different layers, are detected by different audits, and are repaired by different changes. They compose: a healthy system needs both — non-fabricated evidence reaching a gate that evaluates that evidence on quality alone. Removing either makes the other insufficient.

Build Gate Mandatory (0.70 in the same scan) and All Changes Land via PR Against Main (0.69) sit at similar alignment for the same dimensional reason and the same additivity logic applies.

Why one rule, not a per-case enumeration

Per verify-substrate-before-proposing-new, the alternative is a growing list of “external branch ok if X,” “operator hotfix ok if Y,” “hand-coded BI ok if Z” exceptions. Each exception is a gate that the next producer scenario will not fit. One rule — gate on evidence — generalizes to every future “non-Build-Studio producer” scenario without code changes to the gate.

Related principles

• human-in-the-loop-at-phase-boundaries — defines where the gates fire; this principle defines what they evaluate.
• evidence-before-diagnosis — the upstream form for runtime claims; the same shape applies at gate decisions.
• structural-verification-is-not-functional — names what counts as evidence at the ship gate specifically.
• structured-handoffs-not-conversation-history — the artifact shape phase handoffs produce so the next gate has structured evidence to read.
• verify-substrate-before-proposing-new — why one principle generalizes better than a per-producer rule list.