Drawing the
Trail Mapbefore anybody builds it
You can build things now, and you can undo them. What limits you from here is not the horse. It is how clearly you can say what you actually want.
By the end of today you will be able to write one page that describes a job clearly enough to hand over — to an assistant, or to a person.
Presented by Emile du Toit
brainitconsulting.com
Here is an overview of the last two sessions in five lines.
- You have a folder and an assistant in it that reads, writes and runs things.
- It stops at every gate, and you are the one who decides.
- Your house rules live in the folder, so you stop repeating yourself.
- And since last time, every version is kept. A mistake is a step backwards rather than a rebuild.
- Which means the tools are no longer what is slowing you down.
Today we deal with what is.
Contents
- You got exactly what you asked forWhich is the problem.
- What a map isFive headings, one page — and what to leave out.
- Dale's map, in fullThe one to copy the shape of.
- Let it draw the map with youA real conversation, printed.
- The map lives in the folderAnd what to do when you change your mind.
Then the questions this always raises, the glossary so far, and the picture to photograph.
You got exactly what you asked for
Which is the problem, and it is nobody's fault but the sentence.
Dale asks for “something to track my estimates.” Twenty minutes later he has a thing that tracks estimates: every estimate he has ever written, in a tidy list, newest first, with totals. It works. It is well made. He opens it once and never opens it again.
What he wanted at six in the morning, sitting in the truck with the engine running, was which of these is waiting on me. Three names. That is all.
Nothing went wrong. He asked for the wrong thing, and he had no way of knowing it was the wrong thing until he saw the right thing missing.
This is the session where the limit stops being the tool. You have an assistant that can build, an editor to build in, and an undo if it goes badly. From here on, what you get is decided almost entirely by how clearly you said what you wanted.
Three things go wrong with a plain request, and they go wrong every time.
- Every word you left out, it fills in. You did not say “only the ones waiting on me”, so it had to decide, and it decided reasonably.
- It cannot see your Friday. It does not know this gets read on a phone, in a truck, before seven, by a man with one hand free.
- It will not tell you that you were vague. Not unless you ask it to — which is chapter four, and is the most useful sentence in this session.
“When I get in the truck I want to know which jobs are stuck on me. Not the ones I've sent — those are gone. The ones where somebody's waiting and I'm the reason. And if there's a gas one in there I want it at the top, because that's the one I can't sit on.”
Nobody asked. He would have said all of it in fifteen seconds.
You will get what you asked for. The skill is asking for the right thing.
What a map is
One page of plain English, written before anything is built.
You would not send a driver to a place he has never been with the words “head north, you'll see it.” You would draw him a map — not the whole county, just enough of it: where he is going, what he will pass, where the road is closed, and how he will know he has arrived.
A map here is one page describing a job well enough that somebody else could do it without you in the room. In the trade it is called a spec, short for specification, or sometimes a brief. Same thing. Five headings and about three hundred words.
“Spec” makes people write the wrong document. They hear specification, and within two paragraphs they are describing how to build the thing — which tables it needs, which buttons go where, which language it should be written in.
The more technical the person, the worse the habit, and it is meant kindly. They know how things get built, so they write down how. Then they hand over a page that has quietly settled every decision in advance, and they never find out whether there was a better way of doing it, because they never asked.
You do not tell a plumber which wrench. You tell him the sink is leaking under the cabinet, there's damp in the wood, and you'd like it done before Christmas.
Look back at session two. Look, decide, act, check — the loop. Deciding how is the part it is genuinely good at. Your part is what, and why, and what must never happen. Hand over the how as well and you have taken away the only bit it does better than you, and you now own every one of those decisions, including the ones you did not notice you were making.
If you have a real constraint — it must open in Excel because your accountant lives there, it has to work on the office computer that never gets replaced — that is not a how. That is a what, and it goes under heading two.
Describe the leak. Not the wrench.
1. What it is. One sentence, and who it is for. If you cannot finish this sentence, stop — that is the actual problem, not the building.
2. What it reads, and what it must never touch. Which files, which folders, which information. And then the nevers, plainly.
3. What you would actually see. Describe the thing itself. Not “a summary” — write out a line of it, the way it would really look.
4. How you will know it is right. Two or three things that must be true. “Tanner is at the top.” “Nothing I've already sent appears.”
5. What you are not sure about. The questions you cannot answer yet. This heading is the one people leave out, and it is the most valuable one on the page.
One page, on purpose. Longer than that and nobody reads it, including you in three weeks. If it will not fit on a page, you are describing three jobs, and three jobs want three maps and doing one at a time.
You are not writing this for a computer. Write it the way you wrote your house rules in session six — the way you would brief a capable new employee on their first morning. That is the same skill, and you already have it.
The map is worth more than the horse. Anyone can borrow a horse.
Dale's map, in full
The one to copy the shape of. The words are his; the shape is yours to steal.
Working example. This is the map for the thing Dale actually wanted — the list of estimates stuck on him — written before a single file was made. It is shorter than the description of it took.
What it is. One short list, on Dale's phone, of estimate requests that cannot move without him. Nothing else on it. When an estimate is written and sent, it drops off — there is nothing to mark as done.
What it reads. Three things already on the office computer: inbox/, the emails saved in each morning; past-estimates/, so it knows what has been done; and rate-card.txt and notes.txt, so it can tell a job we can price from one we cannot.
What it must never do. It does not read email. It does not send anything. It does not write the estimates. It does not price gas — it flags it and stops.
What you would see. Name, one line on the job, why it is waiting, and what would move it:
Tanner, 212 Wilbanks Rd — 4 days
Gas smell at the stove. We don't price gas. Call him.
Water heater's separate and quotable if you want it split.
How I will know it is right. Tanner is at the top, because gas beats waiting time. Alvarez shows as ready to price. Nothing already sent appears anywhere on it. No prices on this list — prices belong in the estimate.
What I am not sure about. How it knows a job is finished. Today the only signal is a file appearing in past-estimates/ with the customer's name on it — so if Alvarez calls again next spring about something else, the old file still has her name and the new email gets counted as already done. That is a job silently missing off the list, which is the one failure that actually costs money.
Three things to notice about it
- It says what the thing must not do as clearly as what it must. Half the value of a map is the roads you cross out.
- It writes out a real line of the output. “Tanner, 212 Wilbanks Rd — 4 days” settles a dozen small arguments that would otherwise be settled by whoever builds it.
- It names its own weakest part instead of pretending to be finished. That last heading is where the next conversation starts.
Half the value of a map is the roads you cross out.
Let it draw the map with you
You do not have to be good at this on the first morning.
Writing a map from a blank page is hard, and nobody should have to start there. The assistant will write it with you, and it turns out to be rather good at it — because the thing it is genuinely best at is noticing what you did not say.
There is one sentence that does it. Say the thing you want, then add:
“Don't build anything yet. Ask me what you need to know first.”
Say it every time until it stops feeling odd. Without it, it will start building, because that is what it was asked for.
Here is a real one, trimmed to fit the page. Dale's folder, the same one from session three, and the same one-line wish that produced the wrong thing in chapter one.
I want something that tells me which estimates are still waiting on me. Don't build anything yet. Ask me what you need to know first.
I read the folder first so my questions aren't generic. Here's what's here: three customer emails in inbox/, all unanswered as far as I can tell. One finished estimate in past-estimates/. Your house rules, and a rate card effective March 2026.
Worth flagging up front: nothing in this folder records state. There's no “I sent this”, no “I'm waiting on Brody to tell me the model”, no date on anything. The only signal available today is “there's a file in inbox/ and no matching file in past-estimates/”. That shapes most of the rest.
First question. When you say an estimate is “waiting on me”, which of these do you mean?
- A. Emails with no estimate written yet — the plain backlog.
- B. Ones I've started but can't finish without a decision only you can make. Tanner is the live example: his water heater is priceable, the gas stove isn't, so the whole job stalls on you.
- C. Ones where I need something from the customer first — Brody says “jammed and humming” with no model, and there's no address on his email at all.
- D. Ones I've sent that the customer hasn't replied to.
A, B and C are all “the ball is in your court”. D is the opposite. Which do you want counted, and is D in or out?
A, B and C. Leave D out — once I've sent it, it's off my list. And I look at this on my phone in the truck, first thing.
Good — that keeps it to one list: things you can act on.
The phone detail matters more than it might seem, so let me chase it. These three emails are sitting here as text files in a folder. Is that the real setup, or is it a snapshot someone made of what's actually in your email?
I ask because it decides who has to do something to keep the list current. If the folder is real, somebody is already saving emails into it by hand — and you'd be reading yesterday's picture in the truck unless they'd been in that morning. If it's standing in for your actual inbox, this has to read your mail directly, which is a bigger build and needs access to your account.
The folder is real — my daughter saves the emails into it every morning before she opens the office. Now write me the map: one page, plain English, no code, so I can check you understood before you build anything.
— and out comes the map in chapter three, plus three things it still needs from him: who runs it each morning and when, how it reaches his phone, and whether the inbox ever gets emptied.
What just happened
- It read the folder before it asked anything. The questions are about Tanner and Brody by name, not about “your workflow”.
- It found the hole Dale did not know was there. Nothing in that folder records what has been sent. Dale would not have thought to mention it, because it had never been written down anywhere in twenty years.
- The second question is the one that matters. “Is this folder real, or a stand-in for your email?” Dale had never once said which, because to him it was obvious. It was not obvious. It changes what gets built.
Four questions and about three minutes of typing, and what came out of the other end is the map in chapter three — including the part where it names its own weakest point without being asked. That is the same one-line wish it started from.
The button that does this for you
Both assistants have a setting for it, and it is worth knowing the name because everybody uses it. It is called plan mode: it works out what it would do, writes the plan down, and shows it to you without touching a single file until you say go.
- Claude Code. Press Shift + Tab to cycle the mode until it says plan. Same key cycles back.
- Codex. Ask it for a plan first and read it before approving. Same idea, one step less formal.
Plan mode and the sentence above do the same job. The sentence works everywhere and costs you nothing to remember, so start there.
It is not that it cannot read your mind. It is that nobody ever asked you the questions.
The map lives in the folder
And what to do on the day you change your mind.
A map that lives in your head is not a map. Save it as a file in the project folder — call it spec.md, or map.txt, or anything you will recognise — right next to the house rules you wrote in session six.
Three things follow from it being a file, and all three matter more than they sound.
- It is still there in three weeks, when you have forgotten why you decided the sent ones drop off the list.
- You can point at it. “Read
spec.md, then build the first part of it” is a better instruction than anything you will type from memory on a Tuesday. - It gets marked, like everything else. Which means that in a month you can read how your own thinking changed, in your own words, with the dates on it.
When you change your mind
You will, and quickly — usually the moment you see the first version. There is a right way round and a wrong way round.
Argue with the build. Six messages later nobody can say what the thing is meant to do, including you.
no, not like that
put the gas ones first
actually take the prices off
Change the map, mark it, then ask again. One message, and the reason survives.
I've changed spec.md - gas jobs go
at the top regardless of how long
they've waited. Read it again and
rebuild the list to match.
The map is the thing you argue with. Once it is right, the building is the easy part — and if it comes out wrong anyway, you have a marker to step back to and a page to point at.
Now write one
Ten minutes, on the thing you brought with you. Paper is fine — better than fine, actually; nobody types their first one well.
- Write the first sentence. “It is a ___ for ___ that ___.” If you get stuck here, that is the finding, not a failure.
- What does it read? Where does the information come from today — a folder, a notebook, somebody's head?
- What must it never do? At least two. There are always two.
- Write one real line of what you would see. Not a description of it. The line itself, as it would appear.
- Two things that must be true for you to call it right.
- Then the last heading: what you are not sure about. Write down the questions even if you cannot answer any of them.
- When you get home, type it into
spec.mdin a folder, open the assistant there, and say: “Read this map. Don't build anything yet — tell me what's missing from it.”
There is an empty map with the five headings on it, and Dale's finished one beside it, in the class folder: github.com/brainit-consulting/ai-workshops
Pick end-of-008 from the dropdown, then the green Code button and Download ZIP. The template is trail-map-template.md.
Step seven is the one that teaches you the most, and it takes two minutes. Almost nobody's first map survives it intact, and that is the point.
Questions people actually ask
Seven that come up every time this session is taught.
Isn't this just more work before I get anything?
Ten minutes with a map beats an afternoon riding the wrong way.
It is about ten minutes, and it is the ten minutes that decides whether the next hour was worth having. The cost of skipping it is not that you get nothing — it is that you get something plausible, use it twice, and quietly stop.
What if I don't know the answers to my own questions?
An unmarked stretch of map is still worth drawing.
Write “I don't know” and move on. That is what the fifth heading is for. A question you have written down is a thing you can go and find out on Thursday; a question you never noticed is the reason the thing gets rebuilt in March.
How long should it be?
One page. A map you have to unfold twice is two maps.
One page, around three hundred words. If it genuinely will not fit, you are describing more than one job — which is useful to have discovered. Split it, and build the first one.
Should I say which database, or which language to build it in?
You choose where you are going. It knows the ground better than you do.
Almost never. If you have a genuine reason — everything else you own is already in one place, or your bookkeeper needs it to open in Excel — write that down as a thing it must do, under heading two. If you are only saying it because it sounds like the sort of thing a spec should say, leave it out and see what it suggests. You can always disagree afterwards, and by then you will know why.
Do I have to write it, or can it?
It can draw the map. You still have to know the country.
It can write most of it, and chapter four is how. But you have to read it back and correct it, and that part cannot be handed over — you are the only one in the conversation who has ever sat in the truck.
Is this the same as a contract or a statement of work?
A map is for the riding. A contract is for afterwards.
Related, but no. A contract is about who owes whom what if it goes wrong. A map is about making sure it does not. If you are hiring somebody to build this, a good map makes a far better contract possible — but write it for yourself first.
What if it builds something different from the map anyway?
Then the map had a road on it you did not mean to draw.
Nine times in ten the map was ambiguous and you can see exactly where when you reread it. Fix that line, mark it, ask again. And you have an undo now, so the wrong version costs you nothing but the ten minutes.
Plain words
Everything the series has named so far. Today's are marked.
This list grows every session and always shows the lot, so you never need last week's handout to read this week's.
- Large language model (LLM) 001
- The engine that predicts the next word. The horse.
- GPT 001
- Generative — it makes new text rather than looking up a stored answer. Pre-trained — all its learning happened in advance. Transformer — the design of the machinery underneath. A breed name, not a job title.
- Knowledge cutoff 001
- The date its training stopped. It knows nothing after it, and doesn't know that it doesn't. The last day the horse was out in the world.
- Prompt 001
- What you type. A pull on the reins.
- Chatbot 001
- A model you can talk to, turn by turn. Horse plus bridle.
- System prompt / instructions 001
- Standing orders sent with every message, whether you type them or not. The saddle.
- Context window 001
- How much of the conversation it can hold at once. How far it can see on this ride.
- Token 001
- A chunk of a word — how length is counted, and how you're billed. Sugar cubes.
- Hallucination 001
- Making something up and sounding certain. Shying at a shed snakeskin.
- Tool 002
- A specific action it's allowed to take in the real world. A saddlebag.
- MCP 002
- An agreed standard for plugging tools into a model. Standard-size buckles.
- Agent 002
- A model given a goal, tools, and permission to keep going. A working horse, not a show pony.
- Agentic loop 002
- Look, decide, act, check, repeat. The ride itself.
- Human in the loop 002
- A person approves before something real happens. A hand on the reins.
- Automation 002
- The same work happening without you starting it each time. The horse knows the route.
- File 003
- A thing with a name and contents. A single piece of gear.
- Folder (directory) 003
- A box holding files, and sometimes other folders. A shelf.
- Project 003
- One folder holding one job's worth of everything. The room, with the door shut.
- Path 003
- The written address of a file — which boxes it sits inside. Directions to the shelf.
- Editor (VS Code) 004
- A window showing you one folder and everything in it. The tack room.
- Terminal 004
- A panel where you type an instruction to the computer directly. Talking to the stable itself.
- Install 004
- Putting a program on your own machine, once. Building the room.
- Permission prompt 005
- The stop before it changes anything, showing what it plans to do. The gate, and your hand on the latch.
- Approval mode 005
- Whether it asks every time, works on its own, or only shows a plan. How loose you're holding the reins.
- Interrupting 005
- Stopping it mid-job with the escape key. A pull on the reins. Ordinary.
- Project instructions 006
- A plain-English file of standing rules that lives in the folder. The saddle, hanging in the room.
- Run a command 006
- Doing something on the computer rather than writing words about it. Actual work, not conversation.
- Working on copies 006
- Duplicating a file so the original can't be harmed. Schooling in the paddock, not on the road.
- Version control 007
- Keeping every previous version of everything, so any of them can come back. A trail you can ride back.
- Git 007
- The program that keeps the trail. It runs on your own machine. What drives the markers in.
- Commit 007
- One marker, with a short note saying what you had just done. A gate you can ride back through.
- Repository (repo) 007
- A folder that keeps its own history. The field, with the trail marked in it.
- GitHub 007
- A copy of the repository kept online — a real backup, and a way to hand it to somebody. The shared stable at the trailhead.
- Push and pull 007
- Sending your markers up to that copy, and fetching down anything that is there and not here. Riding to the trailhead and back.
- Spec (brief) 008
- One page describing a job well enough to hand it over. What it must do — not how to build it. The trail map. Where you are going, not which foot the horse leads with.
- Scope 008
- What is in this job, and what is deliberately not. Where the map stops. The country past the edge is not today's ride.
- Acceptance 008
- How you will know the thing is right when you see it. How you know you arrived.
- Plan mode 008
- A setting where it works out what it would do, and shows you, before touching anything. Reading the map aloud before anyone mounts up.
- Assumption 008
- Something you took to be true and never checked. A stretch of map you drew from memory rather than from riding it.
Everything on one page
If you photograph one thing today, photograph this.
1 · One sentence, three roads
All fair readings. One of them is the one you meant.
2 · Five headings
One page. The last one is what you are unsure of.
3 · Make it ask you
“Don't build anything yet. Ask me what you need to know.”
4 · The well
One well, many troughs. Where the information actually lives.
The habit that carries all of it: before you ask for anything you would be annoyed to get wrong, say what it is, what it reads, what it must never do, what you would see, and how you will know. Ten minutes. Then let it ask you what you left out.
#009 — The Well
Every map you have just written points at the same awkward question: where does the information actually live? For Dale it is a folder of text files his daughter fills in each morning, which works until two people need it at once, or he wants it on his phone without her being at her desk. Next time we dig a well — one place the information lives, that everything else draws from.
Before you come: bring the map you wrote today, and underline the line that says where the information comes from.
I do this for a living, and love to help people.
Thirty-plus years in enterprise software and a computer science degree — which mostly means I have watched a great many horses bolt, and I can usually tell you which ones are worth saddling before you spend money on the saddle.
In person
Your team, your room, your actual work on the whiteboard instead of somebody else's examples.
Over video
The same session, at your desks, with fewer chairs to stack afterwards.
Built for real
When the idea survives the workshop and somebody has to go and build the thing — that part I do too.
Fun fact — I rode to school on horseback as a kid in South Africa. So the metaphor isn't borrowed. I've done the falling off in person.
Emile du Toit brainitconsulting.com
Workshop #008 · Drawing the Trail Map
© 2026 Emile du Toit, BrainIT Consulting
Print it, download it, share it with your team. Just leave my name on it.