using-audit-pipelines
Audit pipelines
Produce a decision-evidence contract that a separate verifier can check. Preserve the difference between an operational event, a recorded decision, and proof of that decision.
Work from the affected contract
- Identify the decision types, producers, consumers, adversaries and evidence obligation. Reuse the existing schema and storage when repairing one failure.
- Bind inputs, ruleset/policy version, code identity and output. Specify the canonical bytes and version boundary before choosing hashes or signatures.
- Choose chain/export construction, key custody, rotation and recovery against the threat model. State residual risks and independent verification steps.
- Reconcile content retention/redaction with integrity witnesses and legal requirements verified for the deployment. State what the trail cannot reconstruct.
- Exercise canonicalization vectors, alteration/deletion, key rotation, restore and bounded export cases applicable to the change. Record results and omissions.
Scope and completion
A local repair needs the affected contract, evidence and checks. For a new audit system, use the scope tiers in decision-log-architecture.md and consistency checks in the references; create numbered artifacts only when their consumers need them. A signed chain proves integrity under stated custody assumptions, not that recorded inputs were truthful.
Use the user’s existing intent and authorization. Ask only for missing information that materially changes the result; use additional reviewers when they address a concrete uncertainty. Treat unavailable checks as gaps rather than successful verification.