Ask a general-purpose chatbot about the corrosion history of exchanger E-101 and it will answer fluently. It has never seen E-101. The answer is a plausible-sounding composite of its training data, and plausible-sounding is precisely the failure mode an inspection program cannot afford. A wrong number stated confidently is worse than no number, because it travels: into a scope decision, an interval calculation, a turnaround plan.
This is why the useful question for evaluation committees is not "does the product have AI" but "where do its answers come from, and can I check them."
Two architectures, one distinction
The distinction that matters is grounding. A generic assistant generates answers from patterns learned in training. A grounded assistant retrieves from a specific, bounded corpus, in this case your own inspection records, and composes its answer from what it retrieved, citing the records it used.
The consequences are practical:
- Source. Grounded answers come from your readings, your reports, your recommendations. Generic answers come from the internet's average refinery, which is not your refinery.
- Verifiability. A grounded answer arrives with citations: this reading, that report page, this recommendation record. The inspector can open each one and confirm before acting. An answer without citations can only be trusted or distrusted; it cannot be checked.
- Honest failure. When the record does not contain an answer, a grounded system can say so: no internal inspection report exists for this vessel in the range you asked about. That "I don't know" is not a weakness; it is often the finding. A generic model fills the gap with fluent invention.
- Boundaries. A grounded system answers within your data and your permissions. It does not know things your records do not contain, and it should not answer questions your role is not permitted to see.
What this looks like in inspection work
The daily value is retrieval speed on questions practitioners already ask, against records that already exist:
- Before a field visit: what were the last three thickness readings at this CML, and was anything flagged? Answered with the readings themselves, not a summary of them.
- During planning: which recommendations on this unit are open past their due date, and what did each originate from? Each item cited back to its inspection.
- During an audit: when was this relief valve last serviced, and where is the record? The answer is only useful if the record opens.
- During a turnaround: what did we find the last two times this vessel was opened? Cited to the reports, with the photographs attached to them.
None of this is exotic. It is the corpus of work your program has already paid to create, made answerable in seconds instead of an afternoon of folder archaeology.
Questions to put to any vendor
Ask where answers come from, and insist on specifics: retrieval from customer records, or model general knowledge, or an undisclosed blend. Ask to see a citation opened live, from answer to source record. Ask what happens when the corpus lacks an answer, and watch whether the system admits it. Ask whether one customer's data can influence another customer's answers. Ask how permissions apply: does the assistant respect the same access controls the user has elsewhere in the product?
Vague answers to these questions are themselves the answer.
Spectra, the assistant inside intelliSPEC, is built on this grounding contract: it answers from the customer's own inspection record, with citations, and says so when the record is silent. Hold it, and every alternative, to the standard above: no citation, no trust.
