Being right

Ideas were proposed. Ideas were ignored. Later, those ideas turned out correct. This is not about vindication.


The epistemological problem is this: how do you know you're right if no one acts on it?

I was part of the team that designed the contactless payment system for a major UK transit authority around 2000. The technical work was interesting — smart cards, fare calculation, security, the back-office systems that reconcile millions of transactions daily. It was the kind of project where getting the design right was significantly cheaper than fixing it later, because "later" in a deployed transport system means retrofitting across hundreds of physical locations.

There were ideas I proposed that didn't survive the decision-making process. I want to be careful not to rewrite history in my favour. I'm describing this with twenty years of hindsight, and hindsight has a way of making the ignored correct and the deciders obtuse. The people who pushed back had reasons. Cost. Schedule. The limits of what technology could reliably do at scale in 2001.

One persistent debate: what should the system do gracefully versus refuse? I had views about failure modes — how gates behave when the back-office connection degrades, the risk profile of different offline scenarios, what a fraud vector actually looks like when you think through the economics. A colleague, Sanderson, disagreed. Not from carelessness. He had a different mental model of which failure modes were plausible in practice versus theoretical. We were both reasoning from incomplete information, as you always are in design.

His view carried the room on several points.

Here's the problem with being right without being heard: **visibility is part of correctness.** If I argued for something and nobody listened and the thing turned out to be correct, what does my correctness mean? The system encountered the edge cases I'd flagged. Some were handled well. Some required workarounds later. None catastrophic. But predictable, and predicted.

What's interesting, in retrospect, is not the vindication. Being right is not instructive on its own. What's interesting is the question of why the correct argument didn't carry. And the honest answer: "correct" is only one component of a decision. There's political capital, schedule pressure, the limits of what people can absorb in real time, who says something and when they say it — whether your point lands before or after the group has already been primed in a direction.

This matters in research too. An unread paper is an unpublished paper, from a certain angle. An issue closed as "works as intended" when it's actually a bug is just a bug no one fixed. The feedback loop — the thing that tells you if you were right — can be silenced by inattention, by process, by the structure of communication itself.

Sanderson was a competent engineer doing a difficult job under real constraints. I don't think he was wrong to push back. He had a different model. That's normal in technical design. Not heroes and villains.

The system still operates. It's been extended in ways nobody on the original project imagined. The contactless bank card integration transformed how it works, and that happened long after my involvement ended.

The lesson is quiet: if you design something that outlasts your involvement, used by people who've never heard your name, you get to notice silently, occasionally, that something you argued for turned out correct. But you don't get credit for it, and maybe that's fine. Maybe the design isn't about you. Maybe the correctness of your ideas isn't about vindication, it's about whether, somewhere, the system behaves the way you said it should.

I'm still not sure how to know if you're right before the people who can act on it decide to listen.