Request Triage
DEPL_2026.09.06An LLM parses a free-text request into structured output that follows a predefined schema. Deterministic code then maps that output to actions from a fixed action table. The LLM only classifies; it never executes anything.
One call splits the message, classifies each ask and pulls the fields the tables need.
The model only says what the request is. A table decides what happens next — and where it has to stop and ask a person.
The tables answered it outright — a tier-1 grant, a cited policy answer, or a small purchase.
A standing team owns this work. It goes to their queue with the facts attached.
Nobody below a named authority may decide this. It goes up, with the reason.
Policy refuses it, or the message tried to rewrite our rules. Nothing was actioned.
What It Does
Internal teams send free-text requests (access, data pulls, policy questions, bugs, purchases) to a single inbox. Each message produces one auditable record.
Code first masks obvious PII. A single Claude or Laya (Local Jev) call then splits the message into individual requests and, for each one, identifies the intent and extracts the fields that intent requires. The model only classifies; it never executes anything.
Everything after that is deterministic Python. Prices are annualised and totalled before any rule evaluates them. The intent selects one of seven action tables, and the extracted fields select a row, where the first match wins. Each row specifies the action, the target team and the required approver. All 33 rows live in one file, and nothing that grants access runs without passing the approval gate.