This is a decision framework, not a description of a deployed system. It sets out how to decide what an automation may write on its own and what it must hand to a person. The two principles it rests on can be inspected on this site: confidence-threshold fallback in the ScoutLocal case study, and read-only-by-default, validated tool boundaries in the MCP SQLite demo.
The problem. Values arrive in one system and someone retypes them into another: invoice fields into accounting, form submissions into a customer record, rows from a spreadsheet into a database. It is slow, it is inconsistent, and once volume grows it is hard to audit who entered what.
Most data entry work is really three problems: extraction, validation, and the path a record takes when validation is not sure. Automating the first two without designing the third is how teams end up with clean-looking records that are quietly wrong.
Level 1: structure the input
Data entry exists because the input is unstructured. Before adding any extraction, ask whether the input can be structured at the source: a form with required fields instead of a free-text email, a portal where the counterparty enters values directly instead of sending a document to be retyped.
This is the cheapest level and it removes the extraction problem entirely for every input that can be moved here.
Level 2: extract into a schema, not into the database
For inputs that stay unstructured, extraction should produce a typed record that matches an agreed schema: named fields, expected types, allowed values. The extractor's output is a candidate, not a committed record.
The MCP demo applies the same boundary to tool calls: every input is validated against a schema before anything runs, and write operations are off by default. Extraction should be held to the same standard. A field that fails validation is not "probably fine"; it is a review item.
Level 3: decide what may be committed without a person
This is the decision that matters. For each field, the team agrees on the rule that makes an automatic write acceptable, and everything that does not meet it goes to review.
- Meets the agreed rules: commit the record and log the source it was extracted from.
- Missing, ambiguous, or below the agreed confidence: route that record, or just that field, to a person with the original input attached.
The ScoutLocal case study shows the shape of this rule in a search context: when the semantic match is below a tuned threshold, the system falls back to deterministic SQL matching instead of trusting a weak result. The principle transfers directly. A weak extraction should fall back to a person, not be committed because it was the best guess available.
What the review path needs
- The original input next to the extracted value, so the reviewer checks rather than re-enters.
- One field at a time where possible. Reviewing an uncertain total is quick; re-keying a whole record is the job the automation was meant to remove.
- A record of the decision. Which fields were auto-committed, which were reviewed, and by whom. This is the audit trail that manual entry never had.
- A rate to watch. If most records go to review, the extractor or the schema needs work. If none do, the threshold is probably too loose.
When this is the wrong build
- The decision behind each entry is rare or too subjective to write down as a rule.
- The volume is low enough that a good form and a checklist solve it.
- Nobody will own the review queue. An unattended review path is a backlog, not a safeguard.