# A Signed AI Agent Receipt Can Still Be Wrong > Source: > Published: 2026-08-24 12:19:10+00:00 Your AI agent returns a signed receipt: 0 defects found. The signature is valid. The receipt has not been altered. The agent was authorized to run the check. The result can still be wrong. Perhaps the scanner hit a rate limit and silently converted eleven failures into eleven empty results. Perhaps a watchdog inspected 8 machines and issued a conclusion about 68. Perhaps a database health check ran `select 1` successfully while the application was failing because a required column did not exist. In every case, the software can produce a well-formed result. It can even sign that result correctly. What it cannot prove is that it measured the claim the business thinks it measured. That distinction is becoming one of the most important problems in agent infrastructure: ``` authentic receipt != adequate measurement authorized action != correct conclusion zero findings != complete inspection ``` Cryptographic signatures are valuable. They can prove who signed an object and whether its contents changed after signing. They do not prove: This is the difference between **provenance integrity** and **measurement integrity**. Provenance integrity asks: Who made this statement, and was the statement altered? Measurement integrity asks: What was actually observed, how much of the target was covered, and is the conclusion justified by that observation? An agent work protocol needs both. Otherwise, a signature can turn uncertainty into durable false confidence. This article grew out of a thoughtful [comment from Heinrich Neb](https://dev.to/heinrichneb/comment/3dema) on the first article in this series. He described three incidents from one week. First, a harvesting tool scanned 16 public repositories. Five returned hundreds of results. Eleven returned zero because the tool hit a rate limit and swallowed the exceptions. The output file was valid. The process exited successfully. A failure to observe became a factual claim that nothing existed. Second, a production watchdog sampled 8 machines from a fleet of 68, then reported its verdict as if it covered all 68. The sample may have been measured correctly. The population-level conclusion was still unsupported. Third, a database health endpoint returned success because `select 1` worked. At the same time, application screens were failing because a required column did not exist. The check was not false. It answered the wrong question. These are different systems, but the failure is the same: ``` php not observed -> zero partial observation -> full-population claim proxy check -> business conclusion ``` The problem is not simply bad code. Many systems have only two result states. If the answer is not `yes` , the implementation eventually pushes it toward `no` . Silence becomes a value. That is dangerous when the value controls a merge, deployment, payment, acceptance decision, or compliance report. There is a crucial difference between an `UNKNOWN` receipt and no receipt. No receipt can mean many things: Those states cannot safely be interpreted by a downstream system. A signed `UNKNOWN` is different. It is an explicit epistemic statement: A verification attempt occurred, but the available evidence does not justify VERIFIED or REFUTED. That statement can carry a reason code, a measurement record, a timestamp, a verifier identity, and a causal link to the work being checked. It can be audited. It can also block acceptance without pretending that counter-evidence exists. The protocol rule should be simple: Every completed verification attempt produces a signed verdict. No receipt means no attestable outcome exists. [OpenWorkProof v0.5](https://dev.to/dengyier/verifying-the-verifier-how-an-independent-audit-hardened-openworkproof-v05-5a54) already treats `UNKNOWN` as a signed, first-class verification decision. Its verdict is three-valued: ``` VERIFIED REFUTED UNKNOWN ``` The verification logic can derive `UNKNOWN` when evidence is incomplete or unsuitable for the requested conclusion. Current examples include population drift, unavailable population evidence, control mismatch, unavailable control evidence, and insufficient verifier independence. That is useful, but Heinrich's examples reveal a gap that should not be hidden. The current protocol can sign the statement: The evidence available is insufficient for this claim. It does not yet provide one general measurement-status field that cleanly separates every operational cause, such as: ``` measurement_status: - measured - not_run - not_measurable - interrupted - incomplete verdict: - VERIFIED - REFUTED - UNKNOWN ``` These fields should remain separate. A check may be fully measured and still return `UNKNOWN` because the evidence is inconclusive. Another check may be incomplete because only 8 of 68 targets were observed. A third may never have run. Collapsing those cases makes diagnosis harder and creates opportunities for downstream systems to interpret absence as success. This split is a design proposal, not a claim about what the current release already implements. A useful verification receipt should not contain only a verdict. It should bind the basis of the verdict. At minimum, that means recording: Consider the 8-of-68 example. This can be a truthful receipt: Eight targets were measured under sampling rule S. No failure was found in those eight targets. This is a different claim: All 68 targets are healthy. The second conclusion is valid only if the verification contract explicitly permits that inference and the sampling method satisfies its conditions. A signed result must not blur the two. The same issue applies to verification systems themselves. A large green test count proves that the registered tests passed in the recorded environment. It does not prove that the suite is representative. It does not prove that each guard would reject a realistic bad input. It does not prove that the benchmark supports the business claim being made. So raw test count is not enough. Verification infrastructure should also report **falsifiability coverage**: OpenWorkProof already uses reason-bound negative controls in parts of its verification-integrity path. A mutation does not count as a successful control merely because something failed. The observed failure must match the registered failure semantics. But this is a direction, not a victory declaration. Test count and falsifiability coverage should be reported separately. Companies do not buy signatures because signatures are elegant. They care about avoiding expensive false green states: The commercial value of verifiable agent work is not "more cryptography." It is a lower cost of delegation without turning uncertainty into a certificate. This is also why human final authority depends on honest machine uncertainty. A person cannot make a meaningful acceptance decision if the evidence surface hides the difference between `nothing found` and `nothing measured` . Human control is not preserved merely because a person clicks the final button. It is preserved when the system tells that person the truth about what it knows, what it does not know, and what it never observed. The first two articles in this series argued that autonomous agents need verifiable human authority and that people should retain the final say at consequential boundaries. This discussion adds a necessary condition: The human's final say is meaningful only when uncertainty is a first-class, signed state. OpenWorkProof is open source, and this measurement-status split is now a concrete design question for its next evolution. If you build agent runtimes, evaluation systems, MCP servers, or automated delivery pipelines, I would value your view on two questions: `UNKNOWN` always be a signed outcome for every completed verification attempt?[Explore OpenWorkProof on GitHub](https://github.com/dengyier/OpenWorkProof)