Skip to content
allanninal.dev/build
Collaborate

Part 3 of 7 · Safety incident logger series ~5 min read

How a report gets triaged

Triage is the only place in this system where a model does anything, and its job is narrow: get a serious report in front of somebody in minutes rather than hours. It does not decide anything, and the design goes to some trouble to make sure it cannot.

Key takeaways

  • Severity is proposed to route the report, and confirmed by a person afterwards.
  • Routing speed is set by the proposal: minutes for high, the same hour for medium.
  • An injury or anything involving a vehicle skips triage and routes immediately.
  • The proposal errs upward. Over-routing costs somebody a minute; under-routing costs more.
  • The confirmed severity is what everything downstream counts, never the proposal.

Propose, then route, then confirm

How a safety report is triaged and routedA vertical chain of five steps entered by a box labelled A report, with a description and a photo. Step one asks whether it involves an injury or a vehicle, judged by keywords rather than by a model; if so it exits to Route now, skipping everything else. Step two proposes a severity with a single Bedrock call, grounded by your own severity guide. Step three routes by that proposal, within minutes or within the hour, using the routing rules for who and how fast. Step four has a person confirm or change it. Step five is the Confirmed severity, which is what everything downstream counts. A note says the first check is keywords on purpose, because an injury must not wait for a model call.AWS ACCOUNTA reportdescription and photoInjury or vehicle?keyword, not modelRoute nowskip everything elseyesPropose severityone Bedrock callSeverity guideyour own wordingRoute by proposalminutes, or the hourRouting ruleswho, and how fastA person confirmsor changes itConfirmed severitywhat everything countsThe first check is keywords on purpose: an injury must not wait for a model call.
Fig 1. How a report is triaged. The keyword check in front is deliberate belt-and-braces: the highest-consequence reports do not depend on a model call succeeding.
  • App integration
  • Machine learning
  • Management
  • Analytics
  • Front-end & mobile
  • People

Why keywords in front of the model

A report containing “cut his hand” or “the van hit” must route immediately, and it must route even if Bedrock is having a bad afternoon. So a small keyword list runs first — injury words, vehicle words, words like ambulance and hospital — and any hit routes at the highest urgency without waiting for anything.

It will over-trigger occasionally. “Nearly cut my hand” is a near miss and will be routed as though somebody were injured, which costs a manager thirty seconds. That is a good trade and it is the trade to make consistently: the cost of over-routing is a minute of somebody’s attention and the cost of under-routing is not.

What the proposal is for

Not to classify the incident — a person does that. Its only purpose is to decide how fast the report needs to reach somebody, which is a question that has to be answered before a person can look at it, or there is no point answering it at all.

ProposedRoutesTo whom
HighImmediately, phone and emailSite manager and the safety lead
MediumWithin the hour, emailSite manager
LowIn the daily digestSite manager
UnclearWithin the hour, as mediumSite manager, flagged as unclear

Unclear routes as medium rather than low, which is the same erring-upward principle. A report the model could not place is more likely to be unusual than trivial, and unusual is worth an hour of somebody’s attention.

The confirmation

Whoever the report routed to sets the real severity, and it is one tap on the routing message. That confirmed value is what every count, report and trend in the system uses. The proposal is kept alongside it, and the difference between the two is quietly one of the more useful things the system records.

How proposed and confirmed severities compare over a periodA horizontal row of five boxes. Proposed high and confirmed high: forty-one. Proposed high but confirmed lower: nine. Proposed low but confirmed higher: two. The two matter: those were under-routed. Adjust the guide: rather than the model. A note says nine over-routes are fine and two under-routes are a change to the severity guide.PROPOSAL VERSUS CONFIRMATIONProposed highconfirmed high: 41Proposed highconfirmed lower: 9Proposed lowconfirmed higher: 2The 2 matterunder-routedAdjust the guidenot the modelNine over-routes are fine. Two under-routes are a change to the severity guide.
Fig 2. What the gap between proposal and confirmation tells you. The asymmetry is the point: over-routing is noise and under-routing is a miss.
  • App integration
  • Machine learning
  • Management
  • Analytics

Two under-routes in a period is a prompt to look at what they described and add that wording to the severity guide, which is a sheet rather than a prompt in code. The guide is written in your own terms — “anything involving working at height is at least medium” — and it grounds the proposal, so improving it is a five-minute edit by somebody who knows the business rather than a prompt-engineering exercise.

Next: the actions, which are where an incident log stops being paperwork.

All posts