Glossary

The catalog is the single source of truth the factory projects from: test skeletons, documentation, and parity assertions all derive from it deterministically, with the LLM filling only the irreducible parts under gate enforcement. Every catalog ships with an explicit boundary stating what was read and what wasn't, because absence of a finding is only a claim inside the boundary. When a system is rebuilt, the approved catalog becomes the contractual definition of parity. An excerpt is published at /proof/catalog.

Deterministic gates are scripts: a compile, a grep, a test run. LLM-judged gates score work against a rubric that is fixed before the run, with a fixed pass threshold, and a low score blocks the line the same way a failing compile does. Gate names are public and appear in transcripts; prompts and orchestration internals don't.

A transcript records the gate name, its kind, the result, and what happened on failure, including the resubmission that fixed it. Failures stay in the log; a transcript with no red entries would read as theater, and the fix loop carries most of the information. An annotated sample is published at /proof/transcript.

Order matters. The suite derives from an approved behavior catalog and must first run green against the original system, proving it tests reality before it judges anything new; only then does a green run on the rebuild mean parity. Dual-green is the acceptance standard for rebuild engagements: parity becomes a test result against criteria the client approved rather than a promise.

Where dual-green runs a projected test suite on both systems, parity replay re-runs what actually happened: recorded operations, executed against the new system, with every result diffed against the original's. Its proven scope today is internal; it's how our own platform moved between factory generations (see the changelog, v3).

The tiering is the point. Flat coverage tools inflate the browser-test number; routing each uncovered behavior to the cheapest test level that actually exercises it (unit, integration, or end-to-end) keeps the backlog honest and reserves e2e for the behaviors that need it. A coverage-debt report is a standard deliverable of a verification engagement.

Probe candidate is one of three epistemic tags the factory applies to its own claims: proven (an artifact is on disk or a test ran green), traced in source (read from code, not yet run), and probe candidate (needs a live environment to settle). Each probe candidate ships with the exact API call that settles it, and it stays a candidate until that call has run. The tags appear wherever findings or capabilities are described on this site.

Proven An artifact is on disk or a test ran green. Traced in source Read from code, not yet run against a live system. Probe candidate Needs a live environment to settle. Never presented as a confirmed defect.

Each cell falls into one of three classes: both-layers, the control group where frontend and backend agree; UI-only, the finding class, rules the frontend promises that the backend doesn't enforce; and backend-only, the inverse, where the server refuses what the interface lets you click. A sample matrix is published at /proof/catalog.

v1 built a production platform with an architect reviewing at stations that are now automated gates; v2 ported Bugzilla end to end without those reviews; v3 added catalog-driven verification and turned it on our own prior work. The changelog records each generation with its receipts.