Certification: what it means for a workbook to be trusted.

What certification asserts

A bounded claim, not a general endorsement.

The certification question the workbook answers is precise: given a controlled scenario, does the target workbook produce the expected behavior, expected value, correct maturity state, correct source-of-truth routing, and correct visual output state? Five properties, one scenario at a time, against one workbook version. What certification therefore means is bounded in three directions — this version, these approved scenarios, these checked outputs — and it says nothing about untested scenarios or subsequent versions. That boundedness isn't a weakness of the claim; it's what makes it worth anything. An unbounded assertion that a workbook 'works' is unfalsifiable and therefore uninformative.

Scenario approval

Invalid scenarios can't become certification evidence.

Before a scenario can prove anything, the Test Matrix determines whether that timeframe-and-scenario combination is structurally valid, limited, an edge case, or not approved — and the approval status propagates into the expected-output contracts as an inherited field. The purpose is stated directly: to prevent invalid scenarios from becoming formal certification evidence. It's a guard against a subtle corruption where a workbook accumulates passes on tests that couldn't have failed — a one-week scenario 'proving' annual rollup behavior, for instance. Eligibility first, evidence second: the same ordering the whole system applies to sample gates and maturity rules.

Readiness versus certification

Two related states with different meanings.

Master Control's readiness flag answers whether the system can advance right now — computed from blocking error counts, latest retest statuses, and scenario validity. Certification is the stronger, more durable claim that a specific version passed a formal run. Readiness can flip in an afternoon when a blocking error is registered; certification is a historical fact about a version that remains true even after that version is superseded. The practical relationship: readiness gates whether new work proceeds, certification records what was proven about what already shipped, and both derive from the same logs rather than from anyone's assessment.

• Blocking errors are the readiness lever — one open blocker is enough, regardless of how many checks passed.
• A version bump invalidates certification for the new version by definition. Fresh version, fresh run.
• Warnings and Needs Review states carry certification weight too: unresolved ambiguity is not a pass.

Why this matters here

The workbooks govern capital, so their correctness is a risk control.

In most contexts a spreadsheet defect is an inconvenience. In MARS, the workbooks compute gate states, tier authorizations, pool budgets, and expectancy verdicts — a wrong rollup doesn't produce a wrong report, it produces a wrong deployment. That's why the QA layer is a governed certification process rather than casual inspection, and why the doctrine insists the QA workbook itself be audited: the dropdown-output audit tab exists to verify the cockpit is properly controlled before it certifies anything else. A testing instrument that hasn't been tested is just another untested workbook with opinions about the others.

The key idea

Trust is a claim with scope, evidence, and an expiry.

The certification model closes the Diagnostics category on the same note the whole system runs on: nothing is trusted because it looks right. It's trusted because a specific version, under approved scenarios, produced expected behavior with no blocking errors open — and that trust ends the moment any of those bounds change. Provable rather than merely built, bounded rather than assumed, and re-earned rather than inherited. That's what it means for a workbook to be believed here.