Criterion-Version and Decision Audit Log¶
Document — instantiates Resource Rationing
Links each rationing decision to the active criterion version, evidence, authority, reason, appeal outcome, and later correction without making sensitive data broadly visible.
When a claimant asks "why was I denied, and under what rule?", the answer has to be reconstructable months later by someone who was not in the room. The Criterion-Version and Decision Audit Log is the evidentiary backbone that makes that possible: an append-only record that binds every rationing decision to the exact criterion version in force at the time, along with the evidence, authority, reason, appeal outcome, and any later correction. Its defining property is version-linked immutability — decisions are never silently rewritten, corrections are appended rather than overwritten, and access is scoped so the log can prove what happened without broadcasting sensitive claimant data.
Example¶
A cloud platform is rationing scarce GPU-accelerator hours during a capacity crunch. Workloads are classed (essential inference services, then research training, then discretionary batch jobs), and each request is granted, throttled, or denied under a published allocation policy. The audit log stamps every decision with the policy version — v3.2 for the first week, v3.3 after the essential-service floor was raised — plus the requesting team, the reason code, and the human approver for exceptions. When the policy changes mid-crisis, older decisions remain bound to v3.2; they are not retroactively re-judged. Two weeks later an internal reviewer asks why one research team kept losing allocations. The log lets them replay it: the team's jobs were correctly classed discretionary under the version then in force, and the one reversal on appeal is appended, not swapped in. The reviewer reconstructs the governing rule for each decision without ever exposing another team's private workload data.
How it works¶
Its distinguishing discipline is provenance, not judgment:
- Version the charter. Every change to the criteria produces a new, dated version id.
- Bind each decision to a version. A grant, partial grant, wait, substitution, or denial carries the version that governed it, so drift and unpublished versions become detectable.
- Append, never overwrite. Corrections and appeal outcomes are new entries linked to the original; the history is complete and tamper-evident.
- Scope access and schedule deletion. Store the reason and authority while minimizing claimant data, and delete emergency-only fields on the sunset schedule.
Tuning parameters¶
- Record granularity — how much of each decision is captured. Fuller records support stronger audits but hold more sensitive data and cost more to maintain.
- Access scoping — who may read which fields. Tight scoping protects claimants; loose scoping speeds oversight but risks exposure.
- Retention schedule — how long emergency-only fields persist before deletion. Longer retention aids after-action review; shorter retention limits standing privacy risk.
- Version-change threshold — how large a criterion edit warrants a new version id. Fine versioning tracks drift precisely but multiplies bookkeeping.
- Immutability strength — from convention to cryptographic append-only. Stronger guarantees resist tampering but raise operational complexity.
When it helps, and when it misleads¶
Its strength is that it makes decisions explainable and correctable after the fact — the precondition for legitimate appeal, criterion-drift detection, and honest audit. The log is essentially an append-only record: entries are only ever added, never edited in place, so the sequence of what was decided under which rule is preserved intact.[n1] That property is what lets a claimant, an appeal panel, and an auditor all reconstruct the same history.
Its failure modes are quiet. A log can be technically complete yet over-collect sensitive data, becoming a privacy liability and, if retained past sunset, part of the emergency ratchet. It can also record decisions faithfully while the published criteria and the applied criteria diverge — the log will show the drift only if versions are actually bound to decisions. A classic misuse is treating the log as a compliance artifact nobody reads until litigation, so drift accumulates unexamined. The guarding discipline is version-binding on every decision, append-only corrections, scoped access, and scheduled deletion.
How it implements the components¶
claim_decision_and_reason_record— it is that record: each adverse or favorable outcome with decision time, responsible authority, reason, and appeal eligibility.ration_entitlement_and_priority_charter— it stores the versioned charter and links each decision to the version in force, so a later auditor can reconstruct the governing rule.
It does not convert denial patterns into procurement requests (supply_recovery_and_alternative_access_link, aggregated residual need distributional_impact_and_burden_monitor) — that is its document twin, Unmet-Need Supply Escalation Packet; this log proves which rule governed each past decision, while that packet demands future supply.
Related¶
- Instantiates: Resource Rationing — this log is the provenance record the whole regime's legitimacy rests on.
- Consumes: Scarcity Declaration and Activation Protocol supplies the initial criterion version the log binds decisions to.
- Sibling mechanisms: Unmet-Need Supply Escalation Packet · Claims Adjudication and Rapid Appeal Panel · Independent Rationing Equity Audit
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: Criterion-Version and Decision Audit Log operates as a durable record, ledger, register, or trace whose value depends on preserving actual state or history because it links each rationing decision to the active criterion version, evidence, authority, reason, appeal outcome, and later correction without making sensitive data broadly visible.
Independent corroboration: The frozen evidence defines Criterion-Version and Decision Audit Log as 'Links each rationing decision to the active criterion version, evidence, authority, reason, appeal outcome, and later correction without making sensitive data broadly visible', so its operative form is Record, Log & Register.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Law & Governance
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Administrative law cohered reviewable records tying consequential decisions to the rule in force; the exact artifact synthesizes audit trails, version control, and public rationing administration.
Related originating lineages:
- Accounting & Auditing — Audit trails supplied immutable evidence, authority, reasons, appeals, and correction history for later reconstruction.
- Computer Science & Software Engineering — Version control and append-only logging supplied exact criterion identifiers, tamper evidence, and linked corrections.
- Public Administration & Policy — Administrative rationing supplied reason codes, delegated authority, privacy constraints, and accountable appeal outcomes.
Review resolution: All four lineages are necessary to the version-linked, append-only, privacy-scoped decision record, and the mechanism transfers beyond one rationing domain.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] An append-only log records events by adding new entries and never modifying or deleting existing ones, so the full ordered history is preserved and tampering is detectable. Corrections are made by appending a new record that references the original, which is why the mechanism can show both the first decision and its later reversal. ↩