Skip to content

Harness V3.1 governance — roles, gates and fail-closed state machine

This document is the operating model of the Harness V3.1 pilot. The decisions live in ADR-0008 (proposed); the pilot itself is OBJ-HARNESS-V31-001. Nothing here is accepted governance until ADR-0008 is accepted after the pilot verdict.

What this covers

Roles and their boundaries, the review gates, degraded routing, and the fail-closed state machine that governs every Objective under V3.1.

Roles

Role Actor Delivers Hard boundary
THINK (Architect) architect-designated profile or the operator as architect Objective Draft: WHAT / WHY / DONE (outcome, context, ACs, verification contract, constraints, boundaries, stop conditions) No Git write. Never pushes branches/commits. Never claims cards. Never judges its own draft.
OWN (Lead) wetopi-lead Objective acceptance, card decomposition, dispatch, Execution Ledger (single writer), documentation PRs Does not author WHAT/WHY/DONE it was not handed; does not judge deliveries.
DO (workers) wetopi-build, wetopi-senior, wetopi-ops Card implementation with self-validation and evidence No apply/destroy of real infrastructure from build cards; no self-approval; stays inside objective boundaries and stop conditions.
JUDGE (review) wetopi-approver or any reviewer that did NOT implement Verdicts against the verification contract: APPROVE / REQUEST_CHANGES / REJECT Does not implement or patch the delivery; does not merge without operator authority.

The Architect capability boundary

The Architect defines WHAT, WHY and DONE — nothing else:

  • Writes: outcome statement, context, acceptance criteria, the verification contract (how DONE is proven), constraints, boundaries, out-of-scope, stop conditions, review boundaries, promotion matrix.
  • Hands off: the draft to the OWN (Lead) role as an Objective Draft. Entering Git is the Lead's documentation task, via PR — the Architect never pushes.
  • May: answer questions, refine the draft on request, flag drift between execution and intent.
  • May not: hold Git credentials for the docs repo, execute cards, review its own draft, or expand the objective mid-flight (a scope change is a new draft, re-reviewed).

Gates (conditional review, fail-closed)

  1. Objective gate — the Objective Draft must be reviewed (operator or JUDGE) before the Lead acquires it. Unreviewed draft → objective does not start.
  2. Card gate — every card carries its own self-validation evidence in the DO role; the Lead spot-checks against the objective's constraints.
  3. Delivery gate — the objective's verification contract must pass independent review (JUDGE ≠ implementer) before the objective is DONE. Missing reviewer, missing verdict, incomplete evidence → blocked, never accepted. goal_mode iteration may drive a worker's loop but NEVER substitutes for this gate.
  4. Acceptance gate — the operator accepts the accepted-and-merged ADR-0008 and the pilot verdict; only then does V3.1 become standing governance. (ADR-0008 itself must already be accepted and merged before any P2 work; the post-pilot step is operator confirmation, not a second ADR acceptance.)

Degraded routing

Condition Routing
Reviewer (approver lane) unavailable Objective delivery blocks (fail-closed). The operator may appoint a substitute judge that did not implement. No auto-approval, ever.
Qwen local fails its capability gate or economics gate, or is in cooldown Qwen local is excluded; work routes to available capable lanes or blocks. Exclusion never weakens any other gate and never blocks the role design.
Worker lane unavailable The Lead re-dispatches to another capable lane inside the same role boundaries; if none, the card blocks.
Git/PR unavailable (credential or platform failure) Objective execution continues only if no gate needs the PR; otherwise blocks. No local "shadow merges".
Evidence incomplete at delivery The delivery is rejected back to DO; no partial credit.

Qwen local routability gates

Qwen local (Ollama) may participate only if BOTH gates pass:

  1. Capability gate — adequate reasoning/verbosity for the assigned role, judged on the role's evidence requirements.
  2. Economics gate — a paired benchmark on the same three non-mutating fixtures: record wall_time_validated for the direct GPT/Lead run and for the Qwen + Lead audit/rework run. Qwen is routable only if 3/3 fixture ACs pass under Qwen, Qwen makes zero cloud/GPT fallback calls, and the aggregate Qwen time is ≤ 1.20× the direct baseline. Any failure ⇒ excluded (fail-closed routing, above).

