An architecture record marked Accepted
means we decided, not it runs

Architecture decision records are one of the better habits a technology organisation can build. They capture why, they survive the people who wrote them, and they keep a team from relitigating the same choice every eighteen months. They also carry a status field, and that status field is where the trouble lives. Accepted means the decision was made. It says nothing whatsoever about whether the thing runs.

Those two states look identical in a document and are completely different in production. If you only ever read the document, you can't tell them apart.

Three capabilities, 30 August 2026

I was preparing a write-up of what a system could do. Three capabilities were on the list and each one was about to be described as working. Checking them individually took under an hour and none of the three survived it.

The first was a payments path. Real integration, real code, real credentials. In test mode. No customer money had ever moved through it, and the difference between test mode and live mode is not a detail you discover gracefully in front of a buyer.

The second was a CRM integration. The code was written and reviewed. The account signup was still pending, so there was nothing on the other end of it.

The middle case is the dangerous one

The third was a model gateway, and it's the one worth dwelling on. It was genuinely live in one service, routing real traffic. In another service it existed as an opt-in that nobody had opted into. Same component, two different maturities, and one sentence in the write-up covering both.

That sentence wasn't false. It was true about one service and aspirational about the other, and there's no way to read it and know which. Partial deployment is the state that documentation handles worst, because a document describes a component and reality attaches maturity to a call site. A diagram has one box for the gateway. Production has two answers.

The check is never the document

What separates decided from running is always the same three things, and none of them live in a repository of markdown. A live call site, meaning something in production actually invokes the path, not that the path exists. A running process, meaning the container is up right now, not that a deployment manifest mentions it. And a real credential against a real account, in the mode you intend to operate in.

I found the same gap a different way earlier this year: a deployed workflow had silently drifted from what was in git, because its directory was untracked. The status table had a green check on it. What found the drift was running the thing, not reading the row.

Why this bites hardest before a board meeting

A CTO reading their own architecture documents the week before a board meeting is doing exactly the right thing and is in the worst possible position to catch this. The documents are accurate about decisions. The question being asked is about capability. The translation between those two happens silently, in the reader's head, usually under time pressure, and it always translates in the optimistic direction.

The fix is unglamorous. Add a second field next to the decision status, recording what was last observed running and when. Not a plan, not a target. An observation with a date on it. Then a stale field is visible as staleness rather than passing for currency.

Where this shows up commercially

This is close to the work I do in technical diligence, where the gap between an architecture document and an operating system is often the single most expensive thing in the room. If that's the position you're in, on either side of a deal, that's what the private equity page is about.

For everyone else the habit stands on its own. Before you describe a capability to anyone who'll act on it, go and watch it run once.

Sources: The three capabilities checked on 30 August 2026 (a payments path in test mode, a model gateway live in one service and opt-in in another, a CRM integration pending account signup) are from this project's own pre-publication verification pass. The deployed workflow that had drifted from git while its status row showed a green check is recorded in docs/research/NLT-TECH-SUBSTANCE-INVENTORY.md §2.3 in this repo.