Derived relations expose multi-hop context in knowledge graphs

At a glance

What this is: This is a Collibra product post about derived relations, a capability for surfacing multi-hop relationships in a knowledge graph on asset pages.

Why it matters: It matters because governance teams often miss indirect context, and IAM, NHI, and AI oversight all depend on relationships that are not one hop away.

Context

Most governance platforms are good at showing direct relationships, but the harder problem is exposing the context that sits several hops away in a knowledge graph. When that context stays hidden, teams struggle to understand how assets, policies, and AI-related objects influence one another across the data estate.

Derived relations are Collibra's way of making indirect relationships queryable and visible on an asset page. The governance issue is not data absence but discovery friction, because the relevant connection already exists in the graph yet remains operationally invisible to users until it is modelled as a derived path.

Key questions

Q: How should teams use multi-hop relationships in a knowledge graph for governance decisions?

A: Use multi-hop relationships to surface the dependencies that matter for lineage, policy scope, and accountability, not just to make diagrams richer. The useful test is whether the path changes a review, approval, or classification decision. If it does, model it as governed metadata and expose it on the asset page where the decision happens.

Q: Why do direct lineage views fail for compliance and AI oversight?

A: Direct lineage only shows the nearest dependency, while compliance and AI oversight often depend on a chain of relationships that sits several hops away. If the governance context is not surfaced at the asset level, users have to reconstruct it manually and important links stay hidden.

Q: What breaks when indirect asset relationships are not surfaced in governance tools?

A: Reviewers lose the context they need to see which policies, lineage paths, or governance objects apply to an asset. That creates manual work, inconsistent interpretation, and weaker decisions because the relationship exists in the graph but not in the user workflow.

Q: Should teams prioritise lineage visibility or policy traceability first?

A: Prioritise the relationship that changes the most decisions first. In many programmes that means policy traceability for sensitive data, then lineage for critical assets, then AI governance paths where model accountability depends on indirect relationships.

Technical breakdown

How derived relations model multi-hop paths

Derived relations are configurable paths that connect a head asset type to a tail asset type through one or more direct or derived relations. The administrator defines the relation type, then specifies the path that the graph should traverse, including role and co-role naming for each direction. Because the path can fork and rejoin, the model can represent richer lineage patterns than a single explicit edge. A widget on the asset page then queries the graph and returns the assets at the end of that path, which turns a relationship definition into a reusable governance view.

Practical implication: model the relationship once, then reuse it wherever users need the same indirect context on an asset page.

Why direct lineage stops short

Traditional lineage is often point to point, which works for immediate dependencies but hides the deeper relationship chain that gives a data asset its meaning. In practice, users end up clicking through multiple objects or relying on diagrams to infer how a column, policy, model, or owner connects to the asset in front of them. Derived relations compress that search process by pulling distant context into a single view. That matters because governance decisions depend on the complete relationship set, not only the first hop that is easiest to display.

Practical implication: use derived views when the decision depends on indirect context that direct lineage alone cannot surface.

Why asset-type assignment changes visibility

A derived relation type does not appear everywhere automatically. It must be assigned to an asset type, which then adds the corresponding widget to the asset page and triggers the graph query at view time. That design keeps the surface area governed, because the relationship is exposed only where it is useful for a defined class of assets. The pattern is especially relevant for policy compliance and AI asset traceability, where the user needs to see a distant control, policy, or governance object without manually reconstructing the path each time.

Practical implication: tie each derived relation to the asset types that actually need the context, rather than exposing every path everywhere.

NHI Mgmt Group analysis

Derived relations solve a governance discovery problem, not a data modelling problem. The article is really about making hidden context usable at the point of decision. In governance programmes, the graph often already contains the relationship, but the user experience fails because the path is too indirect to find quickly. That means the control gap is operational visibility, not missing metadata, and the consequence is slower or weaker decisions about lineage, compliance, and AI oversight.

Multi-hop visibility is becoming a governance requirement, not an analytical luxury. As data estates expand, single-hop views stop being enough to support accountability across policy, lineage, and ownership. Collibra's derived relations point to a broader pattern in data governance: teams need curated relationship views that match how practitioners actually ask questions about assets. The practical conclusion is that governance design has to treat relationship discovery as a first-class function.

Policy compliance and AI traceability depend on relationship surfacing at the asset level. The most useful part of derived relations is that it brings distant governance context into the same workflow where the asset is being reviewed. That reduces the gap between governance intent and operational use, especially when a policy applies several hops away from the object a user is inspecting. Practitioners should treat multi-hop context as part of control visibility, not just reporting.

Business and technical lineage only become operational when the user can consume them without reconstruction. The article shows that lineage value is not created by the graph alone but by the ability to expose the relevant path on demand. This is a named concept worth retaining: multi-hop context visibility is the difference between having a connected graph and having a governable one. Teams that cannot surface it will continue to depend on manual interpretation.

AI governance will increasingly depend on indirect relationship modelling. The post's AI use case is important because model oversight rarely sits one step away from the object under review. If the lineage from an AI use case to a policy or governance artefact is hidden behind multiple hops, teams will miss the context needed for review and accountability. The implication is that AI governance programmes need relationship-aware asset views, not just inventories.

What this signals

Governance teams should expect relationship modelling to move closer to the point of use, because asset pages are becoming the place where indirect context must be consumed, not just stored. Multi-hop context visibility: when a graph can surface the right path on demand, stewardship, policy review, and AI oversight become more operational and less interpretive.

The practical shift is from documenting relationships for later analysis to exposing them for immediate review. That matters whenever the control decision depends on a policy, owner, or upstream dependency that is not visible in the first-hop lineage view.

For practitioners

• Map the indirect relationships that matter most Identify which policy, lineage, ownership, and AI traceability questions routinely require more than one hop of context, then model those paths explicitly so they can be queried from the asset page.
• Assign derived relations only to useful asset types Limit exposure to the asset types where the extra context changes governance decisions, so the widget appears where analysts, stewards, or reviewers actually need it.
• Standardise relation naming across the graph Use consistent role and co-role naming so users can read the relationship in both directions without having to infer what the path means from the widget alone.
• Prioritise compliance and AI review use cases first Start with the paths that surface policy applicability, lineage for sensitive assets, and traceability for AI models or AI use cases, because those are the contexts most likely to justify the additional modelling effort.

Key takeaways

• Derived relations address the visibility gap that appears when important governance context sits several hops away in a knowledge graph.
• The capability matters because policy review, lineage analysis, and AI oversight often depend on relationships that are not direct.
• Teams should model only the indirect paths that materially change governance decisions, then expose them where users actually review assets.

Key terms

• Derived Relation: A derived relation is an inferred connection that allows a platform to connect technical data sources to business-facing assets even when the link is not directly stored. It is useful for roll-up logic, but it must be validated carefully because inferred links can hide gaps if the underlying graph is incomplete.
• Multi-hop Context: Multi-hop context is the meaning carried by relationships that sit several steps away from the object you are reviewing. In governance work, it often determines whether a policy applies, who owns the dependency, or how a downstream asset is affected.
• Knowledge Graph: A knowledge graph is a data model that stores entities and the relationships between them instead of treating records as isolated rows. In security, it helps teams explain how identities, permissions, tokens, and resources connect, which is essential for understanding access paths and risk propagation across SaaS and NHI environments.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.