Glossary · 45 terms

Glossary of AI agents and process automation

The words that come up when a team decides whether to put software on a process — defined plainly, with an operations example for each, and a link to the agents where the term matters.

Agentic workflow

A process in which software decides some of the next steps while the task runs, rather than following a path fixed in advance.

A process in which software chooses part of the sequence at run time: which document to read next, which system to query, whether to stop and ask a person. It sits between a fixed script and a fully autonomous agent, and most real deployments are of this kind. In supplier invoice matching, for example, the main steps are fixed (read, match, post), but when the purchase order number is missing the software decides where to look for it: the email body, the delivery note, the supplier's open orders. The fixed parts should stay fixed and be tested like any script; only the branches that genuinely vary are left to the software.

Related: AI agent, Script, Orchestration, Tool use.

AI agent

Software that reads a case, chooses its next steps while the task runs, acts in your systems and finishes with a changed record.

Software that carries a task to the end rather than answering a question. It reads the input, decides the sequence of steps while the task is running, calls the systems that hold the state, and finishes with a changed record: a credit note raised, a case closed, a supplier record updated. What separates it from a script is who decides the next step, and when. An agent earns its cost only when the path varies case by case, the input is unstructured, and the outcome can be checked cheaply afterwards. A nightly transfer between two stable systems does not qualify; matching remittance advices written in free text to open invoices may.

Related: Script, Copilot, Chatbot, Candidacy checks.

AML (anti-money laundering)

The controls a regulated firm runs to detect, investigate and report activity that may involve the proceeds of crime.

The set of controls a regulated firm operates to detect, investigate and report activity that may involve the proceeds of crime. In operations, most of the effort sits in alert review: a monitoring system raises alerts on transactions or behaviour, and an analyst gathers the customer's profile, history and counterparties before closing the alert or escalating it. Software can assemble that evidence, compare it with the customer's declared activity and draft the rationale, so the analyst reads a prepared file instead of searching five systems. The decision to report suspicious activity stays with a named person under the applicable rules, and every closure needs a record of what was reviewed.

Audit trail

A per-case record of what the software read, which rule it applied, what it did and when, so each step can be checked.

A record, tied to a case identifier, of every step the software took: which documents and records it read, which rule or threshold it applied, which system it called, what it wrote and at what time. Without it you cannot answer a complaint, satisfy an auditor or find which step went wrong. In expense report audit, for example, the trail for a rejected claim shows the receipt that was read, the policy clause on meal limits that applied, the amount compared and the message sent to the employee. A log of model conversations is not enough on its own; the trail must describe actions in the systems of record.

Calibration

How well a system's stated confidence matches how often it is actually right, so that a high score can be trusted.

The degree to which a confidence score means what it says. If the software marks a group of cases at 0.9 confidence, a calibrated system is right on roughly nine in ten of them; an uncalibrated one may be right on far fewer. Calibration matters because thresholds depend on it: when you let cases above a given score complete automatically, you are relying on the score being honest. You check it by grouping past decisions by score band and comparing each band with known-correct outcomes. In AML alert triage, a model that is confident but poorly calibrated will close alerts that should have reached an analyst.

Candidacy checks

Five checks, run before any code is written, that decide whether a process is worth automating with an agent.

Five checks that decide whether a process is a candidate for an agent, run before anyone writes code. The rules are written down and current. The systems expose their state, and the licence permits software to drive them. Something cheaper than a person can check the outcome afterwards. The volume repays the build. And the people who own the process describe it the same way. If the rule for when a credit note needs a second signature lives only in one person's head, the first check fails. If correctness can only be judged by someone redoing the work, the third fails, and what you are buying is a copilot.

Chatbot

Software that answers questions in conversation; a person reads the answer and decides what to do with it.

Software that answers questions in a conversation. It may look things up, summarise a policy or explain a status, but a person reads the answer and takes the action. A chatbot is the right choice when someone needs information and already holds the authority to act on it: a payroll officer asking which allowance code applies to a night shift, or a customer asking where their claim stands. It is the wrong choice when the goal is a finished task, because nothing in the conversation changes the record. The test for anything sold as an agent is whether a record in a system changes without a person making the change.

Confidence score

A number the software attaches to an output to say how likely it is to be correct, used to decide what goes to a person.

