COR
Maturity Model
Five levels describing an organisation's operational capability; the criterion is not which tools are used but where the knowledge and the control reside.
The Design Premise
Differences in operational capability are, at root, not differences in technical level but differences in where the knowledge resides.
Two organisations may both keep a service running, but whether the knowledge sits in an individual engineer's head, in documents, in executable rules, or in a framework that checks itself, determines how that organisation performs when staff change, when it scales, and when something breaks unexpectedly.
Five Levels
| Level | Name | Criterion | Typical symptoms |
|---|---|---|---|
| L1 | Individual dependence | Practice resides with individual engineers and is not systematically recorded. | Only one particular person can perform the critical task; changes freeze when they are on leave. |
| L2 | Documented | Practice is recorded, but nothing ensures it is followed in execution. | Documents exist but are out of date; discrepancies between the live system and the documents go unnoticed. |
| L3 | Executable | Rules are the basis for execution; change is controlled and recorded. | Work follows the rules; changes have plans and records; the live state can be compared against the target. |
| L4 | Verifiable | Production is separated from acceptance, and key criteria can be machine-checked. | The performing and accepting parties are separate; criteria leaving no room for judgement are written as check programs. |
| L5 | Evolving | Records feed back into the rules and the framework improves itself. | Incidents and defects are corrected at the rules layer; recurring problems can be detected. |
The Boundaries Between Levels
The boundary from L1 to L2 is whether it has been written down. Most organisations overestimate where they sit on this line — having documents is not the same as being documented; what matters is whether the documents cover what is actually needed during execution, and whether they are kept consistent with the live system.
The boundary from L2 to L3 is whether what was written down is actually followed. This is the hardest line to cross in practice and the one with the greatest return. The test is not a claim that everyone follows it, but whether it can be shown that every task can point to the revision of the rules it followed.
The boundary from L3 to L4 is whether an error can be found before it has an effect. There are two tests: whether production and acceptance are carried by different roles, and whether rules leaving no room for judgement have moved from text to executable checks.
The boundary from L4 to L5 is whether the framework improves itself. The test is whether records feed back to the rules layer: whether the conclusions of incident reviews become revisions to the rules, whether recurring problems are caught by a detection mechanism, and whether rejected options and their reasons are kept for later reference.
Assessment Method
Assessment is evidence-based, not document-based. Assessors do not accept "we have a rule about that" as evidence; they require records of actual work: recent change records, how a failed task was handled, whether things were synchronised when rules were revised, and the actual output of checking mechanisms.
Results are given as both an overall level and per-domain levels. The overall level is the lowest of the domains, not the average — because operational failure generally happens at the weakest link, and an average conceals that. Domain levels are shown separately so the organisation knows exactly what to strengthen next.
The assessment cycle is two years; where there has been major organisational or architectural change in between, a reassessment may be requested. The Council also provides a self-assessment tool with no formal standing — it uses the same criteria as the formal assessment, and differences in result usually come from how strictly evidence is judged.