The library

1. List the ten things you're responsible for. Names only.
2. Draw arrows between them — not what they are, what breaks what.
3. Push to second order: if A affects B, what does B affect?
4. Mark pairs with a required sequence.
5. Mark every edge only you know about.

What ruins it: Describing what each thing is. That's knowledge, and it's infinite — you'll fill ten pages and quit.

1. Write it down anyway, and know why you didn't want to.
2. Undocumented knowledge is perfectly secure and completely un-backed-up.
3. Start with the five things that would cost most if you vanished.
4. Write the structure, not the procedures.
5. Document to be portable, not replaceable.

What ruins it: Waiting until you're leaving. The version written under pressure is the worst one you'll ever produce.

1. When it sounds obvious, you've written the what.
2. When it sounds paranoid, you've written the what without the why.
3. Write the when instead.
4. Not 'never touch that' — 'if you're about to change this, ask why it's like that.'
5. The trigger is the transferable part.

What ruins it: Writing rules. On the page a rule reads as either banal or superstitious, because the judgement fell out.

1. Notice the moments you prevent something. They leave no record.
2. Keep your own list of them for one month.
3. You'll be surprised how many there are.
4. That list is the shape of what you actually do.
5. It's also exactly what vanishes when you leave.

What ruins it: Assuming the work is visible. Prevented problems produce no evidence, so activity-based measures can't see them.

1. Draw the org chart. Then draw the decision map beside it.
2. Who must hear it first or they'll unwind it later.
3. Whose approval is required and functionally automatic.
4. Who has no formal authority and can stop everything.
5. Keep it private. Write it for a successor.

What ruins it: Assuming the chart is the map. New senior hires underperform for a year rebuilding this from scratch.

1. Imagine you're unreachable for two weeks. Not gone — unreachable.
2. Walk through the week and ask what stops entirely.
3. Not what slows. What stops, because only you know something.
4. Most people find three to eight.
5. Write up the top three.

What ruins it: Doing a documentation audit instead. The two-week test finds single points of failure faster and takes five minutes.

1. Stop applying task-shaped advice to connective work.
2. Your work is routing, sequencing, and noticing consequences.
3. Ask for structure and consequences, not completion.
4. What breaks downstream. What has to move first.
5. Who needs to know before this is announced.

What ruins it: Concluding the tools aren't for you. The advice was aimed at a different kind of job.

1. Write the ordering constraints as a list of pairs.
2. This before that — and one line on why.
3. Which approvals precede which announcements.
4. Which group hears it first, and what happens if they don't.
5. One page, one hour.

What ruins it: Documenting steps without ordering. A competent person follows the procedure perfectly and still causes a mess.

1. Write the structure, not the accumulated detail.
2. What depends on what, and why.
3. Detail is bound to one building. Structure travels.
4. It's the difference between being needed here and being good at this.
5. One expires the day you leave.

What ruins it: Keeping it in your head to stay indispensable. That's leverage that expires; the written version is a capability.

1. Every time you learn something, ask what kind of thing it's an example of.
2. The instance stays here. The kind goes with you.
3. Keep a running note of kinds, not instances.
4. How to find what depends on what. How to identify who really decides.
5. That note is what makes you effective somewhere else.

What ruins it: Accumulating detail. Thousands of facts about one place transfer at exactly zero percent.

1. Before pasting, ask a different question.
2. Not: did I remove the identifier.
3. Ask: could someone rebuild it from what's left?
4. Check dates, locations, ranges, titles — in combination, not one at a time.
5. If the answer is maybe, generalise one more field and ask again.

What ruins it: Checking fields individually. Three harmless fields together can point at exactly one record.

1. Sort what you handle into exactly three buckets, not more.
2. Bucket 1: you'd happily forward it outside your organisation.
3. Bucket 2: you'd forward it after removing a few details.
4. Bucket 3: never leaves, under any circumstance.
5. Write two real examples under each, in your own words.
6. Keep it on paper. Nobody else needs to see it.

What ruins it: Making more than three buckets. A scheme you can't recall under pressure is a scheme you won't use.

1. Ask one question: would I email this outside the organisation?
2. If yes, it's safe to work on with AI.
3. Start with agendas, process notes, explanations of how things work.
4. Stay inside that filter for two weeks.
5. Widen only once the habit is automatic.

What ruins it: Judging each case fresh. You already make this call daily — reuse it instead of inventing a new one.

1. Make the rule when you're calm, not when you need it.
2. Three tiers, crude on purpose.
3. Two or three real examples under each, from your actual work.
4. Your words, not policy language.
5. In the moment, ask which of three — not whether it's safe.

What ruins it: Deciding under deadline. Pressure pushes you to refuse everything or wave everything through.

1. List where your week actually goes.
2. Notice how little of it touches the protected record.
3. Drafting, structuring, explaining, comparing, preparing decisions.
4. All of that is available to you right now.
5. Stop waiting for access the useful work never needed.

What ruins it: Treating no-data-access as a consolation prize. It's most of the value.

