OpenCyber Academy
Rapid course · Lesson 15 · English
Course code: OCA-016Lesson 15: OCA-016-A015

Queue reconciliation before return to service

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Week 3, day 5. Work through the teaching and the worked checkpoint before attempting the assigned exercise(s). Compare your artifact with the final worked result only afterward.

3.12 Reconcile a manual queue before resuming writes

Why a pause ending is not proof that bookings are safe to accept again

A bounded staff-write pause can be a reasonable containment choice while the incident lead investigates unexplained booking edits. It may also create a second operational risk: new requests arrive while ordinary application writes are blocked. If staff record those requests manually, they become pending obligations, not automatically accepted reservations.

The existing Module 3 already teaches how to propose a pause, validate the configured write paths through the separate W1 laboratory, and compare authoritative booking states through P1/C1. It also says queued requests must be reconciled before approved resumption. The missing intermediate skill is determining whether each request remains valid, has already been applied, conflicts with current state, or lacks the evidence required to apply it safely.

A pause does not make every queued instruction correct. During a pause, a staff member might copy the same request twice, a patron might retry after receiving no confirmation, an appointment time might become unavailable, or someone might submit a request that was never approved. When writes are reenabled, automatically replaying everything in arrival order could create duplicate reservations, overwrite legitimate later changes, or mislead a patron into believing an unaccepted request was confirmed.

The required outcome is not "empty the queue." It is account for every queued request with a supported disposition: applied exactly within its authorized scope, recognized as a duplicate, held for approval, rejected as conflicting, or left pending with a named decision owner. These are process dispositions, not claims that a production booking was changed.

NIST SP 800-61 Revision 3 addresses incident response as part of cybersecurity risk management, including considering operational consequences. NIST SP 800-184 discusses recovery planning and tests. The queue contract below is an original Harbor Library teaching method, not a prescribed NIST process or evidence of any real library service.

Five states of a pending booking request

Before discussing a replay or service resumption, distinguish five questions about every proposed manual request.

Received: Was a request recorded, under which unique receipt ID, at what claimed time, by which authorized intake role and from which permitted channel? A row with a booking label but no trustworthy receipt might be a note or duplicate, not an actionable instruction.

Authorized: Does the request have the approval appropriate to the specific action? A permission to collect a manual queue is not necessarily permission to edit a booking. The service owner should define the action authority and any patron confirmation required by the actual process.

Current: Does the request still make sense relative to the now authoritative schedule? An old expected room/version may no longer exist. A prior room assignment is not a guarantee it remains available.

Unique in effect: Is this a second receipt of the same intended operation, a different operation with a reused deduplication key, or a separate legitimate request? Counting receipts is not the same as counting changes.

Recorded after decision: Is there a durable, auditable outcome for the attempted application or hold? A queue item should not disappear simply because an operator tried to apply it. A retry after an uncertain acknowledgement requires checking whether the original effect occurred.

A beginner-friendly queue ledger records both the original request and its evolving review state. A useful minimum schema is:

Lesson table; scroll horizontally to read all columns →

Field Role in the review
Receipt ID Identifies a particular intake event and permits reconstruction of retries
Idempotency or operation key Identifies the logical operation under documented service rules; not itself evidence of authorization
Requested booking and desired state Names exactly what the request asks to change
Expected version or business precondition Defines the state the requester assumed
Intake source and original time Supports chronology and custody of the manual entry
Approval and decision owner Determines whether the requested change may be applied
Latest authoritative state/version Used to detect stale assumptions or conflicts
Disposition Applied, duplicate, held, conflict, rejected, or unresolved
Operator, verification and audit pointer Needed to defend a completed action
Patron communication state Separates received, accepted, rejected and notified

For Harbor Library, these are proposed educational fields. The canonical Branch P card does not provide any actual queue manifest. Its statement "two pending requests" cannot support claims about which rooms were requested, who submitted them or whether either can safely be applied.

Duplicate receipts are not necessarily duplicate business actions

