When AI enrichment meets human edits

An enrichment pipeline usually starts with a simple assumption: if the system finds better information, it should write that information back.

That assumption works until a person edits the same record.

Imagine a venue record with an automatically suggested category. Before the enrichment job finishes, someone reviews the venue and changes that category because the suggestion does not match how the place actually operates. A few minutes later, the job completes and writes its original suggestion over the correction.

The pipeline did exactly what it was designed to do. It also erased a decision made by someone with better context.

That is the problem behind the way I think about enrichment systems: automation should reduce repetitive work without making human corrections temporary.

A field is more than a value

A record is not just a collection of values.

A category may have come from an external source. An address may have been assembled from several candidates. A description may have been generated automatically and later corrected by someone who understood the context better.

If the database stores only the current value, it becomes difficult to answer basic questions:

• Where did this value come from?
• When was it last changed?
• Was it written by a person, a provider, or an automated process?
• Is the next automated result allowed to replace it?
• What should happen if two sources disagree?

Those questions are part of the data model, not just debugging questions.

The system needs to preserve enough information to explain why a field has its current value.

Provenance makes the decision visible

The useful unit of provenance is often the field, not only the record.

A record can have a human-reviewed address and an automatically suggested category at the same time. Treating the whole record as either “manual” or “automated” is too coarse.

Field-level provenance makes the distinction explicit.

For each important value, the system can retain information about its source, the kind of evidence behind it, and the operation that produced it. That does not mean every field needs a complicated history interface. It means the backend should be able to distinguish a human decision from an automated suggestion.

This changes how enrichment code is written.

The job no longer asks only:

What value did the provider return?

It also asks:

Is this field eligible for an automated write?

That second question is usually more important.

Write policies are safer than scattered exceptions

A common way to protect human edits is to add a separate condition inside each enrichment workflow.

That can work for one field and one process. It becomes difficult to trust when several parts of the system can write to the same data.

Enrichment, normalization, geocoding, search preparation, and manual review can all evolve independently. If each workflow implements its own version of “do not overwrite a human edit,” the policy will eventually drift.

A better approach is to make write eligibility explicit.

Before changing a field, the system should determine:

• which field it wants to change;
• what source produced the candidate;
• what existing provenance protects the field;
• whether the candidate is strong enough to apply;
• whether the result should be stored for review instead of written directly.

This makes the decision testable. It also gives later workflows a shared rule instead of another special case.

Discovery is not acceptance

One of the most important distinctions is between finding a candidate and accepting it.

An external source may provide an address. A service may return a possible match. An AI model may suggest a category. Those results are useful, but they are not automatically product truth.

The system can record the candidate and its evidence first. A later policy can decide whether the value is safe to apply.

That separation helps in several ways.

A provider failure does not look like an empty answer. A low-confidence result does not silently replace a reviewed value. A person can inspect the evidence before accepting a change. A retry does not need to guess whether the previous attempt already changed the record.

It also makes testing more meaningful. Instead of testing only that a provider response is parsed, the system can test that protected fields remain protected and that unresolved candidates follow the intended path.

The difficult decision is usually the boundary

The interesting part is not deciding whether a model can produce a value. It is deciding when the value is safe to apply.

A high-confidence suggestion for an empty field may be safe to write automatically. The same suggestion should probably follow a different path when a person has already edited that field.

A candidate can also be technically valid and still be wrong for the product. A place may match a provider’s taxonomy while belonging to a different category in the product’s own language. Two sources may both be plausible while describing different parts of the same place.

Those cases need an explicit outcome. The system can accept one candidate, preserve the existing value, record a conflict, or send the decision for review. Returning “success” after silently choosing one is usually the least useful result.

Automation needs an honest result

A background job that finds a candidate has not necessarily completed its job.

It may have discovered useful information that the write policy correctly refused to apply. That is a valid outcome, and the system should be able to represent it.

Useful outcomes include:

• candidate found;
• candidate rejected;
• field protected by a human edit;
• provider failed;
• evidence stored for review;
• value accepted;
• downstream synchronization requested.

When these outcomes are visible, retries become safer. Operators can distinguish “nothing was found” from “something was found but should not be written.”

That distinction prevents the system from rewarding automation simply because it changed more rows.

Human edits are part of the product

It is tempting to think of manual corrections as exceptions that automation should eventually eliminate.

In real products, they are often part of the quality model.

People notice context that a provider does not have. They recognize when two similar records are actually different. They can see when a category technically matches a source but does not describe how people use the product.

The goal of automation is not to make those decisions disappear. It is to reduce repetitive work while preserving the decisions that require judgment.

A human edit should not be treated as an obstacle to enrichment. It should be treated as a signal that changes what enrichment is allowed to do next.

The practical lesson

The safest enrichment systems do not ask only whether automation found a value.

They ask whether the system has permission to write it.

That permission depends on provenance, field-level policy, evidence, and the history of the record. Once those concerns are explicit, automation can become more useful without becoming destructive.

The result is not a system that never changes automatically. It is a system where automated changes have a clear boundary, human decisions remain durable, and every important write has a reason behind it.