Here's a scenario that's more common than anyone likes to admit.
A software product grows over several years. For most of that time, two people ran it: one developer who built it, and one operations person who directed what got built. No formal documentation. No knowledge base. Just two people and their shared mental model of how everything worked.
Then the company grew. A full development team came on board. And suddenly, the absence of documentation — which was never really a problem when two people were talking every day — became a crisis. The knowledge wasn't gone. It had never been written down in the first place.
This is the knowledge archaeology problem. And it's not a niche edge case. It's the default state of most growing organizations.
What knowledge archaeology actually means
Archaeology is the study of human history through the recovery and analysis of physical remains. You're not creating history — you're finding it, piecing it together, reconciling contradictions, and making it legible.
That's exactly what most organizations need to do with their knowledge before they can even think about building a proper documentation system.
The knowledge exists. It's in Slack threads, in recorded meetings, in developer notes scattered across Notion pages and Google Docs and sticky notes and email chains. It's in the heads of people who've been there since the beginning. It's in the decisions that were made but never explained, the processes that evolved but were never written down, the institutional memory that lives nowhere anyone can find it.
A documentation initiative that starts by asking people to write things down from scratch is solving the wrong problem. The better starting question is: what do we already have, and how do we surface it?
"This software kind of just ran out of control and got larger and larger. There wasn't appropriate documentation to begin with for how things were meant to work. It was just housed within the two of their skulls."
The signs you have a knowledge archaeology problem
It's not always as dramatic as a two-person company scaling into a dev team. The archaeology problem shows up in subtler ways too:
- New hires take months to become productive because onboarding is essentially an oral tradition passed down by whoever has time.
- The same questions get asked over and over, answered differently each time depending on who's available.
- Different teams have conflicting versions of how a process works, and nobody knows which is current.
- When a senior person leaves, a significant portion of operational knowledge walks out the door with them.
- You have documentation, but it's out of date, nobody trusts it, and nobody updates it.
- You have hours of recorded meetings where important decisions were made — but nobody has time to watch them.
If any of these sound familiar, you don't have a documentation gap. You have a knowledge excavation backlog.
Why the traditional approach fails
The standard response to a documentation problem is to assign someone to write documentation. A technical writer gets hired. A documentation sprint gets scheduled. A knowledge base platform gets purchased. People are told to start contributing.
It almost never works.
The reason is simple: writing documentation from scratch is enormously time-consuming, and the people who have the knowledge to write it are also the people with the least available time. The developer who understands how the system works is also the person responsible for keeping it running. They will always prioritize the latter.
So the documentation never gets written. Or it gets written once, goes out of date immediately, and becomes less trustworthy than asking a colleague directly. The knowledge base becomes a graveyard of stale articles that nobody reads.
"The knowledge isn't missing. It just hasn't been extracted yet."
A different starting point: extract, then organize
The archaeological approach flips the process. Instead of asking people to create knowledge from nothing, you start by extracting knowledge from what already exists.
That recorded team meeting where the architecture decision was made? Process it. Extract the key decisions, the reasoning, the open questions. Turn seventeen hours of video calls into structured knowledge assets in a fraction of the time it would take to watch them.
Those developer notes scattered across different tools? Ingest them. Let an AI agent read across all of them, find the common themes, identify where they agree and where they contradict each other.
Those vendor manuals and product specifications sitting in a folder nobody looks at? OCR them into the knowledge base. Make them queryable. Cross-reference them with what's on the web to find gaps and outdated procedures.
The goal of phase one isn't a polished knowledge base. It's a rough, complete one — everything in, organized enough to work with, queryable enough to find contradictions.
The three phases of knowledge archaeology
- Phase 1: Extract — Get everything in. Videos, documents, notes, recordings. Raw and unpolished is fine.
- Phase 2: Reconcile — Find duplicates, contradictions, and gaps. Surface what's missing and what conflicts.
- Phase 3: Standardize — Build SOPs from the reconciled knowledge. Now you're writing from evidence, not memory.
The deduplication and contradiction problem
Once you start pulling scattered knowledge together, you immediately hit the next problem: the same thing is documented in three places, described differently each time, and you have no idea which version is correct.
This is actually progress. You've moved from "knowledge doesn't exist" to "knowledge exists but is inconsistent." That's a solvable problem.
An AI agent working across your full knowledge base can do things that would take a human team weeks to do manually. It can read across all your developer notes and find every place a particular workflow is described. It can surface the similarities and differences between those descriptions. It can flag where two documents directly contradict each other and ask you to resolve the conflict. It can build a comparison matrix showing what each source says about the same topic.
What used to be a documentation project — slow, expensive, dependent on the availability of people who'd rather be doing something else — becomes an excavation and reconciliation project. The AI does the heavy lifting of finding and comparing. The humans make the judgment calls about which version is right.
Deduplication as a forcing function
There's a useful side effect of this process that often goes unappreciated: finding contradictions forces decisions that were previously avoided.
When two documents describe a process differently, it's rarely because someone made a mistake. It's usually because the process actually changed at some point, or because two teams developed different approaches independently, or because what was intended and what was implemented diverged. The documentation contradiction is a symptom of an organizational ambiguity.
Surfacing it forces a conversation: which version is correct? What should the standard actually be? Who has the authority to decide?
These are conversations that needed to happen anyway. The knowledge archaeology process creates the context to have them efficiently, with the relevant information in front of you rather than scattered across tools and people's memories.
What comes after the dig
Once you've excavated and reconciled, you have something you didn't have before: a trustworthy knowledge base. Not polished, not comprehensive, but accurate and queryable. That's the foundation for everything else.
From there, you can start assigning courses to new hires. You can publish scoped portals for different teams. You can build certification processes that verify people actually understand how things work, not just that they sat through a training. You can maintain the knowledge base as a living thing, updating it as processes change rather than letting it go stale.
But none of that works if the foundation isn't trustworthy. And the foundation doesn't become trustworthy by asking busy people to write things down from scratch. It becomes trustworthy by methodically surfacing, reconciling, and standardizing what the organization already knows.
The practical starting point
If you're sitting on a backlog of recorded meetings, scattered documents, and institutional knowledge that lives in people's heads, here's the most useful thing you can do right now: stop thinking about documentation as a writing project and start thinking about it as a recovery project.
Take the recordings. Process them. Get the content into a system where an AI can read across all of it and start finding patterns, duplicates, and gaps. Let the machine do the first pass of reconciliation. Then put the humans in the role they're actually good at: making judgment calls, resolving ambiguities, and signing off on the standard.
You have more knowledge than you think. You just haven't dug it up yet.
Docsie can process your video recordings, ingest your scattered documents, and use AI to surface duplicates, contradictions, and gaps across your entire knowledge base. Start free at app.docsie.io — or talk to us about a guided pilot if you're working against a deadline.