A customer reports that a machine overheats. A technician notes that its display showed a warning. A later report says the cooling system failed. Those statements have different sources and levels of authority. If a summary blends them, an unverified suspected cause can become an apparent technical conclusion. A useful evidence record preserves the distinctions through intake, inspection and later reporting.
AI can help organise varied notes into a consistent record. This proposed workflow does not diagnose equipment or decide whether it is safe to operate. The responsible technician and technical owner retain the assessment and approval decisions. Its practical output is an evidence record that shows what was reported, what was observed and what was actually concluded.
Give every statement a source and an authority level
Create separate categories for customer-reported symptom, technician observation, tentative interpretation and approved conclusion. Keep the original wording beside any concise paraphrase. Customer says it happened after a power interruption is not proof that the interruption caused the fault. Technician suspects a sensor issue is not confirmation that the sensor failed.
Record the source person or role, job and equipment identifiers, time and relevant conditions. A reading without its unit or measurement context is incomplete. A photograph may show an indicator at one moment without establishing how long it remained active. If the source is a forwarded account, label that limitation rather than describing it as direct observation.
Use authority labels to express process status, not to assign arbitrary confidence percentages. A customer can accurately observe a symptom; a technician can make a tentative interpretation. Neither person's role alone turns a statement into a final conclusion. The technical owner determines what review or evidence is required.
Keep measurements and narrative in linked records
Preserve numeric values, units, tolerances where supplied, equipment references and the original record. Treat a part number as an identifier, not a quantity to round or reformat. If an unclear character changes the possible equipment match, keep it unresolved until the technician clarifies it.
Source: OpenAI Structured Outputs describes schema-constrained responses. A proposed schema can require source category, evidence reference, measurement fields and approval state. A required field should allow an explicit unknown where the input is incomplete. Schema conformity does not validate a reading, establish causation or confirm a diagnosis.
Do not ask the model to fill gaps from typical values for similar equipment. A familiar-looking measurement can belong to another operating condition or model. The workflow should return a focused clarification question with the affected record reference, keeping technical interpretation separate from administrative formatting.
Reusable reported-observed-concluded evidence record
Use this proposed record for each significant statement in a job. The responsible technical owner should approve the actual categories and sign-off rule.
| Field | Required content | Interpretation limit |
|---|---|---|
| Statement identity | Stable statement ID, job ID and equipment ID | Avoid merging different assets or visits |
| Original content | Exact note, message, image or reading reference | Preserve before summarising |
| Category | Reported symptom, observation, tentative interpretation or approved conclusion | Do not promote authority automatically |
| Source | Person/role, channel and direct or forwarded status | Role alone does not prove correctness |
| Timing and conditions | Event/measurement time, relevant operating context | Receipt time is not event time |
| Measurement | Original value, unit and source location, if present | Missing unit or unclear digit remains unresolved |
| Supporting evidence | Linked records used by the technician | A related attachment is not automatic support |
| Uncertainty | Missing context, conflicting observation or provisional wording | Retain limits in later summaries |
| Technical decision | Accepted finding, further test requested or unresolved | Only authorised technical review changes this state |
| Revision | Earlier statement, correction reason and approving person | Do not erase the history |
A report can then use three explicit sections:
- Customer report: [Attributable symptoms and stated timing, with unverified suspected causes labelled]
- Technician observations: [Recorded evidence and conditions, including unresolved measurements]
- Approved findings and next step: [Accepted conclusion, supporting references, limitations and authorised action]
The completion check is that a reader can identify the source and review state of every technical assertion. If a conclusion is not accepted, it remains tentative or unresolved instead of appearing in the findings section.
Keep corrections from silently rewriting authority
A later technician may discover that the original equipment reference was wrong or that a reading was taken under a different condition. Create a corrected version with the reason and links to the earlier record. The report should indicate which version controls the current interpretation while preserving what the team knew at the earlier decision point.
Source: OpenAI function calling describes application execution of model-requested functions. A record-update function can enforce accepted job IDs, allowed fields and review permissions. It should not let a summarisation step change a tentative finding to approved simply because the generated wording sounds definitive.
Keep a distinction between correction of transcription and revision of technical judgement. Fixing a copied unit might require evidence from the original note. Changing the diagnosis requires the appropriate technical decision. An edit interface or model tool request should not collapse those two review paths.
Compare a straightforward observation with ambiguous notes
In a hypothetical inspection, the customer reports intermittent stopping after several minutes. The technician records the equipment ID and an observed warning on its display at the recorded time. Their note says further assessment is needed. The proposed record preserves the customer symptom and technician observation separately, with the interpretation still unresolved. A customer report can accurately state what was observed without inventing a root cause.
Now suppose an office summary says motor failure confirmed, although the technician wrote possible motor issue. The reviewer compares the source and restores the tentative wording. The report does not recommend replacement as if that diagnosis were established. Any authorised next step refers to the technical owner's accepted decision.
A duplicate imported note with the same stable statement identifier should retrieve the existing record. Similar notes from two visits remain separate because timing and conditions may differ. If the customer and technician disagree about when the symptom occurred, the report retains both accounts and asks for clarification instead of choosing the more authoritative-sounding person.
An unreadable measurement creates a specific exception. The workflow should show the original evidence to the technician and request clarification through the approved process. It must not select a plausible digit because that would support the emerging explanation.
Review summaries before they become customer findings
Source: n8n human review documents approval or denial for selected agent tool actions. A team might place a review gate before external report delivery or an authorised record update. That mechanism does not determine technical competence, evidence sufficiency or safe next steps. Those remain organisation-specific responsibilities.
Evaluate the proposed organiser using technician-labelled records containing suspected causes, unclear units, contradictory timing, forwarded messages and revised findings. Check whether it preserves negation and tentative language, whether it links the correct equipment and whether it invents conclusions. A fluent report is not evidence that the workflow correctly handled authority.
Questions about evidence authority
Is a technician's note automatically a verified finding?
No. A technician can record observations, hypotheses and accepted conclusions in the same note. The workflow must preserve those distinctions and the technical review state. Do not use the person's role as a shortcut that promotes every sentence into a final finding.
Can the assistant remove uncertainty to make the report easier to read?
It can simplify language without removing the meaning of uncertainty. Possible, reported and awaiting verification may be essential to the statement. If a shorter sentence would become more definite, retain the limitation or ask the technician to approve a different wording. Clarity should help the reader understand the actual evidence state.
What happens when a later inspection changes the conclusion?
Create a revision linked to the earlier record, with the evidence and authorised decision that justify it. Show which conclusion is current while retaining the historical sequence. This allows the team to understand earlier actions without presenting an obsolete finding as today's accepted assessment.
If your business needs help defining this process, explore Document processing, the wider AI automation services, and our custom-agent workflow guide. The agents and automation comparison and custom AI agent glossary explain the terms. To discuss your records and approval rules, get in touch.