A number attached to an output, such as an extracted field or a classification, estimating how likely it is to be correct. Operations teams use it to route work: above a set threshold the output is accepted, below it the case goes to a person. In corporate action capture, a record date read from a clean notice might score high, while one read from a scanned fax showing two conflicting dates scores low and is queued for review. The score is only useful if it is calibrated against known-correct outcomes, and a score produced by the same model that made the decision can be overconfident. A check against a second source is often more reliable than the score alone.

Copilot

Software that drafts or suggests inside a person's workflow; that person reviews and commits every result.

Software that works alongside a person, drafting, suggesting or pre-filling, while that person reviews and commits each result. It is the right design when the judgement is genuinely irreducible but the typing is the bottleneck: a lawyer marking up a contract against the firm's standard positions, or an underwriter writing a rationale. It is also what you are buying when the outcome cannot be checked cheaply afterwards, because without that check nothing can run unattended. A copilot saves time on each case; it does not remove the case from anyone's desk. Selling it as an agent sets expectations it cannot meet.

Related: Chatbot, AI agent, Human-in-the-loop, Candidacy checks. Where it matters: Contract review against a playbook.

Drift

A gradual change in inputs or rules that makes software less accurate over time, although nobody changed the software.

A gradual change that makes a system less accurate than it was when you measured it, without anyone touching the system. The inputs shift: a supplier redesigns its invoice layout, customers start describing a new product fault, a scheme updates its application form. Or the rules shift: a policy threshold changes and the old correct answers become wrong. In complaint routing, a new product line can send a growing share of complaints to the wrong team for weeks before anyone notices. You detect drift by re-running the known-outcome case set on a schedule, sampling recent live cases for review, and watching the rate of cases sent to a person.

Escalation

Passing a case from the software to a person, with the reason and the evidence, when the rules do not decide it.

The hand-off of a case from the software to a person, or from one person to a more senior one, because the rules do not decide it or the stakes are above a set limit. A good escalation carries its evidence: the document read, the rule that failed, the figure that did not reconcile, and what the software would have done. In refund and goodwill requests, a request above the goodwill limit, or from a customer with an open complaint, is escalated with the order history and the policy clause attached, so the reviewer decides without re-reading the file. Escalation criteria should be written down and tested like any other rule.

Evaluation

Measuring whether software gets cases right, by running it on cases with known-correct outcomes and checking the end state.

The practice of measuring whether the software gets cases right, before go-live and after every change. You run it on a set of past cases with known-correct outcomes and check each result with a test over the end state, not over the conversation: a credit note exists, its value equals the disputed lines, it references the original invoice, and no second note was raised. Tests that run without a person let you compare a new model or a rule change quickly. Ask for scores on cases drawn after the system was built, and for repeated runs of the same case; a single attempt on a chosen example is a demonstration, not an evaluation.

Exception handling

How cases that do not fit the standard path are detected, assigned to an owner and resolved.

The part of a process that deals with cases that do not fit the standard path: a missing reference, amounts that disagree, a document in an unexpected format, a system that rejects the update. In most back offices this is where the time goes, because standard cases are already quick. Good exception handling names each exception type, states who owns it and how it is resolved, and records the outcome so recurring causes can be fixed at the source. In telecom provisioning, an order that fails because a port is already allocated needs a different owner from one that fails on an address mismatch. Software helps most when it classifies the exception and attaches the cause.

Exception queue

The work list of cases the software could not complete on its own, each waiting for a person with its reason attached.

The list of cases the software could not finish on its own, waiting for a person. Each item should carry the reason it stopped, the evidence behind that reason and what the software proposes, so the reviewer decides rather than starts again. In settlement break triage, the queue holds breaks the software could not explain from the three systems it checked, sorted by value and age. The queue is also a measurement: its size, its age profile and the reasons in it tell you where the rules are unclear, where a source system is unreliable, and whether the oversight threshold is in the right place. A queue that grows every week is a finding.

Extraction

Reading a document and turning the facts in it into structured fields that another system can use.

Turning the content of a document into structured fields that another system can use: the invoice number, the amount on each line, the record date of a corporate action, the notice period of a lease. It is usually the first step of an agent's work and the one most easily checked. Good extraction keeps the source location of each value, so a person can verify it in one click, and marks fields it could not read rather than guessing. Where the same fact appears in two places, such as the invoice total and the sum of its lines, the software should cross-check them and flag any disagreement. Extraction errors carry into every later step.

