Two verifiers or no decision: the fix for agents that grade their own test runs

An agent that reports its own green test run has handed you a signature on a story, not an execution of it ^[2][3]. OpenWorkProof v0.5, described by its author in a dev.to post, tries to close that gap by refusing to form a high-risk decision unless two independent verifiers have each executed the work, each signed their own result, and their conclusion-bearing fields agree field by field ^[1].

The independence is structural rather than declared. Profile construction enforces two distinct verifier bindings with different keys, different subjects, different controllers and different execution contexts ^[4]. Each verifier must cover every arm - positive arm, negative controls, population observations, scope evidence - and a split where one does the positive arm and the other does the negative is rejected as split coverage ^[5]. That rule costs more than it looks like it should, and it is the point: dividing the work between reviewers halves the number of independent executions of the claim you actually care about.

The more useful part of the writeup is what the project got wrong first. The naive design compared the evidence snapshot digests the two verifiers cited ^[7]. But evidence refs are self-signed metadata, so a lying verifier could copy the honest verifier's refs verbatim and flip expectation_status: pointer matches, conclusion does not ^[7]. The fix is to compare every field that carries a conclusion - expectation_status, execution_status, mutation_status, reason_codes, action_receipt_ids, observed member count, population digest, required target ids, scope_expectation_status, population and control observations, and the evidence snapshot digest ^[6]. A fabricated exit code then produces different conclusion fields from the honest run, which is divergence, which is no decision ^[8].

Two adjacent cheats are closed elsewhere. A verifier citing its own older passing run to bury a newer failing one is stopped at commit, where the stale gate requires the referenced set to equal exactly what prepare would load, newest per (arm, verifier) ^[9]. A verifier that signs but never produces results cannot convert a single-verifier UNKNOWN into VERIFIED ^[10]. Decisions reference the full dual set, and commit, chain replay and the offline delivery package all recompose from those references, so an appended later run cannot retroactively break a committed decision ^[11]. Each hole was demonstrated by an adversarial probe first, then fixed, then re-attacked: a specification reviewer and a quality/security reviewer, separate agents, ran seven rounds each ^[13], across 29 commits in three phases ^[17].

The limits are stated plainly in the post. Divergence currently produces no decision at all, a combination failure, because the frozen v0.5 decision model holds only one reference per arm; a formal DUAL_VERIFIER_DIVERGENCE state is deferred to v0.6 ^[12]. According to the author, the work proves the protocol requires dual-verifier convergence, not that any real delivery went through dual verification, that verifiers are honest, or that no collusion occurred; the trust model assumes at least one honest verifier ^[15]. Customer adoption, paid work and upstream adoption are all recorded as not_evidenced ^[16].

There is a recursion here worth naming. The closing figure, a required-live full gate at 3543 passed, 0 failed, 0 skipped ^[14], is itself reported by the party whose whole argument is that self-reported results are signatures rather than evidence ^[19]. The partial answer is reproducibility: the post supplies clone, install and bundle-verification steps against a checked-in delivery package, and invites the reader to change one byte and watch it fail ^[18].

Worth watching: whether v0.6 turns divergence into an on-ledger state ^[12], because "no decision formed" and "two runs disagreed" are different operational facts, and whether anyone outside the project runs the bundle verification ^[18].