A field engineer restores a display and marks the case resolved. The note says "fixed." The case does not record what failed. It does not show which component was checked. It does not confirm whether the fault returned after movement. It provides no evidence.
The equipment may be working. The operating record is not complete.
This walkthrough follows one synthetic display fault from configuration to reporting. The names, sites, assets, and cases are illustrative. The point is the workflow. Define the evidence before dispatch. Enforce it at closure. Keep troubleshooting reviewable. Preserve a path from every report number back to the work underneath it.
Define completion before dispatch
The example begins with a governed issue classification: Display fault. The classification gives the team one place to define what must be captured whenever that issue appears.
The issue classification becomes the shared definition for field evidence and reporting.
The manager defines five fields:
- Observed screen state.
- Diagnostic code.
- Display cable condition.
- Resolution path.
- Confirmation that evidence was captured.
Every field is required. The decision is deliberate. A diagnostic code without a component condition is difficult to interpret. A repair path without post-repair evidence is difficult to defend. Free text can add context, but it cannot replace the minimum operating record.
The same required-field definition drives the field form, closure validation, and report catalog.
This is where structured field operations differ from adding another checklist document. The definition is attached to the issue. It follows the case into the technician interface and becomes part of the closure rule. The manager decides which facts are mandatory before any engineer leaves for the site. The system then enforces the record they agreed to collect.
That does not remove operator judgement. It makes the judgement legible. The technician still decides what they observed and which repair was performed. The service manager still decides which facts are mandatory. The result is narrower than a generic form builder and more useful than a free-text ticket. The fields exist because an operating decision depends on them.
Carry the evidence rule into the field visit
Jordan Lee opens FIELD-104, a synthetic case for a customer-facing display that drops out after cabinet-door movement. The application remains responsive and the diagnostic log records DISP-204, which points the investigation toward the display signal path.
The mobile work surface shows the site, asset, and classification. It also shows the conversation and completion details for the assigned job.
The technician sees the affected asset and required completion details without navigating an administrative case screen.
Two facts are already present: the screen blanks intermittently and the diagnostic code is DISP-204. Three required facts are still missing: cable condition, resolution path, and evidence confirmation.
The interface says so at the point of work.
Resolved work cannot be closed while required evidence is missing.
This distinction matters. Resolved describes the service state. Complete describes the operating record. Treating them as the same thing is how teams end up with closed cases that cannot support a repeat visit, a manager review, or a trend report.
The engineer powers down the unit, inspects the display path, and records a loose connector. The selected resolution is Reseated display cable. Three controlled door-movement cycles pass without another DISP-204 event.
The technician records those facts in the required fields and drafts a plain-language update. The attachment control provides direct access to a photo, video, or existing device file.
Structured values, narrative evidence, and media capture stay in the same field workflow.
This is not a choice between forms and conversation. The structured fields answer the questions that must be comparable across cases. The note explains what happened on this visit. Photos and video provide supporting evidence where the physical condition matters.
Once the required values autosave, the close action becomes available.
The closure control unlocks only after the required operating record is complete.
The enforcement happens while the engineer still has access to the equipment. A reminder sent after the visit has already missed the useful moment.
Let AI guide the next check without taking control
The case also contains an AI troubleshooting recommendation. It proposes:
- Power down the kiosk.
- Inspect and reseat the display cable.
- Restore power.
- Complete three controlled door-movement cycles.
The recommendation includes a confidence score and its reasoning. Application audio continues while video disappears. The fault repeats with door movement. The diagnostic code points to the display signal path rather than a full power loss.
AI proposes a bounded next step. The operator reviews the evidence and decides whether to use it.
The recommendation does not silently change the case or declare the root cause. A proposed task remains visible for review. This control boundary is what makes the suggestion useful on real work. The model narrows the search. The person who can inspect the equipment still decides.
Turn field evidence into a governed operational report
After several display cases, the service manager wants to know which observed symptoms coincide with which cable conditions.
The report library contains a saved definition named Display fault patterns by observed state and cable condition. It sits beside standard operational reports and can be rerun without rebuilding the question in a spreadsheet.
A saved report retains its measure, dimensions, time window, filters, visualisation, and owner.
The reporting engine does not expose arbitrary SQL. It provides an allow-listed set of measures and dimensions. Standard dimensions appear alongside governed Issue Data Fields. Those dimensions include customer, site, asset, status, priority, and engineer.
Custom workflow facts become report dimensions without becoming an unrestricted query surface.
The names remain specific: Display fault · Observed screen state and Display fault · Display cable condition. A generic label such as "Condition" would become ambiguous as soon as another issue type defined a field with the same name.
The saved report records stable field identifiers rather than copying display labels into query logic. The backend resolves those identifiers against the governed schema and runs a parameterised query. Changes to the visible label do not silently change what the report means.
The synthetic report covers eight distinct cases. Intermittent blanking with a loose connector appears three times. Flickering with a secure connector appears twice. Blank displays with damaged cables and colour distortion with secure connectors appear once each.
One case has no field values. The report does not discard it. It appears as Not provided.
The report counts distinct cases and keeps missing evidence visible instead of quietly shrinking the denominator.
That treatment matters. If incomplete records disappear from the report, the operation can look cleaner as evidence quality gets worse. Keeping missing values visible turns data completeness into something managers can monitor.
The result also avoids multiplying case counts through related tags, assets, or history records. The unit being counted is the distinct case, not every joined row that happens to describe it.
Make every aggregate answerable
An aggregate can reveal a pattern. It cannot explain whether the pattern is trustworthy on its own.
The manager opens the Intermittent blanking · Loose connector row. The drill-down shows the three contributing cases. For each, it includes the issue classification, governed field values, and status. It also includes the assigned engineer, resolver, and other case evidence.
Each aggregate row retains a path to the case records that justify it.
This is the useful boundary for a custom reporting engine. Managers can ask operational questions that were not anticipated in a fixed dashboard. The answer stays governed by known measures, named dimensions, and explicit filters. The source records stay readable.
Field evidence should be defined before dispatch. It should be enforced before closure. It should be reusable after the visit. The sequence holds together because each step feeds the next: the required fields defined up front become the closure rule in the field, the completed evidence becomes the basis for a reviewable AI recommendation, and the same governed values become the dimensions and drill-down paths in the report. A field case is complete when the equipment state and the evidence record agree. That is what turns one repair into operational memory for the next visit.