GDP Proof is fail-closed. Operation identities are explicit, proof obligations are frozen before verification, verify_operation accepts only GDP-owned bounded journal evidence, and prove_patch requires the exact incoming patch identity plus matching full-apply and hash-bound terminal verification evidence.
Start from one exact typed operation identity
Operation Proof uses canonical typed references such as incoming:<id>, suggestion:<id>, run:<id>, or task:<id>. Bare identifiers are rejected because the same string shape can appear in different GDP journals and co-occurrence alone is not correlation proof.
inspect_operation reads bounded GDP-owned evidence for one exact typed identity without verifying, retrying, cancelling, or mutating it. Missing evidence remains unknown rather than being filled from a caller's narrative.
Choose the exact operation whose outcome matters before defining what success should mean.
Freeze proof obligations before asking whether they passed
build_proof_obligations freezes keyed success criteria against the exact operation identity and returns a deterministic proof contract with pending obligations. The builder does not inspect evidence and always keeps verified=false.
verify_operation then validates that frozen schema-v2 contract and evaluates only predicates supported by GDP-owned bounded operation-journal evidence. Caller-supplied authoritative evidence is never accepted. Unsupported or custom criteria that GDP cannot prove from its journal stay unproven instead of being guessed true.
Tampered proof identity, criteria, obligation text, or verified state fails closed as unverifiable.
A zero-exit run can satisfy supported terminal/success predicates; a nonzero exit can contradict them.
A completed Suggested Check proves success only when its material counts are terminal with no failed, skipped, pending, or other unresolved checks for the supported predicate.
Stale or incomplete evidence cannot be promoted to verified merely because some obligations are satisfied.
Use prove_patch for one exact full patch apply
prove_patch is more specific than a generic operation view. It takes one exact incoming patch ID and the exact lowercase SHA-256 content hash and classifies only GDP-owned full-apply receipts plus patch-attached verification bundles bound to that same hash.
Only apply_patch or apply_all receipts with the matching patch hash can satisfy the full-apply obligation. Verification must come from patch-attached, hash-bound, terminal material checks. Standalone Suggested Checks, historical unbound bundles, queue presence, or caller claims cannot satisfy exact patch proof.
Matching full apply plus fully terminal passing hash-bound verification: verified.
Matching full apply with missing, pending, skipped, or otherwise insufficient verification: partial or unproven verification.
Passing verification without an exact full-apply receipt: unverifiable because the material apply is still unproven.
Hash conflicts, a failed bound check, or contradictory apply identity: contradicted.
Interpret proof status conservatively
verified means every obligation supported by that exact proof contract was satisfied by the required authoritative GDP evidence. partial means some required evidence exists but at least one obligation remains unproven. contradicted means authoritative evidence conflicts with the requested success condition. unverifiable means GDP cannot establish the required evidence chain.
These classifications do not widen authority or rerun work. If proof is partial or unverifiable, inspect the listed unknowns and evidence references, then continue from the missing operation or verification step rather than repeating an already-proven mutation.
Proof answers what authoritative GDP evidence establishes. It does not turn a successful check into an apply receipt, a queue item into execution, or a model statement into repository truth.
