An enforcement job trusted to run itself, daily, in production
Shutdown authority handed to a scheduled job on AWS's European Sovereign Cloud partition, with every safety property structural rather than procedural.
Business Analyst, AWS Payments & Fraud Prevention
Eight ordered safety gates, a hard kill switch, and a shadow twin measuring precision continuously now stand between a candidate account and closure. Zero policy thresholds are hardcoded.
- Population scoping Defines the candidate pool a run may consider at all.
- Unlabelled filter Restricts the pool to unlabelled accounts.
- Confirmed-fraud linkage Weighted, and only over non-placeholder hard identifiers.
- Not already enforced Drops accounts an earlier action already covered.
- Account-age floor A minimum account age is required to proceed.
- Carve-outs → review Legitimate-customer patterns route to human review, never to closure.
- Enforce-time re-check State is re-verified at the moment of action, not just at selection.
- Ranked per-run cap Ranked and capped, so one run has a bounded blast radius.
Candidate accounts enter at gate one. Per-gate survivor counts are not published.
Show the data table
| Stage | # | What it checks |
|---|---|---|
| Population scoping | 1 | Defines the candidate pool a run may consider at all. |
| Unlabelled filter | 2 | Restricts the pool to unlabelled accounts. |
| Confirmed-fraud linkage | 3 | Weighted, and only over non-placeholder hard identifiers. |
| Not already enforced | 4 | Drops accounts an earlier action already covered. |
| Account-age floor | 5 | A minimum account age is required to proceed. |
| Carve-outs → review | 6 | Legitimate-customer patterns route to human review, never to closure. |
| Enforce-time re-check | 7 | State is re-verified at the moment of action, not just at selection. |
| Ranked per-run cap | 8 | Ranked and capped, so one run has a bounded blast radius. |
Automated enforcement is where a false positive stops being a metric and becomes a customer outage. A scheduled job acts unattended, on a brand-new sovereign partition, so each safety property has to hold with nobody watching the run.
- I built, deployed, and own the fraud-relations auto-shutdown job that runs daily in production on AWS's European Sovereign Cloud partition.
- Candidates pass eight ordered gates, and the sixth routes legitimate-customer patterns to human review rather than closure.
- A hard kill switch sits above all eight.
- A shadow twin runs the same selection into a parallel table, so precision is measured continuously rather than asserted at launch.
- Every policy threshold lives in deployed environment config instead of a code constant, so tuning enforcement needs no release.
- Reaching production meant clearing a five-gate sovereign deployment path: branch build, auto-deploy, manual cross-region promote, ADC pre-approval, host run.
- After six environment-level failures I wrote that path up as internal guidance with a failure-symptom-to-cause table.
The team gained a live automated enforcement capability whose safety case is inspectable rather than argued: every property is a gate a reviewer can read off the code, not a claim they have to take on trust. The write-up turned an undocumented sovereign-region deploy path into something a teammate can walk cold.
Enforcement stays manual and slow. Or worse, an automated job ships with its safety properties living in a runbook, and the first bad batch of shutdowns is discovered by the customers it hit.
Closing an account is a one-way door. That is what decides the shape of everything else here: a design whose safety argument has to be readable off the structure, because there is no reviewer standing at the moment of action to make the judgment call.
Ordering is the whole trick. “Is this a legitimate customer?” is a hard question to ask of an entire population and a tractable one to ask of a set that five prior gates have already narrowed. So the carve-out gate is placed where its answer is worth trusting, not where it was easiest to write. Two gates deliberately follow it, because selection and action are different moments and the world can change between them.
Launch is the easy half. Staying trustworthy afterwards is not. Precision asserted once is a claim with an expiry date nobody can see. Thresholds drift, populations shift, and an unmeasured job goes on reporting success either way. Running the selection continuously in shadow is what turns that claim into an observation. Externalized thresholds do the same work for change itself: because tuning is a config change, the config diff is the audit trail, and every adjustment to enforcement policy leaves a dated record without anyone maintaining one.
Production on a sovereign partition was its own problem. All six failures I hit were environmental rather than logical. Nothing about the job was wrong, only the ground it stood on. That is exactly why the guidance I wrote is a symptom-to-cause table.