1. Ask three questions, not one.
2. How long is my input retained?
3. Who at the vendor can access it, and under what circumstances?
4. Where is it stored, and under whose jurisdiction?
5. The answers are usually in the docs, and usually fine.

What ruins it: Stopping at 'they don't train on it'. That answers about a third of what you asked.

1. If you influence policy, argue for three tiers instead of one.
2. A blanket rule is calibrated for the most sensitive thing.
3. Which makes it absurd for the other ninety percent.
4. People stop applying it — and they stop selectively.
5. If you don't influence policy, apply gradation to your own work honestly.

What ruins it: Treating a uniform rule as the safe option. It produces undifferentiated non-compliance, which puts the sensitive material at more risk.

1. Don't paste then redact. Start from blank.
2. Open a new note and write the situation in your own words.
3. Generic labels, no names, only what makes the question answerable.
4. Nothing was ever exposed, so nothing needs removing.
5. It's also faster — you were forced to identify what mattered.

What ruins it: Treating sanitisation as a prerequisite. Prerequisites get skipped under deadline; step one doesn't.

1. List the writing you do that contains no protected record.
2. Process notes. Onboarding material. Explanations of why things are done.
3. Notice that it's also your slowest, most valuable writing.
4. Start there, not with the trivial safe stuff.
5. Sort by what the data is, not by how much the work matters.

What ruins it: Using AI only on trivia. Perceived risk tracks importance, not sensitivity — and that instinct is backwards.

1. Stop asking whether the tool is approved.
2. Ask whether this specific document may leave your systems.
3. Ask what categories may go to a third party under existing agreements.
4. Those questions have owners and real answers.
5. The tool question mostly dissolves once you know.

What ruins it: Asking about tools. Approval depends on unbounded use, so you get a hedge and nothing moves.

1. Keep your own running sense of what has already gone out.
2. Before each disclosure, ask the question nobody in the process asks.
3. Not: is this one fine.
4. Ask: is this fine given everything already sent to the same place?
5. Five seconds, and nobody else in the chain is doing it.

What ruins it: Relying on the review process. It assesses each request in isolation; the risk accumulates across them.

1. Stop asking whether the integration can be approved.
2. Ask what you're permitted to export by hand.
3. Export it, work on it, bring the result back yourself.
4. It doesn't scale and requires you present. That's why it's approvable.
5. Ask what you may carry, not what you may connect.

What ruins it: Waiting for the pipe. A standing connection runs unattended — that's the thing that's hard to approve, and should be.

1. Design the read-only version of the workflow first.
2. It reads the thread and tells you what was decided.
3. It reads the document and tells you what's missing.
4. It hands you a draft. You send it.
5. You remain the thing that acts.

What ruins it: Designing a workflow needing write access. Unattended action is the actual approval risk, not comprehension.

1. Write down how your environment differs from the standard one.
2. The separator that isn't standard. The path that isn't where paths go.
3. The thing that must happen first or nothing works.
4. Keep it to one page.
5. Use it to translate every generic tutorial you find.

What ruins it: Searching for a tutorial that matches your setup. Your combination is close to unique — it doesn't exist.

1. List the layers in your most-used workaround.
2. Next to each, write one line: why this layer exists.
3. Not the process. The reason.
4. Especially for the layer that looks pointless.
5. That's the one someone will remove.

What ruins it: Documenting the steps without the reasons. Someone new deletes a load-bearing layer that looked redundant.

1. List what you actually want AI to do this week.
2. Check each against the free tier of a tool you can already access.
3. Paid tiers mostly buy scale, integration and admin control.
4. Do the work at the free tier first.
5. Ask for the licence once you can show what it returned.

What ruins it: Waiting for approval before starting. You lose a quarter proving nothing.

1. Name the shape of your problem before evaluating any tool.
2. Matching, ranking, classifying, generating, or deciding?
3. Then ask what the tool actually produces, not what the demo showed.
4. If the shapes don't line up, stop.
5. Keep the goal. Go find a tool that fits it.

What ruins it: Evaluating tools before naming the problem type. No amount of model quality closes a shape mismatch.

1. Before designing, ask what needs nobody's sign-off.
2. Prefer the boring reliable route over the elegant one.
3. Export, convert, move by hand if that's what's open.
4. Only escalate to permission when nothing else works.
5. Check whether it's genuinely blocked first — it's less often than assumed.

What ruins it: Designing the elegant version. It needs permission, and permission is the scarce resource, not cleverness.

1. Take the slow manual step everyone wants gone.
2. Ask: is this slow, or is this a control?
3. If slow, automate it.
4. If it's a control, automate everything up to it instead.
5. Prepare the decision so completely it takes ten seconds.

What ruins it: Automating through the control. You didn't just save time — you removed the evidence anyone decided.

1. Name the thing that already happens in an unmanaged way.
2. People are pasting into whatever they found. That's the exposure.
3. Frame the request as closing that exposure.
4. An approved tool with a data agreement reduces risk.
5. Write it for the person signing, not the person using.

