Continuous chain of trust in the automatic closed-loop release of executable analyzer modules

Authors

1. Prozorov A.A., Director of Technology, RTLAB; Architect, Sbertech; ap@rtlab.ru;

Abstract

Objective: This paper defines a continuous chain-of-trust contour for executable analyzer modules after governed release. It closes the evidence gap between signed release evidence, deployment admission, runtime startup verification, and later diagnostic review.

Method: The paper is a methodological systems article with bounded trust-chain design evidence. It separates governed release, provenance attestations, signature and transparency evidence, dependency trust, deployment admission, runtime verification, and diagnostic trust signals. External sources ground software lifecycle and quality-system traceability, risk-control framing, provenance and audit analogies, canonical digests, schema-constrained evidence, SBOM and vulnerability exchange vocabulary, container image identity, secure software development, SLSA, in-toto, DSSE, and Sigstore-style signing and transparency logs [1-19].

Results: The article specifies a reviewable trust chain that joins release receipts, provenance attestations, artifact signatures, transparency-log evidence, SBOM and VEX material, deployment admission records, runtime startup verification, runtime evidence projections, and diagnostic trust signals without converting trust-chain evidence into semantic authority.

Conclusion: Continuous trust-chain evidence makes release-bound analyzer modules reviewable across release, deployment, runtime, and diagnostic contours while keeping semantic, release, deployment, runtime, and trust-verification responsibilities separate.

Keywords: continuous chain of trust; executable analyzer modules; SLSA; in-toto; DSSE; attestation; transparency log; deployment admission; runtime startup verification; continuous verification

Abbreviations And Terminology

Chain of trust: A reviewable chain of evidence that links trusted release outputs to attested build, signing, transparency-log, deployment, runtime, and diagnostic evidence.

Continuous chain of trust: A chain of trust that is rechecked across time and lifecycle stages rather than treated as a one-time release signature. It covers evidence freshness, revocation, key rotation, dependency posture, deployment admission, runtime startup verification, and diagnostic trust signals.

Trust subject: The artifact, identity, configuration, deployment input, or runtime observation about which a trust claim is made.

Trust claim: A bounded assertion about a trust subject, such as source identity, builder identity, artifact digest, SBOM digest, VEX status, signature verification result, transparency-log inclusion, or deployment admission status.

Attestation: A signed or otherwise verifiable evidence statement about one or more trust subjects. Attestation material may describe provenance, build inputs, dependency evidence, signing policy outcomes, or verification results.

DSSE envelope: A Dead Simple Signing Envelope used here as a general attestation-envelope pattern for binding a payload and signature material.

in-toto statement: An attestation statement pattern that identifies subjects and predicates for supply-chain evidence.

SLSA level: A supply-chain assurance vocabulary used to discuss build provenance and verification expectations. Conformance claims require explicit evidence and are not implied by use of the vocabulary.

Transparency log: An append-oriented log surface used to make signed artifact or attestation records discoverable and reviewable. Log inclusion supports verification, but log presence alone does not prove artifact adequacy.

VEX: Vulnerability Exploitability eXchange material that records whether known vulnerabilities are exploitable in a product or artifact context. VEX complements SBOM material; it is not a substitute for dependency provenance.

Continuous verification: Repeated verification of signatures, attestations, log inclusion, dependency posture, deployment admission, and runtime startup evidence across release and post-release time.

Global invariant: The trust-chain contour is not semantic authority. It verifies and carries evidence about released analyzer modules; it does not authorize graph semantics, perform direct graph or triple-store mutation, validate clinical efficacy, apply autonomous remediation, or replace human governance.

Introduction

Governed release makes analyzer modules reviewable at a publication point, but release-time evidence is not enough for long-running executable knowledge. A signed release receipt can become stale when a certificate is revoked, a dependency becomes newly vulnerable, a deployment selects an unexpected image, a service starts with a different compiled bundle, or runtime evidence cannot join back to the accepted release basis. The operational problem is therefore continuity: reviewers need to know not only what was released, but whether the release remains connected to source, builder, dependency, deployment, runtime, and diagnostic evidence.

