Kernel capabilities implemented. End-to-end platform integration and qualification are progressing.Interactive demonstrationPlatform status
Explore the platformBecome a collaborator

Runtime and execution assurance

Reconciliation and Audit

A successful response is not proof of outcome.

Independent observation, expected-versus-observed reconciliation and linked evidence across the audit ledger.

Integrated4 lifecycle positionsNon-production evidence
Try the interactive demonstrationDiscuss an evaluation

Responsibility

What Reconciliation and Audit is responsible for

All products

This capability group establishes what actually happened. An observer records external state, reconciliation compares expected and observed results, and the certification and audit ledger links decision, execution and outcome evidence so conformance can be evaluated rather than asserted.

Executor responses are claims. Reconciliation treats them as such: it compares the required postcondition against observed state and records DIVERGED, UNKNOWN or CONFORMANT rather than inheriting the executor's opinion.

The audit ledger is the durable spine. Each component keeps an ordered, hash-linked chain, and conformance evaluation reads those records instead of trusting a status flag. What is not yet true is one signed envelope spanning every component — correlation is by identifier.

In depth

The problem, the boundary and the lifecycle role

Each section below is drawn from the product register and states the context this product is built for, in the product's own terms.

01

Three responsibilities in one evidence chain

Independent Observation records external state after an action. Reconciliation compares that state with the required postcondition. The Certification and Audit Ledger keeps the linked decision, execution and outcome records that make review possible.

  • Observer: captures observed state; the current implementation reads effects back through NARG.
  • Reconciliation: classifies the result as conformant, diverged or unknown.
  • Audit ledger: ordered, hash-linked records per component with lifecycle reconstruction.

Lifecycle position

Where it sits in the governance lifecycle

Stage numbering is canonical across the site. Open the interactive lifecycle to see every component with responsibilities at each stage.

Open the full lifecycle

  1. Independent observation

    Record what the external state actually is.

  2. Reconciliation

    Compare expected and observed results.

  3. Evidence and audit

    Keep linked, ordered, reviewable records.

  4. Conformance

    Evaluate outcomes against the original obligations.

Verified capabilities

What is verified today

Capabilities are drawn from the product register. Each one is bounded by the limitations stated further down this page.

  • Observation of external state after an action
  • Expected-versus-observed comparison with explicit divergence
  • Outcome classification: conformant, diverged, unknown
  • Hash-linked, ordered audit records per component
  • Evidence-driven conformance evaluation with ALIGNED/DRIFTED/UNKNOWN verdicts

Inputs

  • Expected postconditions from intent and contract
  • Observed external state
  • Decision, permit and execution records

Outputs

  • Reconciliation verdict
  • Conformance verdict (ALIGNED, DRIFTED, UNKNOWN)
  • Reconstruction artefact linking lifecycle records
  • Verifiable audit chains

Evidence and maturity

What the evidence supports

Maturity describes verified engineering evidence in a bounded environment. It is not a production-readiness statement.

Integrated

Maturity note

Reconciliation and hash-linked audit chains were verified in the local demonstration stack, including divergent-outcome detection. No single signed lifecycle artefact spans every component, and NARG's effect observation is performed by NARG rather than a third-party observer.

Not production-qualified

This label describes verified engineering evidence only. No production deployment, certification, benchmark or customer outcome is claimed.

Evidence recorded

  • Acceptance step 14: acknowledged dispatch plus mismatched observation produced DIVERGED; unobservable produced UNKNOWN.
  • Acceptance step 10: signed evidence record produced ALIGNED; unreachable bound produced DRIFTED; stale produced UNKNOWN; unsigned refused (422).
  • Acceptance step 12: both component chains verified and lifecycle reconstruction written.
  • Audit integrity cases passed with durable ordering and restart recovery.

Dependencies

  • Control Plane
  • Independent observer
  • Substrate
  • NARG
  • Chinje

Dependencies are stated as the product register records them. A dependency is not automatically production-qualified; see its own product or component page for its maturity and limitations.

Limitations

What this product does not do (yet).

Limitations are stated before the evaluation questions so they cannot be missed, downplayed or treated as future-work footnotes.

Limitations — read before evaluating
  • Independent observation is not third-party independent: observation reads the same local effect store, and NARG observes its own effect.
  • No single lifecycle artefact spans every component; chains correlate by decision/request id.
  • The audit ledger is tamper-evident per-component hash chaining, not WORM or externally anchored; no external anchor destination is configured.
  • No signed cross-component envelope and no third-party/auditor validation are claimed.

No capability on this page should be read as production qualification. If a limitation is material to your use case, it belongs in the evaluation scope — not after it.

Relationship to the platform

How it fits

See the full architecture

This is the evidence back-edge of the lifecycle. Intent and conformance meet here: the original obligations are re-read against verified outcomes, and the result is available to the people accountable for the system.

Evaluation questions

  1. What counts as observed state, and can it be produced without the executor's cooperation?
  2. How is an unknown outcome distinguished from a successful one?
  3. Can a reviewer reconstruct the whole transaction from records?

Related products

Continue through the lifecycle

Product portfolio
  • Decision and controlIntegrated

    Control Plane

    Policy evaluation, decision coordination, execution state and optimisation across the governance lifecycle.

    View Control Plane
  • Runtime and execution assuranceDemonstrable

    Substrate

    Controlled execution and resource adapters that apply an action and support independent read-back.

    View Substrate
  • Governance and formal assuranceIntegrated

    Chinje

    Intent governance, actor identity and authority, obligation tracking, evidence sufficiency, conformance and drift.

    View Chinje

Next step

Evaluate Reconciliation and Audit against a real control problem.

Bring a system boundary, an action class and a failure mode. The first step is to agree what should be governed and what evidence would count.

Run the interactive demonstrationDiscuss an evaluationDesign-partner programme