{"schemaVersion":"0.1","generatedAt":"2026-10-09T20:01:51.888Z","entry":{"knowledgeKey":"independent-verification","kind":"capability","entityKey":"security-trust","locale":"en","primaryQuestion":"How does someone independently verify a Decision Receipt, and what does replay check?","questionVariants":[{"question":"What is in a verification bundle?"},{"question":"What does replaying a receipt actually re-run?"},{"question":"What keys does a verifier need, and where do they come from?"},{"question":"Can a receipt be checked without access to MeshQu?"}],"title":"Independent verification: the bundle, and what replay checks","answer":"Where export is enabled, a verification bundle brings the receipt, policy snapshot and applicable proofs together for an offline check. Replay checks the recorded assessment against the supplied context and snapshot; it does not repeat the action. Signature checks require separately trusted keys obtained out of band. Included keys are informational. Confirm deployment export access before relying on it; general production availability is agreed per engagement.","explanation":"A verification bundle can contain the signed receipt, policy snapshot, applicable chain and transparency proofs, evidence manifest and policy-approval records, plus an integrity manifest. The snapshot can be replayed against the supplied context. Required trust roots come from channels outside the bundle; included keys do not authenticate themselves. A check reports the relevant sub-claims and distinguishes valid, verified with caveats and failed. Integrity recomputation and signature verification are separate checks that work together. None of this establishes true inputs, authenticated actor identity, a correct decision or subsequent action execution. Export is conditional: where it is enabled for the deployment, the receipt and policy snapshot can be exported. The 17 July register's staging-on/production-off observation remains dated historical evidence and has not been upgraded into a fresh environment check.","applications":[{"value":"Where export is enabled, give an external reviewer the receipt, policy snapshot and applicable proofs for an offline check."},{"value":"Distinguish valid, verified with caveats and failed outcomes, and inspect which checks apply rather than treating them as one unconditional badge."}],"limitations":[{"value":"Replay re-checks the recorded policy assessment. It does not repeat the real-world action and does not recreate a model's internal reasoning."},{"value":"The public keys included in a bundle are informational and are never used for authentication; trust roots must be obtained out of band."},{"value":"MeshQu's signing-keys endpoint is documented as deprecated and self-asserted, and must not be used as a trust root."},{"value":"Bundle export was recorded as enabled in staging and not enabled in production as of the 17 July 2026 register, and the verifier CLI was recorded as unpublished. Confirm availability before relying on it."},{"value":"What a successful check does and does not settle is a separate subject: see the limits-of-verification entry."},{"value":"Where export is enabled for your deployment, the receipt and policy snapshot can be exported for offline verification. Export enablement is a separate operating condition from the existence of the verifier and bundle format."}],"nextStep":{"label":"What a verification bundle contains","href":"https://docs.meshqu.com/concepts/verification-bundle"},"claims":[{"claimKey":"bundle-is-self-contained","statement":"A verification bundle is a self-contained archive of everything an external verifier needs to validate a Decision Receipt offline. It contains the signed receipt, a policy snapshot for rule re-execution, chain proofs and seal where applicable, a transparency proof where anchored, public keys marked informational, and a top-level manifest with integrity hashes.","qualification":"Export must be enabled for the deployment. Chain, transparency, evidence and approval-lineage material are present only where applicable; independently obtained trust roots are still required."},{"claimKey":"replay-checks-the-assessment","statement":"Replay re-runs the bundled policy snapshot's rules against the bundled context and checks that the result reproduces the receipt's integrity hash. It re-checks the recorded policy assessment; it does not repeat the real-world action and does not recreate a model's internal reasoning.","qualification":"This is one of the sub-claims a bundle check reports, alongside manifest, integrity, signature, transparency, chain, canonicalisation, evidence and approval-lineage checks."},{"claimKey":"trust-roots-out-of-band","statement":"Signature checking is performed against trust roots obtained out of band. The public keys included in a bundle are informational and are never used for authentication, and MeshQu's signing-keys endpoint is documented as deprecated and self-asserted and must not be used as a trust root.","qualification":"Independent verification therefore depends on how the verifying party obtains and governs its trust roots."},{"claimKey":"graded-outcome","statement":"A bundle check reports a result for every applicable sub-claim without stopping at the first failure, and the outcome collapses to three states: valid, verified with caveats where only advisory checks failed, or failed where a hard failure is present.","qualification":"Ten sub-claims are documented, covering the manifest, integrity, signature, replay, transparency, chain link and seal, canonicalisation, evidence and approval lineage."},{"claimKey":"export-not-enabled-in-production","statement":"Bundle export was recorded as deployed and enabled in staging but not enabled in MeshQu's production environment, returning 503; the verifier CLI was recorded as private and not published publicly.","qualification":"As of the 17 July 2026 verified-claims register. Not independently re-verified since that date; confirm current availability before relying on it."}],"statementKind":"capability","availability":"in-development","evidenceStrength":"source-reported","publicSources":[{"title":"MeshQu docs — Verification bundle","url":"https://docs.meshqu.com/concepts/verification-bundle","context":"What the bundle contains, the sub-claims an offline check reports, and the out-of-band trust-root requirement."},{"title":"MeshQu docs — Concepts overview: Decision Receipt","url":"https://docs.meshqu.com/concepts/overview#decision-receipt","fragment":"decision-receipt","context":"The documentation owner's definition of the record being verified, including the policy snapshot that replay uses."},{"title":"MeshQu docs — Trust model","url":"https://docs.meshqu.com/security/trust-model","context":"What the trust model assumes, read alongside the requirement that trust roots come from outside the bundle."},{"title":"MeshQu docs — API reference: error codes","url":"https://docs.meshqu.com/api/errors","context":"The BUNDLE_EXPORT_DISABLED condition means export is not enabled for the tenant; availability is deployment-specific."}],"canonical":{"externalUrl":"https://docs.meshqu.com/concepts/verification-bundle"},"revision":"45b5ee73ecab75958c45888b664128501733af4ae5b1cc18c451a4732dfb3599","updatedAt":"2026-10-05T17:39:15.862Z","canonicalUrl":"https://docs.meshqu.com/concepts/verification-bundle","related":[{"key":"limits-of-verification","url":"https://www.meshqu.com/knowledge/limits-of-verification.json"},{"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"}]}}