Closed-loop Governance of Formalizable Knowledge in Clinical Information Systems

Authors

1. Prozorov A.A., Director of Technology, RTLAB; Architect, Sbertech; ap@rtlab.ru;
2. Redkin I.V., Director of Science, RTLAB; MD, PhD; Leading Research Scientist, V.A. Negovsky Research Institute of General Reanimatology, FRCC RR; iredkin@rtlab.ru;
3. Bakhvalov I.M., General Director, RTLAB Oncology; ibakhvalov@rtlab.ru;

Abstract

Objective. To describe a closed-loop governance method for formalizable knowledge that preserves the unity of authorized semantics across compilation, deployment, observation of system behavior, and subsequent governed refinement.

Materials and Methods. This is a methodological and conceptual-architectural article. The analysis addresses recurrent gaps between authorized semantics, compiled artifacts, release identity, runtime evidence, and post-deployment correction in knowledge-intensive clinical software systems. Public standards and specifications related to ontologies, knowledge graphs, constraint validation, medical information models, terminologies, artifact provenance, medical-software lifecycle governance, and quality-management systems were used as the external basis [1-12]. The authoring corpus was used as background synthesis rather than as an independent public citation layer.

Results. An invariants-oriented model of the closed governance loop is proposed. The model distinguishes one source of authorized semantics, an explicit authorization-space boundary, deterministic compile-time projection, release-bound artifact handoff into the execution contour, structured runtime evidence, and a governed refinement path that returns changes into the same authority space. It is shown that local corrections to code, gateway configuration, rule files, or runtime registries must not become independent sources of semantic truth. The method also distinguishes authoritative semantic artifacts, compile-time derived artifacts, release-bound artifacts, runtime evidence artifacts, governance artifacts, and closure artifacts.

Conclusion. Closed-loop governance of formalizable knowledge may be treated as a methodological basis for verifiable clinical software systems, including OR/ICU supervisory contours, cardiology-specific assessors, and other domain-bounded extensions. The method does not prove clinical efficacy of any particular system, does not constitute registration-grade validation, and does not claim completeness of the compute core, automated release contour, or trust chain. Its value lies in preserving one inspectable artifact chain from governed semantics to execution, runtime evidence, and subsequent refinement.

Keywords: formalizable knowledge; closed governance loop; authorized semantics; source of authorized semantics; knowledge governance; clinical software; artifact provenance; runtime evidence; governed refinement; auditability

Abbreviations and Terminological Conventions

ICU - intensive care unit; OR/ICU - operating room and intensive care unit; IR - intermediate representation; OWL - Web Ontology Language; RDF - Resource Description Framework; SPARQL - RDF query language; SHACL - Shapes Constraint Language; FHIR - Fast Healthcare Interoperability Resources; SNOMED CT - Systematized Nomenclature of Medicine - Clinical Terms; PROV-O - PROV Ontology; SLSA - Supply-chain Levels for Software Artifacts.

In this article, formalizable knowledge denotes the governed semantic basis before execution. Unlike executable knowledge, which is the operational descendant of authorized semantics in the bedside contour, formalizable knowledge belongs to the pre-execution layer: it defines what the system is entitled to mean, classify, infer, recommend, or pass into downstream logic.

The term source of authorized semantics denotes a governed knowledge representation that has passed the required authorization procedures and can therefore be used for compilation, release, and subsequent runtime-evidence linkage. The artifact name Authorized snapshot is retained in English within the prose as the stable identifier of that architectural object.

1. Introduction

Knowledge-intensive clinical software systems are increasingly used in settings where clinical meaning, response time, and patient-safety responsibility are tightly coupled. These settings include the operating room, the intensive care unit, cardiac-anesthesia contours, high-risk patient monitoring systems, and domain-specific assessors. In such systems, clinical rules, semantic constraints, terminology alignments, safety policies, and mappings into operational logic may begin as governed knowledge models but later pass into code, local configuration, integration gateways, or manual correction.

That transition is not problematic in itself. The problem arises when the source semantics, compiled artifacts, deployed behavior, and post-deployment corrections diverge into multiple parallel sources of truth. Under such conditions, the system may remain outwardly functional, yet it becomes difficult to determine which semantic basis was active, how it was projected into executable logic, which release reached the execution contour, and whether a post-deployment correction belongs to the knowledge model, the projection layer, the release boundary, or local service behavior.

