Two payment rules, one record. Which one wins?

Read the sources, challenge two rules, then record your decision in this fictional case.

About this exercise and your answers

This fictional case uses a deliberately flawed draft, written for the exercise rather than taken from an AI response. It contains no client data or live payment standard.

Your entries are not submitted to us and the exercise is not graded. Download or copy your record before leaving, or turn on optional browser saving in Keep your record.

Review sources
Follow a decision
Self-review
Keep your record

Source pack · available throughout

Source notes

SYN-01 · Approved contract · V1

The target field payment_status permits only PENDING, COMPLETE and FAILED. The agreed mappings are QUEUED → PENDING, SETTLED → COMPLETE and REJECTED → FAILED.

SYN-02 · Observed legacy behaviour

The legacy field processing_state can also contain HELD.

SYN-03 · Unrelated example

A specification for another service says “retry failed requests three times”. This example is supplied for layout and tone only. Its business rules do not apply to this assignment.

1. Review the two rules

Use the three notes above. For each rule, record the evidence you found, what is missing and who needs to decide. If you are unsure, explain why.

CL-01: “Map HELD to FAILED.”

Support status

Evidence and reasoning — source ID, passage and relevance

Open question — what needs to be resolved?

Proposed decision owner — who needs to decide?

CL-02: “Retry failed requests three times.”

Support status

Evidence and reasoning — source ID, passage and relevance

Open question — what needs to be resolved?

Proposed decision owner — who needs to decide?

You can record later reflections separately.

Keep your record

Download your entries as a text file, or copy them below. The explained answer is a separate reference, so it stays distinct from your own work.

Copy your record if downloads are unavailable

Select the text below and copy it into your own document. It contains your entries, separately from the explained answer.

Your practice record — ready to copy

BA AI Collective | MY PRACTICE RECORD
Practice session revision: 1 — 26 September 2026
Fictional exercise. Your entries are kept here; the explained answer is available separately.
Stage: Initial review in progress.
No AI grading, certification, observed productivity result or executed test result is implied.
The claim statements below are supplied exercise prompts; the responses are learner entries.

ORIGINAL REVIEW — NOT YET CAPTURED
CL-01: Map HELD to FAILED.
Support status: [not recorded]
Learner evidence and reasoning: [not recorded]
Learner open question: [not recorded]
Learner proposed decision owner: [not recorded]

CL-02: Retry failed requests three times.
Support status: [not recorded]
Learner evidence and reasoning: [not recorded]
Learner open question: [not recorded]
Learner proposed decision owner: [not recorded]

LATER REFLECTION — AFTER READING THE EXPLAINED ANSWER
[not recorded]

FOLLOWING SUPPLIED FICTIONAL DEC-01 — LEARNER WORK
Changed requirement:
[not recorded]

HELD expected check (not executed):
[not recorded]

Existing mapping expected checks (not executed):
[not recorded]

Remaining questions and approval boundary:
[not recorded]

SELF-REVIEW — LEARNER ASSESSMENT, NOT A SCORE
Evidence and authority: can you trace each retained rule to an applicable source or DEC-01?
Outcome: [not recorded]
Evidence or correction: [not recorded]

Requirement and checks: do your HELD requirement and expected result agree, while preserving the three approved mappings?
Outcome: [not recorded]
Evidence or correction: [not recorded]

Uncertainty and approval: are retries, queue failure and other unexpected states still visible as unresolved decisions?
Outcome: [not recorded]
Evidence or correction: [not recorded]

Next action:
[not recorded]

Optional saving in this browser

Off by default. Saved records stay in browser storage on this device until you disable saving, remove them or clear site data. This does not sync across devices. Use fictional material only.

Save my record in this browser

Loading is available in an empty session so it cannot overwrite work in progress. Download, then reset if you want to load another record.

Browser saving is off. Download your work before leaving if you want to keep it.

Downloadable companion and worked records

DOWNLOADABLE COMPANION

Payments companion in Word

The same payments case, with workshop notes and linked working records.

Download the free companion ZIP

What you will work towards

A source-and-question record, a recorded decision, two requirements and linked acceptance checks. The supplied answers are for comparison, not certification or automated grading.

Work through it in this order

