Section 10: Seven Ways to Miss Day 30 - Interviewer Deep-Dive Challenges

Executive Summary: The orchestrator is drawn and Section 9 showed how completeness gets proven. Now the interviewer attacks the edges: a service that never answers, a lawyer who says "stop", an identifier that changes owners, data two people share, a log that remembers too much, a regulator who wants proof, and a flood that may be an attack. Each challenge gets three beats: the interviewer's line, an answer that starts from a ledger number or decision, and the senior line. Most answers leave the architecture alone and add a rule about who decides.

The interviewer taps the whiteboard. "Lena's request went smoothly. Let's make it go badly." Find the deciding number, name the mechanism, say what would change your mind.

Challenge 1: The Service That Never Answers

"A service holding Lena's data has been down for three weeks. Or it was deprecated last quarter. Now what?"

Start with the budget. Fan-out on day 14 plus a 10-day service SLA leaves a 6-day buffer before day 30. The escalation ladder fires at task day 5 (owning team), day 8 (on-call page) and day 10 (director), so by day 24 a human owns the problem with six days left. A three-week outage outlives the 14-day dispatch-log retention too, which is harmless: the DISPATCHED task row stays in the ledger, the deadline scanner keeps seeing it, and the event is re-published when the consumer returns.

What we must not do is mark the task NO_DATA to close the request: the data still sits in its stores. By design the orchestrator holds no credentials to delete it, but if those stores live on platform-owned infrastructure, a platform connector can wipe Lena's rows directly as a last resort, with the owner's sign-off recorded in the audit log. For a deprecated service, decommissioning isn't finished until its data is deleted.

If neither path lands in time, Art. 12(3) allows an extension of up to two further months for complex or numerous requests, provided Lena is told within one month of receipt, with the reasons. The request moves to EXTENDED with an extended_deadline. Whether one dead service counts as "complex" is counsel's call, not ours.

The senior line: "A dead service is a deadline problem, not a delivery problem: the ledger never forgets the task, and the 6-day buffer is where we choose between a connector wipe and a documented extension."

Quick check before moving on: