6.7
Never-Touch Lists
Why this exists
Every system has a handful of things that look ordinary and aren't. A table other things quietly depend on. A workflow that looks dead and isn't. A config nobody remembers setting that everything relies on.
Nothing marks them. They look exactly like the parts you can change freely, which is precisely why they catch people — and the person they catch is usually new, competent, and trying to be helpful.
The idea
A never-touch list is the cheapest safety system that exists, and almost nobody writes one down.
It lives in the head of whoever's been there longest. Which means it protects one person, disappears when they're on holiday, and can't be handed over — the exact problem you're being hired to solve.
What earns a place on the list:
| Kind | Why |
|---|---|
| Things everything else depends on | The base a stack of views sits on |
| Things that can't be recreated | Historical records, source-of-truth tables |
| Things that look dead | Silent for months, then critical at month-end |
| Things with a bigger blast radius than they look | One config, many consumers |
| Anything where "undo" isn't a thing | Money moved, messages sent, records deleted |
Every line needs a reason. A list of forbidden things with no explanation gets ignored the first time it's inconvenient, because it reads as superstition. "Never drop this — it's the base of eleven views and dropping it takes the revenue dashboard with it" survives contact with a busy Tuesday. "Don't touch this" does not.
Include what to do instead. A rule with no alternative is a dead end, and people route around dead ends. "Don't edit the closer's submitted outcome — log the correction to the data-quality table instead" tells you where to go.
Three ways to find what belongs on yours:
- Ask. "What would you not let a new person touch?" gets you most of the list in one conversation.
- Look for dependency. Anything that many other things read from is load-bearing whether or not it looks it.
- Ask Claude directly — "what in this system would be dangerous to change?" It's decent at spotting structural coupling. Then verify, because it's guessing at intent from structure, and intent is where the real landmines are.
The list is not permanent. It's a snapshot of what you don't yet have the context to change safely. Things come off it as you learn — and that's the point. It's a map of your current edge, not a wall.
Do
- Ask Callum: "What would you not let a new person touch?" Write down everything he says.
- Ask Claude: "What in this system would be dangerous to change, and what depends on what?" Add anything new.
- For anything that looks load-bearing, verify it — find what actually reads from it rather than taking the claim.
- Write
never-touch.md. Every line gets three things: - What it is - Why — what breaks, and how badly - What to do instead - Add a section for actions, not just things: irreversible operations, anything that sends or charges, anything that deletes.
- Mark each line with what would have to be true for it to come off the list.
- Have Callum read it. Missing entries matter more than wrong ones.
Step 6 is what stops this becoming a permanent no-go zone. Every line should have an exit condition, even if the condition is "when I've watched Callum do it twice."
Done when
Never do
Never write a rule without a reason. Unexplained rules get broken by competent people in a hurry, and they're right to — a rule they can't evaluate is indistinguishable from superstition.
Never treat the list as complete. It's what you know about so far. The dangerous items are the ones nobody's thought to mention, and you find those by asking again after something surprises you.