Formal Knowledge Representation as the Input and Internal Languages of the Knowledge Compiler in Safety-relevant Clinical Systems

Authors

1. Prozorov A.A., Director of Technology, RTLAB; Architect, Sbertech; ap@rtlab.ru;
2. Bakhvalov I.M., General Director, RTLAB Oncology; ibakhvalov@rtlab.ru;

Abstract

Objective. To formulate a formal representation model for a knowledge compiler applicable to safety-relevant software, including supervisory ecosystems for the operating room and intensive care unit. Particular attention is given to the separation among the authorized input language, the authorized input instance of a concrete compile, the lowering contract, the compiler’s internal language, compiled materialization, and derived projections.

Materials and Methods. This article is methodological and architectural in character. A conceptual analysis of the knowledge compiler language stack was performed with attention to governed semantics, machine-checkable mappings, internal intermediate representations, derived runtime and review artifacts, and proof-facing surfaces. The external methodological basis consists of OWL, RDF, SHACL, PROV-O, JSON Canonicalization Scheme, JSON Schema, Meta Object Facility, and the software-language-engineering literature on domain-specific languages [1-9]. The internal authoring basis consists of prior program material on the graph-oriented authorized input language, the Authorized snapshot, formal planes, compiled bundle, derived Plane-JSON and Plane-BIN views, and the ownership boundary among shell, semantic core, and runtime environment.

Results. A layered model of the knowledge compiler is proposed. In this model, authorized semantics are represented in an ontology-oriented authorized input language; the Authorized snapshot is the only admissible input instance for a concrete compile; a machine-checkable mapping artifact governs lowering under a fail-closed policy; formal planes define the internal compilation language; the compiled bundle materializes that internal language; and Plane-JSON, Plane-BIN, runtime-compatible surfaces, manifests, and receipts are treated as derived rather than authorized projections. A separate ownership discipline is also formulated: the input layer, semantic core, and runtime environment must not substitute for one another in defining meaning.

Conclusion. The knowledge compiler is best understood not as a graph exporter or file-format transformer but as a controlled stack of languages. That separation reduces the risk of hidden semantic drift, preserves the distinction between authorized meaning and derived artifacts, and provides a basis for later work on traceability, runtime hosting, audit, and governed refinement. The contribution is limited to the formalization of the representational layers of the knowledge compiler; it does not claim clinical efficacy, completeness of runtime-environment artifacts, or sufficiency of the automated release chain.

Keywords: formal knowledge representation; knowledge compiler; authorized semantics; authorized snapshot; intermediate representation; compiler language levels; traceability; safety-relevant software; medical informatics

Abbreviations and Terminological Conventions

ICU - intensive care unit; OR/ICU - operating room and intensive care unit; IR - intermediate representation; DSL - domain-specific language; JSON - JavaScript Object Notation; BIN - binary representation; CI - continuous integration; RDF - Resource Description Framework; OWL - Web Ontology Language; SHACL - Shapes Constraint Language; runtime - runtime environment.

In this article, authorized semantics denotes the governed semantic basis that is allowed to define meaning, classification, relations, constraints, and admissible downstream projections. Authorized snapshot denotes the concrete accepted instance of that basis admitted to one compile. Lowering contract denotes the machine-checkable artifact that defines the admissible path from authorized semantics to formal planes and derived outputs. Internal language denotes the formal planes on which the compiler performs validation, binding, ordering, and materialization of machine-significant structures.

English artifact names are retained in their source form when they belong to the internal canonical architecture: Authorized snapshot, Plane-JSON, Plane-BIN, Go shell, Rust semantic core, and C++ runtime/build. Canonical English renderings used throughout this article include compiled bundle, binding projection, trace manifest, and descriptor control plane.

1. Introduction

Clinical software used in high-responsibility environments cannot rest on the simple declaration that its behavior “comes from the ontology” or “comes from the knowledge graph.” That formulation often hides the key engineering boundary. A knowledge graph, even when expressed through OWL, RDF, or SHACL, is not itself an execution contour; a release bundle does not by itself become a source of authorized meaning; and a runtime-compatible JSON view does not guarantee correct semantic projection [1-3, 5, 6]. Between governed meaning and deployment artifacts there is always a compiler, and that boundary has to be formalized because it is exactly where hidden implementation decisions can appear.

