A residue taxonomy and six design rules for guards that hold after everyone has forgotten the fork — with fleet-scale enforcement results and the public check that runs them.
Abstract
Fork residue is the parent codebase's identity persisting in a forked site on surfaces review cannot see — schema, raster art, asset filenames, CI/CD configuration, generator prompts, half-rewritten prose. Each surface defeats a different class of verification, so the remedy is not more careful review; it is mechanical invariants, enforced in CI per repository and again at fleet scope.
This paper is a development-loop companion to *The Trust Ladder*. That paper asks when a non-deterministic reviewer may be trusted to block a merge. This one asks the prior question: what the deterministic checks must cover in the first place — told through the failure mode that taught us, on a production microsite fleet, that "reviewed and scrubbed" and "clean" are different claims.
The intended reader owns a template fleet: an agency engineering lead, a platform owner, an in-house team running many sites from a shared codebase. Forking a sibling is the rational way to stand up site fifteen — nothing here argues otherwise. The argument is that un-forking is not a reading task, and the organizations that treat it as one will ship their parent's identity for months without knowing it.
1. The Fork That Passed Every Gate
A forked site ships its parent's identity because a fork begins as a byte-perfect copy of that identity, and review removes only what review can see. The layers beneath — raster art, filenames, deploy configuration, generator prompts — pass every grep, diff, build, and live inspection while still asserting that the site is someone else.
One of the sites in a legal-vertical microsite fleet we operate was stood up the rational way: fork the nearest sibling, rewrite what identifies it, review everything, ship. The copy was rewritten. The review was real. The greps came back clean — the parent's name appeared nowhere in the source tree.
Weeks later, someone shared a page. The social share card that unfurled carried the parent's practice area in set type — baked into the raster art, rendered on every share of every page. No grep can see inside a PNG. No diff flags a file that was copied, not changed. The build was green the whole time.
The same fleet produced a stranger artifact. A page on a second fork referenced an image that had never existed in that repository — not a broken path from a rename, but an inherited reference to a file the parent had and the child never did. The page's route returned 200; the preload of the missing image quietly failed on every load.
It passed the build, the type checker, the linter, and two separate live-site review passes, because every one of those instruments checks whether the page renders, and the page rendered.
Neither of these is a review failure in the ordinary sense. The reviewers read the code, and the code read clean. The failures lived in layers that reading does not reach — and every fork carries those layers, because a fork by definition starts as a byte-perfect copy of someone else's identity.
The thesis of this paper is that the fix is not better reviewing. The fix is invariants that hold when nobody remembers the fork happened — checks a machine runs on every commit, designed against the specific ways residue hides. What follows is the taxonomy of those hiding places, the six design rules the incidents taught us, and what happened when we promoted the rules from one repository's tests to an invariant enforced across a 38-repository production fleet.
2. The Residue Taxonomy
Fork residue hides on ten distinct surfaces: rendered copy, schema and alt text, dormant components, CI/CD configuration, raster art, asset filenames, generator prompts, and half-rewritten prose — plus lockfiles and references to assets the child never had. Each surface defeats a different verification instrument, which is why a scrub defined by reading always misses some of them.
Fork residue is not a synonym for "leftover copy." Copy is only the first layer, and it is the only one that ordinary review reliably catches. Our fleet's incident log sorts the residue that actually shipped into seven numbered layers — one of which splits into a raster twin, the numbering a fossil of discovery order — plus two entries that sit outside the stack entirely: ten distinct surfaces in all.
The useful property of the taxonomy is that each surface names the verification class it defeats.
| Layer | What shipped | What it defeats |
|---|---|---|
| L1 — Rendered copy | The parent's practice description on an About page; the parent's chat greeting on every route | Casual reading — though this is the one layer grep catches |
| L2 — Schema, alt text, footers | Structured-data knowsAbout entries 11/12 about the parent's practice; a footer claim on every page; image alt text | Rendered-page review — invisible until view-source |
| L3 — Dormant components | Parent components gated on empty arrays, waiting for a consumer | Runtime testing — nothing renders today, so nothing fails today |
| L4 — CI/CD configuration | Both deploy workflows invalidated the parent's CDN distribution | CI status itself — the deploy that fails by succeeding |
| L4b — Raster art | The share card with the parent's practice area in set type | Every text instrument: grep, diff, crawler, linter |
| L5 — Asset filenames | A parent-claim filename appearing seven times per page in responsive-image markup | Copy review — a filename is public copy nobody reads |
| L6 — Generator prompts | Every image-generation prompt opened with the parent's practice; the palette prompt requested the parent's accent color | Everything downstream — residue that produces more residue |
| L7 — Half-rewritten prose | Nouns swapped, but a subordinate clause still carried the parent's legal theory | Grep entirely — only reading finds it |
| — Lockfiles | A stale lockfile still named for the parent, in a repo that uses a different package manager | Dependency review |
| — Referenced ghosts | The image that never existed in this repo | The entire gate stack: build, types, lint, live review |
The deploy that fails by succeeding. The newest fork in the lineage inherited its deploy workflows from its parent, including the cache-invalidation step — pointed at the parent's CDN distribution. Every deploy reported green. Every deploy invalidated a different site's cache. The fork's own edge nodes kept serving whatever they had, and with a year-long s-maxage on the fleet's assets, "whatever they had" could stay pinned for a very long time.
This is the most dangerous layer in the taxonomy because the failure signal is inverted: the pipeline's success message is the evidence that the wrong thing happened. No amount of watching the dashboard catches a job that succeeds at the wrong task.
Identity that ships through art and filenames. The share card is the raster case, but the subtler one is L5: an image whose filename asserted the parent's marketing claim, appearing seven times per page in the responsive-image markup.
A filename is public copy — it appears in the page source, in network logs, in the URL bar when the asset is opened directly — and it is copy that no copy review will ever read, because filenames live in a layer reviewers treat as plumbing.
The half-rewritten sentence that reads as finished. L7 is the layer that defeats grep by construction: every forbidden word has been replaced, and the residue is structural. One page carried a sentence whose nouns belonged to the child but whose subordinate clause asserted the parent's legal theory — a claim that made no sense for the child's practice, grammatically fluent and lexically clean.
Another page stated a hardcoded count in prose directly above a component that derived the true count — the prose said three, the code said one. A third carried a lookup that failed politely into a graceful fallback, so the page looked intentional forever. None of this matches a pattern, because the pattern is meaning.
The taxonomy's practical lesson is definitional. When a team says a fork was scrubbed, that sentence is a claim about ten distinct surfaces, and most scrub processes have only ever defined three of them. "Scrubbed" is not a feeling of thoroughness. It is a checklist with surfaces named, or it is nothing.
3. Six Design Rules for Guards That Hold
Guards against fork residue hold when they bind to claims rather than words, derive identity from configuration instead of hand-kept lists, put the parent first in every inherited denylist, liveness-check their own allowlists, prove themselves by planted failure, and are verified by an instrument that shares nothing with the guard. Each rule exists because its absence shipped residue.
A taxonomy on its own stops nothing. After the incidents above, we rebuilt the fleet's defenses as mechanical invariants — tests that run on every commit and fail the build when residue appears. Six design rules came out of that work, each purchased with a specific failure. They are stated here in the order a team should apply them.
The code samples are TypeScript because our fleet is; the rules are stack-agnostic, and every pattern here has a direct equivalent in any language with a test runner.
Rule 1 — The forbidden word is usually also a correct word
The naive guard bans the parent's vocabulary outright, and it dies within a week — because on a sibling site in the same vertical, the parent's vocabulary is usually legitimate in some contexts. The examples here are deliberately foreign to our fleet: a maritime term appears correctly in a logistics story; an aviation term appears correctly in a travel explainer.
When the blanket ban fires on correct usage, the team relaxes the rail instead of obeying it, and a relaxed rail protects nothing.
So the rail has to bind to the claim, not the token. The residue that matters is the child asserting the parent's identity — first-person constructions, practice-level assertions — so that is what the pattern should match:
```ts
// Ban the CLAIM, not the word.
// Flags "we handle
const IDENTITY_CLAIMS = [
/\b(?:we|our (?:firm|team|attorneys))\b[^.]{0,80}\b(?:PARENT_PRACTICE_TERMS)\b/i,
];
```
Every exemption goes into an allowlist with a written reason. The reason is not documentation theater — it is what lets the next engineer distinguish a deliberate exception from a forgotten one, which is the subject of Rule 4.
Rule 2 — Derive identity; never list it
The schema that described a different firm got that way through a hand-kept list: a copied constants file carrying the parent's identity fields, which everyone assumed someone else had updated. A hand-maintained list of "who we are" and "who we are not" is residue waiting to happen, because a fork copies lists perfectly and updates them approximately.
Every site in our fleet already declares its identity somewhere authoritative — the deploy configuration that names the app, the site config that names the domain. The guard derives from that source, and computes the foreign set by subtraction:
```ts
// registry-minus-self: the foreign set is everything the fleet
// registry names, except what THIS repo's own config declares.
const self = readAppName('sst.config.ts');
const foreign = fleetRegistry.apps.filter((a) => a !== self);
```
Registry-minus-self has a second virtue: it is fork-proof by construction. When the next fork changes its own config — the one thing a new site must change to deploy at all — the guard's definition of "foreign" updates itself.
Rule 3 — The parent joins every foreign set first
Three separate incidents in one fleet, same shape: a fork inherited a denylist — foreign tenant identifiers, crawler exclusions, sibling domains — and the list was correct for the parent. Every sibling was blocked except one: the parent itself, which never needed to appear in its own denylist. Inheriting a denylist verbatim leaves the likeliest carryover as exactly the one value not blocked.
The mechanical answer is a constructor discipline: the moment a fork is cut, the parent's identity is prepended to every inherited exclusion set, before any other edit —
```ts
// The parent is the FIRST entry in every foreign set a fork inherits.
const FOREIGN_TENANTS = [FORK_PARENT.tenant, ...inherited.tenants];
const FOREIGN_DOMAINS = [FORK_PARENT.domain, ...inherited.domains];
```
Under Rule 2 this happens automatically — subtraction includes the parent the moment the child's config stops matching it. But wherever a literal list survives, the parent goes in first, because the parent is the one sibling the list has never needed to name.
Rule 4 — Allowlists must be liveness-checked
Every guard accumulates exemptions, and exemptions rot. One inherited exemption table in our fleet carried seventeen entries that no longer matched anything in the tree — seventeen lines of dead policy that read as active decisions to every engineer who scrolled past them. A dead exemption is worse than clutter: it teaches readers that the guard is approximate, and it stands ready to silently re-exempt the next thing that happens to match it.
So the allowlist checks itself. Every entry must still match something, or the test fails and names the dead entry:
```ts
for (const entry of allowlist) {
const hits = scan(tree, entry.pattern);
assert(hits.length > 0, dead allowlist entry: ${entry.pattern});
}
```
The measure of this rule is that it caught its own author. When we rebuilt that seventeen-entry table from scratch, the rebuilt table's liveness check failed on four entries in the first draft — four exemptions written from memory of residue that had already been removed. The check outperformed the person who had just written it, which is the entire argument for having it.
Rule 5 — Mutation-verify every guard
A guard that has never been observed to fail is not a guard; it is a hope with a green checkmark. Its failure modes are mundane: a pattern that never matched anything, a scan pointed at a directory that does not exist, a comparison that is vacuously true. A hardcoded expected-total beside a derived actual-total does not guard the total — when the content is deleted, both sides drift together and the assertion passes on emptiness.
Mutation verification is the discipline of planting the disease and requiring the fever.
For the fleet's identity scanner, we planted each class of residue the guard claims to catch — a foreign app name in source, a sibling domain in a config, a foreign accent color in both hex and rgb-triple form, a foreign filename stem, a wrong CDN target in a workflow, a foreign lockfile — six mutations, each required to turn the build red before the guard was allowed to merge.
The plants anchor on permanence: each goes into a file the repo cannot function without, so the control cannot rot away when content changes.
Write the mutation set down next to the guard. The next engineer who edits the pattern reruns six plants and knows in minutes whether the edit killed the guard's teeth.
Rule 6 — Verify with an independent instrument
The most instructive failure in the whole incident log: after a fork's copy was scrubbed, a verification pass reported zero residual identity claims. The verification used the guard's own phrase list to measure. Nine claims were live on the site at that moment — phrased in ways the list did not contain. A check that reuses the guard's patterns is the guard run twice, agreeing with itself; it measures the guard's vocabulary, not the site.
Independence is structural, not attitudinal. The verifying instrument must share nothing with the guard: grep the rendered HTML of the live site rather than the source tree, with patterns written fresh from the parent's actual identity; invert the direction — enumerate what is allowed and flag everything else, rather than enumerating what is banned.
And after the instruments agree, open the pages — including the 404 page, which no crawler visits and no sitemap lists, and which on one fork still carried the parent's identity after every scan came back clean.
The rule binds us too, in both directions. When we later ran our fleet-wide residue check in a dry run, it reported a finding that turned out to be the instrument's own error — it had read a machine's checked-out working tree, stale on an old branch, instead of the repository's main line. An instrument that can manufacture a finding is as dangerous as one that can miss one.
Independence plus honesty about the instrument itself is the standard; anything less is measurement theater.
4. From Repository Rails to Fleet Invariant
A roster-free fleet check derives everything it needs from the repository under test — the app name from deploy configuration, workflow filters from the workflow files, the public host from robots metadata — and asserts their internal consistency. Because it carries no central roster of repository identities, it needs zero per-repository configuration and scales to any fleet size without rotting.
The six rules first landed as an in-repo scanner: a test suite that runs with the fork lineage's ordinary CI, assembled entirely from the rules above. It derives the foreign-app set from the fleet registry minus the repository's own declared identity (Rule 2), includes every sibling's domain and accent color — in hex and rgb-triple form, because colors survive format changes — plus filename stems, so identity cannot ship through a srcSet (the L5 lesson).
It pins the deploy workflows' app filters to the repository's own deploy config, which is the mechanical answer to the deploy that fails by succeeding. It checks lockfile identity. It strips comments before scanning code, so documentation about residue does not read as residue. Its allowlist is liveness-checked (Rule 4), and it merged only after all six mutation plants turned the build red (Rule 5).
That protects one fork lineage. The same disease exists anywhere a template propagates, and a fleet-scale defense cannot work the way the in-repo scanner does — nobody will hand-configure a scanner per repository across an entire fleet, and a central roster of every repository's identity is exactly the hand-kept list Rule 2 forbids.
The fleet check is therefore roster-free. Everything it needs, it derives from the repository it is checking: the app name from the deploy config, the workflow filters from the workflow files, the public host from the robots configuration. It asserts internal consistency — this repository's workflows deploy this repository's app, this repository's public metadata names this repository's host — which requires no knowledge of any other repository at all.
Rule 2, applied at fleet scope, is what makes zero-configuration possible: the check scales to any number of repositories because each repository already contains everything the check needs to know.
That check is public code. The fleet-governance suite, including the fork-identity check and its tests, is published at github.com/iSimplifyMe/fleetcheck — the check is src/checks/universal/fork-identity-consistency.ts. It is the paper's only named artifact, and readers are welcome to read the patterns against the rules above.
5. The Rollout
The fork-identity check rolled out to a 38-repository production fleet in one evening through scripted pull requests, with a deploy-safety classifier holding anything that could trigger a deploy — zero unintended deploys fired. A preceding dry run over 36 locally checked-out fleet repositories produced zero genuine findings; its single apparent finding was the instrument's own error, disclosed.
Numbers from the promotion, frozen at the time of writing.
The fleet check rolled out to a 38-repository production fleet in one evening. The rollout was scripted — a pull request per repository, generated and merged in waves — with a deploy-safety classifier deciding, per repository, whether merging the pin could trigger a production deploy, and holding anything that could. Across all 38 repositories, zero unintended deploys fired.
Before the rollout, the check ran in a dry run over local checkouts of 36 of the fleet's repositories: zero genuine findings and zero false positives on the repositories' main lines.
The dry run's single apparent finding was the instrument's own error described under Rule 6 — one local tree sat stale on an old branch, so the instrument was reading a working tree instead of the repository's main line — caught precisely because the rollout treated the fleet check itself as subject to the rules it enforces.
A handful of repositories also surfaced standing configuration debt during the rollout's first pass; those merges were held until the debt was cleared, the same evening. A fleet-wide check's first pass is a fleet-wide audit, and it is worth planning for the audit to find something.
The timeline is the result worth underlining. The share card, the ghost asset, the inverted deploy — those incidents were discovered, taxonomized, promoted into repository rails, generalized into a roster-free check, published, and enforced across every production repository within days. None of that speed came from heroics. It came from the fact that every step produced a mechanical artifact — a test, a check, a pin — that keeps working after the incident that produced it has been forgotten.
6. Run This on Your Fork Tomorrow
To scrub a fork, grep the rendered HTML of the live site rather than the source, open every page and raster including the 404 route, scrub workflows and prompts and lockfiles beyond the source directory, verify deploy targets rather than deploy status, prepend the parent to inherited denylists, derive identity from configuration, liveness-check every allowlist, and mutation-test every guard.
The checklist below is the paper in executable form, ordered by yield. It assumes nothing about your stack; the public fleetcheck check mechanizes the configuration-consistency steps, and the eyeball passes stay human by design.
- Grep the rendered HTML, not the source. Fetch every route of the live child site and search case-insensitively for the parent's name, domain, and app identifier — including inside URLs and filenames.
- Open the pages and the art. Share cards, hero images, favicons — anything rasterized, viewed by a person. Include the 404 page; no crawl reaches it.
- Scrub beyond
src/. Deploy workflows, infrastructure config, generator prompts, lockfiles. The parent's app name tags cloud resources and appears nowhere a person reads. - Check the deploy target, not the deploy status. Confirm every workflow's cache invalidation, app filter, and environment references name the child. A green deploy proves the job succeeded, not that it succeeded at the right site.
- Prepend the parent to every inherited denylist — tenants, domains, crawler exclusions — before any other edit.
- Replace identity lists with derivation. Compute "self" from the config the site cannot deploy without; compute "foreign" by subtraction.
- Liveness-check every allowlist. Any exemption that no longer matches anything fails the build and names itself.
- Plant residue and watch the guard fire. One mutation per residue class the guard claims to catch. A guard that has never failed is unproven.
- Verify with an instrument that shares nothing with the guard — fresh patterns, opposite direction, different layer — and then read the pages anyway.
7. What This Paper Does Not Cover
This paper covers the guards. The promotion system that produces them — turning an operating incident into a durable rule, a rule into an enforced check, and a check into fleet-wide governance, with defined criteria at each stage — is the subject of a companion paper scheduled for later this year.
The rules above did not stop at one fleet's tests; they were promoted through that layered system. What changes when the operator applying the system is an AI agent rather than a person is the companion paper's core question — the point where guardrails like these stop being a convenience and become the control plane. It is its own paper, with its own evidence, later this year.
Companion Papers
Curated from the iSimplifyMe whitepaper series — the two papers this one leans on directly:
- The Trust Ladder: Supervised Autonomy for AI Code Review *— shipped.* When a non-deterministic reviewer may block a merge. This paper defines what the deterministic layer beneath it must cover.
- The Blind Panel: Position Bias and Agreement as Preconditions for a Win Rate *— shipped.* Instrument honesty in evaluation — the measurement discipline Rule 6 applies to guards.
- *The Layers Review Cannot See* *— this paper.* The residue taxonomy and the mechanical guardrails.
Conclusion
Forking a sibling is the rational way to grow a template fleet, and no argument here says otherwise. What the incident log says is that a fork begins life as a perfect copy of someone else's identity, that the identity retreats into layers reading cannot reach — art, filenames, workflows, prompts, half-rewritten sentences — and that each layer defeats a specific instrument a careful team would otherwise trust. Review finds what review can see.
The rest requires invariants: claims bound rather than words banned, identity derived rather than listed, denylists the parent joins first, allowlists that prove their own liveness, guards proven by planted failure, and verification that shares nothing with the thing it verifies. Build those once, enforce them everywhere, and the scrub stops being a memory exercise. Memory is a wasting asset. Invariants are not.
Notices
Not professional advice. This paper is an engineering reference for informational purposes. Governance and process decisions require review against your organization's own risk and compliance requirements.
Client anonymity. The incidents described are real and drawn from a production microsite fleet operated by iSimplifyMe. Identifying details — site names, practice areas, domains, and visual identity — have been generalized, and no client is named.
Measurements are point-in-time. Repository counts, findings, and rollout figures are frozen observations from the fleet described, at the time of writing; live numbers change as the fleet grows.
Trademarks. GitHub is a trademark of GitHub, Inc. References to third-party services are descriptive and do not imply endorsement.