Practical guide
AI fluency for business analysts: resolve rule ambiguity
Turn a fictional service requirement into examples that expose ambiguous boundaries before writing acceptance criteria.
Business analysts can use AI to turn a requirement into concrete examples while checking for ambiguity. This fictional request concerns a cancellation window for a workshop booking tool. It produces a decision table and owner questions, not legal terms, a production specification or a claim about Two Prune features.
Identify the words that require a decision
A requirement can sound clear while leaving important boundary cases undefined.
The fictional request says users may cancel up to two days before a workshop. It does not specify calendar days or forty-eight hours, which timezone controls the cutoff or whether a cancellation exactly at the boundary is accepted. Do not let AI fill those gaps with whichever convention seems common.
Write the requirement as supplied and list the unresolved terms. Identify the owner who must define the intended rule. Keep proposed interpretations labeled as alternatives rather than presenting one as the existing policy. A precise-looking formula would still be wrong if it encodes the wrong meaning.
Use examples to make the ambiguity visible
Concrete cases are easier to review than several competing abstract definitions.
Set a fictional workshop at Friday 10:00 in the stated local timezone. A request on Wednesday at 09:59 is more than forty-eight hours earlier; one at Wednesday 10:01 is less than forty-eight hours earlier. A calendar-day rule could treat those requests differently from an elapsed-hours rule.
Ask AI to show both interpretations without deciding which is correct. Add the exactly-Wednesday-10:00 case. The examples should reveal the unresolved boundary, not create a hidden policy through their expected results. Avoid using real booking data or actual customer cancellation requests in this practice task.
Record the clarified rule and its provenance
Once an owner decides, the examples should change to reflect that decision.
For the next stage of the fictional exercise, the owner specifies at least forty-eight elapsed hours before the start, with equality accepted. The timezone is fixed in the exercise and no daylight-saving transition occurs. Now the Wednesday 09:59 and 10:00 requests pass the stated rule; 10:01 does not.
Attach the clarification to the decision table. Do not retain an old example that contradicts the new wording. AI can update the table, but check each boundary calculation and preserve the owner’s actual scope. The added exercise assumptions do not resolve every possible timezone case in a real product.
Separate cancellation eligibility from downstream effects
One rule should not quietly invent refunds, notifications or record deletion.
The packet defines whether the cancellation is accepted. It says nothing about refunds, confirmation messages or retention. List those as separate questions if they matter to implementation. Do not ask AI to complete the workflow by assuming a refund is due or that a record should be removed.
Add a case where the booking is already cancelled. The desired repeated-request behavior remains undefined until the owner clarifies it. This exposes a separate state question from the time cutoff. Keep the two questions distinct so a developer can see which part is settled and which is not.
Hand over examples that are ready for review
Acceptance criteria should preserve the clarified rule and its remaining limits.
Deliver the original wording, ambiguity list, owner clarification, boundary table and unresolved repeated-request case. State which results are expected under the fictional rule and which still need a decision. This is a paper specification exercise; do not report executed system tests unless a system was actually tested.
Review whether the worker identified equality and time-unit ambiguity before writing confident criteria. The implementation consultant guide validates an agreed solution. This task creates a clearer agreement about behavior so later validation does not merely test one person’s unstated assumption.
Sources and scope
NIST: AI risk management. Skills England: workplace AI foundations.
These references provide background, not validation or endorsement of this exercise. The case details, calculations and suggested review questions are original instructional material. Use them to discuss observable work, not to infer customer outcomes, professional credentials or performance in every setting. Before adapting the exercise, confirm the relevant facts, approved tools, data permissions and decision owners. If you change the case, revisit the expected answers and checks as well. These examples describe practice tasks, not a promise that a particular product includes the fictional features.
Sources: [1] [2]
Sources
- 1.AI RMF Core · NIST
- 2.AI foundation skills for work benchmark · Skills England