Implementing executable knowledge as compute core and safety kernel
Authors
- Prozorov A.A., Director of Technology, RTLAB; Architect, Sbertech; ap@rtlab.ru;
- Nguyen I.Kh., Software Engineer, RTLAB; Software Engineer, Sbertech; inguen@rtlab.ru;
- Nuzhny A.S., Head of Computational Methods Group, RTLAB; Senior Research Scientist, Institute for Nuclear Power Development Safety Problems, RAS; Cand.Sc. (Phys.-Math.); anuzhny@rtlab.ru;
- Bakhvalov I.M., General Director, RTLAB Oncology; ibakhvalov@rtlab.ru;
- Nikitin T.N., General Director, RTLAB Anesthesiology; tnikitin@rtlab.ru;
- Marochko M.A., Software Engineer, RTLAB Anesthesiology; mmarochko@rtlab.ru;
Abstract
Objective: Compiled executable knowledge becomes trustworthy only when the runtime that consumes it is deterministic, bounded, auditable, and explicit about what it does not authorize. This article defines a runtime architecture in which a deterministic compute core and deterministic safety kernel execute compiled knowledge through stateless analysis without becoming semantic authority.
Materials and methods: The article is a methodological systems paper with bounded implementation evidence from compute-core planning, runtime boundary specifications, scheduler and control specifications, compiled bundle specifications, runtime evidence specifications, and safety traceability materials. External standards ground lifecycle discipline, risk-control framing, quality-system traceability, provenance, audit analogies, canonical digests, and schema-constrained artifact design.
Results: The method separates semantic authority, release and deployment evidence, service-host verification, the runtime compute-core library, stateless request execution, audit and debug evidence, and downstream runtime evidence projection. It defines responsibility boundaries for the compute core, safety kernel, service host, and evidence surfaces, then illustrates the chain with a safety-neutral signal-duration example.
Conclusion: Stateless analysis lets compiled executable knowledge run as deterministic, request-local computation while preserving separate semantic, release, host, and runtime authorities. The safety kernel provides fail-closed runtime admissibility and evidence, but it does not replace clinical validation or regulatory approval.
Keywords: executable knowledge; compute core; safety kernel; Runtime library; stateless analysis; deterministic runtime; fail-closed execution; runtime evidence; auditability
Abbreviations and Terminology
Compute core: The deterministic computation subsystem that validates an in-memory runtime catalog, builds an immutable engine, executes one normalized request, manages request-local staged and committed facts, assembles the response, carries runtime term references, and emits deterministic evidence.
Safety kernel: The deterministic runtime control subsystem that enforces binding resolution, prerequisite checks, applicability checks, module and license scope, skip/degrade/abort policy, and fail-closed rejection. In stateless analysis it controls runtime admissibility and evidence; downstream stateful analyzer contours may also use it for HITL command application. It is not a clinical validation system.
Stateless analysis: A runtime mode in which the runtime compute-core library executes one normalized request against an immutable in-memory runtime catalog, uses only request-local mutable state, returns a deterministic response and evidence, and stores no mutable cross-request clinical state.
Service host: The process or service boundary that owns transport, decoding, file access, network access, secrets, bundle source selection, release/deployment context, digest or signature checks, schema checks, and projection of runtime outputs to external topics or storage.
Authorized snapshot: The bounded, digest-identified semantic basis accepted by the authority path for a compiled runtime artifact. It is the semantic input to compilation, not a runtime-selected source of meaning.
Compiled bundle: The digest-bound runtime projection produced from authorized semantics and compiler output. It carries the runtime catalog and evidence projections consumed by the service host and runtime compute-core library.
Release/deployment evidence: The reviewer-facing evidence that identifies which compiled bundle, receipts, configuration fingerprints, and deployment context form the bounded execution set for deployment, replay, and review.
Runtime catalog: The in-memory declarative execution view derived from the compiled bundle. It describes executable units, dependencies, layer and tier order, bindings, runtime term references, control policies, audit templates, and debug templates.
Immutable engine: The request-shared runtime object built from a validated runtime catalog. It contains catalog-derived immutable plan data and does not retain request data or mutable clinical state.
Pipeline execution entry point: The public request-execution entry point of the runtime compute-core library. It accepts a normalized request and returns an owning response plus evidence.
Pipeline request and pipeline response: The request is one normalized invocation containing request identifiers, configuration fingerprints, signal and context inputs, and active runtime scope. The response is the owning container for outputs, execution metadata, audit events, debug trace, degradation markers, and deterministic hash material.
Audit event: A durable evidence record used for auditability, release review, and incident reconstruction. Debug trace may link to audit events, but it does not replace them.
Debug trace: Request-local diagnostic evidence explaining control decisions, checked contracts, skip/degrade/abort reasons, stub no-output behavior, and execution ordering. It is not non-repudiable audit.
Non-repudiable audit record: A durable audit record whose provenance, digest or context binding, and append-oriented publication make it unsuitable for silent reconstruction from debug traces. This is an evidence-bound auditability concept, not a legal non-repudiation claim.
Runtime term reference: A compiled term identity carried through runtime catalog, normalized request, response, audit and debug references, and evidence projection. Registry and trace joins remain the responsibility of the companion term-traceability article.
HITL command application: A downstream stateful-analyzer path in which the safety kernel gates application of human-accepted commands. It is not part of ordinary stateless analysis.
Runtime evidence projection: The downstream normalization of response, audit, debug, metric, result, and replay surfaces into reviewable runtime evidence artifacts.
PHI: Protected health information. In this article the term marks raw patient-identifying fields and comparable re-identifiable payloads that must not be exposed through debug trace.
Placeholder medical algorithm body: A bounded executable placeholder that checks runtime contracts and emits evidence while intentionally producing no clinical facts or conclusions.
Controlled degradation: A declared runtime policy, held in the validated runtime catalog or release-bound runtime configuration, that allows a bounded degraded response only when the catalog, request, and safety-kernel decision make that degraded path explicit. It is distinct from fail-closed rejection of integrity or admissibility failures.
Deterministic hash: A canonical digest over the request, active catalog identity, execution plan identity, final committed facts, sorted degradation reasons, and other contract-fixed deterministic inputs, excluding volatile timing fields.
Public manuscript text follows two invariants. First, it uses descriptive runtime architecture terms rather than implementation identifiers. Second, it uses stateless analysis rather than internal runtime-mode labels.
Introduction
Executable knowledge passes through several transformations before it affects runtime behavior. Formal semantics are authorized, compiled, projected into runtime artifacts, released, deployed, loaded by a service host, and finally executed for a concrete request. A defect in any boundary can make the system appear to execute knowledge while actually running stale, incomplete, unsupported, or insufficiently evidenced behavior.
This article addresses the runtime part of that chain. The runtime compute-core library executes a validated in-memory catalog under an explicit service-host boundary. Semantic authority remains with the governed graph and compiler lineage; release and deployment evidence identify the bounded execution set; transport and source selection remain host responsibilities. The compute core owns deterministic stateless request execution, and the safety kernel owns runtime admissibility, controlled degradation, and fail-closed control.
The contribution is a reusable systems pattern for implementing executable knowledge as a deterministic compute core and deterministic safety kernel. The pattern is deliberately narrow; its full non-claims are collected in the limitations section.
Companion Articles
The companion article Executable knowledge through the OR/ICU supervisor ecosystem frames why the supervisor needs executable knowledge and bounded bedside runtime behavior. Closed-loop Governance of Formalizable Knowledge in Clinical Information Systems owns the single-authority governance method. Formal knowledge representation as the input and internal languages of the knowledge compiler owns compiler language layers and lowering. End-to-end Codified-term Traceability for Debugging and Auditing Compiler and Executable Modules owns term registry and trace joins. Authorization and diagnostic contour as universal infrastructure for executable-knowledge development and governance owns Workbench-assisted diagnostic closure after runtime evidence exposes a governed refinement need.
Downstream systems papers own hosting and release contours. Implementing a stream analyzer for mixed named features and oscillograms and Stateless rule-based analyzer for mixed named features and oscillograms own stream and stateless analyzer architecture. Automatic closed-loop release of trusted executable analyzer modules from a trusted knowledge snapshot and Continuous chain of trust in the automatic closed-loop release of executable analyzer modules own release automation and trust-chain continuity. Instant health assessment through an ECG example: interpreting mixed named terms and ECG oscillograms owns ECG-domain instantiation and clinical knowledge-graph use.
Materials and Methods
This is a methodological systems article with bounded implementation evidence. The internal authoring basis includes compute-core realization plans, compute-core problem and realization statements, runtime boundary specifications, scheduler specifications, control algorithm specifications, memory and debug-trace specifications, compiled bundle specifications, runtime evidence specifications, safety traceability materials, and the shared IHA terminology canon. These internal materials shape the architecture narrative but are not public references.
External sources provide framing rather than product claims. IEC 62304 grounds software lifecycle discipline [1]. ISO 14971 grounds risk-control framing for safety-related runtime boundaries [2]. ISO 13485 grounds quality-system traceability governance [3]. PROV-O and FHIR AuditEvent ground provenance and structured healthcare audit analogies [4,5]. RFC 8785 grounds canonical JSON digesting and reproducible receipts [6]. JSON Schema 2020-12 grounds schema-constrained evidence and bundle artifacts [7].
The method separates four levels. The semantic level authorizes and compiles knowledge under lifecycle and quality-system traceability discipline [1,3]. The release/deployment level selects and verifies a bounded execution set. The service-host level owns transport, decoding, source selection, and external projection. The runtime-library level performs stateless analysis by executing a validated in-memory catalog with request-local state and deterministic evidence.
Runtime Lifecycle Overview
The lifecycle spine is represented as a top-down artifact and responsibility flow:
Figure 1. Runtime lifecycle and ownership flow from compiled bundle to evidence projection. The diagram shows the top-down path from authorized and released runtime artifacts into service-host verification, in-memory catalog materialization, compute-core execution, response creation, audit/debug evidence, and runtime evidence projection.
Figure 1 emphasizes lifecycle ownership. An authorized snapshot and compiled bundle establish the compiled runtime basis, while release and deployment evidence identify which bundle is accepted for the execution contour. The service host verifies the selected bundle, checks schema and digest evidence, materializes the runtime catalog view, normalizes the request, and passes in-memory structures to the runtime compute-core library. Schema-constrained artifacts and canonical digests make this handoff reproducible [6,7]. The compute core validates the catalog, builds an immutable engine, executes one request through stateless analysis, and emits an owning response. Audit events, debug trace, and runtime evidence projection then make the execution reviewable without turning debug data into audit authority or runtime behavior into semantic authority.
Table 1: Components, Responsibilities, and Authority Boundaries
Table 1. Components, responsibilities, and authority boundaries
| Component | Responsibility | Consumes | Produces | Authority boundary |
|---|---|---|---|---|
| Semantic authority and compiler | Govern authorized semantics and produce compiled runtime artifacts | Authorized graph state, compiler inputs, validation evidence | Authorized snapshot, compiled bundle, lineage receipts | Owns semantic meaning while request execution remains downstream |
| Release and deployment evidence | Identify the bounded execution set accepted for deployment, replay, and review | Compiled artifacts, receipts, deployment selection, reviewer evidence | Release/deployment refs, manifest digests, accepted bundle identity | Establishes deployment context while semantic changes remain governed upstream |
| Service host | Own transport, decoding, source selection, schema/digest verification, secrets, external projection, runtime materialization, and service lifecycle | Released bundle, deployment config, normalized request inputs | Runtime catalog view, normalized request, projected evidence | Owns operational integration while clinical computation remains inside the runtime boundary |
| Deterministic compute core | Execute one normalized request against an immutable in-memory catalog | Runtime catalog view, normalized request, runtime configuration, runtime term refs | Owning response, deterministic hash, request-local evidence with runtime term refs | Owns stateless computation while semantic authority remains outside the library |
| Deterministic safety kernel | Enforce runtime admissibility, control gates, binding checks, module scope, and fail-closed behavior | Engine plan, request context, committed facts, policy refs | Run/skip/degrade/abort/fail-closed decisions, control facts, structured failures | Owns stateless risk-control gates; downstream HITL command application remains a stateful analyzer concern |
| Audit surface | Preserve durable evidence for auditability and reconstruction | Execution decisions, response refs, runtime context refs, audit material | Audit events, audit links, non-repudiable audit records when published durably | Durable audit remains distinct from diagnostic trace |
| Debug trace surface | Explain request-local execution for diagnostics and replay comparison | Control decisions, contract checks, plan node refs | Debug events with stable ids, reason codes, and safe payloads | Diagnostic trace remains bounded away from raw PHI, waveform payloads, and secrets |
| Stream and stateless analyzer hosts | Host downstream operational contours over the runtime library | Runtime library, deployment context, stream or request-local ingress | Analyzer-specific service behavior and evidence | Owned by downstream systems papers, not by this article |
Compute Core
The compute core is the deterministic execution subsystem. It validates the in-memory runtime catalog, derives an immutable execution plan, accepts one normalized request, creates request-local mutable state, executes work in deterministic order, commits staged facts only at visibility barriers, assembles an owning response, and emits deterministic evidence.
The key design principle is separation between shared immutable engine state and request-local mutable state. The immutable engine can be reused across requests because it contains catalog-derived plan data, logical order keys, binding metadata, audit templates, debug templates, and control metadata. The request context holds scratch data, staged writes, committed fact snapshots, audit buffers, debug buffers, control facts, and response-owned storage. No mutable clinical state crosses from one request into the next.
Scheduling is deterministic. The execution order is derived from layer order, schedule tiers, dependencies, and stable logical keys. Observable output order, audit sequence, debug sequence, and response hash must not depend on wall-clock timing, thread identity, queue order, pointer address, or hash-map iteration. Future optimization or parallel execution can be admitted only if it preserves the same committed facts, audit order, debug order, and response hash for the same request, catalog, and configuration.
Runtime term references are carried as evidence identifiers, not interpreted as semantic authority. The compute core can preserve those compiled identifiers through catalog validation, request execution, response assembly, audit material, debug trace, and runtime evidence projection. It does not join them back to the registry or trace during execution; that diagnostic join belongs to the companion term-traceability method.
Staged writes are central to the compute-core contract. Executable units do not write directly into the committed fact snapshot. They stage writes in request-local buffers, then the barrier commit merges staged writes deterministically. Downstream units see only committed facts. Skip, cancellation, degrade, and abort paths discard or preserve staged writes only according to declared policy and evidence rules.
Safety Kernel
The safety kernel is the deterministic runtime control subsystem. It admits or rejects work, applies runtime gates, and records why a path ran, skipped, degraded, aborted, or failed closed. Its responsibilities include binding resolution, prerequisite checks, age/sex/context applicability, module and license scope, dependency validation, schedule-tier validation, rule and condition control flow, staged-write visibility, control-fact emission, and response assembly decisions.
Its decision flow is explicit. Inputs are the engine plan, request context, committed facts, module and license scope, binding metadata, and declared policies. Gate checks evaluate binding availability, prerequisites, applicability, module scope, schedule consistency, declared reads and writes, and evidence obligations. The resulting decision class is one of run, skip, degrade, abort, or fail closed. Each decision emits control facts and debug evidence, links to audit when an audit event is required, and constrains response assembly so the response states whether the request completed normally, degraded under declared policy, aborted, or failed closed.
The safety kernel is a runtime risk-control surface [2], not a clinical validator. It can show that a request ran inside declared runtime contracts, that unsupported conditions were rejected or degraded, that placeholder medical algorithm bodies did not emit clinical facts, and that control decisions were evidenced. Clinical efficacy, diagnostic thresholds, and product claims require separate medical, validation, quality, and governance evidence.
This article’s safety-kernel role is the stateless admissibility role. A downstream stateful analyzer may reuse safety-kernel control to apply human-accepted commands in a HITL contour, but that path is not part of ordinary stateless analysis and does not make the runtime library a human decision maker.
Fail-closed behavior is the safety kernel’s default for integrity and admissibility violations. Controlled degradation is narrower: it is allowed only when a declared policy in the validated runtime catalog or release-bound runtime configuration permits a bounded degraded response, and the degraded state is visible in response metadata, control facts, audit links when applicable, and debug evidence. Undeclared degradation is not an alternative to fail-closed execution. When the runtime catalog is malformed, a dependency is unresolved, a required binding is unknown, a clinical body is required but unavailable, a request violates shape constraints, or required evidence is missing, the system refuses partial authoritative output and emits structured diagnostics instead.
Compute Core And Safety Kernel Inside The Runtime Library
Figure 2. Compute core and safety kernel inside the runtime library. The diagram separates immutable engine construction, request-local stateless execution, safety-kernel gates, staged writes, barrier commits, response assembly, and evidence emission.
Figure 2 receives the validated runtime catalog view from the service host. The runtime library builds an immutable compute engine from that catalog and creates a stateless request context for a single invocation. The safety kernel checks bindings, prerequisites, applicability, module scope, and declared control policies before deterministic compute steps run. Compute steps stage writes in request-local buffers. Barrier commits make staged facts visible in deterministic order, after which response assembly creates the owning response and deterministic hash. If a gate rejects execution, the safety kernel emits skip, degrade, abort, or fail-closed evidence rather than allowing partial or unsupported output.
Service-host / Runtime Library Boundary
The service host owns everything that depends on the operational environment. It selects the released bundle according to deployment evidence, verifies digest and schema evidence [6,7], reads files when needed, manages network ingress, handles transport security, owns secrets, decodes external payloads, normalizes requests, and projects runtime outputs to audit, debug, result, metric, or evidence channels. It selects and verifies the released bundle, but it does not own semantic meaning or in-memory execution. It may host stream or batch contours, but those contours are downstream concerns.
The runtime compute-core library owns only in-memory execution. It receives the materialized runtime catalog view and normalized request, validates catalog admissibility for its execution contract, creates or uses an immutable engine, executes stateless analysis, and returns an owning response plus request-local evidence. Environmental access, source selection, and credential handling remain service-host responsibilities.
This boundary prevents semantic ownership drift. If the runtime library selected or authenticated its own source authority, it would become a competing authority surface. If the service host invented clinical facts outside the compute core, deterministic runtime evidence would fragment. The boundary keeps the host responsible for operational integration and the runtime library responsible for deterministic request execution.
Stateless Analysis Evidence
The current evidence slice supports a stateless-analysis claim, not a product clinical-coverage claim. It shows an implemented compute-core library artifact, deterministic inline execution, request-local state, immutable engine behavior, control-plane algorithms, placeholder medical algorithm bodies that intentionally emit no clinical facts, debug trace, audit/control evidence, and one promoted safety-neutral signal-duration body.
The bounded evidence chain is deliberately narrow. The implemented library artifact accepts a materialized runtime catalog, validates catalog admissibility, creates or reuses an immutable engine, executes one normalized request through stateless analysis, stages writes, commits them at a barrier, emits debug and audit evidence, projects runtime evidence, and exercises a safety-neutral signal-duration body. This chain supports the runtime architecture claim while leaving production readiness, clinical coverage, and release-chain proof outside scope.
The signal-duration body is intentionally modest. It demonstrates governed body binding, declared writes, deterministic execution, and evidence emission for a safety-neutral primitive. It does not validate ECG diagnostic interpretation, rhythm classification, ischemia detection, clinical adequacy, or product-level diagnostic coverage.
Residual gaps remain visible. Clinical algorithm body coverage is limited. Production fixture coverage, memory-safety and zeroization evidence, formal clinical validation, broader deployment evidence, and future optimization or parallel execution evidence are outside the current stateless-analysis claim. The article therefore treats implementation evidence as bounded and reviewer-facing.
Table 2: Stateless Analysis Evidence and Residual Gaps
Table 2. Stateless analysis evidence and residual gaps
| Evidence item | Current claim | Reviewer meaning | Residual gap |
|---|---|---|---|
| Implemented compute-core library artifact | A runtime library artifact exists for deterministic compute-core execution | The article is implementation-backed, not only conceptual | Does not demonstrate production deployment readiness |
| Immutable engine | Engine state is derived from the runtime catalog and shared across requests | Cross-request mutable clinical state is outside the engine | Requires continued conformance tests as catalog shape expands |
| Request-local state | Scratch, staged writes, committed facts, audit buffers, debug buffers, and response storage are request scoped | Stateless analysis is bounded to one normalized request | Memory-safety, leak, and zeroization evidence must mature for production claims |
| Deterministic ordering | Layer/tier/dependency/logical-key ordering controls response, audit, and debug order | Replay comparison can distinguish behavior changes from scheduling noise | Future optimization or parallelism needs equivalence evidence |
| Safety-kernel gates | Binding, prerequisite, applicability, module scope, skip/degrade/abort, and fail-closed decisions are evidenced | Unsupported execution paths can be rejected or explained | Gate coverage must grow with real clinical bodies |
| Placeholder medical algorithm bodies | Placeholder bodies validate contracts and evidence behavior without clinical outputs | Runtime control can be tested before clinical bodies are complete | No clinical diagnostic coverage is claimed from placeholder bodies |
| Safety-neutral signal-duration body | One promoted primitive demonstrates body binding, declared writes, and deterministic evidence | Demonstrates the runtime path for a real body | Does not validate broader ECG interpretation |
| Audit and debug evidence | Audit and debug surfaces record runtime behavior with distinct responsibilities | Reviewers can separate durable audit from diagnostic trace | Debug trace must not be treated as reconstructed audit |
Evidence, Audit, and Debug Trace
Runtime evidence has multiple surfaces because one surface cannot safely serve every purpose. The runtime library emits deterministic audit material as part of response assembly. The service host or audit surface publishes that material to durable audit infrastructure, where it may become a non-repudiable audit record under the deployment’s append, digest, and retention contract. Debug trace is request-local diagnostic evidence for replay comparison, contract checks, reason codes, control decisions, and no-output explanations. Runtime evidence projection normalizes these and other observed surfaces into downstream evidence artifacts.
Debug trace complements audit but does not replace it. When an audit event exists, debug trace can carry stable links to that event. If an audit event or audit ref is missing, the service host and downstream tools must not reconstruct it from debug trace. That rule preserves audit integrity and prevents diagnostic detail from quietly becoming authority. Provenance vocabulary and structured audit-event practice ground the distinction between evidence lineage and the artifact that carries a specific audit record [4,5].
The evidence payload must be privacy and security bounded. Debug trace may contain stable identifiers, contract names, descriptor or rule refs, digest refs, reason codes, counters, schedule decisions, and control decisions. It must not contain raw waveform samples, raw PHI fields, patient names, secrets, TLS material, message-broker credentials, hardware-key material, raw request payloads, or filesystem paths that expose secrets.
Fail-closed Semantics
Fail-closed execution prevents partial or unsupported behavior from masquerading as valid clinical output. The safety kernel fails closed when runtime integrity, catalog admissibility, request shape, required binding availability, control evidence, or mandatory trace obligations cannot be established. Controlled degradation is used only for declared, bounded policy paths whose degraded state is visible to response, audit, and debug surfaces. A fail-closed result is still useful evidence: it explains why the request did not produce a normal response and gives diagnostic surfaces enough structure for triage.
Table 3. Fail-closed condition map
| Condition | Detection stage | Runtime behavior | Evidence emitted | Reviewer meaning |
|---|---|---|---|---|
| Catalog schema or digest mismatch | Service-host verification or runtime catalog validation | Reject runtime basis | Structured startup or catalog error, audit/debug refs when available | Release/deployment or artifact-integrity issue |
| Duplicate identity | Runtime catalog validation | Reject engine creation | Duplicate-id diagnostic | Catalog projection is not admissible |
| Unresolved dependency | Engine plan validation | Reject engine creation | Dependency diagnostic | Compiled execution graph is incomplete |
| Dependency cycle | Engine plan validation | Reject engine creation | Cycle diagnostic | Execution order cannot be deterministic |
| Invalid schedule tier | Engine plan validation | Reject engine creation | Schedule-tier diagnostic | Runtime order contract is malformed |
| Unknown binding | Safety-kernel binding resolution | Fail closed when the binding is required; controlled degrade only under declared policy | Binding diagnostic, control fact | Runtime cannot dispatch a declared executable unit unless policy explicitly bounds the degraded path |
| Required clinical body unavailable | Safety-kernel binding resolution | Fail closed for affected execution path | No-output or unavailable-body diagnostic | Clinical-output claim is blocked |
| Invalid request shape | Request validation | Reject request or abort execution | Request-shape diagnostic | Input is not admissible for stateless analysis |
| Missing required debug event | Evidence validation | Mark execution evidence incomplete or fail the request according to policy | Debug-trace gap diagnostic | Replay and coverage evidence are incomplete |
Worked Runtime Example
Consider a safety-neutral signal-duration primitive. The compiled bundle contains a runtime catalog row for a signal-duration body, runtime term references for the compiled identity involved in the request, a declared write to a quality fact representing signal duration in milliseconds, control metadata, audit templates, debug templates, and binding metadata. Release and deployment evidence identify the selected bundle, and the service host checks schema and digest evidence before materializing the runtime catalog view.
The runtime compute-core library receives the catalog view and a normalized request. During engine creation, the compute core validates catalog identity, dependency order, schedule tier metadata, declared reads and writes, binding availability, and debug/audit template requirements. The immutable engine records the deterministic plan. No request data is stored in that engine.
During stateless request execution, the request context holds the incoming signal metadata, committed fact snapshot, staged write buffer, audit buffer, debug buffer, and response-owned storage. The safety kernel admits the signal-duration primitive only if its prerequisites, module scope, and binding contract are satisfied. If a declared controlled-degradation path applies, the response records that state; otherwise integrity and admissibility failures fail closed. The deterministic compute step computes the duration primitive, stages the declared quality fact, and emits debug events for start, input contract check, output contract check, and completion. At the barrier, the staged write is committed in deterministic order.
Response assembly reads committed facts and produces an owning response with execution metadata, degradation state if any, runtime term references, audit material, debug trace, and deterministic hash. The service host publishes audit material through the audit surface and projects the response, audit refs, and debug refs into downstream runtime evidence. This example demonstrates the runtime path for a safety-neutral primitive: compiled catalog binding, immutable engine planning, stateless request execution, staged write and barrier commit, deterministic response assembly, and evidence projection. It does not validate sinus rhythm, ischemia, morphology, or any broader ECG diagnostic conclusion.
Evidence Chain For A Stateless Runtime Request
Figure 3. Per-request evidence payload chain for a stateless runtime request. The diagram follows one normalized request from request id, configuration fingerprint, and selected bundle digest through stateless execution, response hashing, audit/debug evidence, runtime term references, runtime evidence projection, and diagnostic-contour handoff.
Figure 3 focuses on one request’s evidence payload rather than the full lifecycle ownership flow. The chain starts with the request identifier, configuration fingerprint, and selected bundle digest. The service host turns external ingress into a normalized request and materializes the runtime catalog view. The compute-core library creates or reuses an immutable engine, then creates a request-local context for stateless analysis. Safety-kernel decisions determine which compute steps can run, skip, degrade, abort, or fail closed. Response assembly produces the deterministic response hash, runtime term references, audit material, and debug trace. The service host projects audit refs, debug refs, response hashes, and runtime term references into runtime evidence and, when needed, hands the evidence to the diagnostic contour.
Limitations and Non-claims
This article makes no clinical efficacy claim and no registration-grade validation claim. It does not claim autonomous diagnosis, full ECG algorithm coverage, full production deployment readiness, or complete product safety case closure. It does not claim that the runtime compute-core library selects, loads, authorizes, or authenticates semantic authority. It does not claim that the runtime library reads files, accesses the network, uses message brokers, handles secrets, or owns release-chain proof.
The safety kernel is a deterministic runtime admissibility and evidence mechanism, not a substitute for clinical validation, quality-system approval, or risk-management sign-off. The safety-neutral signal-duration example demonstrates a bounded runtime path, not diagnostic adequacy. Debug trace is diagnostic evidence, not non-repudiable audit, and it must not expose raw waveform payloads, raw PHI, credentials, or secret-bearing paths.
Batch and stream hosting are downstream concerns. This article defines the runtime library boundary that such hosts may use; it does not claim service-host scalability, stream scheduling, batch orchestration, or release-chain continuity.
Conclusion
A deterministic compute core and deterministic safety kernel form the runtime hinge between compiled executable knowledge and auditable execution. The compute core turns an immutable runtime catalog and one normalized request into deterministic stateless analysis. The safety kernel controls runtime admissibility, fail-closed behavior, and evidence. Together they preserve separate semantic, release, host, and runtime authorities while giving reviewers enough evidence to understand what ran, why it ran, what was rejected, and what remains outside the current claim.
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: Runtime library boundaries for Compute core and Safety kernel.
Funding
The work was funded by RTLAB.
References
- IEC 62304:2006/AMD 1:2015, Medical device software - Software life cycle processes. International Electrotechnical Commission.
- ISO 14971:2019, Medical devices - Application of risk management to medical devices. International Organization for Standardization.
- ISO 13485:2016, Medical devices - Quality management systems - Requirements for regulatory purposes. International Organization for Standardization.
- T. Lebo, S. Sahoo, and D. McGuinness, eds., PROV-O: The PROV Ontology. W3C Recommendation, 2013. https://www.w3.org/TR/prov-o/
- HL7 International, FHIR Resource AuditEvent, Release 4. https://hl7.org/fhir/R4/auditevent.html
- A. Rundgren, B. Jordan, and S. Erdtman, JSON Canonicalization Scheme (JCS). RFC 8785, 2020. https://www.rfc-editor.org/rfc/rfc8785
- JSON Schema, Draft 2020-12. https://json-schema.org/draft/2020-12