Answers and explanations · Test and operate the workflow

Module 7 Reference solution

The 12-event Pack A contains 11 unique request revisions and one duplicate delivery. Four unique revisions have a standard DRAFT_READY outcome: R101/1, R109/1, R104/2 and R110/1. Five have HUMAN_REVIEW outcomes: R102, R103, R105, R107 and R108. One is NEEDS_INFO (R104/1), one is INVALID_INPUT (R106/1), and one event is DUPLICATE_SKIPPED. Four + five + one + one = 11 unique revisions. Enumerating records makes the denominator and totals checkable.

Without injected technical failures and assuming the prescribed outcomes are correctly produced, all 11 unique revisions reach a valid intended disposition: 11/11. That is expected rule behaviour, not measured model reliability. Exception-review rate is 5/11, approximately 45.5 percent. All unique items still need human handling before a later action; the ordinary review load is not only the five exceptions. If E010 is left unreconciled on technical hold, safe-disposition rate is 10/11, about 90.9 percent, until its outcome is established.

For the lesson's separate 20-event illustration, use 18 unique request revisions as the denominator. Fifteen valid dispositions yield 83.3 percent; four exception cases yield 22.2 percent. Explain whether claim errors are counted per draft or per claim; neither denominator is provided automatically by the event count.

M7 Q1: the report hides unresolved work and inflates success. Include holds in the chosen eligible denominator or report them separately with the exclusion fully explained. For this course's safe-disposition metric they remain in the denominator. M7 Q2: a comparator can be wrong at equality or around a changed limit. These cases detect both an off-by-one decision and an outdated threshold. M7 Q3: the intended destination effect remains unverified. Inspect the output mapping, destination, record key and queue record before claiming success.

A sound runbook names an owner, reviewer and queue inspection schedule; keeps triggering paused during repairs; states quota/retention limits; distinguishes model repair from network retry; and includes a source-change regression set. A silent queue is not automatically a healthy queue.

Module 7 Capacity and runbook adaptation

For 60 requests, base is 60 × 4 = 240 units. Retry estimate is 60 × 8/30 = 16. Monitoring is six batches × 4 = 24. Subtotal 280; reserve 20 percent = 56; planning total 336; fictional cost USD 3.36. It fits both the 600-unit allocation and the 480-unit operating stop. These remain synthetic estimates, not measured charges.

For 100 requests with two monitoring checks per batch, base stays 400 and rounded-up retry estimate stays 27. Monitoring changes to ten batches × 8 = 80. Subtotal 507; reserve 101.4 rounds up to 102; total 609; fictional cost USD 6.09. It exceeds both limits. Reduce the tranche or choose a justified monitoring/work design; do not disable useful checks merely to hide their cost. Changing a stop limit would require the owner's decision, not an automatic upgrade.

The reviewer-only-at-16:00 scenario already has eight pending drafts against a limit of ten. Starting ten more would breach the limit. A defensible plan pauses new work until review resumes, or admits at most two bounded new items if their processing and monitoring are affordable and the operator can stop reliably. Current records remain pending; no one marks them approved to clear the queue. At 16:00 the reviewer handles the backlog, the operator confirms counts and reconciles holds, and the owner verifies capacity and readiness before restarting. A different schedule is acceptable if it respects the stated backlog, authority and capacity rules.

A good adapted runbook gives actual names/roles, times, threshold and pause steps, then explains the consequences. “Monitor the queue regularly” is not equivalent to a stated check time and a rule for reviewer absence.