In OR/ICU-oriented systems, the problem becomes especially consequential. A supervisory system may process physiological oscillograms, numeric trends, device data, codified terms, and local clinical policies. If the path from authorized clinical semantics to executable structures is not made explicit, the effective owner of meaning may become not the approved model but local code, runtime configuration, compatibility projection, or a review file. Such a system may remain operational, yet its reviewability and reproducibility remain impaired.

The most vulnerable layer is the one in which graph predicates are lowered into runtime fields, internal structures arise only inside code, and compatibility projections begin to serve as authoring surfaces. Once that happens, the compiler ceases to be a mechanism for preserving semantic truth and becomes an opaque co-author of semantics. In safety-relevant clinical systems, this uncertainty complicates audit, root-cause analysis, release replay, and governed refinement.

A broader lifecycle problem may be addressed by a separate frame of closed-loop governance of formalizable knowledge. The present article addresses the narrower question: what language layers must exist inside the compiler so that governed semantics can be compiled without hidden lowering, hidden ownership, or hidden mutation surfaces? In other words, the article is not about the entire governance program, but about formal knowledge representation as the input and internal languages of the compiler.

The aim of this work is to describe a layered compiler language stack in which the authorized input language, the authorized input instance of a concrete compile, the lowering contract, the internal language, compiled materialization, and derived projections remain distinct and reviewable.

2. Methodological Basis and Scope Boundaries

This article is conceptual and architectural in type. It does not analyze clinical outcomes, compare patient groups, estimate sensitivity or specificity, claim registration-grade validation, or describe a complete runtime implementation. Its contribution lies in clarifying compiler formalism and ownership discipline across representational layers.

The methodological basis is organized around the following classes of objects:

1. an authorized semantic basis represented in a graph-oriented language;
2. an authorized snapshot admitted to a concrete compile;
3. a normative mapping artifact that defines the admissible lowering path;
4. formal planes as the internal language of compilation;
5. a compiled bundle as the bounded materialization of that internal language;
6. derived output artifacts for review, runtime compatibility, packaging, and proof;
7. an ownership boundary among the input shell, semantic core, and runtime or build environment.

In form, this approach resembles methodological and review-style articles in anesthesiology and critical care: first the clinically relevant problem is framed, then terminology is fixed, and only after that are mechanisms, applicability limits, and practical implications described. The object of the present article, however, is not a pharmacological or physiological intervention, but the architectural discipline of knowledge representation.

3. Why a Compiler-language Approach Is Needed

A compiler-language approach is needed because several different obligations are often collapsed into one vague notion of “representation.” That collapse may be tolerable in small demonstration systems, but it becomes inadequate for software used in clinically sensitive environments.

The first obligation is authorized semantics: the governed semantic basis that is allowed to define meaning, relations, constraints, policies, and machine-significant structure. The second is the authorized input language, that is, the formal structure in which such meaning is expressed and maintained. The third is the lowering contract, which constrains the path from authorized semantics to machine-significant structure. The fourth is the internal compilation language, over which the compiler actually reasons. The fifth is the family of derived projections consumed by downstream tooling, runtime environments, review workflows, or proof surfaces.

If those obligations are not distinguished, the implementation is forced to improvise. A runtime program file starts carrying hidden semantics. An internal package format starts behaving like an authorized language. The shell acquires semantic ownership merely because the internal language has never been described explicitly. Or a mapping rule remains embodied only in service-local code because no normative lowering surface exists.

This framing does not add formats for their own sake. It makes already-existing representational layers explicit enough that the compiler cannot silently invent another one inside itself. The practical value of the approach lies in separated obligations. Authorized semantics remain in the governed layer and its authorized snapshots. Lowering belongs to the mapping artifact. Internal reasoning belongs to formal planes and compiled structures. Runtime compatibility belongs to derived projections. Boundaries among shell, semantic core, and runtime environment remain governable because the relevant language layers are named explicitly.

4. Authorized Input Language

The compiler input language in this program must not collapse into a hand-authorized runtime JSON file. It is an ontology-oriented abstract syntax expressed in a governed graph model. The program maintains an authorized semantics layer and admits compilation only from an authorized snapshot. That distinction is fundamental: the authorized layer is where the semantic basis is admitted to machine-significant transformation, while downstream files are only derived materializations.

