The limits of verification
What does verifying a Decision Receipt actually prove?
Verification checks the signed record, bound policy and context, evidence references and applicable proofs. Integrity and signature checks work together to detect changes to bound content; a signature alone is insufficient. It does not prove true inputs, authenticated actor identity, a correct decision or that an action was carried out. Offline checks also require the necessary material and separately trusted keys, with export enabled for the deployment.
In more detail
A receipt evidences the policy version that governed the recorded assessment, the supplied context, the outcome and integrity information. It does not settle whether the inputs were true, whether a person was who the calling system said, whether the decision was correct, or whether the application carried out the action. The actor identifier is supplied by the caller; role and authority are display annotations. The record does not explain a model's internal reasoning or establish its version or configuration. Tamper evidence needs integrity recomputation and signature checking together: a content edit can leave the signature over stored integrity information valid, so a signature alone is not a content-integrity verdict. Offline checking depends on the required material, export enablement and independently obtained trust roots. There is no audit-proof or guaranteed-compliance claim.
Limits
Integrity and signature checks together detect changes to bound content; a valid signature alone does not establish unchanged content.
It does not prove that the inputs were true, that the decision was correct or that the action was carried out.
The actor identifier is supplied by the calling system. MeshQu does not independently authenticate it; displayed role and authority are not verified identity.
The record does not establish which model, version or configuration produced a result, or explain a model's internal reasoning.
A receipt describes the policy, rules checked, context and outcome. A rule-by-rule assessment view does not establish the outcome for each individual rule or the evidence for each rule in the signed record.
Offline verification requires the necessary material and separately trusted keys. Export must be enabled for the deployment.
No audit-proof, guaranteed-compliance or quantified-savings claim is made.
Where it applies
Set expectations with a reviewer, auditor or regulator about what a signed record does and does not settle.
Identify what a counterparty needs before independent checking is promised: separately trusted public keys.
Sources
MeshQu docs — Trust model (opens in a new tab)
The documentation owner's account of what the trust model assumes and what it does not cover.
MeshQu docs — Verification bundle (opens in a new tab)
What is brought together for an offline check, which is the scope this entry bounds.
MeshQu docs — Data handling (opens in a new tab)
How decision data is protected in transit and how integration access is limited.
MeshQu docs — Actor attribution (opens in a new tab)
Which actor fields are covered by the integrity hash, and the documentation owner's statement that MeshQu does not authenticate actor identities against an identity provider.
MeshQu docs — Responsible AI: Evidence and Intent (opens in a new tab)
The official record definition, the two-check tamper-evidence boundary and the limits of what a record establishes.
Related answers
Decision Receipts: what the record contains
What is in a Decision Receipt, and what does it prove?
What MeshQu does
What does MeshQu actually do?
Independent verification: the bundle, and what replay checks
How does someone independently verify a Decision Receipt, and what does replay check?
What a receipt records about who acted
Does a Decision Receipt prove who took the action?
What a receipt evidences about a responsible-AI commitment
Can a Decision Receipt show that an AI decision was fair, accurate or correct?