False negative

A case that should have been flagged but was not: the error that escapes, and often the more expensive kind.

A case the software should have flagged but did not: a recoverable claim marked as not recoverable, an adverse event described in a customer email that was filed as a general complaint, an expired identity document accepted. False negatives are the errors that escape, because nobody is looking at the cases the software cleared. You find them only by sampling cleared cases and comparing them with known-correct outcomes. Their cost, multiplied by how often your evaluation says they occur, is the first half of the oversight threshold calculation. Tuning the software to catch more of them produces more false positives, so the two have to be set together.

False positive

A case flagged as a problem that turns out to be fine; each one costs review time and dulls reviewers' attention.

A case the software flags as a problem that turns out to be fine: a transaction alert on a customer whose behaviour is normal for their business, a return marked as suspicious that was a genuine fault, a price increase flagged although the contract already allowed it. Each one costs review time, and a queue full of them teaches reviewers to approve without reading, which is how real problems slip through. Reducing false positives usually means giving the software more context, such as the customer's declared activity or the contract's indexation clause, rather than simply moving the threshold, which trades them for false negatives.

Guardrails

Hard limits placed around software, enforced outside the model, that stop it taking actions beyond its permitted scope.

Limits placed around the software that it cannot talk its way past, because they are enforced in code or in the target system rather than in the model's instructions. Typical guardrails are a maximum value the software may approve, a list of systems and fields it may write to, a rule that nothing goes to a customer except through an approved template, and a stop when two sources disagree. In refund requests, a guardrail might block any goodwill payment above a set amount and any second refund on the same order. Instructions in a prompt are guidance; a guardrail is a permission the system enforces. Test each one with cases designed to break it.

Hallucination

Output from a language model that reads as plausible but is not supported by the source, such as an invented date or clause.

Output from a language model that is fluent and plausible but not supported by the input: a break clause that does not appear in the lease, a policy number assembled from two documents, a summary that states a date the letter never mentions. It happens because the model generates likely text rather than looking facts up. In operations the defence is mechanical: require every extracted value to carry its source location, check that the quoted text exists at that location, cross-check against a second source where one exists, and have the software mark a field as not found rather than fill it. This is why extraction without a check should not run unattended.

Human-in-the-loop

A design in which a person must approve before the software's action takes effect.

A design in which a person reviews and approves before the software's action takes effect. It is the right choice for actions that are irreversible, customer-facing where the rules do not decide, or above a value where an escaped error is expensive. In prior authorisation, the software can draft the request from the patient record and check it against the payer's criteria, but a clinician confirms it before it is sent. The risk is volume: a person approving hundreds of routine items a day stops checking them and becomes a signature. Keep the loop for the cases that need judgement, and let the rest run under sampling instead.

Human-on-the-loop

A design in which the software acts on its own while a person monitors, samples its work and can stop or reverse it.

A design in which the software acts without waiting for approval, while a person monitors its work, reviews a sample and can stop or reverse any action. It suits high-volume work where errors are recoverable and the outcome can be checked cheaply: matching delivery notes to invoices, applying incoming payments to open items. The person on the loop needs three things to be more than a name on the organisation chart: a view of exceptions and sampled cases, a way to pause the software, and a tested procedure to undo a wrong action. Without those, the oversight exists on the process map but not in practice.

Idempotency

The property that running the same action twice has the same effect as running it once, so retries never create duplicates.

The property that performing the same action twice has the same effect as performing it once. It matters because software retries: a call to a system times out, the software cannot tell whether the payment was posted, and it tries again. Without idempotency you get two postings, two supplier records or two welcome emails. The usual mechanism is a unique key for each intended action, such as the case identifier plus the step, which the target system checks before writing. In provisioning, a retried activation order should find the first one and stop rather than allocate a second line. Ask how every write in the design is made idempotent.

Intelligent document processing (IDP)

Software that classifies incoming documents, reads them and returns structured data, using layout and language as well as characters.

Software that takes incoming documents, identifies what each one is, reads it and returns structured data, combining character recognition with layout analysis and language models. A customs file, for example, may arrive as a single scan containing a commercial invoice, a packing list and a certificate of origin; the software separates them, classifies each, and extracts the fields each one should contain. Document processing is usually one stage of a larger agent rather than the whole job: the extracted data still has to be checked against rules and written into a system. Judge it on field-level accuracy against your own documents, not on a supplier's sample set.

