The Five Diagnostic Dimensions

How a system fails — not what it produces. Every Entrowise diagnosis begins by placing a problem in one of five dimensions. They are not categories of measurement. They are categories of failure. That single choice, organizing around how delivery systems break rather than what they should produce, is the reason a diagnosis leads to a cause instead of stopping at a score.

Most delivery frameworks are built around outcomes. Value, flow, quality, speed. They measure where a system is, compare it to where it should be, and report the gap as a score. The Entrowise model is built around something different: the distinct ways a delivery system comes apart. Each of the five dimensions names a class of failure, and naming the failure is already the first move of a diagnosis.

Five Ways a Delivery System Breaks

Each dimension targets a distinct class of failure. The full set of principles within each one lives in the Principles Library.

01 — Flow & Delivery Dynamics

How work stops moving. Where work enters, moves through, and exits the system. Violations produce long lead times, unpredictability, firefighting, and release instability. When delivery slows for reasons no one can quite point to, the breakdown usually lives here.

System Question: How efficiently and predictably does value move through the system?

02 — Learning, Adaptation & Decision Quality

How the system fails to learn, or learns and fails to act. How the organization forms beliefs, tests them, and changes direction on evidence. Violations produce output without impact, strategy drift, false confidence, and metrics disconnected from reality.

System Question: Is the system capable of updating itself based on evidence?

03 — Governance, Accountability & Decision Authority

How ownership and authority come apart. How authority is structured, how accountability is assigned, and how decisions are made visible and traceable. Violations produce accountability fragmentation, governance ambiguity, escalation bottlenecks, and unsafe autonomy.

System Question: Who is allowed to decide, who is accountable, and how is control maintained?

04 — System Integrity & Architectural Coherence

How a system loses coherence as it changes. How systems hold together as they grow, accumulate change, and add components. Violations produce hidden dependencies, cascading failures, and an inability to explain or evolve the system safely.

System Question: Can the organization still understand, reason about, and safely evolve the system?

05 — Human-AI Collaboration Dynamics

How human and machine roles blur. Whether humans and agents reinforce each other or degrade each other. This territory does not exist in classical Agile, Lean, or Scrum. Violations produce human disengagement, blind trust in AI output, oversight collapse, and judgment atrophy.

System Question: Is AI augmenting human judgment, or replacing it prematurely?

The Outcome Lens vs. The Failure Lens

The same complaint, "delivery feels slow," enters each lens differently. One ends at a verdict. The other begins a diagnosis.

The Outcome Lens: Delivery feels slow. Lead time is up, throughput is down. The score turns red. The flow dimension scores low. The diagnosis still has to start from scratch — the score says that something is wrong but cannot say why.

The Failure Lens: Delivery feels slow. Which kind of stall — is work piling up faster than it finishes, or does only the cross-team deadline slip? Different stalls, different causes. The dimension narrows the field to candidate principles. Those principles point to the system condition the delivery has settled into. The diagnosis has somewhere to go.

An outcome lens measures the result. A failure lens reveals the mechanism.

Why the Distinction Matters

An outcome-based dimension names a property a healthy system should have, then scores the distance from it. The question underneath is always the same: how are we doing? The answer is a number or a maturity level. That is the language of dashboards, and it is useful for knowing that something is wrong and roughly how wrong. It says nothing about what in the system produced the result.

A failure-based dimension does something a score cannot. It names a way systems break, so the dimension itself carries diagnostic information. Choosing the failure family narrows the field of possible causes before a single principle is examined. Measurement and diagnosis are different activities, and an outcome dimension stops at exactly the point where the harder work begins.

An outcome tells you the system produced the wrong result. A failure tells you the system has the wrong behavior. Anyone can buy a dashboard that reports the first. A diagnosis is the second.

The Three-Layer Model: Dimension, Principle, USC

Each dimension opens onto two deeper layers. The dimension is the door: it identifies the class of failure in front of you. Inside each dimension sit the principles — specific cause-and-effect relationships that, when violated, produce the failure. Violate the principles long enough and the system settles into an Unintended System Condition: a stable, recurring state it now produces by default, such as Accountability Fragmentation or Customer Disconnect.

A symptom enters in dimension language. It narrows to candidate principles. Those point to the most likely condition the system has drifted into. That path — from a felt symptom to a named condition — is the diagnosis. The dimension is only the door, but the right room cannot be reached through the wrong one.

One Symptom, Two Different Failures

The clearest demonstration is a symptom an outcome model cannot resolve: a team that keeps building the wrong thing. Features ship, adoption stays flat, the intended value never lands.

Routes to Learning, Adaptation & Decision Quality: The system never validated direction. Feedback loops were too slow, increments too large, the understanding of value too stale. The team learned poorly and shipped against it. This is a learning-mechanism failure.

Routes to Governance, Accountability & Decision Authority: The team validated constantly and learned well, yet still built the wrong thing, because the person holding prioritization authority had incentives pointing elsewhere. This is an authority-mechanism failure wearing a value-misalignment costume.

Same presenting symptom. Two root-cause families. Two entirely different coaching conversations. An outcome model cannot make the split. A failure-based model makes the split on its own, because it is organized around the mechanism. Distinguishing which one is in play is the difference between a fix that holds and a fix that quietly fails.

Related Resources