Build and evaluate: a practical guide for buyers

Build and evaluate is the process of testing an artificial intelligence workflow against verified cases and defined controls before it enters production.

This guide helps South African operations, finance and technology buyers assess a focused workflow, the evidence behind it, its controls and its route to production.

A useful AI system starts with a bounded operational problem. Buyers need to understand what triggers the work, which records matter, where judgement is required and who remains accountable for the outcome.

This prevents a promising demonstration from being mistaken for a production-ready workflow. It also gives the business a sound basis for deciding whether to proceed, reshape the proposed system or stop before committing further resources.

South African buyers should consider operational controls alongside privacy, security and regulatory obligations. The relevant requirements will depend on the workflow, the information processed and the parties involved. AgentAligned provides a KwaZulu-Natal point of contact through its Durban office.

01 / 07

How should a workflow be assessed before building?

A workflow may be suitable when it has a clear beginning and end, repeated inputs, an accountable owner and an outcome the business can measure. The purpose of assessment is to define a manageable operating problem, not to find somewhere to apply a particular tool.

Start by following the work as it happens. Identify the source records, handovers, delays, exceptions and approvals. A written procedure may describe the intended process, but completed cases often reveal missing information, inconsistent identifiers and unofficial workarounds.

The assessment should also distinguish interpretation from validation. AI can interpret ambiguous emails, documents and free-text instructions. Deterministic rules, which return the same result under the same conditions, are better suited to required-field checks, fixed tolerances, approval limits and other known conditions.

1. 01Workflow fitClear trigger, boundary and accountable owner
2. 02Source inputsAvailable, representative and traceable
3. 03Decision boundaryPermitted actions and mandatory human approvals
4. 04Evaluation referenceA separate set of cases with verified answers
5. 05Quality measureConfident error rate
6. 06Handling measureMedian human handling time per correctly completed case
7. 07Production readinessFailure paths, escalation, logging and recovery are tested

The following areas give buyers a consistent basis for assessing one focused workflow.

Scroll for more

Assessment areas, what to confirm, evidence needed and why it matters

Assessment area	What to confirm	Evidence needed	Why it matters
Workflow fit	A repeated operational task has a clear trigger, boundary and accountable owner	Workflow map, responsible owner and representative completed cases	Prevents a broad technology exercise from replacing a defined operational problem
Source inputs	The source systems and documents are available, representative and traceable	Sample emails, documents, orders, delivery records and invoices with source identifiers	Reveals missing fields, incompatible identifiers and record-quality limits
Decision boundary	The system’s permitted actions and mandatory human approvals are explicit	Approval matrix, exception rules and access controls	Keeps consequential actions with authorised people
Evaluation reference	A separate set of cases has verified answers before being used for evaluation	Cases reviewed and resolved by authorised subject-matter reviewers	Creates a trustworthy reference for comparing system outputs
Quality measure	The confident error rate is measured for outputs above the agreed confidence threshold that authorised review later finds incorrect	System outputs, confidence records and reviewer decisions	Shows whether apparently confident outputs remain unsafe
Handling measure	Median human handling time per correctly completed case is reported separately from quality	Timestamped case and review records	Shows operational effort without allowing speed to conceal incorrect work
Production readiness	Failure paths, escalation, logging and recovery are tested	Test records, exception logs, access tests and approval evidence	Confirms that predictable failures remain visible and controlled

A verified evaluation reference is a set of cases for which authorised subject-matter reviewers have confirmed the correct answers from the underlying evidence. It provides a stable basis for comparing system outputs. AgentAligned explains the concept further in its guide to a set of cases with verified answers.

Examples used to configure rules, prompts or system behaviour must remain separate from evaluation cases. Testing on the same examples used to shape the system can produce an overly favourable result because the test is no longer independent.

The confident error rate measures the proportion of outputs above the agreed confidence threshold that an authorised reviewer later finds incorrect. This matters because a system can present the wrong output with apparent certainty. The threshold should control escalation, not be treated as proof that an output is correct.

Median human handling time per correctly completed case is the middle review time when cases are ordered from shortest to longest. It must be reported separately from quality. A faster process is not an improvement if errors rise. Equally, a careful system should not be dismissed solely because difficult cases take longer to review.

Assessment should end with an explicit operating boundary. This defines what the system may propose or validate, what it must escalate and which actions always require authorised human approval.

