Blog

For my ninth birthday, my grandmother gave me a copy of Tell Me Why. It quickly became her standard response whenever I asked her something: not the answer, but a gesture toward the shelf. My other grandmother, not to be outdone, gave me a set of encyclopedias the following year. Between the two of them, the message was hard to miss.

It took me a long time to work out what they were actually teaching, and it wasn’t trivia.

The first lesson was intellectual ownership. When you go find something out yourself, you can’t unsee it. That knowledge sticks in a way a handed-over answer never does, because you know what it cost to get.

The second was resource allocation. My grandmothers had finite time and finite patience, and turning my curiosity into their labor was a choice I was making on their behalf without asking.

Source baiting inverts both lessons. It demands that someone else do the intellectual work, while reserving the right to dismiss whatever they come back with.

Recognizing the Pattern

You’ve probably encountered this. You mention something straightforward: a well-established principle, a widely-reported fact, something that takes thirty seconds to verify. Someone responds: “Source?”

You provide one. They dismiss it. You provide another. They want more. You provide a third. They question the methodology. The conversation that was supposed to be about the implication of the information never happens, because you’re stuck in an endless loop of proving basic reality.

If you work in technology, you already recognize this shape. You’re experiencing a Denial of Service attack on shared reality itself.

It shows up in two forms. The first demands evidence for things already established. The second demands that you account for scenarios that will never occur. They look like opposites. One is skeptical of the past, the other anxious about the future. But they run on identical mechanics, and they cost the same thing.

How DoS Attacks Work

A Denial of Service attack exploits a fundamental asymmetry in computer systems:

The attacker’s cost: Nearly zero. Send thousands of junk requests with minimal resources.

The defender’s cost: High. Each request must be processed, validated, and responded to.

The requests don’t need to be valid. They don’t need to be honest. They just need to be endless. Eventually, the system becomes so overwhelmed processing garbage that legitimate traffic can’t get through.

The goal isn’t to break in. The goal is to make the system unable to serve its intended purpose.

How Source Baiting Works

Now map this to conversation.

Typing “source?” costs three seconds. Answering it costs research, citation, context, and follow-up. Each demand is cheap to make and expensive to satisfy, and the attack continues even when you satisfy it. The goalposts move. The citation gets dismissed as biased. New demands emerge.

The objective is to make providing information so expensive that you stop trying.

So you never reach the substantive conversation, the one about what the information means and what we should do about it. You’re stuck processing junk requests while legitimate discussion starves.

The Attacker Usually Doesn’t Know They’re Attacking

In a technical DoS, the attacker knows they’re attacking. In a conversational one, they usually don’t. They may believe they’re being appropriately skeptical, maintaining intellectual standards, or protecting themselves from misinformation.

Part of this is identity-protective cognition, a phenomenon Dan Kahan and the Cultural Cognition Project have spent years documenting: in polarized environments, information isn’t just information, it’s identity. When a fact threatens someone’s sense of who they are or which side they’re on, checking it honestly can feel like self-betrayal. The question shifts from “Is this true?” to “If this is true, what does that make me?”

That doesn’t make the cost to you any lower. But it does mean the right response is sometimes patience rather than a block.

There’s a second caveat, and it’s the more uncomfortable one: sometimes the person demanding a source is right. Well-established isn’t the same as true. “Everyone knows this” has covered for a great deal of nonsense, and the fact that a claim is inconvenient to defend doesn’t make the person asking a bad actor. If you find yourself reaching for the DoS framing every time someone questions you, the pattern you’ve detected might be your own.

So the distinction that matters is behavioral: do they ever update on new information? Someone wrestling with something that threatens their worldview will eventually move, even grudgingly. Someone running the pattern never does, because movement was never on the table.

Everything below assumes you’ve actually checked.

What It Looks Like in Practice

The Incident Response Derailment

Mid-incident, 2 AM, users can’t log in

Engineer A: “Login service is throwing 500s. Database connection pool is exhausted.”

Engineer B: “Source? How do you know it’s the connection pool?”

Engineer A: “The saturation metrics — here, this dashboard.”

Engineer B: “That dashboard could be wrong. Have you verified the instrumentation is accurate?”

Engineer A: “We use this dashboard for every incident. It’s—”

Engineer B: “But have you personally verified the code that generates these metrics is correct?”

Meanwhile, users still can’t log in. The incident that should take ten minutes to mitigate takes forty-five, because half the team is auditing monitoring infrastructure instead of fixing the outage.

