Back to console

Methodology

How AegisLedgerAI derives status and verifies evidence.

Last updated: 2026-09-23

AegisLedgerAI derives every visible metric, signal, result, proof, and control state from a typed record carrying data mode, source, observed time, freshness, coverage, connectivity, provenance, and evidence status. UI status is derived, never typed manually.

Truth Registry

Each signal record includes a data mode (synthetic, sample snapshot, demo unverified, ingested unverified, verified local, verified external), connectivity, freshness, control state, and evidence state. No state is named LIVE. The fail-closed priority ensures the most cautious state wins presentation.

Provenance and proof

The provenance ledger is append-only. Each ledger event includes event ID, previous-event hash, canonical event hash, owner and organization scope, correlation and causation IDs, policy version, safe summary, evidence IDs, and occurred and recorded times. Deterministic Merkle batches record an ordered leaf manifest, root, algorithm, and tree version. A hash proves byte equality; external finality requires a verified external receipt.

Synthetic data

Initial releases use synthetic, non-identifying fixtures that cannot be confused with a connected operational source. Synthetic fixtures render a persistent SYNTHETIC label in the page title region, metric cards, exports, and shared evidence views.

Bounded conclusions

The public proof verifier accepts a redacted proof package and returns VERIFIED, FAILED, or INCONCLUSIVE with reason codes. Verification never makes a legal or compliance conclusion. Revocation appends an event; it never rewrites history.