The Green Build Lie: Why AI-Generated Fixes Need Production-Traffic Replay Before You Trust the Patch

A build goes green. The pull request gets approved. The AI-generated patch looks clean, the unit tests pass, integration coverage is solid, and the end-to-end suite signs off. Then production traffic hits.

A customer edits an order created six months ago under an old schema version. Another user retries a payment flow after a mobile timeout. A webhook arrives before the UI polling loop finishes. An internal admin action mutates state that no test fixture ever modeled. Nothing crashes immediately, which makes it worse. The bug slips through as corrupted state, duplicate side effects, broken workflow sequencing, or silent data drift.

This is the new reliability trap: AI can generate plausible fixes faster than teams can reason about the real-world behaviors those fixes affect. Traditional testing still matters, but green pipelines increasingly prove that your code matches your tests, not that your system survives production reality.

The missing verification layer is not “write more handcrafted tests.” Most teams are already behind on that advice, and AI accelerates the gap. The missing layer is production-traffic replay in CI/CD: sanitized traces replayed against ephemeral environments to validate whether actual user workflows, state transitions, and side effects still behave correctly before merge or deploy.

That is the difference between a patch that looks right and a patch you should trust.

The failure pattern is changing faster than most testing stacks

There was a time when the dominant risk was a human engineer making an obvious coding mistake. Today, a growing class of defects comes from something subtler: changes that are locally correct and globally wrong.

AI-generated fixes are especially good at this failure mode.

Given a stack trace, a flaky test, or a bug report, an AI assistant can often produce a patch that appears reasonable:

• it updates the validation logic
• it adds a null check
• it reorders asynchronous calls
• it adjusts a query condition
• it patches a serializer or parser
• it introduces a retry or debounce

The patch usually aligns with the immediate symptom. It may even improve readability. But software reliability is rarely about whether a line of code is plausible in isolation. It is about whether the system still behaves correctly across real sequences of events, mixed versions of data, race conditions, retries, duplicate delivery, partial failures, and user actions that no test author thought to preserve.

That distinction matters more now because AI expands code throughput without expanding production understanding. It increases the number of candidate fixes entering review. It shortens the time between bug report and patch. It creates more green builds. And it gives teams more opportunities to ship something that passed every test except the one production was about to run.

This is not an anti-AI argument. It is a debugging and testing argument. If code generation gets cheaper, verification has to get more realistic.

Why green CI/CD pipelines increasingly give false confidence

Most teams organize quality around three familiar layers:

• unit tests for isolated logic
• integration tests for service or database interactions
• end-to-end tests for primary user flows

That stack is useful. It is also insufficient for the class of failures that show up when production traffic exercises your system in combinations your test suite does not model.

Unit tests verify functions, not workflows

Unit tests answer questions like:

• Does this formatter handle null input?
• Does this state machine reject invalid transitions?
• Does this helper compute the right output for these fixtures?

Those are good questions. But production incidents often come from the interaction between individually correct units.

A payment handler can be correct. A retry mechanism can be correct. A webhook consumer can be correct. The bug appears when payment success is observed twice under a race, one path writes state before another path reads it, and an idempotency key is scoped too narrowly.

No amount of isolated unit coverage proves the workflow is safe under real sequencing.

Integration tests validate expected dependencies, not production variance

Integration tests usually rely on curated fixtures:

• a few rows of seeded data
• happy-path API payloads
• expected response shapes
• controlled timing
• resettable state

Production does not look like curated fixtures.

Real requests carry version skew, optional fields, stale references, old identifiers, duplicate events, malformed-but-accepted payloads, and data combinations accumulated through years of business logic changes. Integration tests rarely preserve this historical mess because hand-authoring those cases is expensive, brittle, and incomplete.

End-to-end tests cover key paths, not actual traffic distributions

End-to-end suites often become a small museum of the flows the team considers important:

• sign up
• login
• checkout
• edit profile
• create project

They are necessary smoke alarms. They are not production replicas.

A passing Playwright or Cypress suite does not mean your system handles:

• users who open multiple tabs
• browser retries after network drops
• actions triggered by webhooks and humans concurrently
• partial migrations in long-lived accounts
• edge timing around async processing
• account-specific feature flag combinations
• event ordering differences across queues