In the authorized input language, descriptors, methods, rows, predicates, effects, bindings, policies, terminology links, and related structures exist as governed semantic objects. They are not yet runtime fields and must not be edited through derived surfaces. Such a language is abstract syntax in the compiler sense: it fixes the structural and semantic units the system is allowed to reason over, but it does not bind the program to a single deployment or review projection.

Four properties follow from that definition.

First, the layer is named-graph-aware. Semantic partition and authority scope must be part of the input language rather than post hoc storage detail. Second, authorized objects must have stable identity. Descriptors, rows, predicates, bindings, and policies must exist as governed objects before any projection appears. Third, generated JSON must not be a mutation surface. Review or deployment files may reflect meaning, but they must not become the place where durable meaning is edited. Fourth, the authorized layer need not mirror file nesting or downstream consumer convenience. It should be compact in concepts and rich in semantic identity.

This is precisely where the present article diverges from runtime-facing papers. Those papers may legitimately start from compiled artifacts. A compiler-language paper must begin earlier, with the description of what counts as authorized input. Without that layer, the compiler appears to compile “from somewhere,” and that is exactly how hidden semantic ownership arises.

5. Normative Mapping Bridge as the Lowering Contract

Between authorized semantics and internal compiled structure there must be a normative bridge of lowering. In the present architecture that bridge is neither commentary on the code nor informal implementation lore. It is a machine-checkable mapping artifact that defines how ontology classes, predicates, and profiles may materialize into formal planes and derived projection fields.

At minimum, such a bridge includes an authoritative mapping inventory, a schema that constrains row structure, and row families that bind ontology symbols to compiled planes, review fields, and compatibility fields. In the current program one row family defines plane ownership and another defines predicate projection. That is enough to make lowering a governed contract rather than a local coding habit.

The need for this bridge is methodological rather than cosmetic. Without it, the compiler can quietly invent plane ownership, field placement, or compatibility semantics inside local implementation code. In that case, the most important part of compilation ceases to belong to the formal language stack and moves into private implementation detail. The system may continue to emit outputs, but it no longer proves that those outputs are governed descendants of authorized semantics.

For that reason, the lowering contract must operate under a fail-closed policy. If a machine-significant construct in authorized semantics has no governed mapping row, compilation must stop. If an emitted field cannot be justified by an explicit mapping row, it must not be produced. If plane responsibilities are blurred by the mapping table itself, the table is invalid, not merely a particular row. This is what makes the mapping artifact part of the language stack: it acts as the normative grammar of lowering rather than as metadata about lowering.

The bridge also prevents confusion between authorized and derived language layers. Ontology-oriented authorized semantics remain the authorized input language. Mapping rows define the legal lowering path. Formal planes define the internal compilation language. Derived projections define output languages. None of those layers should silently impersonate another.

6. Internal Language: Formal Planes and the Compiled Bundle

Even after the lowering path is constrained, the compiler still needs an internal semantic language in which it can validate, order, bind, and emit executable structures. In this program that internal language is the formal multi-plane IR: control, data, descriptor, and rule-execution planes, together with bounded cross-cutting projections such as binding projection and trace manifest.

Those planes are the compiler’s internal language. The compiled bundle is the bounded materialization of that internal language for deterministic downstream handling. It is not yet the full family of derived consumer-facing artifacts.

Calling the formal planes an internal language is not rhetorical emphasis but an architectural claim. First, the compiler reasons over them as structured objects with invariants rather than as raw exported fields. Second, the planes separate semantic obligations: scheduling and dependency structure do not belong to the same representational space as clinical data semantics, and cross-plane bindings must remain declarative rather than introduce hidden control flow. Third, the planes are closer to the compiler’s proof path than any compatibility projection is.

The compiled bundle should therefore not be treated merely as a packaging convenience. It carries the formal planes, the binding and trace surfaces needed for deterministic reasoning and subsequent explanation, and the digest-bound structure required for provenance and proof. In that sense, it is the materialization of the internal language rather than authorized canon.

