LEARN. PRACTICE. GROW.1. Define the decision before choosing the tool
In a fictional order-intake project, the sponsor requests a new rules engine because operators route requests inconsistently. Before comparing products, describe the decision to improve: given a request under specified conditions, what action should occur and who handles exceptions? Collect examples of delays, reprocessing and manual intervention, distinguishing frequency from consequence. An infrequent incident can justify a mandatory condition without dominating volume. Define the request population and service boundaries, including when responsibility passes to another system. Changing a rule, training operators or improving information may be relevant without immediately replacing the platform. Retain assumptions and open questions as analysis work rather than prematurely turning them into approved requirements.
2. Prepare a table that supports useful questions
Use an exercise with three binary conditions: repeated request, arrival after cutoff and high risk. There are eight possible combinations within this deliberately limited universe. For each combination, ask for an expected action and the rule’s rationale. Do not equate a blank cell with permission to proceed: it may represent missing information. Define what repeated means, the identity used for comparison and the source of risk classification. The teaching model assumes these conditions were already determined correctly; a real implementation would need to establish that determination. If an unknown state appears, the binary universe no longer covers the case and needs an explicit decision. The table organizes discussion but gives the analyst no authority to invent policy.
3. Distinguish gaps, overlap and priority
Under the exercise contract, each combination must match exactly one action. A repeated request goes to reconciliation; a new request after cutoff waits for the next window; before cutoff, risk distinguishes processing from review. If the processing rule also accepts high risk, that combination may trigger two actions. Executing only the first row hides overlap without establishing which action is correct. A priority-based policy can be valid, but priority must be defined, approved and exercised as part of the contract. A combination with no action is likewise not resolved merely because code returns a default. Record the gap, impact and decision owner, preserving the examples that exposed the problem.
4. Treat boundaries and identity as requirements
“After 17:00” alone does not define behavior exactly at 17:00, the timezone or timestamp origin. Distinguish receipt, validation and downstream submission. A file received before the limit may only be validated afterward; the rule must identify the deciding event. For reprocessing, the same technical identifier may represent another attempt at one operation, while a new identifier does not prove a new operation. Define identity and retention of decision-relevant information with the appropriate owners. Do not use clock tolerances or identifier transformation as shortcuts without analyzing consequences. Examples should include the boundary and immediately preceding and following values at agreed precision. These decisions connect requirements to tests and observability that operations will need.
5. Recommend with explicit limits
Run the local model and compare the approved table with two controlled changes: remove one rule and broaden another. Explain why these produce a gap and an overlap respectively. The result establishes only modeled combinations; it does not check integrations, risk classification or financial effects. To recommend an option, combine coverage with cost, dependencies, operational capacity and mandatory conditions. A high weighted score does not compensate for a condition the organization designated as blocking. If an exception is permitted, present its scope and consequences to the correct authority. The next step may be a prototype to reduce uncertainty rather than a final purchasing decision. Deliver versioned rules, examples, uncertainties and decisions so development, QA and APS share the same understanding.
Eight combinations of three binary conditions; broadening a rule can create two actions for one request.
Common pitfalls
Using row order as implicit policy; treating an unknown condition as false; assuming a small model covers real integrations.
Related topics: Version-specific evidence and release decisions
A usable rule has scope, conditions, action, authority and examples exercising its boundaries.
Reference: PMI-PBA Examination Content Outline · Five-domain ECO / verified 2026-10-01