Time-Series Forecasting in Safety-Critical Environments: An EU-AI-Act-Compliant Open-Source Package / Zeitreihenprognose in sicherheitskritischen Umgebungen: Ein KI-VO-konformes Open-Source-Paket
Pith reviewed 2026-05-08 06:12 UTC · model grok-4.3
The pith
The spotforecast2-safe package embeds EU AI Act and safety standard requirements directly into its code structures for time-series forecasting.
A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.
Core claim
spotforecast2-safe operationalizes a Compliance-by-Design approach by anchoring the requirements of Regulation (EU) 2024/1689, IEC 61508, the ISA/IEC 62443 series, and the Cyber Resilience Act inside the library in API contracts, persistence formats, and continuous-integration gates. This is achieved through four non-negotiable code-development rules together with the corresponding process rules, a bidirectional traceability matrix that maps every regulatory provision to the matching mechanism in the code, and deliberate exclusion of components that enlarge the attack surface, introduce non-determinism, or impair reproducibility.
What carries the argument
The Compliance-by-Design approach, which places regulatory requirements inside the library's API contracts, persistence formats, and CI gates rather than outside as scanners or runtime layers.
If this is right
- Time-series forecasting in safety-critical environments can meet regulatory demands through internal code constraints and build processes.
- Excluding deep-learning backends, AutoML, and similar features preserves determinism and limits the attack surface.
- A bidirectional traceability matrix can link every regulatory provision to concrete mechanisms in the code.
- The package supports end-to-end forecasting tasks such as European electricity generation, transmission, and consumption under the stated compliance rules.
Where Pith is reading between the lines
- Similar internal anchoring of rules could be tested in other regulated forecasting domains such as medical or industrial sensor data.
- Independent runtime testing or external audits would still be needed to confirm that the chosen rules suffice in live deployments.
- The open-source release under AGPL 3.0-or-later allows direct inspection and adaptation by teams working under the same standards.
Load-bearing premise
Embedding the four code-development rules and the listed process rules inside the library is sufficient to satisfy the full scope of the cited regulations without requiring additional external verification or runtime monitoring layers.
What would settle it
An audit or regulatory assessment that identifies a specific provision from the EU AI Act or IEC 61508 that remains unmapped or unaddressed by the traceability matrix and the implemented rules.
read the original abstract
With spotforecast2-safe we present an integrated Compliance-by-Design approach to Python-based point forecasting of time series in safety-critical environments. A review of the relevant open-source tooling shows that existing compliance solutions operate consistently outside of the library to be used - e.g. as scanners, templates, or runtime layers. spotforecast2-safe takes the inverse approach and anchors the requirements of Regulation (EU) 2024/1689 (the EU AI Act, in German: KI-VO), of IEC 61508, of the ISA/IEC 62443 standards series, and of the Cyber Resilience Act within the library: in application-programming-interface contracts, persistence formats, and continuous-integration gates. The approach is operationalised by four non-negotiable code-development rules (zero dead code, deterministic processing, fail-safe handling, minimal dependencies) together with the corresponding process rules (model card, executable docstrings, CI workflows, Common-Platform-Enumeration (CPE) identifier, REUSE-conformant licensing, release pipeline). Interactive visualisation, hyperparameter tuning and automated machine learning (AutoML), as well as deep-learning and large-language-model backends are deliberately excluded, because each of these components either enlarges the attack surface, introduces non-determinism, or impairs reproducibility. A bidirectional traceability matrix maps every regulatory provision onto the corresponding mechanism in the code; an end-to-end example of European-market electricity generation, transmission, and consumption forecasting demonstrates the application. The package is open-source and available under Affero General Public License (AGPL) 3.0-or-later.
Editorial analysis
A structured set of objections, weighed in public.
Referee Report
Summary. The manuscript presents spotforecast2-safe, an open-source Python package for point forecasting of time series in safety-critical environments. It proposes a compliance-by-design approach that embeds requirements from Regulation (EU) 2024/1689 (EU AI Act), IEC 61508, ISA/IEC 62443, and the Cyber Resilience Act directly into the library via API contracts, persistence formats, and CI gates. This is operationalized through four non-negotiable code rules (zero dead code, deterministic processing, fail-safe handling, minimal dependencies) and six process rules (model card, executable docstrings, CI workflows, CPE identifier, REUSE licensing, release pipeline), with a bidirectional traceability matrix mapping regulatory provisions to code mechanisms and an end-to-end example using European electricity market data. Non-deterministic elements such as deep learning, AutoML, and LLMs are excluded to prioritize determinism and reproducibility.
Significance. If the central claim holds, the work offers a concrete, code-centric template for compliance-by-design in regulated AI applications, which is timely and useful given the EU AI Act's requirements for high-risk systems. The emphasis on internal mechanisms rather than external scanners, the provision of a traceability matrix, the open-source AGPL release, and the deliberate exclusion of high-risk features for reproducibility are notable strengths that could inform developers and standards bodies working on safety-critical forecasting.
major comments (2)
- [Section describing the traceability matrix and regulatory mapping] The claim that the four code-development rules together with the process rules and bidirectional traceability matrix achieve compliance-by-design is load-bearing but insufficiently supported. The matrix maps provisions to mechanisms, yet the manuscript does not show how these rules mechanically enforce the full scope of cited obligations, such as the risk management system and ongoing monitoring under EU AI Act Articles 9–15 or the complete safety lifecycle requirements of IEC 61508 (including external conformity assessment and post-market surveillance), which extend beyond internal API contracts and CI gates.
- [End-to-end example section] In the end-to-end electricity forecasting example, the application demonstrates usage but provides no concrete verification that the compliance mechanisms (e.g., fail-safe handling or deterministic processing) were exercised or audited during the run, leaving the practical effectiveness of the design untested within the manuscript.
minor comments (2)
- [Abstract and introduction] The abstract and introduction could more explicitly state the scope limitation that the approach addresses only the mapped provisions via internal rules and does not claim formal certification or coverage of runtime monitoring layers.
- [Traceability matrix presentation] Figure or table presenting the traceability matrix would benefit from clearer column headers or an example row to improve readability for readers unfamiliar with the specific standards.
Simulated Author's Rebuttal
We thank the referee for the thorough review and positive assessment of the work's timeliness and potential utility. We address the major comments point by point below, providing clarifications on the scope of our compliance-by-design approach and committing to revisions that strengthen the manuscript's claims and demonstrations.
read point-by-point responses
-
Referee: The claim that the four code-development rules together with the process rules and bidirectional traceability matrix achieve compliance-by-design is load-bearing but insufficiently supported. The matrix maps provisions to mechanisms, yet the manuscript does not show how these rules mechanically enforce the full scope of cited obligations, such as the risk management system and ongoing monitoring under EU AI Act Articles 9–15 or the complete safety lifecycle requirements of IEC 61508 (including external conformity assessment and post-market surveillance), which extend beyond internal API contracts and CI gates.
Authors: We agree that the manuscript should more clearly delineate the boundaries of the compliance-by-design claim. spotforecast2-safe embeds software-enforceable mechanisms—such as deterministic processing via exclusion of non-deterministic components, fail-safe handling through API contracts, and traceability via the matrix and persistence formats—to address specific technical requirements in the EU AI Act, IEC 61508, and related standards. However, comprehensive obligations like the risk management system (Articles 9–15), ongoing monitoring, and external conformity assessment involve organizational processes, human oversight, and post-deployment activities that extend beyond any single software library. The bidirectional traceability matrix links regulatory provisions to the library's internal mechanisms for the aspects under software control. We will revise the relevant sections to explicitly state that the approach provides a code-centric foundation supporting compliance rather than claiming to mechanically enforce the entire regulatory lifecycle. This clarification will prevent overstatement while preserving the core contribution. revision: yes
-
Referee: In the end-to-end electricity forecasting example, the application demonstrates usage but provides no concrete verification that the compliance mechanisms (e.g., fail-safe handling or deterministic processing) were exercised or audited during the run, leaving the practical effectiveness of the design untested within the manuscript.
Authors: The observation is accurate; the example primarily illustrates API usage and workflow with European electricity market data without explicit runtime verification of the compliance rules. Because the four code rules are non-negotiable and enforced at the library level (e.g., deterministic processing is ensured by design choices excluding deep learning and AutoML, and fail-safe handling is built into the API contracts), any execution using the package adheres to them. To make this explicit and testable, we will augment the end-to-end example section with verification elements, including code snippets that demonstrate logging of fail-safe activations, reproducibility checks confirming deterministic outputs, and cross-references to the traceability matrix entries activated during the forecasting pipeline. This revision will provide concrete evidence of the mechanisms' operation within the manuscript. revision: yes
Circularity Check
No circularity: compliance-by-design rests on explicit code rules and traceability matrix
full rationale
The paper presents a software package and process that embed regulatory requirements (EU AI Act, IEC 61508, etc.) directly into API contracts, persistence formats, and CI gates via four non-negotiable code rules and six process rules, with a bidirectional traceability matrix mapping provisions to mechanisms. No mathematical derivations, equations, fitted parameters, predictions, or uniqueness theorems appear. Claims are design decisions and explicit mappings rather than results that reduce to inputs by construction. No self-citation load-bearing steps or ansatz smuggling are present; external standards are invoked as external requirements, not as self-referential support. The approach is self-contained against the stated scope.
Axiom & Free-Parameter Ledger
axioms (1)
- domain assumption The requirements of the EU AI Act, IEC 61508, ISA/IEC 62443, and Cyber Resilience Act can be fully operationalized through the four listed code-development rules and corresponding process rules.
Reference graph
Works this paper leans on
-
[1]
Betriebsseitige Log-Instrumentierung. Das in Kapitel 6.1.5 beschriebene Audit-Log-Schema v1.0.0 erzeugt je Prognoselauf eine zeitstempel-benannte JSON-Datei unter ~/spotforecast2_safe_models/logs/ mit timestamp_utc in Mikrosekunden-Auflösung, Ereignis-Slug ( event), Log-Level, dem Namen der auslö- senden Aufgabe ( task) sowie einem freigeformten Kontext-D...
-
[2]
Lebenszyklus-Metadaten der Ausprägung. Jedes Forecaster-Objekt persistiert die Provenienz der Trainings- daten und die Modell-Hyperparameter (siehe Kapitel 6.1.3); die CPE-Kennung (siehe Kapitel 5.7) identifi- ziert die verwendete Paket-Version in jeder abgeleiteten SBOM; die Semantic-Release-Pipeline (siehe Ka- pitel 6.1.6) dokumentiert in der CHANGELOG....
-
[3]
Interaktion mit anderen KI-Systemen
Automatisierte Beobachtung der Lieferkette. Die in Kapitel 6.1.8 und Kapitel 6.1.13 vorgestellten Workflows codeql.yml, scorecard.yml und Dependabot beobachten fortlaufend Code-Qualität, Lieferkette und Ab- hängigkeiten. Sie bilden die in Art. 72 Abs. 2 KI-VO als Analyse von “Interaktion mit anderen KI-Systemen” mitgedachte Dimension ab, soweit diese über...
2026
-
[4]
Vertraulicher Meldekanal und Versionspolitik. Die Datei SECURITY.md im Repository etabliert GitHub Pri- vate Security Advisories als primären Kanal für die vertrauliche Meldung; als Rückfallweg steht die E-Mail- Adresse der Maintainer zur Verfügung. Öffentliche Issues werden ausdrücklich ausgeschlossen. Die veröffent- lichten Reaktionszusagen (Bestätigung...
2027
-
[5]
Früherkennungssignale. Drei automatisierte Workflows versorgen Anbieter und Maintainer mit Vorwarn- signalen, bevor ein Vorfall eine Marktüberwachung erreicht: der codeql.yml-Workflow für statische Si- cherheitsanalyse, der scorecard.yml-Workflow für die wöchentliche OpenSSF-Scorecard-Bewertung der Lieferkette (siehe Kapitel 6.1.8) und Dependabot für Abhä...
-
[6]
Produkten mit digitalen Elementen
Nachweisbare Korrekturmaßnahme. Nach der Advisory-Triage erzeugt die Semantic-Release-Pipeline (sie- he Kapitel 6.1.6) einen neuen signierten Release mit zugehöriger Korrektur. Die Auslieferungsintegrität ist durch Sigstore-basierte schlüssellose OIDC-Signaturen und Eintragung im Rekor-Transparenzprotokoll gesi- chert; die begleitende CycloneDX-SBOM (sieh...
2024
-
[7]
accuracy
stellt offene Vorlagen für die nach Anhang IV KI-VO geforderte technische Dokumentation von Daten, Modellen und Anwendungen über den gesamten Lebenszyklus bereit 37; AIR Blackbox (ARK Forge, 2025a) und der MCP-EU- AI-Act-Scanner (ARK Forge, 2025b) sind CLI-Werkzeuge, die Python-Codebases gegen die Anforderungen aus Art. 9 bis Art. 11 KI-VO prüfen und Anne...
2024
-
[8]
Check pyproject.toml to confirm the absence of prohibited libraries ( plotly, matplotlib, spotoptim, optuna, torch, tensorflow)
-
[9]
Run uv run pytest tests/ to verify functional correctness of the matrix transformation and the full test suite
-
[10]
Run uv run pytest tests/test_cpe.py to verify CPE identifier generation for compliance and SBOM tracking
-
[11]
Reference the CPE identifiers from §A.1 in vulnerability tracking systems and supply-chain disclosure documents
-
[12]
Consult get_cpe_identifier in src/spotforecast2_safe/utils/cpe.py for CPE generation in automated workflows
-
[13]
load", cat_features =[]) eval_ds = Dataset(eval_tbl, label =
Run uv run reuse lint to confirm SPDX/REUSE licensing compliance. A.13 A.13 Disclaimer & Liability LIMITATION OF LIABILITY : While this library is designed with safety principles and deterministic logic in mind, it is provided “AS IS” without any warranties. The developers and contributors assume NO LIABILITY for any direct or indirect damages, system fai...
-
[14]
URL: https://www.iso.org/standard/77304.html
Geneva. URL: https://www.iso.org/standard/77304.html. – (2023b). ISO/IEC 42001:2023 – Information technology – Artificial intelligence – Management system . International Organization for Standardization and International Electrotechnical Commission. ISO/IEC JTC 1/SC 42. Geneva. URL: https://www.iso.org/standard/81230.html. – (2023c). ISO/IEC 5338:2023 – ...
2023
-
[15]
LightGBM: A Highly Efficient Gradient Boosting Decision Tree
Geneva. URL: https://www.iso.org/standard/81118.html. Jiang, X. u. a. (2022). Kats . GitHub. Version 0.2.0. URL: https://github.com/facebookresearch/Kats . Ke, G., Q. Meng, T. Finley, T. Wang, W. Chen, W. Ma, Q. Y e und T.-Y . Liu (2017). “LightGBM: A Highly Efficient Gradient Boosting Decision Tree”. In: Advances in Neural Information Processing Systems ....
discussion (0)
Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.