What ruins it: Framing it as a capability. To the approver, capability reads as new surface area.

1. Pick something you do every single week.
2. The recurring summary. The update nobody enjoys writing.
3. Do it with AI this week, and again next week.
4. Each round, fix what was wrong last time.
5. Six weeks in, compare it to what it used to cost.

What ruins it: Picking something impressive. Novel tasks give one result and no habit.

1. Find the line in your process where the decision happens.
2. Everything before it: gathering, formatting, checking, assembling.
3. That's where the hours are.
4. Automate right up to the line. Never across it.
5. The deciding takes seconds once everything is prepared.

What ruins it: Automating across the line to save time. The deciding was never the expensive part.

1. Think in data categories, not in products.
2. Keep a note: which categories were involved, which never were.
3. Record how you decided, and that the rule predated the situation.
4. That's the answer a review actually asks for.
5. It's also what keeps you safe in the moment.

What ruins it: Thinking in tools. A list of products is a weak answer to a question that was never about products.

1. Decide at the start whether this work might be examined later.
2. If so, record inputs as they were, not reconstructed afterwards.
3. Make decision points explicit, with a named person.
4. Keep what was rejected, not just what was chosen.
5. None of it is slow. All of it has to be decided upfront.

What ruins it: Documenting afterwards. That describes what probably happened; only a designed workflow records what did.

1. Before the request, write two sentences on the situation.
2. Who reads this. What you're optimising for.
3. What you already tried and why it failed.
4. What would make an answer useless to you.
5. Then ask the question.

What ruins it: Rewriting the prompt instead. Wording is almost never the bottleneck — missing context is.

1. Take a step-by-step procedure you already have.
2. Ask what principle the steps imply.
3. Ask what someone would need to understand before the steps make sense.
4. Argue with the first answer — that's the useful part.
5. It works downward too: principle to steps.

What ruins it: Asking it to do the work rather than change the altitude. Translation between levels is the thing it's actually good at.

1. Separate the material from the structure of the problem.
2. The material is confidential. The structure almost never is.
3. Describe the decision shape with generic labels.
4. Get the framework right out loud.
5. Apply it to the real material yourself, offline.

What ruins it: Assuming you need both. Access looked like the requirement, but the hard part was always the structure.

1. Delete the prompt library.
2. Before every request, say where you are.
3. What this is for, who reads it, what already failed.
4. What would make the answer useless.
5. Thirty seconds, every time, until it's automatic.

What ruins it: Collecting more prompts. No template contains your situation, which is the part that matters.

1. Stop asking for summaries.
2. Summaries preserve proportion — a shorter version of the same shape.
3. Ask what was decided. What changed. What is now someone's responsibility.
4. Ask what you'd need if you had missed the whole thing.
5. Measure how much of the input survived, not how much time you saved.

What ruins it: Optimising for time saved. It rewards producing more, whether or not it was worth producing.

1. Ask for the considerations, not the conclusion.
2. What questions would a reviewer ask?
3. What would have to be true for each option to be right?
4. You can evaluate a framework instantly.
5. You cannot verify a confident answer about a situation only you understand.

What ruins it: Asking for answers. You've created a verification problem you can't solve — and it sounds equally confident either way.

1. Check whether you have procedures or playbooks. Usually procedures.
2. Signs you're missing the layer: people follow steps and still get it wrong.
3. Or nobody acts without checking with one particular person.
4. Start with the situations, not the steps.
5. What kinds of thing happen here, and how is each kind handled?

What ruins it: Writing more procedures. Steps tell you what to do; they don't tell you which situation you're in.

1. Stop asking for creative, better, or more engaging.
2. Give it a number of options and make them differ deliberately.
3. Two conservative, two that would make legal nervous, one that assumes trust.
4. Say what would count as wrong.
5. Constraints are what make output specific.

What ruins it: Asking for creativity. It has no failure condition, so anything satisfies it — which is why everything comes back average.

1. When something works, spend one more minute on it.
2. Ask why it worked, with no reference to the tool.
3. Write that sentence down instead of the prompt.
4. Patterns transfer to the next tool. Prompts don't.
5. In two years the tool is gone and the sentence still holds.

What ruins it: Saving prompts instead of patterns. Tool-specific knowledge decays in months.

1. Treat the first output as a draft from someone who's never met you.
2. Say what's wrong with it, specifically.
3. Say what you actually meant.
4. Ask again. Then once more.
5. The third round is usually the useful one.

What ruins it: Accepting it or discarding it. Both come from treating the output as a verdict rather than a probe.

1. Expect the first output to be wrong. That's the design.
2. Correct it specifically: not that, because we can't commit to a date.
3. Each correction surfaces a criterion you never stated.
4. By round three you've externalised requirements you didn't know you had.
5. Keep the corrections — they're the real output.

What ruins it: Accepting or discarding the first result. The disagreement is where your tacit criteria become explicit.