AI Maturity Assessment
Forty minutes, across eight dimensions of practice. At the end you hold a workbook and a report on your own machine. This page explains the parts that are not obvious from the screens.
There is no score. No total, no average for your entity, no ranking against anyone else. The instrument has no knowledge of any other organisation's answers. What it produces is a reading — where practice is established, where it is emerging, and where nobody yet knows.
Nothing you type leaves your machine. No account, no sign-in, no server. That has one practical consequence: nobody can recover your work for you. The file you export is the backup. Export early rather than at the end.
Everything written is optional. The state of the practice is the answer; every text field alongside it is optional and means it. If you have nothing to add, add nothing.
Where the buttons are. Three sit in the bar across the top of the page, next to the link that brought you here. There is no save button anywhere else, and there is not meant to be — your work is written down as you type it.
| Resume from file | Loads an Excel workbook or a JSON export back in. |
| Export | Writes a JSON file — the handover file, and the one that always loads back. |
| Download workbook | Writes the Excel assessment workbook itself, with your answers in it. |
Download report and Clear and start again sit at the foot of the page. The report is your browser's own Save as PDF, so the print dialogue opens.
Three numbered steps carry the assessment. Three more are there if you want them.
Optional depth sits below those in the sidebar, and nothing in it is required. The numbered journey never passes through it — you go there by clicking, and you come back the same way.
Start the assessment at the foot of Entity & Scope takes you to the first dimension. From there Next dimension and Previous dimension walk A through H and on to Profile & Reading, and going back from A returns you to Entity & Scope. Both sit under the distribution chart.
The same state means something different inside a single business unit than it does across a whole company. The answer only means something once the scope is on the record.
State first. Everything else is there if it would improve a decision.
Each card carries the practice, what to look for, and what evidence could look like. Choose a state and the card tells you what that state means.
| State | Means |
|---|---|
| 0 | Not evidenced |
| 1 | Emerging |
| 2 | Repeatable within the scope you declared — not necessarily company-wide |
| 3 | Sustained and learning |
| IE | Insufficient evidence — a real answer, not a blank |
| N/A | Not applicable |
| DR | This doesn't fit how we work |
The last three are buttons alongside the four numbers, and they carry their full wording rather than the code. They are not part of the 0-to-3 scale and are never worse than a 0.
One link sits under a card once you have named an example: Record this as an initiative, which creates the row on the Initiatives register, gives it an ID, and writes that ID back onto the card. Go deeper opens the next set of fields.
What the file records is what your answer actually contains, not a level you declared in advance. Four rungs, and you reach each one by writing something, not by pressing something:
| 1 · Base | A state, with or without a justification. |
| 2 · With example | You named a real initiative, decision or practice. |
| 3 · With evidence | You named what a reader could look at — or the evidence state, confidence, next proof or owner. |
| 4 · Deep dive | The example is an initiative that carries a deep dive. |
They open and close fields, to keep the card quiet when you do not need them. Stepping back never deletes anything — it hides fields, the text stays. To take something out of the file, clear the field itself. That is the only thing that removes it.
So a practice you meant to answer at "with evidence", that ends up with a state and a justification, is recorded as a base answer. That is normal. You cannot get it wrong by going too shallow — depth raises confidence in an answer, it does not raise the answer.
Three screens that connect. You meet them one at a time, so the connection is easy to miss.
An AI initiative is a specific piece of work where AI does a defined job in a real process, and someone owns the result.
Not a tool you bought and use as it comes — that goes on the Tool register. Not a demo nobody owns. Not "we are getting better at AI" — that is the assessment, not a row.
It starts on a practice card. Add an example, and Record this as an initiative turns that sentence into a row: the example becomes the initiative's name, and the practice code lands against it. The link exists in both directions before you open the register.
One row per initiative: name, AI type, build model, IP position, stage, area, objective, who is affected, what the AI contributes, where human responsibility sits, owner, and which practices it evidences.
The assessment says what is true across the entity. The register says what that is made of.
Set an initiative's AI type to Embedded AI or its build model to Vendor SaaS, and the row offers Move this to the Tool register. Name, area and owner travel with it.
Tools are registered, not scored. They count toward literacy, adoption and governance, and nothing else. Buying a tool is not the same as building a capability.
Pick an initiative from the list — IN-01 and so on — and answer a fuller set of questions about that one: data and rights, regulatory routing, limits on what the system may act on, what happens when it fails, the value it is meant to produce, the cost, and the next proof.
Do not deep-dive everything. Three or four is a full session. Choose the ones where the answer matters, or where you are least sure.
It never concludes that an obligation applies, and it does not replace a legal, clinical or technical decision.
What would remain if the people who built this left tomorrow. That is the difference between a capability and a count.
The workbook is yours. One rule about it, worth knowing before you hit it.
What the tool produces is a real Excel file. Open it, read it, edit it, print it, send it on. It is the deliverable and it is meant to be handled.
Nothing is damaged and nothing is lost — your answers are all still there and still open in Excel. A spreadsheet application rebuilds the whole file in its own format when it saves, and the tool only accepts its own unmodified export. It will tell you exactly this if you try.
Send the workbook exactly as the tool exported it, untouched. Or send the JSON export, which always works.
.xlsx or .json, both are accepted.A handover is a relay, not a shared document. One person at a time, in turn. You answer your part, export, send. They load it, add their part, send it back or on. If two people work from the same file at once, whichever gets loaded last is the one that survives.
So agree who holds the file, and say so when you send it — "this is with you now, send it back when you've done section D." The contributor list on the first sheet records who has touched it.
Export the JSON at the same time as the workbook whenever there is any chance of more editing. It costs nothing, and it always loads back.
Open the workbook and edit it freely. That is what it is for. One thing to know: those edits live in the workbook only. Go back to the tool afterwards and it will still hold what it held before. From the moment you edit in Excel, the workbook is the record. Do not try to reconcile the two.