AI safety report triage with an audit trail

Safety reports arrive however people can get them out: a voice memo from a forklift driver, a chat message from a night-shift lead, an email with two camera stills attached. Someone has to turn each one into a structured incident record, rate its severity, and route it to the right owner fast enough to matter. An LLM can do this work today. What it cannot do, on its own, is prove it did the work right - and when the report that got misrouted involves an injury, "the model summarized it wrong" is not an answer your compliance team can file.

Pebble builds safety-report triage as a verified environment: the intake process mapped into numbered steps, each step with its own verification check. A model runs the process. The checks, not the model, decide whether each step passed.

How does a verified environment triage a safety report?

It walks the report through numbered steps, and each step must pass its check before the run continues. Here is a plausible step map for incident intake at an ops or supply-chain company.

Step 1: Ingest the report from whatever channel it arrived on. Voice gets transcribed, chat and email get captured, camera stills get attached to the record. Check: computed. Code confirms a record exists with a source, a timestamp, and a reporter, and that every referenced attachment actually landed. No model grades this.

Step 2: Extract the structured incident record. The model pulls out location, time, people involved, equipment, what happened, and any counts - units damaged, pallets involved, people treated. Checks: classified and computed together. A small model, trained for this one check and scored against held-out examples before it is trusted, catches illegible or ambiguous fields, like a location that could be two different docks. And where a stated fact can be checked against a system of record, code checks it: does the reported count match the sensor count? That one is computed - the gold standard, verified by code, not by a model grading a model. (The full check taxonomy is in the glossary.)

Step 3: Classify severity. Near miss, first aid, recordable, lost time, regulatory-reportable - whatever tiers your program uses. Check: classified. The severity classifier is trained on your historical incidents or open data, and scored against held-out examples before it is trusted. Its accuracy is a number you can read, not an assurance.

Step 4: Route and draft the escalation. The run assigns the incident to the right owner and drafts the escalation - the message to the site lead, the notification to EHS, the regulator-facing summary if the severity tier requires one. Checks: routing is computed, code confirms the incident landed in the queue your severity matrix says it should. The drafted escalation is judged: your safety operators annotate a few hundred pass/fail examples of acceptable escalations, Pebble trains a judge on them, and reports judge-human agreement on held-outs. Where agreement is too low, a human stays in the check. For regulatory-reportable incidents, that human review is likely permanent, and the environment is built to keep them in the loop rather than pretend otherwise.

Step 5: Confirm the loop closed. Check: computed. The record is complete, notifications sent, acknowledgments logged.

What happens when a step fails?

The run stops at the failed step, gets fixed, and resumes at that step, not from scratch. If the reported count fails against the sensor count at step 2, the run halts there. Someone reconciles the numbers, and the run resumes at step 2. Severity classification and routing never operated on the wrong count, because the wrong count never got past its check.

When something goes wrong you get a step number, not a transcript to scroll through. "Report 2213 failed at step 3, severity check" is something your EHS lead can act on before the shift ends.

What does compliance actually get?

A run record per report: every step, every check result, every fix, in order. When an auditor or a regulator asks how a specific incident was handled, the answer is the record, not a reconstruction. Postmortems start from a step number instead of an argument about what the model was thinking. And reliability stops being a claim: it is a percentage read off run history - this many reports, this many clean runs, failures concentrated at these steps. That is the difference between a demo and a system you can put in front of an audit. The same structure that makes triage auditable makes AI invoice reconciliation auditable on the finance side, and AI claims processing auditable on the insurance side.

What do you own afterward?

The run records, and eventually a model trained on them. Every completed run is appended to a training set: a worked example of your triage process done correctly, with verified checkpoints at each step. Once the history is deep enough, that dataset post-trains an open-source model you own, running your triage at a fraction of frontier API cost per run, that no one can reprice or deprecate out from under you.

How does an engagement start?

With a scoping call, and if an environment is the wrong tool for your intake process, Pebble says so on the call. Then about a week of discovery inside your systems under your access model - Pebble keeps the step map and none of your data - ending in a written proposal. Then the build, exercised against real reports before it is called done. Then it runs, on your infrastructure or Pebble's, with a retainer.

If your safety reports deserve a step number instead of a transcript, book a scoping call: [email protected].