Domain model
Business concepts, definitions, ownership, lifecycle, and the boundaries the model will not cover.
Foundational capability
Give enterprise AI a governed map of what connects to what.
Graph42 designs and builds knowledge graphs and enterprise context layers that connect business entities, systems, data, policies, events, and evidence. AI applications can then retrieve and use governed relationships rather than treating each document or record as an isolated fact.
The problem
Enterprise context is fragmented across records that were not designed to explain one another.
A customer, asset, application, policy, agreement, location, or product may have different identifiers, owners, definitions, and update cycles across the enterprise. Search can find records. A model can summarize them. Neither step alone establishes which entities are the same, how they are related, which source is authoritative, or which policy applies.
That missing context is where plausible answers become operational mistakes. The work is not simply to add a graph database. It is to define a governed semantic and relationship layer that applications can use.
Without a governed context layer
- Entities are matched differently by each application
- Relationship meaning is inferred from nearby text
- Policy and permissions are applied after retrieval
- Source lineage disappears inside generated answers
With an explicit graph model
- Identity and aliases follow disclosed rules
- Relationships have typed meaning and direction
- Context views respect permissions and policy
- Answers can retain paths back to source records
Reference model
Source records → Entities → Relationships → Context services → AI use
The graph is a governed operating layer, not a decorative network. Each stage produces a record that can be reviewed by business, data, security, architecture, and application owners.
- 01
Source records
Resolve the records the graph may use
Identify approved systems, documents, events, identifiers, and evidence sources, including ownership and permitted use.Source and access register - 02
Entities
Define the things the enterprise must distinguish
Model people, organizations, products, assets, locations, policies, agreements, and other domain entities with stable identifiers.Entity model and identity rules - 03
Relationships
Name how those entities are connected
Define typed relationships, direction, validity, confidence, source, and the business meaning a consuming system may rely on.Ontology and relation contracts - 04
Context services
Expose governed context to applications
Provide query, retrieval, lineage, policy, neighborhood, and context-assembly services through controlled interfaces.Context service design - 05
AI use
Apply context within a bounded task
Connect search, assistants, agents, recommendations, and decision support to the context they are permitted to use.Use-case context contract
Cross-cutting graph controls
- Source provenance and lineage
- Identity resolution and confidence
- Permissions and policy enforcement
- Ontology and schema versioning
- Stewardship and exception handling
- Quality, freshness, and usage monitoring
Ontology and entity modeling
Define enterprise meaning before connecting records.
An ontology states which entity and relationship types matter for the selected domain. Entity resolution then determines how records map to those types, how aliases and conflicts are handled, and when a match is uncertain enough to require review.
Identity model
Stable identifiers, aliases, matching rules, confidence, survivorship, merge, split, and exception paths.
Relationship model
Typed edges with direction, business meaning, cardinality, validity, evidence, and permitted use.
Stewardship model
Named owners for definitions, quality decisions, disputed identities, relationship exceptions, and change.
Enterprise semantic layer
Expose business context without forcing each application to rebuild it.
The context layer can provide resolved entities, relationship neighborhoods, policy applicability, provenance, lineage, and domain-specific queries through controlled services. The underlying technology may include graph, search, relational, vector, event, and metadata systems. The architecture is selected around the required context and operating constraints rather than around a preferred product category.
SubjectRelationshipObjectEvidence
AI and application use
Use the graph where relationships change the answer or action.
A knowledge graph is valuable when a task depends on identity, connected records, applicable policies, temporal state, or explainable paths. It should not be inserted into low-complexity use cases that a simpler index, database query, or workflow can support more responsibly.
Enterprise search and retrieval
Resolve business entities, approved sources, and relationships before assembling context for search or retrieval-augmented generation.
Agent context and memory
Give an agent a bounded view of the entities, policies, prior events, and relationship paths relevant to its assigned task.
Decision support
Connect recommendations to the source records, assumptions, policies, dependencies, and entity relationships behind them.
Customer and product context
Reconcile identities and relationships across channels, accounts, products, locations, agreements, and interactions.
Operational and asset context
Represent systems, assets, owners, dependencies, events, controls, and service relationships for operational workflows.
Policy and control resolution
Connect policies, obligations, roles, jurisdictions, evidence, and affected entities so applications can resolve the applicable context.
Lineage, policy, and governance
A useful relationship must remain connected to its authority and operating rules.
The model records where an entity or relationship came from, when it was valid, who governs its meaning, and which consumers may use it. Quality and freshness are monitored at the entity, relation, source, and use-case levels because a graph can be structurally valid while still carrying stale or disputed context.
- Source and evidence path for entities and relationships
- Access and policy decisions applied to context views
- Effective dates, lifecycle state, confidence, and freshness
- Ontology, schema, mapping, and query version control
- Named stewardship, review cadence, and exception handling
- Usage records that show which applications rely on which context
Inspectable artifact
Review the context model before funding the implementation.
The Knowledge Graph Reference Model shows the domain boundary, source register, entity model, relation contract, context services, and operating record. It separates what the engagement defines from what must be proven with the selected data, platform, integrations, policies, and consuming applications.
REFERENCE MODEL RECORD
01Domain boundary
02Source register
03Entity model
04Relation contract
05Context services
06Operating record
When it fits
Conditions that justify a durable enterprise context layer
- Important answers depend on relationships across multiple systems or document collections
- The same entity is represented by conflicting identifiers, names, or ownership rules
- AI applications need governed context that is broader than a single retrieval index
- Source lineage, policy applicability, or relationship provenance must remain inspectable
- Multiple use cases can share a durable enterprise context layer rather than rebuilding context independently
- Business stewards and technical owners are available to define meaning, authority, and exceptions
If the use case does not depend on connected entities, shared semantics, policy-aware context, or source lineage, a knowledge graph may add cost without adding proportional decision value. We will recommend the simpler architecture when it is sufficient.
Engagement
Start with one domain, one context problem, and one consuming use case.
The first working session identifies the decision or task, required entities and relationships, source authorities, policy constraints, consumers, and evidence needed to judge the context layer. Scope then moves into a bounded model and working slice rather than an enterprise-wide ontology program by default.
What the engagement includes
- Domain framing and priority use-case selection
- Source, identifier, entity, and relationship discovery
- Ontology and semantic model design
- Graph platform and integration architecture
- Governance, stewardship, provenance, and quality controls
- A bounded working slice with acceptance and operating decisions
What the client provides
- Business and data owners who can define authoritative meaning
- Access to representative source structures and identity rules
- Security, privacy, retention, and policy constraints
- Named use cases and consuming application teams
- A decision owner for scope, stewardship, platform, and rollout
Decision at the end
Implement the bounded model, revise the domain or source assumptions, select a different platform pattern, continue with another use case, or stop. Pricing is provided after scope, source access, integration, stewardship, and operating responsibilities are understood.