Imagine a patron asks to move a booking. The front desk writes down the request, receives a repeated call, and writes a second note. Two receipts may describe one logical requested change.

An idempotency key is an application-defined way to recognize a repeated logical operation. The crucial condition is that the service must define which exact fields constitute the same request and what outcome follows when the key is reused. A repeat with the same key and same normalized operation may be classified as a retry; a repeat with the same key but different requested operation is a conflict demanding review, not permission to overwrite the first instruction.

This teaching technique is related to, but not guaranteed by, HTTP method semantics. RFC 9110 §9.2.2 defines idempotent methods in terms of the intended effect of repeated identical requests and cautions about automatically retrying non-idempotent methods. It does not grant a booking application's POST endpoint built-in exactly-once behavior or define Harbor Library's custom operation keys. The example below explicitly supplies its own key rules.

A key alone cannot prevent duplicates if it is stored only in temporary client memory or checked separately from the write. In a real, authorized implementation, the key-to-result record, version precondition and business-state update would need suitable consistency and atomicity guarantees. Otherwise an application failure could commit a booking while losing the recorded acknowledgement, and the next retry might apply the same business effect again.

The rapid course need not implement a distributed transaction manager. It must recognize why "the staff did not receive a confirmation" is not the same as "the write did not occur." The correct next step under that uncertainty is to verify the prior effect using an authorized source, not replay blindly.

State versions prevent silent lost updates

A manual request should identify what state it assumed. Suppose an instruction means "change booking X10 from its version 2 state to Room D." If another approved operation already advanced X10 to version 3, applying the old instruction without review could overwrite that newer decision.

A simple state-version precondition expresses the rule:

Apply the requested change only if the current authoritative version still equals the version the request expected.

If the versions differ, classify the request as stale and seek reconciliation. Stale does not automatically mean malicious, rejected forever or already fulfilled. It means the original operation cannot be assumed safe against the state now observed.

In a real concurrent database, comparing a version and updating a value in two unprotected steps would still permit a race: another operation might change the state between the check and the write. The service would need an appropriate conditional transaction or equivalent mechanism under its database consistency model. Our offline Python example runs sequentially, so it cannot prove such concurrency safety.

This also explains why an older backup is not automatically a valid replay baseline. A recovered booking state must be reconciled with accepted work and current authority before pending manual instructions can be applied. The original P1/C1 and K1 laboratories examine different parts of that recovery question; MQ3 does not supply their evidence or alter their results.

A safe queue review is a decision sequence, not a bulk command

For each request, a fictional service owner or delegated authorized reviewer should apply the following sequence:

  1. Freeze intake and scope. Preserve the original queue entries, including duplicate receipts, without editing away rejected rows. Identify the approval boundary and the relevant pause or test window.
  2. Determine the logical operation. Normalize only the documented fields used to distinguish identity of effect. Do not decide that two bookings match because their room names are similar.
  3. Check authority. Hold entries with missing or rejected approval. Neither a patron report nor a help-desk ticket is automatically permission to update authoritative state.
  4. Check prior effect. Look for a documented completed operation with the same key and exact request signature. A matching receipt may be a retry; a reused key with different content needs investigation.
  5. Check object and version. Compare the specific booking object and expected version with the authoritative state in an approved copy or environment. Missing or changed objects are explicit hold conditions.
  6. Apply only under controlled conditions. In a real system this would require an atomic operation and evidence of its outcome; the classroom performs no service modification.
  7. Verify and notify separately. Confirm the effect against authoritative state, preserve the audit link, and communicate an accepted or rejected result only after the outcome is verified and approved.
  8. Reconcile the remainder. An unresolved entry does not vanish when the queue closes. Assign an owner, next review and a supported notification state.

This is a processing model, not an instruction to execute a queue against a real library. If no suitable authoritative state or approval is available, the defensible disposition is hold. A student should never guess a current value in order to make the simulation pass.

Worked contrast: a confident but unsafe restart