This distinction matters because downstream artifacts often look more familiar than the internal language. A runtime-compatible JSON projection is easier to read than formal planes. A Plane-JSON review view is easier to inspect than a compiled bundle. But readability is not authorship. The internal language is the layer semantically owned by the compiler; the projections are layers the compiler emits for downstream consumption.

Worked Example Across Layers

Stage	Example representation
Authorized semantic object	In the ontology-oriented authorized semantics layer there exists a descriptor-dependency predicate.
Authorized compile input	The authorized snapshot admits that predicate and the owning descriptor into one concrete compile.
Mapping row	A predicate-projection row binds that predicate to the descriptor control plane and to the admissible review or compatibility fields.
Internal language	The dependency materializes as a control-plane object carried by the compiled bundle, together with binding projection and trace-manifest entries.
Derived projections	The compiler may emit a Plane-JSON review path and, where needed, a runtime-compatible field derived from that same mapped object.

Figure 1. Language stack of the knowledge compiler

7. Compiler Language Layers and Their Responsibilities

The proposed model requires each layer to have a bounded role, a canonical artifact, and an explicit forbidden overreach. This is especially important in clinical systems, where one and the same machine-significant relation may be reflected in a graph, an intermediate representation, a review file, a binary package, and a runtime surface.

Table 1. Compiler language layers and responsibility boundaries

Layer	Role	Canonical artifact	Forbidden overreach
Authorized input language	Defines governed meaning before execution.	Ontology-oriented abstract syntax and named-graph semantics.	Becoming a runtime-compatible file or a hand-edited deployment surface.
Authorized compile input	Admits one governed instance of the authorized semantic basis to a concrete compile.	Authorized snapshot.	Being treated as optional, inferred by default, or replaceable by local files.
Lowering contract	Constrains how authorized semantics may materialize downstream.	Mapping inventory, mapping schema, and normative projection rows.	Hidden lowering rules living only in code or implicitly inferred uncovered fields.
Internal language	Gives the compiler structured semantic planes for validation and reasoning.	Formal multi-plane IR.	Behaving like an authorized mutation surface or bypassing the lowering contract.
Compiled materialization	Carries the internal language as a bounded output set owned by the compiler.	Compiled bundle with binding projection and trace manifest.	Being confused with consumer-facing derived packages or review views.
Derived projections	Materialize outputs for deployment, review, and proof.	Plane-JSON, Plane-BIN, runtime-compatible projections, manifests, receipts.	Becoming co-equal authorized canon or an independent semantic authority.

This separation does not introduce extra formats for their own sake. It makes the already existing representational layers reviewable and prevents the compiler from silently creating an additional undocumented layer inside itself.

8. Derived Projections and Proof-facing Surfaces

The projection layer begins after the compiled bundle. Some derived artifacts are deployment-facing, such as Plane-BIN and runtime-compatible outputs. Others are review-facing, such as richer Plane-JSON views. Still others are proof-facing, such as manifests and digest-bound receipts. What unifies them is not function but status: they are all derived outputs from one authorized basis and one compiler-owned internal materialization.

Two practical consequences follow from that status. First, derived projections can be regenerated from the same authorized semantic basis and the same lowering contract without changing the system’s meaning. Second, proof-facing surfaces can be evaluated on their own terms. Canonicalization, manifests, digests, and provenance links exist to prove what was projected and from what basis. They must not become a second semantic language.

For that reason, Plane-BIN should not be identified with the compiled bundle itself. The compiled bundle is the bounded materialization of the internal language. Plane-BIN is a derived machine-oriented packaging view of that materialization. Likewise, Plane-JSON is a human-oriented review view. Runtime-compatible projections may preserve operational continuity where needed, and manifests or receipts may bind those outputs back to one semantic basis and one lowering contract. Yet none of these outputs should become the place from which semantic correction begins.

This article conceptually intersects with provenance and traceability, but the overlap is bounded. What matters here is showing that derived outputs belong to the language stack while their proof-facing surfaces remain derived. The full program of end-to-end term traceability, runtime evidence, and governed refinement belongs to companion articles.

9. Boundary Between Shell, Semantic Core, and Runtime Environment

In the current program, the Go shell -> Rust semantic core -> C++ runtime/build split matters not as a language war but as an instance of a more general ownership discipline. The input and orchestration layer owns command parsing, path resolution, operator-facing workflow, and boundary behavior. The semantic core owns lowering, projection proof, fail-closed validation, and internal-language materialization. The runtime or build environment executes or packages accepted compiled structures, but does not own authorized semantics or compile-time meaning.

