4.2.2 - Decide What Reaches You Before Everything Does

Decide which work runs unattended, what hands itself back to a person and what that person actually receives when it does.

Escalation

What is allowed to carry on without you? What has to stop and wait?

The call

Draw the line between what runs unattended and what comes to a person, then say what that person is handed when it does. Draw it while nothing is on fire.

Sharpen escalation with AI

This is a Run idea, so the AI move is Run it for real. You can sharpen the decision here, but it only proves out against a system that is actually live.

New here? Let your AI do this with you. Paste your problem into Guide me and it builds a prompt that walks you through this in ChatGPT or Claude. You do not need to know how to prompt.

Prefer to drive the AI yourself? Give ChatGPT or Claude this page and ask it to help. For skill.txt, the Claude Code plugin and other ways in, see how to use vibe2value.

Or copy this prompt into AI chat, replace the bracketed lines with your real line and keep the instruction exactly as visible here. It helps you put your escalation.md together by refining your three lines until somebody who did not build this could act on them.

You are checking whether this escalation line is clear enough before you move forward.

Constraint:
You must be able to say which work runs unattended, what hands itself back to a person and what that person receives when it does. "Someone looks at everything" is not a line.

Example of the standard:
Vague: "We keep an eye on it and step in when something looks off."
Sharp: "Capture, storage and the digest all run unattended. A bounce, a failed run or a sender whose log has nothing new stops and comes back to me as one email naming the sender and what stalled. Nothing else interrupts me. Everything else runs unattended and we read the weekly digest."
The sharp version says what carries on, what stops and what the person is holding. The vague one relies on somebody noticing.

Working draft:
Runs unattended: [what carries on without anyone]
Hands back to a person: [what stops, plus what triggers it]
What the person receives: [what they can act on immediately]

Task:
Decide whether the line is real. If the answer is that a person checks everything, that is not a line, it is the absence of one. The honest move is to name what should run unattended and start there.

Check:
- Is the line written down anywhere, or does it live in one person's head?
- When something hands back, does the person get enough to act, or do they have to reconstruct it?
- Is anything running unattended that you would not have chosen?

Return:
- Verdict: clear, or needs work
- The corrected three lines
- Anything running unattended by accident rather than by decision

Copy this into AI chat. Replace the bracketed parts. Keep the rest unchanged. AI will likely suggest refinements based on what you enter. Use those to sharpen your thinking, not replace it.

Where the line sits is the decision. Working either side of it is the craft. That is Know when to step in, Where a person should look plus How much to let AI decide.

The same idea on a recipe card

The pass is the line in a kitchen. Most plates go straight out. Some stop, because the chef decided in advance which ones do: anything for the big table, anything already sent back once.

The rule exists before service starts. That is the whole point of it. Nobody is making that call while six plates go cold, because it was made on a quiet Tuesday by somebody who had time to think.

The recipe card is just a simple example, using everyday cooking ideas everyone understands, to make the concept clear. See the recipe card.

What it really means

AI has made running things unattended almost free. Free things spread. So the number of jobs running with nobody watching goes up quietly, one convenience at a time, until it is most of the system.

The default is not no line. The default is a line that got drawn by accident, out of whatever was easiest to automate first. That is different from the line you would have chosen. You only find out which one you have when something goes through it.

The other half is what arrives. Something that stops and hands back is only useful if the person receives enough to act. A notification saying a job failed, with no context, has moved the work rather than escalated it.

Make escalation concrete

Compare the version that sounds responsible with the version somebody could act on.

Too vague: We keep an eye on it and step in when something looks off.
Concrete enough to act on: Capture, storage and the digest all run unattended. A bounce, a failed run or a sender whose log has nothing new stops and comes back to me as one email naming the sender and what stalled. Nothing else interrupts me.

The second version tells a person what will reach them and what they will be holding. The first relies on somebody noticing.

Both versions come from consideredContent, the one project carried through all 35 ideas. See the project.

Work meets a line you drew while nothing was on fire. What stops goes to a person with enough to act on. What does not, carries on. Without a written line you get one of the two failures instead: everything runs unattended, or you end up checking all of it.

Check escalation

Pass: You can say which work runs unattended, what hands it back and what a person receives when it does.
Fail: The line exists only in someone’s head, or it is "a person looks at everything".

A line nobody has written down is not a line. It is a habit.

What you'll walk away with

This post is about the running decision: what has to be true once the thing is already live. You'll come out with your own knowledge-base/system/running/escalation.md written and sharpened: what runs unattended, what stops and why, what the person is handed when it does and an honest list of anything running without you that you did not actually choose.

Write it down

Your escalation.md is a real file in your project. The AI forgets everything between sessions. It reads this file each time to pick up what you already decided, on this idea or another part of the build. Write it down once instead of explaining it again.

knowledge-base/system/running/escalation.md is just a suggested name and place for this information. Call the file and put it wherever suits your project. What matters is that it is written down in a format that is easily understood by both people and the AI.

Risk and mitigation

Risk: Work runs unattended because nobody drew the line rather than because you chose it. You find out from a customer.
Mitigation: Name one thing that must always stop and wait, plus one thing you are happy running without you. The rest of the line follows from those two.

Key takeaway

Decide what reaches you before everything does, then say what it hands you when it arrives.

How to document your escalation

Write it up in full so your AI has the whole picture: the answer, why you believe it, what you are optimising for, where you might be wrong and the standing instruction it should follow. Keep it in a file with your project like this.

# Escalation

## Answer
Runs unattended: [what carries on without anyone]
Hands back to a person: [what stops, plus what triggers it]
What the person receives: [what they can act on immediately]

## Evidence
What has reached you in the last month and what you wish had.

## Decision
What you are optimising for and what you are accepting runs without you.

## Risk
What breaks if this is wrong.

## Standing instruction
What the AI should do every time it touches this. For example: when you add a job that can run without a person, say which side of the line it sits on and what it hands back if it stops.