A proof system that answers each question separately
Instead of one all-or-nothing check, proof is broken into separate questions. Six parts, each with one job.
Technology
The components, one by one
Sealing
Creates the evidence attached to a critical request. It proves who sealed it, and claims nothing about what happens next.
Who it was for
Records who a request was meant for, on the day it was sent, so proof of the intended recipient is never confused with proof of the sender.
Rules posted in advance
A separate statement of what a company says it always seals, meant to be useful to someone holding no request at all. Its format is specified, with an example a reader can copy.
The checker
Examines the available evidence and reports what can be established. A level-A result stays a level-A result. The page is deployed at its permanent address and reaches its service. No seal has been issued, so today it answers that no seal matches a code — and says that this proves nothing either way about the request.
The registry
The record layer the later levels need. Its core is built and tested and a service runs it publicly, with no organisation enrolled; no production registry is anchored.
A public record no single party controls
What would let evidence be reconstructed later without trusting either party. It belongs to level E and is not implied by a request having been sealed. Specified, not built.
Separate methods, separate assumptions
A to E is not one single cryptographic step. Sealing, working out who it was for, receipt evidence, closing the record and anchoring rest on different assumptions. Keeping them apart makes the model easy to inspect, and makes it harder to hide an unproven step behind a proven one.
The honest difficulty: enrolment
Step B and above need the sender enrolled and their recipient known to us. If only a handful of your suppliers are enrolled, most messages stay unverifiable, and we show them as unverifiable rather than pretend. That is the hard part of this business, and also what protects it.