{"schemaVersion":"0.1","generatedAt":"2026-10-09T19:42:17.554Z","entry":{"knowledgeKey":"limits-of-verification","kind":"limitation","entityKey":"security-trust","locale":"en","primaryQuestion":"What does verifying a Decision Receipt actually prove?","questionVariants":[{"question":"Is a Decision Receipt audit-proof?"},{"question":"Does a signature prove the decision was right?"},{"question":"What do I need in order to verify a receipt independently?"},{"question":"Does a receipt prove who took the action?"}],"title":"The limits of verification","answer":"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.","explanation":"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.","applications":[{"value":"Set expectations with a reviewer, auditor or regulator about what a signed record does and does not settle."},{"value":"Identify what a counterparty needs before independent checking is promised: separately trusted public keys."}],"limitations":[{"value":"Integrity and signature checks together detect changes to bound content; a valid signature alone does not establish unchanged content."},{"value":"It does not prove that the inputs were true, that the decision was correct or that the action was carried out."},{"value":"The actor identifier is supplied by the calling system. MeshQu does not independently authenticate it; displayed role and authority are not verified identity."},{"value":"The record does not establish which model, version or configuration produced a result, or explain a model's internal reasoning."},{"value":"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."},{"value":"Offline verification requires the necessary material and separately trusted keys. Export must be enabled for the deployment."},{"value":"No audit-proof, guaranteed-compliance or quantified-savings claim is made."}],"nextStep":{"label":"MeshQu trust model","href":"https://docs.meshqu.com/security/trust-model"},"claims":[{"claimKey":"verification-scope","statement":"Verification checks issuance and integrity of the recorded assessment and its bound material. It does not establish true inputs, correctness, authenticated actor identity or subsequent action execution.","qualification":"The record concerns the policy assessment, not an explanation of a model's internal reasoning."},{"claimKey":"keys-must-be-trusted","statement":"Independent checking depends on how trusted public keys are distributed and governed. With separately trusted public keys, another party can check for changes to signed content without access to MeshQu's live dashboard.","qualification":"The necessary verification material must be available and export enabled for the deployment; no universal export entitlement is claimed."},{"claimKey":"not-actor-identity","statement":"A receipt can carry what happened at the boundary where an agent proposes an action. It binds the actor identifier the calling application supplied, but it does not independently authenticate that actor, and it does not establish which model, version or configuration produced the result.","qualification":"The record binds the supplied identifier through the context. Role and authority are display annotations. No authenticated actor identity or model provenance is established."},{"claimKey":"no-audit-proof","statement":"MeshQu does not claim that a receipt is audit-proof, that it guarantees compliance, or that it produces a quantified saving.","qualification":"Stated as an absence: no such claim appears in the reviewed public copy or in the verified-claims register."},{"claimKey":"integrity-and-signature-together","statement":"Tamper evidence requires integrity recomputation and signature checking together; a signature alone does not prove that the recorded content has not changed.","qualification":"Only the fields the receipt contract binds are covered."}],"statementKind":"product-description","availability":"not-applicable","evidenceStrength":"source-reported","publicSources":[{"title":"MeshQu docs — Trust model","url":"https://docs.meshqu.com/security/trust-model","context":"The documentation owner's account of what the trust model assumes and what it does not cover."},{"title":"MeshQu docs — Verification bundle","url":"https://docs.meshqu.com/concepts/verification-bundle","context":"What is brought together for an offline check, which is the scope this entry bounds."},{"title":"MeshQu docs — Data handling","url":"https://docs.meshqu.com/security/data-handling","context":"How decision data is protected in transit and how integration access is limited."},{"title":"MeshQu docs — Actor attribution","url":"https://docs.meshqu.com/guides/actor-attribution","context":"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."},{"title":"MeshQu docs — Responsible AI: Evidence and Intent","url":"https://docs.meshqu.com/concepts/responsible-ai-evidence","context":"The official record definition, the two-check tamper-evidence boundary and the limits of what a record establishes."}],"revision":"73f530ba721201e01f6914281e6d2f0e82bfb473a50979f9bc0579f3cfd925aa","updatedAt":"2026-10-09T11:41:28.247Z","canonicalUrl":"https://www.meshqu.com/blog/agentic-ai-governance","related":[{"key":"decision-receipts","url":"https://www.meshqu.com/knowledge/decision-receipts.json"},{"key":"what-meshqu-does","url":"https://www.meshqu.com/knowledge/what-meshqu-does.json"},{"key":"independent-verification","url":"https://www.meshqu.com/knowledge/independent-verification.json"},{"key":"actor-identity","url":"https://www.meshqu.com/knowledge/actor-identity.json"},{"key":"responsible-ai-evidence","url":"https://www.meshqu.com/knowledge/responsible-ai-evidence.json"}]}}