Testing from the outside: why the QA module refuses to trust the formulas.

The method

Visible inputs, visible outputs, no assumptions about the middle.

Black-box testing means driving the target workbook with controlled inputs and comparing what comes out against what should have come out — without inspecting the internal formulas at all. The manual's stated reason is precise: it prevents a false sense of security from formulas that calculate but produce incorrect results. Reading a formula tells you what it does; it does not tell you whether what it does is what the specification required. Only a comparison against an independently stated expectation can establish that, which is why the expectation has to exist before the test runs.

The purpose

Moving the system from built to provable.

The operating doctrine states the workbook's role in five words: from built to provable. This is not a distinction most retail trading systems ever draw, because most are never expected to be anything more than built — they work until they visibly don't. A system whose outputs govern capital deployment is held to a different standard, and the QA module is the mechanism by which the claim 'this workbook behaves correctly' becomes something demonstrated under controlled scenarios rather than something believed because nothing has gone obviously wrong.

The spine

Eight stages from matrix to readiness.

The QA workflow runs a fixed sequence: the Test Matrix defines which scenario and timeframe combinations are structurally valid and what they can prove; the Scenario Library stores reusable scenario records with stable IDs; Expected Outputs defines the contract for what each output should do under each scenario; Test Runs records each formal pass against a specific workbook version; the CHK tabs compare expected against actual; the Error Register stores failures and determines whether advancement is blocked; the Retest Log proves repairs actually worked; and Master Control summarizes readiness. Each stage consumes the one before it.

The expectation comes first

Writing the contract before the test is what makes the test meaningful.

The Expected Outputs tab is the methodological heart of the whole apparatus, because it forces the specification to be stated before the answer is visible. A test whose expectation is formed after seeing the output is not a test — whatever the workbook produced will look approximately reasonable, and the operator will find a way to accept it. Declaring in advance what a given scenario should produce is uncomfortable precisely because it creates the possibility of being wrong, which is the only condition under which passing means anything.

The certification question

One question, asked five ways.

The workbook's institutional question is stated as a single sentence covering five dimensions: given a controlled scenario, does the target produce the expected behavior, the expected value, the correct maturity state, the correct source-of-truth routing, and the correct visual or output state? The inclusion of source-of-truth routing is notable — it means QA checks not only whether a number is right but whether it came from the module that was supposed to produce it. A correct value arriving through the wrong path is a finding, because next month the wrong path may produce a different value.

• Behavior and value are distinct: a cell can hold the right number and respond wrongly to a changed input.
• Maturity state catches outputs that display before they should be trusted.
• Routing catches a correct number that arrived from the wrong source — a latent defect.

Readiness is computed, not declared

The logs decide whether the system is ready, and no one overrides them.

The updated doctrine is explicit that Master Control readiness is the downstream result of the logs being clean, not a manual opinion. The Error Register preserves the defect history and determines whether advancement is blocked; the Retest Log proves whether a fix actually worked before an error may be closed. An operator cannot mark the system ready because it feels ready, and cannot close a defect because the repair looked correct — the retest has to demonstrate it. This is the same structural move the rest of MARS makes everywhere: replace a judgment made under pressure with a computed consequence of recorded evidence.