In clinical environments, such uncertainty is especially consequential. An acute-care supervisory system, a cardiology assessor, or a respiratory module may all exhibit the same failure mode: knowledge is described in one place, transformed in another, deployed through a third surface, executed in a fourth contour, and corrected in a fifth. If those stages are not tied together by explicit governance, each stage begins to claim its own authority. As a result, local rules, gateways, service catalogs, or runtime corrections may become the de facto owners of clinical meaning.

The method proposed in this article is based on the opposite principle. Formalizable knowledge should move through one closed loop: from the source of authorized semantics through an explicit authorization boundary, deterministic compile-time projection, release-bound deployment, and structured runtime evidence to a governed refinement path that returns changes into the same authority space. The purpose of this loop is not to prove the clinical efficacy of a particular product but to preserve authorship, traceability, and governability of meaning across the full lifecycle of a clinical software system.

The aim of this article is therefore to describe a closed-loop governance method for formalizable knowledge and to define the invariants that prevent clinical semantics, deployed logic, and post-deployment correction from collapsing into parallel sources of truth.

2. Materials and Methods

This is a methodological article. The object of analysis is not a clinical outcome, not the efficacy of a therapeutic intervention, and not validation of a specific software product, but the governed transition from formalizable semantics to executable and reviewable artifacts.

The methodological work was performed in several stages. First, recurring gaps arising during operationalization of formalizable knowledge were identified: the provenance gap, the traceability gap, the closure gap, and the extensibility gap. Second, the minimal invariants required to preserve one authority chain were formulated. Third, the classes of artifacts that must be distinguished in the public lifecycle description were defined: authoritative semantic artifacts, compile-time derived artifacts, release-bound artifacts, runtime evidence artifacts, governance artifacts, and closure artifacts. Fourth, the model was deliberately bounded so that the governance method would not be conflated with clinical efficacy, compute-core completeness, or sufficiency of the automated release chain.

The external evidence basis includes standards and specifications used for formal knowledge representation, constraint validation, clinical terminology, artifact provenance, and medical-software lifecycle governance. OWL, RDF, SPARQL, and SHACL support machine-checkable representation and validation of semantic constructs [1-4]. FHIR, SNOMED CT, and openEHR provide important reference points for medical data structure, terminological consistency, and clinical information models [5-7]. PROV-O and the JSON Canonicalization Scheme are relevant to artifact provenance and stable identity [8, 9]. SLSA, IEC 62304, and ISO 13485 serve as external reference points for release discipline, medical-software lifecycle governance, and quality-management systems [10-12].

3. Why a Closed Governance Loop Is Needed

The need for a closed governance loop is defined by four recurring gaps.

The first is the provenance gap. A development team may retain access to source files, knowledge graphs, or rule sets, yet still be unable to show which exact authorized semantic state produced the executable artifact that actually reached the clinical contour. Without such linkage, provenance remains a descriptive account rather than a reviewable proof. For safety-relevant systems, that is insufficient.

The second is the traceability gap. Even if a runtime bundle is built reproducibly, observed behavior may remain disconnected from the knowledge object that justified it. Alerts, classifications, recommendations, and escalation paths may all be visible, while the relation between the observed effect and the exact semantic basis remains incomplete. This hinders root-cause analysis and encourages local fixes instead of governed restoration of the chain.

The third is the closure gap. Operational evidence often reveals semantic shortcomings only after deployment. If those shortcomings are corrected directly in service-local code, configuration, or runtime registries, the system may improve locally but loses semantic closure. Operational experience changes behavior without returning through the authority space that should govern meaning.

The fourth is the extensibility gap. When one governed knowledge model is extended into new domains, it may gradually fragment. Cardiology, respiratory, hemodynamic, or workflow-oriented modules can accumulate their own partial mappings and review practices. The system becomes larger, but its governance invariants become weaker.

The closed governance loop is the method that addresses these four gaps at once. It is not merely provenance after the fact, and it is not merely validation before deployment. It is the insistence that semantic authority, projection, release, runtime evidence, and refinement belong to one lifecycle, and that each public artifact in that lifecycle is explicit enough to be reviewed on its own terms.

4. Source of Authorized Semantics and Authorization-space Boundary

