What happens to you if something happens to us. Why a copy of the code was never enough, what has changed, and what we put in the package so a new team could pick it up.
What happens to us if something happens to you? It’s the right question to put to a young company, and we’d rather answer it on the website than wait for it to come up in a procurement meeting. commvita is small and growing fast. That’s a strength when you want a supplier that moves, and a worry when you’re thinking about the next ten years.
The usual answer is escrow: the source code sits with an independent third party, and if the supplier stops trading or can’t meet its obligations, the customer gets the code. We offer that. But we think the honest version of the answer has changed in the last few years, and this page is about why.
A copy of the code in a vault is a legal comfort. On its own it was never much of an operational one. Having the source doesn’t mean you can read it, and reading it doesn’t mean you can change it safely.
Ask anyone who has been through a release. The customer opens the package and finds a large codebase written by a team who aren’t there any more, documentation that stopped being updated two years before, and no record of why anything was built the way it was. A new team can be months in before they dare change a line. Most organisations never exercise their escrow rights at all. They migrate instead, at their own cost, because the code they own is a code they can’t use.
The vault is the same. What goes in, and what a new team can do with it when it comes out, is not.
AI coding agents can now read a large codebase and explain it. Give one the source, the tests and the history of changes, and it will describe the architecture, say why a decision was taken, find the dependencies, write the documentation that’s missing and help a new engineer make a change without breaking the one next to it.
That doesn’t remove the need for people. A team still has to run the platform, decide what to build and take responsibility for it. What it removes is the part that made escrow hollow: the months of archaeology before that team could act. A codebase that is well structured, tested and recorded becomes something a customer or an appointed partner can take on, at a cost and in a time that would have been unrealistic a few years ago.
Escrow is only as good as what’s in it. The point of ours is that a new team, with an AI agent alongside them, can pick it up and act. So the package is more than the code.
The full source, the record of every build with what changed and why, and the test suite that holds each rule in place. The history is what lets an agent answer “why is it like this?” instead of guessing.
Documentation produced from the code rather than written beside it, so it can’t drift. The explainers on this site are the public face of the same approach: each one is generated from the platform it describes.
Your data was never in the package, because it was always on your estate, in open formats. Whoever picks up the code finds a record shaped to published standards, which any competent health-informatics team already knows how to read.
Nobody plans to use an escrow release, so it’s worth walking through what one would look like.
The classic ones: we stop trading, we can’t meet our obligations, or we fail to maintain the platform as agreed. The triggers and the escrow agent are contract terms and are set with you.
Your own digital team, a partner you already work with, or a specialist firm. The package isn’t tied to a particular successor.
An AI coding agent is pointed at the source, tests and history, and the new team asks it questions in plain language: how does the record get written, where do the access rules live, what depends on this module. What used to take months of reading takes days of asking.
The platform keeps running on your estate throughout, because it was always hosted by you. The new team takes on fixes and security updates, with the tests telling them when a change breaks something.
This is the part traditional escrow never delivered. With the code understood and the tests in place, the new team can build on the platform instead of freezing it and planning a migration.
A page like this is easy to overclaim on, so here are the limits.
It isn’t a substitute for a contract. Escrow terms, triggers, the agent and the verification schedule are agreed in writing with each customer, and nothing on this page replaces that. It isn’t a claim that AI will run the platform on its own; a responsible team is still required, and the agent’s job is to make that team effective quickly. It isn’t a statement about support levels or response times, which are separate contract matters. And it isn’t a reason to skip the ordinary questions about a supplier’s finances and governance, which you should ask us directly.
| Safeguard | What it protects | Read more |
|---|---|---|
| Open standards | Your data stays readable by any system that speaks openEHR, FHIR, SNOMED CT or OMOP | Interoperability |
| Your own hosting | The platform runs on your estate, so a supplier event doesn’t switch it off | Security architecture |
| Freedom to leave | A modelled export path if you choose to move to another platform | Migrating on, and leaving |
| AI-enabled escrow | The ability to understand, support and keep developing the platform without us | This page |