Skip to content
GLoops Operating Manual

14. The Transformation Roadmap

Chapter 14

Executive Summary

What this chapter establishes

The roadmap organizes work into five executive programs rather than a feature backlog.

Operator ExperienceEach phase says what stops being manual and where the operator experiences the change.
Concept trail
Operational RoleRole ReplacementWork OrderReference RealizationReceipt

The roadmap is five executive programs, not a feature list. Each answers the same eight questions, so an executive can read any phase and know what it costs, what it changes, and how it’s judged.

Transformation Program Timeline
Transformation Program TimelineWhat to notice: Notice runtime stability comes first; every later program depends on it.

Phase 1 — Stabilize the Runtime

  • Purpose: GLoops can execute work without Zach as the trigger.
  • Operator change: work starts because an event fired, not because Zach prompted.
  • Capabilities: ExecutionRequests · Hermes runner · Work Order ingestion · scheduler/event substrate · receipts · status · basic Action Queue.
  • Success criteria: work starts without prompting · status is visible · receipts exist · stalls surface automatically.
  • Review gates: Operational Gate on each runtime capability.
  • Expected burden reduction: Zach stops being the event bus and dispatcher.
  • Role replacement delta: unblocks responsibilities 7–8, 16.
  • Product surfaces: basic Action Queue, status.

Phase 2 — Replace SDLC Orchestrator for Induct (the headline phase)

  • Purpose: Zach no longer runs Induct’s SDLC.
  • Operator change: Zach handles only true product judgment and Go/No-Go.
  • Capabilities: issue discovery · understanding · clarification · planning · implementation dispatch · verification · adversarial review · PR readiness · merge readiness · blocker resolution.
  • Success criteria: Ready issues understood · clarifying questions drafted/posted · build plans prepared · implementation starts · PRs include evidence · blockers trigger follow-up.
  • Review gates: Burden Gate on each responsibility; scorecard updated each slice.
  • Expected burden reduction: the bulk of the SDLC Orchestrator role.
  • Role replacement delta: the primary metric — drive < 25% → 90%+.
  • Product surfaces: Capability Portfolio, Action Queue, Role Replacement Dashboard.

Phase 3 — Build Product Surfaces

  • Purpose: Zach interacts through GLoops and Ralph, not chat.
  • Operator change: Zach opens GLoops to see work and opens Ralph to decide; markdown reports shrink; prompting becomes rare.
  • Capabilities: Action Queue · Capability Portfolio · Organization Portfolio · Portfolio Health · Executive Updates · Ralph room.
  • Success criteria: Zach opens the products instead of being prompted.
  • Expected burden reduction: the recurring /goal prompting loop itself becomes a surface.
  • Role replacement delta: makes replacement visible and governable.
  • Product surfaces: all of Part IV.

Phase 4 — Operationalize Knowledge

  • Purpose: the system remembers.
  • Operator change: Zach stops repeating context; agents cite prior decisions.
  • Capabilities: GBrain · ingestion · cross-linking · contradiction detection · precedent retrieval · context assembly.
  • Success criteria: repeated corrections become capability improvements.
  • Role replacement delta: completes responsibilities 17–18.
  • Product surfaces: Knowledge Graph, Receipt Explorer.

Phase 5 — Generalize Beyond Induct

  • Purpose: GLoops operationalizes new organizations through onboarding, not reinvention.
  • Operator change: a second organization consumes capabilities instead of triggering a rebuild.
  • Capabilities: organization onboarding · adapter model · capability consumption · role replacement scorecards · organization health · Reference Realization comparison.
  • Success criteria: new orgs consume existing capabilities; reference realizations improve the platform; platform improvement benefits all orgs.
  • Role replacement delta: proves the flywheel across orgs.
  • Product surfaces: Organization Portfolio.

▣ Current Reality of the roadmap. The portfolio is early in Phase 1. The dispatch spine is dry-run (D0); the autonomous scheduler is wired but dormant; zero real receipts exist. Phases are sequential in dependency but the portfolio runs them as parallel streams wherever a stream is unblocked.

Chapter closeout

Decision ledger

Key Decisions

  • The roadmap is sequential by dependency but parallel by execution where unblocked.

Open Questions

  • When does Phase 1 produce the first operational receipt?

Related Chapters

  • Transformation Roadmap Figure
  • Ch. 5 - Runtime
  • Ch. 13 - Scorecard