# Preserving Failure as a Product Requirement

**Public-candidate methodology note — review required**  
**Cross-trial development evidence; not security certification**

## The problem with a clean success story

Passing results are easy to present as if the system had always possessed the final architecture. That erases the most decision-relevant evidence: what failed, how the failure was classified, what changed, and whether the correction preserved earlier boundaries.

Across the governed application and routing work, failed runs were treated as product inputs rather than embarrassing debris.

## Failure has more than one source

A failed test can indicate:

1. a real behavioral or structural defect;
2. a boundary mismatch between the product contract and test environment;
3. an evaluator too brittle to recognize valid behavior;
4. missing promised evidence even when the scored behavior passes; or
5. an integration assumption that direct unit evidence cannot prove.

Those categories require different corrections. Changing the product to satisfy every assertion can be as misleading as weakening every assertion to obtain a pass.

## Three examples

### Structural failure changed the architecture

The first adversarial storage design passed only 7 of 35 structural and integrity attacks. Direct writes could bypass intended helper functions and create invalid states and authority relationships. The response was architectural: constrained transitions, database constraints, authenticated and append-only records, independently anchored exports, staged restore, owner-only storage, model verification, exact-field validation, and fail-closed migration.

The corrected reference corpus later passed the original 35 checks and additional structural, resilience, hostile-context, and continuity suites. The original 28 failures remain part of the record.

### A pass without promised evidence remained incomplete

A bounded structured-extraction trial scored 6/6, but the runner had not retained the raw synthetic evidence promised before the run. The score was preserved; it was not promoted into a complete evidence packet. After an evidence-retention correction, the unchanged confirmation again scored 6/6 with the promised record.

The behavior did not need to change. The evidence system did.

### Direct success did not prove integration

An automatic routing bridge passed its direct contract after a preserved timeout correction. Yet the application-level hook was not observed in a corrected cloud-impossible smoke. With discovery unproven, global activation remained blocked.

Direct contract success answered one question. It did not answer whether the host application actually invoked the component.

## The correction rule

For every material failure:

1. preserve the original fixture, output, scorer, and result;
2. classify the failure before changing anything;
3. state the violated contract or evidence obligation;
4. make the narrowest correction;
5. rerun the failed boundary;
6. rerun inherited regressions;
7. retain the original failure in the public-safe lineage; and
8. keep promotion blocked when the missing evidence remains missing.

## Evaluator repair is not product repair

The language-provenance work exposed evaluator defects that rejected semantically valid responses. Those assertions were broadened without weakening the intended behavior. Separately, an unwanted conversational follow-up was a real behavioral regression and required a request-time grounding correction.

Preserving the distinction prevents the test suite from becoming an unquestionable authority and prevents a flexible evaluator from excusing actual regressions.

## What this demonstrates

The inspected trials support a bounded methodology claim: Alex preserved behavioral, structural, evaluator, evidence-retention, environment, and integration failures; corrected them according to their source; reran inherited boundaries; and refused promotion when end-to-end evidence remained absent.

## What this does not demonstrate

Passing development suites do not establish production security, exhaustive coverage, independent validation, real-world adoption, or the absence of unknown defects. Failure preservation improves the truthfulness of the engineering record. It does not make that record complete.