A knowledge graph can describe what relates. Operational AI also needs to know what holds now, what may change, under whose authority, and how that decision will be accounted for.
A semantic system can have the right graph and still be wrong about what happens next.
It may know that an archival box belongs to a fonds, that a handling procedure applies, and that the box is stored in a particular location. Those facts do not establish whether a transfer request is still open, whether the latest condition check is valid, or whether anyone has authorized a move.
The graph can be correct. The operation can still be unready.
A state ledger
The following is an illustrative records-control example, not a description of a CARM’INK deployment.
| Record layer | Illustrative entry | What it tells the system |
|---|---|---|
| Knowledge | Box B-17 belongs to Fonds F-3; special handling applies. | What the object is and which rules relate to it. |
| Current state | Transfer request is awaiting_condition_check; location was last confirmed at a recorded time. |
Where the operation stands, and how current that information is. |
| Transition | The request can become ready_for_transfer after a current condition check and authorized approval. |
What must happen before the next state is allowed. |
| Authority | An assigned conservator may approve; an automation service may record the result. | Which actor can make or apply the decision. |
| Provenance | The condition report, the activity that recorded it, the responsible actor and the policy version. | Why the system treats the record as evidence. |
| Uncertainty | The location update is missing or conflicts with another source. | Whether the system should pause, reconcile or ask for review. |
These entries belong to one operation, but they answer different questions. A relation in the knowledge model does not automatically supply the operation’s current state or authorize its next transition.
A relation is not a lifecycle
Knowledge representation organizes entities, categories, relationships and constraints. That structure helps an AI system interpret a request and select relevant context.
Operational state answers a different question: what stage is this particular process in now?
A work order may move from open to assigned, then to in_progress, awaiting_review and closed. The useful meaning of each state depends on its source, time, scope and rules for changing it. A status label without those details is too thin to carry an operational decision.
A graph can represent state, events and transitions. The distinction is not about which database stores the data. It is about whether the system defines which assertions are current and authoritative, what changes state, and which actor is allowed to commit that change.
Time changes the reading
Consider the statement “the box is in storage.” It might describe a valid location from last week. Another record might say that the box was moved yesterday. Without an effective time, a recorded time and a clear source, the system cannot tell whether it is seeing a current fact, an outdated one or a conflict.
Operational context therefore needs more than values. It needs the frame around those values: when they apply, when they were recorded, how they were derived and whether they remain usable for this decision.
This is also why missing information needs careful treatment. Under OWL 2’s open-world semantics, an assertion absent from an ontology may be unknown rather than false. [1] For an operational system, that distinction matters. No recorded condition report does not mean the object passed inspection. No recorded restriction does not necessarily mean there is no restriction. The system must know when its sources are complete enough to support a decision.
Validation does not grant authority
Data validation is necessary. SHACL, for example, defines a way to validate RDF graphs against conditions. [2] A system can check that a record has the required fields or that its values fit an expected shape.
That check does not, by itself, decide whether the current user may advance a workflow, whether the policy still applies, or whether the underlying state changed after the check. Those decisions require an execution contract that connects identity, permissions, current state and permitted transitions.
The transition is where semantic interpretation becomes operational consequence. A model may help identify the relevant object and procedure. The surrounding system must determine whether the exact requested change is allowed now.
Meaning and authority have different jobs
A semantic layer can help resolve which records relate to a request and identify relevant policy references. It should not be treated as the authorization decision itself.
There are two distinct questions:
- What information is relevant and available for this task?
- Is this actor or agent authorized to perform this operation now?
Access controls must govern the context returned to the agent. Then consequential actions should pass through a separate, enforceable decision point at execution time. Open Policy Agent’s agent-tool-calling example illustrates this pattern: the agent harness sends a proposed tool call to a policy decision point and enforces the result before running the tool. [4]
Keeping these responsibilities distinct prevents “the model saw it” from becoming “the model may act on it.” It also allows a system to change an action policy without pretending that the underlying business meaning has changed.
Keep uncertainty visible
Operational systems often collapse uncertainty into a binary value: eligible or ineligible, available or unavailable, approved or rejected. That can hide important differences between unknown, stale, conflicting and explicitly denied.
Those conditions call for different responses. Stale information may need refreshing. Conflicting sources may need reconciliation. Missing evidence may require a pause. A denial may be final under the current policy. Treating them as one generic failure makes it harder for both software and people to respond appropriately.
Uncertainty should therefore be represented in the workflow, not left for the model to smooth over. The system needs defined paths for verifying, deferring, asking for help or stopping.
Provenance records how a decision came to exist
A decision becomes more useful when the system can explain which evidence it used, which activity produced the result, and which person or service took responsibility for a step.
W3C PROV-O provides concepts for connecting entities, activities and agents in provenance chains, including relationships that assign responsibility. [3] This is a useful vocabulary for traceability. The operational design still has to define how those records support accountability: who may approve, who may execute, which policy version applied and what happens when responsibility is delegated.
NIST’s AI Risk Management Framework treats governance as a cross-cutting function across AI risk work and the system lifecycle. It does not prescribe a particular state architecture; it supports the broader principle that responsibility and oversight must be designed into operation. [4]
The operational contract
Before an AI system changes a record, the surrounding architecture should be able to establish:
- the current state and its time frame;
- the evidence and source behind that state;
- the transitions permitted from it;
- the identity and authority of the actor requesting the change;
- the route for missing, stale or conflicting information;
- the record that will explain the outcome.
This contract does not require every field to live in one store. A graph may provide structured meaning. A state store or event log may track changing operations. An identity service and policy layer may control authority. The architecture should connect them so that inference receives relevant context and execution respects current conditions.
For CARM’INK, this is part of what makes a semantic system operational. Meaning is not only a network of connected entities. It includes the temporal and organizational conditions that determine whether an inference can be acted on.
A knowledge graph can say what belongs together. State establishes what holds now. Governance determines what may change and who is accountable for changing it.
References
- W3C, “OWL 2 Web Ontology Language Primer (Second Edition),” 11 December 2012.
- W3C, “Shapes Constraint Language (SHACL),” W3C Recommendation, 20 July 2017.
- W3C, “PROV-O: The PROV Ontology,” W3C Recommendation, 30 April 2013.
- National Institute of Standards and Technology, “Artificial Intelligence Risk Management Framework (AI RMF 1.0),” 2023.