What Building My Own Digital Twin Taught Me About Data Silos

My watch, my Neko Health scan and my NHS record had never met until recently, when I used AI to put them on one timeline. In the businesses I work with, joining systems is usually the part everyone worries about. In my own build it turned out to be the quick part. The slow part, and the one that taught me most, was agreeing what each number meant once the sources sat side by side.

I'm keeping my own results private, so there are none here. The lessons are a different matter, because every one of them maps almost exactly onto what happens when a business joins its CRM, its finance system and its project tool.

What is a data silo, and why is joining them the easy part?

A data silo is information held in one system that the others cannot see. Each one is usually good at its own slice. My watch records what happens every day, the scan is a detailed picture of a single morning, the NHS record holds the history and lab results arrive as reports. None of them was built to know about the others, and none of them is wrong to work that way.

A business has the same shape. In the government's latest business data study, 86% of businesses that handle digital data work with customer data, 67% with financial or accounting data and 65% with sales data, and in my experience each of those usually lives in its own tool. The CRM knows who you won and when, the finance system knows what you invoiced and what it cost, and the project tool knows what was delivered. The questions that matter tend to sit between them, such as why margin fell on the accounts you won fastest, and no single system can answer a question it has only half the data for.

Joining silos used to be the expensive step. It is much less so now, because AI will read an export, an API or a PDF report and pull out the fields you need, and working across your tools rather than inside each one has become a normal build rather than a special project. The exception is a system you cannot read at all. When Designs4You came to us, their project management tool had no API and no integrations, with 13,000 contacts in a closed system and customer data effectively trapped, so the foundation had to change before anything could be joined. That situation is rarer now, and when you are in it, it is obvious.

The same measure can mean two different things

The first surprise came early. Two of my sources gave the same measure two different normal ranges, so a single reading could sit comfortably inside one range and outside the other. My first version judged each result against the range of whichever source it came from, which sounds fair and makes the page close to useless, because a green on one row no longer means what a green means on the next. The fix was to pick one named range for each measure and say on the page which one it is.

Ask a CRM, a finance system and a project tool how many customers you have, and you will usually get three numbers that are all correct. The CRM counts accounts with a won deal, finance counts whoever was invoiced in the period, and the project tool counts whoever has a live job. Revenue splits the same way, booked when the deal closes, recognised when the work is done and received when the money lands. Each figure is right for the system that holds it, and put into one dashboard without a ruling, each one looks like it contradicts the others.

Official statisticians live with this. The ONS publishes two estimates of the number of jobs in the UK, and in its April 2025 reconciliation one was 1.724 million (or 4.9%) higher than the other. Once adjusted for the factors it could measure, the gap fell to 0.974 million (or 2.7%). Part of the reason is definitional, since a person can have more than one job, and some jobs may be shared by more than one person. If two national surveys can disagree by more than a million over what counts as a job, a CRM and a finance system can certainly disagree over what counts as a customer.

The answer I reached for my own record is the one I would give any business. Name one definition for each measure, write it down once along with the system it comes from, and have every report and every AI tool read from that list. Our own case study puts it as needing a clear contract for what each field means, and it applies just as much once the fields come from different places. Processes drift in exactly the same way, and an automation will quietly pick one team's version of the work unless someone decides first. Numbers are no different.

Every link needs a reason and a source

The twin lights up areas of the body from the measures that relate to them. There are more than a hundred of those links now, and every one carries a written reason and a source. I insisted on that early, because a glowing organ with no explanation is worse than no glow at all. I have checked only a handful of the links myself so far, which is precisely why the reasons have to be on the page, so that I can open any one of them the day it matters and see whether I agree.

There was a second rule that came out of the same thinking. A single reading is not allowed to colour a whole area on its own, because an odd result on a single morning should prompt a question, and should not change the picture until something else agrees with it.

A dashboard tile that marks an account as at risk is a link of exactly this kind. If nobody can say which fields turned it red and why those fields were chosen, people either ignore it or obey it, and both are bad outcomes. Writing the reason next to the rule costs almost nothing while you are building it, and it is the only way the next person can disagree with it sensibly. It is a close cousin of recording the reason when a decision is made, applied to the rules inside the system rather than the decisions people make with it.

Today is never finished

The watch taught me this one. The day I take an export is always a part day, so a chart that includes it shows a sudden drop that never happened. The twin now leaves that day out, and it is the smallest rule in the build and probably the one that has saved me the most confusion.

