13. The Role Replacement Program
Story moment
The scoreboard only moves on receipts
A role earns a percentage only when receipts prove Zach no longer performs the routine responsibility. Until then it shows an honest maturity state, not a number. Everything else is motion.
Executive Summary
What this chapter establishes
The Role Replacement Program defines the SDLC Orchestrator scorecard and how deltas are reported.
The scoreboard makes autonomy measurable at the role level, not the feature level.
The baseline is under 25%; most responsibilities still require Zach.
90%+ of routine SDLC orchestration runs through governed capabilities.
Move responsibility by responsibility, attaching evidence and receipts to each delta.
The program’s first full target is the SDLC Orchestrator — the operational mechanism that moves software delivery forward. The scorecard below is the canonical instrument; one exists per target role.
13.1 The SDLC Orchestrator scorecard
Section titled “13.1 The SDLC Orchestrator scorecard”Role Replacement Scorecard — SDLC Orchestrator (percentages are the live reading in
CURRENT_STATE.md; shown here illustratively)
- Current human: Zach · Replacement target: GLoops operational capabilities
- Current replacement: < 25% · Desired: 90%+ of routine orchestration
- Preserved human responsibilities: product judgment · priority tradeoffs · reserved authority · customer/accountability decisions
- CEO test: if Zach did not show up tomorrow, Ready-issue discovery → clarification → implementation → verification → adversarial review → PR → receipts → learning would not continue end-to-end.
| # | Responsibility | Replace or preserve | Replacing capability | ▣ Current grade |
|---|---|---|---|---|
| 1 | Watch GitHub issues | replace | Issue Discovery | not started |
| 2 | Identify Ready issues | replace | Issue Discovery | not started |
| 3 | Judge whether Ready issues are truly clear | replace | Issue Understanding | not started |
| 4 | Ask product-friendly clarifying questions | replace | Issue Clarification | built (dry-run) |
| 5 | Decide an issue is ready to build | preserve (judgment) | — | human |
| 6 | Create implementation plans | replace | Build Planning / RT Generation | not started |
| 7 | Spin up Codex/Claude/Hermes agents | replace | Implementation Dispatch | not started |
| 8 | Monitor agent progress | replace | Verification Coordination | not started |
| 9–13 | Review impl · run/check tests · request adversarial review · check CI · determine PR readiness | replace | Verification · Adversarial Review · PR Review · Merge Readiness | not started |
| 14 | Resolve blockers | replace (judgment-only blockers preserved) | Blocker → follow-up Work Order | not started |
| 15 | Prepare merge decisions | preserve final Go/No-Go | Merge Readiness (recommends) | not started |
| 16 | Update documentation & receipts | replace | Receipt generation | partial (built) |
| 17 | Carry context between issues/PRs/tests/decisions | replace | Context Assembly (GBrain) | built (flagged) |
| 18 | Learn from prior work | replace | Learning loop | not started |
A role is not replaced when one capability exists. It is replaced when the human no longer performs the routine responsibilities that define it — and receipts prove it.
13.2 How a delta is reported
Section titled “13.2 How a delta is reported”Each cycle reports the movement, in this exact shape:
role: SDLC Orchestratorreplacement_previous: 23%replacement_current: 31%delta: +8%evidence: - issue clarification loop operational - PR readiness verdict visible - blocker follow-up auto-dispatchedremaining: - implementation dispatch - verification loop - adversarial review loop(The numbers above illustrate the report format; the honest current baseline is < 25%, per CURRENT_STATE.md.)
Chapter closeout
Decision ledger
Key Decisions
- A role is replaced only when the human no longer performs its routine responsibilities.
Open Questions
- Which responsibilities should remain human permanently?
Related Chapters
- Role Replacement Explorer
- Role Scorecards
- Ch. 15 - Success Metrics