An acceptance test for opening a protected position

A successful entry and a successful protection request are separate events unless the execution path establishes their relationship. Our continuous record reports a historical 48-hour window in which 24 of 35 successful opens lacked their protective trigger after a non-retryable trigger-quota error. We propose an acceptance test for that failure class. PROPOSED here means a test specification, with no assertion that current DXAP implements a particular atomic order primitive.

Define protection as observable state

The test starts with a typed entry request, an intended protective order and a declared failure policy. Success requires evidence that the position and its required protection are present in reconciled venue state. An acknowledgement by the model or a local queue entry is insufficient. We would define acceptable price levels, quantities and trigger direction, including how protection changes after a partial fill.

An illustrative request opens ten units with a protective exit for ten. If only four units fill, the fixture asks whether protection covers four, ten or a dynamically updated amount under the venue's order semantics. The expected behavior must be explicit. Otherwise a test can report protection present while missing whether that order can execute as intended.

Inject failures between every transition

We would simulate a rejected protection request, a timeout after submission, a duplicated retry and a quota exhaustion. For each case the record captures submission identifiers, acknowledgements, reconciled positions and protective orders. The same request identifier must be recognized on retries where the implementation supports idempotency. If the transport cannot establish whether an order was accepted, reconciliation should resolve the uncertainty before another entry is attempted.

The critical acceptance invariant is that the workflow reaches a documented terminal state. That might be a protected position, a cancelled unfilled entry or a controlled response to an exposed fill. Choosing among those responses requires product and venue semantics; the protocol evaluates the chosen response rather than inventing a universal flattening policy. An unresolved exposed position remains a failed fixture even when the turn ends cleanly.

Keep the replay finding in its historical scope

The record's fixed 2% stop and 4% target replay estimated improvement on historical positions. That replay used the paper's assumptions and does not establish current returns, reliable trigger delivery or the best bracket for every mandate. The failure-injection test instead asks whether the requested protection survives operational faults. Both questions matter, and they require different evidence.

The operating-layer controls paper describes linking mandate, validation and settlement in a trace. DXAP currently describes a policy engine outside the model and recorded turns on Hyperliquid. Those mechanisms make an execution acceptance corpus relevant to the platform's evolution. A release earns a stronger reliability claim by passing declared failure cases against reconciled state, while performance claims remain attached to their own matched evaluation.