Decision Assurance

Decision Assurance is the contract MeshQu offers a regulator, auditor, or counterparty: given a downloaded artifact and the right out-of-band public keys, you can independently prove what decision was made, under which policy, against which evidence, by which actor, at what externally-verifiable time — without trusting MeshQu’s live database or dashboard.

​

The assurance ladder

L1 to L4 are properties of the artefact, carried by the receipt v2 envelope and checked by the offline bundle verifier — 10 sub-claims, at parity between the 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 out-of-band public-key distribution channel (we publish via JWKS and bundle defaults; you can pin fingerprints).
• That DecisionContext.evidence references and source_artifact hashes the caller submits are truthful — we hash what we’re given.

​

Storage-layer immutability — what it enforces, and against whom

MeshQu enforces immutability with database triggers. Every trigger binds the API’s runtime role and every application caller. No trigger binds the table owner or a DB superuser, either of whom can defeat one with ALTER TABLE ... DISABLE TRIGGER or SET session_replication_role = 'replica'. That is inherent to the mechanism, not a defect in any particular rule, and it bounds every claim below. Enforced against the runtime role and every application caller:

• Deleting a recorded receipt or policy snapshot is blocked.
• Updating any integrity-bound field is blocked. result.transparency_anchor is the one legitimate post-record mutation, and it is one-time-set: it may go from null to an anchor exactly once, and can then never be replaced or erased — only re-written identically as a no-op.
• TRUNCATE on the append-only tables is blocked by a statement-level guard.

Not established by the above:

• A privileged operator holding the table-owner or superuser role can disable these triggers and then delete or rewrite rows. Constraining that is a deployment responsibility — the API runtime connecting as a non-owner role that holds DML only — and not a property any release delivers. Detection is bounded too: disabling a trigger via session_replication_role leaves pg_trigger.tgenabled unchanged, so a health check reading that column does not see it.
• Forging a new receipt still requires the signing key, whatever the database role. Rekor anchoring and external attestor signatures narrow that further; independent custody of the signing key itself is an L5 concern.

The durable statement is therefore about the signing key, not the database: a receipt that verifies against an out-of-band trust root was signed by the key, and no database privilege substitutes for it. Deletion, by contrast, is a retention and access-control property an operator arranges — see the responsibilities table below.

​

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.