Known-outcome case set (golden set)

A collection of past cases with verified correct outcomes, used to measure software before go-live and after every change.

A collection of real past cases, each paired with the outcome a competent person agreed was correct, used to measure the software before go-live and after every change. It is the asset that outlives the model: when you swap models, change a rule or upgrade a system, you run the same cases and compare. Build it from ordinary cases and awkward ones, record who labelled each and where labellers disagreed, and write each expected outcome as a check on the end state of a named system. For supplier invoice matching, that means past invoices with the correct match, the correct exception and the correct posting. Keep adding recent cases.

Related: Evaluation, Shadow mode, Drift, Calibration.

KYC (know your customer)

The checks a regulated firm runs to verify who a customer is and what activity to expect, at onboarding and periodically after.

The checks a regulated firm carries out to establish who a customer is and what activity to expect from them, at onboarding and at periodic reviews. In operations this means collecting identity documents, proof of address and, for companies, ownership and control records, then checking each against the applicable rules: validity, expiry, consistency of names and dates, and screening results. Software can read the documents, compare them with the application and with each other, and flag expiries and mismatches, so a reviewer sees only the files with a real question. Decisions to accept or refuse a customer stay with a person, and each check needs a record of the evidence used.

Large language model (LLM)

A model trained on large amounts of text that reads and writes language; the component inside most current agents that interprets input.

A model trained on very large amounts of text that can read, classify, summarise and draft language. In most current agents it is the component that reads unstructured input and decides the next step; the rest, such as system connections, rules, checks and records, is ordinary software. It is useful where inputs vary in wording, such as a supplier email that gives the order number in the body, and weak where exact arithmetic or guaranteed repeatability is needed. It can produce fluent errors, so its output should be checked by code, not trusted by default. The model you choose will be replaced; your evaluation set should not have to be.

Lease abstraction

Extracting the key terms of a lease, such as rent, dates, break options and obligations, into a structured summary.

Extracting the terms of a lease that drive money and deadlines into a structured summary: parties, premises, term, rent and review mechanism, break options, notice periods, service charge provisions, repair and insurance obligations. Leases are long, amended by side letters and written in varying styles, which makes this slow by hand and a reasonable candidate for software. Each abstracted term should carry its clause reference so a surveyor or lawyer can check it against the source, and the software should read amendments in date order so a later deed overrides an earlier clause. Dates that trigger an action, such as a break notice deadline, deserve a second check.

OCR (optical character recognition)

Technology that converts images of text, such as scans and photos, into characters a computer can process.

Technology that converts an image of text, such as a scanned delivery note, a photographed receipt or a faxed form, into characters a computer can process. It is a first step, not an understanding: it tells you which characters appear, not which number is the invoice total. Quality depends on the image. Skewed scans, stamps over text, handwriting and poor contrast all produce errors, and a misread digit in an amount or an account number can pass unnoticed. In delivery note matching, a handwritten quantity correction on a signed note may be the only record of a short delivery, so fields read with low confidence should go to a person.

Orchestration

Coordinating the steps, systems and hand-offs of a process so each runs in order, with retries, waits and records.

The coordination of the steps in a process: which runs first, what each waits for, how failures are retried, when a person is brought in and how the whole case is recorded. When a new employee joins, the orchestration creates the employee record, waits for the identifier, then opens accounts in each downstream system, retries the ones that fail and reports what could not be done. Orchestration is usually ordinary, deterministic software, even when an agent makes decisions inside individual steps. Keeping the sequence explicit and testable makes the process easier to audit and to reverse, and leaves the model to decide only what genuinely varies.

Oversight threshold

The line above which a case goes to a person, set by comparing the cost of an escaped error with the cost of the review.

The line that decides which cases a person reviews and which the software completes alone, expressed as a value, a risk score, a confidence level or a case type. It should be set by arithmetic rather than instinct: the expected cost of an error that escapes, meaning its financial and regulatory cost multiplied by the error rate your evaluation measured, against the cost of the review that would catch it. In expense report audit, claims below a small amount with a matching receipt might post under sampling, while anything above it or outside policy goes to a reviewer. Revisit the threshold as the measured error rate changes.

Precision