The tell: Engineer B has no alternative hypothesis and no contradictory data, only endless demands to prove that tooling the team relies on every day actually works.

The Post-Mortem Paralysis

Post-incident review

SRE: “We should implement circuit breakers. When the downstream service fails, we shouldn’t keep hammering it with requests.”

Manager: “Show me the research that proves circuit breakers work.”

SRE: “Circuit breakers are a standard pattern. Netflix has published extensively about—”

Manager: “Netflix isn’t us. Show me evidence they’d work in our environment.”

SRE: “We could run a controlled test in staging—”

Manager: “That’s not production. Show me production evidence that this specific change would have prevented this specific incident.”

The conversation never reaches whether circuit breakers are the right solution for this problem. It stalls on whether they’re a valid concept at all. Six months later, the same incident happens again.

The tell: The manager has constructed a standard that can only be satisfied by doing the thing they’re refusing to authorize.

The Exploit-or-It-Doesn’t-Count Defense

Discussing a security vulnerability

Security Engineer: “This endpoint doesn’t validate input. We’re vulnerable to SQL injection.”

Developer: “Source? Show me an exploit.”

Security Engineer: “The code concatenates user input into a SQL string. Here’s the line.”

Developer: “But has anyone actually exploited it?”

Security Engineer: “That’s not how security works. The vulnerability exists whether—”

Developer: “If no one’s exploited it, how do you know it’s actually a problem? Show me evidence of real-world impact.”

The vulnerability stays unfixed, because the developer has redefined “proof” as “must be actively exploited before we fix it.”

The tell: Demanding proof of harm in place of proof of vulnerability is a category error, and it makes security work impossible by construction.

The Second Variant: Death by a Thousand “But What If…?”

The other form is harder to spot, because it sounds like rigorous thinking: obsessive focus on edge cases and low-probability events.

It runs the same play from the opposite direction. Rather than demanding evidence for what’s already known, it demands you account for what will never happen. The effect is identical: the standard for action becomes infinitely high.

How It Works

You: “We should implement rate limiting to prevent abuse.”

Them: “But what if a legitimate user needs to make 10,000 requests per second?”

You: “That’s not a realistic use case. Our 99th-percentile user makes 10 requests per minute.”

Them: “But what if someone’s running a bulk import?”

You: “We can provide a bulk API for that.”

Them: “But what if they’re using a legacy client that doesn’t support the bulk API?”

You: “We can grandfather those specific clients.”

Them: “But what if a new legacy client appears?”

You: “That’s… contradictory. New clients wouldn’t be legacy.”

Them: “But what if someone builds a new client that mimics the old behavior?”

Five layers into hypotheticals, none of which have ever happened, and there’s still no rate limiting.

Why This Works as an Attack

The asymmetry is the same one a DoS exploits:

• Proposing an edge case: five seconds
• Addressing an edge case: minutes of analysis, design work, sometimes code
• Disproving an edge case: often impossible, because you can’t prove something will never happen

Edge cases can be generated faster than they can be answered. Eventually the original proposal is buried under them.

Telling Rigor From Its Imitation

This one is hard, because edge case analysis is sometimes exactly right. Good engineers should think about failure modes. The difference is in what happens next.

Healthy edge case analysis:

• Focuses on likely edge cases, grounded in data or experience
• Proposes how to handle the case, not just that it exists
• Accepts “we’ll handle that if it happens” for rare scenarios
• Moves forward once the major edges are covered

Edge case DoS:

• Invents increasingly unlikely scenarios with no evidence they matter
• Identifies problems, never solutions
• Rejects “handle it later” even at near-zero probability
• Continues indefinitely, because there’s always another “but what if”

The Backup Strategy That Never Shipped

Team: “We should implement automated backups that run at 2 AM daily.”

Skeptic: “But what if someone’s running a long transaction that spans 2 AM?”

Team: “We’ll use snapshot isolation. The backup sees a consistent point-in-time view.”

Skeptic: “But what if the snapshot takes longer than 24 hours and the next backup starts?”

Team: “Our largest database backs up in 3 hours. We can alert if it ever exceeds 12.”

Skeptic: “But what if the database grows 10x overnight?”

Team: “That’s never happened. Our growth is gradual.”

Skeptic: “But what if someone imports a huge dataset?”

Team: “We have import quotas and—”

Skeptic: “But what if they bypass the quotas?”

Team: “That would require root access and—”

Skeptic: “But what if someone with root access goes rogue?”

Six months on, there are still no backups, because the team has been chasing rogue sysadmins with unlimited data imports.

