Proof

Proof, and what it is not yet

This page tells you exactly what exists today and exactly what does not.

There are no screenshots below, no customer logos, no case studies and no specimen Evidence Pack from a client we have not got. What you will find instead is our own public resolver, which you can open and read without an account; a precise account of what the product produces; the field-level shape of a proof response; and a section listing what we have not proven.

A product that asks you to rely on its records has one useful thing to demonstrate before it has customers: what it does when the honest answer is the unflattering one.

Open the public resolver Read what we have not proven

Check it yourself

What you can check right now

ECZ-ID publishes its own records to a public resolver at resolver.ecocitizenz.org. It is live, it is read-only, and it needs no account. Open it in another tab and the rest of this page becomes checkable rather than merely readable.

What you will see

A public proof surface for ECZ-ID records: you resolve one identifier and get its identity, authority, state, bindings and evidence references back, in a human view and as machine-readable JSON. In the resolver's own words, it “is read-only. It does not issue ECZ-IDs, modify records, activate passports, or process payments.”

It is also not a directory. There is no company search and no index to browse — you resolve a specific identifier you already hold, or you get nothing.

What that actually demonstrates

The mechanism, not our virtue. A record can be resolved by a third party who holds only the identifier — without an account, without a subscription, and without contacting the operator who made the claim. The same truth renders for every audience: entitlement widens the fields a reader is shown, never the answer.

It is a separate surface on a separate origin from this site. That is a structural separation, not an independent third party — we operate both. What it gives a reader is a record that does not depend on this page being true.

What is not there

A customer relationship record from an MSP partner. That view is specified and the runtime behind it is built, but there is no customer behind it yet, so there is nothing of that kind for you to resolve today. When there is, it will be resolvable in exactly the way described here — by the customer, not by us on their behalf.

The artefacts

What the product produces

Every artefact the runtime produces, each described three ways: what it contains, who can see it, and what it does not assert. The third column is the one that matters. An artefact described only by its contents invites you to assume the rest, and assumption is precisely what a governance record is supposed to remove.

Fig. 1The artefact register

Artefact	What it contains	Who can see it	What it does not assert
Machine Trust Register	A Machine Trust Register listing the machine actors associated with each client, their native identifiers, and the surfaces they reach. Populated by an ECZ-ID operator during the audit, from tested import code. The self-service console is built but is not switched on in production yet.	You, inside your own tenant. Never another partner, and never one client's entries to another client.	That a listed actor did anything. The entry records that the actor is associated with the client and what it can reach — not that it acted.
Customer Authority record	A customer authority record stating what the client has authorised, separate from what any system happens to permit. Recorded by an ECZ-ID operator during the audit, on the canonical authority model.	You; the client, when you send it to them; anyone holding a live scoped share token for that client.	That a system will enforce it. It records what the client authorised, which is a different fact from what a platform happens to permit.
Customer confirmation	A confirmation request the client answers directly — confirm, request a change, or decline — without needing an account or a subscription. Issued by an ECZ-ID operator. The page your client answers is built and tested; it is not self-service for you yet.	The client, through a link you initiate that stops working once they answer. We do not contact your clients otherwise.	That the client inspected their systems. It records their answer and the exact version of the authority they answered against, so a later change does not silently inherit the confirmation.
Attention Required	Attention Required: deterministic findings that surface what has changed or lapsed across the client base. Produced by the deterministic rule engine and delivered by an operator. The live queue view is built, not yet switched on.	You. Findings are scoped to your own estate and are never aggregated across partners.	That something is wrong. A finding says a deterministic rule matched — an authority nearing its review date, an actor nobody has reviewed — and names the recommended action.
Evidence Pack	An Evidence Pack per client: a versioned document you can hand over at a review, a renewal or an audit. Generated from the canonical record and delivered by an operator.	You, and whoever you hand it to. It carries your firm as the operator, so it is your document about your work, not our document about you.	Actions for which no source evidence exists. Where there is none, the pack says so rather than inferring activity, and its own limitations state that a register entry alone does not evidence a historical action.
Resolver public proof	Existence level only: the kind of record, its current state, and the time that state was last true.	Anyone holding the identifier. It is not a directory, cannot be searched, and cannot be walked.	Who the customer is, what was authorised, or that anything happened. It proves a record exists and what state it is in.
Resolver scoped proof	The customer, the firm managing them, each authority with its scope, basis and state, the delegations beneath those authorities, and the response's own statement of what it does not prove.	Whoever your client shares the token with, for as long as the token lives. No account and no subscription at the other end.	Anything about another customer, and nothing about a historical action. Revoked and superseded records stay visible, because the absence trail is part of the proof.

The “what it contains” column is the capability register's own wording, rendered through the publication gate rather than restated here. Nothing in this table is a screenshot, an export or a customer record — it is a description of the artefacts the runtime produces.

ECZ-ID records identity, authority, delegation, state and evidence, and projects a proof your customer can check independently.

The document

The shape of a proof document

Two proof responses, at field level. The first is what anyone holding an identifier can resolve; the second is what a client can share under a token they control. They are printed here as structures rather than as a picture of a console, because we have no customer record to photograph and a mocked one would tell you nothing except how willing we are to mock things up.

Fig. 2Public proof — existence level

GET /v1/msp/proof/public/{subject_id}          (anonymous)