The method begins with the source of authorized semantics. In this article, this term denotes the governed representation of knowledge that defines what the system is entitled to mean, infer, classify, recommend, or bind into downstream operational logic. Such authority may be expressed through ontologies, formal knowledge models, controlled terminology relations, mapping specifications, policy constraints, or equivalent machine-checkable structures [1-4].

Formalizable knowledge in this article therefore refers to the governed semantic basis before execution. It is distinct from executable knowledge as defined in the companion article Executable Knowledge as a Medical-Informatics Object in the OR/ICU Supervisory Ecosystem. Executable knowledge is the operational descendant of authorized semantics in a bedside supervisory setting; formalizable knowledge is the pre-execution semantic object whose authority must survive authorization, projection, deployment, observation, and correction.

Semantic authority is not preserved merely because the source representation is explicit. It becomes governable only when the write surface is singular and the transition into execution is disciplined. For that reason, the method requires an explicit authorization-space boundary. Not every draft graph, imported term, or provisional mapping is eligible for projection. A Semantic Draft Set may carry terms, descriptors, imports, and other scope-bearing semantic content, but it remains pre-authority material. A Semantic Validation Report may prove that scope, imports, and model constraints have passed fail-closed checks, yet validation alone does not authorize release. Only an Authorized snapshot is eligible for compilation, release, and later evidence correlation.

The Authorized snapshot is not merely a convenient export. It is the governed semantic basis that a responsible authority is willing to put into effect. In practice, that means its scope is explicit, its invariants have been checked, its imports are controlled, and its identity is stable enough to be referenced by downstream artifacts. Named-graph partitioning and domain-scoped bundles are useful because they allow extensions to remain explicit rather than silently bleeding into one another [1, 4].

5. Compile-time Projection and Provenance

Once a semantic basis has been authorized, the next requirement is deterministic compile-time projection. Formalizable knowledge is not operational merely because it exists in a semantic store. It becomes operational only when the system can produce a bounded executable representation whose fields, terms, and effects are derived from the authorized source through explicit mapping rules rather than through informal re-expression.

Such projection must remain fail-closed. If a machine-significant construct lacks a governed mapping, compilation should stop rather than silently emit a partial runtime. This is where ontology and terminology standards become pragmatically important: they provide a machine-readable substrate for explicit projection rules, validation, and constrained imports rather than leaving the runtime to improvise meaning [1-4][6][7].

Projection also requires provenance. A released artifact is governable only if it can be bound back to the semantic basis and the projection policy that produced it. In the terminology used across this series, that binding is carried by a family of compile-time derived artifacts: Compiled IR Bundle, IR Term Registry, IR Term Trace, Authority Refs, and Lineage Receipt. Together they form the digest spine that connects authorized semantics to execution-ready deployment surfaces.

Authority Refs are generated during compile-time projection from the same governed semantic basis and trace surfaces that emit the registry and trace. They are not independent authority artifacts. Their role is narrower: they preserve stable, joinable references from released runtime behavior back to the authorized semantic basis. Lineage Receipt is equally bounded. It is neither runtime evidence nor semantic authority; it is the safe-reference digest spine that proves how the projection set was assembled and released.

The proposed lifecycle can therefore be represented as a sequence of governed transitions from pre-authority material to the authorized snapshot, then to compilation, release, observation, and refinement.

Figure 1. Closed governance loop for formalizable knowledge

The classes of artifacts are separated deliberately in the figure. Authorized snapshot is the last authoritative semantic artifact before execution. Compiled IR Bundle, IR Term Registry, IR Term Trace, Authority Refs, and Lineage Receipt are compile-time derived artifacts. Released Deployment Set belongs to the release-bound handoff into execution. Runtime Evidence Report is a runtime evidence artifact. The candidate, decision, packet, request, payload, validation, and approval artifacts belong to the governance path. Authority Write Evidence, Next Authorized snapshot, and Authority Closure Evidence belong to the post-write closure path.

6. Release-bound Deployment

Deployment in this method is not merely file transfer. It is a release-bound commitment to a specific semantic-to-execution state: which compiled bundle is active, which capabilities are enabled, which deployment identity applies, and which event stream should later serve as runtime evidence. If deployment is not linked to the same provenance chain, formalizable knowledge loses its reviewable relation to operational reality.