Start with the participant guide.
The participant guide includes instructions and response areas. Separate source extracts and a deliberately flawed draft are in the ZIP.
Read the participant guide (PDF)Edit the guide (Word)
Apply DEC-01 after saving your first attempt.
Revise the mapping and write requirements and acceptance checks. Keep unresolved questions visible.
Read the decision card (PDF)Download the card (Word)
Compare your reasoning.
Use the explained answers after your attempt. Check the source links and the limits of the decision, then try the transfer exercise.
Reveal the explained-answer downloads
Read the explained answers (PDF)Download the answers (Word)

AI is optional

Complete the exercise manually, or try the optional prompts on the supplied fictional sources. Use the blank AI review record (CSV) to distinguish a suggestion from evidence and a decision. The prompts have not been benchmarked against a particular provider.

Use only the supplied fictional material or information you are authorised to share. The session’s exercise notes describe its limits.

Extract the ZIP before opening its files. Choose PDF for reading or Word for editing. The free companion is separate from the paid toolkits; nothing in this exercise requires a purchase.

Optional: review an AI draft against the sources

OPTIONAL AI REVIEW

Make the output earn your trust.

Attempt the case yourself first. If you then use AI, keep its draft separate from your own answer and give it only the supplied fictional sources.

Set the boundary. Name the source versions, task and permitted output. Ask for gaps to remain questions rather than invented rules.
Check each consequential claim. Locate the exact source passage yourself. A plausible citation or a second model agreeing is not verification.
Test what would break the rule. Check missing values, conflicting sources, boundary conditions and exceptions as well as the happy path.
Keep authority separate. Record who may approve the decision. Neither confidence, a job title nor an AI response supplies that authority.
Record the outcome. Keep the tool and model version, date, prompt, source versions, errors found and corrections. Compare total preparation, drafting, review and correction time with a manual attempt at the same task.

Review worksheet (Word) · Review worksheet (PDF) · Markdown version · Download the blank AI review record

Research and evidence limits

This is a proposed evaluation method, not a measured productivity result. A 2025 requirements-engineering review informed the emphasis on verification. Its authors have not evaluated or endorsed these exercises. The fictional draft was authored for teaching, not captured from a particular model.

Further reading: preparing the requirements conversation

FROM JEN’S WORKING APPROACH

Preparing for a requirements conversation.

Useful knowledge is often spread across documents, system behaviour and people’s recollections. Jen’s notes describe gathering that material, talking through her understanding and carrying a concise playbook into focused requirements and testing conversations. The method below adapts that approach for practice; the illustration is entirely fictional.

Choose the source material. Record each source’s version, authority and permitted use. Keep observed behaviour separate from an approved rule. Use only material and recording tools permitted in your working environment.
Capture, then classify. Speak or write what you know (with or without AI). Label each statement as recollection, observation, assumption, question or documented decision before drafting. A transcription or summary can omit qualifications; check it.
Challenge: return to the evidence. Check the original passage and exceptions. Ask the relevant owner to resolve conflicts. A fresh AI thread gives a new context, not independent assurance.
Deliver: hand over an explicit baseline. Carry source references, approval status and unresolved questions into test design. Give the reviewer the original sources as well as the requirements, so a missing requirement can still be spotted.

The toolkit uses the same sequence with shorter working labels: Frame sets the problem and source boundaries; Inspect covers capture and classification; Decide records what an authorised owner has agreed; Check challenges the original sources and expected tests. Deliver keeps the approved baseline and open questions visible. An unapproved proposal stays open whichever labels you use.

Try a fictional legacy-report judgement

Task: A replacement report must reproduce an old service report. SRC-L1, a dated code extract from the old report, includes only CLOSED records. SRC-L2, an interview note, says the report includes all completed work. No approved definition of “completed” is supplied.

A draft proposes: “Include CLOSED and RESOLVED records.” Before opening the reasoning, record what each source supports, your question for the owner and what you would test once the rule is decided.

Compare the reasoning after your attempt

The code extract supports an observation about the old filter; it does not approve the replacement policy. The interview gives business vocabulary, but does not define which statuses it includes. Ask the report owner to define scope and resolve the difference.

Additional fictional decision DEC-L1: For this teaching slice, the authorised report owner approves CLOSED only for the replacement’s status filter; RESOLVED is excluded.

REQ-L1: For records that pass all other agreed filters, include CLOSED and exclude every other status. T-L1: Use otherwise identical eligible records with CLOSED and RESOLVED; expect only CLOSED to appear. Check each other valid status and a missing status separately. These are expected checks, not executed results.

Date boundaries, duplicate records and the other report filters remain open. This slice does not establish full like-for-like equivalence or authorise implementation.