> ## Content Index > Fetch the complete content index at: https://devinside.cloud/llms.txt > Use this file to discover other available public pages before exploring further. # AI Readiness Is a Set of Evidence Gaps - URL: https://devinside.cloud/ai-readiness-is-a-set-of-evidence-gaps/ - Published: 2026-02-24T09:30:00.000Z - Updated: 2026-11-12T17:08:28.000Z - Description: Readiness is better expressed as unresolved questions with owners than as a decorative maturity score. - Author: Marcin Borecki - Tags: Advisory, Technical Advisory & Product Strategy, #m19, #devinside-review START WITH THE MECHANISM Interactive companion and laboratory update: 12 November 2026\. The editorial date places the topic on the timeline; this current explanation and its measured evidence retain their actual preparation and execution dates. THE FULL INVESTIGATION ## AI Readiness Is a Set of Evidence Gaps Editorial context: 24 February 2026 · Prepared and updated: 12 November 2026 Dates and technology context This is a retrospective editorial timeline. Topic context: 24 February 2026\. First publicly available: 12 November 2026\. Current text, visuals and laboratory revisions were prepared on 12 November 2026. The recovery and evidence-gap examples use November2026 laboratory evidence. Preserve the February2026 readiness argument as a retrospective framework, not a certification. An organisation receives an AI readiness score of seventy-four. The number is high enough to encourage a programme and low enough to justify a programme of improvement. It looks useful in a presentation. The engineer responsible for the first deployment still does not know who owns the source documents, whether the proposed user can access them or what should happen when the assistant is uncertain. This hypothetical score is not wrong because it is numerical. It is weak because it compresses unresolved decisions into a value that nobody can act on directly. Increasing the score by five points may have no clear relationship to making the intended workflow more reliable. Readiness becomes more useful when expressed as a set of evidence gaps attached to a specific decision. What do we need to know before allowing this system to perform this task for these people? Which gaps can be reduced through a test, which require an organisational decision and which remain unavoidable uncertainty? That framing changes the purpose of an assessment. Instead of describing how modern the organisation appears, it identifies the next justified action. A modest pilot with well-understood limits can be more ready than an ambitious platform surrounded by reassuring documentation and unresolved ownership. ## Readiness belongs to a use case Imagine a hypothetical professional-services firm with a well-maintained public knowledge base and a fragmented internal project archive. It may be ready to offer an assistant that helps people navigate the public material. It may be far less ready to let the same interface answer questions across confidential client records. A single organisational score conceals that difference. The model, interface and development team might be identical in both cases. The evidence boundary, permissions, consequences of error and recovery obligations are not. Start by describing the task in ordinary language. Name the person who initiates it, the information they possess, the decision they need to make and the action that follows. Then state what improvement is sought. “Use AI to become more productive” is not specific enough to determine which evidence is missing. “Help a consultant find the current approved project template without seeing another client's files” is a testable beginning. The use case should include an exclusion. What is the system not authorised to decide or change? A narrow read-only assistant can create useful evidence about retrieval while leaving autonomous action for another stage. Exclusions are productive when they create a coherent experiment rather than hiding an essential part of the promised benefit. ## Turn broad concerns into questions with owners 01 / See the idea ### A concern needs an owner and an action ![Data quality becomes a specific question, evidence need and assigned decision.](https://devinside.cloud/content/images/2026/11/devinside/M19-v1.svg) [Enlarge diagram](https://devinside.cloud/content/images/2026/11/devinside/M19-v1.svg) Suppose a template archive contains contradictory versions. Engineering can locate the conflict, but a knowledge owner must decide which version is authoritative before the assistant can treat it as approved. Interpretation and evidence - Replace labels with answerable questions. - Assign authority, not just a team name. - Name the next observation. conceptual/hypothetical, not measured “Data quality” is a concern. “Can we identify the currently approved version of each template?” is a question. “The knowledge owner will review a sample of conflicting versions by Friday” is an action. The assessment should make that progression visible. Different gaps require different owners. Engineering can inspect how the system handles a missing field. It may not be able to decide which of two contradictory policies is authoritative. A business owner can define an acceptable escalation route but may need security specialists to evaluate a particular access mechanism. Assigning every unresolved issue to the AI team produces the appearance of ownership without the authority to resolve it. The NIST AI Risk Management Framework provides a broad structure for organising responsibilities and risk considerations. It is explicitly intended for voluntary use across the lifecycle. [NIST AI RMF](https://www.nist.gov/itl/ai-risk-management-framework?ref=devinside.cloud). The proposed evidence-gap method is one way to turn that kind of structure into decisions for a bounded workflow, not a claim that a framework endorses a particular readiness score. A useful gap record contains a question, its consequence, the current evidence, the owner and the next observation or decision required. Keep those fields short enough to review together. A register that nobody revisits is simply another place where uncertainty can acquire administrative permanence. ## Distinguish unknown, unacceptable and deliberately limited An unknown result means the team does not yet have sufficient evidence. An unacceptable result means observed behaviour violates a chosen requirement. A deliberate limitation means the team has decided to exclude a capability from the current scope. These states should lead to different actions. Suppose the hypothetical firm's assistant has not been tested on superseded templates. That is an evidence gap. If testing shows that it consistently recommends an obsolete template, that is adverse evidence. If the pilot only includes a single curated template family, that may be a deliberate limitation. Calling all three “medium risk” loses the difference. The distinction protects both sides of the discussion. It prevents a sponsor from treating absence of evidence as proof that the system is safe. It also prevents a reviewer from treating every untested possibility as proof of failure. The next step can then be proportionate: test, repair, narrow the scope or explicitly accept a residual uncertainty. Record what would change the state. If nobody can explain how a question could move from unknown to resolved, the question may be too broad. “Is the AI trustworthy?” has no finite acceptance test. “Does this version cite the approved template on the held-out cases and refuse inaccessible content?” gives the team something it can examine. ## Find the gap that controls the next commitment 02 / A concrete example ### Separate a blocker from parallel learning ![A public prototype can proceed while production data access remains unresolved.](https://devinside.cloud/content/images/2026/11/devinside/M19-v2.svg) [Enlarge diagram](https://devinside.cloud/content/images/2026/11/devinside/M19-v2.svg) Imagine an assistant whose production access rules are unsettled. A synthetic interface trial can still answer usability questions, but its success supplies no evidence that confidential source access has been approved. Interpretation and evidence - Name the blocked commitment. - Continue independent learning. - Do not transfer evidence across scopes. conceptual/hypothetical, not measured Not every uncertainty deserves immediate investigation. The most useful gap is often the one that determines whether the next commitment is sensible. If the business cannot agree on which task is valuable, detailed model comparisons are premature. If the data is inaccessible for the intended use, improving the prompt does not remove that constraint. If the workflow is useful and the access boundary is clear, uncertainty about review effort may be the right thing to test next. This is a dependency problem. Some questions block meaningful work on others; many do not. A team can prototype the interaction with synthetic material while an owner clarifies the production corpus. It should not mistake that prototype for evidence that the corpus problem is solved. Parallel work is useful when the boundaries remain explicit. Rank gaps by decision consequence rather than by how alarming they sound. A poorly specified escalation route may matter more than an exotic attack scenario for the first read-only pilot. In another workflow, a single unauthorised external action may dominate every other concern. The use case and its consequences should determine the ordering. ## Design an experiment that can produce an inconvenient answer For the template assistant, choose a small, approved collection with current and superseded documents. Create questions that require distinguishing them. Include an ambiguous request and an inaccessible document. Have the expected outcomes reviewed independently of the implementation. Before running the experiment, define what each outcome permits. A successful retrieval test might justify a monitored pilot with a limited group. It would not justify allowing the assistant to publish documents automatically. A failed test may support a narrower corpus or an improved versioning mechanism, rather than a different model. The experiment should measure the work surrounding the answer. Does the user have to open several citations to verify it? Can they recognise an escalation? Is the time saved during search consumed by checking a confident but weakly supported response? Those questions are often more consequential than whether the text sounds polished. An experiment also needs a stop condition. Limit the duration, input scope and permitted effects. Decide who will inspect the results and when. Without those boundaries, “pilot” can become a permanent state in which real work depends on software that nobody has formally accepted. ## Readiness includes the people after the launch The product team can build a working demonstration while the organisation remains unable to operate it. Someone must notice when documents change, decide whether the evaluation needs updating and handle questions that the system cannot resolve. Ask who performs those tasks on an ordinary Tuesday, not only during launch week. If the answer is the project's most experienced engineer, inspect whether that responsibility is realistic and whether another person could take over. A process that depends on undocumented judgement can work for a while, but its dependence should be visible. Training also belongs to the evidence boundary. A user may need to learn what a citation does and does not establish, how to correct the system and when to stop relying on it. The assessment should not assume that a familiar chat interface removes the need for those skills. Familiarity can encourage overconfidence as easily as it can reduce friction. The 2024 NIST generative AI profile treats risks as matters spanning system design, deployment and use. [NIST AI 600-1](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf?ref=devinside.cloud). For this proposed method, the practical implication is to include the operating workflow and its owners in the test. It does not follow that every deployment needs the same governance machinery. ## The strongest case for a maturity score 03 / Watch the mechanism ### Use the score to find the decision ![An aggregate readiness score leads to a specific evidence gap, an owner and a bounded commitment.](https://devinside.cloud/content/images/2026/11/devinside/M19-v3.svg) Use the score to find the decisionAn aggregate readiness score leads to a specific evidence gap, an owner and a bounded commitment. Animated explanation, not an execution recording.M19 / PROCESSUse the score to find the decisionReadinessscoreSpecificevidence gapAccountableownerBounded nextcommitmentChanged inputs reopen itConceptual / hypothetical. Not measured. Play animation[Enlarge diagram](https://devinside.cloud/content/images/2026/11/devinside/M19-v3.svg) Static view. Play to see how the mechanism unfolds. Suppose a maturity score points to weak source governance. The useful next step is to inspect the unresolved approval question and let its owner choose a bounded pilot, rather than treat the score as deployment permission. Interpretation and evidence - A score directs attention. - Evidence supports the decision. - Reopen the decision when its inputs change. conceptual/hypothetical, not measured Scores have a legitimate role. A large organisation may need to compare teams, allocate support or track whether basic practices are spreading. A common instrument can expose variation that a collection of narrative reports would make difficult to see. Executives cannot personally inspect every experiment. The problem is not aggregation itself. It is aggregation without a route back to the decisions and evidence underneath it. A score can be useful as an index into a register of findings. It becomes misleading when it is treated as a universal permission to deploy or as proof that a particular use case is safe. If an organisation keeps a maturity score, publish its construction. Explain the dimensions, evidence standards and weighting. Show which questions are unresolved and which conditions cannot be compensated for by strength elsewhere. Excellent training cannot numerically cancel an undefined access boundary. A high score in experimentation cannot make an unowned production incident acceptable. Use the score to direct attention, then use the evidence to decide. That preserves the managerial convenience without asking the number to perform a judgement it cannot express. It also creates a meaningful challenge: if a team disputes its score, it can identify the evidence or weighting that should change. ## Readiness changes when the system changes An accepted pilot is not permanently ready. A new source collection, a changed model, a wider audience or an action-taking integration can invalidate earlier evidence. The assessment should state which changes require reevaluation and which remain inside the tested boundary. This does not require rerunning every test after every edit. It requires understanding dependencies. Changing the colour of a button should not trigger a corpus audit. Changing the permission filter should. A new document parser may require checking table extraction even when the model and prompts remain unchanged. Keep the evidence tied to versions. A result from one corpus and model configuration should not silently certify another. The organisation can then reuse valid evidence instead of repeatedly starting from zero, while still recognising when a material assumption has changed. That is also a healthier way to discuss progress. Progress is not merely a higher score or a longer list of deployed tools. It can be a reduced uncertainty, a clarified boundary or a decision not to automate a task whose costs exceed its value. Those outcomes deserve to remain visible even when they do not produce a launch announcement. ## Separate identity, data and operation gaps 01 / See the idea ### Separate the gaps that protect different promises ![Identity, data and operational readiness are separate prerequisites that cannot simply offset each other numerically.](https://devinside.cloud/content/images/2026/11/devinside/M19-kd1.svg) [Enlarge diagram](https://devinside.cloud/content/images/2026/11/devinside/M19-kd1.svg) Correct content can still be unauthorized, and authorized content can still be obsolete. Each gate needs an owner and evidence appropriate to its consequence. Interpretation and evidence - Tie readiness to a use case. - Keep prerequisites separate. - Choose the next controlling gap. Conceptual teaching diagram; no additional empirical result or organizational measurement claimed. Consider a hypothetical assistant that retrieves internal project templates and can later create a draft in a document system. Its first readiness review should not treat access, content correctness and recovery as interchangeable dimensions of one score. The identity question is whether the requesting person may see the selected material and perform the proposed action. The data question is whether the material is current, correctly extracted and appropriate to the task. The operational question is whether the system can explain the outcome when a dependency fails or an acknowledgement is lost. A successful test in one category cannot compensate for a failed prerequisite in another. Correctly summarizing an inaccessible document is not an acceptable retrieval result. A permission check does not prove that the document version is current. A correct draft does not prove that a failed submission can be reconciled without duplication. The categories should help select tests, not become another abstract taxonomy. For the template workflow, an identity test could include one deliberately inaccessible item. A data test could distinguish current and superseded versions. An operational test could interrupt a submission after the destination may have accepted it. Each has a different expected outcome and a different owner. The record should say what remains unknown after the test. A successful read-only retrieval pilot can resolve selected identity and data questions while leaving action recovery deliberately out of scope. That is a coherent result if the pilot's authority remains read-only. It becomes misleading only when the result is reused to justify a broader responsibility without new evidence. ## Contemporary laboratory evidence shows how a gap changes state 02 / See the idea ### A gap changes state through evidence ![An untested dependency becomes a known failure and then a verified repair after the same probe passes.](https://devinside.cloud/content/images/2026/11/devinside/M19-kd2.svg) [Enlarge diagram](https://devinside.cloud/content/images/2026/11/devinside/M19-kd2.svg) The state change is meaningful because the acceptance condition remains fixed. A successful repair supports the declared fixture boundary rather than a universal deployment approval. Interpretation and evidence - Unknown is not the same as failure. - Keep the acceptance condition stable. - Preserve residual limits. Conceptual teaching diagram; no additional empirical result or organizational measurement claimed. The following examples refer to controlled laboratories executed on 12 November 2026\. They are contemporary additions after this article's February 2026 context date, not evidence that the tests existed earlier or that a production organization was certified ready. In the restricted SQL-agent laboratory, approved observations succeeded under a verified database-user context. Fixed attempts to update, drop and read unauthorized data were rejected by SQL Server. The tool also rejected unsupported proposals before opening the query path. These results resolve selected permission questions for that fixture. They do not resolve every AI-readiness question. The provider was scripted, so the test says nothing about a real model's language accuracy. The trusted host created the database administratively and then impersonated the restricted user, so it does not prove isolation from arbitrary code executing inside that host. The evidence closes a named gap while leaving adjacent boundaries explicit. The recovery laboratory provides a different state transition. A real database backup was restored and its expected transactions verified. The application probe initially reported dependency\_missing because an external template was absent. After the matching content was restored, the bounded probe passed. A later wrong-content case was rejected by the hash comparison. Before the missing-template test, dependency readiness was an unanswered question. The observed failure made it a known unmet prerequisite. Restoring and checking the expected content resolved that prerequisite for the fixture. Calling every stage medium risk would have hidden the useful progression from unknown to adverse evidence to verified repair. The result still does not establish a regional recovery objective or a complete production deployment. It shows how a readiness claim becomes stronger when a test can fail for a specific reason and a repair can be checked against the same contract. This is the evidence-gap method in concrete form. The value is not the number of green checks. It is knowing which responsibility each check supports, which change made the state different and which remaining question controls the next commitment. ## Make the next commitment smaller when evidence is expensive Some evidence is costly to obtain before a product has demonstrated value. A team may not be ready to provision a production corpus, build every integration or rehearse a full recovery merely to learn whether users find the interaction useful. Insisting on all of that at once can make assessment an obstacle to learning. The proportional response is to change the commitment, not to describe missing evidence as though it already exists. Use approved synthetic material to test the interaction. Keep actions in draft form. Limit the audience and duration. State which results would justify spending effort on the next boundary. For the hypothetical template assistant, an early study might ask whether users can locate and verify the right public template more easily than with existing search. That can be useful without confidential data or automated publication. The result should remain an interaction finding until identity and operational responsibilities are actually introduced and tested. The counterargument is that narrowly scoped pilots can become unrepresentative. A perfectly curated corpus may hide the contradictions that dominate real work. That concern should shape the expansion gate: identify which production condition is missing and test it before using the pilot to justify broader deployment. The team should also avoid endlessly shrinking the scope until the original benefit disappears. A draft-only workflow may be safer, but if the economic case depends entirely on unattended submission, the action boundary remains a central unresolved question. The assessment should make that dependency visible rather than celebrating a pilot that cannot support the promised outcome. ## Keep unresolved gaps from becoming permanent background noise A gap register can become as ceremonial as a maturity score if every review repeats the same unresolved items. Each material gap needs a next decision: gather a defined observation, repair an observed defect, narrow the responsibility or accept a residual uncertainty through the appropriate owner. The owner must have authority over the required change. Engineering can implement a permission filter, but it may not decide which users should have access. A business owner can choose a supported workflow, but may need an operations owner to accept its recovery obligations. Naming a person without the relevant decision rights does not resolve ownership. Evidence should remain reusable when its conditions still hold. The team does not need to rerun an unchanged access test because a paragraph was edited. It does need to revisit that evidence when the authorization path changes. This keeps readiness work focused on material dependencies rather than on making every report look recently refreshed. The review should end when the authorized next commitment has sufficient support, even if the system is not ready for every imaginable use. That is not complacency. It is a way to make acceptance finite and honest. Broader responsibility creates a new boundary and may reopen different gaps. The resulting progress can be stated plainly: these questions were resolved by these observations; these limitations remain deliberate; this owner can authorize the next bounded step. That statement is more actionable than either a universal assurance or an unending list of concerns. ## End the assessment with a next decision A useful readiness review should leave the organisation able to choose among concrete actions. Proceed within a defined boundary. Run a specific experiment. Repair an identified prerequisite. Stop because the proposed benefit is not supported. Each action should have an owner and an observable completion condition. For the hypothetical firm, the next step might be a monitored retrieval pilot on one approved template family, with explicit tests for obsolete versions and access boundaries. The unresolved question might be whether review effort remains low enough to justify expansion. That is a clearer state than “seventy-four percent ready,” even if the organisation retains the score for portfolio reporting. Readiness is a relationship between a proposed responsibility and the evidence available to support it. Expressing it as gaps makes that relationship inspectable. The organisation can see what it knows, what it is assuming and which observation would justify taking on more responsibility. That is a practical foundation for progress, including the progress that comes from discovering a boundary before crossing it.