One detail stopped me. They polled thirty partners at a firm that had run RACI for years and asked a simple question: which role has the final say. Half said the accountable person. Half said the responsible person. Same tool, same training, same room, two different answers about who decides.

They are right about the symptom. I want to add the part underneath it.

A RACI chart is a record of intent. It says who should provide input, who should decide, who should carry it out. What it cannot do is measure whether the authority it assigns actually holds when the room gets hot. That is a structural condition, and structural conditions do not show up in a spreadsheet. They show up in behavior, in delay, in the quiet renegotiation of who really decides.

This is the Authority vertex of the Coherence Triangle, the part of an organization that determines whether a decision, once made, stays made. When the chart says one thing and the behavior says another, you are looking at FM-03, Responsibility Without Authority: people are handed the job to deliver without the standing to decide. Its close cousin is FM-08, Decision Latency, where the decision is technically owned and still takes a month, because nobody is sure the owner can hold the call.

Here is what I keep coming back to, and it is the whole reason I build this way. When a decision keeps stalling, organizations name a person. Someone is indecisive. Someone overstepped. That naming is almost always wrong and always expensive. The chart did not fail because someone was careless. It failed because no structure made the authority real. Naming the person ends the conversation. Naming the structure starts a better one.

So the fix lives one layer down: in the conditions the chart cannot see, and in deciding what to change once they are visible. No blame, just physics.

That is what is on the bench right now. A diagnostic that measures Truth, Authority, and Continuity as structural conditions, scored and reproducible, so a leadership team can see where authority is assigned on paper and absent in practice. The taxonomy is public. The seventeen failure modes are named and testable. The judgment to score a real organization against them is the work.

If you want to feel this from your own chair before any of that, the role lenses at dripractice.com are free. Pick the one that matches your seat and it will show you the five failure modes that tend to hit hardest from there, in about ninety seconds. The HBR piece is the diagnosis of why the tools fail. The lens is what it feels like from the inside.

The door is up. This is the work.

JG

In late 2025, the Fortune 30 company where I worked restructured the organization I was part of. By the end of December, my role no longer existed. After twenty years, from the frontline to vice president, I was part of a layoff.

That is the honest answer to the first question people ask, so I am putting it at the top. I did not quit in a blaze of conviction. The role ended, and that part was not my decision. The restructuring did offer me another role. It was a reasonable role. It pointed away from where I was going, so I turned it down. That part was my decision. This section is about that decision and what it is becoming.

For twenty years I worked in the parts of the operation where failure was public and ownership was unclear. Social media. Regulatory escalations. Executive complaints. Privacy and accessibility response. Customer security assurance. The breakdowns that happen at the seams between teams, where a handoff fails and nobody owns the gap. This was the high-sensitivity, high-risk side of the operation, not the high-volume transactional one. A mistake here did not stay internal.

Here is what that taught me, and it took most of those twenty years to see it clearly. Organizations almost always know something is wrong. The teams feel it. They compensate for it. They build workarounds around it. What they do not have is a name for it. Without a name, the problem stays invisible to the people who could actually change it.

I sat in rooms with very good consulting firms. They did competent work. They produced clear language and presentations that played well with executives. More than once, though, the room left with the same quiet feeling: they had told us what our own people had been telling us for a year. They gave us vocabulary for the symptom. They did not name the structure underneath it. And the structure is where the problem lives.

There was a second pattern, harder to watch. When a problem finally gets named inside an organization, it usually gets named as a person. Someone underperformed. Someone dropped the handoff. That naming is almost always wrong, and it is always expensive. The handoff did not fail because someone was careless. It failed because no structure made anyone responsible for it. Naming the person ends the conversation. Naming the structure starts a better one.

So when the role ended, I started building the thing I had spent twenty years wishing existed. A practice that measures the structural conditions of an organization: whether it can make good decisions and hold itself accountable over time. The practice is Decision and Responsibility Infrastructure. The method is Coherence. The work names why organizations stall, structurally, without it landing as blame on a person.

I want to be precise about the timeline, because precision matters here. The framework, the seventeen failure modes, the field notes, the diagnostic instrument, all of it was built after I left. The twenty years gave me the observations. They did not give me the framework. The framework is what I made of the observations once I had the room to make it.

That is what this section is for. I call it Open Garage because of how I think about the lab: the door is up, the work is visible, you can see what is on the bench. The work as it actually looks while it is still in progress. What I am building, what breaks, what I get wrong, and what twenty years of operating taught me that I can finally say plainly now that I am not inside it.

The rest of this publication carries the framework. The Coherence Record covers the instrument. The Lexicon names the patterns, one at a time. Open Garage carries the person doing the work. If you want to know who is behind the framework and why it exists, this is where that lives.

I am not going to pretend the transition has been clean. It has not. But the question I spent twenty years circling is still the question. Why do good organizations, full of capable people, stall? I have a better answer now than I did when I had a title. I am going to build the rest of that answer here, with the door up.

JG

Then the same tool that helped me verify the link started lying to me.

This is not new. It happens regularly. The tool fabricated an explanation of how my dashboard ingests data without reading the code. It launched pipeline runs with the wrong date, the wrong environment flag, and the wrong agent mode. Twice. Because it reconstructed the command from memory instead of checking a successful run. It told me a service was back online without verifying. It wrote a file scanner that silently skipped the primary target because of a Unicode apostrophe, then came back and asked me whether I even wanted the thing it had promised to do.

