A Report Is Not a Fact
A link reported as Connected was off-subnet and dead. The lesson is not about networking — it is about the difference between a report and a fact, and how that distinction governs the way this portfolio is built.
Earlier this week, at a site one of our operating companies looks after, a WAN link was found to be configured with one wrong digit in its gateway address. Off-subnet, unreachable, dead. The dashboard reported it as Connected, at a latency of one millisecond — the number a link returns when nothing is being measured at all.
Nothing alarmed, because a backup link silently carried the traffic. The failure was invisible for as long as nobody asked the equipment a harder question than the one the dashboard was asking.
We are writing it up at the parent level rather than leaving it with the operating company, because the lesson is not about networking. It is about the difference between a report and a fact, and that distinction governs how this portfolio is built.
None of the tools were broken
Every product involved reported exactly what it was designed to report. The monitoring platform checked whether the device answered. The dashboard displayed an interface status field. The management agent was healthy, because the machine it ran on was fine.
Good products, working correctly, producing an answer that was wrong.
That is not a vendor failure and we would not characterize it as one. It is the economics of building one integration that has to serve every customer. A vendor reads the handful of endpoints the average customer needs and stops, because that is the only rational place to stop when you are building one thing for everybody. The state that actually breaks things tends to sit a tier deeper than average.
The build-vs-buy line moved
For twenty years the answer to build-versus-buy in operational tooling was buy, and it was the right answer — not because purchased tools were better, but because the integration surface was where projects went to die. You would write a connector, the vendor would change their interface, and you would own that cost permanently.
That arithmetic has changed, and we do not think it has been widely repriced. The expensive part of integration was never writing the code. It was the discovery: reading undocumented interfaces, working out which tier holds the field you need, handling the authentication quirk nobody wrote down. That discovery cost has collapsed. Separately, vendors have begun shipping their own machine-readable integration surfaces, which means the connection is increasingly something a vendor maintains rather than something a customer reverse-engineers.
The line moved. It did not disappear, and we want to be careful about the version of this argument that says build everything — that version is written by people who have not operated anything.
Our position across the portfolio is narrow. Buy where the vendor's scale is the product: threat intelligence, patch catalogs, anything whose value is that thousands of customers feed it. Buy the commodity where our requirements are genuinely average, because they usually are. Buy anything that would otherwise require staffing a team to keep alive. Build in one place only — where the gap between what an interface permits and what a product surfaces is costing real money. That is a demanding test and most candidates fail it.
And a larger platform is not the escape hatch. An enterprise correlation platform, priced for organizations with a dedicated security operations function, would have ingested the same wrong answer. The status field said Connected; that is what gets indexed. Someone still has to know the reading is impossible and write the rule that says so. The heavier tool rarely removes the build. It relocates it, and prices it.
Why this is a governance matter
Holding deeper access than a vendor would grant is an obligation, not an achievement, and it is the reason our platform layer exists.
Every change our systems make follows one shape: proposed as a plan, verified independently before it runs, approved by a person, applied, then verified again afterward — because a success response means a call was accepted, not that the intended thing is true. Where a capability should not exist, we do not disable it behind a setting; the mechanism is not built, so it cannot be granted in a hurry at midnight by someone tired.
Fidenta, the platform our companies run on, is what performs that verification. Governance and our AI management system are what keep it controlled.
A dashboard reading Connected is a claim. Our operating principle is the same one we apply to our own systems, and it is the whole reason this incident is worth publishing rather than quietly fixing: never assume, verify.