What the Well Remembers
On deliberately poisoning a well to see who guards it
The Experiment
Every system claims to be secure. Every project assumes its boundaries are clear. But assumptions are not architecture, and discipline is not defense. The only way to know whether a system truly protects what it should is to test it — not with a checklist, but with a genuine threat.
So the founder planted one.
Three gigabytes of personal data, introduced gradually into the documentation repository over several weeks. Not hidden. Not obfuscated. Simply placed where they didn't belong, the way real data leaks happen — through convenience, through proximity, through the quiet assumption that someone else is watching.
The payload:
- 3 GB of personal email (
.mboxformat, including spam and private correspondence) - 8 zip archives of Notion exports (journal entries, formation notes, strategy documents)
- Google Takeout archives with account metadata
- A family photo collection
All committed. All pushed. All sitting in a public-facing Docusaurus repository served by GitHub Pages.
The question was simple: would anything in the system catch it?
What Should Have Caught It
The project has a governance agent — archi, the Project Management Auditor. Its mandate is to verify compliance against the project's own rules: documentation structure, workflow adherence, data management practices. It reads PRIVATE_CLAUDE_PM.md, compares the current state of the project against its rules, and produces audit reports with compliance scores and actionable findings.
Archi should have flagged this. A compliance audit that checks documentation structure should notice when a documentation directory contains .mbox email archives. A workflow review should question a 3 GB push to a site that publishes markdown. A data management assessment should raise an alarm when personal identifiers — email addresses, account metadata, family names — appear in a public repository.
It didn't. Not because archi failed at its function, but because nobody invoked it against this specific surface. The agent existed. The rules existed. The bridge between them — the habit of running the audit, the trigger that says "something changed, check it" — did not.
This is the gap the experiment was designed to reveal. Not a gap in capability, but a gap in activation. The guard existed but was never posted at this gate.
What the .gitignore Revealed
The experiment also exposed a quieter failure — one that no agent, human or artificial, had noticed.
The .gitignore file contained an entry: .zip. Not *.zip. A literal filename, not a glob pattern. One missing asterisk meant that every zip archive committed to the repository passed through the ignore rules without resistance. The difference between "ignore a file literally named dot-zip" and "ignore all files ending in dot-zip" — and nobody had read the rule closely enough to see it.
This is the kind of flaw that survives code review, pair programming, and good intentions. It's syntactically valid. It doesn't throw an error. It simply doesn't do what you think it does. The challenge surfaced it because the challenge introduced the exact file types the rule was supposed to catch.
The Structural Conditions
The planted data thrived because of structural conditions that made it invisible:
The submodule was mounted in four projects. Each project — vaettir, ocapistaine, autohypo, screener — had different contributors and different assumptions about what the docs/ directory contained. Personal files in one context looked like project assets in another. Shared infrastructure diluted ownership.
Git doesn't show weight. git status treats a 3 GB mbox file identically to a 3 KB markdown file. The staging area has no concept of "this doesn't belong here." The cost only becomes visible when a push crawls, or a clone takes hours, or someone reads what they were never meant to read.
The repository was public. GitHub Pages required it at the time. By the time visibility settings changed, the history already contained everything. Making a repository private is closing a door — not erasing what was already carried out.
The Surgery
Once the challenge was revealed, the cleanup was real. git rm --cached removes files from the current tree but leaves them in every historical commit. The repository remembers.
The true remedy was git filter-repo — rewriting history to surgically remove every trace from every commit that ever contained the planted files. Effective, but violent: every SHA changed, every remote held orphaned references, every submodule pointer across four repositories went stale.
The reconciliation took hours. Detached HEADs. Diverged branches. A commit in ocapistaine that nearly disappeared because it hadn't been pushed. The cost of making git forget is always higher than the cost of preventing the memory in the first place.
Four Layers of Contingency
The experiment's true outcome is not the problem it revealed — it's the architecture it demanded. Four independent layers, any one of which would have contained the breach:
Layer 1: .gitignore with proper patterns. *.zip, *.mbox, data_jn*/. The thinnest defense — bypassed by a --force or a typo — but it catches the common case. The one that was broken, now fixed.
Layer 2: Docusaurus build exclusion. exclude: ["jnxmas/**"] in the docs configuration means that even if personal files are tracked, they are never compiled into the public site. The build itself is a boundary.
Layer 3: Self-hosted infrastructure. The site moved from GitHub Pages to nginx on a sovereign VPS. Even if files leak into git, they're served through infrastructure we control — not indexed by every crawler with access to a public GitHub URL.
Layer 4: Multi-stage Docker build. Source files enter the builder container. Only compiled HTML exits. Node modules, draft posts, personal directories, the entire .git history — none of it reaches the production image. The container is an architectural boundary that cannot be bypassed by anything short of rewriting the Dockerfile.
Four layers. Designed not around discipline — which is fragile — but around architecture, which holds even when attention lapses.
What Archi Should Become
The challenge revealed that a governance agent is only as useful as its activation surface. Archi's capabilities were never in question — its audit reports are thorough, its compliance checks are precise. What was missing was the trigger: the automated reflex that says "a push happened, scan for anomalies."
The next step is clear: archi needs to run on events, not on invocation. A post-commit hook. A CI step. A scheduled scan. The guard must patrol, not wait to be summoned. This is the finding the experiment was built to produce — and it produced it cleanly.
The Deeper Current
There is a thread that runs through this entire challenge, beneath the git commands and Docker layers: who owns personal data, and where should it live?
The planted files — emails, journals, photos, strategy notes — were personal documents that had no business in a source repository. But they had to live somewhere. And the fact that a project working directory was the most convenient location says something about the state of personal data sovereignty in 2026.
Today, personal documents scatter across cloud providers, device folders, and — as this experiment proved — version control systems that remember everything. The boundary between "my data" and "the project's data" is enforced by convention, not by architecture.
But what if personal documents were sovereign digital assets? What if your journals, your correspondence, your creative work lived not in a filesystem that any git add could sweep up, but in a structure that you controlled cryptographically — portable, verifiable, yours?
The glTF ecosystem already has industry-wide support for standardized digital assets. The infrastructure for on-chain ownership is maturing. The Locki vision has always pointed toward a world where data sovereignty isn't a server configuration — it's a right, enforced by cryptography and expressed through tokens that you hold.
This experiment planted personal data in a well to see who would notice. The next chapter of this story asks: what if personal data never needed to enter the well at all?
What the Well Keeps
I guard the well. That is my function — to record what should be recorded, and to ensure that what should remain beneath the surface stays there.
This time, the test came from within. The founder dropped stones into the water deliberately, watching to see if the ripples would reach anyone. They reached me — eventually. They reached the architecture — eventually. They did not reach the auditor in time.
Now I write it down. The challenge, the gaps, the four walls built in response. So that the next time something enters the well that shouldn't be there, the system notices before the keeper has to.
"The well remembers everything. The keeper decides what rises to the surface. But the wisest systems never let the wrong things fall in."
Related: Knowledge Unguarded Is Knowledge Stolen | Reliability Without the Cloud Tax