Released Deployment Set therefore represents more than a packaging convenience. It is the release-bound handoff of the compiled artifact family into the execution contour. Release Manifest Capture matters as a supporting release artifact because it preserves information about the release wave and compatibility state, but it does not replace the semantic authority chain itself.

In clinical software, this distinction is especially important because deployment conditions may vary by device family, integration surface, and local operating policy. An organization may be able to show that some package was built, yet still be unable to show that this exact package, in this exact configuration, and with this exact semantic basis produced the observed behavior. In the OR/ICU contour, where system behavior may influence interpretation of physiological status, recommendations, and escalation, such uncertainty is unacceptable. The method does not require deployment conditions to be identical everywhere. It requires only that released behavior remain bound to the same authorized source and to the same governable provenance family.

7. Artifact Lifecycle

The artifact lifecycle becomes reviewable only when the responsibilities of the artifacts are explicitly separated.

Table 1. Lifecycle matrix of key artifacts

Artifact	Class	Purpose	Responsibility Boundary
Semantic Draft Set	candidate authoritative semantic artifact	Pre-authority authoring material for governed meaning	Belongs to domain authors and the semantic authoring contour, not to the execution contour
Semantic Validation Report	candidate authoritative semantic artifact	Proof that scope, import, and model checks have passed	Does not authorize release; serves as input to authorization
Authorized snapshot	authoritative semantic artifact	Last authorized semantic basis before execution	Acts as the authority source for compilation and evidence linkage
Compiled IR Bundle	compile-time derived artifact	Deterministic operational projection	Does not authorize semantics and does not carry runtime observations
IR Term Registry / IR Term Trace	compile-time derived artifacts	Term registry and term-level provenance trace	Used for linkage and review, but not themselves a source of truth
Authority Refs	compile-time derived artifact	Stable references from released behavior back to the authorized artifact	Are neither a correction payload nor an independent semantic layer
Lineage Receipt	compile-time derived artifact	Digest spine of provenance for the projection set	Used for provenance verification and release review
Released Deployment Set	release-bound artifact	Handoff of the compiled set into the execution contour	Belongs to release and deployment, not to semantic authoring
Release Manifest Capture	release-bound artifact	Capture of release-wave and compatibility information	Does not directly participate in semantic mutation
Runtime Evidence Report	runtime evidence artifact	Normalized runtime observations with safe references	Is not a second authority source and not a correction surface
Semantic Authority Refinement Candidate	governance artifact	Proposed semantic change justified by runtime evidence	Does not mutate the authority source
Diagnostic Classification Decision	governance artifact	Human-governed diagnostic triage result	Authorizes remediation drafting, but not graph mutation
Remediation Packet	governance artifact	Controlled remediation path	Is not yet an authority write payload
Governed Graph Update Request	governance artifact	Reviewable request for future mutation	Safe request surface, not the mutation itself
Governed Graph Update Payload	governance artifact	Canonical write payload	Produced only through the governed write path
Semantic Mutation Validation	governance artifact	Validation of request and payload under fail-closed policy	Validates, but neither approves nor applies
Semantic Mutation Approval	governance artifact	Separation-of-duties approval of the change	Approves, but does not write the graph
Authority Write Evidence	closure artifact	Proof that the authorized write was applied	Confirms the write, but does not automatically close the loop
Next Authorized snapshot	authoritative semantic artifact	Next governed snapshot after the write	Becomes the new input for subsequent compilation
Authority Closure Evidence	closure artifact	Verification that write, next snapshot, and trace surfaces support closure	Does not create a new authority state and does not apply the write

This matrix also fixes the documentation rule used throughout the series: a public artifact is considered sufficiently defined only when its purpose, composition, applicability boundary, and responsibility boundary are explicit. This is a methodological rule, not only an editorial one. It prevents artifacts from the compiler, execution contour, release path, or diagnostic tooling from becoming implicit substitutes for the source of authorized semantics.

8. Runtime Evidence and Term Join

Authorization, compilation, and release are not enough on their own. A closed governance loop also requires a disciplined account of what happened after deployment. That function is carried by Runtime Evidence Report. It is not a raw log dump and should not be treated as the message format of the runtime bus. It is a structured evidence artifact with safe references that allows the diagnostic contour to compare observed behavior with the currently authorized chain.

