On July 16 the production stack tried to produce the first live production-stack bundle evaluated VALID under the identified v1.3-track evaluator — and the separately executable evaluator rejected its makers' work twice, by named rule and entry index, before accepting the third attempt: VALID_RECORD=true, all nine conditions, independently timestamped by an RFC 3161 authority, establishing the accepted record's existence no later than the token time, on a second machine, cold. A tested one-byte mutation, byte 4000 of the witness, caused conditions R1 and R2 to fail and the evaluator to return INVALID; additional invalid vectors exercise the other stated conditions. This is the record of the refusals and of the yes they purchased.
Every prior record in this archive was verified by machinery that shared a roof with the tools being verified. Trial 0's second movement demanded more: a live run of the production stack — the desktop supervisor driving the orchestration engine driving a real AI executor — whose exported record a separate program, gad-evaluate, would judge on another computer with no access to the producer's software, state, or secrets.
The final evaluation, computed cold on a Linux machine from a record produced on Windows:
The yes is the headline. The refusals are the proof. Three earlier attempts that day produced, in order: no record at all (the plans never armed the protocol layer — four governed runs, chained and complete, and structurally silent); a record rejected seven times over on one rule (verdicts recorded inside later sessions, after their nodes had been re-dispatched — the evaluator's transition table demands verification happen between sessions, in nobody's session, and the product had no such caller); and a record invalidated by its own operator's mouse click (a relaunch after the terminal sealed — legal-looking in the UI, illegal in the record, and correctly fatal).
Each rejection changed something permanent. The first produced a three-layer identity rule: before any record-producing run, prove the plan, the engine, and the supervisor are the ones you think they are. The second forced the product to grow the between-sessions verifier the specification always implied — the evaluator, in effect, filed a feature request and made it non-negotiable. The third was ruled a product defect on the spot, in the operator's words: a completed run must be inert. The guard is queued; the click that found it is preserved in this archive, attributed to the advisor who recommended it.
A verification regime you built cannot impress you by approving you. It can only impress you by refusing you until you deserve it — and showing its arithmetic both times.
0 freeze the frozen plan's hash and canonical bytes: recorded precedence 1 dispatch [m2-01, m2-02] session 1 commissioned over the node set, before the executor exists 2 executor_exit completed the session ends cleanly; node null: a multi-node session names no single owner 3 execution_result the engine's capture of what the session left 4-10 probe (7) the negative evidence, recorded as artifacts: each check's planted-defect probe 11-17 verdict m2-01 pass (7) recorded BETWEEN sessions by the supervisor's verifier, over the captured delta 18 dispatch [m2-01, m2-02] session 2; m2-01's verdicts all precede this line, which is the entire point 19 executor_exit completed 20 execution_result the second session's capture: one authored file, inside its fence 21-23 probe (3) 24-26 verdict m2-02 pass (3) the final node's verdicts, again in nobody's session 27 plan_completed the terminal, DEFERRED until the last session record closed 28 checkpoint post-terminal bookkeeping, one of exactly two entry types allowed after a seal
The content the record attests is itself the project's governance: node one re-proved the entire sealed succession lineage of field record No. 5 inside the witness; node two authored the Movement 2 note whose every figure was computed live — the lineage verifier's own final line quoted verbatim, the v0.9 digest read from the signed succession record, never retyped.
The evaluator needs the bundle, the policy, and public keys. It does not need the producing machine, the supervisor, the engine, this institute, or anyone's goodwill.
VALID is not DEFENSIBLE. Under the strictest policy overlay, this record computes DEFENSIBLE=false: the overlay wants an authority-signed anchor, and the record carries a timestamp authority's token — a claim about when, not about who stands behind it. That gap is an open ruling in the project's register, stated here rather than rounded up. And per the specification's own header, every result in this record is a Proposition or Claim until independent formal and cryptographic review completes. One more honest edge: both of this record's sessions were multi-node; the single-node session tier is demonstrated in the engine's conformance harness, not yet in a live record.
It proves: the full production stack can produce a record that a separately executable evaluator accepts, on a different machine and operating system, for stated reasons, with tamper-evidence demonstrated by construction and by experiment; that the record's timeline is anchored to a public authority's clock; and that the same evaluator rejects this same stack's work when the choreography is wrong — by rule name and entry index, twice, on the same day.
It does not prove: that the work inside the record is good (the record proves the checks ran and passed; the checks' worth is a human judgment); that the stack is conformant in general: the named v1.3-track evaluator returned VALID for this exact bundle under the identified inputs, a historical computation that remains attributable and reproducible, and broader tooling conformance is not inferred from it; or that the evaluator itself is correct (that is Phase 5's question, for reviewers who owe this project nothing).