SUBJECT REQUESTS · IDENTITY BOUNDARY
Subject requests: preserve the identity boundary
Process an access or erasure request for Ana Ruiz across four stores, and see what the verification method and search key release, and to whom.
Event trace
Computed data
Final metrics
Seven fictional records in four stores; two customers share the name Ana Ruiz. Results are delivered in the request portal session. Without verification an impostor can type the real address; with an email link they can only verify a mailbox they control. Legal deadlines, exemptions, backups and the content of an export are outside this drill, and it is not legal advice.
The wrong Ana Ruiz
By default Ana Ruiz sends an access request, confirms an email link and the system searches by name. Four records are exported: her R1 and R3, plus R2 and R4, which belong to customer C-233, a different Ana Ruiz. Her old-address ticket R5, filed as A. Ruiz, her agent memory R6 and her analytics events R7 are missed: OVER-DISCLOSURE, 2/5 subject records, 2 other person. With Request type Erasure the same search deletes the other customer's records: WRONG PERSON ERASED.
Choose the search key
Search key Email address finds only R1 and R3: INCOMPLETE, 2/5. Customer ID with linked identifiers resolves the old address, the memory key and the analytics pseudonym P-55 through C-104 and finds all five: FULFILLED, 5/5. A name is not an identifier, and an address is only one of several identifiers a person leaves behind.
Verification proves less than it seems
Switch Who sends the request to An impostor using her name. With the email link, the impostor confirms a lookalike mailbox they control, and the name search hands them 4 records: IMPOSTOR SERVED. By email or customer ID the lookalike address matches nothing: NOTHING RELEASED, safe only by accident. With Verification None the impostor types her real address, and the customer ID search releases all 5 of her records. Sign in to the account rejects the impostor before any store is searched: REJECTED.
Reading the trace
Each store gets its own event: CRM, Tickets, Agent memory and Analytics, listing every match with its owner and every missed record with the reason it was missed. The table shows the name and address on every record and its outcome: exported or erased, wrong person, to impostor, missed or not matched.
Replay and limits
Any change recomputes the run and rewinds it; the Complete-run preview states the outcome at once. Play and Pause walk through the events, Next event jumps one event, Restart rewinds, Speed runs from 0.25x to 2x and Inspection time seeks from 0 to 60 seconds, where the outcome and final metrics appear. Seven fictional records in four stores; results are delivered in the request portal session. Legal deadlines, exemptions, backups and the contents of an export are outside this drill, which is not legal advice.