Trust Model

MeshQu’s trust model is a five-rung ladder. Each rung answers a stronger verification question. Higher rungs build on lower ones — none of them replace the layers below. L1 to L4 are properties of the artefact. They are carried by the receipt v2 envelope and checked by the offline bundle verifier, in both the Node and browser implementations. They ship in the product. L5 is a property of a deployment. It is not a missing receipt feature. It depends on how trust roots reach verifiers, how signing, custodian and ratifier keys are governed over their lifetime, and what external assurance the operator arranges. A deployment reaches L5 through operational architecture, not through a release.

---

​

L1 — Recorded

When a decision is recorded, MeshQu stores its context, the frozen policy snapshot it was evaluated against, and the verdict. This is the baseline an auditor would expect from a decision record. What this proves: MeshQu recorded the submitted decision in a structured, queryable form. It does not prove an external action took place.

---

​

L2 — Integrity protected

Every decision receipt includes a SHA-256 integrity hash computed over canonical JSON (keys sorted recursively) of the decision, its violations, the input context, and the frozen policy snapshot. The same inputs always produce the same hash regardless of property order or serialisation quirks. You can replay any decision via POST /v1/decisions/{id}/replay and check the hash matches. If someone changes the verdict, adds a violation, or swaps the policy version, the hash won’t match. Hashing alone does not establish who issued the record. Production receipts are signed with an Ed25519 private key. An unsigned receipt from a nonproduction deployment can be checked for hash consistency but does not establish issuer identity. Signature verification requires an independently trusted public key; the cryptographic check itself needs no API call or shared secret. Under receipt_schema_version: 2 the signature covers a canonical envelope rather than the bare hash, binding signature_kid, signature_algorithm, receipt_schema_version and timestamp into the signed bytes. Tampering with any of those fields fails the signature check. v1 receipts continue to verify under the v1 path, indefinitely. Keys are versioned. Each signed receipt includes a signature_kid (for example, msk_v1) identifying the signing key. The JWKS document at GET /v1/.well-known/signing-keys provides issuer-supplied key information; independent verification requires trust roots obtained and pinned through a channel the verifier accepts. What this proves: the signed record has not changed since it was issued, and any alteration is detectable without contacting MeshQu.

---

​

L3 — Context bound

An unaltered record is only useful if it is bound to what governed the decision. The integrity hash covers more than the verdict: A Verification Bundle then packages everything an offline verifier needs into one archive: the receipt, its policy snapshot, evidence manifest, approval receipts, chain proofs, transparency proof, and a trusted_keys.json listing — all under a digest-of-digests manifest. Because the snapshot travels with the receipt, the rules can be re-run and the verdict reproduced. What this proves: the decision is tied to a specific policy content, a specific context and specific evidence references — not merely to a policy name or version number.

---

​

L4 — Lineage verified

L4 covers the relationships around a decision — who approved the policy, who attested the evidence, and what came before and after in a workflow.

• Approval lineage. Policy approval receipts carry a ratifier Ed25519 signature and a policy_rules_hash. Their digests sit on policy_versions[i].approval_receipt_digest, so approval lineage is bound transitively through policy_snapshot_digest — there is no separate top-level approval digest. The verifier checks digest, rules hash and ratifier signature per version.
• Custodian attestation. Evidence manifest items may each carry an independent Ed25519 signature produced outside MeshQu by the custodian that holds the artefact. MeshQu never holds custodian private keys.
• Chain relationships. Chain proofs hash-link each step to its predecessor; a chain seal is a completeness proof over the whole ordered chain.
• Transparency. When anchored, the receipt’s Rekor entry is checked offline: DSSE subject digest binding, envelope-body hash, and the Signed Entry Timestamp against a pinned Rekor log key.

All four are verified by the shipped bundle verifier and reported as the approval_lineage, evidence, chain_link / chain_seal and transparency sub-claims, at parity between the Node and browser implementations. Approval-lineage and custodian checks require ratifierTrustedRoots and custodianTrustedRoots to be supplied out-of-band. Obtaining those roots from a channel the operator does not control is an L5 concern, not an L4 one. What this proves: the decision sits inside a verifiable lineage — ratified policy, attested evidence, and an intact chain — rather than standing alone.

---

​

The Verification Bundle — ten sub-claims

