The Core Problem
Why enthusiasm outruns readiness
A burst of excitement followed by uneven quality, confusion about accountability, and low trust from the people who are meant to benefit from the work — this is the pattern that a readiness framework is designed to interrupt.
— Rankine Innovation Lab · Knowledge HubMany teams experimenting with AI today have access to impressive tools. What they often lack is the less visible infrastructure that makes those tools worth using: clear problem definitions, governed data habits, review workflows, and accountability structures. The absence of that infrastructure does not prevent teams from producing outputs. It prevents them from producing outputs that are trustworthy, reproducible, or institutionally defensible.
This framework does not ask whether a team is enthusiastic about AI. It asks whether the team has the conditions needed to use AI in a way that is useful, safe, and sustainable. For research institutions, programme teams, and technical organisations, those conditions are identifiable and improvable — and the first step is understanding which ones are weak.
Framework Structure
The six readiness dimensions
The framework assesses readiness across six dimensions. Each dimension addresses a distinct enabling condition. The pattern of scores — not the total — is where the most useful information lives. A single weak dimension in governance or data quality can constrain the entire initiative, regardless of how strong the other five appear.
Problem Fit
Does the team know precisely what problem it wants AI to improve? Teams with low readiness start with tools and search for justification after. High readiness starts with workflow pain points. Focus: What and why.
Data & Knowledge Quality
What documents or datasets ground the work? How current are they? Who owns them? Even the most capable model amplifies the weaknesses of a fragile knowledge base. Focus: Foundation layer.
People & Skill
Does the team combine domain knowledge, technical literacy, editorial judgment, and oversight capacity? The right question is not whether there are AI experts — but whether there are experts who can challenge weak outputs. Focus: Human capital.
Workflow Design
AI adds value when it fits a repeatable workflow. Teams with low readiness treat AI interactions as isolated prompts. High readiness teams define steps, output expectations, and handoff points. Focus: Repeatability.
Governance & Assurance
A team is not ready if it cannot explain who owns risk, what information is restricted, how outputs are checked, and what happens when the tool fails. Governance enables quality without improvisation. Focus: Accountability.
Learning & Improvement
Mature teams collect examples, error patterns, and user feedback. Immature teams repeat experiments without evaluation loops. Readiness treated as one-time quickly becomes cosmetic. Focus: Feedback discipline.
Scoring Guidance
What low, medium and high readiness look like
Understanding what each readiness level looks like in practice is more useful than an abstract score. These descriptions help teams locate themselves honestly across each dimension — and identify which transitions are within reach in the short term.
A lower score is not a failure. It is useful evidence. The framework works best when it reveals where to focus next: improving the knowledge base, assigning a review owner, documenting a standard workflow for a single narrow task. Readiness is built incrementally — not declared.
Low Readiness
- Exploring tools casually with no defined problem
- Output quality varies widely across team members
- No source base or document boundaries defined
- Roles, quality thresholds, and review steps unclear
- Governance not yet a design consideration
Medium Readiness
- One or two clear use cases emerging
- Some internal patterns for prompting or retrieval
- Governance still dependent on motivated individuals
- Documentation and evaluation inconsistent
- Moving in the right direction but not yet stable
High Readiness
- Clear problem scope with explicit out-of-scope boundaries
- Maintained knowledge base with versioning and access rules
- Reviewable outputs with documented quality standards
- Performance monitored; improvement pathway explicit
- Can explain standards to external stakeholders credibly
Practical Application
How to score your team honestly
Rate each of the six dimensions on this four-level scale. The descriptions below help calibrate scoring against evidence rather than aspiration. Teams should be able to justify each score with a concrete recent example — either a success that illustrates the capability or a failure that illustrates the gap.
1 · Largely Absent
Not readyThe capability is informal or missing. No explicit policy, process, or ownership exists. AI use depends entirely on individual initiative and self-regulation.
2–3 · Isolated & Inconsistent
EmergingThere are efforts and experiments, but they are not integrated or repeatable. Progress depends on a small number of motivated individuals rather than institutional habit.
4 · Operational in Selected Workflows
CredibleThe capability is explicitly documented and practiced in at least one workflow. Others in the team can follow the same approach without custom instruction from a key individual.
5 · Embedded & Reviewed
StrongThe capability is consistently practiced, documented, reviewed, and improved over time. It would survive a key person leaving the team. External stakeholders could be shown how it works.
Decision Gate
Six questions before moving beyond experimentation
Before moving from limited experimentation to operational use of AI tools, a team should be able to answer all six questions clearly and specifically. Vague or aspirational answers indicate that readiness is not yet there — and that proceeding will likely produce the fragile pattern this framework is designed to interrupt.
What problem are we solving — specifically, and for which users?
What source base grounds the work — and who owns it, versions it, and keeps it current?
Who reviews the output — at what stage, and against what quality standard?
What information is restricted — and does the system know this and enforce it?
How do we know the workflow is working — what evidence will we collect and review?
What will we improve next — and who is responsible for driving that improvement?
Critical Awareness
Mistakes that undermine the framework's value
The readiness framework is most useful when it generates an ordered improvement path. Its value collapses when teams use it to confirm their existing assumptions rather than challenge them. Three misuses account for most of the failure cases.
Confusing Access with Readiness
Having tools available is the starting point, not the measure of readiness. A team that can prompt effectively but cannot govern its outputs or maintain its knowledge base is not ready for operational use.
Over-Scoring on Isolated Successes
One impressive output is not evidence of institutional readiness. Readiness is demonstrated through repeatability, not individual performance. Score from typical outputs, not best cases.
Treating Readiness as Static
Teams, tools, document bases, and policy environments change quickly. A readiness assessment should be repeated at meaningful intervals — not treated as a one-time certification that remains valid indefinitely.
- Rankine Innovation Lab Knowledge Hub research brief: Framework treatment of AI risk, RAG, and quality assurance across research and programme teams.
- Founder-connected GenAI evidence base: Construction and water-systems papers on grounded use cases and review-oriented adoption patterns.
- NIST AI Risk Management Framework: Govern, Map, Measure, Manage — assurance spine for governance design across AI adoption stages.