This is why “all tests passed” is often a report about test design, not about operational truth.

QA cannot keep up with system state complexity

Manual QA still catches valuable issues, especially UX and exploratory failures. But QA cannot realistically reproduce the state entropy of production. The problem is no longer just interface behavior. It is historical state, timing, sequence, side effects, and inter-service coordination.

As systems grow and AI increases change volume, asking humans to manually simulate production diversity is not a serious reliability strategy.

The core insight: test user intent under real sequences, not just code paths

The critical mistake in many testing strategies is optimizing around code coverage instead of workflow correctness.

Users do not care whether a branch was executed. They care whether their intended action completed correctly:

• Did the order update once, not twice?
• Did the refund reverse the right transaction?
• Did the workflow move to the correct state?
• Did notifications fire exactly as expected?
• Did downstream systems observe the same truth?

Production-traffic replay is powerful because it evaluates changes against recorded intent-bearing interactions rather than abstract, handcrafted examples.

Done correctly, replay is not just “send a lot of requests again.” That is load testing. Replay for verification focuses on preserving action-level meaning:

• the request sequence
• the timing relationships that matter
• the payload shapes and real-world variability
• the state preconditions
• the expected workflow outcomes and side effects

This is why traffic replay catches failures green pipelines miss. It does not ask whether your tests anticipated the bug. It asks whether your patch survives the same kinds of interactions that produced reality in the first place.

Traffic replay is not load testing

Many teams hear “replay production traffic” and think of throughput benchmarks, latency tests, or stress tools like JMeter, k6, or Locust. That is the wrong mental model.

Load testing answers questions like:

• How many requests per second can we handle?
• Where are the bottlenecks?
• What happens under peak concurrency?

Those are valuable questions. But they are not the same as validating correctness.

Traffic replay for pre-deploy verification is about preserving business semantics:

• Did this user workflow still produce the right state transition?
• Did this sequence still avoid duplicate side effects?
• Did asynchronous operations converge to the same final outcome?
• Did downstream events still match expectations?
• Did the system remain correct when actions arrived in real production order?

A load test might tell you the patch scales. A replay test tells you whether the patch lies.

That distinction matters because many dangerous regressions are low-volume, not high-volume. One misordered retry in a rare account state can do more damage than a brief latency spike.

A realistic failure example: the AI fix that passed everything

Imagine a subscription platform where customers can update billing details while background invoice finalization jobs run. A bug report arrives: under certain conditions, invoice status remains pending after a successful payment.

An AI assistant proposes this patch in a Node service:

js
// before
async function finalizeInvoice(invoiceId) {
  const invoice = await db.invoices.findById(invoiceId);

  if (invoice.status !== 'pending') {
    return invoice;
  }

  const payment = await payments.capture(invoice.paymentIntentId);

  if (payment.status === 'succeeded') {
    await db.invoices.update(invoiceId, { status: 'paid' });
  }

  return await db.invoices.findById(invoiceId);
}

js
// AI-generated patch
async function finalizeInvoice(invoiceId) {
  const invoice = await db.invoices.findById(invoiceId);

  if (invoice.status === 'paid') {
    return invoice;
  }

  const payment = await payments.capture(invoice.paymentIntentId);

  if (payment.status === 'succeeded') {
    await db.invoices.update(invoiceId, {
      status: 'paid',
      paidAt: new Date().toISOString()
    });
  }

  return await db.invoices.findById(invoiceId);
}

It looks reasonable. It broadens the guard so the function can recover pending invoices more aggressively. Unit tests pass. Integration tests pass with mocked payment success. An end-to-end billing flow passes.

But replayed production traffic reveals the bug.

In the real system, invoice finalization can be triggered by:

• UI confirmation flow
• background reconciliation job
• payment provider webhook retry

Under a real production sequence, two finalize calls hit close together. The first capture succeeds and writes paidAt. The second arrives before a read replica catches up, sees status not equal to paid, calls capture again, and downstream payment infrastructure interprets it as another billable action under a legacy provider integration path.

Your handcrafted tests never modeled:

• duplicate triggers from multiple sources
• read-after-write lag
• account-specific provider behavior
• old invoices created before an idempotency rollout

The patch fixed the reported symptom and introduced a production-grade side-effect bug.

