Skip to main content
MeshQu implements a four-level trust maturity model. Each level builds on the previous, adding stronger cryptographic guarantees. The current deployment operates at Level 2.

​
Level 0 — Deterministic Integrity

Status: Active
Every decision produces an identical hash when replayed with the same inputs. Capabilities:
  • SHA-256 integrity hashing of all decision inputs, outputs, and policy snapshots
  • Canonical JSON serialisation for reproducible computation
  • Replay verification — recompute and compare at any time
  • Frozen policy snapshots bound to each decision
PropertyValue
Hash algorithmSHA-256
CanonicalisationRecursive key-sort + JSON.stringify
Replay endpointGET /v1/decisions/{id}/replay
What this proves: The decision record has not been altered since it was created.

​
Level 1 — Cryptographic Signatures

Status: Active
Decisions are signed — tampering is detectable without any API call. Capabilities:
  • Ed25519 digital signature on every decision receipt
  • Key versioning (msk_v1) with documented rotation runbook
  • Offline verification — no network call required to validate
  • Current + previous key support for graceful rotation
PropertyValue
Signature algorithmEd25519 (RFC 8032)
Key formatSPKI DER, base64-encoded
Key IDmsk_v1
VerificationWeb Crypto API / Node.js crypto
What this proves: The decision was issued by MeshQu and has not been modified.

​
Level 2 — Transparency Anchoring

This is the current deployment level.
Even if MeshQu disappears, receipts remain independently verifiable. Capabilities:
  • Anchored to Sigstore Rekor — a public, immutable transparency log
  • DSSE envelope with in-toto attestation statement
  • Merkle tree inclusion proofs for tamper-evident ordering
  • Graceful degradation — signing is never blocked by log availability
PropertyValue
Transparency logSigstore Rekor (rekor.sigstore.dev)
Entry formatDSSE envelope + in-toto statement
Proof typeMerkle tree inclusion proof
DegradationSigned but unanchored if Rekor unreachable
Why DSSE, not hashedrekord? Ed25519 is incompatible with Rekor’s hashedrekord entry type (sigstore/rekor#851). MeshQu uses DSSE envelopes with in-toto attestation statements instead.
What this proves: The decision existed at a specific point in time, anchored in a public, append-only log that MeshQu cannot retroactively alter.

​
Level 3 — Hardware-Bound Identity

Status: Planned — available on engagement basis.
Signing keys never leave secure hardware. Capabilities:
  • Hardware security modules (HSM) or Cloud KMS for key storage
  • Agent-level identity binding — each agent gets its own attested key
  • Attestation chains linking decisions to specific hardware enclaves
  • FIPS 140-2 Level 3+ compliance path
What this proves: Cryptographic operations are performed within tamper-resistant hardware, providing the highest assurance that keys have not been extracted or cloned.

​
How to Verify

Web Verifier

Paste any decision receipt JSON. Integrity hash, signature, and transparency anchor are validated in your browser — no API call, no authentication.

Verification CLI

Open-source command-line tool for independent receipt verification. Coming soon.
npx meshqu-verify receipt.json

​
Why Sigstore Rekor?

Rekor is a free, public, immutable transparency log operated by the Sigstore project under the Linux Foundation. It uses the same Merkle tree technology behind Certificate Transparency — the system that secures billions of HTTPS connections. By anchoring decision receipts to Rekor, MeshQu creates a tamper-evident record that exists independently of our infrastructure.