When your best analyst quits, how much of your business logic walks out with them?
.webp)
A senior analyst resigns on a Tuesday.
The team spends the analyst’s final fortnight in a panic of screen shares and hurried Loom videos, trying to extract a decade of judgment into a Confluence page. The page is long and everyone feels relieved after documenting all that tribal knowledge.
And yet, three weeks later, the CFO asks why the margin number moved, nobody can answer the question.
The Confluence page documents where the tables live and who owns them. It doesn’t explain why the west region excludes trial accounts, or which of the five revenue tables the analyst used for their numbers.
Tribal knowledge is what your query logs cannot tell you
Every enterprise runs on business logic nobody wrote down: which revenue table is real, why Q3 2021 is excluded from the trend, or what "active" means in the west region. That logic, or tribal knowledge, lives in the heads of three or four analysts, and it leaves when they do.
Revisiting the opening example, the CFO's revenue number comes from one of five tables named revenue, revenue_v2, revenue_final, fct_revenue, and revenue_corrected. The analyst who left knew which one. The other four look equally plausible to anyone else.
Tribal knowledge also comes in handy with conflicting definitions for the same term. “Active" in the west region excludes trial accounts, because west ran a free-trial program the other regions never launched. Same word, different meaning, one dashboard.
Then there are the decisions that leave no trace in the schema at all. Three customer IDs were collapsed into one after the 2019 acquisition, and every churn and retention number your board sees depends on that merge. It doesn’t appear in any data dictionary or column description.
Some tribal knowledge exists purely to keep a trend honest. Q3 2021 is dropped from the growth chart because a billing migration double-counted invoices for six weeks. Leave the quarter in and the board sees a spike that never happened.
All of those decisions are already sitting in your query logs, but what the logs never record is the why. It tells you what ran, when, and by whom. It cannot tell you that the date range was hardcoded after an audit finding, or that your analyst tried the obvious join first and learned the hard way that it double-counts.
That gap between what ran and why it ran is tribal knowledge. It is reasoning, built up over a decade of being wrong once and never being wrong that way again. Calling it documentation undersells it.
Why documentation projects alone won’t close the gap
Documentation projects, catalogs, wikis, and other static efforts don’t fix this problem. Writing it down is not the hard part. Keeping it true is.
A definition written in March describes a pipeline that changed in June. Your human analyst knows this, but the company wiki doesn’t document it. Instead, it keeps confidently describing a world that no longer exists.
Anthropic's data team ran into this problem and solved it structurally rather than with discipline. They collocate documentation files in the same repository as their transformation models, so a pull request that changes a data model also updates the meaning of that model. Anthropic calls it “treating skill maintenance as a first class citizen.” A code-review hook flags any reporting-model change that doesn't touch a skill file.
That’s the fix: capturing logic, i.e., tribal knowledge, as a byproduct of the work itself.
However, most enterprises aren’t Anthropic. Your reporting logic is not in one repo with enforced review. It is spread across twenty years of stored procedures, a legacy estate nobody wants to touch, three BI tools, and a Snowflake migration that is 60% done. There is no single pull request that you can attach to for the truth.
Which is usually the moment someone points out that you already bought a catalog for exactly this. Catalogs are useful, and most large estates need one, but they inherit the wiki's decay problem.
Why catalogs go stale
Catalogs started as a technical index, with no opinions on meaning. Governance catalogs arrived to fill that gap. Collibra spun out of a semantic technology lab in 2008, while Alation launched in 2012 to address the question: how do you connect the people with questions to the data that has the answers?
Both categories are useful. Neither one captures reasoning, and we have written about what you are actually buying when you buy a catalog.
Why? Structure. A catalog captures what a human typed into a form field, on the day someone made them do it. Tribal knowledge doesn’t live in form fields.
A catalog can tell you that revenue_final exists, that Jane owns it, and that it carries a certified badge. It cannot tell you that the CFO's number excludes intercompany transfers because of a 2022 audit finding. That sentence lived in a Slack thread, and then in Jane’s head, and now it walked out the door when Jane left.
The second problem with catalogs is decay. The certified badge was applied in 2023. The upstream model changed twice since. The badge is still there, glowing green, describing a table with a stale definition.
Logic is recoverable as people leave evidence
Ten years of query logs, dbt models, GitHub history, and BI definitions are a continuous record of what people actually measured.
WALT reads them from formats humans don’t read: query plans, abstract syntax trees, model DAGs, and lineage graphs. WALT’s crew of autonomous data engineers reconstruct the tribal knowledge, business formulas, and dependencies that don’t exist in any document.
How autonomous data engineers capture reasoning
WALT builds the Data Context Graph from the work itself, expresses every definition in human-readable YAML, versions each change, and re-evaluates nightly against new questions. A human steward is in-charge of all sign-offs. Business definitions, exceptions, and strategy stay with your people. WALT does the grunt work of harvesting, mapping, and syncing.
WALT's Reasoner builds and maintains the dashboards, and it carries the tribal knowledge with them: the filters, the exclusions, and the recorded reason we drop Q2 returns.
This doesn't require you to buy a new stack. WALT runs on the Snowflake, dbt, Tableau, and catalog you already own, and everything it builds stays in your infrastructure. Fire us like you would fire a systems integrator, and the graph is still yours.
Bottom line: Your data teams still decide what the business means. What changes is that their judgment, i.e., tribal knowledge, stops being stored in a single human memory with a two week notice period. It starts living in a graph that gets read, versioned, and challenged every day.
Three questions to ask your team this week
Pick your most important metric. Ask three people separately, “which table does our most important metric come from?” If you get three different answers, the logic is already fragmented, and the next resignation will decide which version survives.
Next question: “what breaks if this specific person leaves next month?” Name the person out loud. If the honest answer is "we would figure it out," ask how long, and multiply by your team's fully loaded cost.
And lastly, ask “where is that written down, and when was it last true?” Then look for the documentation, and compare its last edit date to the last schema change in the models it describes. The gap between those two dates is your exposure.
None of this needs a steering committee or a vendor. It takes an afternoon, and it tells you how much of your business logic is currently stored in people’s heads instead of in systems.
You cannot stop good team members from leaving. Good people get promoted, poached, and burnt out, and that will not change. You can stop your business logic from leaving with them. See how WALT works, or book a demo and bring the one metric your executives argue about most.
Sources
How Anthropic enables self-service data analytics with Claude | Anthropic
Meet WALT, your next Data Engineer that builds and runs your entire data platform
.webp)
.webp)