Cristian Ducu

A delivery receipt a skeptic can check

Bellbook 0.9.0 is out. Nothing changed on the wire. What changed is that a receipt can now be judged as a delivery, by anyone, holding nothing but the receipt.

The sentence 0.8 could not finish

0.8 gave a receipt the words. A Requirement says what was asked for and who asked. An ArtifactRef names the exact content that was produced or judged. The extended Evaluation says who decided, with what procedure, over what input, against which requirement, with fail-closed outcomes. A receipt can declare which profiles it claims, and every validator re-checks the claim.

Words are not a sentence. “Requirement R was met by evidence E, judged by evaluator V, over artifact A, under profile L” is a claim with a shape, and until now nothing published defined that shape or checked it. A team that wanted to say “this was delivered” had to write its own checklist over the records, and a skeptic had to trust the checklist.

delivery-receipt-v1 is that shape, published.

A claim is read off the record, never declared

There is no “delivery” record in Bellbook and there will not be one. A delivery claim is an accepted Selection whose evaluations bind to the requirements of exactly one Request. The profile finds it by reading: which request do the used evaluations speak to, which candidate was chosen, what does the record say about each. Nothing is filled in. When several claims qualify for the same request, the latest sound one is evaluated and the earlier ones are reported superseded.

This matters because a field can be forged and a structure cannot be forged in isolation. To make a false claim look true you would have to make every record it rests on consistent with it, and those records are content-addressed, cross-referenced, and re-derived on replay.

Eight clauses, all fail-closed

  • D0 a claim exists.
  • D1 every required, unretracted requirement of the request is covered at the receipt head by a passing, unretracted evaluation.
  • D2 no evaluation of a required requirement is non-passing.
  • D3 the claim chooses one candidate; every evaluation judges that candidate; every piece of evidence an evaluation cites is on the record, carried by the candidate or by an accepted result in the same thread.
  • D4 producer and evaluator are distinct actors.
  • D5 every evaluation names its procedure and input; the weakest basis is reported.
  • D6 the baseline bellbook-core-v1 is met.
  • D7 the claim’s selection is sound, untainted, and unretracted.

Fail-closed means a claim that cannot be checked does not conform. A receipt with no claim fails every clause. An Invalid receipt fails every clause. Coverage is judged at the receipt head, so a requirement added after the claim withdraws the claim until it is re-made; a requirement retracted after the claim taints every evaluation that judged it, and D7 says so.

The forgery that matters

Editing a record is not the interesting attack; one changed byte breaks every id downstream and the receipt is Invalid before any profile runs. The interesting attack keeps every hash consistent. The harness genuinely failed. The log honestly records the failure. The claim is made anyway.

Bellbook’s core accepts that record, because it is valid history: someone really did select that candidate on that evidence. The receipt validates Clean. And the profile rejects the claim on D1 and D2, because the only evaluation covering the requirement did not pass. Clean and rejected is the point: the core proves the history is what it says, the profile judges whether what it says amounts to a delivery.

The profile ships with one rejecting vector for every clause, including that one and its sibling, a genuine passing evaluation reattached to a different candidate (D3). The reference implementation rejects all of them. So does the independent Python validator, which implements every clause from scratch and shares no code with the reference. Both run in CI on every commit. If the two ever disagree, the disagreement is the bug report.

From the quickstart

bellbook export   --profile bellbook-core-v1 delivery-receipt-v1 --out receipt.json
bellbook validate receipt.json          # exit 0: Clean, both profiles met
bellbook validate receipt.json --require-profile delivery-receipt-v1   # on a receipt that did not declare it
bellbook query selected deliver --receipt receipt.json                 # the claim, its candidate, its evidence

report = bellbook.validate(open("receipt.json", "rb").read())
p = next(p for p in report.profiles if p["id"] == "delivery-receipt-v1")
print(p["status"], [c["id"] for c in p["clauses"] if not c["passed"]])

The quickstart walks the whole flow on both surfaces, records the forgery, and watches it rejected.

What a conformant receipt means, and does not

It means every required requirement was judged passed by an evaluator who is not the producer, with a named procedure and input, over evidence the record itself carries for the chosen candidate; that the receipt meets the baseline; and that the claim stands at the head. It does not mean the evaluator was competent, that the procedure hash names a good procedure, or that the requirements were the right ones. Those are facts the record binds so a skeptic can go and check them. Bellbook does not judge them, and a profile that pretended to would be lying.

What did not change

Every record, canonical form, signing form, schema, and verdict rule is byte-for-byte that of 0.8.0. Core conformance is unchanged; the profile’s vectors live apart, by design. A 0.8.0 receipt validates identically under 0.9.0. The Python package gains the profile’s surface with the same release.

What comes next

RFC-0003 pre-registered three ways to tell whether this design is the right shape. One is now met: the fraud battery holds in both implementations. The other two open their window with this release: a committed adopter emitting a real delivery receipt through the published surfaces and replacing its own format, and a party outside both projects verifying one. The signed tier, bellbook-core-signed-v1, follows at 1.0, after the production soak.

cargo add bellbook, pip install bellbook. Profile document in docs/profiles/delivery-receipt-v1.md; specification in SPEC.md, section 12.2.