Requirements for AI-Enabled Work: Turn Your Use-Case Canvas into a Delivery Conversation
PathPatron Use-Case Canvas — 7 of 7
Requirements are often treated as paperwork that starts after a team has chosen a tool. That is backwards.
If you have followed the PathPatron Use-Case Canvas, you are not beginning from a blank page. This series has guided you through one living canvas, step by step: whose problem matters, where the pain sits, how the work moves, what delay costs, and which future-state option is proportionate. Requirements are where those entries become a delivery conversation: what people need to achieve, what the workflow must do, and which technical capabilities the team may need to configure, integrate, build or securely access.
Article 7 of 7 does not introduce another canvas or restart the process. It completes the requirements area of the same Use-Case Canvas, then makes its implications clear enough for a business leader and a technical team to explore delivery together.
The supplier-onboarding story, continued
Across this series, a supplier-onboarding request has become clearer step by step.
In Article 1, we recorded the people affected: the requester wants a supplier enabled quickly; Procurement needs a complete and defensible record; Finance needs the right checks; the supplier needs a clear, timely response.
In Article 2, we recorded different pains and decision rights. A requester may experience delay; a buyer may carry the accountability for a missing document; Finance may need a different evidence standard. Those are not interchangeable views of the same problem.
In Article 3, the vague ambition — “use AI to speed up onboarding” — became a use case: identify missing mandatory supplier information and prepare a follow-up.
In Article 4, the work map exposed the hand-offs: request arrives, documents are collected, evidence is checked, exceptions are resolved, a record is created and the supplier receives a response. It also showed where a wrong or premature action would hurt.
In Article 5, the cost of not solving became visible: repeated follow-ups, Finance rechecking, delayed purchasing and avoidable service friction.
In Article 6, the team compared options. It did not choose a system that approves suppliers. It chose bounded assistance: identify likely gaps, explain the evidence, draft a follow-up and hand uncertain cases to a named reviewer.
Now, in Article 7, the requirements area of the Use-Case Canvas captures what has emerged from that path. The core requirement is no longer “build an agent.” It is:
When a procurement request contains permitted supplier documents, the system may identify missing mandatory information and draft a follow-up. It may not approve contractual terms, create a vendor record, or send an external commitment without assigned human authority.
That statement contains a process rule, an information boundary, an authority boundary and an escalation route. But it is not yet a complete technical conversation. The next task is to translate it without asking a non-technical leader to pretend to be a solution architect.
From a business need to technical options
“Procurement needs visibility of incomplete supplier evidence” is a valid business need. It is not a finished requirement, and it is not automatically “build a dashboard.” A dashboard is one possible response. The team needs to make the chain visible:
| What the Use-Case Canvas already tells us | Delivery requirement | Capabilities for the technical team to assess | What must be validated |
|---|---|---|---|
| Buyers lose time chasing missing evidence; the work map shows the request, check and escalation steps | A buyer can see which mandatory evidence is missing for each request and who owns the next action | A work queue or dashboard; a status model; data fields for evidence and owner; role-based access; source-system integration | Which statuses exist today, which system is the source of truth, and who is permitted to see supplier information |
| The chosen future state is bounded assistance, not autonomous approval | The system flags likely gaps and prepares a follow-up; a named person approves external communication | Document extraction or classification; confidence threshold; notification logic; draft-message UI; approval workflow; audit log | Test cases, threshold, approval route and the conditions under which the system must stop and escalate |
| Finance has a distinct evidence standard and exceptions create risk | The system keeps the evidence and the reason for its recommendation available to the reviewer | Evidence links; immutable decision history; integration or access to the relevant record store; retention and security controls | Required retention period, access model, audit obligations and exception handling |
The leader’s job is to describe the outcome, the rules, the affected people and the test for success. The technical team’s job is to turn that into feasible options, architecture, effort and trade-offs. The requirement is specific enough to enable that conversation, but it does not prematurely mandate a particular UI, database or vendor.
The Requirement Evidence and Delivery Trace
Use a Requirement Evidence Trace for each material workflow rule. It keeps requirements grounded in evidence rather than confident-sounding guesses.
| Delivery requirement | Evidence already found in the Use-Case Canvas | Capability / technical implication to assess | Confidence / open assumption | Information owner | Validation and acceptance test |
|---|---|---|---|---|---|
| Identify missing mandatory documents | Work map; policy checklist; examples of incomplete requests | Document intake; status fields; rules or classification; source-system access | Confirm the current checklist and document variants | Procurement process owner + system/data owner | Review five recent cases: the agreed gaps are correctly shown with their source evidence |
| Draft a follow-up | Existing supplier email patterns; brand/contractual guidance | Draft-message interface; notification route; approval workflow; audit log | Draft must not create a commitment | Procurement + Legal / Comms as relevant | Approve template and edge cases; no message is sent without the configured approval route |
| Escalate uncertainty | Exceptions observed in the work map | Confidence signal; reviewer queue; exception status; alerting | Define what counts as low confidence | Procurement lead + technical lead | Agree threshold and reviewer queue; uncertain cases are flagged, not silently passed |
| Use source documents safely | Supplier documents and approved source systems | Permissions; integration/API or secure access; evidence links; retention controls | Confirm permitted data and retention route | Data / privacy / security owner | Data-access and retention check; reviewer can see the source evidence for each conclusion |
The trace makes one disciplined distinction: known evidence, plausible assumption, and validated requirement are not the same thing. A good delivery team can work with all three, as long as it labels them honestly.
This is a zoom-in on the requirements area of your one Use-Case Canvas. It is not a second canvas or a request to run another workshop.
Where the information comes from
The earlier entries in the Use-Case Canvas should yield much of the material. If they did not — or a deadline means they could not be completed perfectly — the answer is not to pretend certainty. Use a focused evidence search.
Start with the work itself:
process maps and real cases, including normal, messy and failed cases;
inboxes, tickets, call notes and service data that reveal repeated exceptions;
policies, contract terms, approval matrices and data-retention rules;
system fields, integrations, identities, logs and the actual source of truth;
supplier documentation, implementation guides and known product constraints;
the people who own the process, the data, the risk and the experience of those affected.
Do not ask “the business” for requirements. Ask a named question of a named owner: Who can confirm the mandatory evidence? Who owns the source system? Who may approve, change or send? Who has to live with an error?
When evidence is incomplete and the deadline is real
There are three responsible moves:
Leave the item visibly unknown. “We do not yet know the current exception rate” is useful information, not failure.
Create an assumption to validate. For example: “Assume the model only drafts a message; Procurement validates the first 20 cases.” State who must validate it and by when.
Use a safe, reversible boundary. Keep external sending, approval, payment, record creation and irreversible changes with a person until the evidence is sufficient.
You can create a credible working estimate from a small sample, public standards, vendor documentation, comparable cases or carefully scoped desk research. Google and AI can accelerate the research, but they cannot turn an unverified estimate into a requirement.
Use AI to structure documents, cluster exceptions, compare anonymised cases, generate interview questions and draft the evidence trace. Keep a link or source beside each claim. Ask AI to flag assumptions and counterexamples. Do not ask it to invent a policy, access right, cost estimate or stakeholder view that only the organisation can validate.
Prepare with AI; validate with people
This does not have to become another all-day workshop.
For a straightforward workflow, prepare the evidence trace asynchronously. Give each owner only the rows they can validate: Procurement confirms process rules; IT or data confirms systems and access; Risk, Privacy or Legal confirms boundaries where needed; affected users challenge whether the proposed outcome actually helps. A short, well-prepared validation pass is often better than inviting everyone to a blank board.
Use a live session when there is a real decision to make: owners disagree, an exception path is unclear, the authority boundary is material, or the team must prioritise trade-offs. A 60–90 minute in-person or online session can then resolve the few questions that matter. If you use Mural or Miro, place the single completed Use-Case Canvas in the background and add the requirements/technical-options trace beside it: one colour for evidence, one for assumptions and one for decisions.
The goal is not workshop theatre. It is a shared decision that can be operated later.
Give the technical team a usable brief
Once the trace is credible, consolidate it into a delivery-ready brief. This is how a leader avoids a vague request (“we need a dashboard”) while leaving solution design with the people responsible for it.
| Layer | What the team must be able to answer |
|---|---|
| Process and people | What triggers the work? Which roles, rules, hand-offs and affected people matter? |
| Information and systems | What data is permitted? What is the source of truth? Which fields, identities, access, integrations and databases must the team assess? |
| Authority and controls | What may be drafted, classified, sent, changed, approved or spent? What must escalate, and what is logged? |
| Constraints | Which deadlines, contractual conditions, regulatory duties, security standards or geography requirements apply? |
| Quality and acceptance | What does a good result look like? How are completeness, accuracy, fairness, timeliness and user experience checked? |
| Operations | Who owns monitoring, source updates, user support, incident recovery and improvement after launch? |
For the supplier example, useful acceptance criteria are observable: on
mandatory documents are identified correctly in the agreed test cases;
uncertain cases are flagged, rather than silently passed;
no external message is sent without the configured approval route;
a reviewer can see the source evidence and the reason for escalation;
the process owner can correct a rule, test the change and see when it takes effect.
These criteria do not promise perfection. They create a controlled test and a way to learn.
The leader’s job: turn a one-off into a practice
The most common failure is not poor wording in a requirements document. It is losing the decisions after a pilot moves on.
Make the Requirement Evidence Trace a lightweight operating practice for material AI-enabled workflows:
name one accountable business owner and the operational owners for process, data and controls;
store the trace with the process map, test evidence and key decisions — not in someone’s personal notes;
require a visible validation before any meaningful change in authority, data source or external action;
log exceptions, overrides and failures as requirements signals;
review the trace after a material policy, supplier, model, workflow or regulatory change, and on a proportionate regular cadence.
This is not bureaucracy for its own sake. It lets a new team member understand why a workflow is allowed to act, where its limits are, and who must decide when reality changes.
Complete the Use-Case Canvas — then keep it alive
The one PathPatron Use-Case Canvas ends with a costed, constrained future-state choice and a requirements-to-delivery trace—not a compulsory implementation. Sometimes the responsible answer is to standardise the process, improve the data, retain a human decision or stop the initiative.
When the case moves into delivery, the Requirement Evidence Trace connects the Canvas to the Agent Handoff Map, The Review Loop and Operating Ownership After the Pilot. Together they turn a promising use case into work people can trust, operate and improve.
Continue the PathPatron Use-Case Canvas
People, Stakeholders and Targets
The Stakeholder-Pain Map
From Pain Point to a Real Use Case
Map the Work Before You Automate It
The Cost of Not Solving: Making Process Pain Visible
From Current State to a Credible Future State: Cost, Control & Change
Requirements for AI-Enabled Work: Turn What You Already Know into a Workflow People Can Trust — you are here.