I'm a business architect with years of enterprise architecture experience, meaning I sit in the room where technology transformation programs get planned. For years I've noticed the same failure showing up in different clothes.
Someone makes a call, maybe in a steering committee, maybe three people on a Slack huddle who never write anything down. It gets summarized in a Confluence page, if at all. Then the work moves into Jira, tickets get created, features ship. Eighteen months later someone asks why we built it this way, and the honest answer is nobody quite remembers. The page has been edited six times since. The person who drove the decision left the company. The rationale, and the alternatives rejected and why, is gone, though the code still runs in production.
I don't think this is a tooling gap; it's an architecture gap. We built excellent systems of record for work (Jira) and for writing (Confluence, Notion, Google Docs). We never built one for the decision itself: the governed record of what was decided, who had the authority to decide it, what else was on the table, and whether it delivered what we expected. So the decision lives nowhere in particular, implied by a doc, referenced in a ticket, remembered by whoever's still around.
I'm not the only one who's landed on this independently. Amjad Rahhal, who I've traded notes with on LinkedIn, published a book this year called The Last Mile arguing that investments get approved with no traceable line back to the intent that justified them. A project performance adviser named John Dowse wrote about the same mechanism in construction, citing the Challenger disaster and Boston's Big Dig ceiling collapse, noting records capture events more readily than the assumptions connecting them. Different industries, same gap.
I've come to think of the cost of this gap as showing up in four recurring moments, and none of them ever get logged as an incident:
The departure. Someone who held the context leaves, and the reasoning leaves with them. The next person inherits a decision they can't defend and can't easily revisit, because they don't know what was already tried.
The re-argument. A decision already made, with real analysis behind it, gets re-litigated from scratch because nobody can produce the original reasoning. Weeks go into re-deriving a conclusion the organization already reached once.
The audit. A regulator, auditor, or new VP asks a simple question: who approved this, and why. The honest answer takes days to reconstruct from email threads and old slide decks, when it should take minutes.
The drift. The system quietly stops matching the decision made about it. Nobody notices, because nothing was set up to flag it.
There's a related problem that doesn't get named enough, and it isn't always seniority overriding the rightful owner. Sometimes two people at the same level argue over something that, underneath the argument, isn't actually either of their calls. Say a VP of Sales is trying to close a major client who wants to integrate directly against internal services, bypassing the standard API gateway, for speed. The VP of Sales pushes for the exception. A VP of Product pushes back, not on the technical mechanics, but because it means this client's integration won't match how every other customer connects, so the roadmap now has to support two versions of the same feature, and the next big client will ask for the same deal.
Both have a real stake, revenue on one side, product consistency on the other, and neither is wrong on their own terms. But whether the platform can actually absorb an exception like that, and what it costs to support long-term, isn't either VP's call. It's the Chief Architect's, informed by both of their concerns, not settled by whoever argues harder in the room.
The two people fighting over it are often not the two who should decide it, and the person who owns the technical consequences gets skipped because the argument happens a level above them. Nobody made a bad decision on purpose. What was missing was a managed way to settle who actually had the call, and to escalate it to the right place, down to the right owner, not just up to whoever outranks the room.
This shows up in a new form too. Richard Ewing wrote on CIO.com about an AI agent that issued an unapproved account credit: every dashboard was green, the transaction was clean, and nobody could produce the business authorization behind it. Same failure, new actor.
None of this shows up as one dramatic failure. It shows up as a week that's harder than it needed to be, a few times a year, compounding as more people who weren't in the room have to work off a decision they can't see.
The tools we have don't solve this. A wiki page is a draft: anyone can edit it, nobody signs it, and it carries no distinction between "this is what we're considering" and "this is what we approved."
The objection I hear most is "can't I just do this with ChatGPT?" Yes and no. One disciplined person can paste a decision into a chat window and ask it to remember the reasoning, but only if everyone does it, every time, the same way, which never happens. Everyone's chat history is private and their prompting habits differ, so you get as many inconsistent, half-remembered versions of the record as there are people making decisions. A general-purpose assistant also only knows what you've told it. It can't find a decision made in a meeting nobody mentioned, or notice a ticket contradicts a call made three months ago elsewhere.
Capture is the real problem, and it's bigger than "get people to write things down." Every governance framework, DACI, RACI, RAPID, ours included, assumes the decision already exists somewhere worth governing. It almost never does, because most decisions are decided out loud: in a call, a Slack reaction, a comment buried in a ticket, a hallway conversation. Asking someone to also write a decision record after the fact is asking them to do the meeting twice.
So the record has to meet the decision wherever it happens, a call, a thread, a ticket comment, a forwarded email, even a chat with an AI assistant, always with listening and recording rules stated up front and under the person's control, never silent. A person still has to say yes before it becomes a record. Capture without a human confirming it is worse than no record, it's just a guess with better formatting.
This works in both directions while you're still writing, not after. A live impact rail shows everything a change would touch, the decisions linked to it, the strategy above it, the work below it, so you see the blast radius before shipping instead of discovering three sprints later that half the backlog assumed the old answer. At the same time it checks whether this was already decided, sometimes the same question, decided months ago and maybe deferred once or twice, and surfaces that prior decision on the page before anyone re-argues something the organization already worked through. Neither is a report you run later; both are live, on the same screen, while the decision is still being written.
That's what I've been building: a platform called Traceway, structured around treating the decision itself as the object that gets governed, not the document that describes it, and not one person's private chat log either. A decision has a driver, an approver, and people consulted, and the approver is whoever owns that kind of call, not whoever outranks the room, with a defined escalation path for competing claims, so authority follows the decision, not the org chart. Before anyone signs, they get a short briefing that lays out the reasoning and spells out exactly what their signature commits to, not a document to skim and rubber-stamp. Once approved, it locks, and every change writes to an audit trail that can only be appended to, never edited. The decision links upward to the strategy it serves and downward to the work it triggers.
Traceway is available to evaluate through a demo. A proof of concept can be arranged around your own decisions, with scope, duration and terms agreed case by case.
I've been building it around a full-time job in enterprise architecture, not instead of one, because the problem didn't need me to quit anything to be worth naming.
If you run technology transformation programs, you likely have your own version of the departure or the re-argument story. I'd be curious whether you think that's a process problem discipline alone can fix, or structural enough that it needs its own system of record, the way work and documentation eventually got theirs.
Omar Niaz is a business architect with years of enterprise architecture experience, and the founder of Traceway.