Stateless rule-based analyzer for mixed named features and oscillograms
Authors
- Prozorov A.A., Director of Technology, RTLAB; Architect, Sbertech; ap@rtlab.ru;
Abstract
Objective: This paper defines the service architecture of a stateless rule-based analyzer for mixed named features and bounded 12-lead electrocardiogram (ECG) oscillogram windows, closing the operational gap between release-bound executable knowledge and reviewable analyzer evidence.
Method: The paper is a methodological systems article with bounded implementation evidence. It separates semantic authority, compiler output, release/deployment evidence, service-host intake, decoder validation, Compute core invocation, and result/audit/debug publication. External sources ground software lifecycle discipline, risk-control framing, quality-system traceability, provenance, audit events, canonical digests, schema-constrained evidence, and EDF container semantics [1-8].
Results: The article specifies an artifact-bound lifecycle: release evidence, startup verification, readiness, 12-lead request intake, pre-acknowledgement validation, asynchronous acknowledgement, worker execution, decoder normalization, Compute core invocation, evidence publication, cleanup, and runtime evidence projection. Using a bounded 12-lead ECG request window as the example, the paper explains how the service validates the lead set, normalizes lead order, normalizes units, checks duration and sample-rate policy, prepares named features, records idempotent request-processing boundaries, and publishes execution evidence without making clinical ECG interpretation claims.
Conclusion: A stateless analyzer service architecture supports operational review of mixed named-feature and bounded 12-lead ECG request-window processing while preserving the Compute core as an execution component rather than a semantic authority.
Keywords: stateless rule-based analyzer; mixed named features; 12-lead ECG oscillograms; named-feature extraction; Compute core; Runtime library; service-host boundary; decoder evidence; runtime evidence; auditability
Abbreviations And Terminology
Analyzer: A software module or service that performs computational analysis, decoding, feature extraction, or rule-based interpretation under released artifacts. In this paper, analyzer is preferred over assessor because the module computes and reports evidence; it does not serve as a human or formal clinical evaluator.
Assessor: A human, organizational, or formal evaluation role. The term is not used for the ECG rule module in this article because it would blur computational analysis with clinical judgement.
Assessment: A clinical object, result, or interpretive act, such as instant health assessment or patient-state assessment. The analyzer may contribute evidence for assessment, but it is not itself an assessor.
Stateless rule-based analyzer: A service architecture that accepts one submitted analysis request, validates and decodes request-local oscillogram material, prepares named feature inputs, invokes the Compute core through the linked Runtime library, publishes result/audit/debug/alert evidence, and avoids mutable cross-request clinical state. The submitted request may materialize a bounded evidence window derived from an upstream real-time signal stream plus current named feature or term-value context. Rule-based means the behavior is driven by explicit rules or compiled executable knowledge rather than by an opaque model judgement.
Stateless analyzer service host: The operational service boundary around the linked Runtime library. It owns transport intake, pre-acknowledgement validation, asynchronous acknowledgement, queueing, worker execution, decoder orchestration, publication, cleanup, and evidence projection.
Runtime library: The unified library linked into the Stateless analyzer during compilation. In the stateless analyzer architecture, the host invokes only the Compute core path; the Safety kernel is reserved for downstream stateful human-in-the-loop command application.
Compute core: The deterministic execution component inside the Runtime library. It executes one normalized request against a validated in-memory catalog and returns deterministic response/evidence.
Safety kernel: The stateful-analyzer control component inside the Runtime library. It is reserved for downstream stateful human-in-the-loop command application and is not invoked by the stateless analyzer request path described in this paper.
Runtime term reference: A compiled term identity carried from the verified runtime bundle into the request, response, publication references, and runtime evidence projection. Registry and trace joins remain outside the stateless analyzer.
Non-repudiable audit record: A durable audit record whose provenance, digest or context binding, and append-only publication make it unsuitable for silent reconstruction from debug traces. This paper uses the term as an evidence-bound auditability concept, not a legal non-repudiation claim.
HITL command application: A downstream stateful-analyzer path in which the Safety kernel gates application of human-accepted commands. It is not part of stateless request analysis.
12-lead ECG: The bounded electrocardiogram input case used in this paper. It is treated as a request-local materialization of a multi-channel oscillographic window with declared lead labels, order, units, sample rate, and duration policy; it is not treated as proof of clinical ECG interpretation or as ownership of the continuous stream lifecycle.
Canonical 12-lead order: The declared normalized order of the 12 ECG leads after decoder validation. The order is an execution and evidence contract, not a cardiology claim.
Mixed oscillogram: A multi-channel oscillographic input whose channels may require format, unit, label, and sampling normalization before runtime execution.
Named feature: A feature or feature group with a stable name within a request. The service uses that name to link input data, computation, result, and runtime evidence. The name itself does not define clinical meaning: that meaning remains in authorized semantics and is confirmed separately during clinical validation.
Async ACK: The accepted-response boundary after pre-acknowledgement validation succeeds and before worker execution produces terminal result, audit, debug, alert, or failure evidence.
Runtime bundle: The release-bound compiled execution package selected and verified by the service host before work is accepted.
Config fingerprint: A deterministic evidence value identifying the runtime configuration used by the service host for a request or deployment context.
Expected bundle digest: The configured digest that the service host compares with the selected runtime bundle before accepting work.
Worker pool: The bounded execution pool that processes accepted requests and enforces queue, cancellation, drain, and rejection policy.
Idempotency ledger: The request-identity tracking surface used to avoid duplicate in-process work and to record duplicate handling boundaries.
Global invariant: The analyzer service host, decoder, Workbench-facing evidence, and runtime projections are not semantic authority. They execute and report against released artifacts; they do not authorize, repair, or reinterpret the underlying knowledge graph.
Introduction
Twelve-lead ECG inputs are operationally demanding for executable-knowledge systems because they combine multi-channel signal material, format decoding, lead labeling, unit normalization, duration policy, request identity, release-bound runtime selection, and durable evidence obligations before any downstream interpretation can be reviewed. The Compute core can execute a normalized request, but the surrounding service architecture must confirm that the request was accepted under the expected release basis, decoded deterministically, executed once within a bounded worker boundary, and reflected in result, audit, debug, alert, and runtime evidence surfaces.
In the implementation framing used by this paper, the Compute core is not a separate deployable service. It is supplied through a unified Runtime library that is linked into the Stateless rule-based analyzer during compilation. The stateless analyzer path in this article invokes the Compute core only; the Safety kernel is reserved for downstream stateful human-in-the-loop command application.
This paper describes a stateless rule-based analyzer service architecture for mixed named features and oscillograms, using a bounded 12-lead electrocardiogram window as the implementation example. That request window may be derived from a real-time ECG stream and current named term values, but the stateless service receives it as request-local material. The focus is infrastructure: intake, validation, acknowledgement, decoding, named-feature preparation, worker execution, Compute core invocation, publication, cleanup, and evidence. The article does not define clinical ECG diagnostic thresholds, prove cardiology accuracy, or move semantic authority into the service host.
The contribution is intentionally narrower than a general analyzer platform. It explains how a request-local service architecture can be deterministic and auditable while remaining downstream of compiler output and release/deployment evidence. Lifecycle and traceability framing is aligned with software lifecycle, risk-control, quality-system, provenance, audit-event, schema, and canonical-digest concepts from the trusted source set [1-7].
Companion Articles
Implementing executable knowledge as compute core and safety kernel owns the Compute core, Safety kernel, stateless analysis semantics, stateful command-control boundary, and Runtime library packaging. This paper uses only the stateless Compute core path and explains the service architecture around it.
Implementing a stream analyzer for mixed named features and oscillograms owns the downstream stateful rule-based stream analyzer architecture and continuous intake concerns. This paper stays request-local and does not claim stream hosting or stream/session/window state.
Formal knowledge representation as the input and internal languages of the knowledge compiler owns compiler language layers and compiled representation concepts. End-to-end codified-term traceability for debugging and auditing the compiler and executable modules owns term registry/trace joins and Workbench triage over runtime evidence. 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.
Instant health assessment through an ECG example: interpreting mixed named terms and ECG oscillograms owns ECG-domain interpretation over current named term values and a real-time 12-lead ECG stream as time-aligned, governed evidence. The present paper only supplies the service-architecture evidence path for a bounded 12-lead ECG request window and its named-feature preparation.
Automatic closed-loop release of trusted executable analyzer modules from a trusted knowledge snapshot owns release automation and governed delivery. The present paper consumes release/deployment evidence and does not claim release-chain automation.
Materials And Methods
The paper is a methodological systems article with bounded implementation evidence. The internal authoring basis consists of service-architecture realization plans, request-pipeline tests, decoder specifications, release-receipt and deployment-evidence surfaces, Compute core boundary material, stateful-analyzer Safety kernel boundary framing, publication schemas, audit/debug policies, and the shared IHA terminology canon. Those internal artifacts guide the manuscript but are not cited as public references.
The external reference set is deliberately compact. IEC 62304 and ISO 13485 ground lifecycle and traceability governance [1,3]. ISO 14971 grounds risk-control framing without converting this infrastructure paper into a clinical safety claim [2]. PROV-O and FHIR AuditEvent ground provenance and structured audit-event analogies [4,5]. RFC 8785 and JSON Schema 2020-12 ground canonical digest and schema-constrained evidence framing [6,7]. The EDF specification grounds the decoder discussion where EDF container material is accepted as one bounded oscillogram input surface [8].
Stateless Analyzer Service Architecture Overview
The stateless rule-based analyzer service architecture places the service host at the runtime-adjacent boundary that turns a released executable-knowledge package into request-local, reviewable work. It begins from release/deployment evidence, verifies the selected runtime bundle and configuration, exposes readiness only after bundle materialization succeeds, accepts a materialized 12-lead request window through pre-acknowledgement validation, emits an asynchronous acknowledgement only after the request is admissible for queued work, executes through a bounded worker pool, decodes and normalizes the electrocardiogram oscillogram material, prepares named feature inputs, invokes the Compute core through the linked Runtime library, publishes evidence surfaces, cleans up request-local material, and forwards a runtime evidence projection to downstream diagnostic review.
Figure 1. Stateless rule-based analyzer service lifecycle. Release/deployment evidence flows into startup verification, which determines whether the service can become ready. Only after readiness does materialized request-window intake run pre-acknowledgement validation. A successful accepted acknowledgement hands work to the worker pool, which coordinates decoder normalization, named-feature preparation, Compute core invocation through the linked Runtime library, publication, cleanup, and runtime evidence projection.
The diagram is top-down because the authority boundary is directional. Semantic authority and compiler output precede the service host; the host verifies and executes released material; downstream evidence consumers receive artifacts after publication. There is no reverse path from decoder evidence or debug traces into semantic authority.
Table 1. Components, responsibilities, and authority boundaries.
| Component | Responsibility | Authority boundary |
|---|---|---|
| Semantic authority and compiler | Provide authorized semantics, compiled runtime bundle, registry/trace material, and lineage evidence before release. | Does not run the request, accept network input, or publish analyzer evidence. |
| Release/deployment evidence | Identifies the accepted bundle, release receipt, expected bundle digest, deployment context, and configuration fingerprint. | Does not perform request execution or clinical interpretation. |
| Service host | Owns startup verification, readiness, intake, acknowledgement, worker orchestration, publication, cleanup, and operational evidence. | Does not define semantic meaning or authorize graph changes. |
| Ingress | Accepts HTTPS request material, request identity, declared input kind, metadata, and idempotency keys. | Does not execute the Runtime library or accept work without pre-acknowledgement validation. |
| 12-lead decoder | Normalizes EDF or normalized JSON evidence into canonical lead labels, order, units, sample rate, duration, and decoder evidence. | Does not create clinical conclusions or alter authorized terminology. |
| Worker pool | Binds accepted work to a bounded execution slot, cancellation policy, drain behavior, and terminal evidence requirement. | Does not promise exactly-once delivery across multiple replicas. |
| Runtime library | Supplies the linked in-process execution boundary. The stateless analyzer invokes its Compute core path; the Safety kernel path is reserved for stateful analyzer command application. | Does not own transport, release-bundle source selection, publication, or deployment context. |
| Compute core | Executes one normalized request against a validated in-memory catalog and returns deterministic response/evidence with runtime term references. | Does not select, load, authorize, authenticate, or join semantic authority. |
| Safety kernel | In a stateful analyzer, ensures that commands accepted by a human reviewer are applied according to the accepted command state. | Is not invoked by the stateless analyzer request path and does not prove clinical safety or regulatory approval. |
| Publication surface | Publishes result, alert, audit material, durable audit records, debug, metric, failure, and cleanup evidence according to contract. | Does not reconstruct durable audit from debug evidence. |
| Observability | Exposes health, readiness, metrics, and operational diagnostics. | Does not expose raw waveform or PHI in debug-oriented surfaces. |
Release-bound runtime basis
The analyzer host starts from a release-bound runtime basis. The basis includes the selected runtime bundle, release receipt, deployment evidence, expected bundle digest, runtime configuration, and config fingerprint. Startup verification checks schema constraints, digest equality, and release/deployment consistency before the service declares readiness. Schema-constrained evidence and canonical digests make the selected execution set reproducible for review [6,7].
An expected bundle digest mismatch is a hard admissibility failure. The service may remain not ready, reject new analysis requests, or emit operational failure evidence, but it must not silently proceed with a different bundle. The config fingerprint travels with result and audit evidence so that later replay can distinguish a computational difference from a deployment/configuration difference.
Ingress, ACK, And Idempotency
Ingress is a pre-execution boundary. The service receives request metadata, request identity, declared input kind, payload location or submitted normalized body, idempotency key when present, and bounded request controls. Before asynchronous acknowledgement, the host verifies that the request is structurally admissible: required metadata is present, the input kind is supported, size and duration limits are satisfied enough for queued handling, the selected release basis is ready, and duplicate policy can be evaluated.
An async ACK means accepted for bounded worker execution, not completed analysis. It must be followed by terminal evidence: result, failure, cancellation, rejection after deeper validation, or publication-error evidence. The idempotency ledger covers the in-process boundary and records duplicates or already-terminal outcomes for the same request identity. It does not claim exactly-once delivery across multiple service replicas.
12-lead ECG Oscillogram Decoding
For the bounded 12-lead electrocardiogram case, the service accepts EDF container material and normalized JSON artifacts as materialized request-window inputs. EDF support is treated as a decoder-container concern grounded by the EDF specification, while normalized JSON is treated as a schema-constrained internal evidence artifact [7,8]. The decoder produces a normalized, request-local representation rather than a clinical interpretation.
The decoder validates the declared lead set, lead labels, canonical 12-lead order, signal duration, sample-rate policy, and unit normalization to millivolts. It rejects missing required leads, duplicate labels, unsupported units without a declared conversion, ambiguous sample-rate declarations, duration outside policy, inconsistent channel lengths, and inputs whose metadata cannot be joined to the accepted request identity.
Decoder evidence records the accepted input representation, normalized lead order, unit conversion decisions, sample-rate and duration outcomes, and failure class when validation fails. Debug evidence may explain the decoder path, but it must not expose raw waveform material or PHI.
Named-feature Preparation
After decoding, named-feature preparation converts validated signals and metadata into request-local feature inputs for runtime execution. The named feature is the computational handle that lets the runtime request select the relevant executable-knowledge path and return evidence under stable names. The service host preserves the distinction between named-feature extraction evidence and clinical diagnostic interpretation: it can show that a named feature was prepared, executed, and published under the accepted release basis, but it cannot by itself claim that the feature is clinically sufficient or diagnostically valid.
If the request includes current named term values, they remain request-local context for the materialized window. Their validity semantics, such as “current until the next update,” are owned by the upstream domain and stream contexts; the stateless analyzer only preserves the evidence links used for replay and review.
Named-feature preparation is also where evidence boundaries become visible. The prepared request links the request id, accepted bundle digest, config fingerprint, decoder evidence, canonical lead order, and runtime invocation metadata. That linkage gives diagnostic reviewers enough context to decide whether a later anomaly is a decoder issue, release/deployment mismatch, runtime execution issue, evidence capture gap, or semantic-authority question.
Worker Pool And Backpressure
The worker pool turns an accepted ACK into bounded execution. It owns queue depth, timeout policy, cancellation, drain behavior during shutdown, queue-full rejection, and terminal evidence obligations. Queue-full rejection happens before acceptance when possible; if deeper validation fails after acceptance, the service publishes terminal failure evidence rather than leaving the request open.
Backpressure is an evidence and safety mechanism, not only an availability mechanism. A bounded queue prevents unreviewable accumulation of request-local material, keeps cleanup obligations tractable, and lets operators distinguish a service-capacity rejection from a runtime or decoder failure.
Compute Core Invocation
The service host prepares a normalized runtime request and release-bound configuration, including runtime term references carried from the verified bundle, then invokes the Compute core through the Runtime library linked into the Stateless analyzer at compilation. For this stateless architecture, the Runtime library owns in-memory catalog validation, immutable engine execution, request-local state, deterministic response assembly, and request-local evidence returned to the host. The stateless path invokes the Compute core only; the Safety kernel is reserved for downstream stateful human-in-the-loop command application. The host owns source selection, bundle verification, process lifecycle, transport, secrets, publication, and deployment context.
This separation is central to the paper. The host chooses and verifies the released bundle, but it does not own semantic meaning or in-memory execution. The Runtime library executes the normalized stateless request through the Compute core. It does not select, load, authorize, or authenticate semantic authority. The output evidence remains tied to both the release basis and the service-host context.
Evidence Publication Surfaces
The analyzer publishes several evidence surfaces. Results carry deterministic response data, runtime term references, and response hashes. Alerts carry operationally relevant events when the runtime or policy declares them. Audit material becomes review-oriented audit evidence only through the durable audit publication path; debug evidence is request-local diagnostic material. Metrics provide aggregate operational observability. Runtime evidence projection normalizes these surfaces for downstream diagnostic contour review.
Audit evidence must not be reconstructed from debug traces. Debug traces are useful for engineering and diagnostic review, but durable and non-repudiable audit records need their own publication path and retention posture. PROV-O and FHIR AuditEvent are used here as analogies for provenance-bearing and audit-event-structured records, while the concrete analyzer artifacts remain implementation-owned [4,5].
Security, PHI, And Operational Controls
Security controls sit at the service-host boundary. The host owns transport-security posture, secret loading, request size policy, payload admission, cleanup, zeroization of request-local memory where applicable, health/readiness endpoints, and operational metrics. These controls support risk management and quality-system traceability but do not constitute clinical validation [2,3].
PHI and raw waveform material are handled as request-local sensitive material. Publication surfaces should prefer references, hashes, metadata, failure classes, and safe summaries over raw signal disclosure. Debug evidence may describe lead normalization and decoder decisions, but it must not become a waveform viewer or a secondary data store.
Table 2. Implementation evidence and residual gaps.
| Evidence item | Current claim | Reviewer meaning | Residual gap |
|---|---|---|---|
| Release-bound startup verification | The host checks bundle schema, expected digest, release receipt, deployment evidence, and config fingerprint before readiness. | Reviewers can distinguish bundle/config mismatch from request-level failures. | Release automation and full trust chain belong to downstream release papers. |
| 12-lead decoder evidence | EDF and normalized JSON paths produce lead-set, order, unit, duration, and sample-rate evidence. | Reviewers can audit decoder admissibility for the bounded 12-lead case. | This is not clinical validation of ECG interpretation. |
| Async ACK and terminal evidence | Accepted requests must produce result, failure, cancellation, or publication-error evidence. | ACK is not confused with completion. | Exactly-once behavior across multiple replicas is not claimed. |
| Worker pool and backpressure | Queue, drain, cancellation, and queue-full policy are visible as operational evidence. | Capacity failure is separable from decoder/runtime failure. | Broader autoscaling or stream-hosting behavior is out of scope. |
| Compute core invocation | The host invokes the linked Runtime library with normalized request/config and records response/evidence hashes. | Runtime execution can be reviewed against accepted bundle and config fingerprint. | Full clinical algorithm coverage is not claimed. |
| Publication surfaces | Result, alert, audit, debug, metrics, and runtime evidence projection are separated. | Debug is not treated as durable audit. | Downstream diagnostic closure is owned by companion governance papers. |
| Cleanup and PHI controls | Request-local cleanup and non-disclosure boundaries are part of the service architecture. | Sensitive material handling is visible to reviewers. | This paper does not prove organization-wide privacy compliance. |
Table 3. Key risks and mitigations.
| Risk | Failure mode | Mitigation in the architecture |
|---|---|---|
| Clinical overclaim | Infrastructure evidence is mistaken for ECG diagnostic validation. | Abstract, terminology, example, and limitations state that the paper does not prove clinical ECG interpretation. |
| Hidden semantic authority | Decoder or host behavior is treated as semantic authorization. | The global invariant and component boundaries keep semantic authority upstream of the service host. |
| ACK without terminal evidence | Accepted work disappears after acknowledgement. | Async ACK requires downstream terminal result, failure, cancellation, or publication-error evidence. |
| PHI leakage | Debug or metrics expose raw waveform or identifiable material. | Debug and metrics prefer references, hashes, metadata, failure classes, and safe summaries. |
| Stale bundle | Service executes a bundle different from the expected release basis. | Expected bundle digest and config fingerprint are checked before readiness and carried into evidence. |
| Duplicate request | Repeated request identity creates duplicate or conflicting execution. | Idempotency ledger records in-process duplicate handling and terminal outcomes. |
| 12-lead decoder ambiguity | Lead labels, units, sample rates, or duration are unclear. | Decoder validation rejects ambiguous or unsupported declarations and emits failure evidence. |
| Publication failure | Runtime execution completes but evidence is not durably visible. | Publication-error evidence and retry/terminal status separate execution result from publication success. |
| Release/deploy evidence gap | Reviewers cannot tie a result to the accepted execution set. | Release receipt, deployment evidence, bundle digest, and config fingerprint join the evidence chain. |
Worked 12-lead Stateless Request Example
Consider a request that submits named-feature targets and a bounded 12-lead electrocardiogram window with a declared request id, idempotency key, input representation, and expected runtime bundle. The window may be materialized from a real-time ECG stream together with current named term values, but the stateless analyzer treats that materialization as request-local input. The service is already ready because startup verification matched the expected bundle digest, release receipt, deployment evidence, and config fingerprint.
The ingress layer performs pre-acknowledgement checks. It confirms that the declared input kind is supported, the request identity is admissible, size and policy limits allow queued work, and the idempotency ledger has no terminal result for the same request. The service then returns an async ACK: the request has been accepted for bounded worker execution, not completed.
The worker pool binds the request to a worker slot. The decoder reads the EDF container or normalized JSON evidence, verifies the required 12 lead labels, normalizes the lead order, converts units to millivolts when conversion is declared, checks sample-rate and duration policy, and emits decoder evidence. If the lead set is incomplete or ambiguous, the request ends with terminal failure evidence rather than entering runtime execution.
For an admissible request, named-feature preparation builds a normalized runtime request that carries the request id, accepted bundle digest, config fingerprint, canonical lead order, decoder evidence reference, runtime term references, and named-feature target. The Compute core executes the request against its validated in-memory catalog through the linked Runtime library and returns a deterministic response plus request-local evidence. The host publishes the result, audit material through the durable audit path, debug trace, alert state if any, metrics, and runtime evidence projection, then cleans up request-local material.
The worked example demonstrates deterministic, reviewable request processing in the service architecture. It does not validate ECG diagnostic accuracy, prove full 12-lead diagnostic coverage, or authorize semantic changes.
Request Processing And Evidence Publication
Figure 2. Request processing and evidence publication. The pre-acknowledgement path either rejects the request synchronously or emits an async ACK and records idempotency state. Post-acknowledgement work moves through the worker pool, decoder, named-feature preparation, Compute core invocation through the linked Runtime library, publication surfaces, and runtime evidence projection.
The result of this flow is not a single output file; it is a set of linked evidence surfaces. A reviewer can ask whether the request was rejected before acceptance, accepted but failed decoder validation, executed but failed publication, or completed with result, audit, debug, alert, metric, and runtime-evidence links.
Evidence Chain For Replay And Review
Figure 3. Evidence chain for replay and review. The evidence chain starts from request identity, joins to the accepted bundle digest and config fingerprint, records decoder evidence, passes through named-feature runtime execution with runtime term references, and ends in response hash, publication references, runtime evidence projection, and downstream diagnostic-contour handoff.
Replay and review depend on the chain staying intact. If a later reviewer sees a stale bundle digest, missing decoder evidence, unmatched config fingerprint, absent runtime term reference, absent audit reference, or debug-only claim, the issue can be classified as a release/deployment gap, decoder/evidence gap, publication gap, term-trace input gap, or diagnostic-contour input problem rather than being mistaken for clinical meaning.
Limitations And Non-claims
This paper does not claim clinical ECG validation, full 12-lead diagnostic coverage, autonomous diagnosis, release automation, stream hosting, stateful human-in-the-loop command application, exactly-once multi-replica delivery, or product-level validation. It does not make the service host, decoder, runtime term reference, publication layer, debug trace, or runtime evidence projection a semantic authority. It does not use debug traces as a substitute for durable audit evidence or non-repudiable audit records. It does not perform registry/trace joins inside the stateless analyzer. It does not expose raw waveform or PHI through debug-oriented evidence. It does not claim support for every oscillogram interchange format; the bounded implementation discussion is limited to EDF and normalized JSON evidence surfaces.
The implementation evidence is bounded. It supports the service architecture, release-bound startup verification, 12-lead decoder admissibility evidence, request-local Compute core execution, publication surfaces, and downstream evidence projection. It does not prove clinical adequacy of named features, cardiology interpretations, or Safety kernel behavior in a stateful analyzer.
Conclusion
The stateless analyzer service architecture is the operational bridge between release-bound executable knowledge and reviewable runtime evidence for mixed named features and bounded 12-lead ECG request windows. By separating release verification, request intake, asynchronous acknowledgement, decoder validation, named-feature preparation, worker execution, Compute core invocation through the linked Runtime library, publication, cleanup, and runtime evidence projection, the architecture makes request-local analysis auditable without making the runtime host a semantic authority.
This pattern keeps the title-level mixed named-feature and oscillogram analyzer general while using 12-lead ECG as a bounded implementation example. The resulting article prepares the ground for downstream ECG interpretation, stream analyzer architecture, governed release, and trust-chain papers without claiming their results.
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: stateless rule-based analyzer service architecture.
Funding
The work was funded by RTLAB.
References
- International Electrotechnical Commission. IEC 62304:2006/AMD 1:2015, Medical device software - Software life cycle processes. https://www.iso.org/standard/64686.html
- International Organization for Standardization. ISO 14971:2019, Medical devices - Application of risk management to medical devices. https://www.iso.org/standard/72704.html
- International Organization for Standardization. ISO 13485:2016, Medical devices - Quality management systems - Requirements for regulatory purposes. https://www.iso.org/standard/59752.html
- W3C. PROV-O: The PROV Ontology. https://www.w3.org/TR/prov-o/
- HL7 International. FHIR Resource AuditEvent (R4). https://hl7.org/fhir/R4/auditevent.html
- RFC Editor. RFC 8785, JSON Canonicalization Scheme (JCS). https://www.rfc-editor.org/rfc/rfc8785
- JSON Schema. JSON Schema Draft 2020-12. https://json-schema.org/draft/2020-12
- EDF/EDF+ specification maintainers. European Data Format (EDF) specification. https://www.edfplus.info/specs/edf.html