Case study / 23 Jun 2026

How I would build a knowledge base for an energy field-service team

I have not worked a field-service roster. It is the industry I find myself most drawn to, because it is real atoms work, often in remote places, where getting the knowledge right is not a convenience but a safety matter. Here is how I would approach a knowledge base for a team that maintains energy assets in the field, using the same method I described for a company and a freight desk.

This one I would build with more care than most, because the cost of a confident wrong answer is not a refund. It is a person on a site.

Where the knowledge hides

A field-service team keeps the lights on by knowing things that are written down almost nowhere.

The history of a specific asset. What has failed on it before, what was replaced, what the recurring fault is.
The quirks of a site. How you get access, what the isolation procedure is, the gate code, the dog, the cell signal that drops in the switch room.
The fault patterns. The way this model of pump fails in coastal humidity, the seal that always goes first.
The procedure that keeps a person safe doing a particular job, and the one near-miss that taught everyone why.

Most of this lives in the experienced technician's memory and in a filing cabinet of inspection sheets nobody can search. When that technician retires, decades of hard-won pattern recognition leaves with them, and the team relearns it the expensive way.

The raw pile

The material exists. It is just trapped in forms a machine cannot read and a human cannot search.

Work orders and job histories, one per asset, going back years.
Inspection reports and condition assessments, often scanned PDFs or photos of paper.
Equipment manuals and manufacturer service bulletins.
Incident and near-miss reports, where the real safety lessons are buried.
Photos from site. A surprising amount of field knowledge is visual, and modern models can read an image.

The first job is the unglamorous one. Get all of it into one folder, including the scans and the photos, so there is something solid to compile.

What the model compiles from it

Have a model compile that pile and the wiki organises itself the way a good supervisor's mind already does.

An article per asset. Its full service history, its recurring faults, the parts it eats, drawn from every work order that ever touched it.
An article per site. Access, isolation, hazards, the local quirks, linked to every asset on it.
An article per asset class. The failure patterns this model shows across the whole fleet, not just one unit.
A procedures layer. The safe method for each common job, linked to the incidents that justify each step.

Each article is built from the real job history and the manuals, and linked back to the source so a technician can check the original. The point is that a tech heading to a remote site can read everything the team knows about it before they leave the depot, instead of arriving and finding out.

The questions it can answer, and the gaps it can find

With the wiki compiled, the team can ask the questions that used to need the one supervisor who remembers every site.

"What is the failure history of this asset class on coastal sites, and what should I bring."
"What do I need to know before I attend this site for the first time."
"Has this exact fault been seen before, and what fixed it last time."
"What does the safe procedure for this job actually say, and why is that step there."

The linting pass matters even more here than in freight. A model reading the whole base can flag the assets with suspicious gaps in their service record, the inspections that are overdue, and the sites where the access information contradicts itself. Missing safety data is not a tidiness problem. It is a risk, and surfacing it is genuinely useful.

Prompt you can use

I run a field-service team that maintains energy assets across many sites, and most of what we know lives in technicians' heads and old inspection paperwork. Help me plan a knowledge base a model can compile and maintain.

Go one step at a time:
1. Ask me what records we hold: work orders, inspection reports, manuals, incident and near-miss reports, site photos, anything else.
2. Propose how to organise the compiled wiki: per asset, per site, per asset class, plus a procedures layer. Adjust it to how we work.
3. For one asset class I name, show me what its article would contain and which sources it would draw on.
4. List the field questions this base should answer before a technician leaves the depot.
5. Be strict about safety: tell me which outputs must stay advisory only, and which decisions must always remain a human sign-off.

Start by asking me what we maintain and where our knowledge actually lives today.

The rule

In field service the knowledge is not an efficiency. It is part of how people stay safe and how assets stay reliable, and most of it lives in heads that will eventually retire.

Get the histories, the manuals and the incidents into one pile. Let a model compile it into the assets, sites and procedures the team already thinks in. Keep every safety decision firmly with a person. Build this one slowly, and build it read-only first.