This boundary matters because it prevents implementation surfaces from blurring the language stack. The shell must not become a second lowering engine. The runtime environment must not become a semantic author. A compatibility projection must not become a source of truth merely because it is convenient for a local service. The split among shell, semantic core, and runtime environment therefore serves the same purpose as the representational split: one semantic obligation, one owner.

At the same time, the article must not make that boundary the model’s headline identity. Detailed command families, request envelopes, protocol schemas, and release orchestration belong to narrower architecture papers. What matters here is the compiler-language consequence: the authorized input language, lowering contract, internal language, and derived surfaces must be aligned explicitly enough that ownership boundaries can actually be enforced.

Figure 2. Ownership boundary between shell, semantic core, and runtime environment

10. Discussion

The results support viewing the knowledge compiler as a stack of formal languages rather than as a technical graph exporter. This framing is particularly important for clinical software, where the distinction between authorized clinical meaning and its derived artifacts must be preserved across the full path from authoring to bedside execution.

The key advantage of the proposed frame is prevention of hidden semantic drift. If authorized semantics, the authorized snapshot, the mapping contract, internal planes, and derived projections are all described separately, it becomes easier to determine which layer is entitled to change meaning, which only materializes it, and which only supports runtime compatibility, review, or proof. That creates the preconditions for later traceability, audit, and governed refinement even though the present article does not unfold the full governance lifecycle.

The second advantage is reproducibility. If derived outputs can be regenerated from one authorized basis and one lowering contract, runtime compatibility stops being an independent source of truth. It remains a consumer-facing projection suitable for deployment, but not a layer that defines meaning.

The third advantage concerns ownership discipline. In clinical systems that may use different technological layers, what matters is not whether parts are written in Go, Rust, or C++, but whether hidden semantic ownership arises in a layer that should perform only orchestration, packaging, or execution. The proposed model lets us separate implementation-language choice from the architectural question of who owns meaning.

It is important to stress that use of ontologies, RDF, OWL, SHACL, or related standards does not by itself guarantee the presence of such a language stack. These technologies can support explicitness, constraints, and provenance, while canonicalization and schema specifications can improve reproducibility of machine artifacts [1-6]. Yet they do not force a project to distinguish authorized syntax, lowering contract, internal language, and derived projections. That distinction must be deliberately designed, implemented, and checked.

11. Invariants of the Proposed Model

The invariants of this article are primarily representational and architectural.

1. There is one authorized semantic basis, and each compile consumes one authorized snapshot of that basis.
2. No hidden lowering is permitted outside the normative mapping artifact.
3. Compilation operates under a fail-closed policy with respect to unmapped machine-significant semantics.
4. Formal planes define the internal language, and the compiled bundle is its bounded materialization rather than a second authorized layer.
5. Derived outputs, including Plane-BIN, Plane-JSON, runtime-compatible views, manifests, and receipts, remain derived and non-authoritative.
6. For each semantic obligation there must be one owner at the level of the input layer, semantic core, or runtime/build consumer.

These invariants are sufficient to distinguish the present article from companion work. Closed-loop Governance of Formalizable Knowledge explains how governed knowledge passes through authorization, release, evidence, and refinement while preserving authorship. The traceability paper explains how compiled terms and runtime evidence remain traceable. Implementing Executable Knowledge as Compute Core and Safety Kernel explains the operational hosting of compiled knowledge. The present article stands earlier in the chain: it defines which representational layers must exist so that later papers do not rely on hidden semantic invention.

12. Boundary with Companion Articles

Table 2. Boundary between this article and companion papers in the series

Paper	Owns	Does not own
Closed-loop Governance of Formalizable Knowledge	Governance method in authority space across authorization, release, evidence, and refinement.	The formal compiler language stack or runtime-host architecture.
Formal Knowledge Representation as the Input and Internal Languages of the Knowledge Compiler	Authorized input language, lowering contract, internal language, and derived projection boundaries.	The full provenance lifecycle, runtime hosting, release automation, or trust-chain execution.
End-to-end Codified-term Traceability for Debugging and Auditing the Compiler and Executable Modules	Term provenance, traceability, and auditability across compiler and runtime artifacts.	Definition of the authorized input language or shell/runtime architecture as such.
Implementing Executable Knowledge as Compute Core and Safety Kernel	Placement of the compute core, runtime architecture, and safety-kernel boundary.	The formal compiler language stack or governance method.