This paper describes the continuous chain-of-trust contour that begins from governed release outputs and follows them through attestation, signing, transparency-log inclusion, dependency review, deployment admission, runtime startup verification, runtime evidence projection, and diagnostic trust classification. The contour does not re-open the release gate or repair semantic authority. It makes trust-chain breaks visible as evidence-backed diagnostic signals.

The contribution is an artifact-first pattern for continuous trust review of executable analyzer modules. It treats SLSA, in-toto, DSSE, Sigstore-style signing, transparency logs, SBOM, and VEX as vocabulary and evidence surfaces that can support reviewer-facing assurance.

Companion Articles

Automatic closed-loop release of trusted executable analyzer modules from a trusted knowledge snapshot owns governed release gates, release receipts, signed release evidence, release manifest capture, release-wave compatibility, and deployment handoff. This paper consumes those release outputs and extends them into continuous trust verification.

Implementing a stream analyzer for mixed named features and oscillograms owns stream/session/window analyzer architecture. Stateless rule-based analyzer for mixed named features and oscillograms owns request-local analyzer service architecture. This paper verifies the trust chain around released modules for those runtime contours; it does not redefine analyzer execution behavior.

End-to-end codified-term traceability for debugging and auditing the compiler and executable modules owns registry/trace joins and runtime evidence joins. This paper carries trust-chain evidence that can help reviewers decide whether an evidence join failed because of release, deployment, dependency, or runtime trust drift.

Authorization and diagnostic contour as universal infrastructure for executable-knowledge development and governance owns diagnostic classification, remediation packets, governed graph-update requests, authority write evidence, rebuilt snapshots, closure evidence, and human closure decisions. This paper may produce trust-chain diagnostic signals for that contour, but it does not close remediation.

Instant health assessment through an ECG example: interpreting mixed named terms and ECG oscillograms owns domain interpretation and ECG knowledge-graph claims. Trust-chain evidence in this paper is infrastructure evidence, not cardiology validation.

Materials And Methods

The paper is a methodological systems article with bounded trust-chain design evidence. The internal authoring basis consists of release-pipeline and release-evidence specifications, release receipt and release manifest capture material, analyzer runtime manuscripts, diagnostic-contour specifications, runtime evidence specifications, and the shared terminology canon. These internal materials guide the manuscript but are not cited as public references.

The external reference set is deliberately compact. IEC 62304, ISO 13485, ISO/IEC/IEEE 12207, and IEEE 828 ground software lifecycle, quality-system traceability, configuration management, and release engineering vocabulary [1,3,11,12]. ISO 14971 grounds risk-control framing without converting trust-chain evidence into clinical safety proof [2]. PROV-O and FHIR AuditEvent provide provenance and audit-event analogies for evidence records [4,5]. RFC 8785 and JSON Schema 2020-12 ground canonical digest and schema-constrained evidence framing [6,7]. CycloneDX, OpenVEX, and the OCI Image Specification ground SBOM, vulnerability-exploitability, and image identity vocabulary [8,10,19].

SLSA supplies the supply-chain assurance vocabulary; in-toto and DSSE supply attestation-layout vocabulary; Sigstore/cosign, Rekor, and Fulcio supply signing, transparency-log, and certificate-identity vocabulary [9,14-18]. The manuscript uses these sources to frame reviewable trust evidence; conformance and certification boundaries are stated in the dedicated SLSA and limitations sections.

Continuous Chain-of-trust Overview

The continuous trust-chain contour starts with governed release outputs and follows them into post-release verification. Its lifecycle spine is: release receipt → provenance attestations → artifact signatures → transparency-log inclusion → dependency trust review → deployment admission → runtime startup verification → runtime evidence join → diagnostic trust signal.

Figure 1. Continuous trust-chain contour. The trust-chain lifecycle begins from release outputs and adds provenance attestations, signatures, transparency-log inclusion, dependency trust review, deployment admission, runtime startup verification, runtime evidence projection, and diagnostic trust signals. Continuous verification loops through revocation, key rotation, and evidence staleness checks before deployment and runtime evidence are accepted for review.

