Frequency vs Magnitude

Most people think about software quality as a single number. "How many bugs does this system have?" That is the wrong question. It collapses two independent dimensions into one and makes you blind to the actual risk.

The right question is two questions: How often do bugs enter the system? And when one does, how much damage does it cause?

These are independent variables. A system can have frequent bugs that are all trivial. A system can have rare bugs that are each catastrophic. The engineering response to each scenario is completely different — and if you confuse them, you will invest in the wrong solution.

The Two Axes

measures how often bugs enter your system. High frequency means every deploy introduces new defects. Low frequency means bugs are rare — most changes work correctly the first time.

measures how much damage a single bug causes when it does occur. Low magnitude means the bug is a cosmetic issue or a minor inconvenience. High magnitude means data loss, financial loss, or permanent trust damage.

These two axes create a 2x2 matrix with four distinct quadrants. Each quadrant has a name, a profile, and a required engineering response.

Quadrant 1: Paradise (Low Frequency, Low Magnitude)

This is where disciplined teams operate. Bugs are rare because quality gates catch most defects before they ship. When a bug does slip through, it is minor — a tooltip is wrong, a counter is off by one, a date format is inconsistent.

Getting to Paradise requires investment. Tests, CI/CD, code review, E2E validation. But once you are here, velocity is high because you spend almost no time on bug triage and incident response.

Quadrant 2: Death by 1,000 Cuts (High Frequency, Low Magnitude)

This is the vibe coder's default quadrant. Every deploy introduces a few small bugs. None of them are critical. None of them warrant incident response. But they accumulate.

The danger of this quadrant is that it feels manageable. Each individual bug is trivial. "It is just a UI glitch." "It is just a minor data inconsistency." But 50 trivial bugs compound into a system where nothing quite works right. Users do not file bug reports — they just leave.

The engineering response is : test coverage, automated linting, CI/CD enforcement. Death by 1,000 cuts is a frequency problem, and frequency is solved by catching bugs before they ship.

Quadrant 3: Circuit Breaker Territory (Low Frequency, High Magnitude)

This is where the real danger lives. Bugs are rare — your tests catch most issues, your CI/CD enforces standards, your review process is solid. But when something does slip through, it is catastrophic.

I lived this quadrant. Foresight, my Polymarket trading bot, had solid test coverage. Bugs were infrequent. Then one night, a combination of market conditions triggered a scenario the tests did not cover. The result: $86 lost in 3 hours. Low frequency. Extremely high magnitude.

You cannot test your way out of this quadrant. By definition, high-magnitude bugs involve scenarios you did not anticipate. The engineering response is not prevention — it is .

Circuit breakers are the answer to low-frequency, high-magnitude failures:

Auto-rollback. If error rates spike after a deploy, the system automatically reverts to the last known good state. No human intervention required. The deploy failed, the system is safe, and you have logs to investigate.

Feature flags. New functionality ships behind a flag. If the feature causes issues, kill the flag. The rest of the system continues operating normally.

Kill switches. For systems that interact with money or irreversible operations, a kill switch stops all activity when anomaly thresholds are crossed. Foresight now has loss limits that halt trading automatically. At Tesseract Intelligence, intelligence pipelines have data quality thresholds that halt publication if source reliability drops below acceptable levels.

Loss limits. A hard ceiling on how much damage any single failure can cause. If a trading bot's maximum loss per hour is capped at $50, even a catastrophic bug cannot cause more than $50 of damage before the circuit opens.

Quadrant 4: Abandon Ship (High Frequency, High Magnitude)

This is the worst-case scenario. Bugs are frequent AND each one is devastating. Every deploy breaks something critical. Users are leaving. Revenue is dropping. The team spends all its time fighting fires.

If you are in this quadrant, the engineering response is not incremental improvement. It is a . Stop shipping new features. Freeze the codebase. Rebuild the quality infrastructure from the ground up — tests, CI/CD, monitoring — before writing another line of feature code.

This quadrant is where vibe-coded systems end up after hitting the wall and continuing to push forward without addressing the root cause. The generate-and-forget cycle from Lesson 150, left unchecked, always converges here.

Your Real-World Diagnostic

Every system lives in one of these four quadrants right now. The question is: do you know which one yours is in?

The diagnostic is simple. Count the bugs introduced in your last 5 deploys (frequency). For each bug, estimate the worst-case user impact if it had gone undetected for 48 hours (magnitude). Plot your system on the matrix.

If you are in Paradise, maintain your gates. If you are in Death by Cuts, invest in tests and CI/CD. If you are in Circuit Breaker Territory, build containment mechanisms. If you are in Abandon Ship, stop everything and rebuild.

The framework at InDecision uses this exact thinking for prediction market analysis — not about bugs, but about risk. Every position has a frequency axis (how often the thesis is wrong) and a magnitude axis (how much you lose when it is). The engineering of quality and the engineering of risk are the same discipline applied to different domains.

---

Lesson 151 Drill

Map your current system to the frequency-magnitude matrix:

1. Frequency audit: Review your last 10 deploys or code changes. How many introduced at least one bug? Express as a ratio (e.g., 3/10 = 30% bug rate). High = above 30%. Low = below 10%.

2. Magnitude audit: For each bug from step 1, classify it: trivial (cosmetic), minor (workaround exists), major (feature broken), critical (data loss or financial impact). If any are major or critical, your magnitude axis is high.

3. Quadrant placement: Using your frequency and magnitude scores, place your system in one of the four quadrants. Be honest — most AI-built systems without quality gates live in Death by 1,000 Cuts.

4. Response plan: Based on your quadrant, identify the top engineering investment: tests (frequency), circuit breakers (magnitude), or both (abandon ship recovery).

5. Circuit breaker inventory: List every automated safety mechanism in your current system. Auto-rollback? Feature flags? Kill switches? Loss limits? Health checks? If the list is empty, you have no containment — and you are one bad deploy away from Quadrant 4.