Start with the meaning of a question
Consider a request to identify customers exposed to a delayed shipment. The word customer might mean an ordering account, an invoiced legal entity, a receiving location or a corporate parent. A language model can produce a plausible answer without resolving that distinction. An operational answer needs an explicit choice, because the selected definition determines the join path and the people who should receive an alert.
Begin by translating a small set of real questions into named business concepts. Define the grain of each concept, the source that governs its identity and the relationship through which it participates in the question.
Give entities durable identities
RDF describes a graph through subject, predicate and object statements, with IRIs available for identifying resources. That structure is useful because relationships become explicit rather than being hidden inside document prose. It does not resolve duplicate customer records or determine whether two source identifiers represent the same organisation. Those remain enterprise identity decisions requiring ownership and evidence.
Preserve source identifiers alongside any enterprise identifier. Record how a mapping was established, whether it was reviewed and when it was valid. Distinguish an exact match from a probable association. A retrieval process should be able to explain which identity path connected a purchase order to a customer rather than silently treating a similarity score as proof.
Separate definitions from observations
A semantic model should distinguish the definition of overdue from an observation that a particular invoice is overdue. The definition might depend on contractual terms, a settlement calendar and an agreed reference date. The observation also depends on a particular invoice version and the latest payment evidence. Combining these into one unqualified label makes later investigation unnecessarily difficult.
Publish important definitions as versioned decisions with accountable owners. Associate derived observations with the definition version and source evidence used to calculate them. When a term changes, reviewers can then identify affected queries, dashboards and AI prompts.
Validate what can be checked
SHACL provides a standard vocabulary for validating RDF graphs against shapes. A shape can express required properties, value types and relationship cardinalities. These checks help detect an order without an ordering organisation or a shipment event without a recorded time. Run these checks before downstream retrieval or reasoning.
Passing a shape does not prove that a business statement is true. A delivery date can be syntactically valid and operationally wrong. Combine structural validation with source reconciliation, domain review and explicit uncertainty. Route incomplete records to a visible exception process, and allow an answer to acknowledge insufficient evidence rather than filling gaps with a confident narrative.
Preserve time and permission boundaries
Enterprise facts change. A supplier relationship may have been valid when an order was placed but no longer be current. Store the effective period of important relationships separately from the time they arrived in the intelligence layer. This distinction supports both present operational questions and historical investigations without rewriting the past whenever new information arrives.
Apply the same care to access. A relationship can reveal sensitive information even when its endpoint documents are restricted. Evaluate whether a user may discover an entity, traverse a relationship and view the supporting evidence. Retrieval should preserve those boundaries through context construction, answer generation and citation display, including caches and logs that might otherwise retain restricted material.
Test the model through real decisions
Choose evaluation questions that force the system to use relationships and definitions: which contract applies, which invoice version matters, or which warehouse serves a delayed order. Include deliberately ambiguous names and historical changes. Inspect the retrieved entities and evidence path as well as the final answer, because a correct answer reached through the wrong identity mapping can fail on the next case.
Ask reviewers to reproduce the interpretation by inspecting the question, resolved entities, applicable definition, evidence timestamp and permitted action. Record disagreements and correct the mappings or definitions responsible. Repeat the assessment when sources or business rules change.