Figure 1 separates release acceptance from trust continuity. A release receipt may be correct at promotion time, but later verification can still find stale evidence, a revoked certificate, missing log inclusion, dependency trust gaps, or runtime startup mismatch. Those findings are diagnostic signals, not semantic changes.

Table 1. Trust subjects, evidence, and authority boundaries.

Trust subject	Evidence surface	Verification question	Authority boundary
Source revision or source identity	Build provenance and release receipt	Which source material was used to build the analyzer module?	Source identity is not semantic authority.
Builder or build service identity	Provenance attestation, SLSA-aligned evidence, certificate identity	Which builder produced the artifact, and under which declared process?	Builder identity is not a clinical or semantic claim.
Compiled bundle	Release receipt, compiled-bundle digest, provenance attestation	Does the runtime artifact match the accepted executable-knowledge bundle?	Bundle trust does not repair registry/trace joins.
Analyzer image	OCI image identity, image digest, signature evidence	Does the deployed image match the released image?	Image verification is not analyzer correctness proof.
SBOM and VEX material	SBOM digest, VEX records, vulnerability posture	Are dependencies inventoried and are known vulnerabilities classified for the release scope?	Dependency evidence is not full transitive trust by itself.
Release receipt	Receipt digest, signature result, release manifest capture	Does the receipt still match release, image, bundle, configuration, and policy evidence?	Receipt verification does not reopen release promotion.
Transparency-log entry	Rekor-style entry, log inclusion proof, signed timestamp	Is the signed evidence visible in the expected transparency surface?	Log inclusion alone does not prove artifact adequacy.
Deployment admission	Verification policy and admission result	Did deployment accept only released image, bundle, configuration, and trust evidence?	Admission does not execute or clinically validate the analyzer.
Runtime startup verification	Startup materialization evidence and runtime evidence projection	Did the service start with the expected release-bound artifacts?	Runtime verification does not authorize semantic changes.
Diagnostic projection	Trust-chain diagnostic signal	Is the anomaly a trust-chain break, release/deployment mismatch, or another class of defect?	Diagnostic projection does not close remediation by itself.

Attestation Model

An attestation is useful only when its subject, predicate, issuer, and verification policy are explicit. The subject identifies the artifact or evidence object being described, such as a compiled bundle digest, image digest, SBOM digest, release receipt digest, or deployment admission record. The predicate describes the claim, such as source revision, builder identity, build materials, byproducts, dependency inventory, signature verification result, or runtime startup verification. The issuer identifies the system or role that produced the attestation. The verification policy states what must be checked before the attestation can be trusted for a given lifecycle stage.

This model mirrors provenance and audit-event principles: the evidence should state what happened, to which subject, under which identity, and with which context [4,5]. The trust chain then binds that evidence with canonical digests and schema-constrained records so that reviewers can reproduce the joins [6,7].

The model intentionally avoids broad proof language. A build provenance attestation can show that an artifact was produced by a declared builder from declared materials. It does not prove clinical adequacy, semantic correctness, absence of all vulnerabilities, or compliance with a supply-chain maturity level.

SLSA And in-toto Boundary

SLSA provides a vocabulary for supply-chain threats, build provenance, and assurance levels [14]. In this paper, SLSA is used to describe what evidence a reviewer would need to inspect: source identity, build service identity, build provenance, artifact identity, and verification policy. The paper does not claim that the project reaches a SLSA level or satisfies SLSA conformance.

in-toto provides a pattern for supply-chain statements and layout-oriented reasoning about artifact production [15]. DSSE provides an envelope pattern for signing attestations [16]. Together, they give the trust-chain contour a disciplined way to describe attestation subjects and predicates, but they do not make the chain complete by themselves. Completeness depends on the actual coverage of source, build, dependency, release, deployment, runtime, and diagnostic evidence.

