Audit Assurance Requirements

An Audit Assurance Profile (AAP) is a claim about deployed, healthy mechanics within a declared scope. It is not a customer-selected badge, a pricing tier, or a synonym for retention length.

AAP-0 · None

Claim: No audit assurance.

Use AAP-0 when canonical audit recording is disabled, unavailable, or cannot be verified. Ordinary application logs and analytics do not raise this profile.

AAP-1 · Recorded

Claim: Structured capture of delivered instrumented events.

Minimum mechanics:

• events conform to the versioned producer-event schema;
• delivery semantics are declared as best-effort, buffered, or required;
• the UI and API distinguish accepted, pending, failed, and unavailable states;
• instrumented lifecycle branches emit one started event and exactly one terminal event.

AAP-1 does not claim a durable, totally ordered, tamper-evident history.

AAP-2 · Chained

Claim: Ordered tamper-evident accepted history for a declared scope.

In addition to AAP-1:

• the journal is durable;
• append is atomic under concurrency;
• each entry commits its predecessor, epoch, sequence, event digest, evidence manifest, recorder, and integrity suite;
• the recorder returns a signed receipt that producers fully verify;
• retrying identical content is idempotent and divergent reuse of an event identity is rejected;
• epoch transitions prove and seal the predecessor epoch.

The profile applies only to accepted history. It does not by itself prove that every producer event was delivered.

AAP-3 · Transparent

Claim: Efficient inclusion, consistency, and declared source-gap evidence.

In addition to AAP-2:

• RFC 9162 checkpoints are created on a declared cadence;
• inclusion and consistency proof APIs are available;
• durable producer source sequence and predecessor linkage are maintained;
• producer high-water marks are reconciled with recorder state;
• gaps, stale checkpoints, and failed anchors are surfaced as explicit health states.

AAP-4 · Observed

Claim: Conflicting observed views are detectable relative to independently known checkpoints.

In addition to AAP-3:

• an observer operates in a separate trust boundary;
• the observer verifies and signs checkpoint observations;
• observation continuity is monitored;
• verifiers obtain observer trust from policy, not from the replay bundle being verified.

WORM, RFC 3161, or SCITT checkpoint anchors strengthen supporting evidence. They do not replace independent observation unless the deployment's declared trust model explicitly makes that external service the observer.

Profile computation

Compute the effective deployment profile from the minimum profile supported by every active audit source and the shared recorder path. Reusing a ledger must recompute this value from current sources; removing a lower-profile source must also recompute rather than preserving a stale downgrade.

Separate policy dimensions

Do not fold these independent questions into the AAP number:

• retention duration and legal holds;
• which event families are instrumented;
• which fields are placed in evidence;
• recovery point and recovery time objectives;
• authorized readers and export purposes;
• regulatory or contractual compliance.

Those belong in deployment policy and conformance evidence. A profile says what integrity and transparency mechanics are operating, not that every applicable law has been satisfied.