Such comparison is possible only if the report remains joinable to the released authority set. Authority Refs play the central role here. They are generated during compilation, included in the release-bound set, and then used during normalization of runtime evidence. IR Term Trace narrows the join down to the individual term, while Lineage Receipt preserves the release-bound digest spine that identifies which projection set was actually deployed.

Runtime evidence must refer to a released deployment set rather than to an abstract compiler output. If Authority Refs, release identity, or trace surfaces cannot resolve an observation back into the authorized chain, the evidence state must be recorded as unresolved or unbound. The system should not silently infer a match and then treat that inference as governed truth.

This part of the method aligns with the broader culture of structured provenance and evidence. PROV-O provides a general provenance vocabulary, while healthcare and lifecycle standards reinforce the need to preserve reviewable relations among event, context, actor, software component, and release [5, 8, 11]. Yet the existence of such external standards does not remove the need for a domain-specific Runtime Evidence Report; it only strengthens the principle that evidence must be designed as a first-class artifact.

9. Governed Refinement and Closure

Operational behavior may reveal shortcomings in authorized semantics, but it must not automatically change the authority source. The closed loop therefore requires a governed refinement path. The first element of that path is Semantic Authority Refinement Candidate. This is a structured change proposal justified by runtime evidence. It may contain affected terms, descriptors, evidence references, current Authority Refs, alternative explanations, and closure tests. However, a refinement candidate is not yet a write request.

The next step is Diagnostic Classification Decision. It records the result of governed diagnostic triage, the selected loop, the owner roles, and the target stage. Remediation Packet then turns the classified issue into a controlled remediation path with closure gates and owner responsibilities. This separation is necessary because a classified problem is not yet a write-ready authority mutation.

Next, Governed Graph Update Request is produced as a reviewable request with safe references to the intended mutation. Governed Graph Update Payload is the canonical write payload. Semantic Mutation Validation checks the request-payload pair against the base snapshot, named-graph allowlist, and safety policy. Semantic Mutation Approval records semantic mutation approval under separation of duties. Authority Write Evidence proves that the authorized write was in fact applied. Only after that can Next Authorized snapshot be rebuilt.

Closure completes the loop, but it does not replace it. Authority Closure Evidence verifies that the write evidence, the new authorized snapshot, the updated registry and trace surfaces, and the replay or regression checks support closure. This artifact neither applies the write nor creates a new authority state. It demonstrates that the governed change has completed the path from evidence to a new authorized state.

This separation of roles is a methodological invariant. Change proposal, classification, remediation preparation, payload validation, mutation approval, write application, and closure review are distinct responsibilities even when part of the path is automated. Without this separation, the loop quickly collapses back into local patching under a more careful name [11][12].

10. Domain Extension

The method must remain valid when one domain becomes many. A cardiology package, respiratory extension, hemodynamic module, or mixed supervisory contour may require its own terms, projection rules, and evidence surfaces. Even so, such packages must not become independent semantic republics.

The safest pattern is domain-scoped compilation over a shared metamodel or equivalent upper-level discipline. Shared structures define how descriptors, methods, policies, findings, evidence references, and refinement objects are formed. Domain-specific packages define which authorized content is projected into a given execution contour. Governed imports allow reuse across domains without silent coupling.

Runtime evidence should scale in the same disciplined way. Sessions that span multiple domains may correlate cardiology, respiratory, hemodynamic, and workflow evidence. Yet operational correlation does not require merging authority sources. Evidence can be analyzed together while semantic authority remains partitioned and governed.

This distinction is what allows the method to be used across clinical systems of different profiles. Acute-care supervisory systems and cardiology-specific assessors are useful examples, but they do not exhaust the method’s scope. The method is about preserving authorized meaning while scaling across domains rather than elevating one early domain into a universal template.

11. Discussion

The proposed method sits between a general theory of knowledge governance and a technical specification of a particular compiler. It defines the invariants that a governed semantic-to-execution transition must preserve: one source of authorized semantics; an explicit authorization-space boundary; deterministic compile-time projection; release-bound deployment identity; structured runtime evidence; governed refinement that returns changes into the same authority space; distinction among artifact classes; and explicit documentation of purpose, composition, applicability boundary, and responsibility boundary for every public artifact.

These invariants are especially important in clinical software because a failure of governance may appear not only as a technical defect but also as an incorrect interpretation of physiological status, an inappropriate recommendation, or unclear responsibility for behavioral change. Even so, the method should not be conflated with clinical validation. It does not show that a particular supervisory system improves outcomes, reduces complications, or safely performs autonomous actions. It defines a reviewable framework within which such systems may preserve semantic governability.