The key boundary is reviewability rather than automatic trust. A release may include an in-toto-style provenance statement, a DSSE envelope, and a signed receipt, and still fail continuous verification because the certificate expired, the log inclusion proof is missing, the dependency posture changed, or runtime startup evidence no longer matches the release handoff.

Transparency Log And Signature Verification

Signature verification answers whether an artifact or attestation was signed according to the declared policy. Transparency-log verification answers whether that signed evidence is visible in the expected log surface. Sigstore/cosign supplies signing and verification vocabulary; Rekor supplies the transparency-log pattern; Fulcio supplies certificate-identity vocabulary for keyless signing scenarios [9,17,18].

The trust-chain contour records signature verification results, certificate identity, signed timestamp, log entry identity, and log inclusion proof when those surfaces are part of the declared policy. These records support reviewable continuity: reviewers can ask whether the same release receipt, image digest, SBOM digest, and attestation bundle remain verifiable after release.

Transparency is not adequacy. A malicious, stale, or clinically irrelevant artifact can still be signed and logged. The contour therefore treats signature and log evidence as necessary review inputs for trust-chain classification, not as sufficient proof of correct analyzer behavior.

Figure 2. Attestation and transparency evidence flow. A trust subject is wrapped in signature or DSSE-style evidence, verified against certificate identity and timestamp, checked for transparency-log inclusion, and reduced to a verification-policy outcome. The result is a trust-chain evidence bundle that can be joined to release, deployment, and runtime evidence.

Figure 2 shows why signature verification and transparency-log verification are separate steps. Signature evidence may be present while log inclusion is missing, or log inclusion may be present while the verification policy rejects the certificate identity or timestamp.

Verification Policy And Outcomes

Continuous trust review is operational only when evidence is reduced to explicit outcomes. The trust evidence bundle carries release receipt digest, image digest, SBOM digest, attestation subjects and predicates, signature verification results, certificate identity, signed timestamp, log inclusion proof, dependency posture, and declared trust exceptions. A verification policy states which evidence is required for a lifecycle stage and which failure classes block admission, require review, or create a diagnostic signal.

The verifier evaluates that bundle against the policy and emits a verification result. A verified result can support deployment admission; a missing, stale, revoked, or mismatched result produces blocked evidence or a diagnostic trust signal; an accepted exception must be recorded as trust exception evidence. This paper verifies deployment admission evidence and its continuity. It does not own deployment orchestration, scheduling, rollout, rollback, or service materialization.

The SLSA vocabulary is used here as SLSA-aligned evidence vocabulary: source identity, builder identity, build provenance, artifact identity, and verification policy. It is not a SLSA level or conformance claim. The same distinction applies to in-toto and DSSE: they structure attestations, while verification outcomes depend on declared policy and actual evidence coverage.

Transitive Dependency Trust

SBOM material lists software components and dependencies; VEX material records whether known vulnerabilities are exploitable in a specific product or artifact context [8,19]. These two evidence surfaces help reviewers distinguish a dependency inventory gap from a vulnerability triage gap. They do not by themselves establish transitive dependency trust.

Transitive dependency trust requires additional evidence: dependency provenance, dependency attestation, vulnerability posture, update policy, waiver evidence, and continuous verification of newly disclosed vulnerabilities. A dependency inventory gap means a component required for review is missing from the SBOM. A missing dependency provenance condition means the component is listed but lacks source, build, or attestation evidence. A known exploitable vulnerability means the dependency posture should block admission or require explicit exception evidence. A non-exploitable vulnerability with VEX rationale can support review when the rationale is current and scoped to the released artifact. A stale VEX condition means the exploitability statement no longer satisfies freshness or policy expectations.

The trust-chain contour therefore treats dependency evidence as living evidence. SBOM and VEX material support release review, deployment admission, and diagnostic classification; they do not establish full transitive dependency trust on their own. Dependency changes after release must remain joinable to release receipt, deployment admission, runtime startup verification, and diagnostic review.

Deployment And Runtime Trust Continuity