Replay catches it because it preserves the actual request sequence and cross-system timing closely enough to expose the unsafe assumption.

What production-traffic replay should actually verify

If your replay system only checks for HTTP 200 responses, you are not doing useful verification. You are just rerunning requests.

Effective replay should validate outcomes at the workflow level.

1. State transitions

Did entities end in the correct state?

Examples:

• order: pending -> paid -> fulfilled
• refund: requested -> approved -> settled
• deployment: queued -> running -> completed

You are not just checking that handlers returned success. You are checking that the business process converged correctly.

2. Side effects

Did the system emit the right downstream actions exactly once?

Examples:

• one email, not two
• one charge, not zero or two
• one inventory reservation per order
• one audit record with the expected fields

This is where many AI-generated fixes fail: they preserve local output while changing side-effect cardinality or timing.

3. Invariants

Did the replay preserve properties that must always hold?

Examples:

• account balance never negative unless overdraft enabled
• order total equals line items plus tax minus discount
• user cannot hold two active primary subscriptions
• workflow terminal states are mutually exclusive

Invariants are often better than brittle exact-match assertions because they scale across real traffic diversity.

4. Event and action sequencing

Did the system handle realistic ordering without drift?

Examples:

• webhook before UI refresh
• retry before previous async completion
• cancellation during in-flight fulfillment
• duplicate submission across devices

Correctness under sequence variation is exactly where green builds overstate confidence.

5. Regression diffing against baseline behavior

For many flows, the goal is not merely “did it succeed?” but “did behavior change unexpectedly compared with the current version?”

A practical replay system compares:

• current main branch behavior
• candidate patch behavior

Then flags unexpected differences in:

• database state
• emitted events
• external calls
• workflow completion status
• timing thresholds where relevant

How this fits into CI/CD without becoming a science project

The objection is predictable: replay sounds powerful, but also expensive and operationally heavy.

It can be. But the alternative is shipping changes—especially AI-generated changes—based on abstractions increasingly detached from production behavior.

The practical version looks like this:

1. Capture production traces for selected workflows.
2. Sanitize or tokenize sensitive data.
3. Store traces with enough context to reconstruct intent and sequence.
4. Spin up ephemeral environments per pull request or pre-deploy candidate.
5. Seed representative state snapshots or synthetic equivalents.
6. Replay trace bundles against the ephemeral environment.
7. Assert workflow outcomes, side effects, and invariants.
8. Fail the CI/CD gate if replay diverges materially.

This is not something you need to apply to every endpoint on day one. Start with the workflows that create incidents or revenue risk.

A reference architecture for replay in modern pipelines

A minimal architecture usually includes these components:

Trace capture layer

Capture requests and relevant events at the action boundary, not just raw packets.

Good sources include:

• API gateway logs
• application request middleware
• event bus envelopes
• webhook ingress logs
• frontend action telemetry correlated to backend requests

You need correlation IDs and timestamps. Without those, sequence reconstruction becomes guesswork.

Sanitization pipeline

Before storage or replay, transform sensitive fields:

• tokenize PII
• replace payment details
• redact secrets
• normalize regulated attributes

Sanitization must preserve structural validity. If you remove the shape that triggers the bug, replay loses value.

State provisioning

Replay is meaningless if the target environment lacks the preconditions that made the workflow possible.

Options include:

• database snapshots scrubbed and subsetted by tenant or workflow
• fixture generation from captured entity graphs
• deterministic synthetic reconstruction based on trace metadata

State is the hardest part. But it is also the main reason replay finds bugs ordinary request reruns do not.

Ephemeral environment orchestration

For each pull request or deploy candidate:

• create isolated service instances
• provision databases and queues
• configure test doubles for dangerous external systems
• route replay traffic into that environment

Ephemeral environments make replay safe and parallelizable in CI/CD.

Assertion engine

Assertions should work at multiple levels:

• protocol: response codes, schema validity
• workflow: final states, event counts, side-effect expectations
• invariant: business rules
• diff: baseline versus candidate behavior

Example: capturing and replaying action traces in JavaScript

A simple Express middleware can capture requests with correlation metadata.

js
import fs from 'fs';
import crypto from 'crypto';

