How to Map a Domain: The Six Layers

The hardest part of mapping a complex domain is not the domain. It is the blank page.

You know the feeling. Something in front of you has grown too big to hold in your head, and you decide, finally, to draw it. You open an empty document. And then nothing happens, because there are a thousand true things you could write about this thing and no obvious reason to write one before another. So you either give up, or you produce a list that is really just the inside of your panic transcribed onto the screen, and the panic was the problem you were trying to solve.

The six layers are the cure for the blank page. They are the six questions I have learned to ask of any domain, in roughly this order, and they turn "map this impossible thing" into six small, answerable jobs. I wrote the field itself up separately, in domain cartography; this is the working manual for the method. None of these layers is clever. Run together, they are what turns an overwhelming pile into a map you can actually move with.

Layer 1. Primitives: what is here?

Start by naming the pieces. The objects, the entities, the roles, the systems, the accounts, the people. Not what they do yet, not how they relate. Just an inventory of what is actually in the domain.

This sounds too simple to matter, and it is the step almost everyone skips, and skipping it is why so much complexity feels infinite. An un-inventoried domain has no floor. It feels like it could contain anything, because you have never made it say what it contains. The moment you write the list, the thing stops being a fog and becomes a countable set of parts. Thirty-one repositories, not "all my projects." Four accounts, not "my money." Almost always the real number is smaller than the dread.

How to do it: write the flat list, fast, without organizing. Do not stop to sort or judge. You are trying to hit the bottom of the pile, and the only way to know you have hit it is to keep going until you stop finding new things.

The failure mode: you confuse activity with inventory and never finish the list, so every later layer floats on top of a domain you only half-named.

Layer 2. Forces: what moves it?

A list of parts is a still photograph. Forces are what make it a system. Ask what is pushing and pulling: the incentives, the constraints, the flows, the pressures, the things that pull effort toward some parts and away from others.

Every domain has a small number of forces that explain most of the motion. Money flows toward what already works. Attention has gravity, and the things that have it get more of it. Deadlines bend everything near them. If you can name the three or four real forces in a domain, you can usually predict where it will drift next without tracking every part, because the parts are not moving on their own. The forces are moving them.

How to do it: for each force, finish the sentence "this gets more of my time or money or attention because ___." If the answer is a real pressure, you have found a force. If the answer is "I am not sure," you have found a part of the domain you do not actually understand yet, which is also useful to know.

The failure mode: you map the parts and stop, and your map is a museum. It tells you what exists and nothing about what is about to happen.

Layer 3. Boundaries: what is inside, and what is not?

Now draw the edge. What is in scope, what is deliberately out, where the seams and interfaces are, what you are choosing not to hold.

This is the layer that protects you, and it is the one people treat as optional. Choosing the boundary of a map is choosing what you are responsible for. Without it, the domain has no edge, which means it has no end, which means it expands to fill all the room you have and then keeps going. A boundary is not a confession of weakness. It is the thing that makes a map finite enough to read and a job small enough to finish.

How to do it: state out loud what is not on this map. "This map is my active work; archived projects are a different map." "This is my money this quarter; estate planning is elsewhere." The exclusions are as much a part of the map as the contents, and naming them is what makes the contents trustworthy.

The failure mode: no stated edge, so the map quietly grows until it is as overwhelming as the territory it was supposed to tame. A map the size of the world is not a map.

Layer 4. Feedback: what loops?

Domains do not just sit there. They respond to themselves. Look for the cycles: the loops that reinforce and accelerate, the loops that balance and hold steady, and the slow drift you only notice looking back.

This is where the levers hide. The repository that gets attention because it works, and works because it gets attention, is a reinforcing loop, and if you want to change its trajectory you push on the loop, not the repo. The habit that funds the habit. The maintenance you defer that creates the fires that eat the time you needed for maintenance. Find the loops and you stop treating symptoms, because you can finally see the thing generating them.

How to do it: take any two parts and ask whether one feeds the other, and whether that comes back around. Trace it until it either closes into a loop or runs off the edge of your boundary. The closed ones are your real control surface.

The failure mode: you treat a loop as a one-time event, fix the symptom, and watch it regenerate, because the loop that produced it is still running untouched.

Layer 5. Governance: who decides?

Even a personal domain has governance. Ask who or what holds authority here: the rules, the ownership, the escalation path, the answer to "when this is in conflict, who decides?"

When a domain feels chaotic, it is often not under-mapped. It is un-governed. There is no standing answer to who gets to decide, so every decision is relitigated from scratch, every time, under load. In a team this is obvious. In a personal domain it is sneakier, because the governor is you, and "you" is not one stable thing. You on a clear morning and you at midnight are different governors with different rules, and a domain with no governance defaults to whichever one is holding the pen at the worst moment.

How to do it: for the important parts, write the decision rule before you need it. "Archived repos do not get feature work, full stop." "No new position without bounded downside." Governance is just decisions made once, in advance, in calm, so they do not have to be made again in panic.

The failure mode: you map everything and govern nothing, so the map describes a domain that still runs on mood.

Layer 6. Levels: what changes when you zoom?

The same domain looks like different things at different distances. Up close it is a taxonomy, a list of named parts. At mid-range it is relationships, parts wired to parts. From far away it is dynamics, the whole thing moving as one. A finished map can move between these altitudes without changing tools.

This matters because the answer you need usually lives at a different zoom than the question you asked. "Why does this keep breaking" is asked at the level of one part and answered at the level of the loop it sits in. "What should I even be working on" is asked at ground level and answered from altitude. A cartographer who is stuck on one zoom is reading a street sign and wondering why it will not tell them which country they are in.

How to do it: deliberately describe the domain three times, at three distances. One sentence from orbit, a paragraph from mid-range, the full inventory on the ground. If you can only do one of the three, that is the zoom you are trapped at, and the trap is worth knowing about.

The failure mode: single-altitude vision. Either lost in detail with no overview, or floating in abstraction with nothing concrete underneath it.

How the layers compose

You do not always need all six, and you rarely run them cleanly in order. In practice you do a rough pass over primitives and boundaries just to get a floor and an edge, then the others pull on each other: naming a force reveals a loop, drawing a loop exposes a missing governance rule, governing a part makes you redraw the boundary. The list is not a pipeline. It is a checklist you circle back through until the map stops surprising you.

And two rules hold across all of them. Every map is provisional, because the territory moves and a chart you refuse to redraw becomes a lie you are loyal to. And every map is for action, because the test of a map is never how complete or beautiful it is. The test is whether, looking at it, you can see the next move. If you cannot, you have not made a map. You have made a picture of the problem.

If you want to see the six layers run on a real, messy domain instead of described in the abstract, I did exactly that to my own sprawl: why thirty-three repositories needed a census. That is the method with the mud still on it. This page is the manual. That one is the field.