A Computational Knowledge Graph of Your Enterprise

OR: Why Metapad isn't Notion, Airtable, or Miro

You're a senior person, you've heard about Metapad, you click through to the homepage, and the question that won't sit still is: what is this, exactly?

It looks a bit like a wiki, but the diagrams are interactive. It looks a bit like a database, but the schemas talk back to you in plain English. It looks a bit like Miro, but the boxes can be queried, not just dragged around. None of the categories you already know quite fits.

That's not because the explanation is poor. It's because Metapad belongs to a category most people haven't met yet.

What Metapad builds is a computational knowledge graph — a connected, living, evolving map of your enterprise that you can interrogate the way you'd interrogate a senior colleague who actually understands the place.

The shift that lands when people meet Metapad for the first time isn't the diagrams or the database or the documentation. It's that they can have a conversation with their enterprise — and the conversation isn't a chatbot improvising on a folder of documents. Each exchange grounds in a structured graph that grows with the conversation itself. You ask, the graph answers from what it knows. You correct it, the graph updates. You explore a new angle, new nodes and connections appear. By the end of an hour, you have a working model of a piece of your enterprise that didn't exist when you started — and the conversation that built it is part of the artefact.

That is what makes a computational knowledge graph different from every other artefact you might have used to make sense of your business. It is connected — every entity has its place in a graph you can navigate. It is living — the graph evolves through use rather than freezing after it ships. It is queryable — ask it questions and get answers traceable to the structure. It is conversable — the AI assistant grounded on it isn't a generic chatbot; it knows what your enterprise looks like, because the structure tells it.

The structure also carries the prose: every node has narrative attached — what it's for, why it's shaped the way it is, what was considered instead. The why travels with the what. And the same graph carries computation: queries, AI conversations, simulations all run directly against it. Change one node and the prose, the queries, the conversations, and the simulations stay in sync because they're projections of the same source.

This is what Metapad is for. Everything else follows from it.

What Metapad is not

Most prospects arrive having mentally filed Metapad under a tool they already use. The fastest way to define a computational knowledge graph is sometimes to say what it isn't.

Not a wiki

Notion, Confluence, and the wiki family are prose-first. The page is the unit. Structure exists implicitly through hyperlinks, tags, and — in Notion's case — databases-as-tables. With enough discipline you can fake a knowledge graph in a wiki, but the structure is decoration on the prose, not the load-bearing thing.

The cost shows up the moment you point an AI assistant at it. AI grounded on a Notion or a Confluence is doing retrieval-augmented generation on documents. It pulls passages and stitches answers from them. It doesn't know that "Compliance" on page A is the same entity as "Compliance Office" on page B — the wiki doesn't model that; the human reader is expected to recognise the relationship.

In a computational knowledge graph, "Compliance" has an identity. Two mentions of it are the same node by construction. The AI doesn't have to recognise the relationship — the graph already encodes it.

Not a spreadsheet, and not an Airtable

Airtable, Excel, and the structured-tables family are data-first. Rows and columns are the unit. You can build genuinely impressive things — relational data, formulas, views — but the meaning of the data lives in column names and your team's tribal knowledge of what each table represents.

A structured database tells you what is true, but very little about why it's shaped the way it is. Open someone else's Airtable base after they've left the company and you'll spend a week reconstructing the assumptions. The structure is there; the rationale isn't.

A computational knowledge graph carries the narrative next to the structure. The "why" travels with the "what".

Not a whiteboard

Miro, Mural, and the visual-collaboration family are spatial-first. Position, colour, and connector lines are the unit of meaning. They are extraordinarily useful for workshops — and almost useless as long-lived artefacts, because the meaning lives in the visual gestalt and there is nothing structured for a machine to compute on.

Take a Miro board to an AI assistant and ask which initiative depends on which. The assistant looks at the board the way you and I do: as an image. The dependencies are there, but they're not addressable.

