Competitive intelligence: ahead, on par, behind, and why

A register inside the platform, revised every build with AI assistance, rating 440 modules against the products that do the same job. 52 modules are behind at least one product, across 90 behind comparisons, and every one of the 90 says what it’s behind on.

1 A register, updated every build

Most competitive comparisons in health software are a slide made for a bid and never touched again. commvita keeps its comparison as a module inside the platform, one entry per capability, rated against the named products that do the same job, and it is revised as part of every build.

The coverage is calculated on the screen instead of asserted. The module registry holds 629 entries. Twelve of them are cross-cutting capabilities with no screen to compare, such as brute-force lockout or per-record scoping. A hundred and ninety-eight are legacy duplicate entries pointing at the same route as another entry, resolved by route so they aren’t given a fabricated second audit. That leaves 419 distinct routed modules, every one audited, producing 440 audit entries because 21 routes host more than one distinct capability and each is rated on its own. A build check enforces both directions: no routed module without an audit entry, and no entry without a module.

2 The numbers today

There are two counts on the screen and they measure different things, so here they are together. Counting modules: of the 440 entries, 242 are ahead of every product they’re rated against, 146 are on par with at least one and behind none, and 52 are behind at least one. Counting comparisons: each module is rated against several products, giving 1,108 comparisons across 454 named products, of which 752 are ahead, 266 on par and 90 behind.

The 52 and the 90 reconcile like this. Of the 52 modules behind, 22 are behind one product, 24 are behind two, four are behind three and two are behind four. Add those up and you get 90 behind comparisons. The tiles count modules; the breakdown above them counts comparisons, because a module behind two products may be behind them for two different reasons, and the reason is what you plan against.

A module counts as behind if any one product beats it on any one comparison, which is why 52 modules produce 90 behind comparisons. That’s the strict reading, and we use it because the lenient one flatters. The competitor products aren’t named on this page, by house rule; they are named on the platform screen, one by one, with the notes that justify each rating.

3 How “behind” is broken down

Behind is too blunt a word to plan against, so every one of the 90 behind comparisons carries a gap class saying what separates commvita from that particular product. The 90 break down like this.

Two rules sit behind that table and are enforced by the build. A rating of not built, not wired or awaiting licence has to say what would close it, because a concession that doesn’t say what would move it is a refusal in disguise. And a rating conceded by design, to a partner or to scope, is forbidden from carrying a “moved by” at all, because there is nothing to move. A hybrid verdict like “ahead but not live” was considered and rejected: it folds two facts into one word and gets shortened to “ahead” the first time it reaches a board pack.

4 How the assessment is made

The audit is written with AI assistance at every build and revised against measurement, and a rating only moves when something measurable changed. Deciding to build a capability moves nothing. A plan is not a capability.

The verdict is honest about deployment. If a commvita surface is seeded and the comparator is a working product, commvita is behind, however good the design, and the gap class records that the gap is deployment. The openEHR column is the clearest example: 204 entries are marked openEHR enabled and none is marked native, because native would mean clinical data persisted as compositions against published archetypes and queryable with the standard query language, and no module claims that today. The screen says so in its own words, above the table.

Claims the register used to make and later withdrew are kept on the entry, with the date, instead of being deleted. A register that only shows what it currently claims can’t answer the question a buyer who read an older deck asks: was this ever asserted, and when did it stop being?

5 The same discipline for how data is used

The competitive register answers “how good is this module?”. A second register answers “is what I’m looking at real?”, and it is measured the same way.

The data transparency register classifies all 422 routed pages from their own source: 90 read the platform, 211 read the platform and carry seeded figures too, and 121 are seeded. The top bar of every page shows the result as a badge. The rule that fails the build is narrow on purpose: a page may understate itself, and may never claim platform data while fetching nothing. Where a page is mixed the register leaves it mixed, because deciding which tile shows which would be a guess.

6 No feature promises

Every founder of commvita has been on the receiving end of a feature promise: the module that was “in the next release” through three contract renewals. We vowed not to do it, and the register is how the vow is enforced on us.

There’s no roadmap column in the competitive audit. A capability is rated on what runs today, and the honest words for what doesn’t run are the seven gap classes above. When something is built it is measured, the rating moves, and the build register records the measurement. If you are shown a rating in a meeting and want to know what it rests on, the entry is on the platform with its notes and its last-verified date, which at this build ranges from June to September 2026.

Where it lives in commvita