The gold setup expired. Did the working order expire with it?

Three clocks can govern one intended trade

CME’s order-type guide distinguishes a day order, active for the trading session if unfilled, from a good-till-cancel order that remains working until cancelled or filled. The applicable product and broker rules still need to be checked. A calendar day on the phone is not a sufficient definition of the relevant trading session.

Now add a third concept: an indicator’s setup-validity window. That window belongs to the signal logic. Unless an actual, verified integration links it to an order-management instruction, its expiry does not establish that a working broker order has been cancelled. This article examines that operational distinction; it does not describe an automatic trading capability of CyGuru.

Source notes: [1] CME Group — Futures Order Types, Time Limits

An expired idea can leave an active instruction

Imagine a hypothetical setup intended to remain valid for thirty minutes. A trader separately enters a persistent limit order and later sees the setup marked expired in a research interface. If no cancellation instruction has been accepted by the order system, the two records may now disagree: the research idea is inactive while the order remains live.

The error is understandable because the same word, active, can appear on both screens. But one screen describes a model state and the other describes an instruction capable of execution. I would record their identifiers separately. A signal ID helps trace the idea; an order ID helps trace the instruction. A link between them is useful only if its behaviour has been tested and its acknowledgements retained.

Cancellation is a state transition to verify

My suggested operating procedure distinguishes cancellation requested from cancellation confirmed. The user’s intention to stop an order and the receiving system’s accepted state are separate observations. If the interface is unavailable or the outcome is unclear, record the uncertainty rather than treating the click as proof. Consult the broker’s documented process for resolving uncertain order status.

A replace operation deserves the same attention. An updated price, quantity or duration may be handled through a particular order workflow. Before relying on it, establish what the broker reports for the old instruction and the replacement. This article is not a specification for a broker API; it is a checklist of questions to answer from the actual service before assigning automation any authority over an account.

Review unfilled quantity, not just the original ticket

A partially completed instruction creates another possible mismatch. The original requested amount, executed amount and remaining working amount are distinct. A journal that retains only the opening ticket can fail to show what is still capable of trading. The same caution applies when a person manually closes a position while a separate exit instruction remains outstanding.

For a practical review, I would reconcile positions and working orders together, including their identifiers, quantities, contract months and duration. Do this after a material manual change as well as at the intended end of the strategy window. Do not infer cancellation from a flat-looking chart or from the absence of a new notification. The authoritative record is the confirmed order state supplied by the actual execution service.

A clean boundary for the research terminal

The CyGuru research record can help preserve when a setup was created, updated or expired. It should remain explicit about what it does not prove: account activity, order acceptance, cancellation or fill. A reported TP milestone is not a broker instruction, just as an expired setup is not a cancellation acknowledgement.

The useful improvement is a two-ledger habit. Keep the indicator lifecycle in one ledger and the execution lifecycle, if there is one, in another. Reconcile them through explicit IDs and timestamps rather than appearance. No trade, missed cancellation or loss is asserted in this article. The example is hypothetical, and the exact order-duration behaviour must be verified for the chosen product and broker.