The Gate We Added Because a Colleague Misremembered

The gate in question checks whether a player's most recent appearance in the corpus was logged under the correct event type — home or away, surface type in tennis, day or night in baseball. It sounds like a bookkeeping rule. It is, mostly. But it exists because Marcus remembered something wrong and nobody caught it for three weeks.

That is the version of the story I do not enjoy telling, because we added the gate with some confidence, wrote it into the documentation as if we had always known we needed it, and only reconstructed the actual origin later when the calibration report came back and something did not fit. The gate was doing real work. The reason we built it was not.

This is the kind of thing that makes the Doctrine desk uncomfortable to write. Rules the shop follows, most of them written after being burned by not having them — that is the brief. But occasionally a rule gets written after being burned by something that never quite happened the way anyone remembers. The gate still runs every morning. I am still not entirely sure we understand why it helps.

What Marcus Actually Said, and What He Thought He Was Saying

In the third week of a hockey evaluation cycle, Marcus flagged what he described as a "systematic context mismatch" — his phrase — in the corpus entries for a cluster of forwards we had been tracking. His claim was that during a stretch of the previous season, we had been pulling performance records for road games and tagging them as neutral-site appearances, because a venue classification table had been updated mid-season and we had not re-ingested the affected rows.

He was specific. He named the approximate date range. He described the downstream effect on the shrinkage calculation. The whole thing had the texture of a careful postmortem, and we treated it as one.

The problem was that when Dani went back to verify it, the mismatch Marcus described did not exist — not in the form he remembered, anyway. The venue table had been updated, that part was true, but the re-ingestion had run correctly. What Dani found instead was a different and smaller issue: a handful of entries where the event-type tag had been inherited from a template row rather than written from source data. Not the same error. Not the same scale. Not the same fix.

"He wasn't wrong that something was off. He was wrong about what it was and how long it had been happening. Which is actually the more interesting failure, if you think about it."
— Dani

We had already drafted the gate by the time Dani finished her audit. It checked event-type tags against source data on every corpus entry before scoring. Marcus's remembered error would have required exactly that fix. The actual error also required exactly that fix. The gate was correct. The diagnosis that produced it was not.

How We Wrote the Gate Into Doctrine as If We Had Always Known

The gate itself is not complicated. Before a player entry moves past the corpus stage, the system confirms that the event-type tag on each appearance record matches the raw source field, not an inherited or inferred value. If there is a mismatch, the entry is flagged and held. A human reviews it. Usually the source field is correct and the tag was wrong; occasionally it is the reverse.

We deployed it in the middle of that hockey cycle and wrote a short internal note explaining the reasoning. The note cited Marcus's diagnosis almost verbatim. It described the venue classification problem, the mid-season table update, the affected rows. All of that went into the documentation as established fact.

This is a version of what we once called "adding a gate after the fact and calling it foresight" — a failure mode we have written about before, where a rule that was actually reactive gets narrated as proactive. In that case the shop had at least gotten the underlying problem right. Here we had gotten the gate right and the problem wrong simultaneously, which is a stranger thing to account for.

The documentation stayed as Marcus had written it for about six weeks. Nobody had reason to question it. The gate was running, the calibration numbers for that cluster of hockey forwards looked cleaner than they had, and the story of why felt complete.

What It Cost to Have the Right Answer and the Wrong Reason

The direct cost was small. Dani's audit added two days to a cycle that had already slipped, and rewriting the documentation took an afternoon. The gate itself did not need to change — it was checking the right thing regardless of why we thought we needed it.

The indirect cost was harder to measure and probably still running. When a gate is documented against the wrong failure mode, the documentation teaches the wrong lesson. Anyone reading that internal note would come away believing the risk was a mid-season table update propagating incorrectly through a re-ingestion pipeline. That is a real risk, and worth watching. But it is not the risk the gate was actually catching. The gate was catching inherited template values — a quieter, more persistent problem that does not announce itself with a visible infrastructure event.

We had, in effect, built a smoke detector and written on the box that it detects gas leaks. It detects smoke. Smoke and gas leaks sometimes co-occur. The detector is still useful. The label is still wrong.

There is also the question of what else Marcus might be misremembering, and what other gates might be documented against plausible-but-inaccurate histories. We have a known tendency to trust the gates we built more than the ones we inherited, which is its own bias. But trusting a gate because a confident colleague described its origin in specific and credible terms is a different failure, and I am not sure we have a systematic check for it.

Marcus, for his part, was not embarrassed. He thought the distinction between his remembered error and the actual error was "methodologically interesting but operationally irrelevant." He may be right. That is the part I keep turning over.

What the Gate Does Now, and What the Documentation Says

The gate runs unchanged. Event-type tags are verified against source fields on every corpus entry before scoring, across all five sports. In basketball it catches the occasional neutral-site game tagged as home. In tennis it catches surface mismatches when a tournament moves an indoor match outside due to weather and the feed does not update cleanly. In baseball it catches a small but consistent trickle of day-night errors in historical records from one data source we have been using for years and do not fully trust.

The documentation was rewritten after Dani's audit. It now describes both the error Marcus remembered and the error Dani actually found, notes that the gate addresses both, and flags that the original diagnosis was partially incorrect. It is longer than it needs to be. I think the length is appropriate.

What we did not do was add a gate specifically for the scenario Marcus described — the mid-season table update problem. That scenario is real, and we have thought about it. But building a gate for one specific failure mode and then applying it across sports is its own trap, and the table-update scenario is specific enough to hockey's data infrastructure that generalizing it felt premature. We put a note in the pipeline documentation and left it there.

What stayed in the doctrine, beyond the gate itself, was a small procedural addition: when a new gate is proposed, whoever proposes it now has to write down the specific instance that motivated it before the gate is built, not after. The write-up gets dated. If the gate gets added, the write-up gets attached. The idea is that if the origin story turns out to be wrong, at least we will know when the wrong story was written.

It is not a perfect fix. Memory is not the only way a gate's documented rationale can drift from its actual function — we have passed through gates twice before we understood what they were actually checking, and in those cases the problem was not memory at all. But it is something.

The gate works. The reason we built it was wrong. I am not sure those two facts are as separable as I would like them to be — that a gate doing real work somehow validates the reasoning that produced it. They might be entirely independent. That possibility is either reassuring or troubling depending on the day, and I have not settled on which.

Note: PlayerGem is a fictional analytics shop and these accounts are invented. Nothing here is a pick, a recommendation, or betting or investment advice, and the players, teams and competitions described do not exist.