Deployment admission is the point where trust-chain evidence becomes a runtime precondition. The admission policy checks release receipt identity, image digest, compiled-bundle digest, configuration fingerprint, signature verification results, transparency-log evidence, SBOM/VEX posture, and declared trust exceptions. If any required evidence is missing or stale, admission should fail closed or emit an explicit trust exception according to the declared policy. The trust-chain contour verifies admission evidence and reports its outcome; the deployment contour owns rollout, rollback, scheduling, and service materialization.

Runtime startup verification then checks what the analyzer service actually materialized. It joins expected bundle digest, image identity, configuration fingerprint, Runtime library or Compute core compatibility digest, and release manifest capture evidence to the service’s startup record. This startup evidence supports later runtime evidence projection; it does not replace audit evidence, term traceability joins, or analyzer execution evidence.

Trust continuity remains active after startup. Certificate expiry, key rotation, revocation, evidence staleness, dependency posture changes, and trust exceptions can invalidate earlier assumptions. Continuous verification turns those changes into trust drift signals rather than leaving reviewers to infer them from unrelated runtime symptoms.

Figure 3. Runtime trust continuity and diagnostic join. Deployment admission checks the released deployment set against trust-chain policy. Startup materialization and runtime startup verification show what was actually started. Continuous verification can later surface revocation, dependency posture, or evidence-staleness signals that join into diagnostic review.

Figure 3 keeps runtime trust evidence separate from runtime computation. The analyzer may compute deterministically while the trust contour still reports a trust-chain break, such as stale VEX evidence or a revoked signing certificate.

Diagnostic Use Of Trust-chain Evidence

Trust-chain evidence becomes operationally useful when it helps classify anomalies. A runtime evidence join may fail because the wrong image was deployed, the expected bundle digest differs, an attestation is missing, a transparency-log inclusion proof cannot be found, dependency evidence is stale, or a certificate identity no longer satisfies policy. These are trust-chain diagnostic signals, not semantic-authority defects.

The diagnostic contour consumes those signals together with runtime evidence, release evidence, and term traceability evidence. It can classify an issue as release/deployment mismatch, trust drift, dependency trust gap, stale attestation, missing transparency evidence, runtime evidence capture gap, or non-semantic explanation. The classification can trigger governed follow-up, but this article does not define remediation closure.

Table 2. Verification outcomes and evidence map.

Condition	Evidence checked	Outcome	Reviewer meaning	Boundary
Verified evidence	Receipt, image, SBOM, attestation, signature, log inclusion, admission, and startup evidence satisfy policy.	Evidence can support deployment admission or runtime trust review.	The trust chain is connected for the declared scope.	Verification supports review; deployment and runtime contours still own execution.
Blocked evidence	Required evidence is missing, malformed, mismatched, or policy-forbidden.	Blocked evidence is emitted.	The release or deployment path should not silently proceed.	Blocking is a trust outcome, not semantic closure.
Stale evidence	Timestamp, VEX, attestation, dependency posture, or policy context no longer satisfies freshness rules.	Trust drift evidence is emitted.	Previously accepted evidence needs review before continued use.	Staleness does not identify a graph defect by itself.
Revoked certificate, key, or evidence identity	Certificate, key, artifact identity, or evidence identity is revoked.	Revocation evidence blocks or escalates according to policy.	Signature history must be interpreted with current revocation context.	Revocation handling is not legal non-repudiation.
Missing log inclusion	Signature exists but required Rekor-style inclusion proof is absent.	Missing transparency evidence is emitted.	Signed-only evidence is separated from visible signed evidence.	Log inclusion supports transparency; it is not correctness proof.
Dependency inventory gap	SBOM does not include a required component or digest needed for review.	Dependency inventory gap is emitted.	Dependency evidence is incomplete at the inventory layer.	SBOM coverage is not full dependency trust.
Dependency trust gap	Dependency is inventoried but lacks provenance, attestation, update, or acceptance evidence.	Dependency trust gap is emitted.	The dependency requires governed review or exception evidence.	The trust chain does not infer missing provenance.
Stale VEX rationale	VEX rationale exists but fails freshness, scope, or policy checks.	Stale VEX evidence is emitted.	Vulnerability exploitability must be re-reviewed for the release scope.	VEX supports classification; it is not permanent waiver.
Governed trust exception	A governed exception is explicitly accepted with rationale and owner.	Trust exception evidence is emitted.	The system records why policy allowed continued use.	Exceptions must not become silent acceptance.
Release/deployment mismatch	Deployment selects image, bundle, configuration, or receipt outside the accepted release basis.	Release/deployment mismatch evidence is emitted.	The issue is classifiable before blaming runtime computation or semantics.	Deployment orchestration remains outside this paper.

