Seeing Is Not Knowing

In 2023 a technician could not point a phone at a hydraulic manifold and get a useful sentence back. By 2025 they could. That change is real, it is well documented, and it is not where the difficulty lives.

What a general-purpose vision-language model does now - read a data plate, describe a leak, name a component, follow a photographed procedure - was research-grade three years ago and is table stakes today. Every vendor in the field service software market has shipped some version of it. The multimodal turn that MIT Technology Review flagged in mid-2024 arrived on schedule.

But the record of the last three years divides sharply, and it divides along a line that has nothing to do with model quality. Capabilities where the set of possible answers is small, enumerated, and owned by the deploying organization have scaled to millions of transactions and are producing measurable financial results. Capabilities where the answer space is open - or where the reference corpus belongs to a different team, a different vendor, or a different revision cycle - remain stuck at pilot, and the peer-reviewed evidence on why is unusually blunt.

The insurance industry did not win at visual AI because insurers had better models. They won because a repairable vehicle has a finite parts and operations catalog that the carrier and its estimating platform jointly control, and because a damage estimate is a number that a business already knew how to act on. Field service, for the most part, has neither condition.

A note on where this workshop sits in the literature

The workshop's subject - capturing and scaling tribal knowledge with video intelligence - maps onto exactly one class in the taxonomy that follows, and it is the class with no published measured outcome anywhere in the three-year record. That is not a warning. Every vendor in the category now sells this capability; not one has published a number for it, and no peer-reviewed study has measured it in a service setting. You are not late to something. You are early to something nobody has instrumented.

It is also worth separating the two verbs in the title, because they fail differently. Capturing is now cheap and largely solved - the enabling change of the last three years. Scaling is not a bigger version of capturing; it is a distribution, adjudication and maintenance problem that the capture tools do not address and mostly do not acknowledge. The pattern underneath and The Adjudication Layer take that apart.

Put the deployment record and the benchmark record next to each other and one variable explains both: whether the deploying organization owns and can write to the knowledge the system reasons over.

A field service organization's knowledge sits in four kinds of places, and they are not equivalent:

• OEM and engineering documentation - authored by another group, for another purpose, on a revision cycle measured in months or years. You may legally own it and still not be able to change it this quarter.
• Structured service data - work orders, parts consumption, warranty claims. Yours, but shaped by the billing and warranty processes that generated it, not by the diagnostic question you want to ask.
• Service call and session records - transcripts, video, photos, the technician's own notes. The one corpus you own outright, author yourself, edit at will, and can reuse for your own purpose.
• What is in the technician's head - the material the industry calls tribal knowledge, and which Julian Orr documented in Talking About Machines thirty years ago, when he found that Xerox technicians' war stories, not the documentation, carried the knowledge that actually resolved faults.

The term tribal knowledge is doing something specific and worth pausing on. It does not mean undocumented. It means knowledge that lives in a social structure - held by a group, transmitted by telling, validated by whether it worked for someone you trust. Orr's finding was not that the technicians had failed to write things down. It was that the war story carried context the documentation format could not hold: which machine, in which room, in which season, presenting how. Strip the context out to make it a knowledge article and you delete the part that made it usable.

That is the real difficulty in the workshop's title, and it is not a capture difficulty.

The business literature has converged on the same point from the strategy side. Tung and Roussiere argue in California Management Review that as agentic AI commoditizes, "the real differentiator is not the data or even the models, but the tacit knowledge embedded in the judgment of their people" - and their prescription is a semantic layer that structures how decisions get made, not a bigger corpus. The MIT NANDA study that produced the widely-quoted 95% figure locates enterprise failure in the same place: pilots die because the systems have no persistent memory, cannot be shaped to a workflow, and do not learn from correction. Their respondents' complaint - "it's useful the first week, but then it just repeats the same mistakes" - is a complaint about the absence of a writable knowledge layer, stated in user language.

Why the single-source-of-truth answer does not ship

The instinctive response to conflicting knowledge is to fix the source. In a service organization this fails predictably, and the constraint is not legal ownership - it is write access. An OEM manual may sit entirely inside your own company and still be unreachable, because the correction path runs through another team's revision cycle. Field truth cannot reach the source at field speed. A company-wide single source of truth dies on multi-use every time: the moment two groups need the same record to serve different purposes, the governance cost of reconciling them exceeds the value of having reconciled them.

The workable alternative is to take the other group's source of truth read-only and bind corrections to it by reference rather than by edit - an annotation layer, authored by the group that has the field knowledge, available to the source owner, and explicitly accepting that the two systems will sometimes give different answers. That acceptance is the hard part, and it is a governance decision, not a technical one.

What "scaling" actually demands

Capture is the easy verb. Scaling captured tribal knowledge is four separate problems, and the tooling in this category solves roughly one of them:

• Distribution to the point of need. A captured session is worthless unless it surfaces at the moment a different technician is standing in front of a similar fault. That is a retrieval problem, and - because the query is visual and the target is visual - it is a visual retrieval problem. Text-parsed indexes cannot do it. This is the practical case for class D Visual document retrieval.
• Adjudication when it conflicts. Scaled tribal knowledge will contradict the manual, and will contradict itself, because two technicians resolved the same symptom differently and both were right. The Adjudication Layer is entirely about this. Nothing in the current toolchain addresses it.
• Decay and maintenance. A war story about a 2019 build is wrong for a 2025 build and nothing tells you when it stopped being true. Captured knowledge has a half-life that authored documentation does not, because nobody owns its revision. An annotation layer without an expiry model becomes a second source of confidently wrong answers within about two years.
• Provenance and trust. Technicians accept a war story because they know who it came from. Strip the attribution in the name of clean knowledge articles and you remove the mechanism by which the knowledge was validated in the first place. The trust literature is unambiguous here: workers' confidence in company-provided AI is volatile and attribution is one of the few things that stabilizes it.

Only the first of these is a technology purchase. The other three are governance, and they are, in my view, the reason class E session-to-record has no published outcomes - not because nobody has captured anything, but because captured knowledge that isn't distributed, adjudicated, maintained and attributed produces no measurable effect to publish.

The retrieval consequence

If the annotation layer is visual, retrieval has to be visual too - and this is where the VisRAG result stops being an academic curiosity. Text-parsed pipelines discard exactly the content that carries diagnostic meaning in service documentation: the exploded view, the callout number, the flowchart branch, the photo of the correct assembly. Embedding the page image directly recovers 20-40% of end-to-end performance. A technician's photograph of a real assembly and the manual's figure of the intended assembly are, for the first time, comparable objects in the same index.

You do not need a thousand words to find the image that gets you to solution.

There is a moment in every guided-diagnosis system that the literature almost never addresses directly: the technician is holding two sources that disagree. The manual says one thing. The service note says another. The photograph in front of them matches neither. Someone has to choose.

Technicians adjudicate constantly, without naming it. Manuals are written cheaply and to a "good enough" standard on purpose, and the human absorbs the disconnect - that absorption is invisible labour that no system currently accounts for. Adding a camera does not remove the conflict; it adds a third, highly credible source to it. A photograph is evidence, and evidence that contradicts documentation is a governance event, not a retrieval result.

Two design commitments follow, and both cut against how these systems are currently built:

• Do not resolve; contextualize. Rather than picking a winner between contradictory claims, build enough context around each claim that both can be true within their own scope - this machine variant, this climate, this duty cycle, this build date. Validity is a property of a claim under a perspective, not of the claim alone.
• Expect the discriminating variable to be discovered, not known. The feature that explains why two contradictory service notes are both correct is usually not in the schema when you start. It has to come out of the data. Systems designed around a fixed set of known discriminators will keep resolving conflicts wrongly and confidently.

The human-factors literature explains why confident wrongness is the specific risk. Reviews of automation bias in human-AI collaboration find that people under time pressure accept plausible machine output at rates well above its accuracy - and the trust data is not stable in the other direction either: Deloitte's index, reported in HBR, found trust in company-provided generative AI fell 31% between May and July 2025, and trust in autonomous systems fell 89% over the same window. Neither over-reliance nor collapse of confidence is a good operating state, and both are produced by the same thing: a system that cannot say why it thinks what it thinks.

The expertise curve does not flatten the way the pitch says it does. Two 2025 field experiments bound this precisely. In the P&G study, 776 professionals working with AI dissolved functional silos - R&D and Commercial staff produced comparably balanced solutions, and AI-equipped individuals matched the output of human pairs working without it. But the IG Group experiment found a hard limit: across 78 workers grouped by expertise distance, AI equalized conceptualization quality (4.05-4.18 out of 5 across all groups) while leaving a 13% execution-quality gap between occupational insiders and distant outsiders. AI provides the map; navigating the terrain is still domain knowledge. For a service organization staring at a technician shortage, that is the difference between compressing time-to-proficiency and eliminating the requirement for proficiency. Only the first is on offer.

Instrument class E before you need to defend it. Nobody has published a measured outcome for session-to-record capture. If you deploy it without a baseline - knowledge article production rate, mean time to first correct article after a new failure mode appears, proportion of resolutions traceable to a captured session - you will be unable to distinguish a working system from an expensive video archive two years from now.

Bound the answer space deliberately. The Lukens finding is the practical one: the same corpus and the same models produced 77-94% hallucination on the open task and 86% accuracy on the constrained one. Constraining the output to an enumerated set you control is not a limitation of the deployment; it is the deployment.

Budget as BCG frames it, not as the vendor does. 70% people and process, 30% technology. The technology in this category is now the cheap part, and the organizations that fail will fail on the write-access question, the adjudication question, and the technician-trust question - none of which appear on a platform comparison matrix.

Treat retirement-driven knowledge loss as the wrong frame. Only 28% of departing field service engineers are retiring; the rest leave for burnout, unclear paths, and disengagement, and 52% of a technician's time already goes to paperwork and searching for information. Knowledge is not walking out slowly at 65. It is churning out continuously at every age, and the capture mechanism has to survive that turnover rate - which means it cannot depend on anyone volunteering to write documentation.