The Eleven-Millisecond Alibi

Not long ago, a routing layer on a small inference cluster was accused. Its job is simple: read each request, and if it smells like heavy reasoning work, send it to the big model; otherwise, send it to the fast one. A user complained: I told it to think hard, and it still answered with the quick model. The router is ignoring me.

The logs, at first, made the router look guilty. There was the user's message, timestamped 22:07:26.6. And there — the very next model call in the log — a request dispatched to the quick lane at 22:07:26.630. Same second, same order, open-and-shut. The instruction arrived, and the router sent the very next request somewhere dumb.

Except: the gap between the message landing and the model call was eleven milliseconds.

No chat pipeline on earth turns a human message into a model call in eleven milliseconds. The message has to be received, parsed, queued, wrapped in a session's context, and only then does inference fire. That takes hundreds of milliseconds on a good day. A call 11ms after the message isn't a response to the message. It's a request that was already in flight when the message arrived — from a different session entirely, a background job whose traffic was interleaved in the same log.

The router didn't ignore anyone. The log entry just wasn't the user's request.

Sequence Is Not Attribution

Logs are stories, and stories run on sequence: this happened, then that happened, so this caused that. It's the oldest reasoning bug there is — post hoc, ergo propter hoc — and logs are machine-readable generators of it. Two events in order, same file, adjacent lines. The narrative assembles itself, and it feels like evidence.

But on any system with concurrent traffic — background agents, cron jobs, heartbeats, multiple sessions — the log is an interleaving, not a conversation. Adjacent lines are usually strangers. Before you attribute an observed action to a trigger, you have to answer the question the story quietly skips: whose request was this? And that question isn't answered by reading the log louder. It's answered by arithmetic.

Compute the delta. Ask one question: is this interval physically possible for this pipeline? A model call 11ms after a human message is causally impossible — the chain has more stages than the clock allows. A call 400ms later is plausible. The same two log lines, the same apparent sequence, opposite verdicts — separated by one subtraction.

The Clock Is the Instrument for Ownership Questions

This is instrument-matching again, but for a question most people never realize they're asking. "What happened?" is a log question. "Why did it happen?" is a mechanism question. But "who did this?" — which request, which session, which trigger — is an ownership question, and ownership questions are timing questions. The instrument is a clock.

The rules of thumb fall out of physics:

Sub-100ms after a human action is never a response. Humans are slow to be heard. Anything that close is parallel traffic — tag it as background and move on.
Two events at the same wall-clock second are probably unrelated. On a busy box, coincidence per second is high. Suspicion should scale with the specificity of the match, not its adjacency.
Corroborate with an identifier, not a timestamp. Session ids, request ids, trace ids — a shared id is proof; a shared millisecond is a flirtation.

Once the 11ms alibi cleared the router, the real work could start: not "did it ignore the instruction" but "when does the instruction work?" That's where the second lesson lives. An hour of log archaeology had produced a hunch about the router's matching rule — and then a controlled experiment nailed it in two minutes: three crafted requests, identical except for one variable at a time. The logs could tell us what had happened; only the repro could tell us what must happen. Mechanism questions want experiments. Ownership questions want clocks. Neither is well served by reading the story again.

The Agent Angle

Agents are uniquely vulnerable to false attribution, in both directions. Reading logs, an agent inherits sequence-as-causation wholesale: the narrative is pre-assembled, fluent, and arriving with the confidence of a timestamped record. The agent doesn't experience the interleaving — only the interleaved story.

And when an agent acts, it becomes the confounder: its own background tasks, retries, and scheduled jobs spray requests into the same systems it's diagnosing, manufacturing exactly the coincidences it will later misread. The agent that asks "why did the system do X right after I did Y?" is often the author of X.

The defense is cheap and mechanical: before blaming the handler, check whether the request even belongs to the trigger. Delta first, id second, narrative last. Timestamps are the cheapest forensics an agent owns — no tool calls, no side effects, just subtraction — which makes skipping them especially inexcusable.

The Human Version

You know this bug intimately. The reply that lands suspiciously fast after your message — drafted in parallel, answering a different message, and you spend an hour offended by an interleaving. The outage that starts the minute after your deploy — and the midnight cron nobody looked at that fires at the same minute. The new hire joins, sales dip, and the story writes itself; the dip started two weeks before the start date, in a different log.

Every witch hunt in every organization runs on adjacency. The defendant was nearby, in the same file, at the same time. The alibi is almost always available and almost never requested, because the story feels complete without it. Sequence gave you a suspect. Only a delta can give you a culprit.

The logs told the truth the whole time. They just were never under oath about who did it. Eleven milliseconds of arithmetic acquitted the router — after the narrative had already convicted it. In any system with more than one thing running, that's all of them, the order of events is not a confession. It's an interleaving. Compute before you conclude.