AI Readiness Decision Pack Design

An AI readiness decision pack should allow a sponsor to decide what may happen next, on what evidence, within which limits and under whose responsibility. Its purpose is not to prove that a team has completed many assessment activities. A useful pack distinguishes facts from assumptions, a proposed action from an authorised action, and a narrow permission to learn from permission to operate at scale.

Design the pack around one decision that matters now. A sponsor considering an internal, read-only pilot needs different evidence from a sponsor considering public access or automated transactions. Enterprise data and AI readiness assessment can supply the underlying evidence; the decision pack makes that evidence usable by the person accountable for the next commitment.

Begin with a decision sentence, not a readiness percentage

Write the requested decision in one sentence that names the activity, users, sources, action rights and duration or review point. For example: “Authorise preparation of a curator-reviewed accession-description assistant using the primary seed-bank collection, with pilot access withheld until the named source-boundary and alias checks are accepted.” This says what is proposed now and what still requires a later release decision.

Contrast that with “Approve the AI project because readiness is 82%.” A percentage does not identify the approved population, evidence age, unresolved prerequisite or authority to start. It can be included as a subordinate summary where its calculation is useful, but it cannot carry the decision. The sponsor should not have to infer launch permission from a green graphic or an optimistic executive summary.

Specify the decision owner and their actual mandate. A collection manager may approve use of collection descriptions but lack authority to approve a new hosting arrangement. A technology sponsor may approve expenditure but not change partner data-use terms. If several approvals are needed, show each separately rather than placing one signature under a sentence that silently spans all of them.

Worked example: a botanical seed-bank description assistant

The following organisation, counts and findings are hypothetical. A botanical seed bank wants to help curators draft plain-language descriptions of accessions from approved records. The proposed assistant would cite the records used and leave scientific interpretation with a curator. It would not infer germination viability, authorise seed release, modify conservation classifications or expose precise collection locations to public users.

The inventory contains 1,800 accession descriptions: 1,200 from the primary collection and 600 supplied by a partner programme. The primary collection's proposed use has a documented owner. The partner programme's permission for this AI use is unresolved. The pack therefore considers a 1,200-record preparation boundary, not a convenient claim that 1,800 records are available because they can all be downloaded.

An illustrative evidence exercise selects 120 primary-collection records randomly from the defined 1,200-record frame. It separately constructs 24 challenge cases involving aliases, incomplete dates and conflicting descriptive notes. These groups answer different questions. The random sample supports scoped estimates of observed record defects; the challenge set probes particular failure modes. Neither proves that generated descriptions will always be correct.

In the fictional findings, 12 sampled records lack a collection date. That is 10% of the 120-record sample, with uncertainty around any population estimate. Missing dates can be explicitly reported as unknown if the curator accepts that behaviour. Four challenge cases expose ambiguous historical plant aliases. Four out of 24 describes this deliberately difficult set; it is not an estimated prevalence across the collection.

Give the sponsor an evidence index they can actually use

Every material conclusion should point to a compact evidence record. Include the evidence identifier, question answered, source or observation, owner, date, scope, method and limitation. Attach a masked extract or controlled reference where appropriate. A list of links without an explanation of what each item supports forces the sponsor to repeat the assessment and encourages reliance on the headline alone.

Illustrative evidence index for the seed-bank decision

Reference	Supported conclusion	Limit	Accountable owner
E1: collection-use record	Defined use of the primary 1,200 descriptions has an owner-approved boundary	Does not cover the 600 partner descriptions	Collection owner
E2: random-sample review	12 of 120 sampled primary records lack collection dates	Snapshot and sampling uncertainty; not output accuracy	Data quality lead
E3: alias challenge review	Four of 24 selected cases need a documented ambiguity response	Challenge frequency is not population prevalence	Taxonomy reviewer
E4: access design	A proposed read-only curator boundary is specified	Design has not yet demonstrated effective enforcement	Application owner

Notice the difference between a documented design and an observed control. E4 can support a preparation decision; it cannot yet prove that a pilot excludes partner material. Similarly, E1 records a scoped business approval rather than certifying every legal or contractual question. Source authority and business meaning helps prevent an authoritative-looking document from being stretched beyond the claim it can support.

Separate the decision page from the supporting annexes

The first page should contain the request, recommendation, options, essential evidence, unresolved gates and next review point. Keep supporting detail accessible in annexes: the scope contract, source inventory, sampling notes, evidence register, boundary demonstrations, risk and uncertainty record, and remediation dependencies. Length is governed by the decision's complexity, not by a compulsory slide count.