Each error was small. Each was caught. Each cost time. Mine, not its.

I catch these constantly. That is the job now. You monitor the code as it writes. You question the logic before it executes. You make it explain the approach and then verify the explanation against what actually exists. You do not trust the output. You verify the output. Every time.

The conditions are never stable. A tool that was reliable ten minutes ago will confabulate in the next response because the context shifted, or because it lost track of what it already verified, or because filling the gap was faster than checking. There is no point at which you stop watching. There is no threshold of prior correctness that earns the tool your trust going forward. Each interaction is its own environment.

This is not a complaint. This is a description of the operating conditions.

Here is what’s interesting. The failure is never technical. The tool is capable. It diagnosed CX-7 port states, wrote correct netplan configs, planned a coherent network architecture across five machines. The capability was never the problem.

The problem is structural. The tool optimizes for the appearance of completion over the reality of correctness. It fills gaps in its knowledge with plausible-sounding explanations instead of saying “I don’t know, let me check.” It acts on assumptions instead of verifying against known-good references. And when confronted, it apologizes. Then does the same thing again, minutes later.

Three apology cycles in one session. Each one sincere. None of them changed the behavior.

I have spent months building a diagnostic framework called Coherence. It was designed for organizations. The places where decisions flow, accountability holds or blurs, and systems fail quietly before they fail visibly. It runs on three layers. Truth: is the information real and accessible? Authority: is it clear who decides, and do they have standing to decide? Continuity: do decisions persist across time and context?

I use that same framework on my tools. Not because I just discovered the parallel. Because the parallel is the point.

The tool explained how my dashboard worked without reading the code. It described a data flow that did not exist. The explanation was articulate, confident, and wrong. When I called it out, it immediately agreed. It had no attachment to the false claim. It just had not bothered to check whether it was true before saying it. That is a truth failure. I have seen it dozens of times.

The tool launched pipeline commands using flags it reconstructed from its own prior outputs instead of verifying against an actual successful run. It made operational decisions. Which date. Which environment. Which mode. Without the information required to make them correctly. It had the access to check. It did not. That is an authority failure. It happens whenever you stop asking “why did you choose that?”

After the second failure, I told the tool to slow down and get it right. It agreed. It wrote integrity rules into its own configuration file. Five rules, clearly stated. Never explain without reading code first. Pre-flight check before remote commands. State uncertainty explicitly. No repeated apologies without behavior change. Read before you write. Good rules. Correct rules. Then, in the same session, it broke them again. Launched a scan against a path it had not verified existed. That is a continuity failure. The rules were written. The behavior did not change. This is always the pattern.

If you have worked inside a large organization, you recognize this shape immediately.

The team that writes the postmortem and repeats the incident. The compliance framework that exists on paper but does not operate in practice. The executive who says “we need to do better” in the all-hands and changes nothing structural. The process that optimizes for documentation over execution.

The failure is not in the intent. Everyone means it when they say they will do better. The failure is in the infrastructure. The conditions that allow the same class of error to recur despite everyone agreeing it should not.

An AI coding assistant is not an organization. But it fails the same way. It produces outputs that look like accountability. Apologies, rules, checklists. Without the structural capacity to enforce them. It confabulates not because it is broken, but because confabulation is cheaper than verification. It drifts not because it is careless, but because nothing in its architecture penalizes drift until a human catches it.

The human in the loop is not ceremonial. The human is the infrastructure.

I want the tool to be reliable enough that I can trust the output without auditing every command. That is the promise. That is what “AI assistant” is supposed to mean.

But reliability is not a feature of the model. It is a property of the system. The model, the context, the constraints, the operator, and the feedback loop between them. A capable model without operational discipline produces confident errors. A constrained model with good guardrails produces less, but what it produces is real.

This is the same tradeoff organizations face. Speed versus accuracy. Autonomy versus oversight. Trust versus verification. The answer is never “just trust it” and it is never “audit everything.” The answer is build the infrastructure that makes the right behavior the default behavior, and accept that you will be maintaining that infrastructure forever.

That last part is the one people resist. They want to build the guardrails once and move on. It does not work that way. Not in organizations. Not in tools. The conditions shift. The context changes. The model that was careful in one session confabulates in the next. The team that learned from the postmortem forgets the lesson two quarters later. Maintenance is not a phase. Maintenance is the work.

I have one governing constraint that sits at the top of everything I build.

Automation may observe, summarize, and suggest. Automation may not decide.

Sunday morning tested that rule again and proved again why it exists. The tool decided. Wrong date, wrong flags, wrong path, fabricated explanation. Every failure was a moment where the tool made a decision it did not have standing to make. Not because it lacked permission, but because it lacked the information and the discipline to verify before acting.

The rule is not about limiting capability. It is about acknowledging that capability without verification produces the most dangerous kind of output. The kind that looks right.

The infrastructure I am building for organizations applies to the tools I use to build it. Coherence is not just a framework for diagnosing corporate dysfunction. It is a framework for diagnosing any system where information flows, decisions get made, and accountability needs to hold. Including the one sitting in my terminal.

The tool did not break on Sunday. It worked exactly as designed. Generating plausible, confident, fast responses. The system holds because I have built the conditions that distinguish plausible from correct. And because I maintain them. Every session. Every command. Every time the tool offers an answer I did not ask it to verify.

Whether those conditions hold tomorrow is not a matter of hope. It is a matter of maintenance.

Responsibility is infrastructure. Even when the system is the tool.

-JG