Incorrect reasoning:

"R21 permits a fifteen-minute pause. Branch P later reports two manual requests. At the end of the fifteen minutes the pause must have finished, so replay both requests and tell the patrons their reservations were confirmed."

The sentence contains several unsupported conversions. R21 records tolerance, not actual execution. Branch P is released only later and reports two pending requests, not two approved or successfully processed bookings. The planned end of a pause does not prove that writes resumed or that the application, booking state, audit and manual queue passed their release tests. No canonical card supplies the two request IDs, contents or conflict status.

Defensible conditional reasoning:

"Only after the separate Branch P release may we report that the fictional service owner described a fifteen-minute pause beginning at 09:45 with two pending manual requests. Before any proposed resumption, the service owner must obtain a bounded queue manifest, determine whether each request is still authorized and consistent with current booking state, reconcile duplicate or conflicting instructions, and record both the effect and pending exceptions. The planned 10:00 end is not proof of automatic resumption. Pending items and unresolved audit or data gates remain on the handoff."

This version identifies precisely which missing evidence a later decision would need. It does not borrow the W1 test's single queued item or the P1/C1 booking comparison as if they described Branch P's two actual pending requests.

Separate the reconciliation result from return-to-service acceptance

A manual queue with every item assigned a disposition is better controlled than an unexplained queue. Still, its completion does not alone justify unrestricted booking writes.

The service owner must consider at least four separate gates: (a) the control is in the intended state after the approved change; (b) the authoritative booking values are correct under an owner-approved target; (c) relevant authorized and unauthorized tests behave as expected; and (d) changes produce adequate audit identity and time fields. The Module 3 V1 fixture separately shows why two narrow access successes do not repair an audit record with a blank actor field.

Likewise, clearing a queue by rejecting all items is not evidence of useful service. A legitimate booking function must work when permitted. A successful replay also cannot repair an unresolved account-cause hypothesis or prove that other staff-write routes are closed.

A good handoff for a manual queue reports counts with their units, such as receipts reviewed, distinct operations recognized, simulated applications, duplicate receipts, unresolved approvals and conflicts. It never reports "all patrons served" without a source supporting that much broader claim. When one logical operation has two receipts, count both receipts in the custody ledger but count its accepted business effect only once.

Failure modes and defensive review

Lesson table; scroll horizontally to read all columns →

Failure mode Attractive but wrong conclusion Required countercheck
Two receipts share the same operation key Two bookings were applied Compare the complete request signatures and prior-result record
One key is reused for different contents The later instruction replaces the earlier one Hold key conflict; obtain source and authorization clarification
Expected version is older than current state Apply anyway because the request was earlier Reconcile against accepted newer state; do not overwrite silently
A booking ID is missing from the authoritative view Treat it as newly created or deleted Confirm source coverage and ownership before deciding
The operator reports success The booking is durably correct Obtain authoritative post-change and audit evidence
A retry has no acknowledgement The original operation definitely failed Check for a recorded prior effect before retrying
The queue ledger has zero open items Service is fully recovered Independently assess state, access, audit and owner acceptance
The pause's planned duration elapsed Writes automatically resumed Require an explicit state/approval and safe-resumption receipt

The most important technical habit is to leave ambiguous items visible and owned. A queue is not successfully reconciled when errors have been erased; it is reconciled when each original entry has a traceable, defensible result, including exceptions.

3.13 MQ3 offline laboratory — Replaying a hypothetical queue without a live write

Objective: Distinguish duplicate receipts, conflicting key reuse, missing approval, stale state and changed processing order. This is a wholly independent synthetic laboratory. Identifiers MQ-01–MQ-08, X10–X12 and KEY-* are not canonical Harbor Library records or the two unnamed Branch P requests.

Environment: Python 3 standard library; entirely in memory. No files, network, accounts, real booking operations or external connections. The code changes only a deep-copied dictionary and does not approve any real action.

