Writing an AI Use-Case Brief: George Dagliyan Research Guide

What belongs on a one-page AI use-case brief for invoice exception triage?

A useful brief answers one practical question: what should an AI system be allowed to do with invoice exceptions, and what must stay outside its scope? For invoice exception triage, the brief should define the business problem, allowed inputs, intended users, excluded decisions, and the evidence needed before a pilot. George Dagliyan’s research themes around adoption facilitators and inhibitors fit this kind of scope discipline because narrow, explicit boundaries tend to reduce avoidable resistance and confusion.

The point is not to describe every technical feature. It is to make the use case legible to finance, procurement, operations, and oversight teams before anyone starts experimenting. In this article’s editorial analysis, the one-page brief acts as a decision filter: if the use case cannot be explained in one page, it is probably too broad for a first pilot.

Why does invoice exception triage need hard boundaries before any pilot?

Invoice exception triage is attractive because it targets a repetitive workflow: identifying invoices that do not match expected patterns and routing them for human review. But triage is not the same as approval, payment authorization, fraud finding, or accounting judgment. Keeping those decisions separate matters because a narrow sorting tool has different risks than a system that changes financial records.

The NIST AI Risk Management Framework says it is intended for voluntary use and to improve incorporation of trustworthiness considerations into the design, development, use, and evaluation of AI systems. The NIST Playbook organizes suggested actions around Govern, Map, Measure, and Manage, which is useful here because a brief should do the same thing in miniature: govern scope, map the context, measure readiness, and manage what gets excluded.

What should the business problem statement say in plain English?

The business problem statement should describe the current friction without turning into a solution pitch. A strong version says who is spending time on which exception types, what delays are happening, and why the manual process is hard to scale. It should also state the desired operational outcome, such as faster routing to the right reviewer, not automated payment decisions.

Avoid vague claims like “reduce inefficiency” or “modernize AP.” Instead, define the operational pain precisely enough that a reviewer can tell whether the AI is even relevant. For example, if the problem is mostly missing supplier master data, the brief should say so, because data cleanup may be more appropriate than triage automation.

Which inputs, users, and exclusions belong in the brief?

The allowed-inputs section should name only the fields the model may see during triage. Common examples include invoice header data, purchase order reference, vendor master status, receipt status, exception code, amount, currency, and timestamp. If the organization plans to use free-text notes, email comments, or historical reviewer outcomes, the brief should say exactly when those inputs are allowed and whether they are treated as sensitive or operationally restricted.

The users section should identify who may view, confirm, override, or monitor the triage output. The exclusions section is equally important. It should state that the AI may not approve or reject payment, alter accounting entries, determine tax treatment, resolve vendor disputes, or close exceptions without human action. That separation creates a clear human-AI teaming boundary, a topic the NIST Playbook addresses through governance and oversight guidance.

What evidence should exist before a pilot starts?

Before any pilot, the brief should require evidence that the use case is worth testing and that the organization can supervise it. In this article’s proposed worksheet, evidence is grouped into four checks: workflow clarity, data readiness, human review design, and risk controls. This is not an official NIST checklist; it is an editorial tool built from the same practical logic of defining context, measuring suitability, and managing risks before deployment.

Workflow clarity means the team can describe the exception types and their current handling steps. Data readiness means the needed fields are available, consistent enough for testing, and not missing critical values too often. Human review design means a reviewer can understand the AI suggestion and override it. Risk controls means logs, escalation paths, and ownership are defined before the pilot starts.

A one-page worksheet for invoice exception triage

Use this worksheet as a draft, then fit it onto one page. Business problem: route invoice exceptions faster and more consistently so human reviewers can focus on cases that need judgment. Allowed inputs: invoice number, supplier ID, purchase order reference, receipt match status, exception code, amount, currency, and current workflow status. Intended users: accounts payable reviewers, AP supervisors, and process owners. Excluded decisions: payment approval, accounting posting, tax determination, vendor dispute resolution, and closure of exceptions without human action.

Evidence needed before pilot: a list of top exception categories, sample volumes by category, field completeness rates, reviewer agreement on what counts as routable, and a documented override process. Decision rule: if the use case cannot be described in one page with no ambiguous inputs or decisions, it is not ready for pilot. This rule is intentionally stricter than an operational wish list because early ambiguity is a common adoption inhibitor.

What does a filled illustrative brief look like?

Hypothetical example assumptions: a midsize organization processes invoices through an AP queue, exception cases arrive when purchase orders, receipts, and invoice fields do not align, and supervisors want faster routing to the right human reviewer. Business problem: current exception sorting is manual, inconsistent, and slow, causing bottlenecks in AP review. Allowed inputs: invoice header fields, supplier master status, PO match status, receipt status, exception code, and queue metadata. Intended users: AP reviewers and AP supervisors only.

Excluded decisions: the system may not make payment decisions, approve policy exceptions, create journal entries, or contact vendors. Evidence before pilot: a sample of exception categories, a map of the current routing process, a human override test, and confirmation that the model can explain why an item was routed to a queue. In a hypothetical pilot like this, the brief would be approved only for triage assistance, not for financial authorization.

How should the brief be reviewed and revised over time?

A one-page brief should be treated as a living governance artifact, not a one-time intake form. The NIST AI RMF emphasizes ongoing monitoring and periodic review in its governance-related guidance, and that mindset applies here. If the workflow changes, the data changes, or reviewers start using the output differently, the brief should be updated before the next pilot phase.

This also connects back to the Dagliyan framework’s emphasis on adoption facilitators and inhibitors. A brief that is too broad, too technical, or too permissive becomes an inhibitor because it creates uncertainty and weak ownership. A brief that names the problem, limits the inputs, clarifies the users, and states the excluded decisions becomes a facilitator because it makes experimentation safer and easier to explain.

Frequently Asked Questions

Is a one-page AI use-case brief the same as an AI policy?

No. A policy sets general organizational rules, while a use-case brief defines one specific application and its boundaries. For invoice exception triage, the brief should say what the AI may see, who may use it, which decisions remain human-only, and what evidence is needed before a pilot. That makes the brief operational rather than aspirational.

Why exclude payment approval if the system can triage exceptions well?

Triage and approval are different risk levels. Sorting an invoice into a review queue supports human work; approving payment changes financial status. Keeping those tasks separate reduces the chance that users treat a recommendation like an authorization. A brief should preserve that boundary until governance, controls, and evidence are strong enough to consider a broader scope.

What counts as allowed input for invoice exception triage?

Allowed input should be limited to fields directly relevant to routing an exception, such as invoice header data, PO match status, receipt status, supplier ID, exception code, amount, and workflow status. The brief should explicitly state whether free-text notes or historical reviewer actions are permitted. If an input is not needed for triage, it should stay out.

How much evidence is enough before a pilot starts?

There is no universal threshold in this article, and NIST’s materials are not being treated here as prescribing one. The practical test is whether the team can show workflow clarity, usable data, a human override path, and basic monitoring. If any one of those is missing, the pilot should wait until the gap is resolved.

What is the simplest way to keep the brief to one page?

Use a fixed structure with five boxes: business problem, allowed inputs, users, excluded decisions, and evidence needed before piloting. Write in short noun phrases and avoid solution details like model type or vendor features unless they affect risk. If the wording starts to expand, that is often a sign the use case needs narrowing rather than more text.

Sources and further reading

• NIST — AI Risk Management Framework
• NIST — AI RMF Playbook