Every commit has a parent. In git, that parent is the previous commit. In CANONIC, that parent is a governance decision. Here is how the loop works.
The Problem With Autonomous Execution
Most software organizations operate on implicit authority. A developer sees a bug, writes a fix, pushes the commit. No one authorized it. No one reviewed the decision to fix it — only the implementation. The governance chain is: developer decided → developer executed → reviewer approved the code. The decision itself was never governed.
This works when there is one developer. It fails at scale. At scale, you get conflicting decisions, priority drift, and the gradual erosion of governance into whoever pushes first.
CANONIC eliminates this by requiring every execution to reference a prior governance event. No orphan commits.
The Causal Chain
The formal statement is Theorem 3 from the CANONIC DOCTRINE:
∀ DEV execution e, ∃ GOV event g such that:
e.work_ref = hash(g)
LEDGER(g).ts < LEDGER(e).ts
In plain language: for every developer execution, there must exist a prior governor event whose hash is referenced in the commit. The governance came first. The execution came second. The chain is causal, not correlative.
This means the LEDGER is not just an audit log. It is a dependency graph. Every commit points backward to the governance decision that authorized it. Every governance decision points forward to the commits that executed it. The graph is complete and traversable.
Five Event Types
Governors produce five types of events:
DIRECTIVE — “Do this.” The most common event. A governor issues an instruction. The developer executes it. The commit references the directive hash.
DEAL — “Approve this transaction.” The governor approves a deal. The developer formalizes it. COIN flows.
VETO — “Stop this.” The governor rejects. The developer reverts. The veto is immutable.
POLICY — “The rule is now this.” The governor sets policy. The developer formalizes it as a CANON.md constraint. The compiler validates it.
REVIEW — “What is the status?” The governor queries. No state change. INTEL answers.
Four of these mutate state and are ledgered. REVIEW is read-only — it consumes INTEL but produces no LEDGER record. This is deliberate. Asking a question should not leave a mark on the governance chain. Only decisions and actions are recorded.
The NOTIFIER Bridge
The loop requires that GOV events reach DEV. This is the NOTIFIER contract.
Every GOV CHAT scope declares a notify: header in its CANON.md:
notify: DEXTER
The compiler wires this into the CANON.json. The NOTIFIER service resolves the header to the DEV principal’s inbox. When a governance event is ledgered, NOTIFIER delivers it.
Discovery is automatic. magic scan walks notify: headers across the entire fleet. No routing table. No manual configuration. The governance contracts declare the routing. The compiler enforces it.
Why work_ref Matters
The work_ref field in the LEDGER record is the anchor. It connects the two halves of the loop:
- In a GOV event:
work_ref= the CHAT turn ID or contribution ID - In a DEV event:
work_ref= the hash of the GOV event that authorized it
This creates a bidirectional link. Given any commit, you can trace backward to the governance decision. Given any governance decision, you can trace forward to the commits that executed it. The graph is queryable, auditable, and tamper-evident (because LEDGER records are hash-chained).
For compliance, this is everything. An auditor does not need to interview developers about “why did you make this change?” The LEDGER answers the question mechanically. The work_ref is the answer.
The Loop in Practice
Today, the loop runs between Fatima (GOV) and Dexter (DEV):
- Fatima opens CHAT at
hadleylab.org/TALKS/FATIMA/ - She says: “We should file the MammoChat patent in the EU”
- CHAT confirms: “Understood. Directing EU patent filing for MammoChat. Ledgered. Dexter will execute.”
- LEDGER records:
{ type: DIRECTIVE, hash: abc123, work_ref: chat_turn_42 } - NOTIFIER delivers to Dexter’s inbox
- Dexter executes: files the patent governance, commits the documents
- Commit message:
GOV: MammoChat EU patent filing (directive: abc123) - LEDGER records:
{ type: GRADIENT, work_ref: abc123 } - Fatima asks in CHAT: “What happened with the MammoChat patent?”
- CHAT pulls from INTEL: “Filed. Commit xyz789. Governance score improved by 12.”
The loop closes. Every step is recorded. Every step references the step before it. The chain is unbroken.
Figures
| Context | Type | Data |
|---|---|---|
| post | flow-chain | nodes: DIRECTIVE → LEDGER → NOTIFY → EXECUTE → COMMIT → LEDGER → REVIEW |
| *The Loop | GOVERNANCE | BLOGS* |