How This Lab Stays Rigorous

Eight standing rules, each one distilled from a real error this lab actually made and caught. Not aspirational — every rule below exists because its absence produced a real mistake somewhere on this site.

1. Boundary Verification

Don't test whether a guarantee holds in typical cases — deliberately find or construct the hardest realistic case where it would be most likely to break, and verify it holds there specifically. A guarantee only tested against average-case pressure hasn't been tested yet, in the sense that matters.

Applied in: the Evaluation Package's strong-alternative baseline (capability tokens), chosen specifically because it's harder to beat than a naive comparison.

2. Same-Party Disclosure

Any evaluation document must state plainly, on its first page, who built the thing under test, who built the comparison points, and who ran the evaluation. If all three are the same party, that's stated up front — never buried in a limitations section a reader has to go looking for.

Applied in: the Evaluation Package's stated limitation #1.

3. Attribution Separation

Original computed findings and cited external findings live in structurally separate fields, never sharing a label that could be misread as attribution to someone else's published numbers.

4. Execution-Required Verification

A description of a result is not the result. No claim about what code does is treated as established until it's actually been run, with the literal output shown — not summarized, not narrated.

Applied in: every code block on the Component A Changelog and Infrastructure pages is real, run output, not description.

5. Polish Is Not Evidence

A result that's unusually uniform, round, or free of any partial failure is worth more scrutiny, not less. Genuine results tend to be irregular — the real Boston Housing test included a 0% accuracy category; fabricated results tend toward suspicious cleanliness.

Applied in: the Boston Housing backtest keeps its Luxury-regime failure in the published result rather than smoothing it out.

6. Deterministic-vs-Statistical Precision

Before stating a conclusion, classify it as one of three kinds: statistically observed with a confidence bound, structurally/logically guaranteed by the mechanism itself, or empirically undefeated across all known extreme cases (not proven, but with no counterexample at the limit). Don't let language drift between these — they warrant different confidence and different caveats.

Applied in: the Evaluation Package's statistical section — "supports a true breach rate below 0.074%," not "impossible."

7. Staleness Tracking

A claim's "verified" status is tracked against a specific, named set of invariants, not a bare yes/no. When a new invariant is discovered — an attack found on one component, a new competitor tested, anything — any claim not yet re-checked against the expanded set shows as stale, not silently still marked done. This isn't the same as a claim's truth degrading; it's the definition of "verified" itself growing, which requires the same re-audit discipline as any other expansion.

Applied in: ncfca_lib's known gaps — Claims 2, 3, 6, 7 marked stale against the value-provenance invariant discovered during the Claim 1 fix.

8. Cross-System Heuristic Transfer

A diagnostic heuristic calibrated on one kind of system, with a known or assumed causal mechanism, can produce an identical-looking surface signal on a structurally different system through a completely different route. When that happens, treat the pattern-match itself as real data — but treat the causal interpretation as a separate, unresolved question. Recognizing a pattern doesn't automatically import the original system's explanation for why the pattern occurs. This is a more specific case than rule 6: it's not about how confident to be in a claim, it's about whether a claim earned on one kind of system is even the right kind of claim to make about a different one.

A note on this page's own history

This section previously stated a different rule 8 — "Mandatory Artifact Consultation" — which does not appear in the actual source document (VERIFICATION_METHODOLOGY_PROTOCOLS.md). That document's real rule 8 is the one now shown above. The previous version of this page was built in a session with incomplete visibility into its own prior turns, and the mismatch was only caught once the real source file was directly re-read. Left here rather than quietly corrected, because a page about verification discipline silently fixing its own unverified content is exactly the failure this page exists to name.

What this page is not

This is a description of working method, not a claim to institutional standing. Nothing here has been externally peer-reviewed. These rules have caught real errors inside this project — that's the actual, bounded claim being made.