Configure the capture path explicitly.
Notary runs in a configured QHx Proxy with a writable database and protocol middleware. In the current documented HTTP path, the openai middleware processes nonstreaming POST /v1/chat/completions requests. It is not a general recorder for arbitrary HTTP endpoints.
The proxy needs Kubernetes API access to the referenced upstream Pod, a supported QHx pod identity, workload credential sources and permission to read the Pod’s metadata. The middleware records successfully parsed HTTP 200 JSON responses. Empty, error and non-JSON responses do not produce the same receipts; TCP transport does not provide request notarization.
The openai middleware reads up to 1 MiB of the request body and buffers the response. Place notary-query before it when both are configured so retrieval requests reach the query handler.
The HTTP adapter selects headers and processes structured request and response content. It can remove unsupported JSON fields, so a receipt should not be described as a transparent, byte-for-byte record of all traffic. Check a sample record and the application-visible response against the deployed version.
Unbuffered MQTT has a separate notarization path requiring an authenticated upstream QHx pod identity. MQTT 5 clients select a level through the qhx.notarization user property on CONNECT or PUBLISH. Buffered MQTT and plain TCP do not inherit this capture capability.
Use persistent storage if records must survive replacement of the Notary Pod. Capture also creates a retention obligation: requests and responses can contain sensitive operational data. Set access rules, capacity and retention periods alongside the capture policy. A local log or append-only storage interface is not cryptographic proof that a privileged administrator could not alter or remove history.
Logging and signing produce different evidence.
The client selects a level using the Qhx-Notarization-Level header on the supported HTTP path. The default is workload.
| Level | Retained material | Signature scope |
|---|---|---|
workload | A workload statement derived from the identified Pod and its metadata. | The workload statement is signed. Request and response content is not recorded at this level. |
logRequest | A request/response record linked to the workload statement. | The workload statement is signed; the request record is not. |
signRequest | A request/response record linked to the workload statement. | The request receipt is also signed by the Notary’s workload credential. |
The Notary’s signer asserts the captured fields and workload association. It does not turn the responding application into the signer. Pod or image metadata provides context for the workload statement; it does not automatically identify model weights, prove a model version or establish faithful execution.
- Application interactionThe configured middleware captures supported fields.
- Retained artifactsReceipt, linked workload statement and signing certificate.
- Independent reviewVerify signatures, trust material and the fields relevant to the review.
For an evaluation, include a successful supported request, an error response and an unsupported request. Observe which artifacts exist in each case. A missing receipt cannot be treated as evidence that no interaction occurred.
Request evidence
Illustrative anatomy HTTP · signRequest
The recorded interaction
/v1/chat/completionsCaptures the selected request and response fields.
Parsed JSON response · HTTP 200
Capture conditionsRequest receipt
- HTTP request
- Method · path · selected headers · body
- HTTP response
- Status · selected headers · captured body
- Workload statement reference
- Identifies the linked statement
Workload statement
Context for the responding workload
- Identity
- Trust domain · namespace · service account
- Pod
- Name · UID · labels · annotations
- Containers
- Declared image metadata
signRequest enabled on this capture path, the Notary signs the interaction record and its reference to a signed workload statement. The Notary is the signer; the application is the recorded workload. This illustration shows the implemented relationships, not a captured receipt or a verification result.Inspect fields and signature scope
What is captured
The request includes its method, path, selected Content-Type and User-Agent headers when present, and the read body. The middleware reads up to 1 MiB and forwards a reserialized supported request.
The captured HTTP 200 response contains the supported JSON fields after processing. This differs from a byte-for-byte record of the wire response.
What a signature covers
The receipt contains the captured HTTP fields and WorkloadStatementID. The statement supplies Pod, service-account and declared image metadata. Both signed documents identify their Notary signer and reference signing certificates through x5t#S256.
A signature supports review of covered content and its signer. It does not establish answer quality, model-weight identity, complete capture or an application authorization decision.
Keep the declaration separate from the observation.
A workflow describes intended work. An access decision permits an operation. An execution record describes what a component observed. A signature lets another party verify covered content and its signer. These records answer related questions, but one cannot stand in for all the others.
Identify each retained artifact, the participant that produced it and the evidence supporting its contents. A stable identifier names an object or run; it is not a cryptographic identity. A declared configuration, an observed result and a verifier’s conclusion remain separate records.
For an AI evaluation, retain the declared input and model configuration separately from the returned content and Notary receipt. Verify what the receipt covers. Reproducibility, model-weight identity, interpretation and answer quality need their own evidence.
Keep the record and its basis for trust.
Verification needs the receipt, linked workload statement, signer certificate or public key, any referenced content, and appropriate trust material. With the required artifacts available locally, a reviewer can check the signature without a live connection to the original issuing system.
The verifier checks the covered fields, signature and signer’s authority under the policy for the recording period. Retain applicable trust history and a policy for expired certificates and compromised keys. A signed timestamp is the signer’s assertion unless additional trusted time evidence establishes more.
Successful verification does not prove that an AI answer is correct, that an actuator performed an action, that a request was authorized, or that every interaction was recorded. Those questions require evidence from the application and its operating environment.
The security model explains host and signer compromise. The operations guide distinguishes offline verification from keeping issuance and other services available while disconnected.