One number, checkable on its own.

The claim

Recompute it yourself

node proof.mjs verify proof-battery.json battery-run.log

The verifier does not read the total from the object. It re-derives the value from the log by the stated method and compares. An object whose stated value does not match its own recomputation fails, which is the entire point of the format.

proof.mjs · proof-battery.json · battery-run.log · schema. No account, no form, no vendor contact.

What it records against itself

The object carries a contradictedBy block, and that field is required by the schema rather than optional. This estate previously published 14,914 across 146 suites. The instrument computes 14,914 across 146. The delta is 185. The vendor claim guard failed at 183 passed / 2 failed until the statement was corrected, and reports 185 passed / 0 failed now.

Setting the claim value in this object back to 14,914 makes the verifier fail with stated 14914, recomputed 14914. The format rejects the number that survived on this site for months.

What is unresolved, and counted as such

Four cases in the transport suite need a live socket service and did not run. They are excluded from the total, not counted as passing. The seal instrument refuses to cut a receipt while they fail, which is why no R147 receipt is claimed anywhere on this estate.

The five largest contributors

Why this is the interesting increment

The Verify Standard grades a vendor at V1 through V3. From V20 onward it would have to grade a claim, and that is a different architecture rather than a further level. The distance between where this estate is and anything worth calling a mature standard is one change repeated: make a claim carry its proof. Everything else is distribution.

This is that change, for a population of one. The second Proof Object is cheaper than the first and the hundredth is nearly free, which is the argument for building the first one properly. The full extrapolation.