What is tribal knowledge, and how do you capture it?

Every floor has one. The operator who can tell a bearing is going by the pitch of the line. The technician who gets called in when the robot is down with a safety error code that shouldn’t exit. None of it is in the manual, all of it keeps the operation running, and all of it has a single point of failure: the person. When they retire, the knowledge goes with them, and the first anyone learns of the gap is a scrap bin, a return visit, or a line that will not restart.

• The sequence: the drawing says tighten in numbered order, but on this fixture the jig flexes, so the veteran seats two fasteners first. Their parts come out flat every time, and nobody knows why.
• The tell: the sound a compressor makes a week before it trips, the smell of a motor running warm, the vibration in a handrail that means a pump is cavitating. Diagnosis through the senses, not the gauges.
• The workaround: what to do when the sensor drifts, the supplier’s batch runs slightly oversize, or the controller throws the error the vendor says is impossible.
• The map: which isolator actually feeds the panel, where the shutoff is on site fourteen, which access road floods. Field knowledge that lives in one truck’s cab.
• The reason: why step six exists at all. Usually a defect years ago that nobody wrote down, so the step looks optional to anyone who was not there.

The three terms get used interchangeably and mean different things. Tacit knowledge is the broad idea: what a person knows but cannot easily put into words, the way anyone who rides a bicycle knows how to balance and almost nobody can explain how. Institutional knowledge is everything an organisation knows collectively, written or not: its history, its customers, its procedures. Tribal knowledge is the operational slice where the two meet: know-how that matters to the work, is undocumented, is held by a few people, and spreads only by proximity. Some organisations prefer to call it institutional or undocumented knowledge. The label matters far less than the fact that it is about to walk out the door.

Most operations have tried. The methods are familiar, and they fail for the same reason: they ask the expert to produce the knowledge somewhere other than the work that produces it.

• The exit interview: by the time it is scheduled the person is halfway out the door, and an hour in a meeting room cannot hold thirty years on the floor.
• The write-up: asking an expert to document everything they know produces a document about what they think they do. Work as described and work as done are rarely the same, and the expert is the last to see the gap: the shortcuts stopped feeling like shortcuts long ago.
• The binder: whatever does get written down is filed, laminated, and out of date by the next engineering change. The floor stops trusting it and goes back to asking the person.
• Shadowing: pairing a veteran with a new hire works, and it is how the veteran learned. It also transfers to one person at a time, takes years, and requires the veteran to still be there.

Tribal knowledge surfaces in exactly one place: while the work is being done. That is when the expert glances at the gauge nobody else checks, pauses before a step, or stops the apprentice a moment before the mistake lands. So the capture has to happen there, on a real unit, in the flow of a real shift. Three things make that practical.

• Record the demonstration, not the description. Video of the hands doing the work, with the expert narrating as they go, captures the sequence they actually follow and the asides they would never think to write down. The useful prompt is not how the job is done in general but what the expert is looking at right now.
• Pin every tip to its step. Know-how is only useful attached to the step, the asset, the variant, and the procedure revision it belongs to. A shared folder of loose tips is a second binder.
• Make it structured and keep it current. Captured knowledge should become part of the controlled procedure, reviewed and versioned like the rest, so it reaches the next person on the step where they need it instead of an archive nobody opens.

In the field the bar is higher. There is no desk, connectivity comes and goes, and hands are in gloves, so capture has to work by voice and by camera from the technician’s own point of view, at the cabinet or up the tower, not back in the truck an hour later when the detail has already blurred.

This is the job Visor Capture was built for. It records an expert by sight and by sound at once: the video of the hands doing the work, the narration as they explain it, and the sequence they actually follow, with nobody stopping to write anything down. The tips and tricks that never made it into a manual come with it, each pinned to its step with the video snippet that shows it, and the result is structured and versioned so the rest of the platform can deliver it, confirm it, and audit against it. Procedures can start from the manuals, specifications, and service bulletins you already hold, so what your experts add is layered on top of the approved standard, never instead of it.

Capture is half the job. Knowledge that sits in a repository is a better-organised binder, and the floor will treat it like one. It pays back when it reaches the next person at the moment they need it: read aloud on the step they are on through Visor Guide, each step confirmed from what the AI sees before the next unlocks, or as the answer when a technician asks by voice what that noise means and Visor Assist replies from the captured tip and the fix that worked last time, citing its source. Because the work is recorded as it happens through Visor Document, every job adds to the record the next revision is built from. The expert’s knowledge stops being a single point of failure and becomes the operation’s standard, still current after the expert has gone.