One is the company you'd describe if I asked — the one on your site, in your deck, in the story you tell new hires. The other is the company your customers actually pay for. They're not the same. They drift further apart every year you operate. And you almost certainly can't see the second one — because you're standing inside the first.

A fleet-safety company sells fewer accidents. Follow the renewals, though, and a different business appears: customers stay for the dashcam footage — the clip that proves their driver wasn't at fault when the lawyer shows up. One exonerating video is worth more than a year of subscription. They're not buying safer drivers. They're buying litigation defense. Same company. Two businesses. Only one is on the marketing site.

That gap is the most expensive thing you can't see. It forms predictably, compounds quietly, and — as everyone races to bolt AI onto the company they describe — it's about to get far more expensive. So it's worth learning to read.

The stated company and the operating company

Every business runs on a story about what it is: what it sells, who it's for, why it wins. The founder tells it on the about page, in the raise, to every new hire on day one. It is mostly sincere and it is rarely current. Call it the stated company.

Underneath runs a second company, defined not by what anyone says but by what the business actually does — where revenue is sticky, what customers refuse to give up, which feature renewals quietly depend on, where the real switching cost lives. Call it the operating company. It is the company your customers experience and pay for, whether or not anyone has named it.

The stated company is the story. The operating company is the truth. Strategy is built on the story.

When the two are aligned, the business is coherent: every decision pushes in the same direction and compounds. When they drift apart — and they always drift, because the story is written once and the operation evolves every day — the company begins paying a tax that never appears on any statement. It shows up only as a strange, persistent friction: good people, real effort, decent execution, and somehow less leverage than the inputs should produce.

