A consulting firm builds your team a knowledge base. A SaaS platform holds your process docs, your decision history, your prompt library. Eighteen months later the contract ends, the vendor changes pricing, or the tool gets acquired and folded into something else. What's left is whatever your people remember, plus an export button that produces a folder of files nobody can read without the vendor's own tool open next to it.
That's the same failure as "when she left, we lost everything she knew," except this time the "she" is a company instead of a person, and the loss was contractual instead of accidental.
Where the Knowledge Actually Lives
A wiki that only renders inside its own app. A prompt library that only runs inside its own chat window. A decision log buried in a project-management tool's proprietary fields. Most organizations don't ask where their operational knowledge actually lives until they need to move it, and by then the answer is usually one of these. None of these tools are wrong to use. They're wrong to depend on as the only place the knowledge exists, because using a tool and owning what's inside it are different things, and the difference only shows up when you try to leave.
Version control solves a narrower problem than people expect. It isn't really about code or developers. A git repository is a plain-text, fully exportable record with three properties almost nothing else offers by default: every change is attributed to someone, every prior state is recoverable, and the whole thing can be cloned and read by a person or an agent without asking the tool that produced it for permission first. Put an organization's decisions, terminology, and the relationships between them into that format, and the knowledge stops being trapped inside any one vendor's product.
The Test That Actually Matters
If the vendor disappeared tomorrow, would your organization still have its own operational knowledge, in a format it could open without that vendor's software running? For a repository the organization actually controls, the answer is yes, because reading a git history has never required the tool that wrote it.
The same test applies to anyone else lending a hand: a consultant, an agency, a platform vendor. If reaching your own decision history ever depends on their continued cooperation, whatever access they were given was never really temporary, and the ownership was never fully yours to begin with. The right shape runs the other way: outside help gets collaborator access for as long as the work lasts, revoked the moment it ends, and everything produced stays behind in a repository the organization already controlled before anyone else showed up.
Call this being git-first: keeping the record of how the organization actually works, its decisions and the reasoning behind them, in a place the organization owns outright, under version control, portable by default. Git isn't the only substrate that could technically do this. It's the clearest one available right now, because persistence, attribution, and the ability for a person or an agent to read the history without a middleman are exactly what version control was built to guarantee.
What This Changes in Practice
A git-first organization can answer a question a documentation-first one usually can't: not just what was decided, but who decided it, when, and what's changed since. That answer stays reachable whether or not the consultant who helped write it down is still on retainer, and whether or not any particular tool is still being sold, because the knowledge never depended on either one to exist.
Read more about how this shows up in engagement structure → How We Work