Captain · Independent Research and Operations · About 30–40 minutes
Safety rule: Protect the account and preserve original evidence before investigating a trading incident.
Your mission today
By the end you can write a factual incident review that separates a normal loss from a controllable process failure.
Before you start
Bring your Captain trading manual, an imaginary loss ledger and the original rule version. Do the exercise after the mock session, not during a live emotional response.
1. A bad result is not always an incident
An aircraft can land safely in heavy weather and still report a procedural concern. A trading position can lose money while its operator follows every rule. The difference matters. An incident is an event that warrants investigation because a process, system or risk control failed or nearly failed. A normal planned stop may be an expected financial outcome rather than an incident. A missing protective stop, an unauthorised risk increase or an unverified duplicate order can be an incident even when the account ends in profit. Your review should ask: What was expected under the written plan? What actually occurred? Which difference was controllable? Begin by stopping new activity if a safety control is still uncertain. Then preserve screenshots, timestamps, order confirmations, broker messages and the strategy version. Do not start by deciding who to blame or by looking for a chart pattern that makes the story feel inevitable.
2. Reconstruct the cash loss without shortcuts
Imagine a fictional EURUSD demo session with three stopped trades. Each intended loss is 10 pips at an invented $1 per pip, giving −$10 each before other fees. Three such losses total −$30. If the written daily loss ceiling is $30 and it includes costs, the student must stop new risk when the cap is reached or could be breached. A fourth proposed trade with the same stop would expose another −$10, making the planned cumulative price loss −$40. That breach is controllable, regardless of whether the fourth position would eventually win. Now imagine one stop fills 2 pips beyond its trigger. That ticket's price loss is −$12, not the hoped-for −$10. Record the actual fill and charge assumptions rather than smoothing away the adverse difference. A later bounce is not proof that the stop was a mistake.
3. Write a factual event timeline
A proper timeline starts with the earliest relevant event, not the largest red candle. Use four columns: timestamp and timezone; observed fact; source evidence; and unknown information. Example: 10:00 plan approved with $10 per-trade limit. At 10:15 the completed M15 candle qualified. At 10:16 the order request was sent. At 10:16:02 the platform returned an uncertain confirmation. At 10:17 the position list showed an open order. Those are fictional times for teaching. Each fact should have a screenshot, log or confirmed platform record. Do not claim the broker deliberately moved prices without evidence. If the actual bid/ask quote history is unavailable, write UNKNOWN. The analyst's first job is preserving what can be checked, not making the most emotionally satisfying explanation.
4. Separate root cause from the last visible symptom
Root-cause analysis tries to understand why a control failed, not merely which bad result appeared at the end. Suppose a duplicate order increases cash risk beyond the charter. The immediate symptom is excess exposure. The earlier action may have been resubmitting after an ambiguous acknowledgement. The deeper control failure may be the absence of an order-status verification procedure in the manual. The corrective action should therefore address the verification step rather than merely telling the trader to 'be more careful'. Some losses arise from market movement even when every procedure works. Do not force a controllable cause onto every adverse outcome. Conversely, a winning trade can hide a serious control failure. Review the process even when positive P/L tempts everyone to forget the mistake. Keep alternative explanations visible until the evidence supports one.
5. Build a correction that can actually be tested
A useful corrective action changes a defined behaviour or system check. Example: 'Before resubmitting any uncertain order, the operator must verify position and order status via the approved channel and record the result.' Name the person or role responsible, the deadline, evidence of implementation and test needed for closure. A vague action like 'Trade with more discipline' cannot be verified. Test the new procedure on a demo outage scenario and attempt to reproduce the failure safely. Save the test result. If the procedure fails, keep the incident open and halt the affected activity rather than declaring victory. Changing the entry indicator may do nothing to solve an order-verification problem. Fix the layer where the control failed. An incident record should also show which risks remain unresolved after the first correction.
6. Finish with an independent, non-punitive review
Your incident report should contain the date, account type, affected strategy version, full event timeline, planned versus actual cash exposure, relevant evidence, root-cause hypothesis, immediate protection, corrective action and follow-up test. Add an explicit distinction between trading outcome and rule compliance. Invite a reviewer to challenge any conclusion unsupported by records. Suppose a lesson ends with a normal three-trade loss reaching the daily cap, and the operator correctly stops. That can be a compliant bad financial day, not a process failure. Suppose instead the operator enters a fourth unauthorised trade that earns money. The outcome is positive but the risk-control incident remains real. Review both without rewriting their original timestamps. It is a safer, clearer operating process that a second person could check. That is a credible foundation for ongoing learning after Captain graduation.
Common mistake
A trader reviews a losing day by redrawing every entry to make the chart appear obvious. The revised chart hides what was known at the time. Fix the report by preserving original order records and tracing the first verifiable process deviation.
Plain-English glossary
- Incident: event involving a process or control failure or near miss.
- Root cause: underlying condition that allowed a failure.
- Timeline: ordered facts with dates, times and sources.
- Corrective action: a specific change whose effectiveness can be tested.
- Closure: documented evidence that a corrective action passed its check.
Try it yourself
Write an incident report for an imaginary four-trade day where the fourth trade violates a $30 daily cap. Include timestamps, quote-side losses, screenshots, immediate halt, possible root cause, corrective action owner and demo retest. Also write a separate report for a rule-compliant three-loss day.
What you can now do
- Explain the operating requirement and its failure mode.
- Recompute the relevant cash-risk calculation and state assumptions.
- Preserve an independent, evidence-based decision or review record.
Next lesson
The journey continues · Maintain your strategy manual, demo records, independent research and incident reviews as ongoing professional development.
