The founders wanted a company that never sells a screenshot of a spreadsheet as a module. So the platform states what is live, built or stub, where every number comes from, how far each standard goes and where it stands against others, and a build fails when the words drift from the facts.
The founders of commvita have all sat on the buying side of health software. We’ve been shown demos that turned out to be mock-ups, bought roadmaps that never shipped, and been told a module was live when it was a screen over a spreadsheet. We decided this company wouldn’t do that, and then decided that a promise wasn’t enough.
So transparency here is engineered, and this page is about the engineering. The platform states, on its own screens and in machine-checked registers, what is live, what is built but not yet connected, what is a stub, where every number on every page comes from, how it measures against other systems, and what each standard it names means in practice. A build that contradicts any of those statements fails.
Open any screen and the top bar tells you whether it is reading platform data or showing seeded demonstration data. That badge isn’t typed by a developer. It comes from a register measured from the page’s own source code.
The register counts, for each page, the calls it makes to the platform and the literal data it carries. A page that does both is classed as mixed and left there, because which of the two a given tile shows can’t be decided from the source, and guessing would be the confidently wrong answer. The build check fails only in the direction that could harm someone: a page declared as platform data while fetching nothing. A page that understates itself is allowed.
Today that gives 422 routed pages: 90 reading the platform, 211 mixed and 121 seeded. We publish the 121 because a buyer who finds one for themselves stops believing the other 301.
The module registry carries a status for each of the 629 modules the platform ships: live, built or stub. The words have definitions, and the definitions are printed next to the count.
Live means fully operational with no external dependency. Built means the code is complete and it needs NHS credentials or national onboarding to switch on. Stub means the adapter or scaffold exists and the credentials would activate it. Backlog is a competitive gap that is an area for improvement and not yet built, and it is counted separately so it can never inflate the module total. The registry, the competitive audit and the routing table are checked against one another on every build, so a module can’t appear in one and not the others.
The Architecture screen lists 142 standards the platform is built to, across NHS, clinical, pharmacy, information governance, interoperability, legal and engineering. Naming a standard is cheap. The screen says what each mapping means.
The alignment against the WHO reference architecture and the European health data space is labelled on the screen as a design-alignment statement and not a certification. Each building block gets one of three words: aligned, partial, or designed to align. Nothing is marked aligned because it sounds good. A build check also refuses any claim of conformance to a standard the team hasn’t read: where a publisher’s site couldn’t be reached from the build environment, the claim is held back and the reason recorded.
The architecture itself is described using an enterprise architecture method, with the business, data, application and technology domains laid out on the same screen, twenty accepted architecture decision records with their rationale, and a risk register with 46 open and 29 resolved items. The tech stack, integrations and data models are tabs on the same page, so a reviewer doesn’t need a deck.
The help guide has an entry for all 425 routed pages. None of it is typed. Each entry is generated from the platform’s own registers, and it is regenerated whenever a page changes.
Thirty-three pages also carry a hand-written plain-English guide and are marked as such. The build check fails if the register has drifted, or if any page’s source changed after its guide was written. A guide that describes last month’s screen is worse than no guide, and the check is what stops it.
The competitive intelligence module rates each of 440 module entries against the products that do the same job, as ahead, on par or behind, and is updated every build. Today 242 are ahead of every product rated, 146 are on par somewhere and behind nowhere, and 52 are behind at least one.
Every behind rating has to say what separates the two products and what would close the gap, and a build check enforces both. Claims the register used to make and withdrew after measurement stay on the record. Those 52 modules are behind across 90 individual comparisons, and the full account of what each comparison is behind on is in the competitive intelligence explainer. It is our assessment and says so.
Every explainer on this site opens with the same line separating live from demonstrated, and every screenshot is captured from the running platform with the build stamped in the caption. The explainers say which they are showing, and when a screen is seeded they say so under the picture.
Where a page found a defect while it was being written, the defect is on the page. The research explainer names an extract that emits more people than its cohort. The architecture explainer prints the number of columns that still hold time as text. Our house rules for this site bar anything that can’t be true on the day it’s published, and a scoring tool checks each page for the tells of copy written to impress instead of inform.
| Register | Route | What it states | Checked |
|---|---|---|---|
| Data transparency register | /data-transparency | Platform, mixed or seeded, per page, from the source | Every build |
| Module registry | /architecture | Live, built, stub and backlog per module | Every build |
| Standards and alignment | /architecture | 142 standards; aligned, partial or designed to align | Every build |
| Help register | /help | 425 page guides generated from the registers | Every build |
| Competitive intelligence | /competitive-audit | Ahead, on par or behind per module, with the gap class | Every build |
| Test catalogue | /architecture | Every test, generated from the suite | Every build |