Six problems, six answers — and the map is not one-to-one.

Why traceability is the test

A problem list without owners is marketing; with owners it is a specification.

Any trading product can enumerate the failures it addresses, because enumerating failures costs nothing and flatters the reader who recognises themselves. The claim only becomes checkable when each item names the surface that answers it, because a named surface can be opened and inspected. If the module does not compute what the problem requires, the row is false and visibly so. That is why the six problems are published alongside the six governing questions and the six owning modules rather than as a list on its own — the mapping is the part that can be falsified.

The clean rows

Three problems resolve to exactly one surface, and resolve completely.

Emotional deployment terminates at the Throttle Control Panel, which issues the authorised gate row, the maximum tier, the selected tier, the authorised cycle pool, and the final operating directive. Drawdown treated as a single number terminates at the gate and brake architecture, which converts distance from the rolling Equity Peak High into a capital state. Open exposure terminates at the Cycle Command Console, which separates original risk, active risk, floating profit, and remaining pool capacity. In each case one surface both defines the problem's measurement and issues its verdict, and no second module is required for the answer to be complete.

The first collision

Two problems share the expectancy machinery, and that is structural.

Profit confused with edge and branch blindness are listed separately, but both are answered inside the same expectancy layer — the Weekly Scorecard blending branch EV by the live weight profile, sitting on CP3's EV logic. They are separate problems because they fail differently: one is a reasoning error about a single result, the other is an aggregation error hiding four different jobs inside one average. They share an owner because both are questions about expectancy, one at the account level and one at the branch level. The shared owner is a consequence of the metric, not a duplication in the list.

The second collision

One problem needs two modules, and neither is sufficient alone.

Distinguishing variance from structural decay is the only row with two owners, and the pairing is deliberate. The Structural Diagnostic Engine reads the operation against its own history through the six-table pipeline — Structural Truth, Rolling Condition, Stability, Drift, Z-Score, Interpretation — and answers whether the machine is strengthening or degrading relative to itself. The Monte Carlo benchmark supplies the external reference the internal record cannot: whether the current stretch sits inside the distribution the branch mix should produce. Internal trajectory without an external envelope, or an envelope without a trajectory, each leaves the question half-answered.

• Three rows resolve to a single surface and need no second module.
• The expectancy collision is one metric answering at two levels of aggregation.
• Variance-versus-decay is the only row that genuinely requires two owners.

Reading the map in reverse

Running it backwards is the harder test, and it is the one that matters.

Forward traceability — every problem has an owner — is relatively easy to satisfy, because a list can be written after the modules exist. The demanding direction is backwards: does every module answer a problem on the list? Most do not, and should not. The Volatility Intelligence Panel, the MAE/MFE Lab, the Regime Classification Engine and the research sandbox are not on the six-problem map at all, because they answer questions the six do not raise. The six are the failures that destroy workable methods; the rest of the architecture exists to explain, refine and protect what survives them. A list that claimed every module answered a named problem would be the more impressive document and the less credible one.

The key idea

The collisions are the evidence that the list was not reverse-engineered.

A problem list built to flatter an existing product tends to resolve too neatly, because it is written module by module. This one does not: two rows share machinery and one needs two surfaces, and those irregularities are exactly what a list derived from real failures looks like once it is mapped onto real architecture. The map is worth checking rather than accepting, and the fastest way to check it is to open a named surface and ask whether it computes what the row claims. That check is available on day one, and it either holds or it does not.