Domain boundary
The business domain, use cases, decisions, and consuming systems the model is intended to support.
Illustrative reference model
Knowledge Graph Reference Model
A reviewable structure for defining enterprise entities, typed relationships, source authority, context services, and the controls needed to expose connected context to AI and business applications.
Reference-model statusIllustrative design, not a deployed client architecture. Domain concepts, source authority, identity rules, relationship meaning, platform choices, permissions, and operating controls are adapted to the engagement.
Model structure
Six records connect business meaning to application context.
The reference model is intended to make the design discussable before implementation. It names the records required to understand what the graph covers, what it relies on, what consumers may ask of it, and how change and exceptions are governed.
Source register
Approved records, identifiers, ownership, access conditions, freshness expectations, and permitted uses.
Entity model
Entity types, stable identifiers, aliases, matching rules, confidence, ownership, and lifecycle states.
Relation contract
Typed relationships with direction, meaning, validity, evidence, confidence, and constraints on use.
Context services
Queries, retrieval paths, policy checks, lineage views, context assembly, and integration interfaces.
Operating record
Versions, stewardship decisions, quality findings, exceptions, changes, usage, and review dates.
Reference diagram
The context path stays connected to its source and governing record.
Source records resolve into entities and typed relationships. Context services expose selected paths to consuming applications. Provenance, permissions, versioning, stewardship, and quality controls operate across the model rather than being inferred by each consumer.
- 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
Relation contract
A relationship is an operating claim with named evidence and constraints.
A line between two nodes is only useful when its meaning can be reviewed. The relation contract defines what the edge means, where it came from, when it applies, who governs it, and which applications may rely on it.
Required fields
- Subject and object entity types
- Relationship name, direction, and business meaning
- Authoritative source and supporting evidence
- Effective dates, status, and confidence
- Permission, policy, and jurisdiction constraints
- Steward, review date, and exception path
ILLUSTRATIVE RELATION CONTRACT
SubjectPolicy
Relationshipgoverns
ObjectBusiness process
EvidenceApproved policy record
ValidityEffective date + status
StewardNamed business owner
Context views
Applications receive a governed view, not unrestricted access to the full graph.
A context view defines the entities, relationship types, depth, source requirements, policy checks, freshness, and response fields permitted for a particular task. Different users and applications may receive different views of the same underlying model because their authority and operating purpose differ.
CONTEXT VIEW CONTRACT
01Consumer identity and purpose
02Allowed entity and relation types
03Traversal depth and query limits
04Source and freshness requirements
05Policy and permission checks
06Lineage returned with the response
Governance and operating record
Track the decisions that change meaning, identity, and permitted use.
Graph governance is not limited to technical schema review. It includes business definitions, identity disputes, source changes, relationship exceptions, policy updates, quality findings, consumer dependencies, and the migration path when a model version changes.
RecordDecision controlledEvidence retained
Approve a meaning or structure change
Proposal, reviewers, impact, effective date
Merge, split, reject, or defer an entity match
Source records, confidence, steward decision
Accept, limit, correct, or remove a relationship
Affected edges, evidence, scope, correction
Publish a view to a consuming application
Policy checks, test results, owner approval
Continue, remap, or suspend affected context
Source version, lineage impact, re-verification
What the engagement defines
Adapted before implementation
- Domain boundary, priority decisions, tasks, and consuming applications
- Entity, relationship, identity, evidence, and source-authority rules
- Context views, permissions, policy checks, and lineage expectations
- Stewardship, quality, versioning, exception, and review processes
- Platform evaluation criteria and integration constraints
Implementation-dependent
Proven with the selected environment
- Whether available source records can support the required identity and relationship claims
- Whether the selected platform can meet query, scale, latency, security, and operating needs
- Whether context views can enforce required permissions and policy decisions
- Whether lineage, freshness, quality, and exception records can be retained at the required level
- Whether consuming applications can use the context safely within the bounded task
Illustrative relation set
SubjectRelationshipObjectEvidence
Use the reference model
Judge the context design before committing to the graph implementation.
The model shows the structure Graph42 would adapt. A working session can determine whether the use case warrants a graph, which domain and sources belong in the first slice, and which claims can realistically be governed and inspected in the target environment.