The bundle binds ten sub-claims under one manifest: Transparency anchoring. When enabled, signed receipts are anchored to Sigstore Rekor, a public append-only transparency log. A verifier can check the bundled Signed Entry Timestamp offline against a trusted Rekor key. Independent online inclusion-proof verification against a co-signed witness is not currently available. Anchoring happens after signing and is not part of the integrity hash — if Rekor is unreachable, the receipt is still signed and valid, just without a transparency anchor. Signing is never blocked by log availability. What this proves: the decision is independently verifiable from a downloaded artifact alone — receipt, signature, policy snapshot, evidence manifest, approval receipts, chain proofs, and (when anchored) the transparency proof — without trusting MeshQu’s live database or dashboard.

---

​

L5 — Independently governed trust

L1 to L4 make an artefact that stands on its own. L5 asks a different question: where does the trust that verification depends on actually come from, and who governs it over time? That is a property of a deployment, not of a receipt. The mechanics below are shipped; what determines whether a given deployment reaches L5 is how they are operated.

• Independently distributed trust roots. Verification is only as independent as the channel the public keys arrived on. MeshQu publishes JWKS and ships bundled defaults, but a channel MeshQu controls is not an independent one. A verifier that pins fingerprints obtained elsewhere — a counterparty, a registry, a regulator — is materially stronger than one that fetches keys from the operator on demand.
• Operational key governance. Rotation cadence, revocation handling, private-key custody, and hardware protection for signing, ratifier and custodian keys.
• Independent custody. Evidence custodians and policy ratifiers should be organisationally distinct from the operator whose decisions they attest. The receipt format supports this; whether a deployment uses it that way is an operating choice.
• External log availability. Anchoring is real, but a transparency guarantee also depends on the log continuing to exist and to be independently monitored. Anchoring is never allowed to block signing, so a deployment must decide what it does when the log is unreachable.
• Organisational controls, retention and publication policy. How long receipts and bundles are kept, who may fetch them, and what is published — none of which the artefact can enforce.

What this proves: verification does not ultimately rest on trust in the operator — the roots, the custody and the assurance around them are governed independently.

---

​

Implemented mechanics vs deployment responsibilities

The distinction that matters when reading anything above: what the product does, and what an operator must arrange around it. Implemented mechanics — shipped, tested and verified by the offline verifier. See the Receipt Reference status matrix for the source-grounded list. Deployment or governance responsibilities — outside the artefact; an operator, not a release, decides these.

---

​

Actor Attribution Trust

When a decision is recorded with an actor, the following trust layers apply: The actor.id field is included in the integrity hash and is therefore cryptographically bound to the receipt. Altering actor.id after the fact invalidates the integrity hash. The binding is transitive, which is why the Receipt Reference states that the structured actor row is not itself hashed: on the record path the API copies actor.id into context.metadata.actor_id before evaluation, and it is that context value which enters the integrity hash via context_hash. Both statements describe the same mechanism. Other actor fields (type, role, authority, display_name) are stored and displayed for audit convenience but are not part of the cryptographic proof — they can be viewed as application-level annotations. The authenticated API key (api_key_id) identifies the calling system. The actor field identifies the responsible party within that system. Both are captured on every recorded decision.

---

​

What still requires trusting MeshQu

• MeshQu’s signing-private-key custody.
• The authenticity of the independently obtained public-key fingerprints used as trust roots. Issuer-provided JWKS and bundled key lists alone do not establish this.
• That DecisionContext.evidence references and source_artifact hashes the caller submits are truthful — MeshQu hashes what it is given.

Independently governed trust (L5) is what narrows the first two: roots distributed and rotated outside the operator’s control, and custody arrangements a verifier can inspect. The organisational side of that trust — tenant isolation, the append-only audit chain, subprocessors, vulnerability disclosure and the compliance roadmap — is published at Security at MeshQu. This page covers what the artefact proves; that page covers what the operator does.

---

​

How to Verify

​

Key Management

Every receipt includes a signature_kid identifying which key signed it. MeshQu publishes a JWKS document for key discovery. A verifier must use independently authenticated trust roots to establish who signed a receipt. Rotation:

• Historical receipts remain mathematically verifiable when the verifier keeps the trusted public key that signed them.

Compromise response: Signature validity and key standing are separate checks. A valid signature does not establish that its key has not been compromised or revoked. No signed key registry is currently published for independent standing checks; see Receipt Reference.