AUDITABILITY

1. Scope

KYA-OS auditability produces cryptographic evidence for audit, incident response, and control workflows. It does not make an application compliant, prove that an uninstrumented action never happened, or make a self-hosted log independently trustworthy merely because it contains hashes.

Detached tool proofs remain origin evidence. Audit entries compose those proofs with authorization collateral, outcomes, ordering, and lifecycle events into a history that can be reconstructed and checked offline.

2. Evidence Pipeline

origin proof
    ↓
producer event          typed, privacy-minimal, stable event identity
    ↓
authoritative recorder  assigns epoch, time, sequence, and predecessor
    ↓
signed entry + receipt  proves acceptance at a specific ledger position
    ↓
Merkle checkpoint       commits an efficient, verifiable range
    ↓
observer / anchor       independent view monitoring / supporting evidence
    ↓
signed replay bundle    portable inventory verified against external policy

These attestations are deliberately separate. A producer reports what it observed. Exactly one recorder authority orders accepted events for each ledger epoch. An independent observer compares and retains checkpoint views. A WORM, RFC 3161, or SCITT receipt can add durability, registration, or time evidence, but is not by itself an independent split-view detector.

3. Recorder Authority and Topology

Exactly one logical authority assigns sequence and signs receipts for a (ledgerId, ledgerEpochId) pair. A producer never supplies authoritative time, sequence, predecessor, epoch, or signature.

MANAGED
MCP server → authenticated producer event → Checkpoint recorder
Checkpoint = authoritative recorder + query projections

SELF-HOSTED
MCP server → tenant-owned transactional recorder → Checkpoint mirror
Tenant recorder = authority; Checkpoint verifies exact envelopes and never resequences

Failover, authority-key rotation, retention rollover, and partition changes create a new epoch with a signed transition. The successor genesis commits the prior epoch and terminal checkpoint. A mirror never resigns an entry or silently promotes itself to recorder.

4. Delivery Modes

best-effort  append attempted; response does not wait       AAP-1 maximum
buffered     durable producer outbox acknowledged           pending until reconciled
required     authoritative signed receipt obtained          AAP-2+ eligible

Delivery is at least once with stable event identity and recorder idempotency. The same event ID and bytes return the original receipt; the same event ID with different bytes is an integrity error. Buffered events are not described as chained until receipt reconciliation succeeds.

For side-effecting tools, deployments record an intent before execution when their profile requires it, use a stable idempotency key, then record completion or failure. A failed terminal append after an external side effect is exposed as degraded and reconciled; the system does not claim exactly-once execution across unrelated external services.

5. Privacy and Evidence

The integrity ledger contains bounded metadata, coarse action and outcome categories, pseudonymous references, digests, evidence references, signatures, and checkpoints. It excludes raw arguments, response bodies, prompts, access tokens, exception text, direct session IDs, and exact sensitive tool names by default.

public_did        intentionally public correlation
pairwise_did      relationship-specific identity
keyed_commitment  tenant-keyed indexing for sensitive identifiers
evidence_ref      encrypted object in a separately authorized vault

Exact payloads belong in a randomized, encrypted evidence vault under an explicit access, purpose, retention, and legal-hold policy. The ledger commits only bounded reference metadata. Disposal removes ciphertext, not the historical commitment, and is represented by a later administration event rather than mutation of an old entry.

6. Checkpoints, Observation, and Anchors

RFC 9162-style Merkle checkpoints commit stable journal ranges and support inclusion and consistency proofs. Checkpoint lifecycle events are appended only after a checkpoint is signed, preventing recursive self-inclusion.

observer  validates, retains, chains, and compares checkpoint views
anchor    supplies narrower time, registration, or durability evidence

observer + consistency proofs  → detects known rollback or conflicting views
anchor alone                   → does not prove non-equivocation

7. Replay and Offline Verification

Protocol replay means deterministic reconstruction and verification of an observed timeline. A signed manifest commits the selected ledgers and ranges, every included component, every explicit redaction or unavailable item, the export purpose, and the digest of the verification policy.

inventory              every declared component is present or explicitly omitted
cryptographic          schemas, canonical hashes, and signatures verify
ledger                 epoch, sequence, predecessor, receipt, and genesis verify
transparency           checkpoints and inclusion/consistency proofs verify
external observation   observer and supporting-anchor evidence verifies
historical context     authorization as observed is separate from current status

Trust is supplied outside the bundle. Bundle-provided keys, DID documents, status lists, genesis entries, or checkpoints cannot authorize themselves. Missing collateral is indeterminate, never silently valid.

Re-executing a model or tool is a separate opt-in sandbox feature. It defaults to dry-run, declares nondeterministic inputs, and requires explicit authorization before any side effect.

Verified reconstruction  default; no code, network, or secret resolution
Decision simulation      deterministic policy replay with side effects replaced
Active tool rerun         restricted sandbox, declared replay contract, fresh authorization

8. Assurance Profiles

AAP-0  NONE         audit disabled
AAP-1  RECORDED     typed capture of delivered, instrumented events
AAP-2  CHAINED      durable atomic ordering + idempotent signed receipts
AAP-3  TRANSPARENT  source high-water evidence + Merkle checkpoints and proofs
AAP-4  OBSERVED     independent checkpoint monitoring + supporting receipt

Audit assurance is orthogonal to identity and delegation conformance. Capability discovery declares the profile, recorder topology and epoch, delivery and durability mode, coverage scope, checkpoint and observer policy, evidence retention, integrity suite, and trust-policy identifier. Implementations fail startup when their mechanics cannot support the advertised profile.

9. Honest Verification States

A single “verified” badge is insufficient. Consumers report each dimension independently:

cryptographic integrity    valid | invalid | indeterminate
chain integrity            valid | invalid | indeterminate
checkpoint integrity       valid | invalid | indeterminate
observation / anchor        valid | invalid | indeterminate
scope completeness         valid | invalid | indeterminate
authorization as observed  valid | invalid | indeterminate
current authorization      valid | invalid | indeterminate

A credential can have been valid when observed and be revoked now. Completeness is always limited to the signed bundle selection, declared instrumentation coverage, and evidence-retention policy.

10. MCP Integration

MCP lifecycle instrumentation emits session, tool, proof, authorization, delegation, key/configuration, and administrative events through the same audit trail. The server can return a compact append-receipt reference in MCP _meta; full Merkle proofs remain asynchronous. See the MCP binding for the enforcement flow.

The normative wire objects are published as versioned JSON Schemas. The implementation, verifier, provider contracts, and conformance vectors live in the donated @kya-os/mcp repository.