Skip to content
← Back to Why MARS Was Built

Operator brief · 205

It started as a trading plan and stopped being one for identifiable reasons.

The key idea

The starting point

A plan that was already better than most.

It is worth being clear about what the original was, because the story is not one of replacing something inadequate. The initial plan specified branch management with ATR-assisted exits, defined partial-profit behaviour, set break-even rules, required journaling, and included protective brakes. That is a more complete specification than most traders operate under, and it addressed the questions a trading plan is supposed to address — what to trade, how to manage it, when to protect. What it could not address were questions of a different type, and the difference is what the whole subsequent architecture is about.

FigureHow the architecture accumulated
Plan in operationrules that govern one tradeA question arrivesabout the account, not a tradeNo machinery answers itthe plan has no such objectA module is builtthe answer becomes a workbookNew questions followthe module raises its ownACCUMULATED

The loop ran repeatedly rather than once. Each unanswerable question produced machinery, and the machinery produced the next question — which is why the module list reads as a history rather than as a design.

The five questions

Each is about the account, and a plan has no account-level objects.

How should risk change as drawdown deepens? How should several concurrent trades share a finite pool? How should open positions affect new deployment? How should live expectancy be measured branch by branch? How can structural deterioration be detected before it reaches P&L? A trading plan cannot answer any of these, and the reason is structural rather than a matter of detail: a plan's unit is the trade. It specifies what to do with one position. Every one of the five questions concerns the account as an object — its state, its capacity, its history, its condition — and the plan contains no such object to reason about.

What each became

The module list is the answer list.

The mapping is close to one-to-one. Risk changing with drawdown became the gate ladder measured from the equity peak, with deterministic states. Concurrent trades sharing a pool became the four-trade cycle and the tiered risk pools. Open positions affecting new deployment became smart exposure and throttle authority. Branch-by-branch expectancy became the scorecard and the analytics layer. Detecting deterioration before P&L became the structural diagnostics and regime interpretation, with Monte Carlo benchmarking supplying the yardstick. Read in that order, the eleven workbooks stop being a product catalogue and become a sequence of answers.

Why this history is worth knowing

It explains what the system is not trying to do.

Understanding the origin resolves a recurring confusion about scope. The architecture is dense on capital state, deployment, exposure and evidence, and comparatively silent on entry criteria and setup quality — which looks like an omission until the history explains it. The plan already handled selection and still does; the plan's territory was never taken over. What accumulated was machinery for the questions the plan could not reach, and none of that machinery has an opinion about which trade to take. The founding split between discretionary selection and governed deployment is not a philosophical position adopted at the start. It is where the boundary ended up because that is where the unanswered questions were.

The pattern that produced it

Machinery raises questions machinery has to answer.

The loop did not run once. Introducing gates raised the question of how tiers resolve inside them; introducing tiers raised the question of how pools allocate across concurrent trades; introducing evidence-based expectancy raised the question of what sample size makes an expectancy figure meaningful; introducing simulation raised the question of when a benchmark goes stale. Each answer generated its own successor question, which is the characteristic shape of a system that grew rather than one that was specified. It is also why the promotion workflow and the research boundary exist at all — a system that accumulates needs a governed way to keep accumulating.

  • A trading plan's unit is the trade; every unanswered question was about the account.
  • The module list maps almost one-to-one onto the five questions.
  • Selection was never taken from the operator because it was never the unanswered part.

The key idea

The architecture is a record of what a good plan could not do.

Systems described as comprehensive are often assembled from a view of what a complete product should contain. This one was assembled from a shorter and more useful list: the specific things that kept coming up and had nowhere to go. That origin is visible in the result — the density sits exactly where the plan was silent, and the silences sit exactly where the plan already worked. Knowing which is which is most of understanding what the system is for.

Connected inside MARS

Every brief documents the same shipped system.

The complete MARS package — eleven workbooks, three TradingView indicators, the full manual library — $497.