CogniDev
5 · Governance
How the readiness score works
Governance checks the repository against eight groups of controls and gives you one number. This section covers how that number is worked out, why the breakdown matters more than the number, and what the findings look like.
The readiness score
Open Governance and the repository is scored out of 100, with the number of groups it managed to check next to it.
The repository above scores 71 out of 100, with 8 of 8 groups checked. Both halves matter. A 71 from eight checked groups says something different from a 71 where three groups could not be checked at all, and the screen never lets those look the same.
The eight groups
They run worst first: can it be attacked, is the stack still alive, are you allowed to ship it, and then the craft and process ones.
| Group | The question it asks |
|---|---|
| Security | Can this be attacked as written — secrets, authentication, data protection. |
| Currency | Is the stack still supported, or has it gone out of support. |
| Compliance | Are you allowed to ship it, given the rules your industry has. |
| Dependencies | What you have taken on from outside, and what state it is in. |
| Quality | The craft measures across the codebase. |
| Ownership | Who knows this code, and what happens when they leave. |
| Process | How a change gets to production. |
| AI hygiene | What generated code has left behind. |
The scoring is fixed, not a judgement call. The same repository at the same commit gives the same score every time, which is what lets you use it as a gate instead of an impression.
Reading the breakdown
The number is broken down by group, and that is the part to read. On the repository above:
| Group | Score | What it rests on |
|---|---|---|
| Security | 100 | 3 checks · no hardcoded secrets in shipped code |
| Currency | 90 | 3 checks · one of two tracked components needs action, one out of support |
| Compliance | 35 | 3 checks · financial reporting, 7 of 20 controls failing |
| Quality | 100 | 7 checks |
| Ownership | 10 | 2 checks |
71 looks like a reasonable number and it describes no part of this system accurately. Security is perfect. Compliance is 35 and ownership is 10. Ship the one number without the breakdown and you hide the two findings that should stop a release.
Each group also says how many checks it was scored on, so a score backed by seven checks is not confused with one backed by two.
What a finding looks like
The main risks sit above the breakdown. Three from the same repository:
- No audit trail around financial records. Nothing in the repository implements this control, and every change to a financial record has to be attributable: who, what, when, and what it was before.
- No separation between who starts a transaction and who approves it. The same person doing both is the textbook fraud path.
- Entity Framework Core 9.0.0, out of support since 2026-05-12, 58 days
ago. Move to 10. Declared in
Acme.Banking.csproj, one major version behind.
They all have the same three parts: what is wrong, why it matters, and where the evidence is. The dependency finding names the file that declares it, the version, when support ended, how long ago that was, and what to move to. The compliance findings say what the consequence is in the words a reviewer would use, because a failing control with no consequence attached does not survive a prioritisation meeting.
Who knows the code is a finding too
"Bus factor 1 — one author wrote 100% of changed lines" appears in the same list. Ownership risk is measured from the repository's own history and scored next to the technical groups, because it fails a readiness review just as reliably.