Proof · Case study
OTR Select, in chapters
Greenfield Production Systems built OTR Select on Factory v1, operated it after launch under a managed agreement, and later verified the estate around it with Factory v3. Each chapter below ends at its boundary; every number sits beside the artifact that backs it, and findings keep their epistemic tags. Nothing here has been promoted for the sake of the page.
Chapter 1 · Build
Six weeks from spec to production
OTR needed a production platform built around the OTR Select profile, its data asset. The Greenfield Production System delivered it in six weeks. We don't publish a speed multiplier; the delivery record is below, and the math against your own baseline is yours to do.
Provenance
Built on Factory v1: every line AI-written, with an architect reviewing at stations that are now automated gates.
The delivery record
| Week | Phase | Delivered |
|---|---|---|
| 1 | Discovery | Domain model, service boundaries, first architecture decision records |
| 2 | Architecture and specification | Journey, API, and view specs drafted; ADRs reviewed and accepted |
| 3 | Implementation | Core services through the gate pipeline |
| 4 | Implementation | Remaining endpoints and views; the test suite growing alongside |
| 5 | Integration | End-to-end journeys assembled and run against the integrated system |
| 6 | Quality review | Final gate runs, staging deployment, handoff and walkthrough |
The spec inventory
Proven An artifact is on disk or a test ran green.These documents were the deliverable; the code is their consequence. A new engineer can read the specs and understand the system without a walkthrough.
- Journey specs
- 19 The user-facing flows, specified before implementation
- API specs
- 26 One per endpoint
- View specs
- 7 The frontend surfaces
- Architecture decision records
- ADRs Each with its rationale and the alternatives considered
The suite shipped with the system: 536 test files, a 20:1 ratio of test files to API endpoints. Coverage was a gate in the pipeline, not a metric tracked after the fact.
Between the chapters, OTR Select ran in production under a managed operating agreement. The next engagement wasn't a build at all.
Chapter 2 · Verify
The estate, read by a separate machine
OTR later put its production estate through the verification factory, Factory v3: 15 targets, including our own prior work. The verifier is read-only by construction; it never modifies the system it inspects, and the factory that builds is never the one that signs off.
- 15
- Targets read across the production estate
- 1,485
- Generated regression tests, delivered into OTR's QA repository
- 23/24
- Generated specs green against staging, first run
The suites landed in OTR's own QA repository, in OTR's idiom: their naming conventions, their page-object structure, their helpers. Not a vendor sandbox.
The staging run
Proven An artifact is on disk or a test ran green.On OTR Connect, 23 of 24 generated specs passed against staging on the first run, with real Auth0 logins. The one failure was a timing flake, not a behavioral miss.
That flake earned its keep. It produced two permanent fixes: a flake lint that now runs on every generated suite, and a learned status correction. The factory keeps what it learns.
The enforcement matrix
The matrix crosses every frontend rule against every backend guard. The finding class that matters is the one-sided cell: rules the frontend promises that the backend doesn't enforce. Each finding ships as a probe candidate with the exact API call that settles it, because a rule traced in source isn't a defect until a live system says so.
The matrix format, with all three cell classes, is shown in the catalog and enforcement-matrix sample (view the artifact) .
Finding excerpt, redacted
serverless-████-service/███Form.tsx:59Path partially redacted. Probe candidate Needs a live environment to settle. Never presented as a confirmed defect. A required-field rule the form enforces with no matching guard on the write path. The probe that settles it: the API call that submits the field empty.
The independence result
Traced in source Read from code, not yet run against a live system.Permutation testing across an estate's configuration axes explodes fast unless you can show which axes don't interact. The analysis examined 21 axis pairings and found 3 coupled, each coupling cited to the licensing guard that creates it. Independence isn't assumed here; it's read from the guards.
The arc
What this client experienced
In order: a build, then managed operation, then verification of the whole estate. Each engagement left artifacts the next one could check.