Behind the builder / 30 September 2026
A candidate could speak. It still could not give itself authority.
R3.8.5 gained a locally tested implementation for isolating candidate output. The engineering work kept evaluation, instructions and promotion authority separate.
The handoff became tested code
The R3.8.5 work had moved from a handoff into a source-pinned local implementation for its selected scope. The stage was called Untrusted Candidate Output. Its purpose is easier to understand through the failure it tries to prevent: a candidate produces text, and another part of the system treats that text as if it were an authorised instruction.
The newer engineering result described real consumer guards rather than only a design intention. That was the material change to record on the thirtieth. There was an implementation to inspect, a test campaign and a reproducible packet.
The scope remained local. Native acceptance, independent review, remote deployment and stage certification were still separate gates.
A proposal is allowed to be interesting
Keeping candidate output untrusted does not mean refusing to read it. It means reading it without giving it a new role merely because it is fluent or persuasive. Evaluators need to examine candidates. Supervisors need to understand their claims. Neither should take orders from the thing being evaluated.
The selected implementation covered candidate ancestry, supervisor intake, evaluation and certification boundaries, exact-reply custody and persistence behaviour that fails closed. Those are places where an apparently harmless piece of text can acquire consequences if its origin becomes blurred.
The boundary keeps the candidate available for inspection while preserving who is allowed to decide what happens next.
The number needed its sentence
The final campaign recorded 1,074 passing tests with no failures or skips; the focused R3.8.5 set recorded 131 passes. Those numbers were worth preserving. So was the sentence that explains them: they supported the selected-scope local candidate.
A test count becomes misleading when it sheds the scope that gave it meaning. I want a later builder to know which predecessor was used, which code was tested, what the checks covered and what still needed acceptance. That is more useful than asking the largest number to carry the entire story.
The durable packet and reconstruction evidence helped make the engineering result recoverable.
The next handoff had a different job
A R3.8.6 Memory Architecture handoff was prepared. It described the next stage rather than claiming that the next stage had already been implemented. This kept the transition honest: a tested candidate on one side, a bounded starting point for the successor on the other.
The customer-facing constraint had not disappeared while the engineering advanced. There was still no new evidenced buyer commitment or revenue in the daily checkpoint.
The day’s useful achievement was a stronger boundary inside the machine. The candidate could contribute to the work without being allowed to appoint itself the authority over that work.