Operational Knowledge Models: Making Context Useful for Real Work

What Are Operational Knowledge Models?

A context model first describes the people, objects, activities, rules, and states through which a specific situation can be interpreted in domain terms. The operational knowledge model adds which approved knowledge may be used in that situation.

The term does not denote a single technical standard. It describes a function within the system architecture: domain concepts, object relationships, states, rules, and provenance information are connected so they can be evaluated during work. A model can express, for example, that a material batch belongs to a product, must be released for a processing step, and may be used only under a particular SOP version.

“Operational” does not mean automatic or autonomous. The model provides a reliable context. Whether this leads to information, a check, a block, a suggestion, or a human decision must be explicitly defined by the respective application.

An Upcoming Check Needs a Rule, Inputs, and a Permitted Consequence

In an illustrative processing step, a temperature value needs to be assessed. Task A-17 belongs to product variant V-2. Rule R-7 from a particular approved SOP version governs this task. A more recent working draft has not yet been activated and is therefore not used merely because it is newer.

The measured object, unit, and required equipment status are checked first. If the equipment status is missing, the application does not produce a seemingly complete determination of whether the value is within range. In the assumed process, it requests clarification. This response is an explicitly defined application rule.

If the prerequisites are met, the value can be assessed against R-7. In this example, an out-of-range result leads to a review task for the responsible role. It neither automatically grants release nor already determines the cause of the error.

Observation, rule evaluation, and the subsequent decision remain separate. This makes it possible to explain, even after R-7 changes, which statement arose under which rule at the time.

Selecting the Applicable Version and Preserving Its Reference

For A-17, the application must unambiguously assign the governing SOP version and rule R-7. A document number without a version is too imprecise for this purpose. For ongoing tasks, a version change requires an explicitly defined transition.

The origin of the rule also remains relevant. Data Provenance can describe the connection to the source, its transfer, and the responsible parties involved; PROV-O provides a formal vocabulary for this purpose.[4] This provenance does not automatically determine whether the rule applies to the current task.

A Review Finding Needs an Explicitly Defined Effect

A structural check can establish that the equipment status is missing. SHACL is one way to formulate such conditions for RDF data.[3] The result initially answers the stated data question.

Whether the application generates a clarification request, a block, or a review task from this is defined separately. In the example, clarifying the equipment status is a prerequisite for further assessment. This effect must not arise implicitly from the vocabulary.

Even a complete input can be factually wrong. The application rule must therefore remain connected to appropriate data capture and substantive review; passing a structural test does not replace them.

Observation and Subsequent Assessment Remain Separate

The temperature value belongs to the data captured in A-17. The statement “out of range” arises only from evaluating it under R-7. Using a different limit later does not retroactively change the original observation.

A new analysis therefore needs its own reference to the data used and the new rule. The historical assessment and the current reassessment may coexist but must be distinguishable.

From Static Knowledge to Ongoing Execution

An operational knowledge model provides value at specific points in the work. Before a task, it can determine the applicable SOP version, required qualifications, and released materials. During execution, it can check required information, units, and permissible value ranges. After a result, it can identify the responsible review, possible follow-up tasks, or affected objects.

This creates a cycle:

1. The current process context determines which knowledge is relevant.
2. The model provides concepts, relationships, rules, and applicable versions.
3. People or systems perform a task and make decisions.
4. Execution produces new states, events, and evidence.
5. These results extend the context for subsequent tasks.

This cycle is a core element of Process Intelligence: operational data are not analyzed only afterward. Verified relationships can be fed back into execution without obscuring the decision-making authority and accountability of the people involved.

An operational model must not become an unmanageable overall theory of the organization. It should start from specific decision situations. What information does the person performing the task need now? Which relationship must the system check? Which provenance must be traceable later? Starting from these questions, the model grows in a controlled manner along real use cases.

Five Building Blocks of an Operational Knowledge Model

For the operational use described here, we consider five interacting levels. They organize this approach and do not form a universal minimum catalog:

RDF can represent the necessary statements; OWL can describe their formal concepts and inferences.[1][2] OWL domain and range statements do not automatically safeguard inputs. Data checks and the permitted effect in the application are defined separately.

A Knowledge Model, Knowledge Graph, and Workflow Are Not the Same

A data model defines which fields and structures a system stores. A knowledge model additionally describes the domain meaning of objects, properties, and relationships. It can express that “uses material” is a different relationship from “produces intermediate product” and that the two relationships have different prerequisites.

Knowledge graphs are one possible form of representation for such knowledge. They connect identified entities and named relationships into a network that can be analyzed. An operational knowledge model can build on a knowledge graph but must additionally clarify when statements apply, how they are checked, and in which execution context they are needed. The graph is the knowledge structure; operational use connects that structure to ongoing tasks and decisions.

Ontologies can formally describe classes, properties, and general domain statements. An operational knowledge model uses these levels of meaning but additionally connects them to specific states, validity conditions, and points of effect in process execution.

Workflow models also serve a different purpose. They describe the activities, transitions, events, and decision points of an intended process. The knowledge model supplies the domain context a workflow needs at these points. The workflow can specify that a review follows a measurement. The knowledge model describes which limits apply to the affected product and current SOP version and which release role is responsible.

A knowledge base, in turn, can make documents and answers retrievable without formally connecting their contents. An operational knowledge model begins where the system can not only find text but also relate the meaning of information to the specific operation.

What Operational Knowledge Models Do Not Automatically Provide

• A model does not produce correct data. It can check structure and relationships but cannot turn erroneous observations into truth without further evidence.
• More semantics do not automatically mean more value. Concepts and rules without a specific application increase maintenance effort and interpretation risk.
• Inferences need explainable foundations. Users must be able to see which statements and rules produced a recommendation or check.

Knowledge Takes Effect at a Specific Point

A-17 demonstrates the crucial connection: an identified rule meets specific inputs and an explicitly permitted response. If a prerequisite is missing, that situation must also have an understandable path.

The value of operational knowledge models can therefore be assessed through such work situations. A collection of concepts is insufficient; the selection of knowledge, its evaluation, and the actual consequence in the process must be understandable.