Allocation Evidence Guide ยท OpenChainGraph v0.4

An Optimizer Chose This Allocation. Can You Show Why, Six Months Later?

For operations and internal-audit leads who inherit an allocation decision after the fact: a settlement pledge, a treasury cash placement, a payment routing choice, a liquidity sweep, an order fill. The question that matters is not whether this allocation was the best one; it is whether the allocation that was actually chosen follows from the inputs that were true when it was chosen. This is a reproducibility question, and art-515, the allocation decision receipt, answers it directly by re-deriving the allocation from the declared inputs and reporting whether the two agree.

Reproducibility check, not a suspicion check Any optimizer, not one asset class Not a competing optimizer Zero PII · client-side only
๐Ÿ”’ All inputs are processed locally in your browser. No data is transmitted. Do not enter real personal data โ€” use synthetic or anonymised inputs only.

Why "reproducibility," not "suspicion"

An allocation record that only states the outcome (this asset, to this obligation, at this haircut) gives an auditor nothing to check it against. An allocation record built to be re-derived gives the auditor a re-run.

Six months after an allocation runs, the person reviewing it was not in the room. They were not the trader, the optimizer, or the desk that ran it. What they have is a record. The reproducibility question asks: given the eligibility schedule, the inventory that was on offer, the haircut table version in force, and the objective that was declared at the time, does re-running the declared objective over those declared inputs land on the allocation that was actually chosen? If yes, the allocation is explained. If no, the record should say so plainly, name the input or constraint that explains the gap, and stop there; it should never speculate about why a human or system diverged from the optimum.

The four generic inputs, and why they are not collateral-specific

art-515 takes the same four inputs regardless of what is being allocated. None of the four is written against a collateral data model.
InputWhat it isCollateral instanceNon-collateral instance
Eligibility scheduleThe set of candidates permitted to satisfy the obligation, as of the snapshot in forceWhich assets are eligible to be pledged against this obligation, per the schedule in force that dayWhich accounts are permitted to fund a payment corridor, per the routing policy in force that day
Inventory snapshotWhat was actually on offer at the time, with its per-candidate cost or weightThe pool of pledgeable assets, each with a cost and an HQLA/haircut weightThe pool of liquidity positions available for a treasury sweep, each with a cost of funds
Objective declaredThe stated goal the allocation was optimizing forcheapest_to_deliver, preserve_hqla, minimise_movementsA caller-named objective such as fastest settlement corridor or minimum counterparty concentration
Allocation chosenWhat was actually decided, to be checked against the other threeWhich specific assets, in which amounts, were pledgedWhich specific account funded which specific leg of the payment
If the input shape only worked for collateral, the receipt would be a point solution for one desk. Because eligibility, inventory, objective and chosen allocation are generic, the same kernel re-derives a treasury liquidity sweep or a payment routing decision exactly the way it re-derives a collateral pledge: same fields, same verdict logic, no per-asset-class branch.

art-515: what it answers

art-515 · Allocation Decision Family
Build Allocation Decision Receipt
Question it answers: does the allocation actually chosen follow from the declared objective, over the eligibility schedule and inventory snapshot in force, at the haircut table version declared? Outputs a reproducibility verdict, the cost delta between the chosen and the re-derived allocation, and the binding constraint behind any gap.
build_allocation_decision_receipt

The re-derivation runs one fixed, published rule per declared objective: the same rule every time, so identical inputs always re-derive an identical candidate allocation. It does not search for a better allocation than the one it is checking, and it does not claim the chosen allocation was wrong when the two diverge. It reports whether the declared objective and declared inputs explain the choice, and if they do not, which constraint is binding.

The worked example: a collateral pledge, end to end

art-515 works for any optimizer. This chain instantiates one case, a collateral pledge, to show the three steps composed: eligibility, then haircut, then the allocation re-derivation.
Step 1 · eligibility 505-tokenized-collateral-eligibility-checker: which candidates are eligible against the obligation, per the schedule snapshot Step 2 · haircut art-444-collateral-haircut-engine: the haircut applied to each eligible candidate, per the haircut table version Step 3 · re-derivation art-515-build-allocation-decision-receipt: re-derives the chosen allocation against the declared objective, over the outputs of steps 1-2. Reproducibility verdict, delta, and binding constraint are the chain's terminal output.

art-515 ships no eligibility table and no haircut table of its own, and performs no lookups of any kind after the page loads. It consumes the eligibility and haircut steps' outcomes as inputs and edits neither. See the allocation-decision-receipt chain page for the full composed run.

What a divergence does, and does not, mean

What divergence does not mean

ADR_DIVERGENT is not a finding of error, negligence, or misconduct. A divergence means the chosen allocation is not explained by the declared objective and inputs, as re-derived by this kernel, and nothing more. Routinely legitimate causes include a trader override for a reason outside the declared objective, an undeclared constraint the record did not capture, or a stale snapshot that no longer matched the market at execution. No flag name, no field, and no line of copy on the art-515 page characterises intent.

What divergence does mean

The record reports the gap and the binding constraint. The reviewer gets three things: a reproducibility verdict (ADR_REPRODUCED or ADR_DIVERGENT), the cost delta between the chosen allocation and the re-derived one, and the specific input or constraint that explains the difference. That is the entire claim. What the reviewer does with a divergence, whether that is asking the desk, checking for an override memo, or escalating, is a downstream judgment the receipt does not make for them.
Two related flags carry distinct meanings. ADR_INPUTS_INSUFFICIENT fires when the declared inputs cannot decide the question at all (for example, no eligible inventory covers the obligation), which is different from ADR_DIVERGENT, which fires when the inputs are sufficient but the chosen allocation still does not match the re-derivation. ADR_OBJECTIVE_UNDECLARED fires when no objective was named for the run; a caller-named objective outside the three built-in labels is accepted and used as declared. ADR_CONSTRAINT_BINDING names the specific constraint that explains a divergence.

Not a competing optimizer

art-515 re-derives against a declared objective over a declared input set. It does not search the solution space for the cheapest possible allocation across every objective, it does not claim to find a better allocation than the one the caller chose, and a divergence is not proof the caller's allocation was wrong. Its only claim is whether the chosen allocation is explained by the objective and inputs declared for it.

art-515: art-515-build-allocation-decision-receipt.html, the allocation decision receipt kernel and page.
Worked chain: chains/allocation-decision-receipt.html, eligibility → haircut → allocation re-derivation, composed.
OpenChainGraph v0.4 · Suite · Education hub · Spec v0.4 · Zero PII · CC BY 4.0