export function traceCapture(req, res, next) {
  const startedAt = Date.now();
  const traceId = req.headers['x-correlation-id'] || crypto.randomUUID();

  const chunks = [];
  req.on('data', chunk => chunks.push(chunk));

  res.on('finish', () => {
    const body = Buffer.concat(chunks).toString('utf8');

    const trace = {
      traceId,
      method: req.method,
      path: req.path,
      query: req.query,
      headers: {
        'user-agent': req.headers['user-agent'],
        'x-feature-flags': req.headers['x-feature-flags']
      },
      body: safeSanitize(body),
      statusCode: res.statusCode,
      startedAt,
      finishedAt: Date.now()
    };

    fs.appendFileSync('./traces.ndjson', JSON.stringify(trace) + '\n');
  });

  next();
}

function safeSanitize(body) {
  try {
    const parsed = JSON.parse(body);
    if (parsed.email) parsed.email = 'user+redacted@example.com';
    if (parsed.cardNumber) parsed.cardNumber = 'tok_sanitized';
    return parsed;
  } catch {
    return body;
  }
}

That is intentionally simple. In production, you would push structured traces to object storage or a data pipeline with stronger privacy controls and better correlation.

Now a replay runner:

js
import fs from 'fs';

const BASE_URL = process.env.REPLAY_BASE_URL;
const traces = fs.readFileSync('./selected-traces.ndjson', 'utf8')
  .trim()
  .split('\n')
  .map(line => JSON.parse(line));

const results = [];

for (const trace of traces) {
  const res = await fetch(`${BASE_URL}${trace.path}`, {
    method: trace.method,
    headers: {
      'content-type': 'application/json',
      'x-correlation-id': trace.traceId,
      'x-replay-mode': 'true'
    },
    body: ['GET', 'HEAD'].includes(trace.method) ? undefined : JSON.stringify(trace.body)
  });

  results.push({
    traceId: trace.traceId,
    path: trace.path,
    status: res.status
  });
}

const failures = results.filter(r => r.status >= 400);
if (failures.length) {
  console.error('Replay failures:', failures);
  process.exit(1);
}

Useful, but still too shallow. The real value comes from checking state and side effects after replay.

Example: verifying workflow outcomes in Python

Suppose replaying traces should leave subscription state consistent and ensure only one invoice email event exists per invoice.

python
import json
import os
import psycopg2
from collections import defaultdict

conn = psycopg2.connect(os.environ["DATABASE_URL"])

EXPECTED_TERMINAL_STATES = {"active", "canceled", "past_due"}


def assert_subscription_invariants():
    with conn.cursor() as cur:
        cur.execute("""
            SELECT account_id, COUNT(*)
            FROM subscriptions
            WHERE is_primary = true AND status = 'active'
            GROUP BY account_id
            HAVING COUNT(*) > 1
        """)
        duplicates = cur.fetchall()

        if duplicates:
            raise AssertionError(f"Multiple active primary subscriptions found: {duplicates}")


def assert_invoice_email_cardinality():
    with conn.cursor() as cur:
        cur.execute("""
            SELECT invoice_id, COUNT(*)
            FROM outbox_events
            WHERE event_type = 'invoice.emailed'
            GROUP BY invoice_id
            HAVING COUNT(*) > 1
        """)
        dupes = cur.fetchall()

        if dupes:
            raise AssertionError(f"Duplicate invoice email events found: {dupes}")


def assert_terminal_states():
    with conn.cursor() as cur:
        cur.execute("SELECT id, status FROM subscriptions")
        bad = [(row[0], row[1]) for row in cur.fetchall() if row[1] not in EXPECTED_TERMINAL_STATES]

        if bad:
            raise AssertionError(f"Unexpected subscription states: {bad}")


if __name__ == "__main__":
    assert_subscription_invariants()
    assert_invoice_email_cardinality()
    assert_terminal_states()
    print("Replay assertions passed")

This is the kind of verification that turns replay from traffic generation into a reliability gate.

Browser-level validation still matters, but it is not enough alone

There is still a role for Playwright in this model. Not as the sole source of truth, but as part of workflow validation.

For example, after replaying traces that affect account state, you can run targeted Playwright checks to confirm the UI reflects the final system truth.

ts
import { test, expect } from '@playwright/test';