Why the gap forms (it isn't carelessness)

The gap is not a sign of a sloppy founder. It is produced by four forces that operate on good companies, quietly, over time.

The origin story calcifies. The founder's original thesis — the reason they started — becomes the official identity and stops being re-examined. The company keeps describing itself with the sentence that was true at the seed stage, long after the operation has moved on.

The market re-purposes the product. Customers are relentless and inventive; they find the job your product does best for them, which is frequently not the job you built it for. They adopt you for a reason you never advertised, and they tell you about it only obliquely — through usage, renewals, and the support tickets you find slightly embarrassing.

Success hides the truth. This is the cruel one. When the company is growing, the growth gets credited to the stated story, because that's the story everyone's looking at. The operating company does the work; the stated company takes the bow. Nobody investigates a win.

The org chart hardens into reality. Teams get built around the stated company — the roadmap, the titles, the metrics — and then those teams defend the frame that justifies them. The structure becomes self-confirming. To re-read the company would be to re-draw the org, so the company quietly agrees not to look.

None of these require a mistake. They are what happens to a company that is busy operating. Which is exactly why the founder can't see the gap unaided: every force that creates it also creates a reason not to examine it.

Three companies that aren't what they say

Once you have the shape, you start seeing it everywhere. Three quick reads:

A B2B accounting tool sells save your accountants time. Follow the operation: the feature that drives renewal isn't the automation — it's the audit trail, the thing that lets the senior partner verify the junior partners actually did the work and catch it before the client does. Strip the time-saving and a few users grumble. Strip the audit trail and the partner cancels. They are not selling efficiency. They are selling oversight. Time is the story; control is the product. And notice what that means: the buyer is the partner, not the accountant who uses it — which changes the entire go-to-market, if anyone reads it correctly.

A "team productivity" platform sells collaboration. Follow the operation: adoption is pushed by managers, every dashboard points upward, and the sticky surface is visibility into who did what, when. The team are the users; the manager is the customer; the product is managerial visibility into remote work. Sold as collaboration, it underperforms against tools built for collaboration. Sold — quietly — as visibility, it has no real competition. Most of these companies never figure out which one they are, and price and position as the weaker one.

A developer tool sells ship faster. Follow the operation: the reason it survives procurement is that it generates the compliance artifacts the security team needs to sign off a release. Engineers tolerate it; the security org renews it. It's sold to engineers as speed and bought by security as evidence. The whole funnel is aimed at the wrong room.

In every case the founder could pass a polygraph swearing the stated version is true. That is precisely what makes the gap dangerous — it is not deception, it is a sincere and outdated map. People don't audit maps they trust.

The tells: how to find your own gap

You can't introspect your way to the operating company — introspection returns the story. You have to look at behavior and money, where the truth has no choice but to show itself. Six places it leaks:

1. Where renewals concentrate. Not logins, not "engagement" — renewals and expansions. Find the feature or outcome that, if removed, would actually cause a cancel. That is the operating product. It is often not the one on the homepage.
2. What churned customers say. Exit interviews are the most honest conversations your company will ever have. People leaving have nothing to sell you. Listen for what they thought they were buying versus what they got.
3. Where your best reps go off-script. Top performers improvise their way to the real pitch and call it "feel." That improvisation is the operating company speaking through the people closest to the money. Write down what they actually say.
4. The feature you're a little embarrassed by. Every company has the un-sexy thing that everyone uses and no one features. The export button. The audit log. The one report. Embarrassment is a reliable signal that the operating company has outgrown the stated one.
5. The shape of your support tickets. Support requests reveal the job customers are actually trying to do. When the questions cluster around something you consider peripheral, it isn't peripheral to them.
6. Who actually signs. Map the real buyer against the stated user. When they're different people — as they usually are — the gap between who you talk to and who pays is the gap in miniature.

Run those six and you will feel the distance between your story and your operation. You won't get the full read this way — that takes an outside eye, for the structural reasons above — but you'll know whether the gap is small or whether you've been running the wrong company for two years.

Why a few degrees off is enormous

Here is the part that should make an operator uncomfortable, because it explains a frustration you've probably felt and mislabeled.

Every downstream decision inherits the stated frame. The roadmap prioritizes features for the company you describe. Pricing is set against the value of the stated product, not the operating one — which is why so many companies are wildly underpriced: they're charging for time-saving while delivering oversight, and oversight is worth ten times more. Positioning markets the weaker job. Hiring profiles recruit for the stated company's needs. The funding narrative sells the story, which means the next round's expectations get calibrated to a company that doesn't exist.

A few degrees of misalignment, applied to every decision, compounded across a few years, is not a rounding error. It is the difference between a company that feels like it's fighting uphill and one where everything clicks. This is why excellent execution can leak leverage continuously: the execution is genuinely good and it is aimed slightly, persistently wrong. You are not losing because you're slow. You're losing because the entire machine is pointed at the stated company while the operating company quietly carries the business on its back.

Founders feel this as a vague drag — "we should be further along than we are." They almost always misdiagnose it as an execution problem and respond by pushing harder on execution, which aims the now-faster machine at the same wrong target. Speed multiplies whatever direction you're already pointed.

The AI multiplier — why this is suddenly urgent

For most of business history the gap was expensive but slow. You could carry a misread company for years; the cost accrued gently. That is over.

When you install AI into a company — agents, automations, an "operating system," a folder architecture, whatever the shape — it does one thing with brutal efficiency: it materializes the picture you give it. It takes your frame and renders it faster, cheaper, and at scale. Point it at the operating company and it compounds your real leverage. Point it at the stated company — which is what happens by default, because the stated company is the one written down — and you get a faster, cheaper, more scalable version of the wrong company.

The gap doesn't shrink under AI. It compounds at machine speed. Every founder rushing to "add AI" on top of an unexamined story is about to find out, faster than they expected, exactly how wrong the story was. The companies that win the next few years won't be the ones with the best models. They'll be the ones that read themselves correctly before they pointed the machine.

How to actually read it

The full read is a discipline, not a worksheet, but it has a clear logic. Three principles:

Look at behavior, not opinion. Everyone in the company has a theory of what the company is. The theories are the stated company in different costumes. The operating company is in the data, the renewals, the churn calls, the rep improvisations, the support clusters. Go where people act, not where they describe.

Separate the user from the customer from the beneficiary. The person who uses it, the person who pays for it, and the person who actually benefits are frequently three different people. The stated company usually collapses them into one flattering character. Pulling them apart is most of the read.

Bring an outside eye for the frame itself. You can run the six tells yourself and learn a lot. But the founder is structurally the last person who can see their own frame — it's the water they swim in, and every force that built the gap also defends it. Reading the frame, not just the symptoms, is the part that needs someone standing outside it. That is the actual work: not optimizing the company you describe, but first correcting the description, then rebuilding strategy — and now AI — on the company that's really there.

What changes when you close it

When the operating company gets named, the moves are obvious and large. You reprice against the value you actually deliver. You reposition to the buyer who's actually paying. You cut the roadmap items serving the stated company and double the one feature the operating company runs on. You hire for the real job. And when you install AI, you install it on the corrected picture, so the machine compounds leverage instead of error.

None of these are clever. They only look clever from inside the gap. From outside it, they're just true — and most of a company's available leverage is sitting in the distance between the two, waiting for someone to read it.

If you want the structural read done on your own company — the layer beneath strategy, before any architecture goes in — that is the work. The full version is the ontological audit, and the method runs in public, one piece at a time, in the Reading Room.

A developer or agency builds you something on a framework — LangChain, CrewAI, AutoGen. Code that wires a bunch of AI agents together. A server. Dashboards. They charge you $20,000 to $200,000. And when it breaks, only they can fix it — because only they understand it.

For 95% of what a business actually needs, that isn't sophistication. It's a moat around your wallet.

Here's what none of them want you to know: you can build the same thing yourself. For free. In an afternoon. Using folders.

Not a metaphor. Actual folders, on your computer, with plain text files inside them.

This is the whole foundation, start to finish. It runs long because it's complete — the idea, the reason it works, the history it's borrowed from, and the exact files to copy. Read it twice. Build as you go.

The one idea

Folder structure is the architecture.

That's the whole secret. Instead of writing code to coordinate AI agents, you organize your instructions and context into a folder tree. The AI reads the right file at the right moment and does the work. The folders do the job the expensive framework was doing in code.

When you first hear it, it sounds like a downgrade. Folders are old. Text files are old. Surely a real AI system needs something more sophisticated. The simplicity is the point. Here's what a folder gets you that a $50,000 framework can't:

1. You can read it. Every instruction is a plain text file. Open it. Read it. No black box.
2. You can change it. Need a new step? Add a folder. Wrong tone? Edit a file. No developer. No deployment.
3. You can move it. The whole system is one folder. Copy it, back it up, email it. No server.
4. You can see inside it. Every step writes a file you can open and check. The files ARE the dashboard.

You lose nothing. You gain everything you were paying to not have.

Why most people get nothing out of AI

Most people open Claude or ChatGPT, type a question, get an answer, and start over. Next time, they re-explain who they are and what they're working on. They paste the same context again. They hit a limit and open a new chat from zero.

That's fine for quick questions. It falls apart the moment you try to do real, ongoing work. You burn the AI's attention re-explaining yourself. You can't edit what it produces at each step. Every session starts cold.

The folder structure fixes all of it. But to see why, you need to understand one thing first.

Tokens — the thing that decides everything

A token is roughly three-quarters of a word. Short words are one token. Long ones — "hamburger" — can be three. It's the smallest chunk of text an AI reads at a time.

The word is borrowed. Language researchers in the 1990s needed a unit smaller than "a word," because not every language breaks into words the same way. They took "token" from linguistics, which took it from old English — a token was a sign, a small thing that stands for something. That's exactly what it is here: the smallest meaningful piece of a sentence.

Here's why it matters. An AI can only hold so many tokens at once before it starts to slip. That ceiling is the context window — everything the AI is "thinking about" right now: your instructions, your files, the conversation so far. It's finite.

So if you dump everything into one endless conversation, the AI writing your blog post is also carrying your video production notes, last week's client email, and Tuesday's half-finished spec. It spends its limited attention on things that have nothing to do with the task — and quietly gets worse at the one you asked for.

The folder structure fixes this by separating your work into areas and loading only what the task in front of it needs. Clean attention, every time. That alone is most of the gap between people who get magic out of AI and people who get mush.

The three layers

This is the core of the whole system. Three layers, each with one job.

Layer 1 — the map (CLAUDE.md). One file at the top of your project. The AI reads it first, every time. Think of it as the floor plan by the door: what this project is, what the workspaces are, where things go, and a short routing table that says "for this kind of task, go here, read this." Without the map, the AI reads everything (wasting tokens) or guesses (getting it wrong). It's the single most important file in the system.

Layer 2 — the rooms (a CONTEXT.md in each workspace). Each area of your work gets its own folder and its own context file. Tell the AI to work in the writing room and it reads the writing room's context — your voice, your process, what good looks like there — and nothing from the other rooms. No bleed. You walk in; it already knows where it is.

Layer 3 — the tools (skills). Skills are packaged processes — make a slide deck, humanize a draft, review code — wired into the rooms that need them. You don't load every tool everywhere. The production room gets the build tools; the writing room gets the writing tools. Plug them in where they belong, leave them out where they don't.

Map routes. Rooms hold context. Tools plug in. That's the engine.

Why every file is plain text

Every file in this system is markdown — a plain text file with a few light symbols. Dashes make bullets. Hash signs make headers. Asterisks make bold. That's basically it.

A writer named John Gruber created markdown in 2004. The goal was simple: write something that reads fine as plain text but can also render into a clean document — the readability of a note, without the tags of HTML.

You're already using it without knowing. When Claude answers with headers and bold text, it's writing markdown underneath. Copy its reply into a plain text file and you'll see the little symbols. That's why we use it for everything: the AI reads and writes it natively, and you can open any file in any text editor on any computer made in the last forty years.

You don't need special software for any of this. Your normal file explorer and Notepad are enough. Tools like VS Code — or Claude's own folder mode — just make it tidier to move between a lot of files. Skip them until you want them.

Build one right now

Steal this exactly.

Step 1 — Make these folders and empty files:

my-workflow/
├── CLAUDE.md
├── stages/
│   └── 01_do-the-thing/
│       ├── CONTEXT.md
│       └── output/
└── _config/
    └── standards.md

Step 2 — Put this in CLAUDE.md. This is the map. It says what the thing is and routes every task:

# [Name it — e.g. "Weekly competitor brief"]
This workspace produces [the one thing it makes].
Run it one stage at a time, in numbered order.

## Routing — for each task, go here and read this
| Task        | Go to         | Read       |
| ----------- | ------------- | ---------- |
| Do the work | stages/01_... | CONTEXT.md |

## Rules
- Before working in a stage, read that stage's CONTEXT.md first.
- Write every result into that stage's output/ folder.
- Follow _config/standards.md for tone, format, and quality.
- Don't skip a stage — each stage's output feeds the next.

Step 3 — Put this in stages/01_do-the-thing/CONTEXT.md. This is one room — one job:

# Stage 01 — [what this step does]
GOAL: [the single outcome this step produces]
INPUT: [what to read — a URL, a file, a prompt you paste]
DO:
  1. [first action]
  2. [second action]
  3. [check it against _config/standards.md]
OUTPUT: write the result to ./output/ as [filename].md

Step 4 — Run it. Open the folder in any agentic AI tool — Claude Code, Cursor, whatever you use. Point it at CLAUDE.md. Tell it to run stage 01.

Done. That's a working AI system. Want a second step? Make a folder called 02_. Want to reorder the work? Renumber the folders. Want a different voice? Edit one text file.

You just built the thing they quote five figures for.

Naming conventions: a database without a database

One more piece that makes this work with zero code. In your CLAUDE.md, you set naming rules.

A blog draft becomes api-auth-guide_draft.md. A newsletter becomes 2026-03-launch-week.md. Version two of a demo script becomes demo_v2.md.

Now the names carry the information. You can say "pull my demo v2 and turn it into a spec" and the AI knows exactly what to find, where it lives, and what to do next. No database. No search index. No code. The filename is the lookup.

Make it yours: three real setups

The folder names above are placeholders. The layers never change — the labels do. Here are three real shapes. Find the one closest to your work, then build your own.

If you make content. Three rooms: a script lab (ideas to drafts to final), a production room (briefs, specs, builds), a distribution room (per-platform formatting, scheduling, repurposing). The script lab's context holds your voice and audience, so the AI writes like you from the first line.

If you're a freelancer or consultant. One room per client, each with its own context — who they are, the engagement, the phase, their terminology — plus a templates room and a business-dev room. Say "let's work on Alpha" and it reads Alpha's context and nothing from Beta. Land a new client? Copy the structure, write one new context file, add one line to the map.

If you build software. Rooms for planning, source, docs, and ops — each with a context file describing the stack, the conventions, the standards. This is where Layer 3 earns its keep: wire a testing skill into the source room, a doc skill into the docs room, so each loads only where it's relevant.

Same three layers every time. You change the labels and the context. The architecture holds.

Why this works: fifty years of one idea

This isn't new. It's the oldest principle in software, pointed at AI.

In 1972, a computer scientist named David Parnas wrote a short, famous paper arguing that systems should be split into parts that each hide their own complexity and connect through clean, simple interfaces. Separation of concerns. It became one of the load-bearing ideas of all software.

Everything good that followed is a version of it:

• Unix, 1970s — small programs that each do one thing, connected by plain text. Still running today.
• Compilers, 1980s — break a hard transformation into stages, each reading the last one's output.
• Infrastructure-as-code, 2010s — stop configuring servers by hand; put the whole system in plain files in a folder, and the files are the source of truth.

Each of those beat the smarter, more complicated alternative of its day. Folders-for-AI is the same bet: each room does one thing, the map routes between them, plain text is the interface. Simple things you can read and change beat complex things you can't. Fifty years of evidence say so.

The full lineage — 1972 through to AI — and the deeper five-layer version of this architecture are written up in a 2026 research paper I'll point you to at the end. Hand it to your AI and have it walk you through whatever part you want to go deeper on.

Now here's how you make money with it

Two ways.

Use it. Build the repetitive, boring work in your own business as folder workflows — content, outreach, reporting. You stop paying for tools, and you stop doing the same work twice.

Sell it. This is the part people are sleeping on. Businesses are being quoted $30,000 for systems they can't even operate. You can build them a folder workspace they own — readable, editable, no lock-in — and charge for it. They pay happily, because it's the opposite of everything else on the market. One folder. One handoff. Theirs forever.

The cost of building just fell to almost nothing. The people who win now aren't the ones with the fanciest stack. They're the ones who know what to point it at, and who can hand someone a thing that works — then walk away.

That's the whole game.

This is just the foundation

Everything above is the ground floor. It's enough to change how you work this week — but it's the beginning, not the whole building.

What you just learned is three layers. The full architecture has more: skills built and chained in depth, external tools and live data wired in, several workspaces orchestrated together, the five-layer version laid out in the research. It gets more capable — and yes, more complex.

Don't reach for that yet. Get this working first. Build one workspace. Run it until the three layers are second nature — until you can feel where a task belongs before you've finished reading it. When that clicks, you're ready for what's next.

Because this is the start of a series. I'm going to build this all the way up, one piece at a time, in plain language, exactly like this. If you can build the foundation in this post, you're ready for every layer that comes after it.

If this was useful, subscribe — I give the whole playbook away, one piece at a time. No upsell, ever. The next one goes deeper.

(Credit: the full history and the five-layer architecture are formalized in a 2026 paper by Van Clief & McDermott — arxiv.org/abs/2603.16021. I landed on the same shape building my own systems before I read it.)

Take this with you

The fastest possible start — three files, five minutes. Make a folder. Put these inside.

CLAUDE.md — who you are, what this is, where things go:

# Identity
You are helping [YOUR NAME] with [WHAT YOU DO].

# Folders
- /drafts      — work in progress
- /final       — finished outputs
- /references  — background material

# Rules
- Read this file first on every new task.
- Ask before creating files outside /drafts.
- When unsure, ask.

CONTEXT.md — the current project:

# Current project
[What you're building. 2–3 sentences.]

# What good looks like
[What a successful output looks like.]

# What to avoid
[Common mistakes or things you don't want.]

REFERENCES.md — background the AI should know but not act on:

# References
[Examples, links, style guides, notes — anything the AI
should have access to but doesn't need to act on directly.]

Point your AI at the folder — Claude Code, or upload the three files to a project, or paste them into your first message — and give it a task. You'll feel the difference on the first reply.

And if you'd rather learn it cold than just read it: copy this entire post, paste it into your AI, and say "Teach me this. Quiz me until I've got it, then walk me through building my first workspace." You'll own it by the end of the day.

The technical work is fine. The workspace is correctly structured, the models are credible, the agents do the work they were instructed to do. The architecture is sound. And the company gets less out of it than the architecture should be able to deliver.

The reason is structural. The architecture was installed around an inherited frame — the company's implicit theory of itself — and the frame was wrong. Not catastrophically wrong. Just wrong enough that every downstream choice now compounds in a direction that doesn't match what the business actually is.

Strategy applied to the wrong picture compounds in the wrong direction. Architecture applied to the wrong picture does the same thing faster.

This essay is about the layer that has to be read before any architecture goes in.

The architecture is real

Interpretable Context Methodology, published by Van Clief and McDermott in March 2026, formalizes what serious AI practitioners had been arriving at independently for the prior two years. The thesis is direct: folder structure is the architecture. The workspace is laid out as a tree of folders, each holding a small amount of context relevant to the work routed to it, and the AI assistant reads its way through the tree by following the structure of the folders themselves. No orchestration code. No agent frameworks stacked on top of each other. The folders are the order of operations; the files inside them are the working memory; the AI is the thing that reads them.

This isn't a novel claim from someone selling a course. It's an old idea: computers have run on files in folders for fifty years, and Unix engineers have been doing this for nearly that long. ICM names the pattern, formalizes the five-layer architecture, and demonstrates why for the kind of work most operating businesses actually do, plain files win against more infrastructure.

For the practice I run, ICM is the technical foundation. I converged on the pattern independently before encountering the paper, and have been building workspaces this way across several ventures since. The methodology is real and examinable. I cite Van Clief and McDermott when I introduce it, and link to the paper when readers want the long version.

Where the installations fail

Despite all of that, ICM installations into operating businesses tend to produce one of two outcomes.

The first outcome: the workspace accelerates existing work without changing what the work is for. The founder gets faster outputs of the same things they were already producing. The company can do more of what it was already doing. This sounds like a win. But if what the company was already doing was itself misaligned with what the company structurally is, the architecture has now made that misalignment harder to see and faster to compound. The team executes more efficiently on the wrong picture. Six months in, the founder cannot explain why a system that was supposed to clarify the work has made the work harder to course-correct.

The second outcome: the workspace fails to gain traction. The folder structure mirrors the org chart the founder grew up with — sales, marketing, ops, engineering — and the workspace ends up being a digital version of the same compartmentalization the company has been quietly outgrowing. People don't use it. The architecture is correct in form and wrong in fit.

Both outcomes have the same root cause. The architecture was built around an unexamined picture of the business. The picture itself was never read.

What was missed

ICM's five layers, in the order the methodology presents them, are: CLAUDE.md (workspace identity), workspace CONTEXT.md (task routing), stage CONTEXT.md (stage contracts), reference material (standards and voice), and working artifacts (outputs). The methodology is rigorous about how these layers relate to each other and what they hold. It is silent on what the workspace identity should be — who the business actually is.

The silence is structural. ICM is an architecture for installing AI workspaces. The question of what the workspace should be installed around is not a workspace question. It's a business question that has to be answered first.

In practice, what fills the silence is the founder's existing self-description. The marketing site. The deck. The org chart. The story the company has been telling itself for long enough that the story has hardened into operating reality. The workspace gets built around that.

And here is the part most operators don't see until it's six months too late: the story almost never matches the operating reality. The decisions a company actually makes — what gets prioritized when the budget is tight, who gets escalations, what the team mobilizes for under pressure, what the customer is actually paying for — these reveal a different picture from the one in the deck.

The architecture is supposed to materialize the company's structure. If the structure encoded in the workspace is the one in the deck rather than the one in the operating reality, the architecture materializes the wrong thing.

The layer above

What I install before the architecture is an ontological audit. It is a structured reading of the company's foundational frame, conducted through six questions:

1. What is this business? Not at the function level — what category, what industry, what segment — but at the level beneath the function. What does the company actually do when no one is watching? What does the team mobilize for under pressure? What is the underlying transaction the entire operation is organized around?

2. What exists inside it? What are the entities the work actually moves through — customers, products, regions, modes — and which of those are primary versus secondary? Which entities does the team treat as load-bearing in conversation, and which are background?

3. What is the customer actually buying? The stated answer is whatever the marketing site says. The real answer is whatever the customer would still pay for if you stripped everything else away. These are almost never the same answer.

4. Where is the structural mismatch? Between the founder's theory of the company, the team's experience of the company, and the customer's experience of the company. Mismatch is normal at the experience layer; mismatch at the substrate layer is where leverage leaks.

5. What is leaking leverage? Where is execution being applied to the wrong picture? Where is the team being asked to optimize for something the company isn't actually structured to deliver? The answers are usually visible to the team and invisible to the founder.

6. What is the corrected frame? A clean articulation, after the audit surfaces the distortions, of what the company actually is at the substrate level. This is what the architecture then gets built around.

The six questions take a structured set of conversations and a written document to answer. The document is the audit. For most founders who go through this, it is the clearest picture they have ever had of their own company — not because the founder didn't know, but because the structural picture was never extracted into a single document. The picture had been living distributed across the founder's intuition, the team's frustrations, and the customer's reported reasons for renewing.

What changes when the audit runs first

Two things change.

The first thing: the architecture materializes the right picture. The workspace identity — the highest ICM layer — is grounded in what the company actually is, not what it was told to be. The routing follows the structural reality, not the inherited org chart. The reference material encodes the actual voice and standards of the company. The artifacts produced by the workspace map onto the work that the business actually does. The architecture works because it was applied to the corrected frame.

The second thing, which matters more: the architecture becomes interpretable to the team. When the workspace structure matches the operating reality, the team recognizes it. They use it. The folder tree feels like the company. The architecture stays in use after the installer leaves because it was built around something the team already implicitly knew but had never seen named.

Without the audit, the architecture is technically correct and operationally drifting. With the audit, the architecture is technically correct and structurally aligned, and the alignment is what makes the architecture compound rather than calcify.

The order matters

The order is: audit, install, hand off. The audit reads the company. The install builds the architecture around the corrected picture. The hand-off trains the team to run it.

In practice, most consulting starts at install. Most strategy work starts at the strategy layer, which sits two levels above the substrate. Most AI deployment starts at the workspace layer with no audit at all. Each of these can produce visible outputs. None of them, by themselves, produces a system that compounds. Compounding requires the architecture to be installed around the right picture, and the right picture only surfaces after the substrate is read.

ICM's five layers are the architecture. The audit is the layer above them. The audit doesn't replace the architecture; it determines what the architecture is for.

That's the work.

Full methodology: jaydenforshee.com — "The Ontological Layer." ICM source: Van Clief & McDermott, 2026 (arXiv:2603.16021).

This is incomplete. A business is not one layer; it is three. Confusing them produces most of the frustration that founders feel when they cannot explain why smart advice does not produce the results it promises.

I have come to see businesses as operating on three structural layers, and I want to lay them out plainly, because once you can see them you can see why the work I do happens where it happens, and why most consulting works at the wrong altitude.

The three layers

Substrate is what the company actually is. The structural reality underneath every description, every pitch, every org chart. It is what the company does when nobody is watching, what the customer actually pays for, what the team mobilizes for when an emergency hits. It is the layer the rest of the business is built on, whether the founder has named it or not. Most companies have a substrate they have never articulated, and the gap between the named version and the actual one is where most operational friction lives.

Experience is how the company is lived. The felt reality of being inside it, working in it, buying from it, leading it. It is the layer where founders burn out. It is the layer where employees decide whether they want to be there. It is the layer where customers decide whether to renew. Experience is not the same as substrate — a company can have a sound substrate that is being lived as friction (because the systems are wrong) or a fractured substrate that is being lived as smoothness (because the people are heroic). Experience is the lived translation of the substrate, mediated by everything that sits in between.

Strategy is what the company decides to do. The expansion plans, the hiring decisions, the product roadmap, the market positioning. Strategy is downstream — it depends on having a clear picture of what the company is (substrate) and what the company feels like to run (experience). Without those two layers settled, strategy floats free of reality. It produces decisions that look reasonable on paper and then quietly fail to materialize when the company tries to execute them.

Most consulting works at the strategy layer. Some excellent coaching works at the experience layer. Almost nothing works at the substrate layer. This is what Substrate is for.

Why missing the middle layer matters

The reason I want to name the experience layer separately, rather than collapsing it into substrate or strategy, is that experience is where founders feel the friction first. The substrate gap shows up in lived experience long before it shows up in strategic failure.

A founder who is exhausted by their own company is rarely exhausted by the work itself. They are exhausted by the gap between how the company is supposed to feel (according to the deck) and how it actually feels day to day. The deck says they are running a high-growth software company; the daily experience is that they are running a high-touch services business with software as the delivery mechanism. The gap between those two pictures is what produces the exhaustion. It is not a strategic problem. It is not a substrate problem. It is an experience problem caused by a substrate problem.

If you only have two layers — substrate and strategy — you cannot see this. The founder's exhaustion looks like a personal problem. Hire an executive coach. Read a book about resilience. The actual cause — that the company's lived experience does not match its stated structure — never gets named.

A team that is underperforming relative to what the strategy says they should be producing is rarely underperforming because they are lazy or incapable. They are underperforming because the experience of doing the work does not match the experience the strategy assumes they are having. The strategy assumes a coordinated team working from a shared picture of the company. The experience is that the team is operating from three different pictures and translating between them constantly. The output looks like a strategic failure. The cause is in the experience layer.

A customer that signed up enthusiastically and is now churning is rarely churning because the product got worse. They are churning because the lived experience of being a customer has drifted from what they thought they were buying. The substrate may have shifted under them. The strategy may have changed without anyone telling them. The experience layer is where they notice. The experience layer is also where they leave.

Naming experience as its own layer makes these failures visible. It lets you ask: is this a substrate problem, an experience problem, or a strategy problem? That question alone surfaces things that consulting frameworks calibrated to two layers cannot see.

What an audit does at each layer

The audit phase of an engagement reads the company at all three layers simultaneously, because they reveal different things and the divergences between them are where the real work is.

At the substrate layer, the audit reads what the company actually is. The four signals I have written about elsewhere — what the founder says in private, what the operators say separately, what the customer reports buying, what the company mobilizes for under pressure. The output of this part of the audit is a clear articulation of the company's underlying structure.

At the experience layer, the audit reads how the company is lived. What it feels like to be the founder day to day. What it feels like to be on the team. What the customer reports experiencing in the months after purchase. The output is a picture of the company's felt reality — where it is smooth and where it is friction, where the experience matches the substrate and where it has drifted.

At the strategy layer, the audit reads what the company has been deciding to do. What initiatives are in motion. What hires are queued up. What roadmap items are scheduled. The output is a picture of what the company is actively pointed at.

Then the audit reads across the three. The most valuable findings are usually in the gaps. The substrate says you are a knowledge-transfer business. The experience says you are operating like a software company. The strategy says you are scaling the software platform. That is why everyone is exhausted. Or: The substrate is sound. The experience is excellent. The strategy is mismatched — you are deciding to do things that the substrate and experience would not naturally support. Or, most commonly: The substrate has drifted, the experience knows, and the strategy is calibrated to the old substrate. The friction will compound until one of the three is corrected.

This is what I am actually doing when I audit a company. Not running a diagnostic. Reading across the three layers and surfacing the divergences. The audit document explains what is there, in plain language, with the structural reasoning visible enough that the founder can carry the picture forward themselves.

What the install does

Once the audit is signed off, the install operationalizes the corrected picture. The architecture I build maps to the substrate the audit surfaced — but it does more than that. It creates a daily operating layer that materializes the substrate into experience. The team works from files that reflect the corrected ontology. The decisions get made inside a system calibrated to what the company actually is. The customer encounters a company that operates from a single coherent picture rather than three competing ones.

The install does not change the substrate. That was already there. The install also does not change the strategy directly. What it changes is the experience layer — the daily lived reality of working inside the company. Once the experience matches the substrate, strategy becomes simpler, because the questions strategy is supposed to answer become clearly tractable. Given who we are (substrate) and how we are lived (experience), this is the obvious next move. Strategy collapses into clarity rather than spiraling into options.

This is why I describe the practice as working the layer underneath strategy. The strategic decisions that get made after an engagement are usually obvious. The hard work happened at the substrate layer (the audit) and the experience layer (the install). Strategy follows from those two being settled.

Why this changes how to think about consulting

Most consulting today works at the strategy layer with occasional excursions into the experience layer. The strategy frameworks of the 1980s and 90s — Porter, SWOT, BCG matrix — assume the substrate is settled and the experience is downstream of execution. In stable industries this assumption was approximately correct. In modern businesses, where categories blur and companies drift faster than they can rewrite their decks, the assumption breaks down. Most consulting fails at the strategy layer because the strategy layer is downstream of two layers nobody was looking at.

The next generation of consulting will work at the substrate layer first. Some practitioners will start there explicitly, like Substrate does. Others will arrive there through different paths — phenomenologists, ontologists, structural designers, organizational theorists who have read enough philosophy to know that "what is this company" is a non-trivial question. The ones who succeed will be the ones who can do three-layer reading without overcomplicating it. The ones who fail will either stay at the strategy layer (and produce work that does not land) or get lost in the substrate layer without a way to operationalize what they find (which is what most philosophical consulting looks like).

The advantage of installing AI operating architecture is that the install gives substrate work a concrete output. The audit produces the corrected picture. The architecture encodes the picture into the daily operating layer. The team begins working from the corrected picture immediately, and the experience layer shifts within weeks rather than months. The substrate becomes lived, not just named. That is what most substrate-level consulting cannot deliver, because it ends at the document. The install is what closes the loop.

The deeper claim

What I want to leave you with is this: most of the work a founder needs done is not where most of the work a founder gets done is happening. The strategy layer is where founders go for help, because that is where the frameworks live and where the consultants gather. The substrate layer is where the actual problem usually is. The experience layer is where the problem first shows up as a feeling.

If you have read this far and recognized your own company in any of the descriptions — exhausted by the gap between stated and felt reality, frustrated by smart advice that does not produce results, sensing that something is off without being able to name what — the layer you need worked is probably not strategy. It is one of the two underneath.

That is the layer this practice works first.

This is a build log from the operating architecture I have been installing inside it for the last year. The methodology is the same one I install for clients. The reason I am publishing the build log in the Reading Room is that the question of whether the methodology works in a real business environment with a real non-technical operator running it daily has to be answered somewhere, and the most direct way to answer it is to show what the architecture looks like and what it has produced.

What the audit surfaced

When I started installing the architecture, the stated picture of On Duty was "a fleet safety SaaS platform." That is the label. It is on the marketing materials. It is how the company is described at industry conferences. It is what an investor would expect to evaluate.

The audit found something different underneath.

What On Duty actually is — when you watch what the customers are responding to, what the pilot operator is paying attention to, what determines whether a tenant renews or churns — is a compliance and litigation defense product wearing safety language. Fleet operators do not buy safety platforms because they want their drivers to be safer in the abstract. They buy them because the legal exposure of operating commercial vehicles in the current US tort environment is catastrophic, and they need a documented system that demonstrates due diligence in the event of a nuclear verdict. The safety is real. The reason they pay for it is liability.

This sounds like a small distinction. It is not. The stated ontology — safety SaaS — implies that the most valuable output of the product is improved driver behavior. The actual ontology — compliance and litigation defense — implies that the most valuable output is a comprehensive, court-admissible audit trail. Those are different products even though they look the same from the outside. If we built the product around the stated ontology, we would optimize for driver coaching engagement metrics. If we built it around the actual ontology, we would optimize for the documentation, traceability, and defensibility of the system itself.

The architecture I installed reflects the corrected picture.

The shape of the install

The workspace has eight top-level domains, each mapped to a specific function the company actually performs. I will describe them in shape only — the specifics of the routing logic, the context files, and the reference material are bespoke to On Duty and not the kind of detail a build log should expose. What is useful here is the structural pattern.

Sales and outreach. The workspace used daily for prospect identification, outreach sequencing, and pipeline management. The architecture is calibrated to the specific buyer — operations directors and safety officers at fleet operators between $5M and $50M in revenue. Every output the system produces is calibrated to that buyer's specific vocabulary, decision criteria, and procurement process. The material it produces lands differently from generic sales copy because the architecture knows the buyer at a structural level.

Compliance and audit preparation. This is the workspace that translates the actual ontology into operating output. When a tenant is preparing for a DOT audit or building documentation for legal defensibility, this workspace produces the artifacts they need in the format their auditors and attorneys expect. The corrected ontology is encoded directly into the routing logic — the system treats compliance documentation as the primary output, not as a side effect of safety coaching.

Client success and retention. Onboarding new tenants, monitoring health scores, running the 30-day pilot framework, executing the renewal playbook. Each of these is its own stage with its own context, but they share a coherent picture of what success looks like inside On Duty — calibrated to the corrected ontology rather than the inherited one.

Three other operational workspaces handle marketing content, internal operations, and the technical build itself. They mirror the same structural pattern: numbered folders for stages, plain markdown for context, reference material that captures industry knowledge in a form the AI can use.

The architecture is built on Interpretable Context Methodology. Every file is plain markdown. The whole system lives in a Git repository that can be cloned, edited, extended, and operated without my involvement. There is no platform to depend on. There is no proprietary configuration. There is no vendor lock-in.

What is working

A few patterns have surfaced over the last year of running the system.

The non-technical operator pattern is real. My co-founder uses the architecture daily. He edits the markdown files himself when he notices something off. He has added two workspaces on his own that I did not build, by copying existing ones and modifying them. The system has grown beyond what I installed, in directions I did not anticipate, because the architecture was designed to be operable rather than dependent. This is the most important validation of the methodology, because it is the hardest thing for AI consulting to deliver. Most installs degrade or become dependent within six months. This one has compounded.

The corrected ontology produced unexpected operational clarity. Once the workspace was built around compliance-and-litigation-defense rather than around safety-as-such, decisions that had been chronically slow started resolving quickly. Pricing conversations got easier because the value proposition was clearer. Sales calls converted faster because the messaging matched what the buyer actually wanted to hear. Product roadmap discussions stopped fragmenting because there was now a stable picture of what the company was prioritizing for. None of this was the architecture's direct output. It was the side effect of operating from the corrected frame daily.

The audit document keeps paying compound interest. When I wrote the audit, I treated it as a one-time artifact — a document that explained what I had surfaced so the install could be built against it. A year in, my co-founder still references it when he is making decisions that aren't covered by any workspace. The corrected ontology has become the foundation for how he reasons about the company, not just the foundation for what the system produces. The audit was the highest-leverage piece of work in the entire engagement, even though most of the visible output came from the install.

What is not working

A build log that only reports wins is marketing. Here is what is still rough.

The CSV duplicate user issue is unresolved. When tenants upload driver lists, the deduplication logic has a known bug that creates duplicate user records in edge cases. This is a technical problem, not a methodological one, but it shows up here because it is the kind of friction the corrected ontology cannot fix. Architecture can solve coordination problems. It cannot solve implementation bugs. Distinguishing between those two has been a useful discipline.

Email delivery from the platform to external recipients has been unreliable. Same category as the CSV problem. The architecture is sound; the technical execution at the platform layer has gaps that are being worked through.

The non-technical operator has hit a ceiling on workspace creation. Existing workspaces extend well. New workspaces created from scratch — for a function the existing architecture didn't already cover — run into the limits of what the methodology can do for someone without technical training. The architecture is operable but not yet teachable, for the non-technical operator at this skill level. This is an open problem.

The architecture has been revised twice. The audit was correct, but the install's first version did not fully reflect the corrected ontology — there were workspaces that, on six months of use, turned out to be calibrated to the stated picture rather than the actual one. Revising them required reopening the audit, refining the corrected ontology, and rebuilding three workspaces. The methodology is iterative in practice even when it appears clean on paper.

What the build log is for

The methodology works. The architecture has held up. The non-technical operator has been able to run and extend the system. The corrected ontology has produced compounding clarity over twelve months.

This is the evidence. The reason it is in the Reading Room is that anyone evaluating the practice can read it and see the work in motion — what the audit produces, what the install consists of, what the install does over time, where it is solid and where it is still being refined. Most AI consulting work is invisible after delivery. This one is open.

More Field Notes will follow as the build continues and as new things become worth reporting.

The advice was sound. The reasoning was solid. The founder agreed in the room. And yet the company did not move.

This happens too often to be coincidence. It happens with smart founders and smart advisors. It happens with high-end consulting firms and low-end ones. It happens with experienced advisors who have been giving strategic advice for decades. The pattern is consistent enough that it has to mean something structural.

What it means is that strategy is downstream. Strategy assumes that a more fundamental question has already been answered — what is this company, structurally — and when that question has not been answered, strategy has nothing to attach to. The advice goes in, the founder agrees with it, and then the actual operating reality of the company quietly fails to absorb it, because the strategy was built for a company that does not quite exist.

This essay is about that layer underneath strategy. What it is, why most advisors don't work it, what it costs when it is left unworked, and what changes when it is settled.

What strategy actually assumes

When you sit down to make a strategic decision — should we expand, should we hire, should we launch — you are implicitly answering several smaller questions first:

• What is this company, primarily?
• Who is our customer, and what are they actually buying?
• What are we good at, structurally, versus what are we trying to be good at?
• What does the team actually do, versus what the org chart says it does?
• Where is the company headed, given its current shape and momentum?

If you have clear answers to these questions, strategy is straightforward. The decision practically makes itself. Given who we are and where we are pointed, this is obviously the right move. The hard part is execution, not the decision.

If you do not have clear answers — if there is real disagreement, or vague consensus that papers over real disagreement, or a stated answer that does not match the company's actual behavior — then strategy becomes guesswork. The decision feels heavy because each option implies a different answer to the underlying questions, and nobody has agreed on the answers, so the decision is actually several decisions stacked on top of each other.

Most strategic confusion is downstream of unresolved ontological questions. The strategy is hard because the substrate is unsettled. Settle the substrate, and the strategy collapses into clarity.

Why most advisors skip the substrate layer

Advisors who work at the strategy layer are working at the level where their training applied. McKinsey, Bain, BCG — the entire management consulting industry — was built on strategy frameworks. Porter's five forces. SWOT analysis. The BCG matrix. These are tools that assume the question of what the company is is already settled, and that the remaining work is figuring out what the company should do given what it is.

This worked for a long time, because in the era these frameworks were designed for — large industrial companies in stable industries — the question of what the company was was, in fact, usually settled. A steel company knew it was a steel company. An airline knew it was an airline. The strategic questions were genuinely strategic.

But modern businesses are different. Software companies sell services. Service companies sell software. Hardware companies sell subscriptions. Subscription companies sell hardware. The categories blur. A founder who started a "marketing agency" wakes up five years later running what is effectively a media company. A founder who started a "SaaS platform" finds out their customers are actually paying for a community. The category drifts faster than the founder can rewrite the deck. The strategy frameworks assume settled ontology, but in real companies, ontology is rarely settled anymore.

Most advisors do not address this because they were trained in an era when they did not have to. They learned to apply strategic frameworks to companies whose categories were stable. When they encounter companies whose categories have drifted, they apply the frameworks anyway, and the frameworks deliver advice that is locally coherent but globally misaligned. The advice would have been correct for the stated ontology. It is incorrect for the actual ontology. The founder cannot articulate why the advice feels off, because the founder cannot articulate the gap between stated and actual ontology either.

This is the dynamic that produces the moment I described at the start of the essay. The advisor gives sound advice. The founder agrees. Three months later nothing has happened, because the company is structurally incapable of absorbing advice calibrated to the wrong picture of itself.

What it costs to skip the substrate layer

When the substrate layer is skipped, the costs compound in specific ways.

Strategic initiatives launch and quietly fail. The initiative was launched against the stated ontology. The execution happens in the actual ontology. The two do not align. The initiative produces motion without progress, activity without outcomes, and after six or twelve months it gets quietly deprecated. Nobody can fully explain why it did not work. The retrospective concludes with vague language about "execution challenges" or "market timing." The actual cause — that the initiative was calibrated to a company that does not exist — is never named.

Hiring decisions produce friction. A company hiring against its stated ontology recruits people who fit the deck. Those people walk into a daily reality that does not match the deck. They struggle. They underperform. They get blamed for being the wrong hires. They leave. The cycle repeats with the next batch, because the company has not corrected the gap that caused the misalignment in the first place. The hires are not the problem. The job description is the problem. The job description is downstream of the stated ontology, which is the problem.

Founders burn out from carrying the gap. This is the most expensive cost. The founder is the one person in the company who has access to both pictures — the stated one they wrote, and the actual one they are operating in. Every day, they translate between the two. Every meeting requires holding two versions of the company at once. Every decision involves choosing which version to optimize for. The cognitive load is real, and it does not get lighter. Over time, the founder either rebuilds the company to match the actual ontology (rare), forces the actual ontology to match the stated one (usually catastrophic), or burns out trying to hold both (most common). Most "founder burnout" is ontology gap burnout. It is the price of running two versions of the same company simultaneously without ever naming the gap.

Strategy meetings produce decisions that do not stick. A strategy meeting is supposed to align the company on a direction. But the alignment is at the level of stated ontology, while the daily work happens at the level of actual ontology. So the meeting produces decisions that everyone agrees with in the room and that nobody operationalizes after. The team leaves the meeting with renewed clarity that quietly evaporates over the following weeks, because the operating reality of the company has not changed. The strategy was real. The substrate it was applied to was not.

What changes when the substrate is settled

When the substrate is named clearly and the company aligns to it, several things change immediately.

Strategic decisions become easier, because the underlying questions are no longer unresolved. Given that we are this kind of company, the answer is obvious. The hard work moves from deciding to executing, which is where it should have been all along.

Hiring becomes clearer, because the job descriptions can be written against the actual ontology. The candidates who fit the company show up. The ones who don't, screen themselves out. Onboarding is shorter because new hires walk into a daily reality that matches what they signed up for.

Marketing copy starts to write itself, because there is now a clear thing to write about. The founder can describe the company in private and in public using the same language. Customers self-qualify by recognizing themselves in the description. Conversion rates improve, not because the funnel got better, but because the front of the funnel now describes the actual company.

Strategy meetings become productive, because the substrate is no longer the hidden disagreement under every decision. The team aligns faster. The decisions stick. The actions follow through.

And the founder experiences relief. Not because the company is suddenly easy, but because the company is no longer fighting itself. The work that was supposed to be exciting becomes exciting again, because the founder is now operating the company they actually have, instead of translating between two versions of it.

What this means for the practice

This is the layer the practice works first. Not because strategy doesn't matter. Strategy matters enormously. But strategy is downstream — it depends on having a settled answer to the question of what the company actually is, and most founders do not have that answer settled, even if they think they do.

The audit phase of an engagement does not produce strategy. It produces the input that strategy is built on. A written articulation of the company's actual ontology, surfaced across the founder, the team, and the customer, with the structural fractures identified and the corrections named. For most founders, this is the first time they have seen their company described accurately. The strategic decisions that follow are often easy by comparison, because the hard work was already done at the layer underneath.

The architecture install operationalizes the corrected ontology — encodes it into the AI operating layer of the business, so the team is daily working from the accurate picture instead of the stated one. This is what closes the gap permanently. Without the architecture, the audit is a document that can be remembered or forgotten. With the architecture, the audit is encoded into the system the team uses to actually do work, and the corrected picture becomes structurally inescapable.

This is why I do not offer strategy consulting. There are plenty of people who do that well, and most of them are working at the wrong layer to address what most founders are actually stuck on. I work the layer underneath strategy, because that is the layer that has to be settled before strategy can do its work. If a founder reads this and finds that strategy is genuinely their problem — that their ontology is already clear and they just need help deciding what to do — they should hire a strategist, not me. But if they read this and recognize the dynamic I described at the start of this essay, where strategic advice keeps coming in and somehow not landing, the layer they need worked is the substrate.

The deeper claim

The deeper claim of the practice, when you boil it down, is this: most of what looks like a strategy problem is actually an ontology problem. Most of what looks like an execution problem is actually a structural alignment problem. Most of what looks like a hiring problem is actually a question-of-what-this-role-is-for problem. The advisors who get hired to solve these problems are working one layer too high, applying frameworks designed for a different era, and the founders who hire them keep getting smart advice that does not change anything.

The work at the substrate layer is what makes the work at the strategy layer effective. You do not have to choose between the two — you have to do them in the right order. First the substrate. Then strategy on top of it. When you do them in that order, strategy actually works. When you skip the substrate and start with strategy, strategy spins. The motion looks like progress. The outcomes do not match the motion.

If you are a founder who has been frustrated by smart advice that does not produce results, this is likely what is happening. The advice was correct for a company that doesn't quite exist — the version of yours that lives in your deck. The actual company is operating on a different ontology, and the gap is where the advice is getting absorbed and lost. The fix is not better strategy. The fix is settling the layer underneath.

That is the layer this practice works first.

The standard picture goes like this: you hire a developer or a consulting firm to build you an AI system. They use a framework — LangChain, CrewAI, AutoGen, something similar. They write Python code that orchestrates multiple AI agents talking to each other. They deploy it on a server. They build dashboards to monitor it. They charge you anywhere from twenty thousand to several hundred thousand dollars depending on the scope. When something goes wrong, only they can fix it, because only they understand the code that holds the whole thing together.

For the rare workflow that genuinely needs concurrent multi-agent coordination, this is the right architecture. For the vast majority of business workflows that get sold this way, it is overkill — and the overkill carries real costs. The system is opaque. Your team cannot modify it without involving the developer. Every change requires a deployment. Every update is a project. The technology you bought to make your business faster ends up making your business slower, because the technology now has its own maintenance overhead.

There is a cleaner way. It is documented in a 2026 paper by Jake Van Clief and David McDermott called Interpretable Context Methodology — ICM for short. The methodology takes ideas from Unix engineering in the 1970s, multi-pass compilation in the 1980s, and infrastructure-as-code in the 2010s, and applies them to a problem that has only existed for a few years: how do you structure AI systems so they actually work for the businesses operating them?

This essay is about why I install ICM-based architecture for every client, and why I think it is the correct technical foundation for almost every AI system a real business actually needs.

The central claim

ICM's claim is structural: folder structure is agent architecture. Instead of writing application code to coordinate AI agents, you organize the prompts, context files, and reference material into a hierarchical folder system. One agent reads the right files at the right moment. The folder structure does the work that a multi-agent framework would otherwise do in code.

When you read this for the first time, it sounds like a downgrade. Folders are old. Files are old. Markdown is plain text. Surely a modern AI system needs something more sophisticated than that. But the simplicity is the point. Here is what folder-based architecture actually gets you that framework-based architecture cannot:

Anyone can read it. Every instruction, every context file, every routing decision is a plain markdown file. A non-technical operator on your team can open the folder, read what the system does at each step, and edit any of it with a text editor. The system has no hidden state, no proprietary configuration, no black box. The architecture and the documentation are the same thing.

Anyone can modify it. Changing how the system behaves does not require a developer. It requires editing a markdown file. If a workflow needs an additional step, you add a folder. If a prompt is producing the wrong tone, you edit the text. If the order of operations is wrong, you renumber the folders. The control surface that would normally live in code now lives in the filesystem, and the filesystem is something every operator already knows how to use.

Everything is portable. A workspace is a folder. You can copy it, version it in Git, email it as a zip file, hand it to another team member, or move it to a different machine. There is no server to deploy, no environment to configure, no dependency to manage. The architecture goes wherever the folder goes.

Every intermediate output is inspectable. When an AI agent finishes one stage of work and hands off to the next stage, the handoff is a file. You can open the file, read what was produced, and edit it before the next stage runs. If something goes wrong, you can see exactly where. There is no need to build a dashboard to monitor the system, because the system's state is already a folder full of files you can look at.

Why this works

This is not new architecture. It is borrowed architecture, applied to a new problem.

The Unix designers in the 1970s figured out that small programs connected through plain text were more powerful than large programs that tried to do everything. The principle was: each program does one thing well, the output of one program becomes the input to another, and plain text is the universal interface. Pipelines like find | grep | sort | uniq are still in daily use fifty years later, because the architecture is fundamentally sound.

The compiler engineers of the 1980s figured out that complex transformations were more reliable when broken into stages, with each stage reading the output of the previous one and writing its own intermediate representation. A modern compiler has lexing, parsing, semantic analysis, optimization, and code generation as separate passes, and each pass is independently inspectable and replaceable.

The infrastructure-as-code movement of the 2010s figured out that production systems should be defined as files in a repository, not as configurations in a server somewhere. Terraform, Kubernetes manifests, Ansible playbooks — all built on the idea that the deployment artifact and the source of truth should be the same thing, and that thing should be plain text in a folder.

ICM applies these three traditions to AI systems. Each stage of the workflow does one thing well. The output of one stage becomes the input to the next. Everything is plain markdown in a folder structure that doubles as both the source of truth and the deployment. This is fifty years of software engineering wisdom, finally applied to AI orchestration.

The reason it works is not that the methodology is clever. The reason it works is that the methodology refuses to be cleverer than it needs to be. It uses the simplest possible substrate — folders and text files — and lets the structure of those substrates do the work that more complicated architectures spend code trying to recreate.

What an ICM workspace actually looks like

A workspace for a content production pipeline might look like this:

my-business/
├── CLAUDE.md
├── CONTEXT.md
├── stages/
│   ├── 01_research/
│   │   ├── CONTEXT.md
│   │   ├── references/
│   │   └── output/
│   ├── 02_draft/
│   │   ├── CONTEXT.md
│   │   ├── references/
│   │   └── output/
│   └── 03_publish/
│       ├── CONTEXT.md
│       ├── references/
│       └── output/
└── _config/
    ├── voice.md
    └── conventions.md

That is the entire system. There is no application code anywhere. The numbered folders represent the stages of the workflow. Each stage's CONTEXT.md is a markdown file that tells the AI what to do at that step — what inputs to read, what process to follow, what outputs to produce. The references/ folders hold the company-specific knowledge each stage needs: voice guidelines, design conventions, domain knowledge. The output/ folders are where the agent writes its work, and where the next stage reads from. The _config/ folder holds the company's reference material that every stage might need to access.

When the agent runs, it reads the workspace's CLAUDE.md to understand the overall structure, then navigates to whichever stage it is currently executing, reads that stage's CONTEXT.md, loads the relevant references, and produces output to the output/ folder. The next stage reads from there, and the cycle continues.

A non-technical operator who wants to change how the system writes can open _config/voice.md and edit the voice guidelines directly. The next time the workflow runs, the new guidelines are in effect. There is no deployment, no compile step, no developer needed. The text file is the configuration.

This is what I install for every client. The exact folder structure differs based on what the audit surfaced — every business has a different ontology, and the architecture has to mirror the specific structure of each business — but the underlying methodology is the same. Folders for stages. Markdown for context. Plain text everywhere. Git for version control. No server. No proprietary platform. No vendor lock-in.

Why this is the right foundation for ontological work

The reason ICM is the correct technical foundation for ontological work specifically is that the architecture has to be able to mirror the structure of the business with high fidelity. You cannot install a generic AI system on top of a corrected ontology and expect the correction to hold. The architecture has to reflect the specific structural reality of the company — what is primary, what is secondary, what relates to what, where the work actually flows.

In a framework-based AI system, the structure of the business is hidden inside application code. The developer encodes the workflow logic, and the workflow logic encodes some implicit picture of what the business is. If that picture is wrong, or if the picture changes, the code has to be rewritten. The cost of misalignment is high, and the cost of correction is high, so the system tends to stay misaligned.

In an ICM workspace, the structure of the business is explicit. The folder names are the structural categories of the company. The numbered stages are the actual workflow. The reference files are the actual knowledge. If the audit surfaces that a software company is really a knowledge-transfer service, the workspace can be rebuilt to reflect that — the folders rename, the stages reorder, the references update, and the corrected ontology is now encoded in the operating layer of the business. This kind of rebuilding is essentially free in ICM. In framework-based systems, it is a project.

The other reason ICM is the right foundation is that the architecture has to remain editable by the team for the long term. The audit produces a correct ontology at one moment in time, but the company will continue to evolve. The team needs to be able to update the architecture as the business changes, without calling me back every six months. Because everything is plain markdown, they can. The architecture grows with the company. It does not freeze the company at the moment of installation.

The deeper principle

What ICM gets right at a deeper level is that the best technology for a business is technology the business can operate without depending on its installer. The whole point of the install is to leave the company with something they own and can run.

Most AI consulting fails this test. The system gets built, the consultant leaves, and within six months the system is either degraded (because nobody can maintain it) or dependent (because the consultant is still on retainer). Neither is a good outcome. The company spent significant money and ended up either with broken infrastructure or with a long-term cost center.

ICM passes this test by design. The architecture is portable, inspectable, editable, and built on tools every team already has — folders, text files, Git. There is no special skill required to operate it after installation. The training session at the handoff teaches the team how to extend the architecture themselves, and the playbook documents the structural reasoning so future team members can pick it up.

This is the standard I hold for every install. If the team cannot operate the system without me afterward, the install was incomplete. ICM is the only methodology I have encountered that lets me meet this standard reliably, because it builds on the simplest possible substrate.

If you want to read the full paper, it is linked from the main page of this site. The paper is short — twenty-one pages — and worth reading in full if you are seriously considering installing AI architecture in your business. Even if you do not work with me, understanding ICM will help you evaluate any other vendor you talk to. Most of what is being sold as "AI infrastructure" is more complicated than your business actually needs, and now you have a reference for what simpler looks like.

The founder usually doesn't ask this because they think the question is settled. They wrote the pitch deck. They have a tagline. They know what they sell. The question feels rhetorical. This is a software company. This is a fleet operator. This is an agency. The category seems obvious, and the obviousness of the category is exactly why the question stops getting asked.

But the category is not the ontology. The category is the label. The ontology is the actual structural reality of what the business is — what exists inside it, what relates to what, what it is primarily doing when you watch it move, and what it is secondarily doing as a side effect. The label and the ontology are usually different. The gap between them is where most business friction lives.

This essay is about how to read that gap. What an ontology actually is, why it drifts, how to surface the version your company is actually running from, and what changes when you do.

What ontology means when applied to a business

Ontology, in philosophy, is the study of what exists. Not what we think exists, not what we say exists — what is actually there. When applied to a business, ontology asks: when you point at this company, what category of thing are you pointing at? Not what does it call itself. Not what does it sell. What is it, structurally, as an operating entity in the world.

This sounds abstract. It is not. Here is how it shows up in practice.

A software company sells software. That is the label. But when you look at what the company actually does day to day — what its operators spend their time on, what its customers reach out about, what determines whether a deal closes or doesn't — the picture often shifts. The software is delivered, yes. But what the customer is actually buying is a relationship with a team that knows their industry and translates that knowledge through a product. The software is the medium. The relationship is the substance. If you took the same software and shipped it without the relationship, the customers would not pay for it. If you took the same relationship and delivered it through a different medium, they would still pay.

The label is "software company." The ontology is "knowledge-transfer service that uses software as the delivery layer." Those are not the same thing. And the difference matters, because every operational decision the company makes will be calibrated to one or the other. If the company believes it is a software company, it will hire engineers, invest in product features, and treat customer success as a cost center. If the company knows it is a knowledge-transfer service, it will hire industry experts, invest in customer onboarding, and treat the software roadmap as in service to the relationship.

These are different companies, even though they have the same product and the same revenue. The label says one thing. The ontology says another. The team operates from whichever one is implicitly believed, regardless of what the website says.

How ontologies drift

Companies do not start with the wrong ontology on purpose. They start with the ontology that was true at founding. The founder has a clear picture of what they are building, and for the first stretch of the company's life, the picture matches the reality. They wrote the deck about what the company is. The team executes against the deck. The customer experiences what the deck promised.

Then the company changes. It always does. Three things drift the ontology:

The customer teaches you what you actually sell. Founders pitch what they think they sell. Customers buy what they actually want. The gap between those two is where the company learns. Over time, the company's revenue is increasingly weighted toward whatever the customer values, not whatever the founder originally pitched. By the time the company has real revenue, the customer has quietly revised the ontology — often without the founder noticing.

The team teaches you what you actually do. The founder's original vision is the company's first ontology. As the team grows, each new operator inherits a slightly different picture of what the company is, because they joined at a different time, took on a different scope, and had to build their own mental model to function. By the time the company has thirty people, there are thirty partially-overlapping pictures of what the company is, and the official picture (the founder's deck) is just one of them.

The market teaches you where you actually fit. The competitive landscape, the regulatory environment, the macro conditions — all of these put pressure on the company to occupy a specific position. The position the company is forced into is often different from the position it was designed for. Over time, the company shapes itself to survive in the market it actually operates in, not the market the founder originally imagined.

These drifts are not failures. They are normal, healthy, even necessary. A company that does not let its ontology evolve is a company that refuses to learn. The problem is not that ontologies drift. The problem is that the official ontology — the one the founder describes, the one the marketing speaks to, the one the org chart implies — usually does not drift with them. The actual ontology moves. The stated ontology stays. The gap between them widens.

What the gap costs

Most businesses I read are operating with a substantial gap between stated and actual ontology. The cost of the gap shows up in specific places.

Hiring decisions. A company that hires for the stated ontology hires the wrong people. Job descriptions are written against the label, not the substance. The candidate gets hired for one set of skills, then walks into a daily reality that requires a different set. They struggle, the team struggles, and nobody can articulate why because nobody has named the gap.

Strategic decisions. Strategy is downstream of ontology — it assumes the question of what we are is settled. If the strategy is built on the stated ontology but the company is operating from the actual one, the strategy will systematically point the company in the wrong direction. Initiatives launch with great clarity and then never quite produce the expected results. Nobody can find the bug, because the bug is at a layer below where the strategy is being executed.

Marketing copy. Marketing speaks the stated ontology because that is what the founder approved. The customer responds to the actual one. The disconnect produces conversion problems, brand confusion, and an inability to articulate why some leads convert and others don't. The good copywriters intuit the actual ontology and write to it. The mediocre ones speak the stated one fluently.

Founder experience. This is the most expensive cost of all. A founder operating with a wide gap between stated and actual ontology feels constantly off. Decisions feel harder than they should. Meetings drift. The work that should be exciting feels heavy. The founder cannot name what is wrong because, from the inside, the company looks like the deck. The deck is correct, on paper. The work is correct, on paper. But the felt experience is wrong, because the founder is daily operating from one picture while running a company that is structurally a different picture.

When the gap is closed — when the actual ontology is named clearly and the company aligns to it — most of these costs disappear. Not because the company changed. Because the company stopped fighting itself. The strategy now matches what the team is actually doing. The hiring now matches what the work actually requires. The marketing now matches what the customer actually buys. The founder now experiences the company they are actually running, instead of the company they think they are supposed to be running.

How to read the actual ontology

The actual ontology is not hidden. It is surfaceable in conversation, if you know what to listen for. Four signals matter most.

What the founder says when nobody is judging. When you ask a founder to describe their company at a board meeting, you get the stated ontology. When you ask the same founder to describe their company over a long dinner, with no agenda, you usually get something different. The version that comes out in private is closer to the actual ontology. The disagreement between public and private descriptions is itself data.

What the operators say when you ask them separately. If three senior operators on the team describe the company to you in three private conversations, and the descriptions diverge, the divergence is information. The actual ontology is somewhere in the overlap of what they all say, plus the things they all mention that the founder didn't.

What the customer says they bought. Not what the customer said when they signed the contract. What they say six months later, when they describe to a friend why they keep paying. The friend version is the actual ontology, expressed from the buyer's side.

What the company does when it is under pressure. When a deal is at risk, when a customer threatens to leave, when an emergency comes up — what does the company actually mobilize? The thing the company mobilizes for is the thing the company actually values. The thing the company lets slide is the thing the company doesn't actually run on, regardless of what the deck says. Behavior under pressure reveals ontology faster than any other diagnostic.

When you triangulate across these four signals, the actual ontology surfaces. Not as a single sentence, but as a shape. A pattern. The thing the company keeps trying to become every time it makes a decision, even when nobody has named it yet.

What changes when the ontology is named

A founder who reads a clear, accurate articulation of their company's actual ontology — for the first time, in writing, by someone outside the company who has no reason to flatter them — typically responds the same way. There is a long pause. Then a quiet sentence that means some version of "yes." Sometimes more specifically: "I have known this for a year and could not say it." Sometimes: "I have been making this decision and avoiding that decision for reasons I could not explain, and now I can explain them."

This is not magic. It is not transformation. It is the structural relief of finally having language for something that was already there. The company was already this. The founder was already operating from this. The only thing that changed is that now it is named, and a named thing can be acted on. An unnamed thing can only be felt.

After the naming, the work becomes obvious. The hiring decisions snap into focus. The strategic priorities reorder themselves. The marketing copy starts to write itself, because there is now a clear thing to write about. The founder begins to experience their own company as the thing it actually is, rather than the thing the deck says it should be.

This is what an ontological audit produces. Not advice. Not strategy. Not a list of recommendations. A written articulation of what the company actually is, delivered to the founder in a form they can read, sit with, and act on. The audit does not change the company. It makes the company visible to the people running it.

The deeper claim

What I want to leave you with is this: most of the problems founders bring to advisors are not strategy problems, hiring problems, or operational problems. They are ontology problems wearing the costume of strategy, hiring, or operational problems.

A founder who cannot decide between two strategic options is often facing a hidden ontological choice — which version of the company do they actually want to be running? A founder who cannot find the right hire is often facing a hidden ontological gap — they are hiring for the stated ontology but need someone who fits the actual one. A founder who is exhausted by operational complexity is often running a company whose stated structure does not match its actual structure, and the friction is the price of operating from two pictures at once.

When you work the ontology layer first, most of the downstream problems either solve themselves or become much easier to solve. Strategy becomes simpler when you know what company you are running strategy for. Hiring becomes clearer when you know what role actually needs to be filled. Operations become smoother when the structure matches the work.

This is the layer the practice works first. Everything else is downstream.