Review the trade with the context it had at entry

The Settings On Screen Are Not The Settings It Used

The most common error in reviewing a closed position is silent and almost impossible to notice from the inside. You open a cycle that closed three weeks ago, read the exit rule in your settings panel, and conclude that the loop behaved oddly. It did not. It was following a different rule, because the rule it followed was captured when the cycle opened and has been travelling with that cycle ever since.

CVEST snapshots the exit policy at entry and uses that snapshot for the whole life of the cycle. Change your take-profit fraction tomorrow and every position already open keeps the fraction it started with. This is the correct behaviour — a position should not have its exit conditions rewritten underneath it — but it means a review that reads current settings is comparing a decision against limits that did not exist when the decision was made.

There is a second-order consequence worth knowing. A cycle old enough to predate the snapshot mechanism has no captured policy, and rather than guessing, the system forces its risk exits to zero. An old cycle that appears to have ignored a risk threshold may simply have had none to ignore.

What The Record Actually Contains

A cycle is not a summary row with some history attached. It is a sequence of recorded observations, each written at the moment it occurred, each carrying its own sequence number, kind, mode, event time, observation time, schema version, engine version and a content digest. The digest matters: it makes an observation verifiable rather than merely stored.

The kinds are specific, and reading the list tells you a great deal about what a review can ask. A scanner evaluation records a comparison that happened. An entry decision records why one candidate was selected. An order intent records what was about to be submitted. An order reconciliation records what the venue said afterwards. Position monitors record the state over time. Exit decisions record the rule that fired, with manual exits recorded separately from rule-driven ones, and deferred revalidations recorded as their own event rather than as an absence.

That last one is the sort of detail that distinguishes a record from a report. When an exit condition was breached and then cleared before the close was submitted, the system does not quietly do nothing. It writes down that it deferred, so the gap between a breach and a non-event is legible later.

Full Chain Versus Owned Legs

One distinction in the record repays close attention, because misreading it will make you believe the loop saw less than it did, or more. Entry decisions carry the full option chain that was fetched at the time. Position monitors carry the owned legs, and the full chain again whenever the position changed or the cycle is closing. Each observation is tagged with which of the two it is.

The reason is practical rather than philosophical. At entry, the comparison is between many possible structures, so the alternatives are part of the evidence for the choice. While a position is open, the question is the state of what is held, and recording the entire chain on every monitoring pass would bury the relevant data under an enormous amount of unrelated quoting.

Do not read a position monitor as evidence about the wider market at that moment. It was never a picture of the market. It is a picture of what you held.

When a review needs to know what else was available, the entry decision is the observation that answers it, and it is the only one that can.

Read The Phase, Not The Calendar

A cycle moves through four phases: opening, open, closing and settled. The temptation is to treat an expiry date as equivalent to settlement, and the product deliberately refuses to do so. An expired position reads as awaiting settlement, and the label never implies that settlement happened.

In live execution the standard for settlement is strict. The system requires the venue's official delivery price and matching account bills before it will book anything. Without those bills it says so plainly rather than estimating, with a message stating that it is waiting for settlement bills and that no profit has been booked. An expired position is an unfinished record until the venue confirms it.

In paper mode settlement is computed from intrinsic value at the official settlement price, and in replay from the synthetic spot the generator produced, in both cases minus an estimated fee, and is labelled as estimated with the reason recorded as a simulated settlement. That label is the whole point. A simulated settlement is not a weaker version of a real one; it is a different kind of statement, and the record keeps them separable.

What Each Part Of The Record Can Answer

The table is a reading aid for locating the right evidence, not a checklist and not a scoring model. The third column is the one worth reading twice, because it is where reviews usually overreach.

Notice that no row lets you ask what would have happened under a different rule. The record is evidence about what occurred. There is no facility for replaying a closed cycle under alternative settings, and the absence is deliberate rather than pending: a counterfactual fill is not something the journal could honestly produce.

The Record Cannot Be Tidied

Nine tables are protected at the database level by a trigger that raises an error on any update or delete: observations, order intents, imported portfolios, raw venue records, broker mutations, and the analytics inputs, snapshots, overlays and forecasts. This is not an application convention that a future feature might relax. It is enforced beneath the application, on every one of those tables.

The same principle extends upward. Deleting an organisation is refused outright, with the reason given as financial workspaces retaining their audit history. There is, correspondingly, no in-app control for deleting trade history, and the absence of that button is a design decision rather than an unbuilt feature.

For a reviewer this is the property that makes the exercise worth doing at all. A record that could be edited after the fact would only ever tell you what the last editor believed. A record that cannot tells you what happened, including the parts that are unflattering or inconclusive.

First Steps

1. Open the cycle in Position history and read its recorded exit decision first. The entry policy travels inside the cycle record rather than on that screen, so take it from the research export when you need the exact fractions.
2. Find the entry decision and read the alternatives it recorded, then move to the exit decision and read the rule that fired and the state at that moment.
3. Check the phase and, for a live cycle, whether settlement evidence exists. If it does not, stop before drawing a conclusion about the outcome.

A Review Ends In A Question, Not A Verdict

The useful output of reviewing a closed cycle is rarely a judgement about whether it was a good trade. The record cannot support that judgement and does not try to. What it can support is a much more specific question: was this limit the one I meant to set, did the exit fire on the condition I expected, and does the gap between intent and execution have an explanation I can point at.

Those questions accumulate into something useful over a year in a way that a verdict never does. And because the record cannot be revised, the question you write today can still be checked against the same evidence when you return to it, which is the only reason keeping a journal is worth the storage it consumes.