.svg)
The first step of the build — an honest, domain-by-domain picture of where company knowledge actually lives.
Part two of the Company Brain series. How to trace a question to its real source, list your domains, and read the three failure patterns a map reveals. About six minutes to read.
01 Trace one question through your company
This is part two of the Company Brain series. Part one covered what a company brain is and why you need one — one source of truth per domain, reachable the same way by people and AI. This piece is the first step of building it: Map. Every later step is a decision made on top of what this one finds, so before you clean, connect, automate, or govern anything, you need an honest picture of where your company's knowledge actually lives today.
Part one opened with a question every company should be able to answer: who is this customer, and what did we agree with them? Now try to answer it for real — not from memory, but by going to find where that answer actually lives in your company today. Chances are it isn't one place.
A CRM record, partly filled in. A folder of agreements, several versions, no marker for which one is current. And the account owner, who actually knows the state of the relationship — because they're the one in the room.
That's not one company's problem. Run the same trace on any domain — finance, legal, recruiting, delivery — and you get the same shape of answer: a system that's partly right, a person who's fully right, and documents nobody's checked against either. Mapping is doing that trace on purpose, domain by domain, instead of discovering it by accident when the wrong answer costs you something.
02 List every domain before you trace any of them
A domain is a bounded area of company knowledge with its own rules — its own owner, its own definition of what counts as true. Ours run: accounts, finance, recruiting, people, sales, projects, legal and contracts, design system, operations, and frameworks and best practices. Yours will look different — add or split domains until the list matches how your company actually organizes work.
You can't map what you haven't named. List the domain first; trace it second.
03 Ask the same five questions of each one
For every domain on your list, ask:
— Where does the answer live today — which systems hold it?
— Who would you actually ask if the system turned out to be wrong?
— If more than one place has an answer, which one wins?
— When was it last confirmed accurate — not created, confirmed?
— If something changes here, does anything else update automatically, or does someone have to remember to do it by hand?
Run the customer question through these five and you land on exactly the three-way split above: CRM for where, the account owner for who — reliably — the agreements folder for which one wins — unreliably — and never, formally, for when it was last confirmed. Five questions, asked domain by domain. That's the entire method.
04 Keep the first pass to facts, not the full picture
Treat this first pass as an MVP, not an archive. You're after the basic facts nobody would argue with — not the full context behind them. That this account renews in March, at a given value, is a basic fact — arguable only if the record's gone stale, which is exactly what mapping catches. A recording of the renewal call is not a basic fact. It's supporting context: useful, but it can misrepresent what was actually agreed, and treating it as a source of truth just moves the ambiguity somewhere harder to check. The same goes for email threads and chat history — evidence a conversation happened, not a record of what was decided.
Supporting context is not a source of truth
Note where it lives, so you know it exists, then leave it out of this pass. Basic, non-arguable facts on the table is the definition of done for a domain's first map.
05 What usually goes wrong
Do this honestly across ten or fifteen domains and the same three patterns show up every time.
— No source of truth, only a carrier — the knowledge exists, but only in someone's head. This is the one that matters most for AI: every question in that domain means re-explaining context from zero, and the answer is only as good as what you remembered to include.
— Systems that don't talk to each other — a change on one board doesn't trigger an update on the related one it should be connected to. Two systems that look like one system quietly drift apart.
— Multiple live versions, no pointer to current — three agreements, all plausible, and the only reliable answer to which one is signed is asking the account owner directly. The map isn't in the document — it's in one person's head, which means it isn't a map at all.
None of this is a failure on your team's part. It's what happens by default when nobody's explicitly decided where an answer lives — and mapping is the first time most companies see the pattern laid out, instead of felt as a vague sense that the data's a mess.
06 Know when a domain is mapped
The output isn't a fix — it's a list. For every domain: where the facts live, who the carrier is, whether it's reliable, which pattern applies. It doesn't clean anything up and it doesn't pick a winner between three agreement folders. What it does is turn "our data is a mess" into a specific, domain-by-domain statement of fact you can act on — and it's the direct input to step two, Clean, where each domain gets a named owner and one source of truth. You can't make that call until you know, precisely, what you're choosing between.
07 Four questions this raises in practice
Which domain do you map first?
Not all of them at once — map one domain at a time. Need and enthusiasm decide the order, nothing else does: pick the domain costing you the most real time, with an owner who wants it fixed. Success there is what gets the rest of the company to trust the process.
What tool do you use to build the map?
Nothing sophisticated — a shared board or spreadsheet is enough, one row per domain, columns for where it lives, who the carrier is, which pattern applies. We're mapping our own domains the same way right now, on one shared board, no dedicated software. The tool matters far less than doing the exercise.
The carrier won't just hand over what they know. What do you do?
Vague requests don't produce knowledge; named gaps do. Identify the exact components missing from the domain and assign them as a direct task. If writing it up is the friction, a voice tool like Wispr Flow — which turns spoken knowledge into organized text — can make it fast enough that it actually happens.
What about domains that overlap — a deal that touches both sales and legal?
Split it. Map the strictly-sales components and the strictly-legal components against their own domains. The deal itself bridges the two — it isn't a domain of its own, it's the record that points from one to the other.
Part 3 covers turning the map into a domain a named owner can trust — one source of truth, and the two ways ownership quietly fails.
Asaf Yosifov
Founder & CEO Asaf Yosifov