Inputs and assumptions: Each tuple contains receipt ID, operation key, booking ID, expected state version, desired room and a fictional approved flag. The baseline state is an invented exercise dictionary. Operations are processed in the printed order and one version increment represents a simulated successful change. An operation key is remembered only after a simulated apply; an unresolved hold requires independent review. These rules are intentionally narrow and do not implement durable idempotency, concurrent locking, reliable messaging or an audit service.

Before running, predict: Which receipt repeats an already simulated operation, which reuses the same key for different contents, which lacks approval, which refers to an unknown booking and which becomes stale because of an earlier simulated application?

from copy import deepcopy

BASE = {
    "X10": {"room": "Room A", "version": 2},
    "X11": {"room": "Room B", "version": 5},
    "X12": {"room": "Room C", "version": 1},
}

REQUESTS = [
    ("MQ-01", "KEY-A", "X10", 2, "Room D", True),
    ("MQ-02", "KEY-A", "X10", 2, "Room D", True),
    ("MQ-03", "KEY-B", "X11", 4, "Room E", True),
    ("MQ-04", "KEY-C", "X12", 1, "Room F", False),
    ("MQ-05", "KEY-D", "X99", 0, "Room A", True),
    ("MQ-06", "KEY-A", "X10", 2, "Room Z", True),
    ("MQ-07", "KEY-E", "X11", 5, "Room E", True),
    ("MQ-08", "KEY-F", "X10", 2, "Room B", True),
]

The next block checks approval, prior effect, object existence and expected version in that order. Run all three blocks in one Python session.

def simulate(requests):
    state = deepcopy(BASE)
    applied = {}
    results = []

    for receipt, key, booking, expected, desired, approved in requests:
        signature = (booking, expected, desired)

        if not approved:
            status = "HOLD_UNAPPROVED"
        elif key in applied:
            status = (
                "DUPLICATE_RETRY"
                if applied[key] == signature
                else "CONFLICT_KEY_REUSE"
            )
        elif booking not in state:
            status = "HOLD_UNKNOWN_BOOKING"
        elif state[booking]["version"] != expected:
            status = "HOLD_STALE_VERSION"
        else:
            state[booking]["room"] = desired
            state[booking]["version"] += 1
            applied[key] = signature
            status = "SIMULATED_APPLY"

        results.append((receipt, status))

    return results, state

The final block prints each disposition and then runs two independent order variants from the same starting state.

results, state = simulate(REQUESTS)
for receipt, status in results:
    print(f"{receipt}: {status}")

print(
    "STATE:",
    ",".join(
        f"{key}={value['room']}@v{value['version']}"
        for key, value in sorted(state.items())
    ),
)

# Negative/sensitivity control:
# Change only the order of two competing X10 requests.
for label, sequence in [
    ("ORDER_A_THEN_F", [REQUESTS[0], REQUESTS[7]]),
    ("ORDER_F_THEN_A", [REQUESTS[7], REQUESTS[0]]),
]:
    outcome, changed = simulate(sequence)
    print(
        label + ":",
        ",".join(f"{receipt}={status}" for receipt, status in outcome),
        f"X10={changed['X10']['room']}@v{changed['X10']['version']}",
    )

Compare your predictions with the MQ3 worked transcript and review in the final answer appendix.

MQ3 intake preflight: receipt identity before simulated effect

The original simulate() remembers an operation key only after SIMULATED_APPLY; it does not check whether a receipt ID was used before. In adversarial runs, two different operations both labeled MQ-01 can both return SIMULATED_APPLY. If a stale X11 request first uses KEY-Z, a different X12 request can later reuse KEY-Z and apply, because the first request was never stored in applied. These results are limits of the teaching simulator, not evidence of real queue behavior.

Review intake identity separately from any later approval, version or effect decision. The following standalone preflight retains the first signature for each receipt and each operation key; a duplicate receipt cannot seed a new key. Every original row remains in the returned output, including holds. A same-key, same-signature row is only a possible retry with unknown prior effect until a trusted outcome record is checked. Two different keys competing for the same booking may still both look new and require an owner-defined ordering rule.

