Eligibility → scenarios → runs → verdict: the eight-stage QA spine.

The spine

Three phases, eight stages, one direction.

The architecture principle states it compactly: the front end of QA is scenario governance, the middle layer is expected-output comparison, and the back end is failure control, retest proof, and readiness certification. Stages one through three establish what may be tested and what the test means — eligibility from the test matrix, a stable scenario identity from the library, and an expected-output contract. Stages four and five perform the audit: a formal run is logged against a specific workbook version, and the CHK tabs compare expected behaviour to actual. Stages six through eight govern the consequences — failures are registered, repairs are proven by retest, and Master Control reports whether advancement is safe.

Why eligibility comes first

Not every scenario and timeframe combination can prove anything.

The test matrix exists because a test that is structurally incapable of proving what it claims is worse than no test — it produces a pass that means nothing and is recorded as though it meant something. The matrix defines which timeframe and scenario combinations are valid, limited, edge-case, or not approved, along with what each can prove and how deep an interpretation it supports. A one-week scenario cannot certify quarterly structural behaviour no matter how cleanly it runs, and the eligibility stage is where that is settled — before anyone has invested effort in the run and before a result exists to be argued about.

The identity discipline

Scenario IDs are audit identity, and they are never repurposed.

Stage two produces a stable Scenario ID that every downstream stage joins on — expected outputs, test runs, error register, retest log, master control, and the CHK tabs all reference it. This makes the ID load-bearing in a way that is easy to underestimate. Repurposing an existing Scenario ID for a different scenario retroactively changes the meaning of every historical record that references it: old errors now appear to have been discovered under conditions that never applied to them, and the audit trail becomes actively misleading rather than merely incomplete. The rule is to create a new instance under the same Scenario Family ID instead, which is exactly what the instance counter exists for.

• The Matrix ID is the archetype; the Scenario ID is the specific record. Confusing them collapses the hierarchy.
• A repurposed ID corrupts history silently — nothing errors, and every prior reference now points at the wrong thing.
• Variants are cheap. The instance counter exists so that creating one is never harder than reusing one.

Why Master Control is last and lean

The command surface summarises a finished chain; it does not hold the detail.

Master Control reports the current state, the selected run, blocking errors, readiness, scenario approval, and next action — and deliberately stores none of the underlying detail. It reads lifecycle state from the stages beneath it. This is the same build-order discipline the Contradiction Engine follows in wiring its control panel last: a summary layer built before the thing it summarises tends to get designed around what would look reassuring, and the calculation layer then gets shaped to produce it. Built last, Master Control reports what the chain actually found, including the inconvenient conclusion that advancement is blocked.

The key idea

The order is the argument, and running it out of sequence dissolves it.

Each stage's output is the next stage's input, so a shortcut does not merely skip a step — it removes the constraint that made the following step meaningful. Inspecting before a contract exists means comparing behaviour to expectation formed after the fact. Certifying before retest means certifying a repair nobody proved. The spine is not a checklist of good practices; it is a dependency chain.