> For the complete documentation index, see [llms.txt](https://rawctx.gitbook.io/rawctx-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://rawctx.gitbook.io/rawctx-docs/documentation/trust-and-verification.md). # Trust and verification rawctx proof material lets reviewers check the integrity and internal bindings of submitted answer records, commitments, checkpoints, and receipts. ## Verify an answer proof ```bash rawctx trust proof answer ANSWER_LOG_ID --output proof.json rawctx trust verify proof.json --online --json ``` Offline verification checks the bundle's local structure and cryptographic bindings and returns `ok`, `errors`, and optional warnings. It does not compute the server's policy-aware trust status. With `--online`, the configured registry evaluates supported trust and external-anchor checks. Interpret only the checks and state actually present in the response. ## Read proof states precisely * `ANCHORED`: local proof bindings pass, the checkpoint has a confirmed external anchor, and any policy-required witness is verified and bound to that same checkpoint. * `BITCOIN_OBSERVED_PENDING_CONFIRMATION`: a Bitcoin attestation was observed but has not reached the required confirmation state; any required witness condition must already be satisfied, otherwise the result remains `PENDING`. * `PENDING`: required anchoring or confirmation is incomplete. * `LOCAL_ONLY`: only local verification material is present. * `INVALID`: one or more required verification checks failed. * `SIGNATURE_UNVERIFIED`: the bundle carries a signature algorithm the selected verifier did not verify. Individual checks may report `PASS`, `FAIL`, `SKIP`, or `NA`. A `PASS` applies only to the named check. ## Proof lifecycle and triage Answer creation, signed tree-head publication, external anchoring, witness observation, and final confirmation can happen at different times. A newly created answer may therefore return a pending proof shell before a checkpoint covers its trust leaf. 1. Verify locally. A `FAIL` is a hard stop; do not promote the bundle. 2. If the leaf is not covered yet, retry proof retrieval after the next checkpoint interval instead of rebuilding the answer record. 3. Verify online when policy requires external anchor or witness interpretation. 4. Escalate an `INVALID` result, a long-lived `PENDING` state, a missing required witness, or a signature that the selected verifier cannot evaluate. `SKIP` means the verifier intentionally did not run a check. `NA` means the check does not apply to that proof. Neither is equivalent to `PASS`. ## What a proof does not establish A proof does not establish that an answer is factually correct, that it reached an end user, that a referenced source was used in reasoning, or that submitted external content was true. ## Verification contract The verification contract covers canonical JSON, Merkle inclusion, signed tree heads, checkpoint bindings, external checks, supported signatures, and the privacy boundary. * [Answer Audit guide](https://hub.rawctx.dev/docs/answer-audit) * Advanced inference trust Proof material should contain commitments and verification data, not tenant-private question text, answer text, media, storage keys, or sessions. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://rawctx.gitbook.io/rawctx-docs/documentation/trust-and-verification.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.