From a document to a reviewed business record

Purpose and scope

That is a more concrete buying brief than “automate our documents”. You can take one representative request, decide what the resulting record should contain and test the exception path alongside the straightforward case. The worked example below shows how to do that before selecting a model or integration.

Everything in this example is synthetic: the request, person, site and proposed record. It is a design exercise, not a customer story or an observed DataXLR8 result. The worksheet is our editorial recommendation for a bounded trial.

Start with the source exactly as received

Imagine an example maintenance desk receives this message:

Please arrange maintenance for site BR-17 next Thursday. The access contact is Jordan Example. Our preferred time is after 2 pm.

The message contains useful information, but leaves out the request date, timezone, contact channel and required work. A demonstration that fills every field could conceal those omissions. A reviewable draft should make them easy to see.

Keep the original wording beside the extracted fields. This lets the reviewer distinguish what the sender said from what another system subsequently verified. If an authorised register confirms BR-17, record that register lookup as a separate source rather than making it appear in the original message.

Resolve uncertainty before asking for approval

“Next Thursday” needs context and can still need clarification after the sending date is known. Do not silently use the date the automation happens to run. A delayed message or retried job could otherwise change its interpretation.

The reviewer should ask for the missing work description and confirm the intended date and timezone. The workflow should preserve that clarification as evidence for the revised draft. A preferred time remains a preference until an authorised scheduling step confirms it.

Anthropic's evaluation guidance recommends tasks grounded in realistic usage with verifiable outcomes. In this example, a good outcome is a record whose fields are supported and whose unresolved state is visible. Formatting a plausible booking is insufficient.

Make the approval attach to a particular version

A reviewer needs to see the source, proposed fields, outstanding exceptions and the precise action they are approving. An “approve” button should not authorise unspecified future changes.

For this example, define the allowed action as creating one maintenance-request record from the reviewed version. Keep appointment confirmation outside that authority unless it is explicitly part of the agreed process. If someone edits the draft after review, return the changed version for approval before it can be written.

Diagram description: Extraction produces a draft with evidence. Missing or invalid values go through clarification. A person reviews a specific version, then system checks enforce permission and duplicate protection before a write. Failed checks leave a visible recovery state. Success displays the saved record and its audit reference.

This separation matters because the model's proposed action and the system's permission to perform it are different controls. OWASP recommends restricting functionality and permissions, requiring approval for high-impact actions and enforcing authorisation outside the model.

Use an exception worksheet before accepting the build

Give the implementer expected outcomes before the demonstration. Ask for observed results from the actual trial configuration, including failures. The table below contains proposed expectations; no system is claimed to have passed them.

For each case, add a responsible reviewer, observed result, correction required and retest date. Set acceptance thresholds for the actual workload and consequences of error. The National AI Centre recommends documented acceptance criteria, relevant testing, supplier evidence and accountable deployment authorisation; it does not make this example a certification.

Include the review work in the business case

Measure the entire path to an accepted record. Record extraction time, human review, clarification, correction and failed attempts. Compare that with the existing process on comparable work. Counting only the model's response time would omit much of the job illustrated here.

A useful accounting view is total operating cost during the trial divided by accepted records during the same period. Include usage fees, infrastructure, review and support where they apply, and avoid double-counting bundled charges. If no records are accepted, report the total cost and failures; the ratio is undefined. This is a proposed measurement method, not a price estimate or a claim of savings.

Also decide who can access source documents, drafts and review logs, and how each is retained or removed. OAIC's AI guidance covers personal information in inputs and outputs; the appropriate handling decision depends on the organisation and use. Do not assume that removing a document from one folder removes every retained copy.

Bring one representative document, a blank target record and the exception worksheet to a scoping conversation. If ordinary form validation and a fixed workflow solve the job, that is a useful result. For wider authority boundaries, read Before an AI workflow acts, decide how it can fail. To define the first useful release, see Start with a decision or discuss the workflow with DataXLR8.