The first question in a digital-intelligence project is rarely “Which model should we use?” It is “Which decision keeps going wrong, taking too long, or depending on one person’s memory?” A new search tool can find more information, but it cannot tell a team which answer is safe to give or which tradeoff it has authority to make. Those boundaries must come from the work itself.
Choose one recurring decision that matters, can be described, and can be checked. Write what a good decision requires, who owns it, and what happens when the evidence is missing. Only then decide whether better records, a checklist, search, or AI assistance would help. This article develops that choice in detail. The series introduction explains the larger loop of decision, evidence, retrieval, action, and learning.
Recognize a decision hiding inside a task
Teams often describe a project as a task: answer customer emails, write listings, create reports, or schedule repairs. Each task contains decisions that may have different evidence and consequences.
Consider a small seller receiving a return request. “Process the return” may include at least five choices:
- Does the request match the order and buyer?
- What does the published policy say, and which version applied when the purchase was made?
- Is the item damaged, defective, misdescribed, or simply unwanted?
- What response can a staff member offer without further approval?
- Does the case expose a recurring problem with a product or listing?
A tool that drafts a polite response helps with wording. It does not resolve those five questions. If the team starts with the entire task, it may automate the easiest visible step while leaving the costly judgment untouched. If it names the decisions, it can improve the right records and approvals.
Ask employees or yourself what they check before saying yes, no, or “I need to find out.” Watch one real case from start to finish. The point where someone opens three tabs, messages a colleague, or says “I think the rule used to be…” is often where a decision needs better support.
Select a candidate with a simple scoring conversation
Do not rank projects by how impressive the technology sounds. Compare them by four practical questions:
| Question | Strong early candidate | Poor early candidate |
|---|---|---|
| How often does it occur? | Repeated enough to learn from several cases | Happens once a year with little repeatable structure |
| Can the outcome be checked? | A person can compare the decision with records or later events | Nobody agrees on what success means |
| Is the evidence available? | The necessary facts exist and have owners | Critical information is inaccessible or unreliable |
| What is the cost of error? | Mistakes are limited and recoverable | A mistake could seriously harm a person or create an irreversible commitment |
These are prompts for discussion, not a mathematical score. A high-frequency decision with severe consequences may require professional oversight, formal controls, and a longer test rather than a quick pilot. A low-frequency decision can still matter greatly if it is a known bottleneck. The table helps a team say why a project is appropriate.
The NIST AI Risk Management Framework core treats context, expected benefits and costs, human oversight, and risk as part of mapping an AI use. Its framework is voluntary and broader than this small-team exercise. The same principle applies here: understand the decision’s context before deciding how much authority a tool may have.
Write a decision charter on one page
A decision charter is a short agreement about one choice. It prevents a project from drifting from “help me prepare a draft” to “let software commit us to a promise.” It can live in a document or project note, provided the people doing the work can find the current version.
Use these fields:
- Decision: What exact choice is made? Begin with a verb, such as quote, approve, classify, schedule, publish, or escalate.
- Trigger: What event brings the choice to the team?
- Owner: Who is accountable for the rule and its revision?
- Required evidence: Which records must be present and current?
- Permitted action: What may a staff member or tool do without further review?
- Stop rule: Which missing fact, contradiction, or unusual case requires escalation?
- Outcome check: How will the team know later whether the decision held up?
- Review date: When will the rule and its evidence be checked again?
For a small repair shop, the charter could say: “Quote a completion date after the technician confirms scope, required parts are available or have a confirmed arrival, and capacity is reserved. The service manager owns the rule. If the part date is only an estimate or the diagnosis is incomplete, send a status update and schedule a check instead of promising a completion date. Review missed promises monthly.”
This is not a universal policy. Its value is that the shop can edit it when real cases show that a condition is too strict or too loose. It also identifies which source records need to be accurate. A technician’s confirmation, a supplier’s estimate, and a booked slot are different kinds of evidence.
Separate facts, policy, and discretion
Many bad decisions come from treating a fact, a rule, and an exception as if they were the same thing.
A fact is a claim about a specific case: the part is on the shelf, the buyer purchased on a certain date, or the test showed a defect. It should point to a record or observation. A policy describes how the organization usually acts: returns within a stated period receive a particular remedy. It needs a version, effective date, and owner. Discretion is a permitted departure from the usual rule, often because the case has a feature the policy did not anticipate. It needs a named decision-maker and a reason.
Imagine an AI assistant asked, “Can this buyer return the item?” If it retrieves the current return policy but the order predates a policy change, the answer may be wrong despite citing a real document. If it reads a prior exception as the general rule, it may promise a remedy the team did not authorize. A better system labels each record’s role and date, then escalates when the case falls outside the ordinary path.
The UK Government Data Quality Framework distinguishes timeliness and consistency from accuracy. That distinction is useful for decision records: a policy may be accurately transcribed but not current for this order, or two systems may show conflicting values that require investigation.
Define what the tool is actually allowed to do
A single decision can support several levels of automation. Start with the least authority that gives useful help:
- Find: show relevant records and their status.
- Explain: summarize the rule and identify missing evidence for a person.
- Draft: prepare a proposed answer or action that a person checks.
- Act within limits: carry out a defined routine action with monitoring and a recovery path.
- Escalate: stop when a case falls outside tested boundaries.
These are possible design choices, not inevitable stages. Some decisions should always remain with a person. Others may never need AI at all. A fixed rule can be more reliable when the inputs and policy are clear. If a decision could expose private data, change a financial obligation, affect someone’s safety, or publish a claim, its approval boundary deserves particular care.
For each level, ask what the reviewer can actually see. If a draft says “Your refund is approved,” the reviewer needs the order, applicable policy, condition evidence, and any previous exception. A button that says “Approve” without those facts is not a good control. The site’s AI workflow test guide provides concrete cases for missing data, conflicting records, and unintended actions.
Test the charter against awkward cases
A rule that works only for an ordinary case is not ready. Before building software, run a short tabletop test. Give two people the same set of examples and ask what the rule directs them to do. Include:
- a normal case with complete records;
- a missing or stale source;
- two sources that disagree;
- an exception that seems sympathetic but lacks authority;
- a case from before the current policy took effect;
- an urgent request that should go to a person immediately.
Write down disagreements. They are useful evidence that the decision has not been defined well enough. The fix may be a clearer rule, better labels on records, training, or a new escalation path. It is premature to ask an AI tool to resolve an ambiguity that the team itself has not resolved.
For example, two staff members may disagree about whether a camera with an untested video mode can be listed as “fully functional.” The decision charter can specify that “fully functional” requires testing every feature named in the listing. If a feature is untested, the listing states that limit. A language model can help format that disclosure, but it cannot create a test result.
Estimate whether the decision is worth improving
The benefits of a knowledge project are often described loosely: save time, reduce mistakes, or provide consistency. Write a baseline that a small team can actually observe. For ten recent cases, how long did it take to find the necessary information? How often did a decision need correction? How many were escalated? How many customers had to ask again? Keep the sample size visible; ten cases are a local diagnostic, not a reliable industry benchmark.
Then include the cost of the proposed fix. Building a rule, cleaning records, training staff, reviewing outputs, updating a search index, and handling failures are all work. A five-second AI answer is not a five-second process if a person spends ten minutes checking it. The full-cost worksheet gives a way to count setup, review, rework, and upkeep.
If the team cannot name an observable benefit, it can still run a modest experiment to learn. It should not claim a return on investment before recording the full cost and outcome. The first version may prove that a better checklist is enough. That is a useful result, even if it does not justify new software.
A seven-question decision audit
Before putting a candidate into a knowledge or AI system, answer these questions in writing:
- What recurring choice are we improving, and who owns its rule?
- Which evidence is required, where does it come from, and how old may it be?
- What does a correct ordinary decision look like?
- Which cases require a person or specialist to decide?
- What may a tool read, draft, change, or send?
- How will we detect a wrong decision and repair its consequences?
- What outcome would make us keep, revise, or stop this project?
If the answers are vague, the next action is to study the work, not to automate it. A narrow, checkable decision gives the later parts of the series something real to support: the evidence to capture, the record to retrieve, the workflow to govern, and the outcome to measure.