Canonadr

ADR-2026-09-04-11 — Execution closes only through re-ingestion, verification and reconciliation

Status: ACCEPTED — 2026-09-04 (Founder Canon §21; Book of Record closure rule)

Context

Provider 200 OKs, tool success flags and agent completion messages are observed outputs, not
verified business outcomes. Treating them as completion leaves the organization reasoning from
unverified state — the quiet version of the stale-copy failure.

Decision

  • A provider result is an Outcome Event, never automatically verified business truth.
  • The canonical closure chain is frozen:
Intent → Proposal/Command → Governance Decision → Authorized Execution Plan → Hermes Execution
→ Provider Outcome → Outcome Event → Re-ingestion → Verification → Expected-vs-Actual
→ Reconciliation → Governed Canonical Commit → Projection Invalidation
→ Human + AI Workbench Rehydration → Next Work
  • Every continuity run retains traceability: trace_id, correlation_id, causation_id, event_id, approval_id, capability_run_id, execution_id, idempotency_key, verification_id, reconciliation_id, continuity_run_id.
  • Writes remain incomplete until the external outcome is observed, re-ingested, reconciled and
    reflected in a refreshed projection with evidence.
  • Host-native execution outcomes enter the same closure path as IntegrateWise-native outcomes —
    one reconciliation substrate across routes.

Alternatives considered

  • Trust the provider receipt as completion (optimize latency) — rejected: the platform's defining
    property is that humans and AI continue from verified state, not from a success message.
  • Reconcile lazily/asynchronously only — rejected: reconciliation state must be explicit and
    queryable; lazy reconciliation is how silent divergence begins.

Consequences

Verification and reconciliation are first-class schemas and services, not logging conventions
(register G-20/G-23). A capability is "available" only when its reconciliation behavior is
declared.