Why Trading Limits Need an Enforcement Point Outside the Model

A model can understand a limit and still propose an action that exceeds it. A trading platform therefore needs a place where an exact proposed action becomes either permissible or rejected. DXAP describes policy checks outside the model. We evaluate that design by asking where the check binds to execution.

Start with a concrete instruction

Consider an illustrative mandate allowing exposure of at most a defined amount in one instrument. The model proposes an order below that amount. During serialization, a quantity conversion changes the order. If policy inspected only the earlier text, the submitted action could differ from the approved proposal.

The engineering question is whether policy checks the venue-ready quantity against current account exposure. The relevant values include positions already held and any unresolved orders that could fill. Checking the new order in isolation can miss a limit breach caused by combined exposure.

This is a proposed review scenario. It identifies the enforcement point a reader should inspect rather than asserting an undocumented implementation detail about current DXAP internals.

A prompt promise has another role

Instructions inside the model context help the agent propose better actions and explain why an action fits the strategy. They are useful for reasoning. Deterministic checks provide a separate decision about whether execution may proceed.

A good proposal can fail that check because the account changed between observation and submission. The rejection should be recorded as a state transition, allowing the next turn to reason from the newer information. The model's earlier confidence cannot resolve a changed balance or an already-filled order.

Our operating-layer controls companion describes this wider separation of proposal, policy, and settlement. The narrower lesson here is that a check must follow the action through the transformations that could change its economic meaning.

Build the test around the boundary

We would save a valid proposed action, then deliberately alter one field during conversion to the venue payload. A passing test prevents the altered action from being submitted and preserves the mismatch for diagnosis.

Next, change the account state between proposal and final validation. The test should recompute the applicable exposure from authoritative state. Finally, replay the same approved request twice and inspect whether execution preserves one intended action.

Each fixture targets a specific path rather than asking the model to promise greater caution. This makes failures reproducible and improvements reviewable. It also tells an owner which protection lives in software and which instruction still depends on interpretation.

Keep enforcement and economics distinct

Policy can preserve a stated limit while the strategy loses within that limit. The continuous-record paper is useful context for evaluating economic outcomes separately from behavior and execution.

The platform benefit is control over the action path. A user should be able to express a limit, inspect its enforcement, and understand why a proposal was rejected. Frontier reasoning becomes more usable when a trading runtime supplies that concrete boundary around it. The better question for a platform is where the limit is checked and what exact action the check covers.