Use case · Decision support
Scoring and triage that can defend itself in writing.
A token factory for the class of problem where AI proposes a ranking, a score, or a next action — and a human or a regulator will reasonably ask why.
The problem
What we are actually solving.
Decision support is the category of AI use where the model does not just answer a question — it nudges someone toward an action. Triage a support queue. Rank candidates. Score a loan application. Route a claim. Flag a transaction. Prioritise a maintenance backlog.
The failure mode is specific. A decision-support system that is mostly right, most of the time, with no auditable trail, is worse than no system at all: it earns the trust that lets it fail silently at the margin. The margin is where the material cost lives — the wrongly-deprioritised claim, the wrongly-ranked candidate, the case that should have been escalated and was not.
The regulatory reality is direct. The EU AI Act places systems that materially influence decisions about people — access to services, employment, creditworthiness, risk-based triage in public services — above the minimal-risk tier. High-risk systems must document their training data provenance, their evaluation methodology, their human-oversight mechanism, and their logging. A generic AI vendor is not going to document those on your behalf.
The approach
The shape of the token factory for this use case.
The context engine is narrower here than in retrieval or contracts: the unit of retrieval is often the case itself, plus a small, curated set of comparison cases. Relevance is not free-text similarity — it is a domain definition (same product line, same claim type, same applicant profile) plus a tight embedding budget.
The prompt compiler emits structured outputs, not prose. A score, a rank, a recommended action, a short rationale, and — non-negotiable — a pointer to the evidence the model used. Free-text “explanations” that are generated after the score are a cargo-cult of auditability; the real artefact is the linked evidence.
The router is conservative: decision-support latency budgets are generous compared to chat, so the cost of using a stronger model for the high-stakes fraction of cases is small. The router shifts the question from “which model is cheapest” to “which model clears the eval bar for this case class.”
The eval harness is the spine of the whole factory. A gold set of historical cases — with the actual human decision, the outcome where known, and an adjudication — replays on every model or prompt change. No eval, no deploy. This is where most real-world decision-support AI fails, because the harness is cultural, not technical.
Outcomes
What changes.
Built well, a decision-support factory reduces the routine load on human decision-makers and raises the bar on the non-routine share. Expect measurable throughput gains on the common case and no speed change on the hard case, which is the right shape: speeding up the hard case is where most AI decision-support projects quietly cause harm.
The trade-off is governance weight. Decision support is the use case that most needs a named human owner, a quarterly review cadence, and a paper trail of model changes. If the organisation is not ready to carry that weight, the right answer is to narrow the first slice until it is.
EU AI Act risk tiering. Many Nordic decision-support use cases land in the high-risk tier — credit, employment, essential services, insurance risk pricing. High-risk obligations (data governance, technical documentation, logging, human oversight, transparency) become enforceable through 2026–2027. A token factory is not a compliance product, but its ordinary outputs — versioned prompts, routed model calls, replayable evals, citation trails — are the artefacts the Act assumes exist.
Honesty
Expert approach based on adjacent delivered work. I have not shipped a production decision-support token factory under Blue Abraham; the approach above is how I would build it given what I delivered in aviation technical documentation. See Technical documentation for the delivered parallel.
Aviation engineering answers are themselves decision support under a different name: an engineer reads a recommendation, weighs it, and signs a defensible decision. The architecture that made those recommendations safe to rely on is the same architecture decision support needs — with a stricter governance layer on top.
Next step
Talk about scoring and triage that can defend itself in writing..
The usual first engagement is an architecture review. Say so on the form, or write directly.
Get in touch