Skip to content

Snapshot-Pinned Decision

Decision method — instantiates Use-Time Precondition Binding

Computes and records a decision against one frozen, versioned snapshot of the state, binding the action to the exact evidence it was based on.

Snapshot-Pinned Decision fixes the evidence rather than the resource. At check time it captures a consistent, versioned snapshot of the relevant state and makes the entire decision against that frozen view — then carries the snapshot's identity forward, so the action on record is explicitly "decided against version N." Its defining move is internal consistency plus provenance: every input to the decision comes from one coherent point-in-time view (no torn reads across a state that is shifting under it), and the version is retained so anyone can later see exactly what the decision saw. It neither locks others out nor re-queries at use; it accepts that the live world may have moved on and instead makes the decision reproducible and attributable to a known state.

Example

An underwriter approves a mortgage against a credit report and income snapshot pulled at 09:14 on the 3rd, reference CR-4471. The decision record does not say "approved because the applicant's credit was good"; it says "approved against snapshot CR-4471." If the applicant opens a new card that afternoon, the approval is neither silently invalid nor silently honored on stale data — it is a decision explicitly bound to a named version, and any re-underwrite is a fresh decision against a fresh snapshot. That pin is what makes the file auditable months later, and what turns "the data changed" from an ambiguity into a visible, decidable event. The same shape appears when a report or dashboard is generated against a single database snapshot, so that every figure on it reconciles to one instant rather than smearing across a moving system.

How it works

  • Freeze one coherent view. All inputs are read from a single consistent snapshot, so the decision can never be assembled from a mix of old and new state.
  • Stamp the version. The snapshot receives an identifier that travels with the decision, not just with the data.
  • Decide against the pin, not the live state. The computation references the frozen view; drift after the snapshot does not retroactively change what was decided.
  • Keep the pin as the record. The version becomes the audit anchor — what was true, as far as this decision could know.

Tuning parameters

  • Snapshot scope — how much state is frozen into one view; too little reintroduces torn reads, too much is expensive to capture and to retain.
  • Pin lifetime — how long a decision may ride an old snapshot before a refresh is forced; longer pins are cheaper but drift further from reality.
  • Staleness tolerance — how far the live state may move past the pin before the decision must be re-made rather than honored.
  • Retention — how long snapshots are kept for audit; longer retention buys traceability at a storage and, sometimes, a privacy cost.
  • Refresh trigger — a time-based re-pin versus a re-pin fired by a signal that the underlying state has moved materially.

When it helps, and when it misleads

Its strength is that it makes decisions consistent and auditable under change: no torn reads, and a durable record of exactly what evidence a decision rested on — decisive in regulated or contested settings where "what did you know when you decided?" is the whole question. It is also the standard database move: snapshot isolation lets a long computation see one stable view while the rest of the system writes around it.[1]

Its failure mode is that a pin is a photograph, and photographs go stale — the further the state has drifted since the snapshot, the more a "consistent" decision is consistently wrong. Snapshot isolation's own classic anomaly, write skew, is the sharp edge: two decisions each valid against their own snapshot can jointly break an invariant that spans them, because neither saw the other. And a tidy pin invites treating an old view as current simply because it is internally coherent. The classic misuse is pinning to dodge accountability — freezing a favorable snapshot and deciding against it after the world has plainly moved. The discipline is to bound how stale a pin may be, re-pin on material change, and never confuse consistent with current.

How it implements the components

  • state_version_or_freshness_token — the snapshot's version identifier; the token that names exactly which state the decision was made against.
  • use_time_state_evidence — the frozen snapshot is the evidence of record the action rests on and can be checked back against.
  • check_use_audit_trace — pinning the version into the decision permanently links check to use ("decided against N"), giving the audit anchor.

It does not run a conflict_abort_and_retry_policy at commit (that's Two-Phase Commit with Freshness Check) or take a reservation_or_hold_record to stop the state moving at all (that's Lock or Hold Until Use); a pin records and reconciles against a version, it does not prevent drift.

Notes

A snapshot pin makes staleness visible and attributable but does not, on its own, act on it. It is frequently the substrate the detection mechanisms sit on: a freshness check compares the live version against a pinned one. Alone it answers "what did we decide against?" — pair it with a use-time re-check (as in Two-Phase Commit with Freshness Check) to answer "should we still act?"

References

[1] Snapshot isolation lets a transaction read from a consistent snapshot taken at its start, so it sees one stable version of the data while others write. Its characteristic anomaly is write skew: two transactions, each valid against its own snapshot, together violate an invariant neither could observe. It is the standard cautionary tale that a decision can be perfectly consistent and still stale. ↩