Skip to content

Searches page titles, section headings and glossary terms.

🏛️

5.3. — Playbook Governance & Change Control

How strategies are added, modified, paused, or removed without corrupting the system
This section exists to solve a problem most traders don’t even realize they have:
They change their system every time the market hurts them.
That single behavior is responsible for more long-term failure than bad entries, bad psychology, or bad risk management combined. This stop prevents that.

Why Governance Exists at All

A playbook without governance is not a playbook. It is a collection of opinions. Without explicit change rules:
  • wins reinforce bad habits
  • losses trigger impulsive rewrites
  • confidence fluctuates with recent PnL
  • edge erodes without anyone noticing
Governance separates:
  • learning from reacting
  • evolution from emotional editing
  • system improvement from damage control

Core Principle

No strategy changes are allowed during live execution. Ever.
Live trading is for execution only. Design happens elsewhere, under different conditions. If a rule cannot survive one full session unchanged, it was never a rule. It was a feeling.

The Three Playbook States

Every strategy, variant, or rule must exist in exactly one of these states at all times. No limbo.

State 1 — Active

Criteria:
  • Fully defined
  • Documented
  • Tested in replay or sim
  • Approved for live execution
Rules:
  • No changes allowed during live trading
  • Execution must follow the written rules exactly
  • Errors are execution failures, not system failures
If a trade fails while the strategy is Active, the default assumption is you executed poorly, not that the strategy is broken.

State 2 — Under Review

Triggers to enter Review:
  • Repeated execution difficulty
  • Ambiguous signals in live conditions
  • Consistent stop-outs despite clean execution
  • Market regime mismatch suspected
Rules:
  • Strategy is paused from live trading
  • Still allowed in replay and sim
  • All observations must be logged
  • No live “testing” allowed
This state exists to protect capital while protecting learning.

State 3 — Deprecated

Triggers:
  • Structural edge no longer present
  • Better strategy subsumes it
  • Excessive overlap causing confusion
  • Proven negative expectancy over sufficient sample
Rules:
  • No live execution
  • No replay focus unless for study
  • Strategy remains documented for historical clarity
  • May be revived only through full re-approval
Deprecation is not failure. It is system hygiene.

The Change Control Rule

Only one variable may be changed at a time.
If you change:
  • entry logic
  • confirmation criteria
  • stop placement
  • targets
  • timing
  • filters
You change one, not several. Otherwise, you cannot attribute cause and effect. Multi-variable edits create false conclusions and phantom improvements.

When Changes Are Allowed

Changes may only occur:
  • Outside of live market hours
  • After a documented review period
  • With written justification
  • With explicit hypothesis
Never:
  • mid-session
  • after a single loss
  • after a single win
  • during emotional arousal

The Strategy Modification Template

Every proposed change must answer these five questions in writing:
  1. What is changing, exactly?
    1. Be precise. No vague language.
  1. Why is this change necessary?
    1. What failure or limitation is being addressed?
  1. What evidence supports the change?
    1. Replay data, logs, statistics, repeated observation.
  1. What is the risk of this change?
    1. What edge might be lost?
  1. How will success or failure be measured?
    1. Define the evaluation window and criteria.
If these cannot be answered clearly, the change is not approved.

Versioning Discipline

Your playbook is versioned, whether you track it or not. The difference is whether you do it consciously. Rules:
  • Every approved change increments a version number
  • Old versions are archived, not erased
  • Trade reviews reference the active version at the time
This prevents hindsight bias and memory rewriting.

Forward-Integrity Constraint

Before any strategy change is approved, it must pass this test:
Does this change actually improve the strategy’s performance or clarity?
Rules that exist only to reduce discomfort, smooth variance, or justify recent outcomes are rejected. Valid rules tend to:
  • reduce discretion
  • sharpen selection
  • add clear disqualifiers
  • lower cognitive load
System evolution should move toward fewer rules, clearer edges, and quieter execution. If a change cannot plausibly survive long-term profitability, it is not approved.

What This Section Explicitly Prevents

  • Strategy hopping
  • Death by a thousand tweaks
  • Overfitting to recent conditions
  • Rewriting rules to justify bad trades
  • Mistaking discomfort for flaw
  • Confusing variance with failure

The Trader’s Oath (Operational)

When a strategy is Active, you agree to this:
  • I execute it as written
  • I do not negotiate with it mid-trade
  • I do not edit it to feel better
  • I take responsibility for execution errors
  • I review performance, not emotions
Without this, the rest of the site collapses.

Why This Matters More Than New Strategies

Most traders believe progress comes from:
finding better setups
In reality, progress comes from:
stopping yourself from destroying good ones
This section is what protects the work you’ve already done.

Hand-Off to the Next Layer

Once governance is in place:
→ You proceed to Stop 5.4 — Strategy Compression & Selection (where future-you starts removing words, not adding them). This is where the system begins to quiet down. And that’s a good sign.