> 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/answer-evidence/advanced-inference-trust.md). # Advanced inference trust Inference commitments and proofs are optional layers on an answer record. Interpret them separately from the answer's trust-log inclusion and factual quality. ## Part A: inference commitment `rawctx.inference.commitment.v1` can bind submitted values such as `model_ref`, `input_hash`, `output_hash`, `config_hash`, runtime identifiers, and provider attestation metadata to the answer record. A `provider_attested` backend means the provider supplied the claimed binding. It does not mean raw model weights were independently verified. ## Part B: inference proof An optional inference proof can be attached after Part A. With a prepared EZKL project, the Python SDK can generate and locally verify a proof, create the commitment-bearing answer log, and queue server verification in one call. Install the optional runtime and define the reusable project once: ```bash pip install 'rawctx[ezkl]' ``` ```json { "schema": "rawctx.ezkl.project.v1", "model_path": "ezkl/model.onnx", "compiled_circuit_path": "ezkl/network.compiled", "settings_path": "ezkl/settings.json", "proving_key_path": "ezkl/pk.key", "verification_key_path": "ezkl/vk.key", "srs_path": "ezkl/kzg.srs", "srs_ref": "kzg_srs_v1" } ``` Save this as `rawctx.ezkl.json` in the working directory, or set `RAWCTX_EZKL_CONFIG` to its location. Paths are resolved relative to the configuration file. The settings must expose exactly one `Public` rescaled input and output. The SRS must be the exact workspace `kzg_srs_v1` bundle; files generated by `ezkl.get_srs()` or `ezkl.gen_srs()` are rejected. Configure the workspace API endpoint and a UI-issued deployment token: ```ini RAWCTX_REGISTRY=https:// RAWCTX_TOKEN= ``` ```python import rawctx with rawctx.RawctxClient() as client: result = client.run_ezkl_and_log( application_key="ezkl_test", input_data=[[2.0]], idempotency_key="ezkl:identity:run-001", ) print(result["log_id"]) print(result["job_id"], result["proof_job"]["status"]) ``` You do not supply an artifact path per call. The helper loads the project, runs `gen_witness`, `prove`, and `verify` with EZKL 23.0.5 in a private temporary directory, derives question and answer text from the single public rescaled input and output, and removes temporary artifacts. It then performs two API writes. A local verification pass does not make the returned `queued` job server-verified; the worker reports `adapter_verified` only after its own verification succeeds. The ONNX model, compiled circuit, proving key, and SRS are not uploaded. Proof/settings/VK and public rescaled values are stored in private job metadata. Because answer-log creation and proof-job creation are not atomic, use a stable `idempotency_key`; a job failure can leave the log recorded, and regenerating a proof can create a different job request. Workspace policy still controls the backend, budget, queue, and artifact limits. An application JWT needs `answer_audit:proof:write` to create or submit proof work. Proof reads use `answer_audit:read`; policy changes require a tenant manager. ## Job and proof states Job progress uses `queued`, `running`, and `succeeded`. Keep the failure states distinct: `verification_failed`, `failed_retryable`, `failed_terminal`, `timeout`, `cancelled`, `expired`, `budget_exhausted`, `rate_limited`, `artifact_too_large`, `policy_blocked`, `backend_unavailable`, and `unsupported_commitment` require different operational actions. Accepted proof results distinguish `commitment_bound` from `adapter_verified`; neither is a factual-correctness judgment. Proof envelopes must use `rawctx.inference.proof.v1`, and an artifact reference that carries a URI must also declare `size_bytes`. Keep raw proof bytes, prompts, answers, private weights, and internal artifact URIs out of public proof envelopes. ## Inference backends * **`provider_attested`:** binds the provider's submitted attestation; it does not independently verify private model weights. * **`ezkl_v1`:** a zkML sidecar may bind a proof job and public inputs. It does not validate factual accuracy or hide values that the proof exposes as public inputs or outputs. * **`hash_only` and `mock_v1`:** development and contract-test backends, not independent production attestations. ## Checkpoint signatures and witnesses * **ML-DSA:** if the public verifier does not support direct verification of the signature, it reports `SIGNATURE_UNVERIFIED` instead of promoting it to a pass. * **Sigstore Rekor:** a Rekor record is a separate witness for a signed checkpoint. It is not proof of answer delivery or correctness. ## Review order 1. Check the answer record and its event history. 2. Check the Part A commitment fields and hashes. 3. Check the Part B backend, proof type, and verification binding when present. 4. Verify the trust-log proof and external receipts separately. 5. Record factual, delivery, and source-use review as separate conclusions. See Trust and verification for proof status terminology. --- # 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/answer-evidence/advanced-inference-trust.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.