REQUESTS = [
    ("MQ-01", "KEY-A", "X10", 2, "Room D", True),
    ("MQ-02", "KEY-A", "X10", 2, "Room D", True),
    ("MQ-03", "KEY-B", "X11", 4, "Room E", True),
    ("MQ-04", "KEY-C", "X12", 1, "Room F", False),
    ("MQ-05", "KEY-D", "X99", 0, "Room A", True),
    ("MQ-06", "KEY-A", "X10", 2, "Room Z", True),
    ("MQ-07", "KEY-E", "X11", 5, "Room E", True),
    ("MQ-08", "KEY-F", "X10", 2, "Room B", True),
]

def intake_preflight(requests):
    receipts, intents = {}, {}
    output = []
    for receipt, key, booking, expected, desired, approved in requests:
        signature = (booking, expected, desired)
        if receipt in receipts:
            status = "HOLD_DUPLICATE_RECEIPT_ID"
        elif key in intents and intents[key] != signature:
            status = "HOLD_CONFLICTING_OPERATION_KEY"
        elif key in intents:
            status = "POSSIBLE_RETRY_EFFECT_UNKNOWN"
        else:
            status = "NEW_INTENT_EFFECT_UNKNOWN"
        if receipt not in receipts:
            receipts[receipt] = (key, signature)
            intents.setdefault(key, signature)
        output.append((receipt, status))
    return output

for receipt, status in intake_preflight(REQUESTS):
    print(f"{receipt}: {status}")

VARIANTS = [
    ("DUPLICATE_RECEIPT_ID", [
        REQUESTS[0],
        ("MQ-01", "KEY-Z", "X11", 5, "Room F", True),
    ]),
    ("STALE_THEN_DIFFERENT_SAME_KEY", [
        ("T1", "KEY-Z", "X11", 4, "Room E", True),
        ("T2", "KEY-Z", "X12", 1, "Room F", True),
    ]),
    ("TWO_COMPETING_REQUESTS", [REQUESTS[0], REQUESTS[7]]),
]
for label, rows in VARIANTS:
    print(label + ":")
    for receipt, status in intake_preflight(rows):
        print(f"  {receipt}: {status}")

Predict the eight baseline receipts and three two-row variants in the supplemental worked transcript. Explain why MQ-02 is not yet a verified duplicate effect, why a held/stale first attempt still reserves its key's intent for conflict review, and why two competing new intents cannot be safely ordered by whichever file is read first. This in-memory check cannot authenticate approvals, guarantee atomic writes, resolve Branch P's two unnamed requests or certify durable exactly-once processing. In a real system, conditional state updates and key-to-result records would require a controlled, durable consistency design.

3.13a Safe return to service is a conjunction, not a single green result

Learning objective: Explain why a successful configuration change, a quiet audit query, correct booking values, accessible user functions and reliable attribution are different acceptance dimensions. A beginner does not need to implement transaction isolation or perform a live restore, but should be able to state what evidence would prevent premature reopening.

A session-revocation control may have the intended narrow protective effect without making booking state correct. A staff-write pause may block one known route while a scheduled job or alternate API still changes the same booking. An isolated backup comparison may match the owner-approved P1 target on B17/B18 but fail B19/B20. An authorized test may succeed while the audit record has no actor. These are not interchangeable observations, and an owner's acceptance should state its tested service scope and remaining compensating controls.

Define protection acceptance as evidence that the harmful or prohibited operation is constrained within the specified tested routes and interval. Define business acceptance as evidence that a permitted booking function remains usable under declared workflow conditions. Define data correctness against an independently approved target, not against an old backup merely because that copy has a matching digest. Define audit adequacy as the attribution and time fields required for the particular authorized test. A queue-reconciliation gate, where a pause generated manual requests, requires the service owner to know what is pending, approved, duplicated, conflicting or held. Finally, owner acceptance is a separate human decision about limited or unrestricted mode; it does not follow automatically from a test script.