Table 3. Key risks and mitigations.

Risk	Failure mode	Mitigation in the trust-chain contour
Unsupported SLSA claim	Reviewers read vocabulary as a conformance or level claim.	The article treats SLSA as assurance vocabulary and requires explicit evidence before any level claim.
Stale attestation	An attestation no longer reflects current release, dependency, or deployment context.	Continuous verification checks evidence staleness and joins stale evidence to diagnostic signals.
Missing log inclusion	Artifact is signed but not visible in the declared transparency surface.	Verification policy distinguishes signature verification from log inclusion proof.
Revoked or expired certificate	A previously accepted signature identity no longer satisfies policy.	Certificate identity, expiry, revocation, and signed timestamp are checked during continuous verification.
Dependency trust gap	SBOM lists a dependency without sufficient provenance, VEX posture, or update rationale.	Dependency provenance, VEX freshness, and vulnerability posture become separate review inputs.
Trust drift	Release evidence was valid at promotion but no longer satisfies post-release policy.	Trust drift is reported as a diagnostic trust signal rather than inferred from runtime symptoms.
Release/deployment mismatch	Deployment selects an artifact outside the accepted release basis.	Deployment admission checks release receipt, image digest, bundle digest, configuration fingerprint, and trust evidence.
Transparency overclaim	Signed and logged evidence is treated as proof of analyzer correctness.	The contour states that signing and log inclusion support review but do not prove clinical or runtime adequacy.
Semantic-authority confusion	Trust-chain evidence is treated as approval of graph semantics.	The global invariant keeps semantic authority in the governed graph path.

Worked Trust-chain Scenario

Consider a governed release that has produced a release receipt and release manifest capture for stateless and stream analyzer modules. The trust-chain verifier starts from the release receipt digest, joins it to the accepted image digest, compiled bundle digest, configuration fingerprint, and SBOM digest, and then checks that each digest appears in the declared trust evidence bundle.

The provenance step verifies a DSSE-wrapped in-toto-style provenance statement. The statement identifies the analyzer image and compiled bundle as subjects, records source revision or equivalent source identity, builder identity, materials, byproducts, and artifact digests, and links back to the release receipt. The signing step verifies the image, receipt, SBOM, and attestation signatures according to the declared verification policy. Where keyless signing is used, the verification result records certificate identity and signed timestamp.

The transparency step checks that required signed evidence has a Rekor-style log entry and inclusion proof. If signature verification passes and log inclusion is present, the verifier emits a verified outcome for that evidence class. If signature evidence exists but inclusion proof is missing, the verifier emits missing transparency evidence rather than treating the signature as a terminal proof.

The dependency step joins the SBOM digest with VEX material. A complete inventory with current non-exploitable VEX rationale can support admission review. A missing component becomes a dependency inventory gap; an inventoried component without provenance becomes a dependency trust gap; a known exploitable vulnerability can block admission; and a stale VEX statement emits trust drift evidence.

Deployment admission receives the released deployment set and trust-chain evidence bundle. It verifies expected image digest, compiled bundle digest, configuration fingerprint, release receipt digest, signature verification result, log inclusion proof, SBOM/VEX posture, and declared trust exceptions. If admission passes, deployment orchestration may materialize the service. Runtime startup verification then records the actual image, bundle, configuration, and compatibility digest. Runtime evidence projection can later join analyzer observations to the same release and trust-chain basis.

