Answer Audit Logs

Answer Audit

Review answer records, model-run information, and evidence references together

rawctx keeps submitted records and later changes in a reviewable form. The guide progresses from a minimal record to optional advanced trust features.

1. Minimal record

Record hashes and a source reference after the answer

The SDK uses the canonical API endpoint. Submit only question and answer hashes when raw text is not required.

import rawctx

log = rawctx.log_answer(
    application_key="support_assistant",
    environment="production",
    idempotency_key="support_assistant:req_123:msg_456",
    question_hash="sha256:235d0f0faf774748394fbb5dec9c41c51ac23b1cc6c344bc06864e7d34442516",
    answer_hash="sha256:f564d7fd469050a37898846611c9a6031be9bad19907812ec0d605b3e614b6f8",
    source_refs=[
        {
            "source_name": "support-policy@2026-06-12",
            "source_hash": "sha256:7777777777777777777777777777777777777777777777777777777777777777",
        }
    ],
    registry="https://api.rawctx.dev",
)

2. Stored data

Connect identifiers, hashes, references, and events in one record

Submit only the fields you need. Code, API names, and JSON fields remain unchanged.

Record identifiers

application_key, environment, idempotency_key, external_trace_id, external_message_id

Content commitments

question_hash, answer_hash, optional question_text, optional answer_text

References

source_refs, semantic_refs, trace IDs, registered evidence assets

Follow-up changes

correction_appended, voided, redacted, export metadata

Endpoint roles

Distinguish the Browser BFF from the SDK/API endpoint

The Hub browser UI uses the same-origin https://hub.rawctx.dev/api/bff; SDK and service integrations call https://api.rawctx.dev directly.

# SDK and service integrations call the canonical API directly.
POST https://api.rawctx.dev/api/answer-audit-logs
GET  https://api.rawctx.dev/api/answer-audit-logs/{id}
POST https://api.rawctx.dev/api/answer-audit-logs/{id}/events
GET  https://api.rawctx.dev/api/answer-audit-logs/export?format=jsonl

# The Hub browser UI uses its same-origin BFF; do not use it as an SDK base.
GET  https://hub.rawctx.dev/api/bff/tenant/answer-audit
GET  https://hub.rawctx.dev/api/bff/tenant/answer-audit/{id}

3. What it proves / does not prove

Review the integrity and bindings of submitted records

What can be verified

Whether the submitted answer record and event hash chain are internally consistent
Whether proof-bundle commitments, Merkle inclusion, signatures, and receipts bind together
Whether submitted source references and trace identifiers are present in the record

What it does not prove by itself

That the answer is factually correct
That the answer was actually delivered to a user
That a source was actually used in model reasoning
That submitted external trace or source content is itself true

4. correction, void, redaction

Append follow-up events instead of overwriting the original

A correction links a replacement answer and reason, a void marks the record as no longer usable, and a redaction narrows what can be disclosed or retrieved.

# Example context: the stored answer said "The Wholesale tier applies."
# Raw corrected_answer is shown only when workspace policy permits raw-text storage.
with rawctx.RawctxClient(registry="https://api.rawctx.dev") as client:
    client.append_answer_log_event(
        log["id"],
        event_type="correction_appended",
        reason="Policy review found that the Enterprise tier applies.",
        payload={
            "corrected_answer": "The Enterprise tier applies.",
            "corrected_answer_hash": "sha256:...",
        },
    )

correction_appendedvoidedredactedreasonpayload

5. Privacy controls

Prefer hashes and references over raw content

Enable raw-text storage only when workspace policy permits it, with retention and review access configured together.

You can record question_hash and answer_hash without sending question_text or answer_text.
Do not rely on public SHA-256 alone for personal data, secrets, or predictable sensitive text; use a tenant HMAC commitment.
Register original media as a separate evidence asset and attach only the required reference and hash to the answer record.

answer_audit_store_question_textanswer_audit_store_answer_textanswer_audit_default_retention_dayshmac-sha256

6. Export and review

Review list, detail, and event history before export

Review answer records and linked evidence in the workspace, or request a tenant-scoped JSONL or CSV export through the API.

Workspace login Reconciliation guide

export_answer_logs(format="jsonl")export_answer_logs(format="csv")correction_appendedvoidedredacted

7. OpenTelemetry (OTel)

Keep the observability system in place and attach only public-safe references

This is not an automatic LangSmith or Langfuse connector. You provide trace IDs, hashes, and references through an OTel bundle or OTLP fields.

Trace storage and access control remain in the existing observability system.
Do not send API keys, secret keys, private trace URLs, or raw tool output.
A submitted trace reference records the link; it does not prove trace truth or source use.

OTel reference guide

8. Advanced trust

Add advanced trust layers only when needed

Part A — inference commitment

Part A is an inference commitment that binds submitted model_ref, input_hash, output_hash, config_hash, and runtime identifiers to the answer record. provider_attested may be used for hosted models; it does not mean model weights were independently verified.

Part B — inference proof

Part B is an optional inference proof layered on Part A. Workspace policy must allow its backend and budget; proof state describes adapter and public-input binding checks, not answer accuracy.

Explicit proof states

ANCHORED, PENDING, LOCAL_ONLY, INVALID, and SIGNATURE_UNVERIFIED describe a confirmation stage or failure state. Do not treat them as synonyms for VERIFIED.

9. ML-DSA, Rekor, EZKL

Check each feature's verification boundary separately

ML-DSA

When an STH or checkpoint uses ML-DSA but the public verifier cannot verify that signature directly, it does not promote the result to PASS and reports SIGNATURE_UNVERIFIED.

Sigstore Rekor

Rekor is a separate witness that binds a signed checkpoint. A witness receipt does not prove answer accuracy or delivery.

EZKL

EZKL is an optional zkML backend. Keep raw proof bytes, prompts, answers, and private weights out of the public envelope, and attach the proof job and verification result as a Part B sidecar.

Public verifier specification