ART-515 · Allocation Decision Family

Build Allocation Decision Receipt

Re-derives whether an allocation produced by an optimizer is explained by the objective and inputs that were true when it was made: the eligibility schedule snapshot, the inventory snapshot offered, the haircut table version, and the objective you declare. Portable to any optimizer, including a liquidity sweep, a treasury cash placement, a payment routing choice, or an order allocation read exactly the same way a collateral pledge does.

Deterministic Re-derivation Your Inputs, Not Ours Not A Competing Optimizer
🔒 All inputs are processed locally in your browser. No data is transmitted. Do not enter real personal data — use synthetic or anonymised inputs only.
Distinct from two shipped surfaces
art-370-supervisory-scenario-replay replays the Fed's published macro supervisory scenario paths against your loss and PPNR functions: a replay of one caller function over an official, regulator-published SCENARIO. This kernel replays no external scenario at all: it re-derives whether ONE DECISION follows from the inputs that were true when it was made. art-236-build-ai-decision-log-record builds an EU AI Act Art 12(2) decision-log record: completeness score, retention window, chain position. It records metadata ABOUT a decision. It never re-derives whether the decision follows from a declared objective, computes no optimal allocation, and carries no reproducibility verdict.
Not a competing optimizer
This re-derives against a DECLARED objective over a DECLARED input set, using one fixed, published greedy rule per objective: the same rule every time, so the same inputs always re-derive the same candidate allocation. It never claims to find a better allocation than the one you chose, and a divergence from your allocation is not proof your allocation was wrong. It only tells you whether your allocation is explained by the objective and inputs you declared for it.
ADR_DIVERGENT is not a finding of error
A divergence means the chosen allocation is not explained by the declared objective and inputs over this kernel's re-derivation. That is routinely legitimate: a trader override, an undeclared constraint, a stale snapshot. No flag, field, or line of copy on this page characterises intent, negligence, or misconduct; the receipt reports the gap and the binding constraint, nothing more.
Why eligibility, inventory and haircuts are all inputs
The eligibility schedule, the inventory snapshot, the haircut applied to each item, and the objective itself are every one of them caller inputs, transcribed from the snapshot in force when the allocation was made. This kernel ships no eligibility table, no inventory feed, and no haircut table of its own, and performs no lookups of any kind (zero-egress, no network calls after load). Where those steps have already run, reuse them: 505-tokenized-collateral-eligibility-checker for eligibility and art-444-collateral-haircut-engine for the haircut applied. This page consumes their outcome as an input and edits neither.
Obligation & Snapshot References
Eligibility Schedule Snapshot
Inventory Snapshot Offered
Allocation Actually Chosen
Reproducibility Verdict
Cost Delta (Chosen − Optimal)
Binding Constraints
Exceptions
Re-derived optimal allocation vs. chosen allocation
AssetOptimal (re-derived)ChosenBinding Constraint
Exceptions: inputs insufficient to decide
FieldReason
Delta detail
Rationale
What was NOT proven
Compliance Flags
⚠ DECISION-SUPPORT DRAFT. A divergence is not a finding of error, and a match is not proof no better allocation exists. Not a competing optimizer.
OpenChainGraph v0.4 artifact · execution_hash: