What it takes to evolve a system with AI.
The AI Readiness Maturity Model was developed for organisations that are bringing AI into software development. It assesses one system in its environment (everything needed to build, verify, deploy, run and recover it) and compares where the system stands with what its owner needs from it. This page explains the model; the AI Readiness Scan is where it is applied.
AI changes who writes the code, not what keeps it safe
AI assistants already write a growing share of the code, and agents are starting to carry out whole changes. Whether that is safe is not decided by the AI, and not by the code alone. It is decided by what surrounds the code: what verifies a change, ships it, runs it, protects the data and keeps the knowledge alive. A maintainability score measures the code. This model measures the rest as well.
AI raises the stakes on exactly that environment. Where quality depends on someone remembering, a higher pace of change means more is forgotten. Where it depends on mechanisms, the same pace is absorbed. And someone still has to answer for the system: an agent can do the work, but it cannot hold the accountability. The model makes that difference visible, in words an executive can read.
- The unit
- One system in its environment. Not the team and not the organisation. A shared platform, such as a common pipeline or shared monitoring, counts for every system that really uses it.
- The comparison
- Where it stands against what it needs. A level on its own says little. A level next to the level this system requires says where to invest, and where not to.
- Built for AI adoption
- Developed for organisations that are actively adopting AI. From assistants that suggest code to agents that carry out changes, each dimension asks what has to be in place for that to be safe.
- Useful without it
- None of the seven dimensions depends on AI being used. A team that writes every line by hand gets the same rich picture of what sustains its system. AI does not create the gaps; it raises the price of leaving them open.
Five levels, defined by what quality depends on
The same ladder is used in every dimension, so that level three means the same kind of thing for security as it does for delivery.
Luck
Nothing supports it.
People
It works if someone remembers.
Defaults
The normal path is the good path.
Guardrails
Enforced, and cannot be bypassed.
Feedback
Detects and corrects its own drift.
Seven dimensions, one question each
Each dimension is one word, answers one executive question, and can be improved on its own. The questions are the same whether a change is written by a person or by an AI agent.
- Code
- Can we change it at reasonable cost?
- Verification
- Would we know if a change broke it?
- Delivery
- Can we ship a change safely and repeatably?
- Operations
- Do we know when it is unwell, and does it survive faults?
- Data
- Can we evolve, protect and restore the data?
- Security
- Is it protected in proportion to what it holds?
- Knowledge
- Could someone new, human or AI, pick this up?
The owner’s needs set the target
The owner says how critical the system is and rates six needs as not relevant, important or essential. It takes about two minutes and uses no jargon.
Always on
How much downtime can we tolerate?
Protected
How sensitive is what it holds?
Correct
What does a wrong answer cost?
Fast at scale
How many users or transactions, and how time-sensitive?
Easy to change
How long will it live, and how often must it change?
Connected
How many other systems depend on it, or it on them?
Those answers set the level each dimension has to reach, so the target is yours and not ours. An organisation’s own engineering standard can set a minimum on top.
Mechanisms, checked against the system itself
Each level rests on a fixed set of yes-or-no capabilities, checked against the system’s own artefacts. Levels are cumulative: a level is reached only when everything below it is in place. The model tests for mechanisms, not for tidiness: a document that describes a safeguard is not the safeguard. That matters more with AI, not less. Clean commits and well-kept documentation used to be signs of a careful process; in a system built with AI they show the diligence of the tool. What we find is reported in four evidence states, and every result reports the mix.
- Evidenced
- An artefact proves it. Counts.
- Attested
- The owner states it, because it cannot be seen from the outside. Counts, and is marked as such.
- Absent
- Looked for, and not there. Does not count.
- Unknown
- Could not be assessed yet. Never counts as a pass.
A system is as sustainable as its weakest dimension. Strengths are shown, and never average away a gap. A result leads with the weakest dimension, next to how many of the seven meet the need.
What the model rests on, and where it stops
- Standards
- The needs are traceable to the quality characteristics of ISO/IEC 25010:2023, and criticality to ISO/IEC 25019:2023. The needs themselves are asked in plain business language, so an owner can answer them without knowing the standard.
- Maintainability Cloud
- The Code dimension builds on the benchmarked maintainability rating of Maintainability Cloud. That rating measures the code in depth; this model covers what it takes to sustain everything else. Stars stay reserved for that rating, which is why this model speaks in levels.
- Not covered
- The model grades a system, not a team or an organisation. It is not a safety assessment: a system whose failure can harm people needs its sector’s safety standards as well.
See it applied to one of your systems
The AI Readiness Scan applies the model to one system: where it stands, what it needs, and the few moves that close the gap.
We developed this model recently, and we are looking for organisations that want to be among the first to put it to work on one of their systems.