What you typed
Highlights show what the guard changed before anything left.
More
Hover a highlight for the rule that changed it. The colours are explained in the key above the columns.
SoCareGuard is an OpenAI-compatible endpoint. Point any client at it and add one header naming the policy pack.
from openai import OpenAI
client = OpenAI(base_url="https://kwanhui-socareguard.hf.space/v1", api_key="not-required")
reply = client.chat.completions.create(
model="openai/gpt-4.1-mini",
messages=[{"role": "user", "content": "Summarise this note...\n\n<case note>"}],
extra_headers={"X-SoCareGuard-Pack": "domestic-violence", "X-SoCareGuard-Actor": "sw-042"},
)
The same with curl, and two calls that the panel uses: the list of policy packs, and a replay of a shipped scenario's recorded reply (no model provider call; the guard and the screen run live).
curl https://kwanhui-socareguard.hf.space/v1/packs
curl https://kwanhui-socareguard.hf.space/v1/chat/completions -H "Content-Type: application/json" -H "X-SoCareGuard-Pack: disability" -d '{"replay_scenario": "uc4-over-caution-override", "replay_model": "openai/gpt-4.1-mini", "messages": [{"role": "user", "content": "<the scenario instruction and note>"}]}'
The reply carries a socareguard object with the decision, the flags (evidence and rewrite already restored), the event stream, every recipient of what left the premises, the session token that opens the session's identity map, and the row of the record. X-SoCareGuard-Audience: internal|external sets the recipient instead of reading it from the instruction. A request without X-SoCareGuard-Pack runs the deployment's default pack, and its response carries the header X-SoCareGuard-Pack-Defaulted: true. GET /v1/ledger?session=… lists the rows of the record. GET /v1/ledger/verify recomputes its chain. DELETE /v1/sessions/… purges a session's identity map and records that it did.
Highlights show what the guard changed before anything left.
Hover a highlight for the rule that changed it. The colours are explained in the key above the columns.
This text went to the model provider. Its names and numbers are stand-ins that look real by design, so that the model writes naturally, and every one is invented.
Names and numbers are replaced by stand-ins (surrogates), and details that identify someone when combined, and sensitive details, are generalised. Stand-ins are per person and stay the same within a session. Relatives who share a surname or a father's name in the note share the stand-in one, and a titled surname that could be either of two relatives is restored and marked. The instruction line (first paragraph) receives stand-ins for names and numbers but is never generalised, so a recipient named there (the client's day activity centre, her GP, an employer) leaves as typed. Detection misses some sensitive details (recall by category in docs/metrics.md), so read this column before relying on the guard. A named employer leaves as an invented name for a recipient inside the agency and as "an employer" for one outside it. The identity map never leaves this server.
The reply as received. The screen reads it in this form, before any stand-in is restored.
The reply with stand-ins restored on this server. Flagged text is underlined in red.
A generalised phrase that cannot come back keeps its colour (hover for what the record says). A withheld or generalised phrase that the model repeated exactly is restored from the record and underlined in dots. An orange mark is part of a stand-in that the model reformatted, so it was not restored.
No flag. Wording that the note itself uses may be echoed without a flag. The record below shows what left and to whom.
Released draft (supervisor view)
The released draft is shown with stand-ins, as in the columns above. Under the shared sandbox login a review never restores the names.
The record shows any edit or reordering of its rows. Keeping a copy of the record fingerprint (head hash) outside the host is the deployer's step (ship the server log).