Using Audit Pipelines

Overview

Procedural decisions are first-class artifacts. Every decision has a verifiable provenance chain.

This pack treats the decision — not the log line that mentions it — as the unit of evidence. A decision-log entry binds together inputs, the rule or policy version, the code version, the output, and a timestamp; entries are canonically encoded, fingerprinted, and chained so that tampering, replay, partial deletion, or time-shift becomes detectable. Exports carry their own integrity proofs so a downstream consumer can verify a subset without re-trusting the producer.

This is the evidence counterpart to security architecture's controls:

• ordis-security-architect answers what must be protected and how — threat models of the system, controls at trust boundaries, defense-in-depth design.
• axiom-audit-pipelines (this pack) answers what proves a decision happened, with what inputs, under which ruleset version and code version — and how that proof survives review, export, partial deletion, and adversarial scrutiny.
• The threat model OF the audit log itself lives in this pack (because the log is the evidence, and adversaries who reach the log are attacking the evidence). System-level threat modelling stays in ordis-security-architect. Cross-link the two; do not duplicate STRIDE tables.

When to Use

Use this pack when: