4. The Canonical Hierarchy
Executive Summary
What this chapter establishes
The canonical hierarchy connects organizations, roles, capabilities, execution, receipts, and learning.
Everything in the company derives from one hierarchy. It unifies the decomposition spine (how a human role becomes capabilities) with the execution spine (how a capability becomes a real, evidenced outcome). Read it top-to-bottom as “what we’re replacing”; read it bottom-up as “how the work actually happens and proves itself.”
| Level | One-line definition | Owner | Canonical home |
|---|---|---|---|
| Organization | The entity being made autonomous (an executive projection in Ralph) | Ralph | GLOSSARY.md |
| Operational Role | A recurring bundle of responsibilities that depends on a human and may become governed capability | Portfolio Steward | ADR 0013 |
| Responsibility | One recurring duty within a role; the thing a capability maps to | Portfolio Steward | BURDEN_REDUCTION_STRATEGY.md |
| Operational Capability | A durable ability defined by intent + contract; the unit a consumer asks for | GLoops | GLOSSARY.md |
| Realization | The swappable implementation of a capability (loop + reasoning + adapter + runner) | GLoops | GLOOPS_ARCHITECTURE.md |
| Loop | A versioned Observe → Reason → Act → Verify cycle — a primitive, not the public abstraction | GLoops | GLOSSARY.md |
| ExecutionRequest | The durable unit of work for executing one Approved action | GLoops | GLOSSARY.md |
| Evidence | Addressable, inspectable proof influencing or resulting from an action | GLoops | GLOSSARY.md |
| Receipt | The immutable record of one decision — the trust substrate | GLoops | GLOSSARY.md |
| Learning | Constraints + grounded knowledge + rising readiness distilled from receipts | GLoops | GLOSSARY.md |
Two cross-cutting parents complete the picture: an Outcome (a durable, measurable goal) parents a Capability — capabilities are the means, the Outcome is the end they are ranked against; a Work Order (the governed expression of delegated intent) invokes a Capability and decomposes into ExecutionRequests. The full planning chain is Outcome → Capability → Work Order → Execution → Receipt → (back to the Outcome’s measured reading).
Why the loop is demoted. In current GLoops code the loop is the de-facto top-level object (a capability ≈ a loop, 1:1). This architecture demotes the loop to a primitive and promotes the Capability to the public abstraction. Capabilities are durable; realizations and loops are swappable. (▣ Current Reality: Capability/Realization as first-class objects is
not started; the 1:1 collapse is the current reality this hierarchy converges away from.)
4.1 Capability cards
Section titled “4.1 Capability cards”A Capability Card is the standard, scannable description of a capability. Every capability in the Capability Portfolio (Ch. 11) renders as one.
Capability Card — Issue Clarification (illustrative; live grade in
CURRENT_STATE.md)
- Role responsibility replaced: SDLC Orchestrator → “determine whether a Ready issue is truly clear; ask product-friendly clarifying questions.”
- Contract: observes Ready issues; may propose clarifying questions; requires propose-only authority (rung 2); verified by accepted/edited/rejected question signal.
- Reference Realization: Induct’s front-door durable-clarification step.
- Grade: built (dry-run only). · Autonomy rung: Proposal (2 of 6).
- Evidence / Receipts: dry-run proposals; zero real receipts yet.
- Consumed by: none in production yet (Induct is the first intended consumer).
- Next improvement: real intake → Action Queue approval → GitHub comment posting → learn from edits.
- Burden removed when: Zach no longer reads every Ready issue to judge clarity.
4.2 Families of capability
Section titled “4.2 Families of capability”Capabilities cluster into families, each aimed at a job the organization needs done.
| Family | Purpose | Representative capabilities |
|---|---|---|
| SDLC | Replace the SDLC Orchestrator | Issue Discovery → Understanding → Clarification → Build Planning → Implementation → Verification → Adversarial Review → PR Review → Merge Readiness → Delivery Readiness → Receipts → Learning |
| Runtime | Make GLoops actually operate | ExecutionRequest lifecycle · Hermes dispatch · event substrate · scheduling · work claiming · receipt generation · capability health · dependency resolution |
| Human Interface | Ensure humans interact through products, not prompts | Action Queue · Capability Portfolio · Organization Portfolio · Portfolio Health · Executive Updates · Decision Briefs · Ralph room · notifications |
| Knowledge | Replace human memory and context-carrying | GBrain · ingestion · synthesis · cross-linking · contradiction detection · decision memory · context assembly · precedent retrieval |
Chapter closeout
Decision ledger
Key Decisions
- Loop is an implementation primitive, not the public product abstraction.
Open Questions
- When does the first first-class Capability/Realization object ship?
Related Chapters
- Capability Cards
- Concept Map - Operational Capability
- Ch. 11 - Product Surfaces