Trust & evidence

Verify the system before you enroll.

Follow the public trust path from published keys to installed policy and the record you can inspect. Each tile opens the underlying surface.

Interactive public evidence pathFour connected, selectable steps explain trust keys, the bootstrap contract, the signed bundle, and installed service health without opening raw JSON.PUBLIC VERIFICATION PATH · CLICK A STEP FOR THE HUMAN-READABLE EXPLANATION 1 · Trust rootwho may sign?which keys do I pin? 2 · Bootstrapwhat protocol?which current bundle? 3 · Signed bundlewhat will install?do the digests match? 4 · Install + healthis the service ready?what is locally verified?

The whole public path

Start with the published signing identities, understand the bootstrap contract, inspect the exact files in the signed bundle, then verify local installation and service readiness.

What a customer is checking

That each stage has an inspectable source and that no raw service response has to be mistaken for a customer explanation.

Technical verification commands
curl -sS https://governance.mistwire.io/v1/trust
curl -sS https://governance.mistwire.io/v1/bootstrap
curl -sS https://governance.mistwire.io/v1/bundle/stable
curl -sS https://governance.mistwire.io/v1/healthz
curl -sS https://governance.mistwire.io/v1/blob/<sha256> | shasum -a 256

A signed receipt binds an enrolled key, observation, bundle, time, and service verdict. It attests installed governance state; it is not a per-action activity log or proof that a customer-controlled machine reported truthfully.

Limitations

A machine you control can misreport what it saw.

The receipt is the service's judgment of a report. If the report is wrong, the judgment is wrong with it. Here is what that looks like today, and what changes next.

The report says
Hook present
The receipt says
Compliant
What is recorded
The report and the disk agree.