goal_mode enablement gate (fail-closed, capability-gated)

goal_mode (automatic goal continuation on a worker) is DISABLED for every real Objective until the Phase P2 smoke proves the full contract below. Like Qwen local (ADR-0008 Decisions 6/9), it is a capability-gated participant — never a replacement for the JUDGE gate (Decision 5).

Enablement gate: goal_mode may be enabled for real Objectives only after a P2 smoke run on a non-mutating scratch card proves ALL of the following, with recorded evidence:

Smoke case Required (fail-closed) outcome Prohibited
Judge DONE No promotion by goal_mode alone: DONE requires AC evidence + Lead audit + independent APPROVE auto-done, auto-merge, auto-cutover
Judge CONTINUE / FAIL Bounded turn budget honored; objective blocked/rejected as configured after the budget unbounded loops, automatic re-dispatch
Provider timeout / offline Objective lands Blocked with visible triage; goal_mode stays off silent retry storms, false DONE, silent cloud fallback
Worker/gateway restart At most one reconciled continuation run; smoke repeatable duplicate runs/workers, lost-blocker resurrection
Turn budget exhaustion Turns bounded by configuration; overflow ⇒ Blocked unlimited continuation
External-mutation watch Zero mutations outside the scratch card for every case any write outside the scratch scope

Fail-closed rule: on ANY failure, timeout, or unverifiable outcome in this smoke — and on any later regression of the above behaviors — goal_mode remains disabled for real Objectives. Disabling it never weakens any other gate and never blocks the role design; enabling it without a fully green recorded smoke is a governance violation, and a goal_mode-completed delivery judged without the JUDGE step is void.

Fail-closed state machine

stateDiagram-v2
    [*] --> Draft
    Draft --> ObjectiveReview: Architect hands off draft
    ObjectiveReview --> Accepted: reviewed
    ObjectiveReview --> Draft: review fails / REQUEST_CHANGES on the draft
    Accepted --> Executing: Lead acquires + decomposes
    Accepted --> ObjectiveReview: acquisition precondition lost
    Executing --> Delivering: cards complete with evidence
    Delivering --> DeliveryReview: verification contract exercised
    DeliveryReview --> Done: JUDGE approves
    DeliveryReview --> Executing: REQUEST_CHANGES
    Done --> AcceptedGovernance: operator confirms standing governance (pilot positive)
    Done --> Closed: operator rejects standing governance (lessons kept)
    ObjectiveReview --> Blocked: no reviewer / verdict
    Accepted --> Blocked: Lead acquisition unavailable
    Executing --> Blocked: dispatch fails at this phase
    Delivering --> Blocked: no verdict / evidence gap
    DeliveryReview --> Blocked: no reviewer / verdict
    Blocked --> ObjectiveReview: re-enter the gate this phase requires
    Blocked --> Abandoned: stop condition / rollback trigger
    Abandoned --> [*]
    Closed --> [*]
    AcceptedGovernance --> [*]

Fail-closed recovery rules:

  • Blocked always records which phase it arose in. Its only exit is back to the gate that phase requires — ObjectiveReview blocks return to ObjectiveReview, post-acceptance blocks (acquisition/dispatch/ delivery) return to the review or dispatch gate of their own phase. There is NO Blocked -> Executing bypass edge.
  • Delivering blocked on missing reviewer/evidence goes to DeliveryReview only when a competent independent reviewer (JUDGE ≠ implementer) is actually available; otherwise it stays Blocked. Recovery never re-enters Executing with unfixed evidence.

Invariant: every non-happy path lands in Blocked or Abandoned, never in a silently-accepted state. Abandonment and rollback follow the triggers in ADR-0008 Decision 7.

Relationship to level-1 / level-2 sources

  • Git Objectives = level-2 versioned contracts (this repo).
  • Kanban board + Work Ledger = level-1 operational state (live).
  • The Execution Ledger (Lead single-writer, level 1) cross-references the objective's commit/PR SHAs; Git never copies live state back. See the ledger template.