Literate Graphs: How metapad Runs Our workOS
transentis runs its own business on metapad. This post opens up two of our working models — a marketing model that holds our strategy, brands and content as a queryable graph, and a masterdata model that acts as a digital twin of the practice, with a real-time view of our sales, project and financial KPIs. A worked example of the workOS pattern, from the inside.
We don't just sell model-driven transformation — we run our own company on it. This is a look inside two of the metapad models transentis operates on every day: the one that runs our marketing, and the one that runs our practice as a live digital twin.
At a Glance
Most companies run on a scattered pile of artefacts: a strategy deck, a CRM, a spreadsheet of capacity, a wiki nobody reads, a folder of proposals. Each is tidy on its own; together they drift out of sync the day after they're written. A workOS is the alternative — strategy, operations, systems and measurement held in one connected, computational model of how the business actually runs.
We don't just describe that pattern. We run on it. In this post we open up two of the metapad models transentis operates on daily: a marketing model that holds our brands, offerings, audiences, campaigns, strategic moves and every piece of content as a queryable graph — the model this very post is a node in — and a masterdata model that acts as a digital twin of the practice, from people and projects all the way to a real-time view of our sales, project and financial KPIs. Different domains, same rules: structure and narrative in one source, projections rendered from it, and an AI grounded in a typed graph rather than a wall of prose.
1. The workOS, briefly
We've written before about the PersonalOS — a second brain built as a knowledge graph, where your notes, journal, tasks and the links between them become one model you can think with rather than a pile of files you search. A workOS is the same idea at organisational scale, and we made the general case for it in A computational knowledge graph of your enterprise.
The short version: instead of describing how your company runs across a dozen disconnected documents, you build one model of it — typed, linked, and computational. Strategy connects to the offerings it shapes; offerings connect to the people who deliver them; delivery connects to the numbers it produces. You stop asking "which document was that in?" and start asking "what does this connect to, and what happens if it changes?"
That's the theory. This post is the practice — two of our own models, opened up.
2. Worked example one — the marketing model: strategy in the open
The first model runs our go-to-market. It holds, as typed and linked nodes, the things a marketing strategy is actually made of:
| Node type | What it holds |
|---|---|
| Brand | transentis consulting, metapad, our academy site — each with its positioning, mission and messaging layers |
| Product / Service / Workshop | What we sell, from the Re-Think Your Operating Model with AI Workshop to Operating Model Transformation |
| Audience | The role-based segments we serve — Operations Leaders, Transformation Leaders, Modelling Practitioners |
| Channel & Campaign | Where we reach people, and the campaigns that bundle the work |
| Content Piece | Every blog post, LinkedIn post and email — including this one |
| Strategic Move & Goal | The bets we're making, each with an explicit success metric |
| Decision Log | Why we made the structural choices we made, with the alternatives we rejected |
The point isn't the inventory — it's that these are wired together. A Content Piece is part_of a Campaign, targets specific Audiences, and promotes a particular offering. A Strategic Move advances a Goal that a Property measures. Change a Brand's positioning, and the affects edges show you exactly which content now needs a second look.
How we actually work with it
Here's the part that surprised us most: the model changed how the two of us argue about strategy. Marketing decisions used to happen in the usual way — a message batted around in chat, a slide reworked three times, a positioning statement that lived in whoever's head last touched it. Now the argument has a shared object.
When we sharpen a brand message, we don't debate an abstraction. We open the Brand node, read its current positioning and messaging layers, and edit them in place — a human and an AI assistant working on the same live artefact, in the conversational way we build every metapad model. When the change is structural — a service renamed, an audience retired, a positioning shifted from "enterprise" to "system" — we don't just make it and move on. We write a Decision Log node capturing the why and the alternatives we weighed, and wire it with affects edges to everything downstream. Six months later, when someone asks "why did we drop that segment?", the answer is a node, not a memory.
The payoff is strategy you can interrogate. Which content pieces advance our move to reduce single-client concentration? Which audience does no current campaign actually reach? What have we committed to that no goal measures? These aren't questions a slide deck can answer — but they're one query away when your strategy is a graph.
A slide deck tells you what you decided. A model tells you what your decision connects to — and what breaks if you change your mind.
This is also, deliberately, strategy in the open. Because the model is honest — it records that metapad has few serious external users yet, that most of our revenue still sits with one client — it's useful precisely where a polished deck would gloss. A workOS that only holds good news isn't a model of the business; it's marketing for the boardroom.
3. Worked example two — the masterdata model: a digital twin of the practice
The second model is bigger, and it does a heavier job. If the marketing model is how we think about the outside of the business, the masterdata model is a digital twin of the inside — a living model of how transentis-the-practice actually operates.
It holds our people (their skills, capacities, professional backgrounds, languages and history), our projects and the customers they were delivered for, our references, and — this is what makes it a twin rather than a directory — the commercial reality underneath all of it: orders, billing rates, fixed-price revenue, yearly capacity and cost. Hundreds of projects, dozens of people and customers, all typed and connected.
Why it's a twin, not a database
A database would tell you who has Python skills. The twin tells you something a database can't:
- It computes. Capacity, utilisation and availability aren't fields you maintain by hand — they're derived from the graph.
- It carries narrative. A reference isn't a row; it's an engagement with a story attached — what we did, what it demonstrates, what's safe to say publicly.
- It generates projections. Capability matrices for proposals, reference decks, RFP boilerplate — rendered from the model rather than maintained alongside it.
A live view of the numbers
The most recent step is the one we're most pleased with, and it's worth being precise about how it works — because the mechanism is the point. The masterdata model holds the stable core of the practice: the projects, the people, the rates. Every day, we pull live data on what our consultants are actually working on from JIRA and push it into our data warehouse — and even that step already leans on the model, because raw JIRA records only become meaningful once they're enriched with the master data: whose project is this, at what rate, against which order.
On top of that sits the twin's front end, and it reads from three places at once: the masterdata model for the reference and commercial layer (billing information, consultants' real names, contract terms), JIRA for the real-time picture of work in flight, and the data warehouse for the long-range historical view. Together they give us a real-time overview of our sales, project and financial KPIs — pipeline, revenue, utilisation, capacity — not a quarterly spreadsheet that's stale two weeks after it's built, but a live read on the state of the practice, grounded in the same model that holds the people and projects the numbers describe.
That's the difference a twin makes: the metric and the thing it measures live in the same model. When a project closes, the revenue figure moves, the capacity calculation updates, and the reference becomes available for the next proposal — because they were never separate records to begin with.
So far, that gives us two of the three time horizons: JIRA shows us the present, the warehouse shows us the past. What we're building right now is the third — wiring the twin into metapad's simulation capabilities so it can also show us the future: not just report where we stand, but project where we're heading, and let us test alternative futures before we commit to them. It's the same move we make with clients, turned on ourselves.
A few of the questions it answers on a normal working day:
- "Who could staff an operations-research-heavy feasibility study in transport, available within eight weeks?" — a query against skills and capacity, answered completely, rather than three messages to senior people and a partial reply by lunchtime.
- "Which references demonstrate computational simulation across loyalty, mobility and supply chain?" — three references with their narratives attached, exportable to proposal format, instead of scrolling a folder of old slide decks.
- "What's our billable capacity over the next three months, by skill?" — a live answer, not a spreadsheet someone last refreshed in April.
- "Where do we stand on revenue and pipeline this quarter?" — the KPI overview, current to the warehouse.
4. One source, many projections, no drift
Both models do the same two jobs at once, and this is the heart of the workOS pattern. They run the work, and they document it — from a single source.
In a conventional setup those are separate efforts that constantly fall out of step: the strategy deck says one thing, the CRM another, the capacity sheet a third, and the wiki describing all of it went stale months ago. In a workOS there's nothing to keep in sync, because the documentation is a projection of the model that runs the work. Update a person's skills and the next proposal's capability matrix reflects it. Close a project and the references list, the capacity numbers and the KPI view all move together. Log a positioning decision and the content it affects is flagged automatically.
It also changes what an AI assistant can do for you. Point a chatbot at a folder of documents — the technique known as retrieval-augmented generation, or RAG — and it can pull the right paragraph out of a long file. Useful, and in practice you want it. But RAG reads text; it can't tell you that this consultant's availability, that client's history and this quarter's pipeline together make a particular bid worth pursuing, because that connection was never written in any one document. The graph knows, because the connection is part of its structure.
Search finds your words. RAG finds your paragraphs. A computational knowledge graph answers questions about how your business actually fits together — and lets an AI answer them with you.
We'll be honest about what this isn't. We haven't solved knowledge management, and neither model is finished — a literate model is a living artefact, not a completed one, and it still takes curation. What we've done is collapse three artefacts into one — the database, the diagram and the document — move our AI grounding from prose to a typed graph, and turn our documentation into projections that can't drift from the thing they describe.
5. Why this matters beyond us
We're a small practice, and that's the point, not a caveat: it's because we run these models end to end that we can open them up and show you the insides. The pattern doesn't depend on our size — clients in mobility, telecom and aviation build operating-model twins on metapad at far larger scale. Ours are simply the ones we can show you honestly.
And it's the same pattern we build with clients. The free Re-Think Your Operating Model meetup shows the workflow on a fictitious company. The AI-Driven Operating Model Workshop applies it to your operating model with your documents. Operating Model Transformation runs the resulting change. And an Enterprise Digital Twin keeps the model live long after the workshop — exactly as our own masterdata model is live for us.
The practice we run on is the proof of the practice we sell. This post is, in a real sense, transentis's own digital twin held up as a reference: we asked our business a question this morning and the model answered.
6. The same pattern, at three scales
If this feels familiar, that's the whole idea. It's one pattern, and you can meet it at whatever scale you like:
- A PersonalOS — a second brain: your notes, journal and tasks as a graph you can think with.
- A workOS — this post: a company's strategy, operations and numbers as a model it runs on.
- An Enterprise Digital Twin — the same thing at the scale of a large organisation, with simulation on top.
Learn the pattern on your own notes and you've learned the pattern that runs a practice. Learn it on a practice and you've learned the one that scales to an enterprise. Different domain, same rules every time: structure and narrative in one source, projections rendered from it, and AI grounded in a typed graph rather than a pile of prose.
7. What's Next
The alternative to a pile of drifting documents isn't a better document. It's a model — typed, linked, computational, and shared between the humans and the AI who work on it.
Want to see it built? Join the free Re-Think Your Operating Model webinar and watch a workOS take shape on a live model in about an hour.
Want it for your own business? The Re-Think Your Operating Model with AI Workshop applies the workflow to your operating model, with your documents — and leaves you with a model you can keep running.
Want to start from scratch? Metapad is free to begin — design your own model, and run your business against it instead of against your slides.
A workOS isn't where you file how your company runs. It's where how your company runs stays true to itself.