Triage

The AI files the obvious and holds the rest

Most triage tools guess a category and let you correct it later. This one only acts where there is nothing to decide: the reading has to agree with what the client already said it was. Everything else is held for a person, with the argument attached.

The policy

Filed on agreement, held on anything else

Every client request is read on arrival and given a type and a priority. If that reading matches the type the client already suggested, the request is filed as an issue or a feature or change request straight away and stamped as sorted by AI.

Everything else is held, and there are exactly three ways that happens: the reading disagrees with the client's suggestion, the client suggested no type at all, or the request is not delivery work and needs a person for another reason.

  • No corroborating suggestion means nothing is filed alone
  • Questions and billing enquiries map onto no work item, so they wait for a person
  • A held request appears as its own tile in the team workspace

Held for human triage

REQ-044bug, high (disagrees with feature, held)Held
REQ-043billing, low (needs human triage, held)Held
The hold

A hold arrives as an argument, not a blank form

A held request carries one sentence saying why: what the reading thought it was, at what priority, and what the client said. Whoever picks it up is reading a position they can agree or disagree with, which is a faster start than an empty triage screen.

A request the client marked urgent keeps that priority. The classifier only ever answers low, medium or high, and applying its answer would quietly demote the request, so it does not. When it does set a priority, the change is written onto the record with the old value beside the new one.

  • The reasoning is an audit row on the record, not a transient toast
  • Human triage is unchanged: sort it, and add your own reason if the call needs explaining
  • Nothing is auto-closed, auto-assigned or auto-replied to, ever
REQ-044Held

The invoice PDF is missing a line

Raised by the clientSuggested: feature request
Read as bug, highDisagrees with the suggestion
Waiting for a personPriority untouched
Provenance

You can always tell which ones it touched

An auto-filed record is stamped as sorted by AI, with the category and priority as the reason on the chip, so a filed item never pretends a person read it. Every verdict, filed or held, is written to the record's own timeline as a system actor rather than under somebody's name.

If the classifier cannot be reached it is retried once and then the request is held, marked unavailable. It never guesses a category to fill the gap. You can re-run the classification on any request from the record, and ask for an advisory second reading on an item that is already filed, which records what the model thinks now and converts nothing.

  • One retry, then a hold, and a plain reason for the hold
  • Advisory re-reads are opinions on the record, never conversions
  • Classification runs against a model endpoint configured for the deployment
Sorted by AI (bug, high)On the chip, on the record
Unavailable after retryHeld for triage, never guessed

AI triage is enabled per deployment, on request. Without it every request goes to human triage, which is the same behaviour as a hold.

Questions ยท AI triage

The things teams ask about this

Is AI triage switched on when we start?

No. It is enabled per deployment, on request, and until it is, nothing is sent anywhere and every request goes to human triage. Turning it on changes what happens to the unambiguous requests only; turning it off puts every request back through a person, which is the same behaviour a hold already produces.

Where does the reading actually happen?

Against a model endpoint configured for the deployment, called with the request's title, description, suggested type and priority. The call is queued rather than run inside the write, so filing a request never waits on a model, and a classifier having a bad day cannot fail the thing that triggered it.

What is it never allowed to do?

It never files a request the client gave no type for, never overrides an urgent priority, never invents a category when the endpoint cannot be reached, and never closes, assigns, replies to or deletes anything. The only automatic action in the whole feature is converting a request whose reading already agrees with the client.

Can we ask for a second reading on something already filed?

Yes, from the record. An advisory re-read records whether the model still agrees with where the item ended up and nothing else: no conversion, no status change, no reassignment. It is useful on an old record somebody suspects was sorted into the wrong lane.

Next step

See it against your own work

Thirty minutes on a call, one of your real client projects on the screen, and an honest answer about whether this part of the product earns its place in how you work.

partnerships@dhcertainty.com