Talha Azfar
applied lesson

Turning Unstructured Input Into a Confirmed Business Record

A pattern for using AI to propose structured records from raw operational text without giving the model final authority.

TA

Talha Azfar

CTO at Aetarix

Published 2026-09-26Updated 2026-09-263 min
AI-Enabled SystemsData ModellingHuman-in-the-Loop

Operational information rarely arrives in the exact structure a system expects. A person may paste a message containing a name, contact details, preferences, source information, and several comments in one block of text. The application, however, needs those facts separated into validated fields.

An AI assistant can help translate between those forms, but it should not be confused with the system of record.

The pattern

In a workflow platform, we implemented a bounded flow:

  1. A staff member provides unstructured lead information.
  2. The assistant extracts and proposes values for known fields.
  3. The interface presents the proposed record to the user.
  4. The user corrects or confirms the values.
  5. The application validates the approved data.
  6. Only then is the lead created through the normal application workflow.

The model’s response is a proposal, not a committed record.

Why the distinction matters

A language model can return confident text even when the source is ambiguous. It may place a value in the wrong field, infer something the user did not provide, or format a valid fact incorrectly.

If its output is written directly to the database, uncertainty becomes operational data. Downstream users may then act on it as if it had been verified.

The confirmation step keeps uncertainty visible. It gives the responsible user a chance to compare the source with the proposed structure and prevents the model from receiving authority merely because it can produce structured output.

Validation remains application logic

The application should continue to enforce required fields, formats, permissions, and business rules. Those responsibilities should not move into a prompt.

For example, the assistant may propose an email address, but ordinary validation should determine whether the value is acceptable. The current user must still have permission to create the record. Source and ownership rules should still be applied by the domain workflow.

This keeps the AI component replaceable. It assists data preparation without becoming the only place where essential rules exist.

Trace the transition

A mature version of this pattern should distinguish among the original input, the model’s proposal, the user’s corrections, and the final saved record. That separation makes it possible to diagnose errors and evaluate whether assistance is genuinely useful.

It also creates the basis for meaningful measurement: which fields require correction, which input formats work poorly, and how often users accept a proposal.

Current limitation

Our implementation was tested, but its ongoing use is paused because operating cost has not yet been justified by measured value. That limitation is important. The architectural pattern can be sound even when the current economics do not support continuous operation.

AI is most useful here as a translator between messy human input and an explicit business schema. The application—and ultimately the responsible user—should remain in control of what becomes an official record.

Related note: What a Business Record Actually Represents.

Talha Azfar, CTO at Aetarix

Written by

Talha Azfar

CTO at Aetarix

Software architecture, AI-enabled business systems, and the engineering judgment that connects them.

Disagree, or working through the same problem? I'm glad to talk it through.

Get in touch