8. Execution Doctrine
Executive Summary
What this chapter establishes
Execution doctrine prevents artifact worship by requiring honest grades, verification, and role-burden proof.
How a slice of work is chosen, verified, and committed. (Canonical home: EXECUTION_PRINCIPLES.md; this chapter is the narrative synthesis.)
8.1 Outcome over artifact, and the honesty grades
Section titled “8.1 Outcome over artifact, and the honesty grades”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 |
8.2 Burden Verification — the required proof of every slice
Section titled “8.2 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 Zach 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 Zach experiences the change | which product surface |
| Evidence / Receipt | addressable proof |
| What Zach no longer does / still does | the honest split |
| Role Replacement Delta | the percentage movement |
8.3 The model roles — who does what
Section titled “8.3 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.
8.4 Planning Checkpoint & delegated execution
Section titled “8.4 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 Zach’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.
Chapter closeout
Decision ledger
Key Decisions
- Built to built is motion, not progress.
- Codex must report reasoning tiers.
Open Questions
- Which verification evidence should become native product receipts first?
Related Chapters
- Ch. 10 - Review Gates
- Role Scorecards
- Source Map - Execution Principles