A photo, voice note, and work card enter one case file, while conflicting information waits for the coordinator.
The system keeps every item in its original form and compares the details they share. If the machine number or another value differs, both sources appear side by side. The coordinator chooses the correct value and records the reason.
What we measured
The reference implementation uses one fictional case and three synthetic files. It shows the evidence comparison, an open conflict, and two separate human decisions. It is read-only and contains no client data.
- Local test · separate reading check
- What we measured
- 16/16 local checks · 60/60 expected live checks
- Field incident documentation
- Verified
- synthetic material
Problem, solution, and result
The problem
Information about a field incident arrives as a photo, voice message, and document prepared earlier. A coordinator has to reconcile them by hand, while an ordinary summary may hide a contradiction that matters for safety.
How it works
Every file enters the case separately and retains its origin. The system compares shared fields and presents conflicting values side by side. An open discrepancy prevents closure until the coordinator decides.
What we tested
The reference implementation uses one fictional case and three synthetic files. It shows the evidence comparison, an open conflict, and two separate human decisions. It is read-only and contains no client data.
For whom
This system fits field operations where incident records arrive through several channels, details sometimes conflict, and the decision to resume work needs a named owner and reason.
Three exhibits → one file → a decision
- 01Every piece of evidence keeps its original, digest, time, and author
- 02An open discrepancy blocks the file from closing
- 03The works coordinator signs the value and the acceptance
- Business type
- Industrial plants and companies running field service for machinery
- Input
- A site photo, a voice note, and a PDF work card from one intervention
- Boundary
- The file will not close while a discrepancy is open, and only the works coordinator clears a machine for work
- Cost
- USD 0.047340 for 10 recorded image reads, or about USD 0.004734 per read.
- Security
- Conflicting details or an unknown safety state keep the case open for the coordinator’s decision.
- Speed
- We measure image and voice-note reading time in a pilot using field material.
- Trace
- Each item retains its source, time, and author. The history exposes later changes to a record.
- Similar system build
- from €6,000 net (approx. $6,500) · 4–10 weeks
Reference exchange rates: USD 1 = PLN 3.72; EUR 1 = PLN 4.30. PLN amounts are rounded, with the measurement currency retained in parentheses.
The decision boundary
Only the works coordinator clears a machine for work
The system describes the material and organizes the evidence. It does not identify the machine, decide where the fluid came from, or release equipment for work. The works coordinator resolves the conflict by choosing a value found in the evidence, selecting a reason from a closed list, and signing the decision. In production that entry is tied to an authenticated identity and role. The demonstrator has neither, so it rejects both writes.
- Boundary
- The file will not close while a discrepancy is open, and only the works coordinator clears a machine for work
- Cost
- USD 0.047340 for 10 recorded image reads, or about USD 0.004734 per read.
- Security
- Conflicting details or an unknown safety state keep the case open for the coordinator’s decision.
- Speed
- We measure image and voice-note reading time in a pilot using field material.
What the system cannot decide
Transcription can vary in punctuation, so the original audio remains the source and the text stays a suggestion. A photo without the nameplate cannot settle the machine number. The history reveals later changes, while production still needs access control, retention rules, and protected storage.
Estimated impact
Calculate the impact at your volume
This estimate uses the stated volume. Enter your own numbers to assess the possible impact in your company. The result is confirmed only during a pilot.
Today
Current assumption: 105 h/month (35 min/case)
With the system
After scenario: 42 h/month (14 min/case)
Time or cost saved
Modelled scenario: 45-80 h/month, 63 h base case
- Volume
- Modelled scenario: 180 cases/month
- Formula
- 180 x (35 - 14) min / 60 = 63 h/month
- Calculation status
- medium
Data in the screenshots. The names, amounts, and documents shown in the screenshots are synthetic. Client data remains private. Measurements describe the demonstrator and are kept separate from production outcomes.
Working surfaces
The works coordinator has the evidence in one place and signs what goes into the file.
The coordinator opens one incident card and has everything that came from the site on it: a photo to enlarge, a recording to play, the work card as issued, and beside each file a time, an author, and a digest. The discrepancy sits in plain sight, and the decision about it carries a date, a basis, and a name, so the question “how do we know it was that machine” has an answer in the file's history. How much this shortens case reconciliation at your incident volume and through your channels has to be measured at your place; the public run does not say.
Three screens: the incident, the evidence, the resolution.
Incident card
Everything that came from the site on one screen: the risk, the location, the file's state, and the next step.
Evidence register
Three files with author, registration time, format, and the SHA-256 digest; the full digest and the original open in the evidence card.
Resolution
Both readings of the machine number side by side, the decision field, the basis and the reason, then the acceptance step.
System screens
See how the system works in practice
These desktop and mobile screenshots come from the running application. They show the process and the points where a person makes the decision.
- Screens
- 8
- px
- 1440 · 390
- 021440×1100
Two source readings with quotations plus the decision gate blocked without an authenticated role. - 031440×1100
The mobile evidence register with explicit provenance and no client information.
Open the remaining screen archive (5)
- 041440×1100
The three-item evidence register - 051440×1100
A model suggestion and its limit - 061440×1100
The conflict in the source comparison - 071440×1100
Acceptance blocked by the conflict - 081440×1100
Record-chain continuity
Technology stack
The evidentiary core is ordinary code and a database, because evidence has to be checkable without a provider.
There is no loop to orchestrate here: the work is registering files, lining up fields, keeping a discrepancy alive, and holding two gates, so an agent framework would be ballast. We use FastAPI and PostgreSQL because the case state and the hash chain commit in one transaction, and the whole decision path reads as code and tests without a network. Image reading and transcription sit beside that core as an optional layer: turn the keys off and the file, the discrepancy, and the history still work. For maintenance that means one language in the API, one database to back up, and a provider dependency only where the output is a suggestion anyway.
- FastAPI, Pydantic, psycopg
- registers evidence, lines up the case fields, and validates both human entries
- PostgreSQL 17
- holds the case, the discrepancy, and the hash chain; a transactional lock serialises event appends
- Named Docker volume
- stores the original PNG, WAV, and PDF, served only by evidence identifier
- Next.js 16, React 19
- the coordinator's seven working routes; an unavailable API is a visible error rather than a quiet fallback to placeholder data
- OpenAI Responses, gpt-5.6-sol
- opt-in description of visible facts in the photo, with a strict schema and store: false
- ElevenLabs Scribe v2, EU region
- opt-in transcription of the Polish voice note as an unverified suggestion
The client takes the code, the database schema, the evaluation data, and the documentation. The reference implementation runs as four Docker Compose services on one fictional case, has no login and no writes, and touches no client information; the only traffic leaving the network is the opt-in measurement run to two providers.
Technical details and measurements
The working loop
The file holds three pieces of evidence and never merges them into one version.
The field-by-field comparison shows where the sources agree and where they part. A single version appears only when a person writes it in, with the basis and the reason kept in the file's history.
A site photo, a voice note, and a work card from one intervention
Registration: the original file, its digest, time, and author
Ten fields lined up → the discrepancy stays open
Model reading → a suggestion marked unverified
The coordinator's resolution with its basis → a separate acceptance closes the file
System architecture
Registration, comparison, resolution, acceptance.
A deterministic evidentiary core in FastAPI and PostgreSQL, where the case state and the hash chain commit in one transaction. Model readings sit beside it as an optional layer.
- 01
Evidence
Three formats enter as originals.
The PNG, WAV, and PDF land in a named volume without re-encoding, and the SHA-256 digest is computed over the bytes as they arrived. The evidence card shows the full digest, the declared source, and what the file does not carry: an image without EXIF supplies no capture time, so that field comes from the reporter's declaration.
- 02
Comparison
Ten fields, three sources, gaps left visible.
The system places the case fields side by side by source and fills no gap with a guess. The discrepancy is its own object in the database, holding both readings and its own state, so it can be counted and reported.
- 03
Suggestions
Model readings are optional and labelled.
Image description runs on OpenAI Responses with a strict JSON schema, a 220-token output cap, and store: false; transcription runs on ElevenLabs Scribe v2 in the EU region. Both results enter the file as unverified suggestions, and missing keys never stop the evidentiary workflow.
- 04
Gates
Two human entries under two different conditions.
A resolution accepts only a value that appears in the evidence and a basis from a closed list, and rejects whitespace-only fields. Acceptance requires a prior resolution, a second resolution attempt ends in a state conflict, and a transactional lock on the case identifier serialises appends to the history.
Why merging the sources would be a defect
The simplest summary of three accounts would produce one smooth description and false confidence about which machine is down. This system earns its keep because the discrepancy has its own place and its own life cycle, right up to the human entry. The stack is deliberately short as well: the evidentiary core is ordinary code and a database, because complexity here has to defend itself with proof, and the model layer has nothing to defend in the machine-safety field.
- Originals and digests stay in the file
- The discrepancy lives until the coordinator writes
- Model readings never touch the safety field
- Accepting the file is a separate, recorded decision
Want to assess a similar process in your company?
- A 30-minute call with the engineer who would lead the work.
- A review of the processes that cost you the most time and money.
- A written summary of what to automate first and the likely cost range.
Times are shown in your own time zone. We work with clients across time zones.
The scan is free and creates no obligation. If automation is unlikely to pay off, the written recommendation will say so.