Vertical SaaS: legal, fintech, healthcare
Somebody will point at one paragraph of AI output and ask what the machine was told before it wrote that. Not today. Eighteen months from now, in a room where the person asking has subpoena power or a regulator's letterhead, about a matter whose engineer has since left. Your answer is either a record or a shrug, and you will have decided which one it is long before the question arrives.
This page is for whoever signs off on that. Usually the person carrying compliance in a product that does contract review, claim triage or prior authorisation.
An audit trail is written forwards
The instinct is to treat auditability as something you switch on when a customer asks. Add logging, keep it a while, extract the report when someone needs it. That works for debugging and fails for evidence, because evidence is about the specific request that already happened, in a form nobody can quietly amend, tied to a case number the auditor recognises. If the matter id was not attached at the moment of the call, it does not exist afterwards. Reconstructing it from timestamps is exactly the sort of answer that makes an auditor take a much closer look at everything else.
So the record is produced during the request, and it is pushed to a store you own rather than parked in ours. Your retention obligation is set by your regulator, and it will almost certainly outlive any vendor's default. Signed webhooks put each event in your evidence store as it happens, which means the copy that matters is under your retention policy, your access control and your legal hold.
What Ringside does not do
Worth being blunt, because the alternative is you finding out during a security review. There is no PII redaction in the API. Ringside will not scrub names, account numbers or patient identifiers out of your prompts. That boundary stays yours: your app decides what leaves your systems, and the sample below passes text your code already redacted. What Ringside gives you is the pre-check on the way in, and the record of what crossed on the way out.
What you actually get
- • A free pre-check. OpenAI-compatible
/v1/moderationscosts nothing, which removes the usual excuse for skipping it on high volume paths. Themoderation.flaggedwebhook fires when content crosses your thresholds, so a block is an event in the record and not just a 422 your app swallowed. - • Case-level tagging.
FC-CustomerplusFC-Tagtie each call to a matter, claim, patient or account, as a comma-joined value up to twenty tags. Slice it later with/v1/usage?group_by=tag, and the same tags ride along on the webhook payload into your evidence store. - • Signed delivery with retries. Run lifecycle and moderation events go out signed, so your compliance store can verify the sender, and a receiver that was down does not leave a gap in the record.
Architecture
In code
# Step 1: moderate the input before it touches a frontier model.
# /v1/moderations is free, so there is no cost argument against running it.
mod = client.moderations.create(
input=document_text,
model="text-moderation-latest",
)
if mod.results[0].flagged:
raise HTTPException(422, "blocked by policy")
# Step 2: your app decides what leaves your boundary. Ringside does not
# redact for you; redacted_text is something you produced.
resp = client.chat.completions.create(
model="fc:anthropic/claude-sonnet-4.6",
messages=[
{"role": "system", "content": LEGAL_SYSTEM_PROMPT},
{"role": "user", "content": redacted_text},
],
extra_headers={
"FC-Customer": matter.customer_id,
"FC-Tag": f"matter:{matter.id},doc_class:{doc.classification}",
},
)
# Step 3: the event lands in your compliance store, signed.
# (registered once: events=["run.completed","moderation.flagged"])