Skip to content
← Back to Why MARS Was Built

Operator brief · 207

The specification was a list of ways to lose, written first.

The key idea

The two design directions

Forward design produces features; backward design produces coverage.

Specifying forward asks what a complete trading system should include, and the answer is drawn from what such systems generally include — a journal, a dashboard, some analytics, a risk calculator. The result is a product that resembles its category and inherits its category's blind spots, because nothing in the process ever asked what was actually killing accounts. Specifying backwards inverts the question: enumerate the ways a positive edge is destroyed operationally, then require that each one has something answering it. The output is not a feature list. It is a coverage map, and the difference shows up in what is present and what is conspicuously absent.

FigureCoverage across the operational failure inventory
Sizinggate, tier, pool, exposure — the densest coverageDrawdown responsethe ladder, automatic and pre-committedConcentrationcycle pools and correlation-aware sizingRecord integrityjournal discipline plus QA validationPremature changesandbox, persistence windows, promotionFee dragmeasured and stressed, not eliminable0%25%50%75%100%architectural coverage (%)

Schematic: how completely the architecture answers each failure family. Nothing scores zero by design — an uncovered item was the trigger to build, not a known gap.

The inventory

Eleven ways to lose, none of which is a bad entry.

The list that drove the design is unglamorous and specific: inconsistent sizing, excessive concentration, emotional reaction to wins and losses, poor branch selection, bad exit behaviour, fee drag, incomplete records, premature strategy changes, uncontrolled compounding, failure to reduce risk during drawdown, and an inability to distinguish variance from deterioration. Not one of them is a claim that the trader picked the wrong trade. Every one has emptied accounts belonging to people who were selecting correctly, which is the observation the entire architecture is a response to.

Why the proportions look strange

The density follows the inventory, not the category.

Backward specification explains the architecture's most commented-on feature, which is how much of it concerns capital state and how little concerns entries. Four separate mechanisms govern sizing because sizing appears on the failure list in several forms. An entire simulation layer exists because distinguishing variance from deterioration is on the list and is genuinely hard. Meanwhile there is no signal generator, no setup scanner, and no entry optimiser — not because those would be difficult, but because no item on the inventory said the trades were being chosen badly. A forward-designed product would have built them anyway, because that is what the category contains.

The uncomfortable items

Two entries on the list are about the operator, and they still got machinery.

Emotional reaction and premature strategy change are the two items that a product could reasonably have declined to address, on the grounds that they are behavioural rather than technical. Backward specification does not permit that exit — an item on the failure list needs an answer regardless of whether it is convenient to answer. So emotional reaction was met with pre-commitment: a ladder that decides de-risking before the pressure exists, and a checklist that names revenge and impatience as hard-failure conditions in the same list as an unknown stop distance. Premature change was met with the research boundary and the promotion gauntlet. Both answers are structural because behavioural advice is not an answer.

What the method cannot do

A coverage map is only as good as its inventory.

The honest limitation is that backward design guarantees coverage of the enumerated failures and nothing else. A failure mode absent from the original list has no module answering it, and would not be noticed as missing — the architecture would appear complete because it covers everything it was asked to cover. This is the deep reason the system keeps an evidence loop and a promotion process rather than treating itself as finished: the inventory is a hypothesis about how accounts die, and the only correction mechanism is the operator's own accumulating record showing a leak the map did not predict.

  • The module density tracks the failure inventory, not what the category usually ships.
  • Behavioural failures got structural answers, because advice is not an answer.
  • Coverage is bounded by the inventory — which is why the evidence loop never closes.

The key idea

Ask what kills accounts, then build one answer each.

The method is almost aggressively unglamorous, and it produces a system whose shape is explicable line by line: this exists because that fails. It also produces the absences, which are as informative as the contents — nothing here helps anyone find a trade, because finding trades was never on the list of what was going wrong. A framework built forward would look more complete and cover less. This one looks lopsided and covers the things that were actually doing the damage.

Connected inside MARS

Every brief documents the same shipped system.

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