5. Runtime Architecture

Story moment

The night shift is the architecture

Events wake the system. Hermes claims bounded work. GBrain carries precedent. Receipts make the result inspectable in the morning.

Chapter 5

Executive Summary

What this chapter establishes

The runtime turns intent into evidenced action through the control plane, Hermes, and the trust substrate.

Operator ExperienceThe operator stops being the event bus and sees only judgment-grade interruptions.

Why this matters

Autonomy is not believable until work starts from events, acts through bounded authority, and leaves receipts.

Current Reality

Receipts, authority, and GBrain outbox are built; live execution is blocked; the spine is dry-run.

Target State

Events wake GLoops; Hermes acts; receipts flow back into surfaces and memory.

Migration Path

D1 through D4 build the dry-run spine before any reserved live mutation.

Concept trail

Capability API Operational Role Role Replacement Work Order Reference Realization

The runtime is how intent becomes a real, evidenced action — and how that evidence flows back into understanding and learning.

**Runtime: Control Plane, Execution Plane, Trust Substrate***What to notice:* Notice intent flows through the control plane to Hermes and always returns as evidence in the trust substrate.

5.1 The three planes

GLoops API / Control Plane — the boundary through which organizations consume capabilities. It supports capability discovery, capability invocation, Work Order ingestion, ExecutionRequest creation, evidence submission, receipt retrieval, Action Queue creation, capability/organization status, and event emission. It is not merely REST endpoints; it is the boundary through which organizations consume capabilities.
Hermes — the Execution Plane. Hermes is how GLoops acts. It claims execution requests, operates across repositories, invokes agents, runs commands, collects evidence, produces receipts, updates status, respects authority, and fails closed. Hermes is not a sidecar.
Evidence & Receipts — the trust substrate. Every governed action leaves addressable evidence and exactly one immutable receipt. This is what makes autonomy inspectable and therefore trustworthy.

A receipt is not a log line. It records what was asked, what authority permitted, what evidence grounded the decision, what actually happened, and whether the action was real or a dry run — so any reviewer can reconstruct the decision after the fact. The shape below is what one immutable receipt looks like:

{
  "receipt_id": "receipt://orch/2024-mr-0042",
  "capability": "merge-readiness",
  "actor": "hermes://runner/sdlc-orchestrator",
  "original_action": "merge pull request #318",
  "final_action": "hold merge — post readiness verdict only",
  "authority_rung": "4 · Promotion (dry-run authorized to act)",
  "evidence": [
    "knowledge://adr/0006-routine-operational-mutation",
    "knowledge://contract/autonomous-merge-contract",
    "receipt://ci/2024-pr318-checks"
  ],
  "decision": "not-ready",
  "decision_reason": "1 of 6 merge gates unproven (coverage gate has no receipt)",
  "outcome": "advisory verdict posted to PR; no mutation performed",
  "dry_run": true,
  "timestamp": "2024-05-14T03:21:07Z"
}

Representative receipt — illustrative schema, not customer data. This synthetic example shows the fields every receipt carries; it does not reflect any real organization or pull request.

5.2 The Authority Escalation Ladder

Authority is earned, scoped, revocable, and auditable — never assumed. It is implemented as six rungs; each needs a stronger actor, passes an added gate, and produces a durable record. No rung may be skipped.

At rung 5 (Mutation) a scoped delegated actor performs the change — never the human directly. Promotion (rung 4→5, first enablement of real action) and Trusted Lanes (automating human review for a proven capability) are high-stakes: first enablement always escalates to Zach (Ch. 9). Most real-world mutations, once a capability has earned the rung, are Routine Operational Mutations — delegated, not escalated (Ch. 9).

5.3 Event-driven operation

The organization should wake because something happened — not because a human prompted it. Events: Work Order state change · ExecutionRequest claimed/completed · receipt produced · PR opened/merged · CI failed · issue moved Ready · Action Queue decision made · capability/organization health changed. Timers are acceptable as bootstraps; events are the target.

Five lenses — The Runtime

Lens
▣ Current Reality	The Authority ladder, receipts, and GBrain outbox are built and well-tested. Live execution is not started / blocked (no GitHub App + secrets); all execution is forced `dry_run: true`. The dispatch spine (Steward → API → ExecutionRequest → Hermes → Receipts) is D0 file-backed dry-run; D1–D4 are authored Work Orders, build not started. The autonomous iteration scheduler is wired but flag-OFF/dormant — it removes zero burden until switched on in production.
◇ Target State	The system wakes on events, dispatches across repos via Hermes, produces real receipts, and continues without a human as trigger, dispatcher, or event bus.
→ Migration Path	D1 (API accepts/validates a Work Order, dry-run) → D2 (ExecutionRequest creation) → D3 (Hermes runner performs bounded Routine Operational Mutations) → D4 (receipts flow back, Steward proposes next) → (separate, reserved) first live mutation.
⚖ Executive Implication	The first live execution, the first Trusted Lane, and any authority widening are reserved to you. Everything below that ceiling runs without you.
☼ Operator Experience	You stop being the event bus and the dispatcher. Work starts because an event fired; you see it in the Action Queue only if it needs your judgment.

Chapter closeout

Decision ledger

Key Decisions

Hermes is the execution plane.
Events are the target; timers are bootstraps.

Open Questions

GitHub App/secrets and first production/customer-impacting execution remain reserved.

Related Chapters

Architecture Atlas
Ch. 9 - Governance & Authority
Ch. 14 - Phase 1