Skip to main content
Snapshot pinning is the mechanism that makes a recorded decision reproducible. When MeshQu records a decision, it stores the 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

If replay used the current policy, it would return 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:
The 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:
Internally, replay:
  1. Loads the original decision — including its policy_snapshot_id.
  2. Loads the pinned snapshot, not the current active policies.
  3. Re-evaluates the original context against the snapshot’s rules, at the original evaluation timestamp (so time-dependent rules behave identically).
  4. Recomputes the integrity hash and compares it to the original.
The response contrasts original and replay and tells you whether they match:
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 re-evaluate an arbitrary context against a known snapshot (for example, to test how a new context would have fared under historical rules) by passing options.snapshot_id and, optionally, options.evaluation_time.

​
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

Replay reproduces a verdict; it does not undo anything. A replayed DENY does not block, and a replayed ALLOW does not execute. MeshQu is advisory — replay is an audit operation, not an enforcement one.

​
See also