> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kowalah.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Building your model from nothing
> Start from an empty operating model and build it in Claude, from the documents your organization has already written, rather than from memory.
[Your operating model in Claude](/integrations/mcp/operating-model) assumes a map already exists. This page is the other case: your model is empty and you are the one filling it.
That is the normal starting point if you signed up through the plugin without a Kowalah engagement. You land in your own organization as its admin, with a root unit and nothing under it. As an admin you are a cross-cutting editor, so you can author the whole map.
If your organization already works with Kowalah, your map is built with your Kowalah team during discovery and the Vision Map Workshop, and you should not start authoring over the top of it. See [Operating model setup](/platform/operating-model/setup) to work out which case you are in.
## Gather before you build
The slowest way to do this is to describe your business from memory. Most of what you need has already been written down by someone in your organization, usually for a completely different reason, and Claude can read it.
| Source | What it gives you | Who has it |
| -------------------------------------------- | ------------------------------------------------- | ------------------------------------------- |
| Org chart export from the HR system | The unit tree, headcount, who leads what | HR or People Ops |
| The last big systems implementation | Process maps, as-is and to-be | IT, or whoever ran the ERP or CRM programme |
| ISO, SOX or internal audit documentation | Processes with controls and named owners | Risk, compliance, finance |
| IT service catalogue | What each function runs on | IT |
| Job descriptions | Tasks and responsibilities, function by function | HR |
| Onboarding and training material | How the work is supposed to be done, step by step | L\&D and team leads |
| The month-end close checklist | A finance process already broken into steps | Finance |
| RPA or automation documentation | The repetitive work, already identified | IT or the automation team |
| An operating model review from a consultancy | Often most of a map nobody actioned | The executive who commissioned it |
| Recorded discovery calls | Your own conversations, already transcribed | Your notes or meetings tool |
When you ask colleagues for these, ask for the specific artifact rather than the general picture. "Do you have a process map or an SOP for the month-end close?" gets a yes far more often than "tell me how Finance works". Ask for whatever exists rather than whatever is current: correcting a three-year-old map is faster than authoring from blank.
## Point Claude at it
The Kowalah connector is not the only one in your conversation, and that is the point of building here rather than in the platform.
**Use your other connectors.** If Claude already reaches your Google Drive, OneDrive, SharePoint, your CRM or your call transcripts, let it find the material rather than hunting for files yourself.
```text theme={null}
Search our SharePoint for anything that looks like a process map, an SOP
or an org chart for Finance, and tell me what you found before reading
any of it in detail.
```
**Upload the rest.** Anything not connected, or anything sensitive enough that you would rather it were not in a shared drive, goes straight into the conversation.
### What lands where
The document stays in your Claude conversation. What is written into Kowalah is the **structure** you and Claude derive from it: unit names, process names, the steps, each step's input and output artifacts, its acceptance criteria and its disposition.
There is no upload path into the operating model. No tool in the connector accepts a file, and none stores one. A sensitive SOP, a draft reorganization chart or a set of call transcripts can inform the map without becoming part of it.
## Build the org tree
```text theme={null}
Here's our org chart. Build the unit tree from it, top two levels only,
with the leader and approximate headcount for each. Ask me where it's
ambiguous rather than guessing.
```
Two levels is usually the right depth to start. Deeper produces a tree you maintain instead of a map you use, and you can push into a unit later when you map its processes.
The org chart is the reporting line, not how work flows. Order to cash runs through Sales, Operations and Finance, and the chart will not tell you that. Let processes cross units rather than forcing them into one.
Add the units you are not mapping yet anyway. A tree with eight units and one filled in makes the gaps visible, which is what tells you where to go next.
## Build a process from its documentation
```text theme={null}
Here's the month-end close checklist. Turn it into a process under
Finance with its steps. For each step capture what goes in, what comes
out and who does it. Flag anything the document doesn't tell you.
```
**The flags matter more than the steps.** A checklist gives you the order of operations and rarely tells you how long a step takes, who covers it when the owner is away, or what happens when it fails. That list of gaps is the agenda for your conversation with the team, and a better opening than an empty page.
### Where documentation runs out
Every documented process has undocumented reality around it, and some processes were never written down at all. Talk those through instead:
```text theme={null}
The checklist stops at "reconcile intercompany". Walk me through
capturing what actually happens in that step. I'll describe it and
you capture it.
```
Record the real version rather than the documented one. If a step happens in a spreadsheet one person maintains and the SOP says it happens in the ERP, record the spreadsheet. The gap between the document and the practice is usually where the value is.
## Then read what you built
Once a function is mapped, the [conversations on the main connector page](/integrations/mcp/operating-model) start working: coverage rollups, the redesign backlog, which steps could move disposition this quarter. Those are the questions you built the map to answer.
## What the connector will not do here
* **Delete anything.** No unit, process, step or eval can be deleted through the connector
* **Accept a file into the model.** Documents inform the map through the conversation; they are never stored in it
* **Set Kowalah-side ownership**, link processes to deliverables or projects, or wire up implementation links. Those are structural edits your Kowalah team makes on an engagement
* **Check your map for you.** A model one person built is that person's account of how the business runs. It becomes reliable when the people who own those processes confirm their own, which is what adding them to your organization is for
Reading, interrogating and refining a map that already exists
How the map gets built on each route, and setting positions and home units
Every connector tool and what it returns
Add the Kowalah plugin and connector to Claude