Pre-pilot workflow triage
AI Workflow Readiness Assessment Template
Use a free evidence-led template to triage one recurring workflow, expose hard stops, and decide whether contained AI test planning is justified.
Published by WhichAI on . Updated .
Built for
Operations leaders, workflow owners, risk reviewers, and implementation teams screening one recurring task
Research intent
Download and apply a reusable worksheet before committing one recurring workflow to an AI pilot.
Direct answer
Direct answer
Use the blank worksheets to document one bounded current workflow across six operating factors, then apply every hard-stop row before choosing a next step. Observed condition, evidence maturity, and confidence stay separate. The result can justify more discovery, process repair, specialist review, human-led work, stopping the current proposal, or planning a contained test. It never authorizes a live or production test.
Download the public artifact
Start with the four assessment records and the instructional protocol.
Four assessment records with no completed assessment data and one instructional protocol provide a scope record, factor scorecard, hard-stop register, decision record, and deterministic disposition precedence before any contained AI test is planned.
Evidence v1, 2026-07-16. Blank template and protocol, no assessment run.
CSV template
Blank readiness scope template
A CSV for the bounded current workflow, evidence window, owners, affected parties, and preliminary containment feasibility.
CSV template
Blank readiness factor scorecard
A six-row CSV that separates observed condition, condition status, evidence level, confidence, stops, and reason codes.
CSV template
Blank hard-stop register
A CSV with auditable stop codes, triggers, required evidence, default dispositions, owners, and resolution rules.
CSV template
Blank readiness decision record
A CSV for the final disposition, stop and reason codes, specialist decisions, action owners, and reassessment conditions.
Markdown protocol
Readiness assessment protocol
A Markdown method with evidence semantics, six factor prompts, disposition precedence, specialist referrals, test-contract requirements, source notes, and limitations.
Finding 01
Score the evidence without turning it into a readiness grade
The template records recurrence, repeatability, permitted data access, exception control, effective human authority, and failure consequence. Each factor keeps the local observed condition separate from a 0 to 3 evidence level and a low, medium, or high confidence label. No total, average, weight, percentage, or color grade is calculated.
A well-documented adverse condition can carry strong evidence and still block the proposal. A favorable condition with weak evidence remains unknown. This separation keeps high volume or a stable common path from offsetting unresolved data permission, weak authority, or an uncontained consequence.
- Volume records recurrence and evidence availability, not value, urgency, savings, or automation fit.
- Repeatability records the common path, variation, change frequency, and which slice could be bounded.
- Exception control separates frequency, novelty, severity, detectability, intervention time, backlog, owner, and fallback.
- Human authority requires source access, domain competence, review time, rejection power, halt authority, escalation, logging, and recourse.
Finding 02
Let explicit stop codes override every favorable factor
The companion register defines auditable stops for unbounded scope, missing ownership, missing representative evidence, unresolved or prohibited data use, unapproved sensitive-data handling, unknown affected parties, missing halt or override authority, unblocked external action, missing containment or rollback, unresolved specialist review, and risk outside documented tolerance.
Each stop has a trigger, required evidence, default disposition, owner role, and resolution rule. When several conditions apply, the protocol records every reason code and uses fail-closed precedence. Explicit prohibition or uncontainable risk stops the current proposal before missing evidence, specialist referral, process repair, or a human-led disposition is considered.
- Privacy, security, fairness, accessibility, intellectual property, vendor, integration, legal, policy, contract, incident, and change questions route to qualified owners when relevant.
- Permitted data access is a local evidence field. The worksheet does not make a legal, security, privacy, contractual, or compliance determination.
- Rare severe exceptions remain visible even when the common path is stable or the exception count is low.
- A high evidence level never clears a stop code or changes the organization’s documented risk tolerance.
Finding 03
Treat a candidate label as permission to plan a test, not run one
The last disposition is BOUNDED_TEST_PLANNING_CANDIDATE. It is available only when the current workflow and case unit are bounded, required evidence is present, every hard-stop row is evaluated, no stop or specialist referral remains unresolved, all six factor conditions support planning, and preliminary containment, blocked external actions, fallback, and rollback are feasible.
That label does not contain a test design and does not approve live data, production traffic, autonomous action, account access, system writes, or deployment. The next stage is to build and separately authorize the controlled test plan. Separate field guides own blueprint completeness, pilot execution, and post-pilot scale readiness so this page does not become a second no-project or production-readiness guide.
- Use process repair first when the current path, case definition, current success boundary, or exception handling is too unstable to assess.
- Keep work human-led when the bounded scope still depends on retained professional, relationship, policy, or consequential judgment.
- Stop the current proposal when data use is prohibited, external action cannot be contained, or documented risk tolerance is exceeded.
- Reassess after the scope, evidence, data permission, authority, control, or operating context materially changes.
Primary sources checked for this finding
Inspectable original evidence
AI workflow readiness operational triage pack
Four assessment records with no completed assessment data and one instructional protocol provide a scope record, factor scorecard, hard-stop register, decision record, and deterministic disposition precedence before any contained AI test is planned.
Evidence v1
2026-07-16
Blank template and protocol, no assessment run
Method
- Define one bounded current workflow, case unit, observation window, accountable owner, affected parties, current path, current success boundary, excluded future actions, and downstream effects before filling factor rows.
- Record each observed condition separately from its evidence level and confidence, then inspect the six factors without calculating a total, average, weight, percentage, or overall grade.
- Evaluate every hard-stop row and specialist-referral code using the published precedence table, then record one disposition, every reason code, the responsible owner, and the evidence required for reassessment.
- Treat BOUNDED_TEST_PLANNING_CANDIDATE as permission to prepare a contained test plan only. Keep no_test_authorization true and require separate local authorization before live data, production systems, external actions, or deployment.
Limitations
- The four records contain prefilled prompts, stop definitions, allowed codes, and NOT_EVALUATED defaults, but no completed assessment data. The instructional protocol is populated. The pack contains no customer data, personal data, assessment run, observed output, benchmark, or business result.
- The factor model, evidence scale, confidence labels, stop codes, and disposition rules are original WhichAI protocol choices. They have not been validated as predictors of any outcome.
- The pack does not perform technical, security, privacy, fairness, accessibility, legal, contractual, vendor, integration, incident, or change-control assessment.
- A completed pack does not authorize live data, a production test, an automated external action, an account change, a system write, or deployment.
- The pack does not establish safety, compliance, lawful delegation, savings, return on investment, staffing effects, production readiness, or scale readiness.
template · CSV
Blank readiness scope template
A CSV for the bounded current workflow, evidence window, owners, affected parties, and preliminary containment feasibility.
template · CSV
Blank readiness factor scorecard
A six-row CSV that separates observed condition, condition status, evidence level, confidence, stops, and reason codes.
template · CSV
Blank hard-stop register
A CSV with auditable stop codes, triggers, required evidence, default dispositions, owners, and resolution rules.
template · CSV
Blank readiness decision record
A CSV for the final disposition, stop and reason codes, specialist decisions, action owners, and reassessment conditions.
protocol · Markdown
Readiness assessment protocol
A Markdown method with evidence semantics, six factor prompts, disposition precedence, specialist referrals, test-contract requirements, source notes, and limitations.
Method
- Define one bounded current workflow, one eligible case unit, the current trigger, inputs, output, current success boundary, excluded future actions, affected parties, downstream effects, and accountable owner before evaluating a factor.
- Collect dated local evidence across a disclosed observation window and operating cycle. Record sample completeness, common-path and exception definitions, disagreements, evidence references, and confidence.
- Record the observed condition separately from the 0 to 3 evidence level. The evidence level describes support for the observation and never acts as a positive readiness score.
- Evaluate every hard-stop row and specialist referral before the disposition table. Record all reason codes and use the highest-precedence fail-closed state.
- Permit BOUNDED_TEST_PLANNING_CANDIDATE only when current-state evidence and preliminary containment feasibility satisfy the published rule. Require a separate test plan and separate local authorization before any live data, production system, external action, or deployment is used.
Limitations
- This is an original WhichAI operational candidate triage protocol. It is not validated, comprehensive, standards-based, NIST-aligned, certified, or a substitute for a qualified assessment.
- The 0 to 3 evidence levels, condition labels, stop codes, reason codes, and disposition precedence are disclosed WhichAI design choices. The cited official sources do not prescribe them.
- The template does not test a model, vendor, integration, security control, privacy control, fairness property, accessibility requirement, incident response, or production workflow.
- The result depends on complete and honest local evidence. Missing cases, seasonal variation, hidden corrections, unresolved backlogs, and weak source records can change the disposition.
- No disposition predicts performance, safety, savings, return on investment, staffing effects, compliance, lawful delegation, production readiness, or scale readiness.
Primary sources
Check the source beside the conclusion.
Source access dates show when the cited material was checked. Current requirements, prices, and product behavior can change after that date.
National Institute of Standards and Technology
Artificial Intelligence Risk Management Framework 1.0
The MAP and MANAGE functions support documenting context, data suitability, human oversight, potential impacts, and whether development or deployment should proceed. This voluntary framework does not prescribe the WhichAI factors, evidence levels, stops, or dispositions.
Accessed 2026-07-16
National Institute of Standards and Technology
NIST AI RMF Playbook, Manage function
The Playbook asks whether AI is appropriate for a task and describes risk response, oversight, contingency, bypass, and deactivation questions. It does not prescribe the WhichAI factors, statuses, reason codes, or dispositions.
Accessed 2026-07-16
U.S. General Services Administration
Federal EOA Playbook, version 1
Pages 19 through 21 ask teams to inspect data structure, decisions and rules, situational human judgment, systems, interfaces, transaction volume, triggers, inputs, outputs, security, and approval. This is federal automation guidance, not a validated AI-readiness score or outcome forecast.
Accessed 2026-07-16
Australian Government Digital Transformation Agency
Guidance for AI proof of concept to scale, Appendix 1
The agency checklist asks whether AI is appropriate and covers workflows, data, integrations, ownership, governance, privacy, security, impact assessment, and approvals. It informed selected referral prompts but is not a universal requirement or validation of this artifact.
Accessed 2026-07-16
Two ways to act
Use the path that matches the work.
Self-serve WhichAI
Open a blank planner for the next bounded step.
Suggested next task: Design a bounded AI-assisted workflow plan for this candidate. Map its trigger, inputs, outputs, source evidence, human decisions, exceptions, controls, contained test mode, fallback, rollback, and acceptance checks without inventing outcomes. This link opens the generic planner without stored assessment data or URL prefill.
Open blank plannerWhichAI Solutions
Open a blank diagnostic for implementation complexity.
Use WhichAI Solutions when the assessment exposes cross-system dependencies, sensitive data, consequential decisions, disputed ownership, or recurring operating pressure that requires implementation design. This link opens the generic diagnostic without stored assessment data or URL prefill.
Open blank Solutions diagnosticContinue the operating map
Related implementation field guides
Implementation insight
When Is an AI Workflow Reliable Enough to Scale?
A scale-readiness gate based on an explicit acceptance envelope, representative reliability evidence, severe-failure tests, recovery, operating load, and drift controls.
Read the field guideImplementation insight
When AI Automation Is the Wrong Answer
A no-project test for low-volume, unstable, inaccessible, high-consequence, or unowned workflows where process repair or human capacity fits better.
Read the field guideImplementation insight
How to Pilot an AI Workflow Without Turning the Company Into a Migration Project
A bounded pilot design that uses representative work, shadow operation, explicit interfaces, human review, rollback, and a written scale decision.
Read the field guideImplementation insight
AI Workflow Blueprint: What Must Be Included Before You Build
A build-readiness checklist for the task contract, source data, component roles, handoffs, human review, exceptions, controls, costs, and pilot evidence.
Read the field guide