# AI workflows, document intelligence and RAG design | tracee > Design and integration of document intelligence, knowledge retrieval with sources, case triage, orchestration and assisted review, with failure handling built in. Source: https://traceegroup.com/ai/workflows --- # AI inside the workflow, not beside it. We design and integrate AI capabilities into the processes where work already happens: documents read and checked, knowledge retrieved with its sources, requests triaged, and every consequential output reviewed by a person who can see why it was proposed. ## Five capabilities, defined precisely. Vague terms produce vague projects. These are the five building blocks we design with, and what each one actually does. ### Document intelligence Three distinct operations that are often bundled under one name. OCR turns an image of a page into text. Extraction maps that text to named fields: supplier, date, amount, clause. Consistency checking compares the fields with each other and with reference data: the lines add up to the total, the supplier exists, the date falls in the open period. The model does the second; ordinary code should do the third. ### Knowledge retrieval Retrieval-augmented generation (RAG) searches a curated, access-controlled set of documents and gives the model only the passages it found, so the answer can cite them. Its quality depends on the corpus before the model: duplicates, outdated versions and documents without an owner produce confident wrong answers. ### Case triage Classifying incoming requests by type, urgency and required skill, then routing them. Usually rules plus a classifier; a language model helps when requests arrive as free text in several languages. ### Workflow orchestration The layer that sequences steps, calls systems, retries safely and records state. It should be ordinary, deterministic software. An agent, in the precise sense, is a model allowed to choose which tool to call next. We grant that freedom sparingly, inside bounded permissions, and only where the path genuinely cannot be specified in advance. ### Assisted review The screen where a person sees what the system proposes, the evidence behind it and how uncertain it is, then approves, corrects or rejects. Corrections are stored and become test cases. This is where most of the design effort should go, because it is where trust is built or lost. ## One process, every step written down. Invoice intake is a good reference because almost every organization has it. The same structure applies to contracts, claims or onboarding files. This is an illustrative design; we do not claim it is deployed for a client. Workflows ยท Reference process ### Invoice intake, fully specified. Scroll the diagram sideways to see all of it. **Read the diagram as text** - Intake: each document arriving by email, upload or portal receives an ID, a content hash and a timestamp. - Validation rules: file type and readability, duplicate detection by hash and by key fields, mandatory attachments present. Failures go to the exception queue. - Known layouts are read by template rules with no model involved. Unknown layouts go to AI extraction, which must return a fixed schema. - Consistency checks: totals reconcile, dates are plausible, the supplier exists in master data, field confidence is above threshold. Any failure becomes a flag with a reason. - Human approval: the reviewer sees the document beside the extracted fields, with doubts highlighted, and approves, corrects or rejects. Thresholds by amount decide what must be reviewed. - Export to the accounting or ERP system through its API or a validated import file, with an idempotency key so a retry never books twice. - The evidence log records the input hash, model and prompt versions, extracted values, checks run, reviewer decision and export ID. Notice where the model is not. It does not decide whether a document is a duplicate, whether totals add up or whether an invoice can be paid. It reads layouts that rules cannot read, and its output is checked before anyone relies on it. ## Designed for the day things go wrong. A pilot is judged on its happy path. Operations are judged on everything else. Each failure below has a defined detection and a defined response before the system goes live. - Failure - How it is detected - What happens - Duplicate input - Same content hash, or same supplier, number, amount and date. - Held and linked to the original. A person confirms; nothing is deleted automatically. - Missing document - Mandatory-attachment rule, such as a purchase order above a threshold. - Case parked as incomplete, sender notified from a template, follow-up timer set. - Low-confidence extraction - Field confidence below threshold, or a failed consistency check. - Field highlighted for review with the reason. Never silently accepted. Rate tracked per layout. - API timeout - Timeout or error code from the model service or the business system. - Retry with backoff and the same idempotency key, then park in a queue visible to operations. No partial export. - Human override - Reviewer changes a value or reverses the proposed decision. - Stored with reason, user and time. Feeds the evaluation set. Override rate monitored as an early warning. - Retry or replay - Operator action or scheduled job after an incident. - Re-run from the last committed step with the same component versions, or with new versions logged as such. ## Where AI is the wrong tool. Saying where not to use a model is part of the job. In these cases ordinary software is cheaper, more reliable, or both. - Arithmetic and totals. A model can read the numbers. Code should add them. - Stable rules with legal or financial weight. VAT rates, approval limits, eligibility thresholds. Encode them; do not ask a model to remember them. - Exact lookups. "What is the balance of this account" is a database query, not a retrieval problem. - Low-volume tasks. If it happens twelve times a year, a checklist beats a pipeline. - Outputs nobody can check. With no ground truth and no reviewer, there is no way to know the system works. - Decisions with significant effects on a person, taken without meaningful human review. These need a different design and a legal assessment first. ## What a workflow mandate delivers. ### Workflow specification Each step, its rules, where the model is used and where it is not, and the review points. ### Integration design How the workflow reads from and writes to your existing systems, with idempotency and error contracts. ### Prototype Built against the specification on synthetic data or an approved sample, never on production data by default. ### Evaluation set and test plan Labelled cases, acceptance criteria and the failure scenarios above, scripted. ### Operations runbook Exceptions, retries, overrides and rollback, written for the team that will run it. ## Have a workflow in mind? Describe the documents or requests involved and what happens to them today. We will tell you which parts a model should touch, and which it should not.