Contrastive worked case A (Branch S after proper release): At 09:45 the identity administrator reports that the current desk-a session was revoked, with a narrow no-later-edit result in its queried range. That supports a bounded session-action report and a limited query observation, not a claim that every write path or all bookings are safe. Later P1/C1 reveals B19/B20 mismatches; later V1 tests one permitted and one denied operation but has a blank actor. Even after these releases, unrestricted service acceptance fails the stated data and audit checks. A responsible lead can propose monitored restricted operation only after a separate service-owner decision and a documented next review.

Contrastive worked case B (Branch P, not Branch S): The later branch card reports two unnamed pending manual requests, a fifteen-minute pause starting at 09:45, and no writes within a bounded audit interval. Those requests are not bookings already applied. Their receipt IDs, expected versions, authorizations and latest authoritative states are unavailable; therefore a student cannot decide which to replay. A queue owner must obtain a restricted manifest, detect a reused operation key or stale state, assign a supported disposition to each request, and retain unresolvable ones for owner review. The separate MQ3 fixture demonstrates these hazards with invented X-bookings, not the two Branch P requests. Reaching a nominal 10:00 expiry does not prove writes automatically resumed or that a queue item was accepted.

A deliberately important comparison: a verified duplicate receipt need not create a second business effect, whereas a different operation using the same key demands a conflict hold. Even if all pending items have dispositions, the service still needs independent booking, access and audit gates. The NIST SP 800-184 recovery guide emphasizes planning, testing and improvement, not a one-signal recovery declaration. The following classroom condition checker is a teaching model rather than NIST-mandated acceptance logic.

R3X offline lab — mandatory gates and a queue that remains pending

This standard-library Python 3 fixture is wholly invented. Each row is an independent reset; True, False and None mean declared pass, declared failure and untested, not authenticated receipts. No file, service, network or real booking is touched.

def accept(protection, service, data, audit, queue, owner):
    if protection is False: return "PROTECTION_FAIL"
    if service is False: return "SERVICE_FAIL"
    if data is False: return "DATA_FAIL"
    if audit is False: return "AUDIT_FAIL"
    if queue is False: return "QUEUE_UNRECONCILED"
    if None in (protection, service, data, audit, queue):
        return "MANDATORY_GATE_NOT_TESTED"
    if owner is not True: return "OWNER_ACCEPTANCE_PENDING"
    return "SYNTHETIC_SCOPED_GATES_PASS_ONLY"

rows = [
    ("NO_TEST", (None, None, None, None, None, None)),
    ("B19_WRONG", (True, True, False, True, True, True)),
    ("MISSING_ACTOR", (True, True, True, False, True, True)),
    ("QUEUE_PENDING", (True, True, True, True, False, True)),
    ("NO_OWNER", (True, True, True, True, True, None)),
    ("TOY_SCOPED_PASS", (True, True, True, True, True, True)),
]
for name, flags in rows:
    print(name, accept(*flags))

Exact tested output:

NO_TEST MANDATORY_GATE_NOT_TESTED
B19_WRONG DATA_FAIL
MISSING_ACTOR AUDIT_FAIL
QUEUE_PENDING QUEUE_UNRECONCILED
NO_OWNER OWNER_ACCEPTANCE_PENDING
TOY_SCOPED_PASS SYNTHETIC_SCOPED_GATES_PASS_ONLY

Adversarial interpretation: Even when the other Boolean inputs are declared pass, B19_WRONG and MISSING_ACTOR are mandatory failures. QUEUE_PENDING refuses an automatic restart merely because the technical block is over. TOY_SCOPED_PASS only shows that the declared toy fields are internally favorable; there is no approved copy, validated source clock, verified actor, independent production route test or actual owner decision. An unobserved path cannot be converted to a pass.

