Role-Based Visibility and Semantic Views: Who Sees What in an Enterprise Knowledge Graph
In the earlier article on designing multi-tenant workspaces, we explored how organisations, workspaces and projects can structure an enterprise knowledge graph....
In the earlier article on designing multi-tenant workspaces, we explored how organisations, workspaces and projects can structure an enterprise knowledge graph. In the article on identity, provenance and context, we examined how facts and claims retain their meaning through sources, ownership and context.
The next implementation question connects both: which parts of that knowledge should each user be able to access, and how should those parts be presented?
Permissions determine what a user may access. Semantic views organise that authorised information for the task they need to perform. Keeping these responsibilities separate is central to the proposed SolidState Graph design.
One graph, different responsibilities
Consider XYZ Corp, where procurement, finance, legal and external suppliers work with overlapping information. A supplier may connect to contracts, invoices, subsidiaries, ownership claims and supporting documents. These connections belong to a shared knowledge model, but each team has different responsibilities.
Procurement needs to understand supplier relationships and approved contracts. Finance needs financial exposure and payment obligations. Legal may need ownership evidence, disputed claims and contractual restrictions. An external supplier should see only the information explicitly shared with it.
These are illustrative policies an organisation configures. A department name should not automatically grant access to every related record. A legal user assigned to one project, for example, may have no authority to inspect another project’s confidential evidence.
Access starts with the workspace
The organisation, workspace and project structure from the multi-tenant architecture article provides the starting point for access decisions.
The organisation establishes the tenant boundary. Workspaces group knowledge around teams or business areas. Projects narrow that context to a particular engagement, investigation or delivery activity. Membership establishes where a user can participate; permissions determine what they can do within that scope.
At XYZ Corp, a supplier assessment workspace might contain several procurement projects. Internal teams could participate across selected projects, while an external supplier receives access only to its own collaboration area.
Inheritance needs explicit rules. Joining a workspace should not silently expose every restricted project beneath it. Likewise, sharing an entity with a project should not automatically share all its relationships, claims or documents.
This is where the workspace architecture becomes an enforceable boundary around knowledge.
Roles alone are not enough
Roles provide a manageable starting point: viewer, contributor or workspace administrator. However, a role becomes meaningful only when combined with scope and the requested action.
A contributor in one project should not gain editing rights across the organisation. Someone allowed to read a contract may not be allowed to export it or change its access settings. Administrative responsibility for workspace configuration also needs an explicit policy on access to confidential content.
For SolidState Graph, the proposed access model should combine:
The initial implementation can keep the available roles small while making their scope precise. Unspecified access should be denied, and broader grants should not silently override explicit restrictions.
Protecting relationships and evidence
Graph permissions must account for the information carried by a connection.
A user may be allowed to see two companies without being allowed to see a confidential ownership claim connecting them. Similarly, access to a supplier does not imply access to an investigation involving that supplier.
This connects directly to the earlier discussion of identity, provenance and context. An entity, a claim about that entity and the evidence supporting the claim are distinct resources. Their access rules may differ.
For example, procurement might see an approved supplier status while legal can inspect the underlying ownership assessment. That separation is appropriate only if the organisation explicitly permits the status to be shared. A derived label can itself reveal sensitive information.
The system therefore needs access checks for relationships, claims, sensitive properties and supporting evidence, not simply a visibility setting on each node.
Semantic views organise authorised knowledge
Once permissions establish the accessible information, semantic views organise it around a task.
A procurement view might emphasise suppliers, approved contracts and delivery dependencies. A finance view could organise those same authorised entities around payment obligations and financial exposure. A legal view could foreground ownership claims, their sources and unresolved disputes.
These views can define which relationship types to emphasise, which properties to display and how information is labelled or grouped. They do not grant additional access.
Selecting a legal view must never confer legal permissions. Equally, hiding a field in a procurement view does not protect it if the API still returns it.
View configuration should also be permission-aware. A view name, description or filter can reveal the existence of a confidential investigation even when its results are hidden.
Preventing indirect disclosure
Removing restricted nodes from the screen addresses only one route through which information can escape.
A graph traversal might cross a confidential relationship and return a result that reveals the connection. Search could expose restricted document titles. Counts could reveal that hidden claims exist. Exports might include properties omitted from the interface.
The proposed enforcement model must cover these operations as well as ordinary reads. Traversal should follow authorised paths, and search results, counts and exports should reflect the information available to the requesting user.
AI features require the same discipline. Retrieval must apply access policies before evidence enters the model’s context. Generated answers, summaries and citations must then remain within that authorised evidence.
Cached results also need to respect access scope and permission changes. An answer prepared for a privileged user must not become available to another user through a shared cache.
Relationship review follows the same rules
The planned relationship-review module will flag confusing relationships, missing sources and claims that may need revision. Those warnings must operate within the same permission model.
A message such as “this supplier has a disputed ownership relationship” could disclose a confidential claim even if the relationship itself is hidden. Review queues, notifications, issue counts and explanations therefore need the same checks as the underlying graph.
Where an authorised user sees a claim but cannot inspect its evidence, the interface should distinguish that situation from evidence being absent—provided the policy permits that distinction to be disclosed. Restricted evidence must not automatically become a “missing source” warning.
The SolidState Graph implementation milestone
For SolidState Graph, the proposed milestone is workspace and project roles, server-enforced access policies, and configurable views over authorised graph data.
The implementation should establish a shared policy layer for graph reads, traversal, search, exports, review features and AI retrieval. Each request needs a verified user identity and scope, with enforcement before restricted information enters a response or downstream processing.
Semantic views can then build on that foundation through configurable entity types, relationships, properties and task-specific presentation. A practical acceptance scenario is to query the same supplier as procurement, legal and an external collaborator, then verify their results across the interface, API, search, exports and review module.
Real-time editing and approval workflows will build on these boundaries in later articles. The foundation here is a graph that preserves shared meaning while giving each person an authorised, useful view of the knowledge they need.