Most traders who say they use a checklist are actually using a feeling — a loose sense that "everything looks right." That is not a checklist; it is an approval ritual. This article is about the structural difference between the two, and how to build a five-to-seven item gate that forces a genuine pass/fail answer before any decision proceeds. By the end, you will be able to design checklist items that actually hold, understand why length kills compliance, and know how to improve the checklist from your own post-mortem record.

A Checklist Is a Gate, Not a Strategy

This distinction is load-bearing. A strategy tells you what conditions favor a certain action. A checklist does something different: it blocks the action if any stated condition is not met. The checklist is not generating the decision — it is filtering it. A strategy without a gate produces decisions at the speed of impulse. A strategy with a gate produces decisions only when the full condition set is satisfied.

The practical consequence: a checklist that does not stop you is not functioning as a gate. If you can look at a failing item and still proceed — if the checklist is advisory rather than binary — it provides the feeling of process without any of the protection. Soft checklists are more dangerous than no checklist at all, because they add the cognitive satisfaction of having "checked" without the actual constraint.

This article is not about the pre-mortem, which imagines how a specific trade might fail before you act. It is not about the decision journal, which records reasoning for later review. The checklist operates earlier and harder than both: it stops a decision that cannot pass a fixed set of tests, regardless of how compelling the opportunity feels in the moment.

Three Properties of a Good Checklist Item

Most checklist items fail at design, not at use. A weak item looks like this: "Conditions feel favorable." That item cannot fail — because "feels favorable" can always be satisfied by the brain that is already committed to the trade. A well-designed item has three properties.

Verifiable. The item must be observable and independent of the decision-maker's current conviction. If confirming the item requires interpreting ambiguous evidence, it is not a checklist item — it is an opinion. Good items point to a specific, readable fact: a price relationship, a session state, a quantified condition.
Binary (pass/fail). The item must produce a clear yes or no. Graded items — "somewhat aligned," "partially confirmed" — allow negotiation in the moment. Binary items do not. If the answer is not a clean yes, the item fails and the decision stops.
Gating. Every item must be individually sufficient to block the decision. If a single item failure does not stop the decision, the item is decorative. The full gate holds only if every item is treated as a veto.

Five to seven items is the functional range. Below five, the checklist tends to become too abstract to be useful — each item has to cover too much territory and loses specificity. Above seven, compliance collapses under time pressure. The brain begins skimming, and skimming defeats the purpose of having items at all. Length is not rigor — it is a compliance tax. Every item you add makes every other item slightly less likely to be read with care.

The "Self" Item

At least one item on any functioning checklist must check the decision-maker's state, not the market's state. This is arguably the most important item on the list, and it is also the most commonly omitted.

The logic is straightforward: even a perfectly designed set of market conditions cannot protect you if the person evaluating them is in a compromised state. A trader who is tired, frustrated after a losing sequence, or emotionally invested in a particular outcome will pass market-condition items with degraded objectivity. The "self" item creates a structural moment of self-assessment before any market evaluation begins.

A self item looks like this: "Am I in a calm, rested, non-revenge state right now?" That item is binary. Yes proceeds. No stops the decision — not the approach, not the day necessarily, but this specific decision, right now. The self item is not asking for perfection; it is asking for a minimum threshold of deliberate function. If the honest answer is no, the checklist has already earned its existence by stopping one deteriorating decision.

The confronting truth is that the self item is precisely the item most likely to fail during the sessions that feel most urgent. A market that "needs" a decision right now, a setup that "won't last," a sequence of losses that "needs recovering" — these emotional states are exactly the conditions under which the self item will fail and the gate needs to hold.

How a Checklist Improves Over Time

A newly designed checklist is necessarily incomplete. It captures what you currently know about your own failure modes, which at the beginning of any honest self-review process is much less than you will eventually discover. The mechanism for improvement is the post-mortem.