Most businesses I have worked with have their own version. Revenue looks down on the ninth of the month because it is the ninth, a Monday pipeline report is missing half of Friday's updates, and finance shows last month as open until the close is done. Joining systems makes this worse, because each one finishes its period at a different time. The CRM is current to the minute while the finance figures may be weeks behind, so the newest period in a joined view is nearly always comparing a finished number with an unfinished one. Mark the current period as unfinished, or leave it out of any comparison until every source has closed it.

Check the joined view against a number you already trust

One of the risk models in the twin builds its answer from several pieces of published research. Before I trusted it for me, it had to pass a simpler test, which was that for an average man it gave the same answer as the national figures from the ONS. At first it did not. One of the gaps came from a measure being read one way in one part of the model and a different way in another, and nobody would have spotted it from my own result, because there was nothing to compare my own result with.

National accounts are built on the same habit. The ONS describes quarterly GDP as a balanced measure of three approaches, output, income and expenditure, which it balances against each other rather than taking any one of them on trust.

The business version is reconciliation, and it is the step most often skipped. Before anyone trusts revenue by account, by sector or by salesperson from a joined view, last month's total should match the finance system's figure to the pound, and the customer count should match whichever definition you named. If the total is off, every split of it is off as well, and usually in ways that look like insight rather than error. The margin question is the classic case. It is exactly what a joined view should be able to answer, and exactly what it will answer wrongly if the revenue in it does not tie back to finance first.

Why the rulings are the part you own

Looking back, the code that joins my sources is the least interesting part of the build. If I started again tomorrow, the thing I would keep is the list of rulings, which range, which source wins, what an unfinished day means and which figure the whole has to match. Every one of them is a decision about meaning, and none of them came with any of the products I was joining.

A business is in the same position. Software will sell you connectors, and AI does the joining well. The definitions are business rules, though, and they are the part that makes a joined view yours rather than a nicer screen on top of the same silos. That is also why the maturity ladder puts writing down how the business actually works ahead of handing work to agents. A system that reads from your rulings can be trusted with harder questions, and one that guesses at them cannot.

Mine is still very young, and there is plenty left to work out. The joining is largely done. The rulings are still growing, and I suspect they always will be.

Practical takeaways

1. Expect the joining to be the quick part. If AI can read a system through an export, an API or a report, getting the data side by side is rarely where the time goes.
2. Name one definition per measure. Write down what counts as a customer, as revenue and as margin, and which system owns each one, before anyone builds a report on the joined data.
3. Put a reason and a source on every rule. Any score, flag or colour should say which fields drive it and why, so people can check it rather than ignore it.
4. Treat the current period as unfinished. Leave it out of comparisons, or mark it clearly, until every source has closed it.
5. Reconcile to a total you trust. Match last month's revenue and customer count to finance before trusting any split of them.

Frequently asked questions

What is a data silo?

A data silo is information held in one system that the other systems cannot see. Each silo is usually good at its own slice, such as the CRM for deals, the finance system for invoices and the project tool for delivery, but the questions that matter most often sit between them. A silo is a problem of visibility rather than of quality, so the data inside it can be perfectly accurate and still be no help to anyone working in another system.

Why do two systems give different numbers for the same thing?

Because each one counts by its own rule, and usually each rule is correct for that system. A CRM may count a customer as any account with a won deal, finance as anyone invoiced in the period, and the project tool as anyone with a live job. Revenue splits the same way between booked, recognised and received. The numbers only look like a contradiction once they sit side by side, which is why joining systems has to come with a named definition for each measure.

Which system should be the source of truth?

Usually no single system, because the right answer is set per measure rather than per system. Finance should normally own revenue and margin, the CRM should own pipeline and win dates, and the project tool should own delivery status. Write down which system owns each measure and which definition it uses, once, and make every report and every AI tool read from that list. Arguing about which whole system is the truth tends to end with one team's numbers overruling another's in places where they should not.

How do you know a joined-up view of your data is right?

Check it against a total you already trust before you trust any of the detail. Last month's revenue in the joined view should match the finance system's figure exactly, and the customer count should match whichever definition you named. If the total is off, every split of it is off too, often in ways that look like insight. Also mark the current period as unfinished, because each system closes its period at a different time and the newest figures are rarely comparable.

Can AI join up data from systems that do not connect?

Usually yes, as long as it can read them. AI is good at pulling fields out of an export, an API or even a PDF report, which makes the joining far cheaper than it used to be. The exception is a system that cannot be read at all, with no API and no structured export, and in that case the foundation has to change first. The harder work, once the data is joined, is agreeing what each number means, and no tool does that part for you.