SUMMARY: A notice-chain test follows one decision from issuance to a usable response route. Run it as a tabletop exercise or in an authorized test environment with synthetic recipients. Do not send test warnings to real members or change live access merely to demonstrate a failure.
1. Draw the Whole Route
List the decision event, notification event, retrieval step, explanation, response action, and responsible owner. Record where authentication is required. Mark any place where the decision itself changes the credentials or permissions needed for a later step.
Define what each status means before testing. If “sent” means handed to another component, say that. If “viewed” means a retrieval event, do not label it understood. The distinction is central to Notice as Infrastructure.
2. Prepare Four Synthetic Cases
- Ordinary route: the recipient can retrieve the notice and submit a response.
- Restricted account: the decision removes ordinary access before the notice is read.
- Unavailable channel: the preferred destination cannot be used, requiring a documented fallback.
- Repeated alert: the same decision generates two notifications, which must not create contradictory instructions or separate cases.
For each case, write the expected outcome and the evidence that would support it. An unresolved policy question is a review item, not permission to invent a production rule during the exercise.
3. Inspect the Content Boundary
Check what appears in the initial alert, the protected notice, and the fallback. Use fictitious sensitive details to see whether information crosses a boundary it should not. Verify that a restricted recipient can obtain the intended explanation without regaining unrelated permissions.
Read the notice without relying on the operator’s knowledge of the system. Can the test participant identify what changed, the next available action, and the route for reporting an access problem? Record ambiguity separately from a broken link.
4. Follow the Clock and the Reply
Identify the declared start event for any response window. Simulate an inaccessible notice and inspect the escalation process. Confirm that a response reaches the original case, rather than an unowned inbox or a new request with no history.
For a repeated alert, confirm that the current instruction is identifiable and older versions remain distinguishable. A retry should not silently rewrite the original issuance time. The Participant Status Ledger can retain those separate events.
5. Record and Retest the Failure
Keep one evidence row per case: synthetic reference, notice version, tested account state, expected route, observed result, unresolved uncertainty, corrective owner, and retest result. Keep operational logs access-controlled and retain only the evidence needed for the review.
Acceptance rule: every tested case has either a demonstrated response route or an explicit, owned escalation; no delivery status claims more than its evidence supports. Use The Unread Decision as the first tabletop scenario.
Combine this notice test with the Digital Systems Accountability review when the same failure also interrupts a queue, challenge, or correction.