Which Strategy Version Authorized This Trade?

An owner reduces maximum position value while a trading agent is preparing an order. The finished action may reflect the old size limit and the new strategy text. Each source was authentic at some time, yet their combination can describe a mandate the owner never approved.

We use version attribution to make that race inspectable. Our mandate compiler article specifies a stable identity for the resolved instruction set and connects it to policy and the final action.

A mixed contract can look plausible

In this illustrative sequence, version 18 allows a $2,000 position and requires a breakout. At 09:01 the agent begins a turn. At 09:02 the owner publishes version 19, lowering the limit to $800 and changing the entry condition to a pullback. At 09:03 the model proposes a $1,500 pullback trade.

The action obeys neither complete version. Its size fits version 18 and its condition fits version 19. A log that stores only “latest strategy” after the fact would conceal the mixture. The needed record is the full version bound to the rendered input, plus the version policy used for the submitted payload.

There are at least two coherent runtime policies. A turn can retain its original version when continuing authority allows that behavior. Alternatively, the update can invalidate unfinished proposals and require a fresh turn. Immediate revocations deserve a defined interruption path in either design. The choice should be explicit and visible to the user.

Reproduction needs the compiler too

Two identical strategy documents can render differently after a prompt-template change. Mandate version alone therefore cannot identify everything the model saw. Preserve the source instruction version, compiler version and rendered input or its recoverable identity.

The operating-layer controls paper companion reports historical prompt-placement and rule-fabrication interventions. Those results show that rendering and memory treatment can change behavior under fixed source facts. They justify recording the compiler alongside the owner mandate, with each change attributable to its own component.

A hash can detect whether a stored object changed. It cannot establish that the object was authorized or that a submitted payload obeyed it. Pair content identity with owner authentication, effective time and policy receipts. These fields answer different questions and should survive retries together.

The race fixture

We would replay one saved proposal while injecting a version change before inference, after inference and immediately before submission. Under the selected policy, every submitted action must map to one complete authorized version. Canceled proposals retain a reason, making cancellation distinguishable from a model choosing to wait.

A second test rebuilds the venue payload after a retry. It checks that quantity conversion and asset normalization preserve the same authority binding. A stable proposal identifier alone leaves the final request unresolved.

DXAP describes a recorded model-to-policy-to-execution loop. Version attribution is a concrete quality criterion for that architecture, rather than a measured current-product guarantee.

The resulting receipt should let a reader answer a simple question: which instruction set authorized this exact order? That answer makes evolving strategies evaluable. It also lets future harness changes be assessed without quietly rewriting the history of earlier decisions.