Sooner or later, any tool that manages data for several clients, projects or teams runs into the same problem: how do you cleanly isolate everyone's data while reusing what already exists, without ending up duplicating everything?
That is exactly the problem we ran into at Graphicient. The solution we built, a mechanism we call context inheritance, illustrates a principle that goes well beyond our own case. Here is how it works, why it was needed, and what it changes in practice.
The problem: silos too expensive to duplicate
In Graphicient, every “context” is a fully isolated workspace. It has its own nodes (the pieces of information), its own links between those nodes, and its own content defining what those elements represent. This separation is deliberate: it guarantees that one client's or project's data never mixes with another's.
The problem appears as soon as you want a variant of an existing context. Take a case from a real industrial deployment: a large-scale manufacturing bill of materials, describing part by part how a complex product is assembled. A single context of this kind can hold tens of millions of nodes and links.
Now imagine a plant needs a variant of that bill of materials: the same base parts, with a few adjustments specific to its production line. Before inheritance, the only option was to duplicate the original context in full. A seemingly simple approach that hid two serious problems.
The second problem breaks nothing overnight, but over time it erodes the trust you can place in your own data. We needed a way to create variants of a context without ever copying the parent's data. That is what inheritance does.
The solution: see the parent's data, never copy it
The core idea is simple: you create a “child” context from a “parent” context. Once that link exists, the child automatically sees all of its parent's data, exactly as if it were its own, without a single node or link being physically duplicated.
Back to our industrial bill of materials: the plant creates a child context attached to the parent context and its millions of nodes. The child starts with near-zero storage weight: it only holds the few adjustments specific to the plant, yet it “sees” all of the parent's data.
The clearest image is a family inheritance. What the grandfather owns is seen by the father, who can add his own assets before passing everything on to the son, without anything ever being copied from one generation to the next.
A context can have a parent, which itself has a parent, and so on. At any moment, a context knows its full lineage up to the root, and that entire lineage determines what it can see and use. This lets you build real trees of variants: a generic root context, intermediate contexts per product family, then contexts specific to one client or plant, each carrying only what is its own.
Two ways to inherit, depending on the type of data
Inheritance doesn't work the same way for the graph's elements (nodes and links) and for the configuration that defines them. These are two different logics, and it was better to separate them clearly than to force a single rule to cover both.
Nodes and links: everything adds up
For the millions of concrete elements that make up the graph, the rule is as simple as it gets: a context sees its own, plus those of all its ancestors. Nothing overrides anything, everything accumulates. Querying one context amounts to querying its whole lineage at once and receiving the sum of the results.
The plant's context sees the parent's millions of nodes, plus the few dozen or hundred nodes it added itself. No conflict is possible: the parent brings its own, the child adds its own.
Configuration: the parent is always right
A child context also carries its parent's entire configuration: the ontology (node types, their attributes and structure), reference data, business rules and even confidentiality settings. Everything is passed down without copying, simply read through the lineage.
But here the rule is stricter: a child can never modify an inherited configuration element, whatever its level in the hierarchy. It remains free to define anything nobody above it has defined yet: its own node types, rules and attributes. But as soon as an element exists somewhere in its lineage, that version prevails.
Why this choice? Because the parent is the source of truth for everything it has defined. Without this rule, each context could maintain its own version of the same concept, or worse, locally relax a confidentiality rule set higher up. We would be right back to the original problem.
The result is never frozen: it is recomputed on every query. If a parent changes a type, a rule or a confidentiality setting, all of its descendants see the change immediately. There is no copy to synchronise, because there never was a copy.
What it changes in practice
Taken together, these mechanisms profoundly change how data can be managed at scale in a multi-context system.
- +Controlled storage. Creating a variant no longer costs a full reproduction of its data, only what it actually adds.
- +A single source of truth. No more copies silently drifting apart: changing the parent instantly updates all descendants, with no sync to trigger.
- +Isolation intact. Inheritance doesn't break separation between clients or projects. A child inherits its parent's access rules without being able to relax them: a security level set upstream holds across the whole subtree.
- +A hierarchy over several generations. A generic common foundation, variations per family, very specific variants at the end of the chain, without ever reproducing the upper levels.
Limits to keep in mind
A mechanism this powerful comes with a few safeguards worth knowing before using it at scale.
A concrete example: extending the scope without breaking the thread
Back to the industrial bill of materials, this time from the point of view of business users who need to broaden what the graph covers. The root context, maintained by a central team, describes standard parts and their base ontology, but it isn't meant to anticipate everything. Rather than waiting for the central team to add every new need to the common foundation, each business team creates its own child context and extends it its own way.
A quality team needs to track non-conformities found on certain parts. An environment team wants to link each part to its carbon footprint and certifications. Neither need exists in the root ontology: there is no “non-conformity”, no “certification”, no “impacts” or “certified by” relationship.
The quality team adds a “Non-conformity” node label and a “found on” link label, which it connects directly to the existing parts of the root context. The environment team does the same with “Certification” and “certified by”, or “Carbon footprint” and “impacts”. Since these labels exist nowhere in their lineage, nothing prevents creating them locally.
Each team extends the graph in its own direction, without touching the root context and without duplicating the millions of parts described upstream: it simply hooks onto them.
This is what creates true digital continuity. A part remains one and the same entity, whether viewed from the root context, the quality context or the environment context. The day the central team fixes a bill-of-materials error, the fix propagates everywhere, including into each team's extensions.
A principle broader than one use case
This mechanism answers a tension found in countless systems that manage data at several scales: how do you reuse what exists without duplicating it, while keeping the ability to customise locally? The answer here, accumulate factual data but leave rule definitions to the most upstream source, applies well beyond a graph of nodes and links.
Good data architecture isn't just about storing information, but about deciding upfront who has the final say on what, and how that decision propagates without human intervention. Multi-tenant software, product configuration management or a knowledge base shared across teams: the question stays the same. What must be common to all, what stays specific to each, and what happens the day one side changes its mind?
Context inheritance is therefore more than a trick to save storage. It is a way to set, once and for all, a clear hierarchy of trust between data, and to let that hierarchy do the work, invisibly, every time data is queried or a new use is grafted onto it.