Do not hide a material limitation in an appendix while stating unconditional readiness on the first page. In the example, partner-use uncertainty and untested access enforcement belong beside the recommendation. The full inventory and configuration notes can sit behind it. A reader should understand the restriction without opening every technical attachment, while a reviewer should still be able to inspect the basis.

Use a stable version and an assessment cutoff. Identify what changed since the previous pack: a new source, a resolved authority question, a revised pilot boundary or a different acceptance rule. A sponsor may otherwise approve a summary that no longer matches the attached evidence. Preserve the previously considered version so the decision history remains intelligible if later information changes the conclusion.

Present real options with consequences

Offer choices that a sponsor could genuinely take. In this example, one option is to pause all work until partner terms and alias handling are resolved. Another is to approve limited preparation using only the primary collection while withholding pilot authorisation. A third is to request a wider evidence exercise covering the partner programme before considering a broader pilot. Launching across all 1,800 records is not an available option while the necessary use permission remains unresolved.

For each feasible option, describe the learning gained, commitment required, dependencies and residual uncertainty. Avoid assigning unsupported savings or success probabilities. The narrower preparation option may establish whether source restriction and ambiguity handling can work, but it does not answer whether the partner records are suitable or whether public users could receive reliable descriptions. The wider assessment option costs additional effort and may still end in a restricted scope.

Include the consequence of doing nothing. Staff may continue drafting descriptions manually, which can be an acceptable baseline while evidence is collected. Do not portray that option as an automatic failure to innovate. The sponsor should compare a defined next experiment with a real current process, including its capacity and limitations, rather than with an imaginary zero-effort alternative.

Make uncertainty visible without making the pack indecisive

Classify uncertainty by the question it affects. Evidence may be missing, contradictory, stale, sampled, dependent on a stated assumption or outside the assessment scope. These are not interchangeable conditions. A missing partner approval requires a different response from sampling uncertainty about missing collection dates. A contradiction between two source owners requires a different response from a routine update to an old inventory.

State what would change the recommendation. If the partner grants an appropriately scoped permission, that removes one barrier but does not establish partner-record quality. If the alias reviewer defines a safe “cannot resolve this name” response, a new demonstration is still needed to show that the proposed workflow follows it. Linking each uncertainty to a decision consequence prevents a list of risks from becoming detached from action.

Separate confidence in the finding from the severity of the issue. The team may be highly confident that a mandatory permission is missing, or have weak evidence about a potentially serious exposure. Neither should be converted automatically into a middling score. A readiness scorecard can organise measured dimensions, while the pack preserves the interpretation and consequence of each unresolved fact.

Write conditions as observable evidence, not promises

“Resolve data issues before launch” is too vague to govern a decision. A useful condition specifies the excluded or required behaviour, evidence to demonstrate it, acceptance owner and consequence if unmet. For the seed-bank example, a condition could require a masked boundary exercise showing that the pilot account cannot retrieve partner descriptions through any included source path. This is stronger than a statement that the project intends to use only primary records.

A second condition could require the taxonomy reviewer to approve the response for ambiguous aliases, followed by a demonstration on the four identified challenge cases and additional near-boundary cases. The evidence should show an explicit unresolved-name response and source citation, rather than a plausible invented identification. Passing those cases supports the defined pilot condition; it does not establish universal taxonomic accuracy.

Define who records condition closure and who grants the subsequent pilot permission. The person completing remediation need not be the person accepting it. A conditional recommendation should not become automatic launch authority merely because a delivery team marks its tasks complete. Mandatory gates versus graded scores explains why a favourable summary cannot substitute for the outstanding evidence.

Include a specimen decision record

Filled example of a proposed sponsor record

Field	Illustrative entry
Decision requested	Approve preparation of a curator-reviewed, read-only description assistant
Population	Primary collection of 1,200 accession descriptions; partner 600 excluded
Permitted output	Draft descriptions with source references and explicit unknowns
Excluded actions	No record edits, seed-release decisions, viability conclusions or public access
Outstanding pilot gates	Demonstrated source exclusion and accepted alias ambiguity behaviour
Acceptance roles	Application owner for boundary evidence; taxonomy reviewer for meaning; sponsor for pilot authorisation
Next decision	Consider pilot access after the required evidence is accepted
Reassessment triggers	New source population, changed permissions, expanded outputs or a changed user group

This is a specimen recommendation, not a record of an actual approval. In a real pack, add the named decision-maker, decision date, accepted evidence version, funding limit where relevant and any dissent or reservation. Record the actual outcome as approved, restricted, deferred or declined according to the organisation's process. Do not preserve only the recommendation and assume it was accepted.

