Rincon Photonics

Rincon Photonics is the largest synthetic specification the method has been run on: an enterprise-scale system with physics held behind contracted seams, written to test whether governance survives size.

The specification covers the control software for a free-space optical communications terminal whose bench hardware is a year away: two systems, the optical link terminal and its management and operations layer, twelve subsystems between them, each defined as an interface contract with its own state machine, fault set and performance bounds. The physics is held behind seams: application code may not reach below the hardware abstraction, and physical parameters enter only through a versioned ingestion contract that records where each value came from and how much to trust it. It is an enterprise-scale document, three hundred and sixty-one requirements, and it was written to find out whether a specification that large can still be governed line by line.

Every requirement traces to its source and carries a criterion. The phase plan, the build tasks and the gates were all derived from it, which is the point: when the specification is the contract, everything downstream is checkable against it.

The build ran in six phases against a pinned manifest of criteria that grew with it, to 549 by the end. Phase three delivered the bulk of the terminal: 106 of 107 tasks, the one left open needing hardware that does not exist yet. Phase four delivered its twenty-seven tasks and eleven requirements. Phases five and six, run together, delivered fifty-nine of sixty tasks across twenty-nine requirements, the last waiting on a ruling about fog tolerance.

Before the final phases began, eleven decisions were put to the specification’s owner and ratified as one ruling: eight places where generated documents had given the same quantity two values, and forty-eight parameters the generator had produced that the specification never stated. The specification’s operating range won over the generated one. That is the method working as intended: the questions were raised before the build, not discovered inside it.

By the end the test suite had grown from 1,162 tests to 2,693, and the rulings log to 305 entries. Every close was recorded by the specification’s owner under one rule: one gate, one remediation pass, one re-gate, then a ruling.

This is the build where the gates earned their keep. Phase three’s first gate rejected on a single blocker, a timing test that failed once in 1,077 runs under load. The re-gate graded more strictly and the score went down, from 87 of 107 to 132 of 163, because twenty-one requirements that had passed were now found partial: older gaps exposed, not new ones made. Phase four was sent back once for a contract mismatch and accepted the second time, eleven of eleven. The cleanup of everything through phase three was graded against 379 pinned criteria and closed at 364 satisfied, by ruling, after one remediation. Phases five and six were graded against 428, closed at 403 satisfied plus seventy-one of seventy-four on the re-gate, with twelve criteria closed by ratified ruling rather than another gate.

Then a blind review of the specification against the code, by a reviewer who had not seen the build, found 161 findings of which 61 were real. Three remediation slices fixed forty-eight of them. The first found that the state-machine transition table had been copied by hand into three places that disagreed, and that the conformance check was comparing the code against its own copy; the fix generates one table. The second put the sensor fusion and feed-forward on the real control loop instead of a simulated variable. The third covered the harness testing the product rather than itself, the steering interface, TLS, the API surface and a 549-case walk of the access rules.

A second blind review, against the same 361 requirements, found nineteen findings that were real and unrecorded. The owner ruled on all nineteen before a line changed: one reversal of an earlier deferral, two contract changes, sixteen fixes. The fourth slice built them, and its gate rejected, on timing tests that fail under load in a copy without its version history; re-run cleanly, 2,688 tests passed twice. Three criteria were genuinely unsatisfied and were fixed in one pass; a scoped re-verification came back twenty of twenty-two, the two remaining being older clauses the slice had brought into scope. The owner ratified one and had the other built as an addendum, and closed the slice: accepted after remediation, the review register at zero open.

What is still owed is stated plainly. Everything that needs a physical terminal: acceptance runs, the hardware-in-the-loop rig, thermal and power bench work, a real network port. Every physics parameter is a stand-in or an estimate. With no steering hardware bound, the shipped build fails commissioning and every update rolls back, by design. A handful of things are recorded and deliberately not fixed because no criterion requires them. The record says all of this, which is the point of keeping one.