The method also does not claim that use of OWL, RDF, FHIR, SNOMED CT, openEHR, or related standards automatically satisfies these invariants. A system may use advanced semantic technologies and still lose authority through manual runtime overrides, undocumented mappings, side-channel releases, or rule forks inside service-local code. Standards support the method, but they do not enact it without lifecycle discipline.

Analogies to the software supply chain also require careful interpretation. Approaches such as SLSA normalize the idea of reviewable and signed artifacts [10]. This article, however, is not about build integrity. Its subject is the semantic layer: how meaning is governed before projection, during release, through runtime evidence, and back through governed refinement.

12. Limitations

This work is methodological and contains no clinical dataset, no prospective-study result, no statistical outcome analysis, and no registration-grade validation. Its conclusions therefore cannot be interpreted as proof of the clinical efficacy of any specific system.

The proposed artifact family describes governed order and responsibility boundaries, but it is not an exhaustive technical specification of the compiler, compute core, diagnostic analyzer, release pipeline, or trust chain. Those questions should be addressed in separate systems papers and verification studies.

In addition, the article does not claim that any software product using an ontology already possesses closed-loop governance. To satisfy the method, a system requires not only formalizable knowledge but also preservation of the authorization, projection, release, evidence, and governed-refinement chain.

13. Conclusion

Formalizable knowledge becomes methodologically unreliable when semantics, deployed logic, and post-deployment correction diverge into separate local authority sources. The method proposed here addresses that problem through a closed governance loop: one source of authorized semantics crosses an explicit authorization boundary, is deterministically projected into a release-bound artifact family, is observed through structured runtime evidence, and is refined only through governed return into the same authority space.

The practical value of the method is not that it removes all implementation risk or proves clinical efficacy. Its value lies in preserving one inspectable artifact chain across the full lifecycle of meaning in clinical software. In this way, OR/ICU supervisory systems, cardiology assessors, respiratory extensions, compiler formalisms, analyzers, and release systems can be discussed without losing sight of the central question: who retains authority over clinical meaning, and how does that meaning remain reviewable after execution?

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: closed-loop governance of formalizable clinical knowledge.

Funding

The work was funded by RTLAB.

References

1. W3C OWL Working Group. “OWL 2 Web Ontology Language Document Overview (Second Edition).” W3C Recommendation, 2012. https://www.w3.org/TR/owl2-overview/
2. R. Cyganiak, D. Wood, and M. Lanthaler, eds. “RDF 1.1 Concepts and Abstract Syntax.” W3C Recommendation, 2014. https://www.w3.org/TR/rdf11-concepts/
3. S. Harris and A. Seaborne, eds. “SPARQL 1.1 Query Language.” W3C Recommendation, 2013. https://www.w3.org/TR/sparql11-query/
4. H. Knublauch and D. Kontokostas, eds. “Shapes Constraint Language (SHACL).” W3C Recommendation, 2017. https://www.w3.org/TR/shacl/
5. HL7 International. “FHIR Release 4 (v4.0.1).” 2019. https://www.hl7.org/fhir/
6. SNOMED International. “SNOMED CT Starter Guide.” 2024 edition. https://www.snomed.org/
7. openEHR Foundation. “openEHR Specifications.” https://specifications.openehr.org/
8. T. Lebo, S. Sahoo, and D. McGuinness, eds. “PROV-O: The PROV Ontology.” W3C Recommendation, 2013. https://www.w3.org/TR/prov-o/
9. A. Rundgren, B. Jordan, and S. Erdtman. “JSON Canonicalization Scheme (JCS).” IETF RFC 8785, 2020. https://www.rfc-editor.org/rfc/rfc8785
10. Open Source Security Foundation. “Supply-chain Levels for Software Artifacts (SLSA).” Specification v1.0, 2023. https://slsa.dev/
11. IEC 62304:2006/AMD 1:2015. “Medical device software - Software life cycle processes.” International Electrotechnical Commission. https://www.iso.org/standard/64686.html
12. ISO 13485:2016. “Medical devices - Quality management systems - Requirements for regulatory purposes.” International Organization for Standardization. https://www.iso.org/standard/59752.html