13. Limitations

This article has several limitations. First, it is methodological and architectural in character and contains no clinical validation. Its conclusions therefore must not be interpreted as proof of clinical efficacy for any decision-support system, OR/ICU supervisory contour, or device-control algorithm.

Second, it does not describe a complete runtime implementation. The Go shell -> Rust semantic core -> C++ runtime/build split is used as an example of ownership discipline rather than as a universal technological requirement.

Third, the article does not claim complete end-to-end traceability, auditability, or trust-chain closure. It formulates the representational layers without which such traceability becomes difficult, but it does not replace separate work on runtime evidence, provenance, and governed refinement.

Fourth, it does not claim that every ontology-based system already satisfies the proposed invariants. The presence of RDF-, OWL-, SHACL-, or comparable technologies is only a potential foundation; it does not guarantee correct separation among the authorized input language, the lowering contract, the internal language, and derived projections.

14. Conclusion

In safety-relevant software, the knowledge compiler is best described not as a graph exporter, a runtime packager, or a single protocol boundary, but as a layered stack of languages. The central distinction of that stack is straightforward: authorized semantics and the authorized snapshot are not the mapping contract; the mapping contract is not the internal language; and the internal language plus the compiled bundle are not the same thing as the derived Plane-JSON, Plane-BIN, or runtime-compatible surfaces.

Preserving these distinctions reduces the risk of hidden semantic drift and helps keep the series intellectually clean. The governance paper can define how authorship moves. The compiler paper can define in which formal layers that authorship is compiled. The later papers on traceability, runtime environments, analyzers, and release can then specialize the chain without reopening the question of where meaning lives and how it first becomes machine-significant.

The proposed model may therefore serve as a basis for further design of clinical information systems in which authorized semantics must remain governable as they move into machine-significant representations, runtime compatibility, proof-facing surfaces, and later audit.

Authoring Basis

The article draws on the internal documentation of the HealthOS project: the specifications, schemas, and registries that define authorized semantics and its compiled form, the runtime and tooling that produce execution evidence, and the companion manuscripts of the series, bound together by a shared terminology canon. These are working sources that ground the engineering decisions and keep terminology consistent across the series. They remain internal authoring basis rather than public references and are not cited as repository links in the text.

Conflict of Interest

The manuscript describes the implementation of a specific aspect of the HealthOS platform, namely: formal knowledge representation as the input and internal languages of the knowledge compiler.

Funding

The work was funded by RTLAB.

References

1. W3C OWL Working Group. OWL 2 Web Ontology Language Document Overview. 2nd ed. W3C Recommendation. 2012. https://www.w3.org/TR/owl2-overview/
2. Cyganiak R, Wood D, Lanthaler M, editors. RDF 1.1 Concepts and Abstract Syntax. W3C Recommendation. 2014. https://www.w3.org/TR/rdf11-concepts/
3. Knublauch H, Kontokostas D, editors. Shapes Constraint Language (SHACL). W3C Recommendation. 2017. https://www.w3.org/TR/shacl/
4. Lebo T, Sahoo S, McGuinness D, editors. PROV-O: The PROV Ontology. W3C Recommendation. 2013. https://www.w3.org/TR/prov-o/
5. Rundgren A, Jordan B, Erdtman S. JSON Canonicalization Scheme (JCS). IETF RFC 8785. 2020. https://www.rfc-editor.org/rfc/rfc8785
6. JSON Schema authors. JSON Schema Draft 2020-12. 2022. https://json-schema.org/draft/2020-12
7. Object Management Group. Meta Object Facility (MOF) Core Specification, Version 2.5.1. 2019. https://www.omg.org/spec/MOF/2.5.1
8. Fowler M, Parsons R. Domain-Specific Languages. Addison-Wesley; 2010. https://martinfowler.com/books/dsl.html
9. Voelter M, Benz S, Dietrich C, et al. DSL Engineering. 2013. https://dslbook.org/