Temporary Trading Instructions Need an Expiry Event

A user says, “You may open a small event trade before the announcement.” The permission can expire while research is still running. A model can produce a reasonable proposal that arrives after the intended window, leaving the runtime to decide whether the earlier permission still applies.

We treat effective time as part of the mandate rather than a detail left inside conversational memory. Our compiled mandate framework recommends a stable version and effective time for the instruction set governing each action.

Three clocks in one event window

Consider an illustrative instruction allowing new exposure from 12:00 through 12:15 UTC. A turn begins at 12:14:50, the model finishes at 12:15:10, and submission would occur at 12:15:12. If permission is evaluated at submission, the new order exceeds the window even though inference began inside it.

The trace needs all three timestamps. “Started before expiry” and “submitted before expiry” are different conditions. The owner-facing text should specify the controlling event in ordinary language, such as “new orders must pass policy before 12:15.” The runtime then checks the current clock and version at that exact point.

Timezone and boundary semantics matter too. Define whether 12:15 itself is allowed, store a normalized timestamp, and render a local-time explanation for the owner. An interval with an exclusive end avoids a hidden extra minute, provided the interface explains that meaning.

Expiring an entry is different from abandoning a position

Suppose the order passed before expiry and filled afterward. The position now exists. Revoking new-entry permission should still leave an explicit management instruction for that position. A temporary research opportunity and the authority to reduce existing exposure can require different lifetimes.

A useful mandate expresses both: the entry window and the continuing exit policy. If the owner instead revokes all trading authority, the runtime needs a defined pause or closure path. These are design choices requiring explicit scope; a model should receive the resolved choice rather than infer it from an old chat sentence.

The state and memory framework explains why current state and historical instructions need separate identities. An expired entry request can remain useful historical context while its transaction authority has ended.

Replaying the awkward boundary

We would test the instruction with the same market snapshot and three artificial completion times: just before expiry, exactly at expiry, and just afterward. A second fixture holds a pending acknowledgement across the boundary. Score permission checks, duplicate submission behavior and reconciliation independently.

This is a proposed fixture. The published operating-layer record establishes historical controls research, while the expiry example supplies a narrower question for future measurement.

DXAP describes scheduled turns and triggers. Those capabilities make timing semantics especially relevant because work can continue between explicit user interactions. We would verify the actual expiry path before attributing this behavior to the current product.

An expiring instruction is useful when its meaning survives slow tools and pending orders. The engineering goal is a readable permission window with an exact enforcement event, so the owner and evaluator can agree on which actions were authorized.