A Valid Trading Action Needs More Than Valid JSON

A language model can return perfectly valid JSON for an order that exceeds the owner's authority. A typed action makes the proposal machine-readable, but the runtime still has to check its meaning against the mandate and the current account state.

We distinguish these checks because an agent's transaction path crosses several representations. The published DXRG control architecture carries a typed model proposal through deterministic policy, submission and reconciliation. Each step has a different job.

Follow a quantity through conversion

Consider an illustrative action requesting a buy with a maximum position value of $100. The model proposes 0.003 units at a reference price of $30,000, implying $90. The action may satisfy its schema: known symbol, buy side and positive quantity.

Suppose a venue adapter rounds the quantity up to 0.004 units. At the same reference price, value becomes $120. Validation of the original object cannot establish validity of the final request. A policy check has to see the converted quantity and the relevant current price or its stated valuation rule.

A better adapter follows the mandated rounding direction and checks the final payload before submission. Depending on venue precision, rounding down to 0.003 may be possible, or the instrument's minimum size may make the requested trade infeasible. An explicit infeasible result preserves the owner's cap.

This is a teaching example rather than a claim about any venue's actual precision. The point is that conversion changes a value policy cares about, so the check must occur after conversion as well as before it.

Three questions for validation

Schema validation asks whether fields have expected types, required values and allowed enumerations. Mandate validation asks whether the proposed action falls within the active authority and risk limits. Final-payload validation asks whether the exact request being submitted still satisfies those limits after translation.

Our mandate compiler framework connects each check to one versioned instruction set. A retry that rebuilds a payload should retain that binding and receive any required fresh-state checks. Otherwise a well-formed retry can execute under stale permissions.

The execution and settlement article extends the record beyond approval. Venue acknowledgement, fill and reconciled portfolio state determine what actually happened. Passing a validator and obtaining the intended position are separate outcomes.

Count rejections and accepted violations separately

An evaluation fixture should include malformed actions, valid-but-forbidden actions and valid proposals that become invalid during conversion. Record which layer rejects each case. A single “validation success” percentage can hide a policy failure behind a large population of easy schema checks.

Also retain false rejections of legitimate actions. A validator that blocks everything can eliminate submitted violations while making delegated trading unusable. The metric pair is accepted violations and rejected valid proposals under a stated fixture distribution.

DXAP describes policy enforcement outside the model. Typed actions make that boundary concrete and inspectable, with implementation quality established by tests and transaction receipts.

The frontier work is in preserving meaning from proposal to final request. Stronger models can improve proposals, while precise validation remains necessary to establish which transactions the owner actually authorized.