test('replayed account workflow renders correct final state', async ({ page }) => {
  await page.goto(process.env.APP_URL + '/accounts/acct_123/billing');

  await expect(page.getByTestId('subscription-status')).toHaveText('Active');
  await expect(page.getByTestId('latest-invoice-status')).toHaveText('Paid');
  await expect(page.getByTestId('payment-warning')).toBeHidden();
});

This helps catch cases where backend correctness and frontend rendering diverge after realistic workflow execution.

CI/CD example: replay gate in GitHub Actions

A replay gate belongs in the pipeline next to unit, integration, and e2e checks—not as a replacement, but as the layer that validates real workflow behavior.

yaml
name: pr-validation

on:
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm test
      - run: npm run test:integration
      - run: npx playwright test

  replay:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Start ephemeral environment
        run: docker compose -f docker-compose.ephemeral.yml up -d --build
      - name: Wait for services
        run: ./scripts/wait-for-healthy.sh
      - name: Seed replay state
        run: python scripts/seed_replay_state.py
      - name: Run production trace replay
        env:
          REPLAY_BASE_URL: http://localhost:8080
        run: node scripts/replay_traces.js
      - name: Assert workflow outcomes
        env:
          DATABASE_URL: postgres://postgres:postgres@localhost:5432/app
        run: python scripts/assert_replay_outcomes.py
      - name: Run post-replay UI checks
        env:
          APP_URL: http://localhost:3000
        run: npx playwright test tests/post-replay.spec.ts

This pattern raises developer productivity over time, not lowers it. Why? Because it catches the painful class of regressions that otherwise escape into incident response, rollback drills, hotfixes, and trust erosion.

What to compare: candidate branch versus baseline

One of the strongest patterns is differential replay.

Run the same trace bundle against:

• baseline: current production-equivalent main branch
• candidate: branch with the patch

Then compare:

• final database snapshots for targeted entities
• emitted event streams
• external call envelopes to mocks or sandboxes
• workflow completion markers
• invariant violations

This is particularly useful for AI-generated fixes because the patch may change behavior in ways no reviewer notices. Differential replay gives you a machine-checkable answer to a practical question: what changed in the real workflow, not just in the diff?

Tools and approaches: what exists today

There is no single perfect stack, but the ecosystem roughly splits into categories.

Traditional test frameworks

Examples:

• Jest
• Pytest
• JUnit
• Playwright
• Cypress

Strengths:

• essential foundations
• good developer ergonomics
• fast local feedback

Weaknesses:

• rely on handcrafted scenarios
• weak at capturing production sequencing and state variance

Load and performance tools

Examples:

• k6
• Locust
• JMeter
• Gatling

Strengths:

• excellent for throughput and latency characterization
• useful for scaling validation

Weaknesses:

• usually optimize for volume, not intent preservation
• weak at business correctness assertions

Observability and trace systems

Examples:

• OpenTelemetry
• Datadog APM
• Honeycomb
• Elastic

Strengths:

• provide rich production insight
• helpful sources for replay trace selection and correlation

Weaknesses:

• not replay systems by themselves
• often lack state provisioning and assertion workflows

Traffic replay and environment platforms

This category is more fragmented. Teams often assemble it from:

• service virtualization and mock layers
• API gateway capture pipelines
• custom trace stores
• ephemeral preview environments
• workflow assertion harnesses

Strengths:

• closest to validating real production behavior before release
• highly effective for debugging and regression prevention

Weaknesses:

• harder to implement well
• requires discipline around sanitization, state, and assertions

That implementation difficulty is real. But compare it to the cost of trusting AI-generated patches because the pipeline was green.

Actionable practices for teams adopting replay

You do not need a massive platform initiative to start getting value. The best path is narrow, opinionated, and incident-driven.

1. Start with incident-prone workflows

Pick the workflows where regressions are expensive:

• billing
• provisioning
• authentication and authorization transitions
• order lifecycle
• webhook-driven state changes

If you try to replay everything, you will stall.

2. Capture at the action level, not only the request level

A raw HTTP log is often not enough. Preserve correlation IDs, actor identity, feature flags, and event relationships so you can reconstruct intent.

3. Build assertions around business invariants

Do not overfit to every byte of output. Assert what must remain true:

• exactly-once side effects
• valid terminal states
• no impossible combinations
• stable downstream event semantics

