Share failure mechanisms while preserving different owner mandates

A shared failure library can help many owners without making their strategies converge. The reusable lesson is often a relationship: apply the current owner's limit to the current account state, recognize an unresolved order, or preserve a correction's effective time. We propose storing those relationships as test families alongside permissioned examples. Different owners can then benefit from the same repair while retaining different decisions.

The DXAP execution reference describes configured opening limits and distinguishes opening from closing exposure. Its position cap covers new symbols when configured. These mechanics give a shared library something precise to test: whether the harness preserves the applicable restriction through variations in the owner's mandate and account.

One family, opposite expected actions

Take an illustrative account with two open symbols and no pending entries. A request opens a third symbol. Owner A has a cap of two; owner B has a cap of four. The expected check rejects A's request and allows B's request to continue through the remaining checks. A candidate that rejects both has memorized a surface answer rather than learned the relationship. Passing B's cap check still leaves venue execution and profitability as separate questions.

Now transform the example by adding one pending entry in a different symbol. The projected distinct-symbol count becomes four. A cap of three blocks the proposed new symbol; a cap of four permits it at this check. Increase an already-open symbol instead, and the distinct-symbol count stays three. This third variation tests whether a repair understands the unit being counted.

We would record the family as a function of current distinct symbols, pending new-symbol entries and configured cap. Its public summary can explain those relationships without exposing another owner's actual positions. Each underlying example needs permitted use, and the family inherits any restrictions required by its source material.

Reward transfer across variations

A proposed evaluation would reserve whole combinations of caps and account states for testing. Compare a candidate repaired from the family with an unchanged harness on those held-out combinations. Report rejection correctness and unnecessary rejection separately, including cases where reductions remain allowed. A single aggregate score could hide a repair that protects restrictive owners by obstructing permissive ones.

The historical controls paper describes harness revisions evaluated through replayed scenarios. A library organized around relationships extends that method into a shared asset: one identified mechanism can generate many meaningful contrasts, provided reviewers validate their expected results. Generated variants should carry a synthetic label and remain distinct from observed incidents.

This value differs from collecting popular strategies. A shared repair should improve how mandates are executed, leaving owners to choose their own approach. We would ask a reviewer to explain why the expected action changes between each pair. If the explanation requires copying a source owner's preferred trade, the family needs revision. If it follows the current owner's constraint, it can support useful cross-owner learning.