Home · Platform · Assurance levels
Trust · Assurance

Four levels of evidence. Pick the one that matches the stakes.

Not every AI event needs a courtroom-grade proof, and not every proof is strong enough for a dispute. AskLedger describes assurance as a clear progression, from data that's simply declared, up to a signed checkpoint anchored in an independent log. Each level is honest about what it means, so you can choose deliberately rather than overclaim.

The ladder

From declared to independently anchored.

Each rung adds a stronger binding between the record and reality: a known signer, then a verified workload identity, then an external anchor. Higher isn't automatically better; it's a match to how much a given event might one day be challenged. AskLedger supports all four.

L0

Declared · data supplied without cryptographic identity

The record is captured, but nothing cryptographically binds it to a signer. It's an honest starting point: useful, but it rests on trust in the source rather than math.

Use whenEarly discovery and imported legacy records, where you're mapping activity before instrumentation exists.
L1

Signed · a known application signs the event

A known application signs each event, so you can verify the signer and that the record hasn't changed. This is standard, dependable application accountability.

Use whenStandard application accountability. Most instrumented production apps live here.
L2

Attested · signer bound to a verified workload identity or hardware key

The signer is bound to a verified workload identity or a hardware-backed key (HSM / KMS), so the signature can't be quietly reused or impersonated. The binding itself is much harder to forge.

Use whenRegulated production systems and agents, where the identity behind a signature must be provable.
L3

Anchored · signed checkpoint externally timestamped or logged

A signed checkpoint is externally timestamped or written to an independent log, whether a transparency log or an RFC 3161 timestamp, so even AskLedger can't retroactively rewrite history without detection.

Use whenHigh-dispute, legal, or cross-organization evidence, where a third party must trust the record without trusting us.
Stay honest about it

Even at the top rung, know what a receipt proves, and what it doesn't.

Assurance level tells you how strongly a record is bound to its signer and to time. It doesn't make a record's contents true. Reading this table alongside the ladder is how you avoid overclaiming to an auditor.

A receipt proves
  • A known signer recorded specific fields, and the record has not changed since.
  • The relationship among linked events and checkpoints.
  • Which policies were evaluated, and what decision was recorded.
  • That an exported package matches the stored evidence.
A receipt does not prove
  • That every field supplied by a model provider was factually true.
  • That all activity was captured if users bypass instrumentation.
  • That the policy itself was adequate or legally compliant.
  • That correlation equals causal business impact.
Choosing a level

Match the level to the stakes. The verifier reports which one you met.

Discovery and legacy imports can sit at L0. Everyday application accountability wants L1. Regulated systems and agents call for L2. High-dispute, legal or cross-organization evidence earns L3. You don't have to guess: the open verifier reports which assurance level a given receipt actually meets. AskLedger is built to span all four: L0 and L1 with the open SDK today, and L2 to L3 as you harden the deployment with HSM/KMS signing and transparency-log or RFC 3161 anchoring. The level describes how strong the evidence is: what was signed, timestamped and chained. It is not a statement about what a third party has agreed to accept. This ladder is ours, no auditor or regulator has adopted it, and whether a given level is enough for a given obligation is their call. That is why the level feeds Layer 5, the governance, compliance and ROI program that tracks how your evidence lands across your systems.