policy_snapshot_id of the exact rules used. Replaying that decision re-runs those pinned rules — never the current policy — so the verdict is the same today as it was the day it was made.
Mental model: evaluation reads the current active policy. Replay reads the pinned snapshot. Changing a policy never changes what a past decision replays to.
Pinning builds directly on Policy Snapshots (the frozen rules) and Integrity & Hashing (the hash that proves the replay matched). Read those first if the snapshot or integrity-hash terms are unfamiliar.
The problem pinning solves
DENY and the original ALLOW would look unjustifiable. Pinning re-evaluates against the Day-1 snapshot, so replay returns ALLOW — and the integrity hash matches the original, proving nothing was altered.
How pinning works
When a decision is recorded, MeshQu captures three things on the receipt:policy_snapshot_id is the pin — a permanent reference to the immutable rules used. Because snapshots are content-addressed and never mutated, that pin always resolves to the same rules.
Replaying a decision
Replay is a single call:- Loads the original decision — including its
policy_snapshot_id. - Loads the pinned snapshot, not the current active policies.
- Re-evaluates the original context against the snapshot’s rules, at the original evaluation timestamp (so time-dependent rules behave identically).
- Recomputes the integrity hash and compares it to the original.
Two independent checks.
matches proves the verdict is reproducible from the pinned rules. signature_verification proves MeshQu signed the original receipt. Both should pass for a clean audit. They answer different questions — determinism vs. attestation.What pinning guarantees
Because the snapshot is immutable and replay freezes the evaluation time, replaying the same decision repeatedly yields the same integrity hash every time.
Evaluation vs. replay — which rules are used
The last form lets you name the snapshot a dry run is read against, by passing
options.snapshot_id and, optionally, options.evaluation_time. It is not a way to evaluate against historical rules, and it is not replay. The snapshot you name must pin, for every policy it contains, the version that is active and ratified right now. A draft, submitted or superseded pin is refused; so is a snapshot whose ratification status cannot be established, or one that names no policy versions at all. Only ratified versions may govern a decision, and that rule applies to a snapshot you name exactly as it applies to the active policy set.
To re-derive a decision that was already recorded, use
POST /v1/decisions/{id}/replay. Replay is deliberately not subject to this guard — its pin comes from the stored decision, and refusing it would make an already-signed receipt unverifiable through the API.result.dry_run: true and no signature fields. Naming a snapshot does not change that. See Evaluate vs record.
When replay does not match
A mismatch (matches: false) is a signal, not a routine outcome — it means the replayed verdict diverged from the recorded one, which should not happen for an untampered decision. MeshQu records the comparison in the audit trail so the divergence is itself evidence. Investigate it as potential data corruption or tampering rather than retrying.
Error responses
Replaying a recorded decision:
Naming a snapshot on
POST /v1/decisions/evaluate via options.snapshot_id:
A snapshot that does not exist is a
404; a snapshot that exists but is not ratified governance is a 400. The two are different answers to different questions, so do not treat every rejected pin as a bad request.See also
- Policy Snapshots — how the pinned rules are frozen and content-addressed.
- Integrity & Hashing — the integrity hash that
matchescompares. - Decision Assurance — what an offline verifier can prove about a replayed decision.
- Receipt Reference — the full replay response and receipt field reference.