Governed Autonomy Journey

State — none yet; the boundary is not yet declared.

Before any position exists, the work needs a typed boundary: a bounded input, a bounded output, and a named governed effect. An unbounded workflow — prose instructions with no typed input or output and no declared effect — cannot enter the autonomy spectrum, because there is nothing to instrument, evaluate, or gate.

The example carried through this page is bounded_publication: input draft_post, output published_post, governed effect publishing a drafted post to a declared channel. The declaration also names two runtime scopes up front, publish:community and publish:professional, because the two channels will need independent authority later in the sequence.

Declaring a boundary does not authorize anything by itself. It defines what every later evidence record, decision artifact, and motion will reference back to.

Invariant: An unbounded workflow cannot enter the spectrum: no typed boundary, no evidence, no gate.

Lifecycle — Bound →

State — position manual, deployment active for scope publish:community

The instrumented task enters the spectrum at manual with deployment active for the human-performed effect that already exists: a person still drafts and publishes every post. What changes is that the boundary input, the boundary output, and the human outcome are now emitted as evidence records instead of disappearing after the fact.

Manual is on-spectrum, not a synonym for disabled or unmanaged. The task is governed from the moment it is bounded and instrumented — governance begins before any candidate automation exists, not after.

A structural evaluator is attached even at this stage, because the evidence-record contract requires a complete producing evaluator identity on every record — there is no such thing as an unevaluated evidence record.

Invariant: Manual is the first on-spectrum position: the human performs the effect, and the effect is observable.

Lifecycle — Instrument →

State — position manual, deployment shadow for scope publish:community

Candidate automation is introduced with deployment shadow while position stays manual: the candidate drafts a response for every case, but its output never reaches a reader. The human continues to perform the governed effect exactly as in Stage 2.

Two evaluators assert the same property, response_quality, on the overlapping cases — a rubric-driven LLM judge with proxy epistemic status and advisory authority, and a human reviewer with human_gold epistemic status, also advisory. Neither the candidate output nor either verdict authorizes anything; both accumulate agreement evidence for later stages.

Shadow never grants authority. A shadow-deployed candidate can be wrong in every case without affecting a single reader, which is exactly why it is safe to run before any evidence has accumulated.

Invariant: A shadow deployment and an advisory verdict can each accumulate evidence, but neither can authorize the governed effect.

Lifecycle — Evaluate →

State — position manual, deployment shadow for scope publish:community

A declared, typed window — 200 cases, in this walkthrough — is consumed through the task's declared admissibility policy. First-match exclusion rules remove records that fail admissibility (a missing boundary output, a duplicate subject, a stale evaluator version), and the eligible population is capped.

The frozen population is evaluated against the declared promotion rule as the decision artifact is finalized. Only after the artifact records its eligible or ineligible outcome is the completed artifact content-hashed, with exact included and excluded evidence references and a reason for every exclusion. Recording evidence in Stage 2 and Stage 3 did not make it admissible — this snapshot is the first artifact that decides admissibility.

Invariant: Recorded evidence is not automatically admissible evidence; admissibility is a declared, snapshotted decision.

Lifecycle — Accumulate →

State — position manual, deployment shadow for scope publish:community

The finalized decision artifact from Stage 4 records that the frozen population satisfies the declared report and window. This stage reads its eligible outcome as the basis for a possible motion; it does not rewrite or re-hash the artifact.

Eligibility changes nothing else. Position, deployment, and evaluator authority are exactly what they were in Stage 4 — folding the event history at this point still resolves both declared scopes to manual, because no motion has been proposed yet. Eligibility is evidence that a motion could succeed, not the motion itself.

Invariant: Eligibility is a decision-artifact outcome, not a position change. A motion must still be proposed and resolved.

Lifecycle — Promote →

State — position manual, deployment shadow for scope publish:community

The eligible decision artifact from Stage 4 and Stage 5 lets a motion be proposed: motion_proposed, bound to the artifact's canonical bytes by evidence_ref and evidence_sha256. The declared execution mode for this promotion is operator_approval, so a named person must ratify the motion before anything changes.

operator:jordan_lee reviews the bound evidence and approves it: motion_approved, carrying the same actor and a stated reason. Had the reviewer found the evidence wanting, the alternative terminal branch is motion_rejected — the motion ends there, and position stays manual with no further event required.

Automatic execution uses this identical event model with a system actor in place of a named person; approval and rejection are not special-cased per execution mode.

Invariant: A motion is proposed and resolved by a named actor or a system actor — it does not fire itself.

Lifecycle — Promote →

State — position hitl, deployment shadow for scope publish:community

The approved motion emits its third and final row, position_changed, for exactly one declared scope: publish:community moves from manual to hitl. Current position is not a stored field anywhere — it is a fold over this append-only event stream, and folding it now returns hitl for this scope.

publish:professional shares the same declaration and the same initial_position, but it has never had a motion proposed against it. Folding its event history returns exactly what it started with: manual. There is no wildcard scope and no sibling-scope inheritance — a motion approved for one scope changes authority for that scope alone.

Invariant: position_changed is scoped to exactly one declared scope; no other scope is affected by the same motion.

Lifecycle — Promote →

State — position hitl, deployment active for scope publish:community

Activation is a declaration change, not an in-place state mutation. A new declaration version sets deployment to active for the task; because position is keyed by declaration_version, no scope inherits position from the shadow version. After a new exact-scope motion establishes publish:community at hitl under the active declaration, candidate automation prepares each publication, blocking evaluators must pass, and a human authorizes execution before a post reaches the community channel. publish:professional remains at the new declaration's manual initial position — active deployment did not grant it authority it was never promoted into.

Per-case selective autonomy can still route or escalate individual cases inside publish:community — routing a low-confidence draft straight to a human, for instance — without creating another position. That routing lives inside the hitl scope's operation; it is not a fourth position and it does not touch publish:professional.

Once measured agreement between the two response_quality evaluators clears the calibration bar, a later declaration version is published: a distilled classifier succeeds the rubric judge as the blocking evaluator for response_quality, and the human_gold evaluator drops to advisory calibration. Historical evidence keeps the identity of the evaluator that produced it — nothing is rewritten — and the version change starts a new evidence partition; position for that version resolves from its own initial position until new exact-scope events occur under it.

Invariant: Deployment and evaluator succession require new declaration versions; neither silently mutates a position or an evidence record already on file.

Lifecycle — Gate →

State — position manual, deployment active for scope publish:community

Demotion has two legitimate triggers, and neither waits for the promotion window to refill: an operator may demote at any time, and a declared policy failure can fire a demotion motion on its own. This task's demotion.window is kind: cases, size: 1 — a single confirmed failure is sufficient to open a demotion motion for publish:community.

A confirmed failure is observed, and operator:jordan_lee commits the demotion as one immediate action: motion_proposed, motion_approved, and position_changed for publish:community only, moving it back from hitl to manual. publish:professional, never promoted, is untouched by this motion.

Demotion is a real, executable path, not a metric that is only ever discussed. The same three-row event model that promoted this scope in Stage 6 and Stage 7 demotes it here, immediately, for one named reason.

Invariant: A policy failure or an operator can demote immediately, on a one-case window, for the affected scope only.

Lifecycle — Demote / Fall Back →