Deterministic replayability

Context

An auditor reviewing a compliance determination years after it was made cannot trust an outcome that depends on the current state of anything. The rule set evolves. Reference data evolves. Clock-bound logic introduces non-determinism. If the same inputs at different times produce different outcomes, the audit posture is invalidated and the platform cannot defend a historical determination. This is the failure mode that loses fair hearings.

Decision

Every determination stores its inputs, the rule version that evaluated those inputs, and any deterministic seed required for reproducibility. The same inputs against the same rule version produce the same outcome at any point in the future. There is no clock-bound randomness, no “current best estimate” logic, and no stale model output in the determination engine. Rule versions are first-class entities; every determination row links to the rule-version row that produced it.

Consequences

An auditor in 2030 can replay a 2026 determination and arrive at the same outcome. Rule changes require a new rule version and a clean cutover; old determinations stay associated with the old rule version. Operational cost: storing inputs verbatim (the platform cannot rely on reconstruction from state). The determination engine is a pure function of (inputs, rule version), and that purity is enforced at the type level via ADR-004’s view/mutation separation.

Alternatives considered

• Store outcome only, recompute inputs from current state. Rejected: state evolves. Recomputed inputs in 2030 may not match the inputs as they existed in 2026.
• Store outcome plus a digest hash of inputs, not the full inputs. Rejected: cannot replay if rule version changes. Digest tells you whether something matches; doesn’t let you re-run the rule against the original inputs.