A computational knowledge graph is addressable through an API and queryable through AI grounded in the structure. The dependencies aren't just drawn — they are encoded.

Not Lucidchart, drawio, or any static diagramming tool

The diagramming family lives one step above whiteboards: cleaner output, more structure, exportable formats. But the structure exists only to render the diagram. The shapes have no behaviour, the connectors no semantics, and nothing computes.

The giveaway: try asking "what changes if I delete this box?" of a Lucidchart diagram. You'll get nothing back. The diagram doesn't know what it depicts — it just draws it.

A computational knowledge graph knows what it depicts because the diagram is a view of the underlying structure. Delete a node and the dependent edges go with it; the AI assistant grounded on the graph can tell you exactly what is now disconnected.

What changes when your knowledge artefact computes

Once your artefact has structure and narrative and computation in one place, five things change:

1. You can query it. Not search-the-prose; ask-the-graph. "Which services depend on Service X?", "Which decisions have we made about positioning, and what was considered instead?", "Which target audiences have no content piece aimed at them?" These are queries against a structured graph, not full-text searches against pages.

2. AI grounds on it differently. A computational knowledge graph is a fundamentally different substrate from a folder of documents. The assistant doesn't retrieve passages and synthesise — it reads structure. Answers stay traceable to the graph. You can ask "why did the assistant say that?" and trace the chain.

3. You can simulate it. When the structure includes dynamic behaviour — flows, capacities, delays — the same graph can be run as a simulation. Not exported into a separate simulation tool: run in place. The narrative and the simulation are the same artefact.

4. Narrative and structure stay in sync because they're one source. Every other approach (wiki + database + diagram tool, or worse) requires you to keep three artefacts aligned by discipline. In every team we've watched, the discipline fails within months. The drift is what kills knowledge artefacts. A computational knowledge graph removes the drift by removing the gap.

5. The prose pays its way. The narrative attached to each node isn't decoration — it is the operating documentation. Operating manuals, runbooks, website copy, slide decks, PDFs: all of them are projections of the graph rather than separately-authored artefacts. The cost of writing the prose is paid back many times by the documentation systems you no longer have to maintain.

We run transentis on computational knowledge graphs

Computational knowledge graphs aren't an intellectual artefact we publish about. They're the operational substrate the practice runs on. Here is a partial inventory of the graphs that keep transentis working — every one of them a live, queryable, AI-conversable graph on metapad:

The marketing graph — the one behind the blog post you're reading right now. Every Service we offer, every audience we target, every reference engagement, every campaign, every content piece is a node, narrated with the why and the what was considered instead. The graph decides what gets written, who it targets, what it's expected to advance. The web pages on metapad.ai are projections of it.
The masterdata graph — our internal digital twin. People, projects, clients, capacities, capabilities, dependencies. Used for staffing decisions, capacity planning, knowledge transfer, and the kinds of "who could do this work?" questions that normally require a Slack message to three senior people. Live, current, queryable.
The CVs and project references graph — every consultant's profile, every project reference, every skill and domain, each as a node, related to the engagements that demonstrate them. RFP responses are queries against this graph. "Have you done loyalty-programme simulation? Show me three references. Who staffed those? Are they available?" — the graph answers, in seconds, with the prose to back it up.
The systems-documentation graph — the tools we use, the integrations between them, the data flows. The graph is the system map and the documentation about the system. Change one and the other stays current by construction.
Client operating-model graphs — for every transformation we run with a client, we build (with them) an explicit graph of their operating model: capabilities, processes, decision rights, KPIs, dependencies, partner interfaces. The graph survives the engagement and stays useful: queryable for decisions, conversable through AI, simulatable when dynamic behaviour is added.

In each of these cases, the artefact serves two purposes simultaneously, and that combination is the point:

