The brief
A fictional shop marks a customer’s deletion request Complete. Weeks later, the customer can’t sign up again: “This email is already registered.” Their data is still in secondary databases, support attachments, search indexes, exports, logs and backups, and a sync job has quietly recreated what the primary service deleted.
The task: for 518 deletion requests, decide COMPLETE, INCOMPLETE or NOT_APPLICABLE, and produce the ordered remediation and verification steps, without deleting records the policy says must be kept.
What I built
A Python pipeline where plain code makes every decision:
- Ingest: one parser per evidence format: logs, SQL snapshots, JSON, text, PDFs and screenshots.
- Identity: resolve each person’s current and historical emails, phones and email hashes from the audit log, because the ghost usually lives under an old identifier.
- Linking: tie records to requests through identifiers, data-catalog rows and the timing of deletion runs.
- State: reconstruct every record’s state at the audit timestamp, apply
deletion_rules.csv, and emit the steps.
Claude is used in exactly two places where code can’t read the input: transcribing 11 evidence screenshots into a fixed JSON schema, and reading each request’s text to decide whether it actually asks for deletion (with a keyword fallback in code, and a log of every case where the two disagree). Every answer is cached, so the full run makes zero live model calls and gives the same output every time.
The numbers
On the 32 public samples:
| Metric | Result |
|---|---|
| Case status accuracy | 32/32 |
| Step precision | 175/175, so every step it emits is right |
| Step recall | 175/193 (90.7%) |
| Whole row exact | 17/32 |
| Total model spend | $1.39 across 19 calls |
These scores are optimistic: I read the samples closely while designing the rules. Every miss is a verification step for a record the pipeline never linked, usually one with no identifier in any evidence file, reachable only through deletion-run timing.
One call I’d make again
Strict mode is the default: evidence captured after the audit timestamp isn’t used, because an auditor at that moment couldn’t have seen it. Allowing it would recover 5 more sample steps. I kept it strict anyway; an audit that peeks at the future isn’t an audit.
The night
The event ran in person at HackerRank’s office: kickoff at 6 PM on Saturday, the office open overnight, and submissions closing at 6 PM on Sunday. After submitting, there was a 30-minute AI judge interview to walk through the decisions and tradeoffs.