Decision Assurance

Decision Assurance describes what a regulator, auditor, or counterparty can check in a downloaded artifact. With independently trusted public keys, a verifier can check the recorded verdict, bound policy snapshot, submitted context and evidence references, and any available lineage or transparency proofs without relying on MeshQu’s live database. Actor identity and the truthfulness of submitted evidence remain outside the cryptographic proof; external time evidence is available only when a transparency anchor is present.

​

The assurance ladder

L1 to L4 describe checks available from the artefact, as applicable to its contents. The offline bundle verifier reports 10 sub-claims in both its Node and browser implementations. L5 is a property of a deployment. It is not a missing receipt feature; it is reached through how trust roots are distributed and how keys are governed. See Implemented mechanics vs deployment responsibilities below, and the Trust Model for the long form.

​

Trust roots — the load-bearing rule

Every signature in a Decision Receipt and Verification Bundle is verified against an out-of-band trust root. The bundle’s own trusted_keys.json is informational — useful for fingerprint UIs — but never used to authenticate a signature. Otherwise, a self-signed bundle (operator-controlled keys listed as “trusted” in the bundle) would pass verification.

​

What an offline verifier proves today

See Verification Bundle for the full sub-claim taxonomy and failure codes.

​

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 defaults alone do not establish this.
• That DecisionContext.evidence references and source_artifact hashes the caller submits are truthful — we hash what we’re given.

​

Storage-layer immutability

MeshQu’s database controls block ordinary application callers from changing or deleting recorded receipts and policy snapshots. A transparency anchor can be added to a recorded receipt once, after signing; the signed content cannot be changed through the application API. These controls do not establish that a privileged database operator could never change or remove stored data. Limiting and monitoring privileged access, as well as retaining and publishing bundles, are deployment responsibilities. An independently verified receipt establishes that the trusted signing key signed its contents; database access alone cannot create that signature.

​

Implemented mechanics vs deployment responsibilities

Implemented mechanics — shipped, tested, and checked by the offline verifier in both runtimes. Statuses are source-grounded in the Receipt Reference status matrix. Deployment or governance responsibilities — an operator arranges these; no release delivers them.

​

Roadmap

Everything above under implemented mechanics has shipped. What remains open is a genuine roadmap, not a backlog of receipt structure:

• Recursive governance — governance_source.level is always 0; do not describe MeshQu as offering tiered or hierarchical governance.
• Online Rekor inclusion-proof verification against a co-signed log witness — anchoring and offline SET verification are implemented; live witness verification is not.
• RFC 8785 canonical JSON (meshqu-canonical/v1) — today the frozen profile is meshqu-canonical/v0.
• AI provenance envelope · RFC 3161 timestamps · multi-log transparency · counterfactual replay.

​

See also

• Verification Bundle — the L2–L4 contract in full.
• Trust Model — the same ladder, at length.
• Verifying Bundles — auditor workflow.
• Bundles API — endpoint reference.
• MeshQu Research — the empirical work behind these claims: pre-registered studies over signed decision corpora, with DOIs and published datasets.
• AI governance platforms and the execution-proof layer — the same distinction stated in the category’s own vocabulary, for a reader who has not met this page’s terms yet.