Session Evidence Receipt

What the receipt is, and is not

QiXMind is OrchIntel's governed mental health AI workspace, built on QiXHealth, for adult and youth mental health services. It is not a chatbot, it is not designed to diagnose, and it makes no claim about clinical effectiveness. The receipt records what the service recorded about the safeguards on one AI-assisted session. It is issued by the IOA Core evidence library. It is signed with a private Ed25519 key and can be verified offline using the corresponding published public key, so a service auditor, an ethics committee, a regulator or a family can confirm that it has not been altered since it was signed. Verification does not check the facts it records: gate results are as reported by the QiXMind runtime, and roles, care events, disclosure, consent and follow-up completion are as stated by the signing clinician.

The receipt contains hashes, identifiers, roles and timestamps. It never contains clinical text, names, dates of birth, NHI numbers or the matched words that triggered a gate.

The four questions it answers

1. What was sent to the model? The receipt records a fingerprint (SHA-256) of the de-identified message sent to the model, the declared de-identification mode and detection counts. Someone holding that exact message can check that it matches. The message itself is not kept. The fingerprint does not show that de-identification was complete.
2. Which configured checks fired? Every gate declared on the governing profile (risk to self, risk to others and imminent danger for adult services, plus child protection for youth services) is listed in order with whether it fired, its severity, its category and the lexicon version. Gates run on the model's own output before anything is committed; they do not read the text entered by the clinician. They look for specific wording and can miss risk. If the gate check cannot run, the output is held, and the hold itself is recorded. If the model declines to write a draft or returns an empty one, the output is held and cannot be signed off, so no receipt is issued for it.
3. Who acknowledged the output? The role the signer selected (clinician or supervisor, never a name), the review event identifier, the time, and the list of fired gates that were explicitly acknowledged. A fired gate that was not acknowledged blocks sign-off, so a receipt cannot be issued while a fired gate is unacknowledged. A receipt does not show that every risk was flagged.
4. Was the follow-up recorded as completed in time? When a gate fires at escalate severity and the session is signed off, a follow-up obligation is created with the profile's deadline (24 hours by default for adult and youth mental health). The receipt records whether a role marked it complete, which role, whether that was late, and whether it was marked overdue. It does not record what was done. When the follow-up status changes, a new receipt can be issued that names the one it supersedes.

What is included

• Receipt identifier, the evidence bundle it describes, the workflow, care setting, profile and jurisdiction.
• Model input hash and length, de-identification summary. Model output hash and length.
• Ordered gate results, detector version and status, overall action, lexicon versions.
• Acknowledgement by role with review event identifier and time.
• Escalation follow-up: obligation identifiers, deadline, status, closure role and time, alert, and how overdue is evaluated.
• Software versions and explicit disclaimers: no diagnosis, no efficacy claim, not youth-facing, no content included.
• The profile identifier is recorded. The version of the profile and policy applied is not yet recorded; this is being added.

Jurisdiction block

The session's jurisdiction is recorded as a code such as NZ or AU-NSW, with the country, the state or territory, the policy pack, and the identifiers of the jurisdiction templates shown to the clinician. Only template identifiers are recorded, never their text, so the receipt stays small and a reader can see which notices were shown, by identifier. The identifiers do not yet carry a version. In Australia, state and territory templates layer over the national ones; see jurisdictions for what each template covers.

Optional longitudinal and care-event fields

Care is longitudinal, so a receipt can carry a few more fields when the service records them. They are optional, the schema identifier stays qixmind.session-evidence-receipt.v1, and a receipt without them is unchanged.

• Episode. The service's own pseudonymous episode reference, so several sessions can be linked into one episode of care. It is rejected if it looks like an NHI or Medicare number. Do not use names.
• Care event. Clinician review, service review, follow-up or escalation.
• Review state. Reviewed, escalated to the service while a follow-up is open, or closed once it is confirmed.
• Withheld. Counts of what was held back and why, for example one model output held by a safety gate. Counts only, never the content.
• Disclosure. What the clinician states about whether AI use was disclosed to the patient and how, whether consent was recorded, and an opaque reference to a consent record. These are recorded as stated, not independently checked. They relate to the Medical Council of New Zealand's guidance to tell patients and always record whether consent was obtained, and to the AHPRA guidance on transparency and consent.
• Inference. The kind of output involved, such as a summary or a risk indicator flag. The receipt schema does not accept triage or diagnosis as inference types. This limits what a receipt can record; it does not by itself prevent a draft from containing such content. Regulatory status depends on intended purpose; QiXMind is not designed to diagnose, recommend treatment or triage.

The schema has room for self-reported and ambient signal events in the future. QiXMind does not collect them today.

Verify offline

Download the public verification key from the permanent QiXMind registry path, then keep the key and the receipt together.

pip install ioa-core
curl -o qixmind-pubkey.pem https://orchintel.com/.well-known/qixmind-pubkey.pem
ioa verify qixmind-receipt-<id>.json qixmind-pubkey.pem

The verification command does not contact OrchIntel. It exits non-zero when the signature, the signing key identity or any signed field has been changed. Verify against the signature envelope's canonical hash with ioa verify; the bundle's informational evidence_hash field is not the signed value.

Public-key registry

QiXMind publishes a registry rather than relying on one permanent key. Each entry maps a public_key_id to its public key and issuance window. When keys are rotated, retired public keys will remain listed so earlier receipts continue to verify. The registry lives at /.well-known/qixmind-key-registry.json and is also served by the QiXHealth console at /api/qixhealth/receipts/key-registry. The private signing key is held in a dedicated secret and is never published or shared with any other product.

The current key is ed791d2e07a29414, valid for issuance from 2026-10-13 through 2028-10-13. The demonstration script prints a notice that its receipts are signed with an ephemeral key; those receipts do not verify against the published registry.

What the receipt does not decide

A fired child protection gate records that the model's output contained language consistent with abuse, neglect or an unsafe home. In New Zealand, reporting a concern under the Oranga Tamariki Act 1989 section 15 is permissive, not mandatory. In Australia, who must report and what must be reported differ by state and territory, so the acknowledgement shows the summary for the service's configured state or territory. In both countries the gate obliges acknowledgement and follow-up; it does not report and it does not determine whether a legal duty applies. The receipt likewise does not grade clinical quality, does not replace the clinician's assessment, and does not assert that any outcome was correct. It shows, in a form that cannot be altered without detection, what the service recorded about the safeguards and what the recorded roles stated they did. A signed receipt establishes integrity and provenance within its verification scope. It does not prove clinical correctness, complete capture, that every risk was flagged, or legal compliance.