The standard
How the CAI is computed.
The Code Assurance Index is one number between 0 and 100. It is built from ten lenses, each a broad view of a codebase such as how the code reads, how it is put together, or how it is secured. Every lens carries a score of its own, and this page sets out how those ten become the headline. The rules doing that work are the rubric, and every score names the version of the rubric it was worked out under.
The roll-up
Every step of the roll-up is visible.
A lens score is built from the individual measurements taken inside that lens, and the headline is built from the ten lens scores. Both stages use weights published with the rubric version in force, so somebody holding the same evidence can follow it through both stages and reach the same number.
The weights are published
The ten lenses do not count equally. The rubric sets how much each one carries and publishes it with every version, so the arithmetic that turned ten scores into one can be read in full.
Core always counts
Five lenses are always on: Code Health, Architecture, Maturity, Readiness, and Security and Compliance. They apply to every codebase, whatever it does and however it is built, and they contribute to every headline.
Five more apply only where they fit
Domain Modelling, Event-Driven, Event Sourcing, Accessibility and Performance count only where the architecture calls for them. Where one does not apply, the weights re-normalise: the share it would have carried is spread across the lenses that do apply, so a codebase is never marked down for a lens that was never relevant to it.
The presentation bands
Five bands, cut at 25 / 50 / 70 / 90.
Every score renders on the same fixed scale, running from Critical through Weak, Adequate and Strong to Exemplary, with a pin at the exact number. The pin is the reading. The band it lands in is a label for that reading, put there so a number can be talked about in a sentence, and which band a score falls in never changes the number underneath it.
Bounds on the headline
One critical lens holds the whole number down.
The cap
A critical lens caps the headline.
A single lens sitting in the critical band caps the headline, however well the other nine read. Strength in nine places is real and the score still shows it, but it cannot lift the number past the one place that is failing.
The floor
A contract floor breaks down into its parts.
Writing CAI at 80 or above into an agreement is not a threshold either side has to take on trust. It resolves to something both of them can check: every always-on lens reading Strong or better, and no lens reading Critical. The meaning is fixed when the contract is written.
The firewall
Only three things move the number.
When a CAI number moves between one reading and the next, there are three reasons it can be: the code changed, the score was taken under a new version of the rules, or newly disclosed vulnerability data changed a security finding under rules that had not changed. Each of those is on the record. Nothing else reaches the arithmetic. An opinion, a declaration, a suppressed finding or a contract term can change what a report says, and none of them can change what the number is.
Deterministic vs advisory
The AI only ever advises.
Most dimensions are measured by deterministic tools reading the code. A few carry an advisory, tolerance-banded LLM read that explains in plain English, and by construction it can never move the headline number. It is there to explain a score.
Declarations and contracts
Paperwork cannot move a score.
Compliance declarations, suppressed findings and contract profiles change what a report says, never what the CAI is. Two parties can agree between themselves how a finding should be presented, and the number they are both looking at stays where the evidence put it.
The behavioural dimensions
Four dimensions are read from git history.
Four of the measurements behind a lens score come from the repository's history rather than from the code as it stands today. They are scored the same way as everything else, and they say things about a codebase that reading the current files cannot.
Hotspots
Where change concentrates. A file that is both edited constantly and complicated to read is the one most likely to hurt next.
Bus factor
How concentrated the knowledge is. Which parts of the codebase rest on one contributor, and whose leaving would orphan the most important code.
Knowledge freshness
Code that everyone who understood it has gone quiet on. The knowledge is decaying in place, and the files themselves look no different.
Change coupling
Files that keep being changed together without any declared dependency between them. That is structure the code has but does not admit to.
This page is the authority.
An implementation may summarise this specification for its own readers. Where a summary and this specification disagree, the specification wins.
Read what gets measured, then check a number against it.
Why the rules hold still, and what happens when they change → rubric versions