Why graphs at all?
Browsing the use case library tells you what exists. The graph tells you how things connect. Two questions that browsing can't answer well, but the graph can:
- What's the impact of this single thing across the whole corpus? Pick one root cause — say, "Unassigned Cross-functional KPI Accountability" — and the graph shows every use case it touches, every value leak it drives, every enabler that addresses it, and every KPI it impacts. The same data exists in the corpus; the graph is what makes the pattern visible.
- What's the connecting tissue between things I care about? If you need to move OEE, the graph shows you the full chain from goal → KPI → use cases → value leaks → causes → enablers. You can see which enablers have the broadest reach, which causes are most pervasive, and where the leverage actually is.
Neither of those questions is something you can answer well from a list view, a search box, or a generic AI chat. They require a structured network of validated relationships, which is what this site has built.
The graph shape
The graph layout is intentional. Reading top-to-bottom, every graph follows the same flow:
Strategy at the top, mechanics at the bottom, the use case in the middle.
Goals at the top set strategic direction. KPIs measure progress toward those goals. Use cases are the things you actually do. Value leaks are gaps within use cases. Root causes drive the leaks. Enablers — people, process, technology, governance — address the causes. Reading top-down is "why we care." Reading bottom-up is "what we'd actually invest in."
Every chain converges on the use case that ties strategy to execution — that's the unit of work, and everything else is either upstream context or downstream mechanics. In a real contextual graph (centered on a single cause or enabler), the layout often takes on an hourglass shape: the corpus fans out wide at the top through goals, KPIs, and use cases, narrows at the focus node in the middle, then fans back out through causes and enablers below.
The seven node types
Each level of the hourglass is a different node type with its own color. The legend lives in the top-right of every graph view — but here's the quick reference:
Strategic Goal | Top-level business outcome (e.g., Operational Efficiency, Quality) |
L2 Goal | Sub-goal under a strategic goal |
KPI | Metric that tracks progress (OEE, FPY, MTBF, etc.) |
Use Case | The unit of work — what someone actually does |
Value Leak | A specific gap or weakness in current state |
Root Cause | Underlying reason a leak exists |
Enabler | Capability that addresses one or more causes |
Larger nodes (goals, use cases) are shown as labeled rectangles. Smaller nodes (KPIs, leaks, causes, enablers) are shown as colored dots — hover to see the label, click to dig in.
Edges: direction and influence
The arrows tell you which way the relationship flows. Goals point down to KPIs, KPIs point down to use cases, use cases point down to value leaks, leaks point down to causes, causes point down to enablers. Read with the arrows for why. Read against them for how to fix.
Edge thickness shows influence score. The relationships between value leaks and root causes, and between root causes and enablers, are scored 1–5 — how strongly the cause drives the leak, or how directly the enabler addresses the cause. Thicker lines mean stronger relationships. This isn't opinion; it's scored consistently across the entire corpus by the same model with the same prompt, so you're looking at a relative measure that means the same thing in every graph you open.
Six entry points: same network, different lens
You can enter the graph from any node type. The shape and behavior are the same — but the focus changes, and so does the question you're asking.
| Entry point | Question it answers | Best for |
|---|---|---|
| Use case | What's the full network around this specific use case? | Reading or sharing one use case in depth |
| Cause | Where else in the corpus does this cause show up? | Pattern recognition — same problem across departments |
| Enabler | Which use cases does this capability address? | Investment scoping — what would this enabler unlock? |
| KPI | Which use cases move this metric? | Building a portfolio around a specific KPI |
| Goal (L1 / L2) | What's the full chain from this strategic goal down? | Strategy-to-execution mapping |
| Value leak | What causes drive this gap, and what enablers address them? | Targeted root-cause analysis on one issue |
Click navigation: hop between graphs
Most nodes in a graph are themselves entry points.
In a use-case graph, click a root cause and you land on that cause's contextual graph — every UC across the corpus that shares it. Click an enabler and you see every use case that enabler addresses. Click a KPI and you see the network of use cases that move it. Each click is a re-frame: same data, new center of gravity.
Look for the "→ Click to explore" hint in the hover tooltip — that's the signal that a node is itself a navigable view.
The Focus slider: finding the spine
At full breadth (1), you see everything. At maximum focus (5), you see only the strongest signals.
The Focus slider in the top-left of every graph filters edges by influence score and prunes nodes that lose their connections. It's a lens for cutting through noise: what's the spine of this network when you only show the strongest validated relationships?
Practical use: open a noisy contextual graph at threshold 1 to get a sense of the full reach, then push to 4 or 5 to see the dominant patterns. The graph that shows up at the high end is the "you can't ignore this" view — the things the data says are most consequential.
A worked example
Suppose you're trying to figure out why your plant struggles with cross-functional ownership of metrics — KPIs get reported, but nobody owns moving them. Walking through the graph layer by layer:
- Start at the cause. Open the contextual graph for Unassigned Cross-functional KPI Accountability. You'll see every use case across the corpus where this cause shows up — not just within Quality, or just within OpEx, but everywhere.
- Tighten the focus. Push the slider to 4 or 5. The graph narrows to the use cases where this cause is most strongly connected. That's your priority list.
- Look at the enablers. The bottom of the graph shows the enablers that address this cause across the corpus. The most-connected enabler is going to be Cross-Functional Governance Structures — open it and you see the whole network of use cases that use this enabler.
- Pick a use case to act on. From either the cause graph or the enabler graph, click into a specific use case's knowledge graph to see the full implementation context — KPIs, stakeholders, value leaks, the full chain in one place.
Four clicks, three graph views, one coherent question answered: "What's causing my cross-functional accountability problem, what addresses it, and where do I start?" That sequence is what an AI chat can't produce — not because the model isn't capable, but because there's no structured network for it to query in the first place.
When to use which view
- Use the use case knowledge graph when you want the complete picture of one specific use case — its goals, KPIs, leaks, causes, enablers, and how they all connect.
- Use a cause or enabler graph when you want to see how broadly a problem or solution shows up across the corpus — "where else does this matter?"
- Use a KPI graph when you have a number you're trying to move and want to see all the use cases that affect it — your starting portfolio for that metric.
- Use a goal graph when you're building a strategy and want to see the full chain from a strategic objective down to specific actions.
- Use a value leak graph when you're doing root-cause analysis on a specific gap — what causes drive it, what enablers address it.
The takeaway
Other manufacturing resources give you content. The graph gives you context. It's the same underlying corpus you can read in the use case pages, but rendered in a way that lets you ask cross-cutting questions and follow influence chains across the network.
Open one. Click around. The intuition for what's here comes from using it more than from reading about it.