Of the cases the software flagged, the share that were genuinely problems; low precision means reviewers spend time on false alarms.

Of all the cases the software flagged, the proportion that were genuinely what it said. If it flags forty expense claims as out of policy and thirty of them are, its precision on that batch is three in four. Low precision fills the review queue with false positives and wears down reviewers' attention. Precision is always read together with recall, because you can raise one by giving up the other: flag only the most obvious cases and precision rises while real problems are missed. Measure both on a set of known-outcome cases, for each case type, since an overall figure can hide a category the software handles badly.

Related: Recall, False positive, Evaluation. Where it matters: Expense report audit, AML alert triage, Return fraud patterns.

Prior authorisation

Approval a healthcare provider must obtain from the payer before a treatment, test or medicine, for it to be covered.

Approval a healthcare provider must obtain from the payer, such as an insurer or a public scheme, before carrying out a treatment, test or prescription, if it is to be covered. The request has to show that the payer's criteria are met, usually by citing diagnosis codes, previous treatments and clinical notes from the patient record. The work is repetitive because the answers already exist in the record but must be found and re-entered in the payer's format. Software can draft the request, check it against the payer's published criteria and track the response. A clinician confirms the clinical content, and any denial goes to a person.

Process mining

Analysing event logs from business systems to reconstruct how a process actually runs, including its variants and delays.

Analysing the event logs of business systems, such as the times at which an invoice was received, approved and paid, to reconstruct how a process actually runs rather than how it is documented. It shows the variants, the loops, where cases wait and how many follow the standard path. For an automation decision it answers useful questions: how much volume there is, how many cases are exceptions, and whether the process owners' description matches the data. It sees only what systems record, so work done in email, spreadsheets or on the phone stays invisible. Pair it with conversations with the people who do the work.

Recall

Of all the real problems present, the share the software caught; low recall means errors pass unnoticed.

Of all the cases that were genuinely problems, the proportion the software caught. If a batch of claims files contains ten recoverable claims and the software surfaces eight, its recall on that batch is eight in ten; the other two are false negatives that nobody sees. Recall matters most where a missed case is costly: a reportable adverse event, a recovery opportunity past its deadline, a sanctioned counterparty. You can measure it only on cases where you already know the answer, since misses are invisible in live work. Raising recall usually lowers precision, so set the balance from the relative cost of each kind of error.

Reconciliation

Comparing two or more records of the same activity and explaining every difference between them.

Comparing two or more records of the same activity, such as your ledger and a supplier's statement, the balances two group companies hold with each other, or bank lines and open invoices, and explaining every difference. Matching the items that agree is the easy part and is often a script. The time goes on the remainder: timing differences, partial payments, amounts netted together, references typed differently. That is where an agent can help, by reading remittance details and correspondence to propose an explanation, while a person approves write-offs and adjustments. A reconciliation is finished when every difference has an explanation and an owner, not when the totals agree.

Retrieval (retrieval-augmented generation)

Fetching relevant passages from your own documents and giving them to a language model, so its answers rest on your sources.

Fetching the passages relevant to a case from your own documents, such as the policy manual, the contract or the payer's criteria, and giving them to the language model with the task, so its output rests on your sources rather than its general training. In contract review against a playbook, the software retrieves the firm's standard position and fallback wording for each clause type before comparing. Retrieval fails quietly: if the wrong passage or an outdated version is retrieved, the answer is confidently wrong. Keep sources versioned, record which passages were used for each case, and test retrieval on its own before judging the final answer.

Rollback

A known, tested procedure for undoing an action the software took, in the system where it took it.

The procedure for undoing an action the software took, in the system where it took it: reversing a posting, cancelling a payment instruction, restoring a record to its previous values, withdrawing a message. Every action should have one, written down and tested before go-live, including who is authorised to run it and how long it takes. Some actions cannot be rolled back, such as a payment that has left the bank or a letter a customer has read; those stay with a person or wait for approval. In cash application, a payment applied to the wrong customer is reversed and re-applied, and the audit trail shows both steps.

RPA (robotic process automation)

Software that repeats fixed steps in application screens, clicking and typing as a person would, along a path set at design time.

