Alexander Arvidsson

Most organizations have a risk acceptance process on paper. What they actually have is hallway conversations and comment threads that vanish when projects close. When something breaks, everyone reconstructs who knew what from memory, under pressure, with lawyers involved. Aviation solved this problem decades ago with the MEL. The framework forces explicit conditions, named owners, and real expiry dates. Security work has similar machinery. We just let it collect dust while risks drift between teams unowned.

Back in 2015, I was debugging a SQL Server cluster that worked perfectly. Except when it didn’t. Connections timed out randomly, failovers failed silently, and nothing made sense. I was sure it was DNS. It was DNS. But that wasn’t the real problem. The real problem was me, seeing exactly what I expected to see instead of what was actually there. Turns out, pilots and DBAs have something important in common: expectation bias can really mess you up.

You did the hard work. Found the buried metric, rebuilt the report, put the lever in the top-left tile. The meeting went beautifully. Everyone nodded. Then nothing changed. Here’s what I keep relearning: a lever is not a mechanism. It’s a person with a calendar, a bonus structure, and reasons to leave things exactly as they are. Most reports die in the gap between who requested them and who has to work differently on Monday.

Every student pilot learns this the hard way: staring at the altimeter won’t fix your altitude. It’s a readout, not a control. Your dashboards have the same problem. Most of the metrics sitting at top left are gauges, things people can only watch. The actual levers, the numbers someone could move on Monday morning, are buried three clicks deep rendered in grey font. Three questions tell you which is which. The answer is usually uncomfortable.

Software versioning is solved. Ontology versioning isn’t. When you change what counts as an ‘active customer,’ that’s not a schema migration with a clear notion of correctness. It’s a contested definition where reasonable people can land in different places. Fabric IQ gives you the artifact, but it doesn’t ship the governance workflow. That part you build yourself. This post digs into what running layered ontologies actually takes, and why the organizational problem matters more than the technical one.

A sharp LinkedIn critique argues declared ontologies are broken by design. Model your business formally, and by the time you’re done, it’s already changed underneath you. The proposed fix: let structure emerge from data instead of declaring it upfront. It’s a compelling pitch, but I think it misdiagnoses the problem. Ontology drift isn’t evidence that formalization failed. It’s evidence we failed to separate what should be stable from what shouldn’t. The real answer might be simpler than either camp admits.

I said my rituals are for me, not the audience. That’s technically true. But a ritual that changes your internal state doesn’t keep that change contained. It shows up in your posture, your pace, whether your eyes land on people or drift past them. When your body says one thing while your words say another, the audience isn’t hearing confidence. They’re hearing the gap. That costs you trust and attention, and the science on why got interesting.

You built the pipeline everyone recommends. One model drafts, another reviews. Two sets of eyes. Except your reviewer is a language model, and language models can be argued out of a position by nothing more than a confident counter-argument. No payload to catch. No injection required. Just a wrong document in your retrieval set making a fluent case. The verdict flips, the badge says ‘reviewed,’ and everyone downstream stops looking. You added a laundering step.