Write the complete requirements pack for an AI email-triage feature: eval-based acceptance criteria referencing a golden set, failure modes and fallbacks as numbered requirements, oversight with a real override path, EU AI Act transparency, and DPDP-aware privacy requirements. A circulating draft contains four classic AI-requirements defects — find them, fix them, finish the pack.
Meridian General Insurance's claims inbox receives roughly 14,000 emails a month — new claims, document submissions, status queries, complaints, and the occasional solicitor's letter. The pilot now approved: an AI triage feature that classifies each email, routes it to the right queue, drafts an acknowledgment, and flags urgency. A solution consultant produced a draft requirements pack; Divya owns turning it into the real thing. This is the track's signature deliverable: requirements for a system that is probabilistic, where "shall be accurate" is not a requirement but a wish, and where failure modes are specified with the same rigor as features.
The critique target. Four defects are planted; the rest ranges from serviceable to good.
DRAFT — AI EMAIL TRIAGE, REQUIREMENTS v0.7
DR-01 The system shall classify inbound claims-inbox emails into:
new-claim, document-submission, status-query, complaint,
legal, other.
DR-02 The classifier shall be accurate.
DR-03 Emails classified new-claim shall be routed to the FNOL queue
within 5 minutes of receipt.
DR-04 The system shall draft an acknowledgment reply for human
review before sending.
DR-05 Failure modes: (a) IF classification confidence < 0.75, THEN
the email shall route to the manual triage queue; (b) IF the
AI service is unavailable > 10 minutes, THEN all emails shall
route to manual triage and an alert shall fire.
DR-06 Oversight: the triage team lead shall be notified of all
emails routed by the AI, via a daily summary report.
DR-07 Complaint and legal emails shall never receive an
auto-drafted reply; human handling only.
DR-08 Emails and AI outputs shall be retained for model
improvement purposes.
DR-09 The system shall process personal data in claim emails in
accordance with applicable law.
Run the defect hunt before writing anything new. Audit DR-01–09 against four AI-requirements failure patterns: an untestable quality claim (find the requirement no test could fail), a missing failure mode (list threats an email-ingesting AI faces and check DR-05's coverage — think adversarial, not just technical), oversight without power (can the overseer actually do anything, in time, with what DR-06 gives them?), and an unbounded data clause (check every retention and purpose statement for a missing limit). Log defects: ID | Defect | Why it fails | Rewrite direction. Expect exactly four majors.
Rewrite the untestable criterion as eval-based acceptance criteria. This is the pack's heart. Pattern: "On golden-set vX, the classifier shall achieve ≥ [target] macro-F1, with per-class recall ≥ [floor] for new-claim and legal classes; measured by the versioned eval harness on every model or prompt change, and weekly in production on a sampled, human-labelled subset." Define the golden set as a requirement of its own: composition (mirror the case mix, exceptions included — Lab 13's inventory logic), size, labelling process, versioning, and ownership. Numbers you cannot ground yet get a TBD with a named decision forum — never a confident invention.
Build the failure-mode catalog as numbered requirements. Brainstorm with AI — "List failure modes for an AI email-triage feature: input-level, model-level, integration-level, adversarial" — then write each surviving mode as an EARS-style requirement with detection + response + fallback. Your catalog must cover at minimum: low confidence, service outage (both in DR-05, keep them), misclassification discovered downstream (a correction loop, not just a shrug), prompt injection via email content (an email instructing the model to change its behaviour — the draft's blind spot), attachment-only emails with empty bodies, non-English/regional-language emails, and volume surge. Every mode gets a testable trigger and a named fallback queue or behaviour.
Rewrite oversight with an override path and teeth. Replace DR-06 with requirements that give the overseer three powers, each verifiable: see (queue-level dashboard of AI routings with confidence, near-real-time — a daily digest reviews yesterday's mistakes), correct (a one-action reroute that both fixes the email and logs a labelled correction feeding the weekly eval sample), and stop (a kill-switch requirement: any triage lead can revert the inbox to full manual routing within X minutes, no vendor ticket required). Add the sampling requirement: N% of high-confidence routings audited weekly — oversight that only reviews what the model doubts never catches what the model is confidently wrong about (Lab 13's X23 lesson).
Write the EU AI Act Article 50 transparency requirements. Meridian serves EU-resident policyholders through a partner, so draft for the strict case: WHEN an AI-drafted acknowledgment is sent, the message shall disclose that it was generated with AI assistance; WHEN a customer interacts with any automated triage response, the disclosure shall be clear at first interaction; disclosures shall be in the communication's language. Write each as a checkable requirement (presence of disclosure text is testable in UAT — connect it to your Lab 09 instincts). Add the boundary honestly: Article 50 is the transparency floor; classification of the system under the Act is a compliance determination — log it as an open item owned by legal, not silently self-assessed.
Write DPDP-aware privacy requirements with verification methods. Fix DR-08 and DR-09 into specific, verifiable requirements: retention with a stated period and trigger ("triage logs retained N months from email receipt, then deleted; N set by privacy office — TBD owner named"); purpose limitation (Lab 12's scar: model-improvement use requires a covering notice — requirement: "emails shall not be used for model training or evaluation unless the applicable notice covers that purpose, verified by privacy-office sign-off recorded in the pack"); data minimisation (only fields needed for routing enter the model context; attachments processed transiently); and a verification method column for every privacy requirement — how each will be shown true (config inspection, deletion-job evidence, DPIA reference, UAT case).
Assemble the pack and build its verification matrix. Structure: feature requirements (rewritten DR-01/03/04/07 as needed — DR-07 is good; keep it and say why), eval-based acceptance criteria + golden-set requirement, failure-mode catalog, oversight requirements, transparency requirements, privacy requirements, open items with owners. Then the matrix: every requirement × verification method (eval run / UAT case / config audit / process evidence / sign-off). Any requirement with an empty verification cell gets rewritten until it can be verified or demoted to an open item.
Red-team the finished pack. Prompt: "You are a hostile auditor reviewing requirements for an AI email-triage system. Find: any requirement that cannot be objectively verified; any failure mode absent from the catalog; any way the oversight can be bypassed; any data use without a stated purpose and period." Adjudicate every finding — fix, rebut in writing, or log as open. The pack ships with its rebuttals; that is what "defensible" means.
For AI features, "the system shall be accurate" is never an acceptance criterion — accuracy claims are only requirements when they name a metric, a threshold, a dataset version, and a measurement cadence.
A complete lab has all of the following:
AI-feature requirements differ from classical ones in exactly four places — accuracy becomes an eval against a versioned golden set, failure modes include what the input can say to the model, oversight means the power to see, correct, and stop, and every data clause carries a purpose and a period. Get those four right and the rest is Lab 03.