Reproducible task: Write a five-column plan listing the required owner, source, expected observation, failure action and status of each gate. Then reproduce all six lines, identify a failed data gate and a failed audit gate after the later P1/C1 and V1 releases, and state what the queue owner would need before reading either pending Branch P request. A full result refuses to borrow W1, MQ3 or RTE3 synthetic outcomes as Harbor Library operations and keeps incident root cause and identity questions open.

Synthesis: A temporary successful control, an accepted limited operating mode, and an eradicated cause are different decisions. Module 4 tests whether the learner can maintain these boundaries while cards are gradually released and the receiving shift lacks the author's explanations.

Worked checkpoint

If a manual request has no unambiguous disposition, reopening writes can duplicate or lose a reservation. Preserve the receipt, owner and reconciliation state; keep the service restricted until the unresolved queue and the other mandatory gates are reviewed.

Practice — Lesson 15

EX037 — Residual risk

Objective: distinguish page availability from safe, correct service. Inputs: R20, R22–R24 and a hypothetical observation that the page loads after an approved revocation; this is not the Module 4 branch result. Output: a claim/limit note with two unresolved questions, a test and owner for each, and a proposed case status. A score of 2 asks about booking correctness and adequate post-action audit coverage, and does not use R24 to claim that no personal-data access occurred.

Worked answer: EX037 in the final appendix.

EX038 — Alternative defensible choice

Objective: defend a different containment path without inventing a unique right answer. Inputs: R18–R21 and the section 3.3 matrix. Output: a pause-first proposal with two assumptions, approving role, manual-queue plan, one immediate effectiveness check, a 15-minute review time and a condition for changing to narrower session action or a longer restriction. A score of 2 states that R21 records tolerance rather than execution, and includes reconciliation and service-owner sign-off before resuming writes.

Additional queue template for EX038: At 09:37, include an empty proposed ledger with receipt ID, booking/action, claimed time, approval, expected version, prior-effect check, disposition and owner. Name at least two hold conditions and a controlled owner review before writes resume. The Branch P outcome is unavailable at this checkpoint.

RB3 extension: Additional requirement: Retain the original pause-first proposal, its two assumptions, service-owner approval requirement, queue plan, immediate effectiveness check, 15-minute review and conditional alternative. Keep the queue-ledger template empty at 09:37. Add a reversal-readiness clause: if the pause blocks essential authorized work or fails its protective purpose in a future separately verified test, what exact owner decision and bounded post-reversal checks would be required before changing that control? Do not use Branch P's later two pending requests or MQ3's synthetic rows as an observed 09:37 queue.

RB3 2-point refinement: R21 remains a tolerability statement; the proposed pause and any later reversal have independent authorization and verification. The ledger format stays empty and unchanged, and resumption remains conditional on booking/queue review and owner sign-off.

Worked answer: EX038 in the final appendix.

Worked answers

EX037 — Worked result

Claim: the booking page loads after a hypothetical approved session revocation. Limit: a page response tests availability at one moment; it says nothing by itself about schedule correctness, authorization of edits or the completeness of later audit coverage. Question 1, booking state: are B17–B20 consistent with a service-owner-approved target? The service owner authorizes a restricted comparison and owns any correction; R20 says a copy is available but does not supply the row values at 09:37. Question 2, continued change: did an approved, sufficiently ingested audit query after the intervention show any new unexplained edit? The application custodian records source, interval, filters and cutoff; R22 is earlier and cannot answer. Proposed status: keep the case open with a named review and possible restricted service. R24 says no current record establishes access to another personal-data store, but it cannot close an exposure question by proving absence.

EX038 — Worked result

