Our AI Judge Went Down. Nobody Noticed.
The system didn't crash. It succeeded at writing to the wrong place — for weeks. Here's what I built after.
For three weeks, the system ran perfectly. Every job completed. Every log entry showed success. Every health check returned green. The agents processed their tasks, stored their results, updated their records. Nothing was on fire.
Three critical architectural memories were orphaned.
The configuration file that governed where agents stored persistent context had drifted. Not crashed — drifted. A routine update to the agent orchestration layer changed the storage path format. The write operations succeeded at the new path. The read operations still pointed to the old one. Every agent that depended on shared architectural context was making decisions based on stale data — decisions that were logged, validated, and marked successful.
I found it during a manual audit three weeks later. Three memories that should have been referenced dozens of times showed zero access since the configuration change. The agents hadn’t failed. They’d adapted — producing outputs that were internally consistent but disconnected from the context they were supposed to reflect. The system had been confidently wrong for twenty-one days.
The fix took fifteen minutes. Identifying the scope of the damage took a week.
That word — “scope” — is the one most teams skip. When something breaks in production, the instinct is to fix the immediate cause and move on. Configuration file pointed to the wrong path? Fix the path. Deployment done. But “fix the path” doesn’t answer the harder question: what happened downstream while the path was wrong? Which outputs were contaminated? Which decisions were made on stale context? How far did the damage propagate before anyone noticed?
The Blast Radius Question
This is the question I now call the blast radius question. Not “what broke?” but “who got hurt, how badly, and how would I know?”
A different project taught me the financial version of the same lesson. I was building CRM integration for a financial services site — a pre-qualification form that collected funding goals and credit score ranges from prospective borrowers. The form submitted successfully. The serverless function returned a 200 response. The CRM created the contact record. The user saw a confirmation message. Every layer reported success.
Two days later, someone pulled up the CRM and found that every lead’s financial data was blank. Funding goals, credit score ranges — silently dropped. The form field keys in the serverless function didn’t match the CRM’s actual custom field keys. funding_goal versus funding_amount_needed. credit_score versus estimated_credit_score_range. The CRM accepted the submission, created the contact, and quietly ignored the fields it didn’t recognize.
The blast radius wasn’t the technical bug. A key mismatch is a ten-minute fix. The blast radius was every prospect who submitted sensitive financial information, received a confirmation that it was received, and then got a follow-up call where the advisor knew nothing about their situation. The blast radius was measured in trust, not uptime.
The blast radius was measured in trust, not uptime.
The notification system I worked on for an enterprise platform had its own blast radius lesson — but this time the scope was measured in customers, not leads.
The system processed notifications for over 6,000 active customer accounts. A deployment introduced a code path that could create duplicate notification settings — if a customer’s record was processed twice in the same batch window, they’d receive duplicate emails on every subsequent scheduled run. Not once. Every Monday. Every week. Until someone noticed.
The risk assessment changed the architecture. We added an idempotency check that queried for existing records before creating new ones. But the idempotency check itself introduced a new question: what’s the blast radius of the check failing? If the query times out, does the system create a duplicate (wrong data) or skip the customer entirely (missing data)?
We chose missing data. A customer who misses one notification cycle can be back-filled. A customer who receives duplicate emails every week loses trust in the platform — and there’s no back-fill for trust. The architecture optimized for the less dangerous failure mode, not the one that was easier to implement.
That decision came from mapping the blast radius first. “What breaks?” has a technical answer. “Who gets hurt and how badly?” has a business answer. The architecture needs to optimize for the business answer.
A compliance audit on a multi-brand content platform showed me how blast radius propagates through content lineage — a failure mode I hadn’t anticipated.
The first audit found a compliance violation on the public website. Fixed it. Same violation appeared in a PDF that was generated from the website copy. Fixed that. Same violation appeared in an email template that referenced the same source paragraph. And then in a shared UI component that pulled from the same content block.
Propagation Through Content Lineage
Fourteen surfaces. One root cause. The source document — the master copy that every downstream asset inherited from — had never been corrected. Every fix I applied to a downstream surface was a patch. The violation regenerated every time a new asset was built from the contaminated source.
The blast radius wasn’t the fourteen surfaces. It was the content lineage — the invisible dependency graph that connects a source document to every asset that inherits from it. Fixing the leaf nodes without fixing the root is a game of infinite whack-a-mole. The system will re-contaminate itself faster than you can patch it.
When I designed the Comprehension Audit, blast radius mapping shaped two architectural decisions that a user never sees — but would immediately feel if they were missing.
The first is the heuristic fallback scorer. The primary evaluation path runs user responses through a dual-run LLM judge — an API call to an external model. If that API is unavailable, slow, or returns malformed data, the system doesn’t show an error. It activates a keyword-based heuristic scorer that evaluates responses against signal-word libraries for each dimension.
The fallback scorer has a hard ceiling at Level 3. It cannot assign L4 or L5 scores because keyword matching can’t assess the kind of nuanced comprehension those levels represent. That ceiling is a blast radius decision — it’s better to under-score a sophisticated response than to over-score a surface-level one. The user gets a useful result. The result might be conservative. It will never be inflated by a system that couldn’t fully evaluate the input.
The second is the five-second timeout budget. The Comprehension Audit backend runs as a serverless function with a hard execution limit. The LLM judge call, the scoring calculation, the email integration, and the response formatting all share that budget. If the judge call takes too long, the fallback fires and the remaining budget goes to the operations that the user actually sees — their score and their result screen.
It's better to under-score a sophisticated response than to over-score a surface-level one.
The user never knows the judge went down. They see their score, their radar chart, their maturity band. The architecture absorbed the failure because the blast radius was mapped before the system was built. “What happens when the judge is unavailable?” wasn’t a question we asked after launch. It was a question that shaped the architecture from day one.
Blast radius mapping is the discipline of quantifying damage before it happens. Not “what could go wrong” — that’s risk assessment, and it produces spreadsheets that live in SharePoint folders nobody opens. Blast radius mapping is specific: this component fails, this data is affected, these users are impacted, this is how long until we detect it, and this is what the system does automatically to contain the damage.
The configuration drift ran for three weeks because nobody had defined the detection window. The CRM field mismatch ran for two days because nobody had defined what “successful submission” actually means at the data layer. The compliance violation propagated across fourteen surfaces because nobody had mapped the content lineage.
Every one of those failures looked like success from the outside. Every dashboard was green. Every health check passed. The systems didn’t crash — they succeeded at the wrong thing. And the blast radius of succeeding at the wrong thing is always larger than the blast radius of failing loudly, because loud failures get fixed immediately and silent successes compound daily.
Map the blast radius first. Then build the system.
The Comprehension Audit uses blast radius mapping as both an architectural principle and an evaluation dimension — one of eight factors that determine whether you actually understand your AI project or just think you do. Try it at wilfredmorgan.com/comprehension-audit.
Wilfred Morgan
AI Systems Architect · Agentic AI Implementation