The last objection deserved better than it got. A rogue administrator destroying backups is low probability, high impact, and worth planning for. It is still not a reason to have no backups at all. The edge case was legitimate; using it as a veto was not.

Risk Management Versus Risk Paralysis

Aviation worked this problem out in public.

For decades, twin-engine airliners were restricted to routes that kept them within sixty minutes of a diversion airport. That’s why long ocean crossings belonged to three- and four-engine aircraft: the obvious edge case, losing an engine over water, was addressed by carrying more engines.

Then engine reliability improved, and the industry did something more disciplined than bolting on another engine. It measured. ETOPS, or Extended-range Twin-engine Operational Performance Standards, allowed twins onto those routes under strict maintenance, crew training, and route-planning requirements, with permitted diversion times extended in increments as the reliability data justified each step: 120 minutes, then 180, then beyond.

The residual risk never went to zero. It went to a number the industry could name, defend, and revisit.

That’s the whole distinction. Risk paralysis asks “but what if?” and treats any unanswered scenario as disqualifying. Risk management asks “how likely, how bad, and what does coverage cost?”, then accepts what’s left and operates.

The Tells

Edge case fixation reveals itself through what’s missing:

1. No risk quantification: the probability is never estimated.
2. No cost-benefit analysis: the scenario is never weighed against the cost of addressing it.
3. No risk acceptance: “we’ll handle that if it happens” is rejected categorically.
4. No alternative proposals: they’ll tell you it must be addressed, never how.
5. Infinite recursion: answering one edge case spawns three more.

It borrows the appearance of rigor to prevent action.

Triage Questions for Edge Cases

When someone raises one, these five questions separate rigor from stalling:

“How likely is this?” If they can’t offer an estimate, it probably shouldn’t block anything. Below about one percent, ask why it warrants attention now.

“What’s the impact if it happens and we haven’t planned for it?” Low impact means later is fine. High impact with low probability means you want mitigation ideas, not just identification.

“What does it cost to handle now versus later?” High cost and low probability usually means later. Low cost may mean it’s worth doing anyway.

“What’s your proposed solution?” No solution means they’re identifying problems, not solving them.

“Are you willing to accept any level of residual risk?” If the honest answer is no, the conversation isn’t an engineering conversation anymore, and it’s worth naming that directly.

When AI Becomes the Authority

Generative AI has added a new wrinkle: the model said so.

Someone can produce a confident explanation, a statistic, or a list of references in seconds and present the output as evidence. When you point out that the claim is unsupported, or that the citations don’t say what the response claims they say, the burden lands on you: audit the reasoning, trace every reference, and refute an argument that was never properly supported to begin with.

This is source baiting with the costs pushed even further apart. Generating the claim is nearly free; checking it is expensive. And because the output arrives polished and authoritative, questioning it can be framed as technophobia rather than as an ordinary request for evidence.

AI is useful for finding and understanding information. It cannot convert an unsupported claim into a supported one. The standard doesn’t move: identify the actual source, look at what it establishes, and engage with the evidence rather than treating fluency as proof.

Task Saturation in the Cockpit

Aviation has a name for what both variants produce: task saturation. Crew members become so overloaded that they can’t perform critical functions. This is how accidents happen.

If someone in the cockpit keeps demanding you re-prove that the basic instruments work (verify the altimeter, now the airspeed indicator, now the attitude indicator), you cannot also fly the airplane. They’ve made the crew unable to perform its primary function. Not by being right. By consuming all the available bandwidth.

Crew Resource Management depends on people being willing to challenge assumptions, so the line matters:

“I’m seeing conflicting indicators on our altitude, can we cross-check?” — healthy challenge.

“Prove to me that altimeters work.” — task saturation.

High-reliability organizations require a shared baseline of reality. Interpretations are open to challenge. Decisions are open to question. Whether the wings generate lift is not, and refusing to accept foundational principles sabotages collaboration rather than protecting psychological safety.

How This Shows Up in Tech Organizations

I’ve watched this kill incident response. Mid-incident, someone questions whether the metrics indicate user impact at all, not because they have contradictory data, but because if the metrics are valid, their component is the cause. The team ends up debating measurement methodology instead of mitigating an outage.

Post-mortems attract the same thing. “Show me the research that says monitoring matters.” “Prove that SLAs aren’t sufficient.” “Cite evidence that blameless culture improves outcomes.” Each demand looks reasonable in isolation, and the aggregate effect is to prevent the review from reaching a conclusion anyone finds uncomfortable.