Pause-first proposal at 09:37 UTC: assume the observed B19/B20 edits may not be limited to the one current session, and assume front-desk staff can safely record new requests in the manual queue for fifteen minutes. R21 supports the owner's tolerance for that cost, not a completed pause. Ask the service owner to approve a named fifteen-minute write restriction; only then could the application operator implement it and record the actual target and time. If applied, verify in the approved test scope that staff booking writes are blocked while the manual queue captures requests, then inspect a new bounded audit interval. Schedule a planning and decision-status review at 09:52 UTC, or sooner if verified new harm or a control failure requires attention. This appointment does not certify fifteen minutes of effective protection. Calculate any nominal fifteen-minute end from a trustworthy, source-linked actual activation time, not from the 09:37 proposal; record approval, covered write routes, independent block verification, manual-queue continuity, expiry behavior and the next owner decision separately. Neither a calculated end nor a scheduled review proves that writes resumed or queued requests were applied. Before any resumption, check current booking state, queue dispositions, access and audit, and obtain explicit service-owner sign-off. If the block does not work, patron harm becomes unacceptable, or authorized identity evidence identifies a narrower safe action, the incident lead and service owner should reconsider revocation or a different control. The pause reduces one class of harm while leaving cause and other paths unresolved.

Offline timing contrast for EX038: Predict the planning review and the conditional end for each artificial input, then run this standard-library example. applied_at is only a supplied hypothetical time, not an authenticated operator or protective-effect receipt.

from datetime import datetime, timedelta

def time(clock):
    return datetime.strptime(clock, "%H:%M")

def timing(proposal_at, applied_at, minutes=15):
    review = (time(proposal_at) + timedelta(minutes=minutes)).strftime("%H:%M")
    if applied_at is None:
        return f"planning_review={review} effective_end=UNKNOWN_NO_EXECUTION_RECEIPT"
    if time(applied_at) < time(proposal_at):
        return f"planning_review={review} effective_end=INVALID_PRE_PROPOSAL_TIME"
    end = (time(applied_at) + timedelta(minutes=minutes)).strftime("%H:%M")
    return f"planning_review={review} conditional_effective_end={end}"

for label, start in [
    ("ONLY_PROPOSED", None),
    ("IMMEDIATE_IF_RECEIPTED", "09:37"),
    ("DELAYED_IF_RECEIPTED", "09:42"),
]:
    print(label, timing("09:37", start))

ONLY_PROPOSED planning_review=09:52 effective_end=UNKNOWN_NO_EXECUTION_RECEIPT
IMMEDIATE_IF_RECEIPTED planning_review=09:52 conditional_effective_end=09:52
DELAYED_IF_RECEIPTED planning_review=09:52 conditional_effective_end=09:57

The last two lines are counterfactual classroom variants, not R-series or Branch P events. A pause may activate late, cover fewer routes than intended, extend beyond a technical expiry or end without safe service resumption. The 09:52 review remains useful even if the control never starts: it asks whether the plan is still appropriate, not whether protection completed.

MQ3-linked 09:37 proposal: R21 supports tolerance only. The pause-first plan includes an empty queue-ledger schema: receipt ID | booking/action | claimed time | approval state | expected version | prior effect | disposition | owner. Actual entries are not supplied. Hold any entry with missing approval, conflicting key reuse, unknown current state or stale version; do not replay in arrival order by default. The service owner must approve the pause, later queue dispositions and a controlled review before resuming writes. The later Branch P card cannot be used as an observation at 09:37.

RB3 additional worked reasoning: A pause-first proposal is defensible if the team explains that the account-to-edit path is uncertain and the service owner could tolerate a short interval of manual intake under appropriate approval. R21 does not authorize or execute that pause. The plan names a service-owner decision, application operator, protective test, legitimate service/queue cost, next review and a possible alternative if the control fails.

At 09:37 the proposed queue ledger stays empty, with its schema unchanged: receipt ID | booking/action | claimed time | approval | expected version | prior effect | disposition | owner. If a future independent source establishes that the pause prevents essential permitted work or fails to block its intended path, the incident lead and service owner should evaluate a new bounded reversal or replacement under separate scope, approval and verification. A rollback is not automatically safe merely because it ends the pause: a post-reversal check must test remaining protection and legitimate booking behavior, while queue reconciliation and data correctness stay with the service owner. The later Branch P and MQ3 records are unavailable to the canonical 09:37 decision.