Govern: Authority, Honesty & Review
Story moment
Authority becomes a product surface
The Action Queue is where true judgment is preserved: one decision, evidence attached, consequence visible, receipt returned. Six ROM gates say whether a mutation may proceed without escalation; four review gates prove the slice actually removed burden.
Executive Summary
What this chapter establishes
Authority is earned and delegated where ROM gates hold; honesty grades and four review gates prove every slice actually removed burden; named anti-patterns identify the ways to look like progress while the human remains the mechanism.
How authority is earned and kept trustworthy, how a slice of work is chosen and verified, and how the portfolio avoids mistaking activity for autonomy. (Canonical homes: EXECUTION_PRINCIPLES.md for honesty grades and model roles; WORK_ORDER_SPEC.md for Work Order governance.)
Honesty grades and the cardinal sin
Section titled “Honesty grades and the cardinal sin”Every status claim, commit, and capability description must state which honesty grade it makes. Claiming a higher grade than the evidence supports is the cardinal sin — it poisons the very trust substrate the products exist to provide.
| Grade | Means | Does not mean |
|---|---|---|
| Built | Code exists, tests pass | That it runs in reality |
| Operational | Running in production against real targets, used by real users | That it is trustworthy (a single happy-path run is never “proven”) |
| Proven | Demonstrated trustworthy by independent audit at the bar to increase autonomy | That one agent self-graded it |
| Blocked | Was operational/proven, now prevented by infra/credentials/dependency | That it needs a rebuild — it needs a named unblock |
Burden Verification — the required proof of every slice
Section titled “Burden Verification — the required proof of every slice”Every slice that touches a recurring human dependency must answer the Burden Verification block. If the answer to “What does the executive stop doing tomorrow?” is “nothing,” the slice is not complete.
| Burden Verification field | |
|---|---|
| Role targeted | which Operational Role |
| Responsibility replaced | which recurring duty |
| Prior human mechanism | what the human did |
| New GLoops mechanism | what now does it |
| Where the executive experiences the change | which product surface |
| Evidence / Receipt | addressable proof |
| What the executive no longer does / still does | the honest split |
| Role Replacement Delta | the percentage movement |
Authority and the ROM / Reserved distinction
Section titled “Authority and the ROM / Reserved distinction”The governance model exists to let agents act for months without re-litigating decisions, escalating only the few things that genuinely require the human.
The reserved boundary is unbounded authority, not mutation. A real-world mutation that satisfies all six gates — scoped · receipted · reviewable · reversible · fail-closed · within delegated authority — is a Routine Operational Mutation (ROM): it is the purpose of the platform and is delegated, not escalated. The test is conjunctive and fail-closed: if any one gate fails or is unproven, the action is Reserved. Blast radius, not target system, sets the class.
| Routine Operational Mutation — DELEGATED | Reserved — ESCALATES to the executive | |
|---|---|---|
| Examples | GitHub comments/branches/commits/PR creation; Hermes/GLoops/Ralph/Portfolio updates when all six gates hold | Production authority; authority widening (rung promotion / scope / Trusted Lane); irreversible production actions; customer-impacting execution; security-boundary changes; constitutional changes |
| Why | Mutation alone does not reserve; this is what the platform is for | Each is a case where a ROM gate cannot hold |
| Check | The Work Order attests each gate (mutation_class: routine); a separate-agent review confirms it near the boundary |
Recorded once as a persistent Action Queue item — not re-prompted each cycle |
Decision rights — one obvious owner per decision
Section titled “Decision rights — one obvious owner per decision”| Decision type | Owner |
|---|---|
| Roadmap/slice selection, priorities within a product | That product’s agents, under its doctrine |
| Architecture & naming within a product | That product’s agents |
| Promotion-readiness threshold values | GLoops agents — raising a bar is delegated; lowering one escalates |
| The boundary, the Capability API contract & wire design, shared vocabulary, which product owns a new concept | Portfolio Steward |
| Routine Operational Mutations (all six gates hold) | Delegated |
| Reserved boundary = unbounded authority | the executive (escalation) |
The Portfolio Steward is an Opus-level agent holding portfolio authority (or the executive). It both adjudicates portfolio/cross-boundary questions (by ADR) and generates the portfolio’s governed work as Work Orders — not prompts. It holds portfolio authority but no execution authority: it asks and authorizes; GLoops performs.
The Work Order — the organizational-execution primitive
Section titled “The Work Order — the organizational-execution primitive”A Work Order is a durable, governed, identified expression of delegated organizational intent: “this capability work should exist — here is why, where, under what authority, and how completion is judged.” It is immutable once issued; changes by supersession. It is not a prompt, a GitHub issue, an ExecutionRequest, a Capability, an ADR, or a Decision Brief.
Three distinct, never-confused records anchor trust at three altitudes:
| Receipt type | Records a decision about… | Owner |
|---|---|---|
| Receipt | An operational action (who decided, original/final action, reasoning, evidence, outcome) | GLoops |
| Decision Record | An executive decision (brief, perspectives, dissent, evidence, authority set) | Ralph |
| Portfolio Receipt | A stewardship decision (issue/escalate/withdraw/close a Work Order, move a grade) | Portfolio Steward |
The two gate systems — they compose, not collide
Section titled “The two gate systems — they compose, not collide”The six ROM gates (scoped · receipted · reviewable · reversible · fail-closed · within authority) answer a permission question: may this mutation proceed without human escalation? The four review gates (Planning · Implementation · Burden · Operational) answer a proof question: did this slice actually remove human burden and earn its claimed grade? The ROM gates govern whether an action is safe to delegate; the review gates govern whether a slice proved its value. Both must hold; they are not the same checklist.
The four review gates
Section titled “The four review gates”Work passes through gates, in order. Each is a checklist, not a vibe.
| Gate | When | Must hold |
|---|---|---|
| Planning Gate | Before implementation | Role identified · burden stated · capability proposed · reusable boundary clear · executive’s day-change clear · risks known · verification plan clear |
| Implementation Gate | Before merge | Tests pass · typecheck passes · no authority widening · no auth weakening · evidence produced · receipt path exists · independent review where needed |
| Burden Gate | Before claiming success | Human burden removed · operator-visible outcome exists · the executive no longer performs the step · receipts prove it · role scorecard updated |
| Operational Gate | Before calling something operational | Runs without human trigger · works on live input · produces receipts · health monitoring exists · failure modes known · rollback exists |
Anti-self-grading (the discipline behind the gates). “Proven” requires independent audit of a random evidence sample by a separate adversarial agent — threshold math on self-produced evidence is not enough. Never self-merge governance code (authority, receipts, promotion/readiness, evidence schema, the Capability API): it goes through review by a separate agent even when no human is available.
Anti-patterns — the named failure modes
Section titled “Anti-patterns — the named failure modes”Each is a way to look like progress while the real goal stalls. Name them out loud when you see them.
| Anti-pattern | What it looks like |
|---|---|
| Artifact Worship | Mistaking PRs, docs, comments, or JSON for outcomes |
| Advisory Dead End | Producing a BLOCKED comment with no follow-up execution initiated |
| Local Optimization | Improving one feature while ignoring role replacement |
| Strategy Churn | Writing more doctrine when the runtime is missing |
| Human as Event Bus | Depending on a person to wake the system |
| Human as Dispatcher | Depending on a person to route work between repos |
| Surface Without Use | Building UI no one uses and claiming burden reduction |
| Capability Without Consumption | Building a reusable capability no organization consumes |
| Replacing Judgment | Automating decisions that should remain executive judgment |
| Project-Manager Steward | Shepherding every implementation instead of managing throughput |
The model roles — who does what
Section titled “The model roles — who does what”| Role | Used for | Never |
|---|---|---|
| Opus | Judgment that could change a thesis, boundary, authority model, or public abstraction; role decomposition; planning checkpoints; adversarial review; executive synthesis; final acceptance | Mechanical code changes unless necessary |
| Sonnet | Execution of a scoped slice: UI implementation, frontend, tests, refactors, moderate backend, reconciling stale docs | Redefining a thesis, boundary, vocabulary, or governance rule |
| Codex | Code implementation, test repair, repo operations, focused backend, mechanical refactors, PR prep — selecting its reasoning tier by task class (CODEX_USAGE_POLICY.md) |
Choosing slices or making product decisions; high reasoning tier never grants authority |
| Hermes | Persistent/background execution, cross-repo orchestration, scheduled/event-driven tasks, evidence collection, receipts | — (it is the execution plane, not a decision-maker) |
The rule: scope with Opus when judgment is needed; execute with Sonnet or Codex; never the reverse.
Planning Checkpoint & delegated execution
Section titled “Planning Checkpoint & delegated execution”Before major implementation, the Portfolio Steward produces a Planning Checkpoint answering: target role · responsibility replaced · current human burden · proposed capability · product surfaces affected · execution organizations · reusable-vs-org-specific boundary · evidence/receipts expected · verification plan · burden verification · risks · reserved decisions · explicit “how the executive’s day changes.” Implementation starts only after checkpoint approval — unless the slice is routine, reversible, already authorized, and clearly within delegated authority.
The Steward is an executive, not a project manager. Once a Work Order has an execution owner, active implementation, a verification plan, and a receipt path, the Steward monitors but does not shepherd. If execution stalls, it intervenes; if it proceeds, the Steward continues elsewhere. The portfolio is parallel capability streams, not a single queue — a reserved decision pauses only its dependent stream.
Part IV — The Product
Section titled “Part IV — The Product”Chapter closeout
Decision ledger
Key Decisions
- Built to built is motion, not progress.
- Reserved boundary equals unbounded authority, not mutation.
- Proven requires independent audit.
- Governance code is never self-merged.
- Codex must report reasoning tiers.
Open Questions
- Where should ROM gate evidence be displayed in the product?
- Which anti-pattern should be instrumented first?
- Which verification evidence should become native product receipts first?
Related
- Action Queue Flow
- Product Surfaces
- Role Scorecards
- Source Map - Execution Principles