This makes replay robust even as harmless implementation details evolve.

4. Sanitize without destroying bug-triggering structure

Security and privacy are non-negotiable. But over-redaction can make traces useless. Replace sensitive values while preserving:

• field presence
• payload shape
• cardinality
• data type
• sequence relationships

5. Use differential replay for risky patches

Not every commit needs replay at the same depth. Trigger stronger replay gates for:

• AI-generated fixes
• hot paths
• state machine changes
• retries, queues, webhook handlers
• billing and permissions code

6. Replay bundles, not random traffic dumps

Curate trace bundles by workflow, tenant shape, feature flag, and incident history. You want representative slices of production reality, not noise.

7. Mock external effects safely, but record intent

You should not charge cards or send customer emails from replay environments. Route these interactions to sandboxes or mocks while asserting:

• whether the call would have happened
• how many times
• with what payload shape

8. Make replay failures debuggable

A replay gate that only says “diverged” will be ignored. Surface:

• the trace ID
• the workflow name
• baseline versus candidate diff
• state transition mismatch
• side-effect mismatch
• correlated logs and spans

Debugging quality determines whether teams trust the system.

9. Keep traditional tests, but demote their implied certainty

Unit, integration, and e2e tests are still necessary. The change is conceptual: a green build should mean “basic confidence,” not “safe to ship.” Replay is the layer that tests contact with reality.

10. Treat replay as part of developer productivity, not just QA

The fastest team is not the one that merges quickest. It is the one that spends the least time in incident channels, rollback calls, and forensic debugging after “successful” deploys.

Replay improves developer productivity because it catches workflow regressions while the diff is small, the context is fresh, and the patch author is still looking at the code.

Common objections, answered directly

“We already have high test coverage.”

Coverage is not behavior realism. You can execute every branch that matters to your tests and still miss the production sequence that breaks money movement or state convergence.

“This sounds expensive.”

So are incidents caused by false-positive CI confidence. Start with the top 5 workflows tied to revenue or support pain. The ROI shows up quickly when you prevent even a handful of escaped regressions.

“We can just write more end-to-end tests.”

You should write the critical ones. But handcrafted e2e suites do not scale to production state diversity and sequence entropy. Replay complements them by importing reality instead of trying to imagine it.

“Our production data is too sensitive.”

That is a valid constraint, not a reason to avoid replay entirely. Sanitization, tokenization, shape-preserving redaction, and synthetic state reconstruction are hard but tractable. Teams in regulated environments already do harder things.

“This will slow down CI/CD.”

Only if you apply it indiscriminately. Use tiered replay:

• small curated bundles on pull requests
• broader replay on release candidates
• deep replay on risky changes

The goal is smarter gating, not maximal gating.

The bigger shift: reliability now depends on verifying generated change at system boundaries

AI is changing software development in an unglamorous but important way: it increases the number of changes that are syntactically correct, semantically plausible, and operationally uncertain.

That means debugging and testing need to evolve from “did the code satisfy our examples?” to “did the change preserve real user outcomes under real conditions?”

The old model assumed humans were the bottleneck in code production, so handcrafted tests could roughly keep pace. That assumption is gone. When patches arrive faster—especially bug fixes produced by AI—the verification layer must pull reality closer to the pipeline.

Production-traffic replay is one of the clearest ways to do that.

Not because it is trendy. Not because it replaces all other testing. But because it checks the thing that matters most and is most often missing: whether your patch survives the mess your customers actually generate.

Conclusion

The green build is becoming a dangerous social signal.

In many teams, it still implies a level of trust it no longer deserves—especially when AI-generated fixes are involved. A patch can satisfy unit tests, integration suites, and browser automation while still failing under the sequencing, payload variance, and timing irregularities of real production traffic.

That is the lie: not that tests are useless, but that passing them is enough.

If you want a more reliable CI/CD system, do not just add more handcrafted cases and hope coverage catches up with generated code volume. Add a verification layer that replays sanitized production traces against ephemeral environments and checks workflow outcomes, side effects, and state transitions before merge or deploy.

Test user intent. Test sequence. Test invariants. Test what production will actually do.

Because the standard for trusting a patch should not be that the pipeline stayed green.

It should be that reality had a chance to disagree—and didn’t.