On a Sunday afternoon in March 1977, Los Rodeos Airport on the Spanish island of Tenerife was not supposed to be busy. Instead, a bomb went off at the main airport on nearby Gran Canaria, and dozens of flights were diverted to this small field. Parked jets soon blocked the only taxiway, so departing aircraft had to taxi down the runway itself to reach the far end. Patches of thick fog drifted across the airfield. The pilots could see little, and the control tower could see almost nothing.
Two Boeing 747s ended up on that runway at the same time, one KLM and one Pan Am. The KLM jet had reached the far end and turned around, ready to depart. The Pan Am jet was still taxiing on the runway behind it in the fog, working its way toward an exit. The Pan Am crew had radioed that they would "report when clear of the runway." The KLM captain, believing he had been cleared for takeoff and that the runway was clear, pushed the throttles forward.
At 5:06 that afternoon, the accelerating KLM jet struck the right side of the Pan Am aircraft. All 248 people aboard the KLM plane were killed. On the Pan Am jet, 335 of the 396 aboard died; every one of the 61 survivors had been seated in the front of the aircraft. In all, 583 people lost their lives. It remains the deadliest accident in aviation history.
The Tenerife Airport disaster
Nothing failed mechanically. Spanish investigators concluded that the primary cause was the KLM captain's decision to take off believing he had clearance. Dutch investigators put more weight on a mutual misunderstanding in the radio exchanges between the KLM crew and the tower. Either way, the disaster came down to messages: words that meant one thing to the people sending them and another to the people receiving them, in conditions where no one could look out the window to check.
Accidents like that one changed how the aviation industry trains people. The lesson wasn't that pilots needed to be smarter. It was that the way information reaches a person matters as much as the information itself. A message that's clear on a quiet afternoon can be missed, misread, or tuned out under pressure. So you design the message for the moment it will be received.
Some of the changes were small and telling. After Tenerife, the word "takeoff" was reserved for one moment only: when clearance is actually given. Before that, crews and controllers say "departure." Readbacks became stricter, and the accident became a founding case for Crew Resource Management. Part of aviation's answer to a catastrophe of misunderstanding was to give one word exactly one meaning.
At BrightHelm, that lesson is woven into how we build Knowledge. It's why our Salesforce Knowledge base was ready for AI before we knew it needed to be. And it's why we think the most useful way to understand AI readiness is a simple idea: an AI is just a new kind of reader.
Two High-Stakes Environments, One Discipline
BrightHelm is led by two veterans who learned their trade in places where a misread message had consequences. Before I became BrightHelm’s founder, I was a Naval Aircrewman, and our Head of Delivery, Trent Whalon, was a Submariner.
A cockpit and a submarine conn don't look much alike, but they ask the same thing of the people inside them: technical precision and sound judgment under pressure, when the information you need is coming at you fast and incomplete. Both disciplines have spent decades refining how information should move between people, and both arrived at the same principles. The field is called human factors: people take in information in a context, so the message has to be shaped for that context.
Once you know the principle, you see its expressions everywhere:
Checklists, so a critical sequence never depends on memory.
BLUF, "bottom line up front," so the point sits where a busy reader looks first.
Crew Resource Management in aviation, with set phrasing and readbacks, so a message survives noise, stress and rank.
Repeat-backs on submarines, every order is repeated back word for word, and nothing happens until the officer confirms it was heard correctly.
Fixed report formats, so a tactical report from sonar arrives with the same information in the same order every time, without conversational filler, and the receiving team can act on it instantly.
None of this is red tape. The people who designed these practices knew exactly where human attention fails, and built around it. The structure is what frees the crew to think about the hard part.
AI is just a new kind of reader
Aviation has another story worth knowing. In December 1972, Eastern Air Lines Flight 401 was on approach to Miami when a landing gear indicator light failed to come on. Three experienced aviators focused on the burned-out bulb while the airplane, its autopilot unintentionally disengaged, descended into the Everglades. Nobody was watching the altitude. Tenerife was a failure of the message; Flight 401 was a failure of attention. Both have AI equivalents.
When AI tools started reading our Knowledge base, we noticed something. Their failures looked familiar. Each limit we ran into rhymed with a human limit that human factors had already solved.
| What trips up an AI | The human version | How human factors fixes it | How a knowledge base fixes it |
|---|---|---|---|
| Missing context. It fills the gap with something plausible and says it with confidence. | Misreading an ambiguous message under stress | Set phrasing and readbacks, so nothing is left to interpretation | Record types and deliberate fields that say what a thing is, so the model doesn't have to infer it |
| A wall of text. The relevant passage gets split up or diluted when it's retrieved. | Overload: the critical item buried in noise | BLUF and checklists put the point where you look first | Structure the model can navigate straight to the part it needs |
| Tunnel vision. It sees only what the search returned, and nothing in the next record over. | Fixating on one problem while a bigger one closes in | Situational awareness: scan patterns, callouts, crew cross-checks | Links between related articles, a clear signal when one replaces another, and honest dates |
That third row is Flight 401. An AI that finds last year's policy and answers confidently, unaware that last month's update replaced it, is staring at the bulb. A "replaces" link and an honest date are the callouts that break the fixation.
The lesson for anyone building with AI is that you don't need a new discipline. You need an old one, pointed at a new reader.
Our Knowledge Base Speaks Navy
The clearest example of all this at BrightHelm is how our Knowledge base is organized. Every article looks up to a parent "Map" record; this is the ontology we use to structure everything, not just Knowledge. The Maps are numbered on a system borrowed from Navy staff codes and instruction numbering. Anyone who has served on a Navy staff knows N1 is personnel and N7 is training without looking it up. The number explains itself before you read a word, and that's exactly the point.
| Navy staff code | What it means in the Navy | Our map | What lives there |
|---|---|---|---|
| N1 | Personnel | 001 | Company culture, crew, and core positions |
| N3 | Operations | 003 | Project management |
| N4 | Logistics | 004 | Marketing |
| N5 | Plans | 005 | Sales |
| N6 | Communications and information systems | 006 | Delivery |
| N7 | Training | 007 | Training |
Some of those mappings are exact. Some are ours. In the Navy, N4 handles fuel and fungibles; at BrightHelm, it handles blog posts; both drive our progress. N5 writes plans, and nothing is more forward looking than Sales. N6 is communications and information systems, and for a Salesforce firm, that's our Delivery.
The humor is part of the design. A system people enjoy is a system people keep using, and keeping it up is the whole game.
The result is that every article tells a reader three things before they open it: the label of the map it belongs to, its position in a numbering scheme that carries meaning, and the sibling articles around it. That's situational awareness, built into the data. A new teammate gets oriented fast.
Turns out... So does an AI.
We Stumbled into this Backwards
We'd love to say we planned all of this for AI. We didn't. We built our Knowledge Base, our Slack channels and our Salesforce org for people, the way we'd been trained to build anything that someone else would rely on later.
Then we turned on Slackbot, and it worked better than we had any right to expect. Our team asks it what we've said about a topic and gets a real answer. We turn procedure articles into action steps and checklist articles into tasks. That last one is a straight line from the cockpit: a checklist written for a person under pressure turned out to be exactly what an AI needed to act on.
We'd seen the same thing in Slack. Our five-person firm keeps a lot of channels, each with one clear purpose, and we used to joke about it. As we wrote in Slackbot Rocks Part 1, that discipline looked a little obsessive before Slackbot. Afterward, it looked like foresight. Your channel model is Slackbot's map of your business, and ours was already drawn.
None of it was preparation for AI. It was preparation for clarity. AI just happened to reward it.
What This Means for the Organizations We Serve
You don't need to have flown in a cockpit or served on a boat to use any of this. The principles travel: shape your knowledge for whoever will receive it, at the moment they'll receive it. More and more, that reader is an AI. And how well you've shaped your knowledge is one of the biggest factors in whether your agents give good answers. Models keep getting better on their own. Your knowledge is the part you control.
The plumbing does differ depending on which AI is doing the reading. Slackbot searches your Salesforce live, as the person asking. An Agentforce agent answering your clients needs a grounding source you've prepared on purpose and scoped to its audience. We walked through those differences in Searchable Isn't Ready for Your Agent. Slackbot Disagrees. Both are Right. But the philosophy holds either way: an AI can only be as clear as what it reads.
These are the habits we bring to every engagement, and the ones any team can start on Monday:
Every field gets one meaning, so neither a new hire nor a model has to guess which one you meant.
Every piece of knowledge gets a place, in a structure that tells a reader where they are before they start reading.
Every article knows its neighbors, including the one that replaced it.
The bottom line goes up front, in the summary, where both people and retrieval systems look first.
None of these are new. They're the same habits that keep crews safe, applied to the knowledge that keeps a mission-driven organization running. What's new is how much they pay off. An organization that has done this work for its people is closer to AI-ready than it thinks. One that hasn't will find out quickly, because AI reflects back whatever it's given.
Why Salesforce Knowledge, and Why Knowledge Plus Slackbot
Salesforce Knowledge was built for exactly this kind of discipline. Article types, data categories, and a publication workflow give you structure, ownership, and an honest answer to "is this current?" without building anything custom. The parts some admins call clunky are the scaffolding an AI needs. We know, because we called it clunky once ourselves.
Pair well-designed Knowledge with Slackbot and you get a one-two punch. Your Knowledge is ready-grounded the moment it's published. Slackbot can find it, reason over it, and act on it for your team, with no separate retrieval system to build first. And when you're ready for an agent that serves your clients, the same articles become the foundation it grounds on.
The economics work in your favor, too. With unmetered Slackbot on Slack's Enterprise+ plan, your cost sits in the people who write and maintain your knowledge, not in credits spent every time an AI reads it. You invest in the knowledge, and every question your team asks draws on that investment.
It's easy to assume structure slows you down. In a cockpit or a control room, it does the opposite. A checklist means a pilot doesn't spend attention remembering the routine, so that attention is free for the thing nobody planned for. A repeat-back means an officer doesn't spend a second wondering whether the order was heard right, so the next decision comes faster. The structure isn't the work. It's what clears the deck for the work that matters.
The same is true for us. Because our Knowledge base has a place for everything, a new teammate can get oriented without a guided tour. Slackbot can turn a checklist into tasks in seconds instead of someone retyping it. And when a client brings us a genuinely hard problem, we spend our time on that problem, not on hunting for what we already know. The structure handles the routine, so the people, and now the AI, can spend their attention on the hard part.
Our discipline sets us free. It's how a five-person firm moves like a much bigger one, and it's what we bring to every organization we work with.
Want us to design this for you too? Let's talk.