When a decision goes wrong, the review question is: which condition was not actually present when I entered? Not "why did the market move against me" — that is an outcome question. The checklist question is about the state of the conditions at decision time. If the review finds a condition that was absent or ambiguous when you acted, that condition becomes a candidate for a new checklist item — provided it meets the three design properties above.

This converts post-mortem pain into structural protection. A loss that teaches you nothing is just a cost. A loss whose root condition becomes a checklist item is a loss that has purchased a gate. Over time, a well-maintained checklist becomes a compressed record of every identifiable decision failure, translated into a future block. That is why the checklist is a living document, not a fixed one — it should be longer next year than it is today, up to the seven-item ceiling, at which point items should be evaluated for consolidation or replacement rather than mere addition.

One discipline note: do not add an item after a profitable decision you feel uncertain about. Checklist items must trace to losses or near-losses, not to general anxiety. Adding items from anxiety produces bloat; adding items from identified root causes produces protection.

Why Soft Checklists Achieve Nothing

A checklist becomes soft when its items are phrased as qualities rather than conditions. "Good risk/reward" is a quality — it requires judgment to assess and judgment can always find it present. "Defined invalidation point at or below the last structural low" is a condition — it is either there or it is not.

Softness also enters through application: the checklist exists but is mentally processed after the decision has already been made emotionally. In that order, the checklist becomes a rationalization tool. The brain confirms items that point toward the desired answer and quietly discounts items that do not. The only structural defense against this is the order of operations: checklist first, decision derived from it — not decision first, checklist consulted afterward for comfort.

The harder truth is that a checklist you designed yourself can always be gamed by the brain that designed it. This is why the self item, which checks state rather than conditions, is partially immune to this failure mode — it is harder to rationalize your way through "am I in a calm state" than to rationalize your way through a market condition assessment. The self item operates at a layer below the motivated reasoning that corrupts the rest of the list.

When Expertise Is Not Enough: The Boeing Model 299

On October 30, 1935, a Boeing Model 299 — the prototype of the aircraft that became the B-17 — crashed on takeoff at Wright Field, Ohio, killing the pilot, Major Ployer P. Hill, and a second crew member. Investigators found the cause was not mechanical failure and not lack of skill: the crew had simply not released the flight-control gust locks, a preparatory step that existed in no formalized sequence. In response, Army Air Corps test pilots and Boeing test pilots produced a written pre-takeoff checklist — a fixed, ordered gate that any crew member could run independently of memory or habit. The principle embedded in that response is the same one this article is built on: complexity defeats unaided human memory even in highly trained experts, and the correct fix is an external gate run before action, not a demand for greater individual expertise. That checklist became the ancestor of modern pre-flight procedure.

Simulator Exercise: Build and Run a Five-Item Gate

Before your next Speed Run session, write five checklist items on paper or in a text file. Do not start the simulator until the checklist is written. Each item must meet the three properties above: verifiable, binary, gating. Include at least one self item as item one.

Then run a Speed Run of at least ten events. Before each entry decision, work through the checklist out loud or in writing — one item at a time, in order. Record the result: pass on all five, or fail on item N. If any item fails, the decision stops. You do not enter. You note which item failed and continue to the next event.

The exercise target is this: at least one entry should be blocked by a failing item across the session. If every decision passes every item, either your checklist items are too soft or the Speed Run events are unusually clean. Either way, review the items after the session and tighten any that never produced a no answer. A checklist that never fails is not functioning as a gate — it is functioning as a ritual.

After the session, answer: which item, if any, produced the most hesitation to record honestly? That item is doing the most work and deserves to stay on the list.

Simulator note: Speed Run sessions in Abu Terminal are time-limited per event. If your checklist takes longer than the decision window, that is diagnostic — either the items need to be more automatic or the session mode needs adjustment. Start with a non-speed-limited session until the items become reflexive.

The Trading Checklist: Designing a Gate That Actually Holds