What a worked example of review process means
A worked example of review process is a fully stated, step-by-step demonstration of how someone reviews a past decision using recorded inputs, explicit assumptions, and a repeatable method. The goal is not to predict the future; it is to verify what you did, what happened, and why the difference may exist.
In practice, “review” usually refers to: (1) capturing the decision context, (2) listing the planned reasoning and conditions, (3) recording the observed outcome, and (4) explaining any gap using factors that are either stable (your method) or variable (market conditions, costs, and execution details).
How the mechanism works (stable vs variable inputs)
A review process works best when you separate mechanics you control from conditions you cannot.
1) Decision mechanics (stable): how you chose actions, how you calculated position sizing or risk limits (if applicable), and how you defined criteria for “good” vs “bad” outcomes.
2) Inputs that can change (variable): market movement, spreads/transaction costs, latency or order execution differences, and any constraints that depended on time or jurisdiction.
3) Evidence: prices, timestamps, and trade/order records—whatever artifacts exist in your own records. If you do not have a specific record, you should treat that as an uncertainty rather than filling the gap.
A worked example should therefore state assumptions up front. If a number is illustrative, say so. If a component is unknown, say so.
Worked example (transparent numbers and assumptions)
Below is a scenario-style worked example of the review process. It uses a simplified “planned vs observed” comparison and assumes no real-time data.
Assumptions (declare everything):
- You are reviewing one single event.
- Planned entry price: 1.2000.
- Planned reference spread or estimated transaction cost: 0.0002.
- Planned execution effective price (planned): 1.2000 + 0.0002 = 1.2002.
- Observed entry price: 1.1988 (from your own execution record).
- Actual transaction cost is unknown, so you assume the same spread model as planned for this example.
- Quantity (units) is Q = 10,000 (assume spot-like conversion for illustration).
Step 1: Compute planned “effective” entry value (mechanics).
- Planned effective entry = 1.2002.
Step 2: Compute observed effective entry using the same cost assumption (variable condition + repeated assumption).
- Observed effective entry = 1.1988 + 0.0002 = 1.1990.
Step 3: Compare the gap in effective entry.
- Difference = 1.1990 − 1.2002 = −0.0012.
Step 4: Translate into a simplified P&L impact (illustrative).
- For illustration only, assume the effective-price difference times quantity gives the monetary difference.
- Monetary impact = −0.0012 × 10,000 = −12.
Step 5: Attribute the gap (avoid a single-cause story).
- Part of the gap comes from market movement between your planned reference and observed execution.
- The rest (if any) could come from cost modeling error (our assumption that costs behaved the same way).
- There could also be execution timing differences (not modeled here because timestamps are not included in the example).
A completed review ends by listing what was verified (your planned numbers vs your observed records) and what remains uncertain (e.g., whether transaction costs truly matched the assumption, because you did not include separate observed cost data).
Limitations and failure modes (what can go wrong)
Even a well-structured worked example can fail if it hides uncertainty.
- Missing evidence: If you do not have execution timestamps or recorded costs, you may accidentally “assume away” key drivers.
- Unrealistic cost assumptions: Transaction costs, spreads, and effective execution can differ from your estimate; reusing the planned cost model can misattribute the gap.
- One-off reasoning: Historical relationships in a single event do not establish what will happen next.
- Overfitting the narrative: A common failure mode is explaining outcomes using only one preferred factor while ignoring other plausible contributors.
The review process remains useful if you treat these as verification limits: you can still identify inconsistencies, but you should not claim certainty about future results.
How to verify and what to ask next
To independently verify your review:
- Ensure each numerical step is traceable to either a recorded artifact or a clearly stated assumption. 2) Recompute the comparison using the same assumptions and show intermediate values (like effective entry).