This is the luxury of ignorance in operation: the person demanding citations for commonly-held knowledge gets to conscript everyone else’s intellectual labor while staying insulated from the implications.

It’s a close relative of the interrogation-style management I’ve written about before: the manager who makes you justify routine professional decisions they should already understand. Not because they want to learn. Because making you explain yourself is a power move.

Organizational Consequences

When either pattern becomes normal, the damage stacks up at three levels.

Individually, people exhaust themselves defending basic reality. Good-faith participants disengage because the price of engagement is too high, and the most knowledgeable people go quiet first, because they’re the ones being billed.

On teams, conversations never advance past “prove it.” Critical discussions stall. Nothing compounds, because no shared understanding is ever allowed to settle.

Organizationally, decisions stop getting made, capable people leave for places where work happens, and setting any standard becomes impossible when everything is perpetually re-litigated.

Eventually the organization resembles a DoS’d server: still technically running, no longer able to serve its purpose.

Mitigations: What DoS Defense Teaches Us

The strategies that work against technical DoS translate well.

1. Rate Limiting

Technical: Cap how many requests a single source can make in a window. Past the limit, requests get dropped.

Conversational: Cap how many times you’ll provide sources before requiring good-faith engagement.

“I’ve provided three citations from different sources. If you’re genuinely curious, that’s enough to continue on your own. I’m not providing more until you engage with what’s already here.”

Three unanswered rounds is a pattern, not curiosity.

2. Challenge-Response

Technical: Before processing a request, make the sender demonstrate they’re human and acting in good faith.

Conversational: Before investing in another citation, ask for evidence of effort.

“What did you find when you looked into this? Which specific part are you trying to verify?”

Genuine curiosity answers those questions easily. The pattern can’t, because the goal was never to learn.

3. Traffic Analysis

Technical: Identify attacks by behavior. Real users browse and interact; attackers are repetitive and mechanical.

Conversational: Read the pattern rather than the individual message.

Genuine curiosity engages with what you provide, asks clarifying questions about the content, and updates when shown evidence. The attack pattern dismisses sources without engaging, moves the goalposts, never acknowledges what it received, and re-raises the same demands in new contexts.

The first builds knowledge. The second builds work.

4. Blackholing

Technical: Once traffic is identified as an attack, stop responding entirely. No error message, no acknowledgment. Don’t spend resources on junk.

Conversational: Once you’ve identified the pattern, stop responding.

This feels wrong. We’re taught that not answering is rude, that every question deserves a reply. But you don’t negotiate with DDoS traffic. Continuing to answer bad-faith demands doesn’t make you principled. It makes you complicit in your own exhaustion.

5. Upstream Filtering

Technical: Block attack traffic before it reaches your servers, at the CDN, firewall, or ISP level.

Conversational: Set organizational norms so the burden never lands on an individual in the first place.

In healthy teams, leadership establishes shared baselines and defends them:

“We’re not relitigating whether monitoring matters. If you don’t understand why we use these metrics, that’s a training question and we’ll handle it separately. We’re not turning every discussion into a proof-of-concept exercise.”

The goal is protecting team bandwidth, not suppressing questions.

6. Load Distribution

Technical: Don’t let one server absorb everything. Spread the load.

Conversational: Don’t let one person carry it alone.

“I can take that one — here’s the research from last time this came up. Let’s move on to implications.”

Where these patterns are common, individuals burn out defending reality by themselves. Shared response prevents it.

7. Logging

Technical: Keep records of attack patterns to recognize repeat offenders and improve defenses.

Conversational: Name the pattern out loud.

“This is the fourth time you’ve asked for sources without engaging with the previous three. I’m going to treat this as a pattern rather than as individual questions.”

Naming it makes it harder to sustain. These tactics depend on each exchange feeling isolated; documentation reveals the shape.

Shared Reality as a Prerequisite for Collaboration

Healthy organizations, like high-reliability teams in aviation, medicine, and infrastructure, operate from a baseline of shared reality. Not because everyone agrees on everything, but because some things aren’t perpetually up for debate.

We should welcome questions. Being able to tell them apart from the patterns that only look like questions is what makes welcoming them sustainable.

My grandmothers were right about both halves of it. Do your own work, and don’t make your curiosity someone else’s burden. Demanding sources you’ll never read and inventing scenarios that will never happen violate both lessons at once, and they do it while wearing the costume of intellectual rigor.

You don’t negotiate with DDoS traffic.