Conflict as an object: why an evidence system never merges contradictory sources

A field event reaches the office in several formats: a photo, a voice note, a work card, and perhaps a service-system entry. A polished summary can become the main risk if it hides disagreement between those sources. When the recording identifies machine P-14 and the work card says P-41, the conflict is information required for a safe decision.

An evidence workflow should preserve three things: the original material, the provenance of every extracted fact, and the state of unresolved conflicts. That gives the coordinator a basis for action and makes the decision reconstructable later.

When an evidence workflow is justified

Consider this pattern when an event has financial, quality, or safety consequences; material arrives through multiple channels; and closure requires a named accountable person. Common settings include maintenance, warranty claims, transport damage, construction acceptance, and field service.

A simple register may be sufficient when all facts arrive through one controlled form, conflicts are rare, and decisions are easily reversible. The extra evidence layer earns its place when the cost of a wrong decision or the time spent reconstructing events is material.

A data model that preserves uncertainty

A useful case file separates four kinds of record:

1. Evidence: the original file, registration time, declared source, author, and SHA-256 hash.
2. Extraction: a fact read from an exact location in one item of evidence, with the extraction method recorded.
3. Conflict: two or more values for the same field, stored as an open object.
4. Decision: the selected value, accountable person, basis, and reason.

This structure prevents an operator decision from overwriting source material. It also enables operational reporting: open conflicts, time to resolution, and the channels that most often deliver incomplete evidence.

In the field case file, three synthetic files remain separate evidence. The system compares shared fields, displays two machine identifiers side by side, and holds the case open. A coordinator selects a value present in the material, records the basis, and accepts the file in a separate step.

A safe role for models

Speech recognition can prepare a transcript, and a vision model can describe what is visible in a photo. Both outputs should be marked as suggestions and link directly to the original. The model should have no field that can authorize a machine restart or decide which conflicting value is correct.

Before implementation, define:

• which fields may come from automated extraction;
• what confidence or condition routes an output to review;
• which decisions require a role or second approval;
• how long originals and history are retained;
• how intake works when a model service is unavailable.

The evidence workflow should continue without a model. Automated reading may reduce preparation time, while registration and human resolution remain available during an outage.

Common implementation failures

The first is storing a summary without a path back to the source. The second is choosing a value by document count, even though three forwarded copies may be one declaration. The third is treating a checksum as a complete audit control. A hash reveals a later change, but durable evidence also needs access control, retention, backups, and suitable storage.

Capture time also needs careful semantics. A photo without metadata does not prove when it was taken. The interface should say when a timestamp was declared by the reporter rather than recovered from the file.

Reading the evidence and cost

The controlled system covers one fictional case. Its checks exercise file integrity, explicit conflict state, workflow holds, and human gates. Separate image and speech runs test whether suggestions retain the required structure. They do not establish quality on a client's field photography or quantify coordinator time saved.

Model usage is only one cost line. A pilot should also measure evidence items per case, review time, unreadable-file rate, retention and storage, and the proportion of cases that need resolution. A strong business metric is elapsed time from receipt of the final evidence item to accepted closure, while preserving the safety rules.

Pilot checklist

• Select one event type and define its minimum evidence set.
• Name the conflicts that must hold a case open.
• Assign roles for registration, resolution, and acceptance.
• Preserve originals and locators from each fact to its file.
• Prepare cases with missing evidence, duplicates, conflicts, and unreadable material.
• Measure handling time before and after the pilot.
• Test retention, permissions, backups, and history reconstruction.

The case page shows the mechanism and its measured limits. A free process scan can identify the first event type worth testing.