Patterns § 06
The Vault proven in production
Your decision record lives in the repository — and you keep it when we leave.
Every engagement builds a vault: decisions, designs, requirements, and evidence as plain text in the same repository as the code they govern. One history, with git’s machinery behind it.
One history, not two
Most consultancies keep the thinking in one place and the code in another — decisions in slideware, rationale in email, the "why" evaporating the moment the people rotate. We keep the engagement’s record as plain text inside the code repository itself, so design history and the code it governs land in the same commits and review in the same pull requests.
That buys you git’s entire machinery for your institutional memory: every decision is versioned, diffable, attributable, and recoverable. And because it is plain text in your repository, it is yours — no export, no vendor, no goodbye-tax when the engagement ends.
The context doesn’t leave when we do.
The recovery that proved it
The receipt is a near-loss. On one engagement, an entire program’s history — 38 commits of decisions, production evidence, and closure records — turned out to live only on a stale local branch after a machine change. Because the vault is git, it was recoverable, diffable, and mergeable with per-file conflict resolution. Nothing was lost.
On a wiki or a shared drive, that history would simply have been gone — and nobody would have known what vanished, because there would have been no diff to read.
What we build from it
The vault is not an archive — it is what we build from. Every piece of work starts better-informed than the last because the last one wrote itself down, and the AI sessions that build for you ground on the same record you read. One source of truth, human- and machine-readable, compounding for as long as the engagement runs.
Software firms hand over code. We hand over the code and the reasoning — in the same repository, under the same history, owned by you.