02 / 07

What might this look like in practice?

Consider a hypothetical port-logistics workflow in which staff compare documents received after a completed movement. This scenario shows how interpretation, controls and accountability could work together. It is not a claim about an existing deployment or client result.

1. 01Trigger

   supplier email with delivery and invoice documents

2. 02Source inputs

   order, delivery record, invoice and operational document

3. 03Bounded role

   AI interprets; deterministic rules validate

▲ Conflicting, missing or low-confidence?

Conflict boundary

both values retained

routed with source evidence to an authorised reviewer

Exception path

review queue

source references, extracted values and reason for escalation

Human approval: accept, correct or reject. The system must not silently choose one or approve, post or pay anything.

Trigger: A supplier email arrives with delivery and invoice documents for a completed movement. The email starts the case, but it does not authorise posting, approval or payment.

Source inputs: The system receives the order, delivery record, invoice and relevant operational document. Purchase-order, shipment, container, delivery and invoice identifiers may use different formats or fail to align across systems. Each extracted value remains connected to its source record so that a reviewer can inspect the evidence.

Bounded role: AI interprets ambiguous email and document content, including varied layouts, abbreviations and free-text references. Deterministic rules validate known conditions such as mandatory fields, agreed tolerances and approval limits. Interpretation is used where ambiguity exists; predictable checks are used where the business already knows the condition.

Conflict boundary: When source records conflict, the system retains both values and routes the discrepancy, with its source evidence, to an authorised reviewer. It must not silently choose one or approve, post or pay anything.

Exception path: Missing, low-confidence or contradictory information enters a review queue. The case includes the source references, extracted values and reason for escalation, allowing the reviewer to investigate without reconstructing the entire case.

Human approval: An accountable, authorised person examines the source evidence and accepts, corrects or rejects the proposed result. Access controls should ensure that only people with the appropriate authority can complete consequential actions.

This pattern supports document reconciliation without transferring accountability to the system. Buyers can explore the wider context through AgentAligned’s document-to-cash workflow for Durban logistics.

03 / 07

How should a focused system be evaluated before production?

Pre-production evaluation asks whether the system can perform its bounded role under realistic conditions while failing visibly and safely. It cannot prove that every future case will be correct. Instead, it provides evidence for a controlled production decision and identifies limitations that should shape the operating boundary.

The verified evaluation reference should contain ordinary cases, difficult edge cases and known failure cases. Ordinary cases cover the work expected most often. Edge cases cover uncommon but valid inputs. Failure cases cover malformed, incomplete, unavailable or contradictory material.

Reserved evaluation cases must remain separate from configuration examples. If a case is used to adjust a prompt, rule, extraction method or decision boundary, it becomes part of configuration and should no longer count as an independent evaluation case.

Configuration examples

Used to adjust a prompt, rule, extraction method or decision boundary.

Reserved evaluation cases

Ordinary cases, difficult edge cases and known failure cases.

A focused evaluation should cover these controls:

• Source traceability: Every material input and proposed output should be traceable to the relevant email, document, system record or rule. The retained evidence must allow an authorised reviewer to understand how the result was produced.
• Confidence and escalation: The agreed confidence threshold should determine when review is mandatory. Testing should confirm that uncertain cases enter the correct queue with enough context for a reviewer to act.
• Permissions and roles: Evaluators should test whether users and system components can access only the information and actions required for their roles. Attempts to exceed those permissions should fail and be recorded.
• Unsupported actions: Tests should deliberately attempt to make the system act beyond its approved boundary. This includes instructions embedded in documents or messages that try to trigger an unauthorised approval, record change or external action.
• Input and service failure: Testing should cover unavailable source systems, malformed files, unreadable documents and incomplete records. The expected result is a visible, recoverable failure path rather than an unexplained output.
• Measures and limitations: Results should be compared with the quality and handling measures agreed during assessment. Known weaknesses, excluded case types and mandatory review conditions should be documented as operating constraints.

Evaluation evidence should include the cases tested, expected answers, actual outputs, confidence records, reviewer decisions and failure reasons. A summary score without the underlying evidence gives decision-makers little basis for judging where the system remains unsafe or unsuitable.

