An Answer Needs a Route Back to Its Evidence
Provenance records how a claim was produced and changed, helping people inspect an answer without mistaking traceability for truth.
A system says that Pump P-17 requires inspection every 500 operating hours. The sentence is clear enough to schedule work. It leaves other questions open. Which model of pump? Under what operating conditions? Did the interval come from the manufacturer, a later engineering review, or a note copied from another site? Has the requirement changed?
The data may show that P-17 has run for 487 hours. A manual may contain a maintenance table. An engineer may have approved a local variation. A software rule may compare the hours with an interval and issue an alert. Calling the alert “knowledge” can hide the several different claims and actions that produced it.
Knowledge engineers use provenance to preserve this history. W3C describes provenance as information about the entities, activities, and people involved in producing something. It can help somebody judge the quality, reliability, and trustworthiness of a record. It does not, by itself, prove that the record is true. (W3C PROV Overview)
A source is not a warrant for every use
Suppose the 500-hour interval appears in a genuine manufacturer manual. That is a strong source for the models and conditions the manual covers. It is not proof that P-17 is one of those models, that the manual is the latest revision, or that the pump has been used under ordinary conditions. A source can be authentic and still be applied to the wrong case.
The system needs to preserve the relation between the claim and its scope. Which pump type does the rule concern? Which manual revision supplied it? Did a qualified person approve a site-specific change? How did the actual pump record become linked to that type? Each link is another opportunity for correction.
If the application simply displays a citation beside the final sentence, it may create the appearance of evidence while concealing the weak link. An inspectable answer should let a person move from the alert to the rule, from the rule to its source, and from the equipment record to the identification on which the rule depends. The route needs to be short enough to use during work and complete enough to investigate when the answer is contested.
Truth, evidence, and authority differ
A laboratory result can be evidence for a claim without settling it. A technician’s observation can be important without becoming a confirmed diagnosis. A signed approval can authorize a decision while relying on evidence that later changes. Knowledge systems need to keep these relationships separate.
This is an old philosophical question in operational form: what warrants the claim that we know something? The familiar account of knowledge as justified true belief never provided a complete answer; Edmund Gettier’s 1963 cases showed how a belief might be justified and accidentally true without amounting to knowledge. A maintenance system does not need to solve epistemology to benefit from the warning. Correct output and a plausible citation are not enough if the path between evidence and conclusion is unsound. (Stanford Encyclopedia of Philosophy, analysis of knowledge)
Provenance is also useful when knowledge changes. If an inspection interval is revised, the organization can find which rules, alerts, open work orders, and past decisions used the old value. That does not automatically tell it which decision to reverse. It tells the responsible people where to look.
The present generation of AI applications makes this problem more visible. A language model can write a smooth answer from retrieved material, and the answer may be correct, wrong, or correct for a different context. The next post examines how external retrieval changed what knowledge engineering must supply to such a model.
