Unit 4 · On your own work
When the work is physical
The principle
A chat assistant reads a description of the machine, never the machine itself — and every failure worth worrying about lives in the gap between the two.
By the end: You can take one alarm from your own area and name what the instrument measures, what the failure would be, and the cheapest observation that separates a bad instrument from a bad machine.
The situation
06:40. The night shift left one line in the log: "Pump 4 rough after 02:00, vibration climbing, kept it running." You open the monitoring page. Overall vibration at the drive-end bearing moved from 4.2 to 7.1 mm/s over six hours, then flattened. The technician who walked past at 04:00 says it sounded normal. Production wants that line for a full run today. You have twenty minutes to say something.
None of this is a document problem. The numbers are real, the log note is real, and neither of them tells you what is happening inside a casing you cannot see into. The reading went up. The machine may or may not be failing. Those are two different questions, and only one of them has data attached.
The principle
A chat assistant reads a description of the machine, never the machine itself — and every failure worth worrying about lives in the gap between the two.
In documentary work the text is the thing. A contract is its words. A plan is its rows. In physical work every input is a proxy: a sensor with its own drift, a note typed at the end of a twelve-hour shift, a reading taken at one point on a casing that is hotter on one side than the other. Four things change. Latency — the deadline belongs to the machine, not to your calendar. Consequence — a wrong call costs a shutdown, a scrapped batch, or a person. Noise — the reading can be wrong while the equipment is fine, and the equipment can be failing while every reading sits inside limits. Observability — most of what a good technician knows was never instrumented at all.
So be exact about the split. AI is good at reading everything at once, holding a fixed structure under time pressure, and listing what would have to be true for a reading to mean what it appears to mean. It is not the thing that decides whether a machine is safe to run. It is not standing at the equipment, and it does not carry the accountability for running it.
Worked example
Shown here in Gemini.
The useful move is not asking for a verdict. It is asking for competing explanations plus the cheapest observation that separates them.
Job: A pump shows a rising vibration trend and I have twenty minutes before
a production decision. Do NOT tell me whether to run it.
Inputs: Drive-end overall vibration 4.2 mm/s at 02:00, 7.1 mm/s at 06:00,
flat since. Non-drive-end unchanged. Motor current unchanged. Coupling was
replaced eleven days ago. Ambient dropped 9 C overnight. Night technician
reports no audible change at 04:00.
Output: A two-column table. Column 1, explanations consistent with these
readings. Column 2, the single observation that would rule that explanation
out. Order rows cheapest check first.
Standard: List instrument and mounting faults alongside machine faults. If a
pattern fits two causes equally, say so rather than choosing one. Do not
recommend an action.What came back, abbreviated:
Loose accelerometer mount / cable Re-torque sensor, retake reading in situ
after coupling work (2 min, no shutdown)
Thermal growth after ambient drop Compare against the last cold-night
changing alignment trend at similar ambient (5 min, desk)
Coupling misalignment from the Dial-indicator check at next stop
eleven-day-old rebuild (25 min, requires shutdown)
Bearing degradation Spectrum at bearing defect frequencies;
overall value alone cannot show thisThe first two rows are not machine faults at all. Getting them onto the same table as the bearing is the entire value of the run — it is the instruction list instrument and mounting faults alongside machine faults that produced it, and it is the line most people leave out.
In your tool
The capability that matters here is arithmetic over a file of time-stamped readings, done by running code rather than by eyeballing numbers in a chat window.
| Tool | Working from a file of readings |
|---|---|
| Claude | Upload the file; it writes and runs code over the rows and shows you the code |
| ChatGPT | Upload the file; it writes and runs code over the rows and shows you the code |
| Gemini | Upload the file or point it at a sheet; it can execute code on the values in the conversation |
| Microsoft 365 Copilot | The arithmetic happens inside the host app, against the open spreadsheet, rather than in general chat — the formulas it writes are the trace |
Product surfaces checked 2026-08-04.
Try it
Take one alarm or reading your area produced in the last month. Write three lines. What the instrument physically measures. What the failure would physically be. The cheapest observation that separates a bad instrument from a bad machine.
You are done when the third line names a physical action, a person who can do it, and how long it takes. "Investigate further" does not count. "Re-torque the sensor mount and retake it, technician, two minutes" does.
Common failures
- Treating the reading as the equipment. The trend line is evidence about a sensor and its mounting as much as about a bearing. People skip that because the chart looks like the machine, and the machine is not in the room.
- Asking for a verdict. "Should I run it?" returns a confident answer built from an average of everything ever written about pumps, not from your pump. Ask for explanations and discriminating checks instead — both can be verified in front of the equipment.
- Feeding it only the clean numbers. The trend sits in the historian; the fact that the coupling was rebuilt eleven days ago sits in someone's head. Given half the record, a model returns a confident answer about half the machine.