Guardrails and escalation

Escalation is not the failure path, it is a first class product surface, and it is usually the one that decides whether a system is allowed to stay switched on. A handoff that arrives as a cold transcript costs a person more time than doing the task themselves. A handoff that arrives with the record retrieved, the evidence assembled and the reason for the uncertainty stated is the thing that makes the automation worth having. We design that surface before the happy path.

What we actually do

• An authority model written down before implementation: act, recommend, or refuse, with the threshold for each and the named owner of the decision
• Schema validation on every output, so a malformed response is caught by code rather than by a customer
• Grounding checks that verify a claim against a retrieved source before it reaches a user, and refuse rather than assert when it cannot
• Confidence scoring calibrated against your labelled set, not taken from a provider's self report
• Escalation payloads that carry the record, the retrievals with versions, the reasoning trace and the stated reason for the handoff
• Prompt injection defence at the boundary where untrusted content enters, treating retrieved and user supplied text as data rather than instruction
• Data handling designed to your controls: what leaves your perimeter, what is redacted before it does, what is retained and for how long, and whether anything can be used for provider training
• An immutable decision log with a per case export, built for the question an auditor asks in nine months

What we instrument

Measurements, not results. These are the readouts we put in place so that you end up with numbers about your own system. There are no values on this page because a value here would be somebody else’s.

• Escalation rate, and the split between low confidence, policy rule and validation failure
• Human time per escalated case, measured before and after
• Override rate: how often a person disagreed with a recommendation the system was confident about
• Grounding check failures caught before output
• Coverage of the decision log: proportion of runs with a complete, exportable record

Where this stops working

• No guardrail set makes a generative system incapable of error. The design goal is that errors are caught, bounded, visible and reversible, and we will not claim more than that
• Confidence scores are useful as a routing signal after calibration and misleading before it. Anything quoting one out of the box is quoting a number nobody checked
• Fully air gapped deployment narrows the model options substantially. Raise it in the first conversation rather than in week nine

What we work with

Named as plain text. None of these is a partnership, an endorsement or a default: the right one is chosen per engagement, usually the one your team already runs.

• Schema validation with typed contracts on every output path
• Policy engines for deterministic rules that should never be a model's judgement
• Redaction and classification at the perimeter
• Immutable append only logs in your own cloud storage