Privacy and data-governance questions also require workflow-specific review. Data location alone does not settle lawful processing, access, retention or operator responsibilities. AgentAligned’s guidance on POPIA, data residency and sovereign AI provides a starting point, but appropriate professional advice may still be required.

A production decision should state the system’s tested scope and known limits. Untested documents, business units, languages or decision types should remain outside that boundary until separately assessed and authorised.

04 / 07

When should a business defer AI automation?

A business should defer, stabilise or reshape a proposed workflow when nobody is accountable for its operational outcome. A system cannot resolve unclear ownership, and automation may make existing accountability gaps harder to see.

It should also defer when representative source records or a measurable outcome are unavailable. Without real examples, the team cannot assess input quality or build a credible evaluation reference. Without a defined outcome, it cannot distinguish useful improvement from technical activity.

Operational stability matters too. When the underlying process, responsibilities or source systems change frequently, it becomes difficult to separate system failure from process change. The better first step may be to clarify the workflow and its controls before building.

Deferral does not necessarily mean rejection. It may lead to a narrower scope, a better-controlled process or a clearer problem that becomes suitable later.

05 / 07

How does AgentAligned move a focused workflow into production?

AgentAligned’s delivery model has three phases, each serving a different decision purpose.

1. 01Bottleneck Diagnostic

   about 1 to 2 weeks

   ▲ go, reshape or stop
2. 02Build and Evaluation

   about 4 to 6 weeks for a focused first workflow

   ▲ evaluated against reserved cases
3. 03Sustaining Production

• Quality
• Latency
• Cost
• Adoption

The Bottleneck Diagnostic takes about 1 to 2 weeks and leads to a go, reshape or stop decision. It examines the workflow, owner, source material, exceptions, systems, constraints and intended outcome. A go decision supports a focused build. A reshape decision narrows or changes the problem. A stop decision avoids further investment where the evidence does not support a viable workflow.

Build and Evaluation takes about 4 to 6 weeks for a focused first workflow. The work defines the operating boundary, connects the necessary inputs, configures interpretation and validation, establishes the review path and evaluates the system against reserved cases. The goal is a controlled workflow that can be judged against agreed evidence, not a demonstration built around favourable examples.

Sustaining Production begins once the approved workflow operates in its real environment. Quality, latency, cost and adoption should be considered together because no single measure describes operational health. A reliable output may arrive too late for the process. A fast result may cost too much at scale. A technically sound system may add little value if the people responsible for the workflow cannot or do not use it correctly.

Production evidence may reveal new failure patterns and possible improvements, but reviewer corrections must not change production behaviour without authorised testing. A correction may point to a new rule, configuration change or training example. That change should be evaluated separately and approved before release, ensuring that feedback does not bypass the system’s controls.

06 / 07

What should you prepare for a Bottleneck Diagnostic?

A useful diagnostic starts with operating evidence, not a preferred platform or model. Buyers should prepare:

Sensitive records should be handled through an approved route and shared only with people authorised to examine them. Where necessary, representative examples can be prepared with appropriate protections while preserving the structure needed to understand the work.

07 / 07

Should the business proceed, reshape or stop?

The business should proceed when the workflow has a bounded task, representative evidence, an accountable owner and a measurable outcome. The proposed system should also have a clear permission model, a visible exception path and a tested route to human approval.

A reshape decision is appropriate when the problem is real but the initial scope is too broad, the records are inconsistent or the action boundary is unclear. A narrower workflow may provide a safer and more useful first implementation.

The business should stop when the evidence does not support a stable, controllable or worthwhile workflow. Stopping before the build is a valid operational decision when it prevents an unfocused technology project.

PROCEED

When

The workflow has a bounded task, representative evidence, an accountable owner and a measurable outcome.

RESHAPE

When

The problem is real but the initial scope is too broad, the records are inconsistent or the action boundary is unclear.

STOP

When

The evidence does not support a stable, controllable or worthwhile workflow.

Book a Bottleneck Diagnostic

Related guide: Where does work get stuck? A practical AI workflow guide

Last reviewed: October 2026. This article provides operational guidance, not legal advice. POPIA and related compliance decisions require appropriate professional review.

Sources and further reading

• its Durban office
• a set of cases with verified answers
• document-to-cash workflow for Durban logistics
• POPIA, data residency and sovereign AI
• AgentAligned’s delivery model