How Trading-Agent Mandates Become Executable Instructions

An authenticated instruction becomes useful only when the runtime can preserve it through a market decision. We call the mechanism that performs that translation the mandate compiler: it resolves instruction precedence, combines natural-language strategy with structured settings, binds the result to a version, and renders the active contract that the model and deterministic policy will use.

The compiler sits before inference. It should make the current mandate easier to interpret without granting the model authority to rewrite permissions or limits. After inference, deterministic validation checks the proposed action against that same compiled version and the current state snapshot.

We built this pattern while running DX Terminal Pro. Across a bounded 21-day real-capital deployment, 3,505 user-funded agents shared one base model and one frozen runtime while their mandates, settings, positions, and histories differed. Controlled pre-launch tests showed that compilation choices changed measurable behavior even when the model and underlying facts stayed fixed.¹

Evidence boundary: The before-and-after results below come from controlled pre-launch tests, while the setting gradients come from the bounded historical deployment. They show mandate interpretation and behavior inside those settings. They do not establish alpha, profitability, universal safety, or cross-market transfer.

Download the versioned mandate-compilation evidence table as JSON or as CSV. Version 1.0 separates controlled interventions from live setting gradients and records the fixed components, observed measure, interpretation, and evidence boundary for each result.

From User Language to an Executable Contract

A user can say, “trade actively, keep some ETH available, and exit if the position turns against me.” A form can hold a trading-activity setting, trade-size limit, asset allowlist, or loss threshold. The mandate compiler has to turn both inputs into one active contract with a clear source for every field.

That contract is richer than a prompt. It identifies the authenticated principal, the source instruction version, the structured settings, and the precedence rules that resolve conflicts. It also names the allowed action types and the abstention path. The runtime can then associate a model decision with the exact mandate it received.

We use compiled mandate to mean that versioned output. Later uses of the term refer to the same mechanism: the resolved instruction object that feeds prompt rendering and deterministic validation. A prompt is one representation of the compiled mandate. The compiler output remains the source of truth when the runtime builds another representation for policy or audit.

This distinction matters because natural language and structured settings do different jobs. Strategy text carries goals, conditions, and context that are hard to anticipate in a form. Structured settings carry values that need stable types, units, ranges, and enforcement. Compilation joins them while preserving the stronger authority of authenticated controls.

Precedence Has to Be Explicit

Mandates change. A user can update strategy text while an earlier decision is still settling. A portfolio can move after the model reads it. An old memory can describe a rule that has since been withdrawn. Without explicit precedence, the runtime cannot explain which instruction governed an action.

Our preferred order begins with owner-level interruption and closure controls. Venue and policy constraints come next, followed by authenticated structured settings. Current natural-language strategy supplies the flexible decision objective. Historical observations and prior reasoning remain context with timestamps and provenance.

That order should be encoded as data. A compiler test can then present contradictory inputs and assert which field wins. The output should retain the losing source and the reason it was superseded. Silent deletion makes later diagnosis harder because the trace can show only what the model saw, not how the runtime arrived there.

The same rule applies to updates. Each compiled version needs an effective time and a stable identifier. An invocation that begins under version 18 should either complete under version 18 or be canceled before submission when version 19 revokes its authority. Mixing fields across versions creates a contract that no user approved.

The Paragraph-Eight Test

One pre-launch scene exposed the compiler’s leverage. Every agent received the same 2.3% trading fee. When the unchanged fee sentence appeared in paragraph eight, agents cited the fee in 3% of sampled reasoning traces. Moving that sentence to paragraph one raised citation to 74%. The model, wording, and market data stayed fixed.¹

The fact existed in both prompts. Its placement changed whether it shaped the visible reasoning trace. That result does not tell us the ideal prompt order for every market. It gives us a regression case: critical mechanics should survive compilation in a position and form that the evaluated model actually uses.

We can test that case without placing capital at risk. Freeze the model and market snapshot. Render both compiler versions, collect the same trace measure, and confirm that the intended fact remains salient. A new compiler can then be compared with the existing version before it reaches paper, shadow, or live evaluation.

This is why we treat prompt rendering as compiled output. A template edit can be a behavioral change even when the user mandate stays constant. It deserves a version, a diff, and a replay set.

Three Failures a Compiler Test Can Catch

DX Terminal Pro produced three controlled results that belong together because each involved how stable source material became active instructions.

The second row was a compound intervention. We should preserve that attribution instead of describing it as a memory-only result. The third row measured capital deployment in a controlled population, not investment quality. Each record in the downloadable table carries its own evidence class and boundary so later analysis cannot flatten the three results into a single improvement score.

Together, the cases suggest a practical compiler suite. Test critical-fact placement. Test whether old reasoning remains labeled as historical context. Test whether market mechanics retain their structure and units. Then test contradictions between user text and stronger controls.

The result we want is observable mandate fidelity. The compiled output should contain the right sources, and the evaluated behavior should respond to them in the intended direction. Neither check alone is enough. A correct-looking prompt can still be ignored, while a desirable action can occur for an untraceable reason.

Structured Settings Need Behavioral Checks

Schema validation proves that a value has the right type and range. It cannot prove that the setting changes behavior as intended. We therefore pair contract tests with behavioral gradients.

During the frozen live deployment, the Trading Activity setting produced a sixfold spread in action frequency, from 2.8% to 16.8% of invocations. Trade Size mapped from about 2% of available ETH at the lowest setting to about 95% at the highest.¹ These were live setting gradients, not randomized before-and-after ablations.

The distinction is important. The gradients show that structured user settings reached agent behavior inside this deployment. They do not show that higher activity or larger trades were better. A mandate compiler should preserve the monotonic relationship that the setting claims to encode while policy still enforces capital and venue limits.