Software that repeats a fixed sequence of steps in application screens, clicking, copying and typing as a person would. It suits stable, rule-based tasks where no integration is available, such as copying approved orders from a supplier portal into the purchasing system every night. Its weakness is that it follows one path through one version of the screens: when a field moves, a label changes or an input arrives in an unexpected format, it stops or, worse, types into the wrong place. Maintenance grows as exception branches accumulate. RPA and agents are often combined, the agent deciding what to do and a fixed step carrying it out. Check that each application's licence permits automated use.

Script

Software that follows a path fixed at design time; cheaper, faster and more auditable than an agent when nothing varies.

Software that follows a path decided at design time: every branch was written in advance, and it does the same thing each time it meets the same input. For most automation it is the right answer. If you can draw the flowchart, a script will be cheaper to run, faster, deterministic and auditable line by line. A nightly transfer between two systems with fixed formats and no exceptions is a script, not an agent. Scripts stop working when the interface, the data or the wording of the input shifts, and each new variation becomes another branch to maintain. If no step depends on what a document actually says, you are looking at a script.

Shadow mode

Running new software on live cases alongside the current process, recording its decisions without acting on them, to compare.

Running the software on live cases alongside the existing process, recording what it would have done without letting it act. Staff continue as usual, and each day the software's decisions are compared with theirs. Disagreements are reviewed one by one: some are software errors, some are staff errors, and some reveal a rule nobody had written down. Shadow mode tests the software on current cases rather than a curated set, and shows how reviewers respond to its evidence. In application eligibility, a period in shadow mode shows whether the pre-check agrees with officers on borderline files before any applicant is affected.

Straight-through processing (STP)

Completing a case end to end with no manual step; the straight-through rate is the share of cases that pass untouched.

Completing a case from receipt to final record with no manual step. The straight-through rate, the share of cases that pass untouched, is a common automation measure, but read it with care: a rate that rises while errors also rise means cases are passing that should have stopped. Report it alongside the error rate on sampled straight-through cases and the size of the exception queue. In cash application, a payment with a clear remittance advice matching one open invoice can go straight through; one covering several invoices with a deduction cannot, and should reach a person with a proposed allocation.

Subrogation

An insurer's right, after paying a claim, to recover the cost from a third party responsible for the loss.

The right of an insurer, having paid a claim, to recover the cost from a third party who caused or contributed to the loss, such as another driver, a contractor or a manufacturer. Recovery opportunities are often visible only in the detail of a claim file: a police report naming another vehicle, an engineer's note blaming a faulty part, a tenant's statement about a neighbour's leak. Because nobody has time to read every file closely, opportunities are missed and recovery deadlines pass. Software can read each file, flag potential recoveries with the evidence and the likely responsible party, and leave the decision to pursue with a claims handler.

Related: Recall, False negative, Triage. Where it matters: Subrogation detection, Claim first notification.

Three-way match

Checking a supplier invoice against the purchase order and the goods receipt before it is paid.

Checking a supplier invoice against the purchase order and the goods receipt before it is paid: were these items ordered, at this price, and were these quantities received. Where all three agree within set tolerances, the invoice can be approved; where they do not, the difference is an exception. The hard cases are routine in practice: partial deliveries, one invoice covering several orders, price changes agreed by email, differences in unit of measure, and receipts not yet recorded. Software can read the invoice, find the matching order and receipt lines, apply the tolerances and explain each failure, so the person in accounts payable handles the reason rather than the search.

Tool use

A language model calling defined functions, such as searching a system or updating a record, instead of only producing text.

The ability of a language model to call defined functions, such as searching the order system, reading a customer record or creating a case, and to use the results in its next step. It is what lets an agent act rather than only write. In card dispute intake, the software reads the customer's message, calls one tool to find the transaction, another to check earlier disputes, and a third to open the case. Each tool is a permission: define narrowly what it may read or write, validate its inputs in code, make its writes idempotent, and record every call. A tool that can do anything means the model can too.

Triage

Sorting incoming cases by type, urgency and owner so each reaches the right queue, with the urgent ones first.

Sorting incoming cases by what they are, how urgent they are and who should handle them, so each reaches the right queue in the right order. In claim first notification, emails, forms and call notes are read, classified by claim type, checked for duplicates and missing documents, and routed to the right team, with injury claims and large losses moved to the front. Triage is a good early use of software because a misrouted case is usually recoverable and the correct route is easy to check afterwards. Keep a route for cases that fit no category, and review what lands there regularly.

Read next