{
  "kind":  "<CustomerAuthority | MspOrganisation>",
  "state": "<ACTIVE | SUSPENDED | REVOKED | SUPERSEDED | EXPIRED>",
  "as_of": "<ISO 8601 timestamp — when that state was last true>"
}

Structure illustration. Deliberately almost empty: a public answer establishes that a record exists and what state it is in, and stops there. It names no customer and describes no authority.

Fig. 3Scoped proof — resolved against a share token

GET /v1/msp/proof/scoped?token=...             (anonymous)

{
  "customer":   "<customer name, as recorded on the grant>",
  "managed_by": "<the accountable operator's legal name — your firm>",

  "authorities": [
    {
      "scope": {
        "action_classes": ["READ", "WRITE"],
        "surfaces":       ["<surface the authority covers>"]
      },
      "basis_type": "<MSP_DECLARED | EVIDENCE_REFERENCED | CUSTOMER_CONFIRMED>",
      "state":      "<ACTIVE | SUSPENDED | REVOKED | SUPERSEDED | EXPIRED>",
      "as_of":      "<ISO 8601 timestamp of the last state change>"
    }
  ],

  "delegations": [
    {
      "actor": "<machine actor name>",
      "scope": {
        "action_classes": ["<never broader than the authority above>"],
        "surfaces":       ["<never broader than the authority above>"]
      },
      "state": "<ACTIVE | SUSPENDED | REVOKED | SUPERSEDED | EXPIRED>"
    }
  ],

  "what_this_does_not_prove": "<the response's own limitation statement>",
  "as_of": "<ISO 8601 timestamp of this response>"
}

Structure illustration, not a screenshot and not an export. Every identity-bearing value is a placeholder in angle brackets; enumerated fields list their permitted values. It contains no customer data because there is no customer data to contain.

Read the last two fields first

Every scoped response carries its own limitation statement and its own as_of time. A proof that will not say when it was true, or what it declines to cover, is an assertion wearing a schema.

A delegation is never broader than its authority

The subset rule is enforced when the record is written, not checked when it is read: a delegation whose action classes or surfaces exceed the customer authority above it is refused at write time and never exists to be resolved.

Independent re-check

The client checks without going through you. That is the point, not a feature.

Suspension and revocation are recorded events with a time, not a silent change to a permission somewhere. A revoked grant is terminal — it is never resurrected, and a replacement is a new record with a new identifier. Your client can check the current state themselves without asking you and without taking your word for it.

Revocable

You can revoke a share at any time. The next attempt to resolve it is refused, and the refusal is recorded.

Expiring

A share can carry an expiry. Past it the token is refused, whether or not anyone remembered to revoke it.

Rate-limited

Each share carries its own request counter, enforced before any record is disclosed rather than after.

Logged

Every attempt is written to that share's access log with its outcome — served, expired, revoked or refused — including the ones that disclosed nothing.

Customer-isolated

A share resolves one customer's records and carries nothing about any other customer of yours.

Not enumerable

An identifier that does not exist and one the asker is not entitled to return the same answer, so absence cannot be told apart from refusal and there is no list to walk.

You are unwilling to let the customer verify authority independently

Independent re-check is not an optional feature we can switch off. It is the reason the record is worth anything.

The share token is the client's copy of the answer, not a login to your systems. It reaches a projection of their own records and nothing else — no console, no estate, no other customer of yours, and no route from the token back into anything that acts.

Stated plainly

What we have not proven yet

This is the section a launch page normally leaves out. It is here because the argument of the whole product is that records should be checkable, and the fastest way to disprove that argument is to write a proof page that quietly overstates its own position.

No external customer has yet run this end to end. Nothing on this page is evidence of a live deployment, a delivered audit or a checked customer record, and nothing on this page should be read as claiming otherwise.

No external customer has run this end to end: Every entity in our testing is synthetic and founder-created. There is no live customer record behind any link on this page, no delivered audit to show you, and no partner we can name.
The MSP routes are not enabled in production: The runtime is built, tested and deployable, and in production it sits behind feature flags that are off. Those routes are not serving traffic today, and we would rather write that sentence than imply otherwise by omission.
Tenant isolation is proven against a test suite, not against real customer data: Attempts to read, write, search, export and enumerate one tenant's records from another tenant's operator context were all refused, with no identifier of the target tenant appearing in any refusal — driven through the real HTTP boundary with authentication in production mode, against synthetic tenants. That is our own testing. It is not a third-party security audit, and it establishes nothing about anyone else.
The production storage binding is proven at deployment, not here: That test run used a store that mirrors the production store's call sites. Binding to the production store itself is deferred to deployment smoke testing, and we will not call it proven before that runs.
What would change this: One partner, one client estate, run end to end with the routes live. When that happens this section is rewritten rather than removed — it will say what was proven and what still was not.

This section stays on the page and gets shorter as things become true. It does not get deleted on the day it becomes inconvenient — and if you ever find it gone while the claims around it have grown, that is a finding about us, and you should treat it as one.

Two next steps, neither of which requires taking our word for anything

Run the free Machine Trust Check Apply for access

The check needs no signup and no email address, and your answers never leave your browser. Applying is how commercial activation starts: there is no countdown, no seat count and no waitlist number, and the qualification criteria are published in full on the programme page.