Unclassified
22 · Execution Closure
The system is not finished when an API returns success. Intent → Plan → Govern → Execute → Re-ingest → Verify → Reconcile → Spine → Rehydrate — the critical differentiator.
Not Finished When the API Returns Success
Intent
↓
Plan
↓
Govern (may it be done? → approval → authorization)
↓
Execute (Hermes → external system)
↓
External Outcome
↓
Re-ingest (Loader → Normalizer)
↓
Verify (expected vs observed)
↓
Reconcile (resolve mismatch, decide what becomes truth)
↓
Update Spine (governed write)
↓
Invalidate / Refresh Projection
↓
Rehydrate (Human Workbench + AI Workbench)
↓
Continue Work / Next Work
Provider success is not completion. A 200 from Salesforce is an observed outcome, not truth. The loop closes only after the outcome is re-ingested, verified, reconciled, and the Spine has been updated under governance.
Why This Matters
- SaaS APIs lie, race, and partially succeed.
- Work state diverges from reality if you trust the response body.
- Audit collapses if you cannot reconstruct expected vs observed and what was eventually promoted to truth.
Verified Closure Checklist
- Outcome was re-ingested via the pipeline (provenance captured).
- Verification judged expected vs observed.
- Reconciliation resolved mismatch and chose the Spine update.
- Governed Writer updated the Business Context Spine.
- Projection invalidated; both workbenches rehydrated.
- Full chain is reconstructable via trace, approval, capability, execution, evidence, and reconciliation lineage.
See Verification & Reconciliation for the stage detail and Spine Architecture for what becomes THE memory.
Where to Go Next
<CardGroup cols={2}>Expected vs observed, evidence, mismatch, promotion, invalidation.
The Work-centric view of this closure flow.
Where Hermes sits in the end-to-end runtime.