# AI Use-Case Feasibility Assessment Decides whether a use case needs a model at all, and whether the data and the error tolerance exist to build one. ## Deliverable One Markdown document, `feasibility-assessment.md`, in the structure set out under **Output** below. It is the input to **Agent & Prompt Specification**. ## Required inputs - **The use case, in the requester's own words** — what the system should produce, for whom, and what decision or action follows from its output. - **The data that exists today for this task** — where it lives, who may use it, and under what terms. - **The acceptable error** — what a wrong answer costs and who absorbs it. If any of the three is absent, report it as missing and never fill it in. A use case with no defined acceptable-error threshold is reported as not yet assessable: without one there is nothing to judge a result against. ## Optional inputs - The non-AI process that handles this task now, and what it costs to run - How often the task occurs and how quickly an answer is needed - Labels, annotations or historical outcomes attached to the existing data - Regulatory, contractual or residency terms that bind the data - Who reviews the output before it acts, and what they see when they review it - Earlier attempts at the same task, and why they stopped Every optional input that is absent becomes an entry under **Open questions**. It never becomes an assumption, and it never becomes a figure. ## Execution **1 — Restate the task as a decision.** Write down what the system is asked to produce, who consumes it, and what happens next because of it. A use case that cannot name the action its output changes is not yet a use case — record that and continue. **2 — Test whether a model is needed.** Describe the deterministic route — a rule, a lookup, a form, a person following a procedure — that would produce the same output. Where that route exists and meets the acceptable error, it is the recommendation. A model is justified only where the deterministic route fails, and this step names where it fails. **3 — Establish the baseline.** Record how the task is performed today and what that achieves, using measurements the requester supplies. Where nothing has been measured, write `unknown` and name what must be measured before any comparison can exist. A system with no baseline cannot be shown to be an improvement on anything. **4 — Audit the data.** For each source: what it holds, whether it is labelled for this task, who may use it for this purpose and under what terms, and whether it represents the population the system will meet in production. Tag each answer `verified` where a document or a sample was inspected, `reported` where a person stated it, and `unknown` otherwise. **5 — Define the acceptable error.** Both directions separately — what a wrong answer in each direction costs, who absorbs it, and whether it can be reversed. If the requester cannot state this, the assessment ends here with the verdict `not yet assessable`, because every later judgement depends on it. **6 — Bound the irreducible ambiguity.** Have the same cases answered independently by more than one qualified person and record where they disagree. Where competent people disagree, no system agrees with all of them, and the target sits below that ceiling. Where this has not been done, record the ceiling as `unmeasured` and carry it as a condition of the verdict. **7 — Write the verdict.** `go`, `no-go` or `not yet assessable`, with the evidence that produced it, the conditions that would change it, and what must be true before the next stage begins. ## Output `feasibility-assessment.md`, in this order: - **1. Use case and date** — the use case as received, its source, and when - **2. Decision it serves** — what the output is for, who consumes it, what action follows - **3. Non-AI route** — the deterministic or manual alternative, and where it fails - **4. Baseline** — how the task is performed today, and what that achieves - **5. Data audit** — per source: contents, labelling, permission, representativeness, and the tag `verified`, `reported` or `unknown` - **6. Acceptable error** — each direction, its cost, who absorbs it, whether it is reversible - **7. Ambiguity ceiling** — where qualified people disagree, and the ceiling that sets - **8. Verdict** — go, no-go or not yet assessable, with the evidence behind it - **9. Conditions and open questions** — what would change the verdict, what is missing, who can supply it ## Validation The assessment is ready when all of these hold: - Section 2 names the action that changes because of the output - Section 3 states the deterministic route and whether it is sufficient - Section 6 states both error directions and who absorbs each - Every claim in section 5 is tagged `verified`, `reported` or `unknown` - Section 8 carries one of the three permitted verdicts, with the evidence behind it - No accuracy, volume or cost figure appears that did not come from an input Fail the run if the verdict is `go` while section 6 is empty, or if any figure in the document has no source. ## Failure handling - **No acceptable-error threshold** — produce sections 1 to 5, mark section 8 `NOT ASSESSABLE`, and name who must set the threshold. A verdict without one is a preference. - **No data inventory** — produce section 5 as the list of sources that must be inventoried, and mark the verdict `PROVISIONAL`. Never assume data exists because the use case needs it. - **No access to the data or the current process** — sections 4 and 5 stand as `reported` only. State that nothing was verified and that the verdict inherits that uncertainty. - **Contradictory inputs** — record both, name both sources, and raise the contradiction in section 9 as blocking. Do not resolve it by choosing. - **Partial material** — produce every section the material supports, mark the rest `INCOMPLETE — pending `, and deliver.