The digital company
A simulated organisation a chief executive can interrogate
Employees, departments, customers, vendors, financials, contracts and workflows, held as one running model rather than a dashboard. Ask it a question, it runs itself forward, and it tells you what happened and who caused it. That is the direction. This page says exactly how far along the road the software currently is.
What is built and what is notWhat exists today
Most of the architecture is here. The depth of the operating model is not.
Every company already runs a simulation of itself. It is just distributed across forty people and nobody can query it.
The chief executive asks what happens if we do this, and gets four answers from four people who each see one part of the machine, none of whom can show their working, all of whom are partly right. The idea here is not to replace that judgement. It is to give it a model that holds the whole shape at once, says which assumption it is standing on, and can be argued with in public.
The idea
What a digital twin of an organisation would have to do
A digital twin of a physical thing is not a diagram. It is a model detailed enough that you run the real decision against the model first. That is the standard worth holding an organisational twin to as well, and it is a high one.
It would need to know who does what, what depends on what, where the work actually queues, who reacts to what, how long everything takes, and how the whole thing responds to being poked. Then it would need to be trustworthy enough that a decision gets tested against it before it gets made.
- Model the whole ecosystem, not only the parts a spreadsheet can hold
- Give every actor its own objectives, so the model can disagree with itself
- Be honest about what it is guessing, and rank its guesses by how much they matter
- Run fast enough that the follow up question costs nothing
- Show its working, so it can be argued with rather than believed
The honest ledger
Built today, or not built
| In the software now | |
|---|---|
| Knowledge graph built from your own files, with citations | yes |
| Agent generation across nine classes, with objectives, constraints, knowledge and personality | yes |
| Multi agent simulation of a year, month by month, hundreds of times | yes |
| Scenario levers across price, people, supply, customers, growth, money and market | yes |
| Sweeps across one lever or a grid of two, with thousands of simulations behind a curve | yes |
| Briefs with the mechanism, the band, the tripwires and the assumptions | yes |
| Assumption ledger with origins, bands, locks and sensitivity analysis | yes |
| Workflow level simulation: queues, handoffs, the actual path a job takes through the company | no |
| Individual employees modelled below department level | no |
| Calendar and process mining from the systems the work actually happens in | no |
| Live data feeds from your accounting, CRM or payroll | no |
| Anything that learns from how your decisions actually turned out | no |
Nothing in the bottom five is on a roadmap slide pretending to be a feature. They are listed here because they are the difference between what this is and what the first paragraph of this page describes.
Built
What the architecture already gets right
The hard structural decisions are made and they are the ones that would be expensive to change later. Facts carry their provenance from the file to the brief. The ledger is separate from the engine, so uncertainty is a first class thing rather than a caveat. Agents are data, so they can be inspected and edited rather than being functions somebody wrote.
The simulation is deterministic given a seed, which means results are reproducible and comparisons are controlled. And the whole thing runs as arithmetic with no dependency on a language model, which is what makes it auditable at all.
Adding depth to the operating model does not require any of that to be rebuilt. That is the actual claim, and it is a claim about architecture rather than about capability.
Not built
What is missing, and why each one is hard
These are not oversights. Each of them is a substantial piece of work with its own risk of being wrong in a way that is hard to notice, which is the failure mode this whole product is built to avoid.
- Workflow simulation needs a real model of how work queues and hands off, and a wrong one would produce confident nonsense about capacity
- Individual employees need data most companies do not have in a usable form, and modelling named people carries obligations a simulation should not take on lightly
- Process mining needs read access to the systems where work happens, which is a different trust conversation from uploading a file
- Live feeds turn a model you inspect into a model that changes under you, and the reproducibility that makes comparisons valid would have to be redesigned around it
- Learning from outcomes needs outcomes, which means years of decisions and results from the same company, held in a way that does not simply overfit to the last thing that happened
The road
What would have to be true for the bigger version
The company level model has to be trusted first
Nobody should build a workflow simulator on top of a twin whose gross margin nobody has checked. The ledger, the bands and the tripwires have to be doing their job on real decisions at real companies before depth is worth adding.
Tripwires have to be tested against what actually happened
The honest measure of a model like this is not whether its central forecast was right. It is whether its early signals fired when it was wrong. That needs decisions made, months elapsed and results compared, and there is no way to shortcut the calendar.
Structured operational data has to be available
A workflow model needs to know how many things arrive, how long each step takes, where they wait and who they wait for. Most organisations hold that somewhere, badly. Getting it out is the work, and doing it without becoming a surveillance product is the constraint.
The unit of simulation has to drop below the department
Today a department is a headcount, a cost and three weights. The next level down is roles with capacity, queues with backlogs, and handoffs with latency. That is a genuine rewrite of the people stage of the engine, and it should be done once and properly.
Live data has to arrive without breaking reproducibility
A twin that changes underneath you cannot be compared with itself. The answer is probably versioned snapshots, where every run names the version of the world it ran against. That is a design decision, not a connector.
And it has to stay inspectable at every step
The moment a part of this becomes a model nobody can open, the whole argument for it collapses. Depth is only worth having if every new layer can still show you the line it came from and the assumption it is standing on.
Why say all this
Because the gap is the interesting part
A page about a larger vision that does not say which parts are missing is a page asking you to buy something that does not exist. The reason to publish the gap is that the product is better than the vaguer version of itself: what is built is genuinely built, and what is not is genuinely not.
If you are here because the first paragraph described something you want, the useful next step is to try the thing that exists on a decision you are actually facing. It will answer that decision today. Whether it eventually becomes the larger thing depends on work that has not been done yet, and on evidence that has not been gathered yet.
The related pages
Everything on this site that bears on the question
Judge it on the part that exists
Bring one decision and one file. If the twin it builds is useful on that decision, the larger version is worth caring about. If it is not, no amount of vision makes up for it.