Atestan Atestan

A proof system built around distinct evidence questions

The architecture follows the proof model rather than treating verification as one operation. Six components, six roles — and each one below carries its state, because an architecture diagram that does not say what exists is a plan drawn as a product.

01

Technology

  1. Sealing

    Built and tested

    Creates the evidence bound to a critical request — the foundation of level A. It establishes evidence about the act of sealing, and claims nothing about what follows.

  2. Recipient resolution

    Built and tested

    Binds the model to “for whom was this intended”, at the date of issue — which keeps the recipient question from collapsing into sender authentication.

  3. Published policy

    Built and tested

    An independent description of what an organisation says it always seals — useful to someone who holds no request at all. The schema and the example a reader can copy are written down and public.

  4. The verifier

    Built and tested · online, not open to a client

    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.

  5. The registry

    Built and tested · online, not open to a client

    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.

  6. Anchoring

    Specified, not built

    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.

02

Separate mechanisms, separate assumptions

A to E is not one homogeneous cryptographic operation. Sealing, recipient resolution, receipt evidence, closure and anchoring rest on different assumptions. Keeping them apart makes the model examinable — and makes it harder to hide an unproven step behind a proven one.

The honest difficulty: enrolment

Rungs B and above need the issuer enrolled and the recipient resolvable. If only a handful of your suppliers are enrolled, most messages stay unverifiable — and we will show them as unverifiable rather than pretend. That is the hard part of this business, and also its moat.