It runs the work. The marketing graph decides content priorities. The masterdata graph staffs projects. The references graph answers RFPs. The client graph carries the transformation.
It documents the work. The prose attached to each node is the operating procedure. It explains what the node is, what it's for, what was considered before this shape was chosen, what's known to be open. And it stays in sync with the structure because structure and prose are the same artefact.

This second point lets us collapse what is usually two artefact systems into one. Most organisations maintain a system (Notion + Airtable + Slack + a folder of process docs) and documentation about that system (an out-of-date wiki page, a slide deck, an org chart last refreshed in 2019). A computational knowledge graph fuses them. The structure and the prose are one source.

And because the source is structured, the projections we generate from it look like real artefacts: the website you're reading is rendered from the marketing graph. Operating manuals are rendered from the masterdata graph. RFP responses are rendered from the references graph. PDFs, runbooks, dashboards, slides — generated, not authored. When the source changes, the projections change with it.

The prose isn't decoration. It's doing operational work — the documentation pipeline running itself, with the graph as the source. (For the architectural lineage behind this — the parallel to Knuth's literate programming, applied at the knowledge graph layer — see our companion piece Literate graphs: when your knowledge graph documents itself.)

The clients we work with end up running their transformations on computational knowledge graphs too — starting from a graph we build with them in a workshop, extending it through the transformation itself, generating their own operating manuals from the same source. Not because we sold them on "knowledge graphs". Because once they've experienced the difference, the question becomes why would we ever go back?

From workOS to PersonalOS — the same pattern at individual scale

The workOS pattern — computational knowledge graph as operational substrate, with projections rendered from it — scales down as cleanly as it scales up. The individual version is sometimes called a second brain: journal entries, notes, todos, contacts, projects, and the relationships between them — all as a single graph rather than a Notion vault and a Things app and an Apple Notes folder and a contacts database that have stopped speaking to each other.

The rules are the same. Structure, narrative, computation, in one source. The same Metapad. The same AI assistant. Just a different domain. If the workOS angle made you wonder whether the same pattern works at personal scale: yes, and we've written that up separately — A Second Brain on Metapad: a Zettelkasten Metamodel you can fork.

And if you want to zoom in on one of the projections we mentioned — the metapad.ai website itself, rendered from a graph rather than authored as static pages — From Model To Site: How Metapad Knowledge runs metapad.ai is the dedicated deep-dive.

So what is Metapad?

The shortest answer that doesn't mislead: Metapad is the platform for building computational knowledge graphs — the kind that don't just describe your business, but run it.

It is a wiki and a database and a whiteboard and a simulator and a documentation generator — but those categories miss the point. The point is the artefact: a computational knowledge graph holding structure, narrative, and computation in one source, generating the projections (web pages, manuals, runbooks, PDFs, dashboards) that used to require separate systems to maintain.

If your business today lives across a Confluence space, an Airtable base, a folder of Miro boards, and three half-current internal manuals — and you spend more energy keeping the four aligned than working with them — that's the problem computational knowledge graphs exist to solve.

Welcome to a category that didn't have a name yet.

TL;DR — what each tool is

Tool family	Unit of meaning	What's missing for a computational knowledge graph
Wiki (Notion, Confluence)	Page (prose-first)	No structured entities — they exist only by reference, not by identity
Database / table (Airtable, Excel)	Row (data-first)	No narrative attached; rationale lives outside the artefact
Whiteboard (Miro, Mural)	Spatial position (visual-first)	No machine-readable structure; meaning is in the gestalt
Static diagramming (Lucidchart, drawio)	Diagram (visual-first, slightly more structure)	The structure is decoration for the picture, not addressable
Computational knowledge graph (Metapad)	Connected nodes + edges, with narrative attached and computation running directly against them — projections (sites, manuals, RFPs, dashboards) generated from the same source	—

*Want to see a computational knowledge graph get built from scratch, live, with AI in the loop? Join us for Re-Think Your Operating Model — Live, with AI — a 1-hour live session