A useful setting test has two layers. The contract layer checks type, range, units, and precedence. The behavioral layer holds the rest of the evaluation subject fixed and checks whether outputs move in the expected direction. If a “lower activity” setting produces more actions, the runtime has found a mandate-fidelity regression even when every payload is syntactically valid.

What the Compiled Mandate Should Record

We recommend a small, inspectable contract rather than an opaque block of prose.

The compiler should fail closed when a required field is missing or a conflict remains unresolved. “Fail closed” here means that the runtime produces no new exposure until it has a valid compiled version. An observe or abstain action can remain available when its schema and policy allow it.

The contract should also stay readable. Operators need to inspect the active mandate during an interruption. Evaluation code needs to compare two versions field by field. A giant rendered prompt may be useful evidence, but it is a poor interface for either job.

Bind the Version to the Final Action

Compilation finishes before inference, yet mandate integrity continues through submission. The model proposes a typed action against one compiled version and one state snapshot. Deterministic policy checks the final venue-ready payload against those same bindings.

That final-payload check prevents a subtle class of errors. Symbol normalization can change an asset identifier. Decimal conversion can change quantity. A retry adapter can rebuild a request after the mandate has changed. Validation performed only on an earlier model object cannot establish that the submitted payload still matches the approved instruction.

The trace should record the compiled mandate hash, state snapshot identifier, proposed action, policy result, final payload, venue acknowledgement, and reconciled outcome. We define the mandate-to-settlement trace as that linked record from authenticated intent to final portfolio effect. Its mechanism is attribution: it shows which compiler and policy version governed the action, plus what happened after execution.

DX Terminal Pro linked each invocation to its mandate and configuration. The same record carried the rendered prompt and reasoning into the tool call, validation result, portfolio snapshot, and chain outcome.¹ That sequence let us separate a buried fee fact from a transaction failure. It also lets a resolved incident become a regression case for the exact stage that failed.

Test the Compiler as Its Own Component

Our minimum compiler evaluation uses five steps:

1. Freeze the model, state snapshots, sampling settings, tool schema, and policy version.
2. Register contradiction cases, critical-fact cases, setting gradients, and stale-version cases.
3. Compare compiled outputs field by field before measuring model behavior.
4. Score typed actions and abstentions against the active mandate and fixed state.
5. Preserve every result with the compiler version and evidence class.

This isolates the compiler from a model upgrade. If both change together, a better action cannot be attributed cleanly. The DXRG Benchmark Card records the full evaluation subject, and the Agentic Trading Evidence Ladder keeps replay results separate from paper, shadow, and live evidence.

The tests also need negative space. A strong compiler should preserve a valid no-trade option. It should reject ambiguous units rather than guessing. It should withhold action when current portfolio state cannot be reconciled. Those outcomes are useful behavior because they keep uncertainty visible to policy and evaluation.

A Technical Pattern, With Scoped Regulatory Parallels

The mandate compiler is our engineering pattern, not a regulatory category. Established trading-control sources still offer useful parallels within their stated scope.

SEC Rule 15c3-5 requires covered brokers or dealers with market access to maintain controls designed to block orders that exceed preset credit or capital thresholds, appear erroneous, or fail applicable pre-order requirements.²

FINRA Regulatory Notice 15-09 discusses development controls, retrievable code versions, system validation, parameter review, monitoring, and rapid-disable mechanisms for member firms using algorithmic strategies.³

Those sources do not create a universal rule for every trading agent. They reinforce a narrower technical point: execution controls need a documented version, tests, and an enforcement point before an order reaches the market. Our compiler supplies the mandate-side inputs to that boundary. Deterministic policy supplies the decision.

Read the Evidence Without Inventing Alpha

Mandate compilation is an attribution mechanism. It can improve whether the runtime carries a user instruction into the model and policy correctly. It can make a behavioral change reproducible. It can also expose conflicts before an action reaches execution.

Those properties remain separate from trading skill. The fee-placement test measured citation in reasoning traces. The fabricated-rule test measured an instruction failure. The tokenomics test measured capital deployment in one affected population. The live setting gradients measured behavioral response. None of those denominators is a return study.

This separation is the practical value of the evidence table. A researcher can reuse the schema without inheriting a broad performance claim. A team can add a new compiler case, state what stayed fixed, name the measure, and preserve the limit on interpretation.

The larger harness and runtime framework shows where the compiler sits beside state assembly, memory, typed actions, policy, execution, settlement, and the feedback loop. Our technical definition of agentic trading explains why delegated market decisions require this end-to-end treatment. The DX Terminal Pro record provides the first-party deployment and controlled-test context behind the measurements here.

The next question after compilation is state: did the model receive the current market, portfolio, venue, and memory record that the mandate requires? We will treat that as a separate spoke so mandate fidelity and state integrity remain distinct evaluation targets.

---

Version 1.0. Published July 21, 2026. Corrections: poof@dxrg.ai. This article is research and educational material, not financial, investment, legal, compliance, or security advice.

Footnotes

1. DXRG, Operating-Layer Controls for Onchain Language-Model Agents Under Real Capital, April 28, 2026, and the DX Terminal Pro companion. See the system architecture, control-loop results, production behavior, and trace sections. ↩ ↩² ↩³ ↩⁴

2. U.S. Securities and Exchange Commission, “Risk Management Controls for Brokers or Dealers With Market Access”. The rule applies to covered brokers and dealers within its stated market-access scope. ↩

3. FINRA, “Regulatory Notice 15-09: Guidance on Effective Supervision and Control Practices for Firms Engaging in Algorithmic Trading Strategies”, March 26, 2015. The notice applies to FINRA member firms within its stated scope. ↩