Sanitize when the lesson is born, never months later

The rule

When client or proprietary work produces a genuinely transferable lesson, write the sanitized, generic version in the same session — while it's still obvious which details are sensitive. Never plan to "clean it up later before publishing."

The scar

The alternative was considered seriously and rejected on analysis: bulk-sanitizing an existing knowledge base of several hundred entries before publishing any of it. That approach is guaranteed to leak, and the reason is structural rather than careless — an identifier hides in frontmatter, a hostname sits inside a fenced code block, a person's name appears in one sentence of a long session log. Reviewing hundreds of documents at uniform attention is not something humans do; attention decays, and the leak lands in the file reviewed forty-first.

The compounding problem: months later, the author no longer remembers which details were sensitive. A detail that reads as generic ("the northeast district") can still identify, and only the person who was there at the time knows that.

How to apply

1. Dual-write: the private entry as usual, plus the generic version, same session, while the sensitive parts are still obvious to you.
2. Write the generic version generically from the start — don't write specifics and plan to strip them. Stripping is where things get missed; never-writing-it is airtight.
3. Two gates, always both: a mechanical denylist check (catches names) and a human read (catches context — the mechanical check will never flag "a large district in the city's northeast").
4. If a lesson genuinely cannot be stated without the specifics, don't write it. Not every lesson is portable, and a half-sanitized entry is worse than an absent one.
5. Security findings are never published in any form — generic or not — while the underlying issue could still be live.