Evaluating Graph Fit

You can now name the parts of a graph and interrogate what an edge actually claims. The next question is harder and more political: does this initiative deserve a graph perspective at all? Most graph proposals fail not because the technology disappoints but because nobody asked which connected question was being answered, or who would still be maintaining the relationships eighteen months later.

In this lesson, you will learn to:

• Name the six connected use cases and the distinct question each one emphasizes.
• Recognize the five ways a graph initiative can fail even when its connected question is legitimate.
• Judge whether a graph perspective fits by probing a sponsor's proposal — naming the connected question, stating the simpler alternative, and defining the evidence that would earn wider scope — without killing a legitimate idea.

Connected work clusters into six recognizable patterns, and each emphasizes a different question:

• Lineage — where a value came from and what it flowed through.
• Dependency — what breaks downstream if one thing changes.
• 360-view — all the connected context around a single entity.
• Recommendation — what related items suit an entity based on its connections.
• Risk-network — how disruption propagates across connected parties.
• Impact — what downstream entities or decisions could be affected by a change.

These overlap enough that proposals routinely blend three of them without noticing. Dependency and impact are especially easy to conflate: dependency looks structurally at what is wired to what, while impact asks which decisions and consumers would actually feel a change. Risk-network is different again, because it cares about propagation through tiers rather than a single downstream step.

Naming the use case matters because it determines what evidence you need and how deep the graph must go. A 360-view rarely needs more than a node's immediate neighborhood; a risk-network question is usually uninformative unless it traverses several hops. When a sponsor cannot say which of the six they are chasing, that is your first diagnostic signal, not a detail to tidy later.

Assume the connected question is legitimate. The initiative can still collapse in five predictable ways:

• Over-modeling — the urge to connect everything at once (entities, contracts, geography, sentiment, weather), where each addition multiplies the relationships to define and defend and the first pass never survives it.
• Unstable identity — the failure you met in the last lesson, now at scale: if entity names arrive from several systems with no shared identifier, every path through the graph is built on unresolved nodes.
• Absent ownership — no domain is accountable for the entities or the relationships once the sponsoring program moves on, which turns a shared asset into an orphan within a year.
• Weak explainability — the graph produces a conclusion nobody can defend in a meeting; if a director cannot explain why an entity was flagged, the output has no decision value regardless of its accuracy.
• Maintenance drag — the cost of keeping thousands of relationships current as contracts, tenancies, and assignments change, work that is invisible in the business case and unfunded in year two.

The exchange below is between Marcus, a product lead pitching an ambitious customer-360 initiative, and Natalie, the senior data steward he brings the proposed scope to.

• Marcus: The 360 view is scoped. Customers, households, accounts, devices, support tickets, plus marketing events and social signals.
• Natalie: Which of those does the first question actually need? You described understanding why a high-value customer is about to churn.
• Marcus: All of them eventually. We'll reconcile the duplicate customer records as we go.
• Natalie: Say the graph surfaces a churn-risk customer next quarter. Who explains to the retention team why it was surfaced, and who keeps the account-to-device links current after launch?
• Marcus: Success would explain it, I think. The upkeep, honestly, I don't have a name for that.
• Natalie: That's the one I'd rather solve before the scope grows, not after.

Notice that Natalie never argued the idea was wrong. She tested scope, explainability, and maintenance separately, and let the gap surface in Marcus's own answer.

The fit question is not "is this connected?" Almost everything is connected. It is whether the decision genuinely turns on relationship depth — or on relationship semantics a simpler view can't hold — that a simpler view would obscure. A question answered at one hop, answered by an existing hierarchy, or answered by a well-defined glossary term is often a sign that a graph perspective would add cost without adding insight, but that sign is not automatic. Depth alone is the wrong test: a one-hop question can still need a graph if the relationship types involved shift constantly, or if the answer depends on a shared, governed vocabulary that a simpler structure has no way to guarantee. The test is comparative, not arithmetic — ask whether a simpler, already-available view would serve this specific decision equally well, not how many hops separate the nodes.

A defensible fit judgment therefore does four things:

1. It names the single connected question the initiative should be tested against first.
2. It states the simpler conceptual alternative honestly, usually a narrow relationship map covering two or three entity types rather than twelve, and asks directly whether that alternative would serve the decision equally well.
3. It applies the connected-claim trust test to the relationship claims that matter most, checking source, confidence, and whether the proposed use is appropriate.
4. It names the evidence that would justify expanding beyond the narrow version.

That last point is what keeps this from being obstruction. "Narrow first" is only credible if you say what would earn the broader scope.

The insight to carry: a graph perspective earns its place by comparison — whether it serves a specific decision better than the simplest available alternative — not by hop count alone, and not by the richness of the picture it could theoretically draw. Next you'll do two quick checks on failure modes and use-case questions, then hold a live conversation with a sponsor who arrived expecting your endorsement, where the skill is probing a proposal hard enough to bound it without killing a legitimate question.