Trace the decision into owned follow-up work

A pack loses value if the decision cannot be translated into an owned next step. Link each condition to a remediation item with an accountable owner, dependencies, closure evidence and a review date. The source-exclusion demonstration depends on a settled inventory and an approved boundary. The alias demonstration depends on a reviewed meaning rule. Scheduling both as generic “testing” conceals the prerequisite work.

Distinguish a due date from an expiry date. A task's due date indicates when someone expects to complete it. The decision's validity may end when the source population or permission arrangement changes, regardless of the calendar. Some evidence also requires periodic refresh. State these rules explicitly so a sponsor does not assume a completed assessment provides indefinite permission.

Use data remediation backlog design for executable follow-up and ownership, evaluation and adoption readiness for the operational responsibilities around the proposed pilot. The pack should identify who receives the resulting evidence and who has the authority to reconsider the decision. It should not silently assign acceptance to the supplier who produced the work.

Show the commitment being made and the assumptions behind it

A preparation approval should explain which resources it commits, even when a detailed implementation budget is premature. Identify the collection-owner time, taxonomy review, technical evidence work and sponsor attention required for the proposed next step. Distinguish resources already confirmed from resources merely requested. An attractive plan that assumes unavailable curators is not ready to execute simply because its technical tasks are small.

Keep any estimate tied to its basis. If the effort depends on reviewing a fixed source population, a changed inventory should trigger reconsideration. If a specialist must adjudicate ambiguous names, identify whether that person has accepted the work and what happens if the queue exceeds the agreed capacity. The pack need not invent a precise price to make the commitment concrete; it must disclose the dependencies that could change the commitment.

Explain reversibility. Preparation using an authorised, masked extract may be easy to stop, while granting broad user access or distributing generated descriptions outside the organisation may create additional obligations. The proposed decision should identify the stopping point, retained evidence and disposition of temporary materials. These details help the sponsor choose a proportionate learning step without confusing a reversible investigation with an unrestricted operating launch.

Preserve disagreement and control how evidence is shared

A decision pack should retain material dissent in a usable form. If the taxonomy reviewer believes the alias rule remains ambiguous while the delivery team considers it sufficient, record the exact disagreement and the consequence for the requested activity. Do not replace two incompatible interpretations with an average confidence score. Identify who has authority to resolve the meaning question and what additional evidence would distinguish the positions.

Where a recommendation depends on an assumption, show the alternative. For example, if the primary collection's approval covers only internal curator use, a proposed public demonstration is outside that assumption. The pack should say that the public scenario requires a different decision, rather than suggesting that a small change in audience is an administrative detail. An assumption register is useful only when its entries connect to such decision consequences.

Share enough evidence for scrutiny without unnecessarily exposing sensitive collection details, partner terms or personal information in approval emails. A sponsor-facing extract can use masked identifiers and controlled references, while authorised reviewers retain access to the underlying evidence. Masking must not remove the field or context needed to assess the claim. Record where the complete evidence resides and how an authorised reviewer can inspect it.

Finally, distinguish an evidence link from a durable record. If a source is overwritten or a temporary workspace closes, the decision may lose its basis. Preserve the approved evidence version according to the organisation's retention and access rules. The pack should remain interpretable after the meeting without creating an uncontrolled duplicate archive of the underlying collection.

Review the pack from the sponsor's side of the table

Ask a reviewer unfamiliar with the assessment to answer five questions from the first page: what is being requested, what evidence supports it, what remains uncertain, what cannot happen yet and who decides next. If the answers require verbal explanation from the author, the pack needs clearer wording or a better evidence index. An impressive appendix does not compensate for an ambiguous request.

Then test consistency across the pack. The population counts must reconcile; the recommendation must respect the stated gates; the Arabic and English summaries must convey the same boundaries; the options must match the available permissions. If one summary says “pilot approved” while the detailed record says “preparation only,” correct the discrepancy before circulation. Translation is part of decision integrity when different stakeholders rely on different languages.

The NIST AI Risk Management Framework provides voluntary risk-management context. The decision-pack structure here is an original practical design, not a NIST certificate or a prescribed regulatory form. Its value comes from the quality and traceability of the evidence and the clarity of the resulting decision, not from adopting a familiar framework name.

To discuss a readiness decision pack, prepare the proposed next action, intended decision-maker, masked evidence inventory and the uncertainties currently blocking agreement. A well-designed pack should help the organisation make a proportionate commitment now, preserve the limits of that commitment and specify the evidence required to change it later.