If a certificate is revoked after deployment or a VEX statement becomes stale, continuous verification emits trust drift evidence. Diagnostic review can classify a later anomaly as a trust-chain break, dependency trust gap, trust exception, or release/deployment mismatch rather than a semantic-authority defect. Human governance decides whether the analyzer remains accepted, requires redeployment, needs a new release, or must be taken out of service.

This scenario demonstrates reviewable trust continuity without adding clinical, regulatory, or semantic-authority claims.

Limitations And Non-claims

This paper does not claim clinical validation, registration-grade validation, legal non-repudiation, product certification, SLSA level or conformance, full transitive dependency trust, absence of all vulnerabilities, autonomous semantic approval, direct graph or triple-store mutation, runtime analyzer implementation, or complete supply-chain proof. It does not claim that a signature, transparency-log entry, SBOM, VEX statement, DSSE envelope, in-toto statement, release receipt, or deployment admission result alone proves trust.

The paper also does not replace governed release gates, diagnostic closure, runtime evidence capture, registry/trace joins, deployment operations, incident response, or quality-system procedures. It defines a reviewable trust-chain contour and the evidence joins needed to detect trust drift and trust-chain breaks.

Conclusion

A continuous chain of trust turns governed release evidence into reviewable trust continuity. Its central contribution is the bounded join from release receipt and manifest capture to attestations, signatures, transparency-log evidence, dependency posture, deployment admission, runtime startup verification, runtime evidence projection, and diagnostic trust signals. By keeping trust evidence separate from semantic authority, release promotion, deployment materialization, runtime computation, and human closure decisions, the contour supports auditability without creating a second source of truth.

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: continuous chain of trust over executable analyzer module release and deployment evidence.

Funding

The work was funded by RTLAB.

References

1. IEC. IEC 62304:2006/AMD 1:2015 Medical device software - Software life cycle processes. International Electrotechnical Commission / International Organization for Standardization. https://www.iso.org/standard/64686.html
2. ISO. ISO 14971:2019 Medical devices - Application of risk management to medical devices. International Organization for Standardization. https://www.iso.org/standard/72704.html
3. ISO. ISO 13485:2016 Medical devices - Quality management systems - Requirements for regulatory purposes. International Organization for Standardization. https://www.iso.org/standard/59752.html
4. W3C. PROV-O: The PROV Ontology. https://www.w3.org/TR/prov-o/
5. HL7. FHIR R4 AuditEvent. https://hl7.org/fhir/R4/auditevent.html
6. RFC Editor. RFC 8785: JSON Canonicalization Scheme (JCS). https://www.rfc-editor.org/rfc/rfc8785
7. JSON Schema. JSON Schema Draft 2020-12. https://json-schema.org/draft/2020-12
8. CycloneDX. CycloneDX Specification Overview. https://cyclonedx.org/specification/overview/
9. Sigstore. Cosign. https://docs.sigstore.dev/cosign/
10. Open Container Initiative. The OpenContainers Image Spec. https://specs.opencontainers.org/image-spec/
11. ISO. ISO/IEC/IEEE 12207:2026 Systems and software engineering - Software life cycle processes. International Organization for Standardization. https://www.iso.org/standard/90219.html
12. IEEE Standards Association. IEEE 828: Standard for Configuration Management in Systems and Software Engineering. https://standards.ieee.org/ieee/828/10549/
13. NIST. SP 800-218: Secure Software Development Framework (SSDF) Version 1.1. https://csrc.nist.gov/pubs/sp/800/218/final
14. Open Source Security Foundation. Supply-chain Levels for Software Artifacts (SLSA) v1.2. https://slsa.dev/spec/v1.2/about
15. in-toto project. in-toto: A framework to secure the integrity of software supply chains. https://in-toto.io/
16. Secure Systems Lab. Dead Simple Signing Envelope (DSSE). https://github.com/secure-systems-lab/dsse
17. Sigstore. Rekor: Software Supply Chain Transparency Log. https://docs.sigstore.dev/logging/overview/
18. Sigstore. Fulcio. https://github.com/sigstore/fulcio
19. OpenVEX project. OpenVEX Specification. https://github.com/openvex/spec