LEARN. PRACTICE. GROW.1. Give data meaning
The limit field can be absent, contain null or contain zero. Those messages have distinguishable structures; the business must still define their meaning. In the exercise, absence preserves the current limit, null removes an optional limit and zero sets a zero limit. An adapter converting all three to zero destroys two intentions. Also record units, precision, allowed values and rounding rules where applicable. A value column without currency or scale can be interpreted differently by two consumers. For a fictional instruction, 1250 represents 12.50 units because the contract specifies integer hundredths. That is not a universal rule for every currency or product. Review invalid examples, boundaries and information returned to the user when a value is rejected. Precision exercise: three charges of 0.335, individually rounded to two decimals with ties upward, sum to 1.02. Summing before rounding gives 1.005 and then 1.01. Record the agreed path rather than selecting the more convenient result. For dates, declaring a string with format: date-time may only add an annotation in the tool used. In OpenAPI, validation behavior depends on support and configuration. If the requirement needs an unambiguous instant, actually check invalid values and offsets rather than assuming the document performs that check.
2. Assess compatibility with actual consumers
The original version returns only pending or completed. A new version adds manual review. One consumer ignores unknown fields but rejects states outside the original two values. Adding a state can break that consumer even though the document remains valid and no old field disappeared. Identify actual reading, validation and display behavior. Define coexisting versions, representation of new states for each and how to prevent a nonterminal condition being presented as completed. One option can defer exposing the state until the consumer is updated; another can provide an agreed translation preserving meaning and needed capabilities. Do not choose a translation solely to make the parser pass. The decision must retain the business outcome and identified constraints.
3. Protect decisions made against a version
Two people read instruction version v5. The first changes the destination account, creating v6. The second tries to change the amount using the complete v5 document. Without a condition, that can unintentionally restore the old account. In the HTTP example, If-Match with the strong ETag of the representation read makes the amendment conditional on the expected representation. If it does not match, the service must not perform that amendment as though nothing changed. This case assumes different requests and a 412 rejection; it does not address the already-applied-request exception. Define recovery: retrieve current state, show the relevant difference and confirm the intended amendment before resubmission. Automatically substituting the newest ETag can bypass protection without resolving the business conflict.
4. Separate security description from demonstrated access
An interface requires two mechanisms together, here called token and certificate. In OpenAPI, two schemes in one Security Requirement Object represent joint requirements; separate objects in the list represent alternatives. Thus security: [{token: [], certificate: []}] differs from security: [{token: []}, {certificate: []}]. These names assume schemes defined in the document and only illustrate contract interpretation. The description does not demonstrate server enforcement. Acceptance planning needs requests with both mechanisms and with each missing, within the authorized test scope. It must also check that a valid identity can retrieve only operations it owns. Knowing a correlation key should not by itself grant access to another client’s outcome.
5. Specify criteria that can fail
A useful acceptance example identifies initial state, action, expected observation and observation point. For a repeated identity, counting HTTP responses is insufficient: confirm the number of authorized movements and how each response relates to the operation. Include simultaneous attempts, changed content under one key, response loss and the retention boundary. For timing, define clock start and end events. In a fictional set of 100 eligible operations, all 100 receive acknowledgment within two seconds and 98 complete within two minutes. The criterion requires at least 99 completions within those two minutes. Fast acknowledgment satisfies another observation; it does not satisfy this criterion. Keep failed results distinct from tests not executed, without changing the denominator after seeing the outcome.
6. Decide per item in a partial batch
The batch contract permits independent item outcomes and a stable identity per instruction. A is confirmed, B was sent to the partner but its outcome is unknown, and C has not been sent. Reprocessing the whole batch with new identities can repeat A and B. Marking the entire batch failed also hides A’s movement. Prepare an item-level table: confirmed effect, unresolved effect or demonstrated absence of sending. In this exercise, C may follow the normal path, A retains its outcome and B enters reconciliation using its original identity. That conclusion depends on the given rules. If the contract requires whole-batch atomicity, a different design and evidence are needed. Do not carry independent-item policy into a batch with an all-or-nothing obligation.
7. Interpret evidence order
The service emits an increasing sequence per operation: 16 running, then 17 completed. The network delivers 17 first and 16 afterward. An interface applying whichever notification arrived last makes the operation incorrectly move backward. Under the exercise policy, the source-assigned sequence is monotonic within one operation and never resets. Therefore 17 takes precedence; 16 can remain historical evidence without replacing current state. If sequences restart across instances, part of the identity is missing or concurrent sources exist, this rule is no longer sufficiently defined. Clarify those conditions before generalizing. In an incident report, separate effect order from the order in which support received records. Screen time can measure receipt rather than execution.
8. Exercise: build the acceptance package
Candidate release R2 declares 72-hour protection, client-restricted lookup and independent item outcomes. You have three records: E1 repeated A/K7 after one hour in R1; E2 sent two simultaneous attempts for A/K8 in R2 and found one movement; E3 showed B/K9’s result to a session authenticated as A in R2. Prepare a report before reading the analysis. E2 supports the simultaneous case it executed; it does not alone cover 72 hours. E1 is historical evidence whose applicability and window are insufficient for that claim. E3 demonstrates failure of the agreed isolation. Propose tests at 71h59, exactly 72h and after the window, using the clock defined in the requirement. Distinguish satisfied requirements, missing evidence and observed failures; route the decision through agreed authority. A correct OpenAPI file does not eliminate E3.
Exercise files
Original Python exercise with instructions, local transactions and cancellation schedules. Requires Python 3.10 or later. Includes reasoned solutions and model limits.
A consumer accepts additional fields but rejects a new state. The change can be incompatible even though no old properties were removed.
Common pitfalls
Treating null as absence; assuming every addition is compatible; accepting only happy-path examples; confusing security description with enforcement; using notification arrival as execution order; resending a partial batch with new identities.
Related topics: Identity and recovery · Traceability and monitoring
A useful interface requirement makes data, states, permissions and exceptions explicit. Acceptance needs observations that can support or contradict each commitment within the evaluated version’s scope.
References
- PMI-PBA Examination Content Outline · Public five-domain ECO: body copyright2013; back cover copyright2017 / PRA-206-2017_PBA (07/17). No new exam effective date inferred.
- HTTP Semantics · RFC 9110, June 2022; fixed publication. Partial errata triage on 2026-10-09; complete live errata register unavailable.
- OpenAPI Specification v3.2.1 · Latest published page and exact v3.2.1 page observed2026-10-09
- Making retries safe with idempotent APIs · Public article inspected 2026-10-09; contextual design discussion, not a PMI exam requirement