A few years ago I wrote a knowledge base for a call center. We were launching a statewide professional learning platform on Canvas, and the vendor’s support staff would be fielding questions about our setup alongside questions about dozens of other institutions running the same software. They needed to understand, quickly and without a training session, what made ours different: how accounts were structured, what the enrollment paths were, which questions to answer and which to route to us. So I wrote it down, plainly, with examples, organized the way someone would actually look for it.
Some time later I fed that same document to an AI tool as context and asked it questions about the platform. It answered them well, and not through any cleverness on the tool’s part. The document had already been written for a reader with no background who needed a correct answer fast, which turns out to be the same reader a language model is. Clear structure, examples from real situations, and plain language served the call center, and they served the model. What began as documentation for people became the most useful piece of AI context I have built.
That experience is the argument of this piece in short. AI tools know a great deal about the world and nothing about your organization. They cannot tell a new staff member how your enrollment process works, why a policy was written the way it was, or how you talk to districts. What helps is not a smarter model but a body of institutional knowledge organized well enough that both a person and a model can use it.
What makes a knowledge base AI-ready?
The phrase sounds more technical than it is. An AI-ready knowledge base is a structured collection of the things your organization actually knows: policies and procedures with real examples attached, communication guidelines, the context behind decisions, standard operating procedures, and the questions that come up repeatedly along with the answers that hold. What separates it from a folder of documents is that it was written to be found and understood by someone who does not already know where things are.
I want to be careful about one thing here. The knowledge base is the part that lasts, and the AI sitting on top of it is the part that will change. If the model changed tomorrow, or the subscription lapsed, the document would still be worth having, because it was worth having before any of this. That ordering matters for how much effort goes where.
How do you start?
The fastest way in is what I think of as the bucket approach: gather the five documents people reach for most (policies, templates, procedures, FAQs), combine them into a single file with a short description of your organization at the top, and hand that to whatever AI platform you have (ChatGPT Teams, Claude Projects, Gemini, Copilot). Unstructured material is fine at this stage: meeting notes, chat logs, project retrospectives. You are giving the tool your documentation as it exists, which produces useful results immediately and teaches you what is missing.
The bucket approach usually reveals its own limits within a few weeks. Answers are inconsistent because the source documents contradict each other. The model cannot tell which version of a policy is current. Someone asks a question the documents answer in three places, differently. That is the point at which it is worth restructuring, and the framework I use for that is BRAIN.
What is the BRAIN framework?
BRAIN is a design checklist for turning a pile of documents into a knowledge architecture. Each letter names something the documents need.
Basic structure means clear titles, consistent categories, and the same shape for every document of the same kind. A policy titled “Student Attendance, Elementary Schools, Version 2.1” tells a reader what it is, where it fits, and how current it is before they open it, and a model relies on those signals just as much. When every policy follows the same pattern (summary, procedure, examples, related documents), a reader learns where to look and a model learns what to expect.
Rich context means the why alongside the what. The board discussion that prompted a policy, the community concern behind it, the approach that was tried first and did not work: this is what lets a person or a model give guidance that acknowledges complexity instead of reciting a rule. Failure stories belong here. A knowledge base that only records what worked produces advice that does not survive contact with a real situation.
Accessible language means plain terms, defined jargon, and one vocabulary throughout. “Follow the intervention steps in the student’s Individual Education Plan” does the same work as “implement remediation protocols per IEP specifications” and will be understood by more of the people, and more of the models, that read it. The tone you write in is the tone the tool will answer in, so it is worth writing the way you want your organization to sound.
Indexed and tagged means the same procedure can be found by everyone who looks for it under a different name. Staff will search for a lockdown procedure as “lockdown,” “security emergency,” “safety protocol,” or “emergency response,” and a tagged document answers all four. Tags also let related material surface together, so a question about parent communication during an emergency pulls the safety protocol, the communication template, and the legal requirement in one pass.
Networked resources means documents point to each other. An emergency procedure that links to its communication template, the staff contact list, and the relevant state regulation is a system rather than a page. For a model, those links are context about how the pieces fit; for a person, they are the difference between finding an answer and finding the rest of what they needed to act on it.
Can a knowledge base replace training?
When I first wrote this piece I leaned on Karl Kapp’s prediction that organizational learning would move toward fewer courses and more AI coaching, with information delivered on demand at the moment of need. I still think a good knowledge base does some of that work well. Quick procedural answers, guidance in an unfamiliar situation, a step-by-step walk through a task someone does twice a year: these are better served by a well-organized reference than by a course nobody remembers.
I am less sure than I was that this adds up to a replacement for training, and I have written elsewhere about why I want much of what passes for EdTech training to die. The difference is that a knowledge base answers the question someone knows to ask. It does not build the judgment to know which question matters, and it does not create the shared understanding that comes from working through something with colleagues. Just-in-time reference and learning are different things, and the knowledge base is good at the first without being a substitute for the second. What it can do is take the reference load off of training, so that the time people spend together goes to the parts that need people.
Where does this live now?
The most direct version of this argument is a tool. The FAQ Chatbot runs on a sheet of your own questions and answers, matches on keywords first, and only escalates to a model when the keywords do not resolve. It is a knowledge base with a thin layer of AI on top, and it was built that way on purpose: the sheet is the part you own, and it keeps working when the layer above it changes.
If you have built something like this in your own district, or if you have found that the bucket approach was enough and never needed the restructuring, I would like to hear how it went. You can reach me at licht.education@gmail.com, and there are more tools, articles, and resources at bradylicht.com.
