3.2.1

HLV‑RAPS v3.2.1 — Patch Release

Release Date: 2026‑04‑05
Scope: Documentation corrections and consistency fixes.
Code Changes: None.

This patch release resolves factual inconsistencies, stale references, and formatting issues introduced or left unresolved after the v3.2.0 hardening round. No source code, API, or architectural changes were made.

---

Documentation Corrections & Consistency Fixes

Version Alignment

• CHANGELOG.md: Corrected incorrect VERSION file reference inside the [3.2.0] entry
  • (2.4.0) → (3.2.0)
• CITATION.cff: Updated year: 2025 → year: 2026 to match LICENSE copyright.
• docs/TELEMETRY_DASHBOARD.md: Updated three stale v2.3/v2.3.0 references → v3.2/v3.2.0.
• docs/contracts/TELEMETRY_STORAGE_CONTRACT.md: Updated contract header
  • (RAPS v2.3.0) → (RAPS v3.2.0).

Broken File Reference

• Fixed incorrect reference to docs/telemetry_dashboard_v2.3.md
  → Corrected to docs/TELEMETRY_DASHBOARD.md.

---

Quick Start Corrections

RTOS Demo

• Removed misleading implication that hlv_rtos_demo is produced by the SIL CMake build.
• Replaced with accurate prose clarifying it is a platform‑specific reference example with no standalone CMake target.

REST API Demo

• Added correct build and run instructions:

  cmake -S examples/api_client -B build/api_demo
  cmake --build build/api_demo
  ./build/api_demo/rest_api_demo
  

curl Example

• Corrected nonexistent endpoint:
  /api/status → /health.

---

Formatting & Completeness Improvements

• docs/architecture.md:

  • Added missing # System Architecture title.
  • Completed dangling sentence with correct path:
    src/common/types.hpp.

• docs/sil_hil.md:

  • Wrapped ASCII architecture diagram in a code fence.
  • Fixed misaligned (SIL) and (HIL) labels for readability.

---

Summary

This release focuses exclusively on documentation accuracy, clarity, and consistency. All changes are non‑breaking and do not affect runtime behavior, APIs, or build outputs.

3.2.0

RAPS v3.2.0 — Security & Stability Hardening Release

Date: 2026‑03‑04

This release delivers targeted fixes across the power/resource management layer, PDT engine, REST API server, and safety subsystems. It eliminates several division‑by‑zero pathways, strengthens numerical stability, adds compile‑time safety guards, and improves maintainability with new versioning infrastructure.

---

Security

• Division‑by‑zero protection in power & resource management when elapsed_ms == 0.
• PID controller fix: parameter type corrected (float → uint64_t) with proportional‑only fallback when dt == 0.
• Monte Carlo engine hardening: prevent division by zero when monte_carlo_runs == 0.
• Field coupling stress model: clamp exponential argument to avoid +inf propagation.
• REST API request safety:
  • Added MAX_REQUEST_SIZE = 8192 limit.
  • Added CORS‑related risk comment for integrators.
• Cryptography safety: compile‑time guard added to prevent stub crypto from being used in production builds.

---

Robustness

• NaN/Inf state sanitizer added (include/safety/state_sanitizer.hpp) and integrated into APCU safety update.
• Rollback store bounds fix: oldest entry is now evicted instead of resetting the counter to zero.
• Telemetry JSONL handling: improved truncated‑line detection for oversized lines.
• Artificial gravity: fixed implicit narrowing in rate‑limit computation.

---

Architecture

• RAPSConfig deduplication: removed conflicting definitions from hlv_field_dynamics.hpp.
• Integrator safety: added non‑production compile guard to reference integrator header.
• Include path cleanup: fixed broken includes in advanced_propulsion_control_unit.hpp.

---

Maintainability

• Added top‑level VERSION file (3.2.0).
• Added CHANGELOG.md.
• Added RAPSVersion namespace constants to raps_core_types.hpp.
• Updated REST API /health endpoint to return RAPSVersion::STRING.

---

Summary

v3.2.0 is a focused hardening release that eliminates numerical hazards, strengthens safety‑critical subsystems, improves REST API resilience, and introduces clearer versioning infrastructure. These changes collectively raise the reliability and operational safety of the RAPS middleware stack.

3.1.0

RAPS v3.1.0 — Rollback Execution Safety Upgrade

Version 3.1.0 strengthens the reliability and safety guarantees of the Rollback Execution subsystem. This release introduces strict validation logic to prevent unsafe or malformed rollback commands from ever reaching the control layer, and adds a dedicated SIL test suite to verify correct behavior across edge cases.

---

Added

• Strict validation in execute_rollback_plan (src/raps/rollback_execution.hpp):

  • Rejects invalid or unsafe rollback commands, including negative thrust values, NaN/Inf angles, and malformed control inputs.
  • Ensures only well‑formed, physically safe rollback actions are executed.
  • Improves system robustness during fault recovery and state rewinds.

• New SIL test suite — tests/sil/test_rollback_execution.cpp:

  • Verifies validation logic for all rollback command types.
  • Confirms rejection of unsafe inputs and correct handling of valid rollback plans.
  • Establishes a baseline for future regression testing.

---

Impact

These improvements harden the rollback subsystem against malformed inputs, reduce the risk of unsafe actuator commands during recovery sequences, and provide a reproducible test harness for ongoing development.

HLV‑RAPS v3.0.0

Read‑Only REST API for Flight‑Ready Observability

Overview

Version 3.0.0 introduces a fully integrated, read‑only HTTP/JSON REST API for the HLV‑RAPS Flight Middleware. This API provides deterministic, thread‑safe, LAN‑wide observability into all major subsystems of the RAPS governance loop — without exposing any control surfaces or altering flight‑critical behavior.

The implementation is lightweight, POSIX‑compliant, and designed for safety‑critical environments where determinism, bounded latency, and strict separation of responsibilities are required.

---

Key Features

1. Read‑Only REST API

• GET‑only endpoints
• POST/PUT/DELETE return 405 Method Not Allowed
• No control surfaces exposed
• Safe for flight‑software observability

2. Lightweight POSIX Server

• Pure POSIX sockets
• No external dependencies
• Minimal footprint
• Designed for embedded and RTOS‑backed systems

3. Dedicated Non‑Blocking Thread

• Runs independently of the governance loop
• Uses std::thread
• Zero impact on deterministic timing
• Clean shutdown and join behavior

4. Mutex‑Protected Snapshot Access

• All shared state accessed through a snapshot provider callback
• std::mutex ensures thread‑safe reads
• No race conditions or partial reads

---

API Endpoints

Endpoint	Description
GET /health	Service health and uptime
GET /api/state	Physical state Ψ and informational state Φ
GET /api/pdt	Predictive Digital Twin forecast, confidence, uncertainty
GET /api/dsm	Deterministic Safety Monitor status and active gates
GET /api/supervisor	A/B supervisor state, failover, mismatch flags
GET /api/rollback	Rollback status and last rollback event
GET /api/itl	Latest ITL telemetry entries (Merkle‑anchored)

All endpoints return structured JSON with deterministic formatting.

---

Files Added

API Infrastructure

• include/raps/api/api_snapshot.hpp
• include/raps/api/rest_api_server.hpp
• src/api/rest_api_server.cpp

Documentation

• docs/REST_API.md — full endpoint reference
• examples/api_client/README.md — usage guide

Examples

• examples/api_client/rest_api_demo.cpp
• examples/api_client/api_client.py
• examples/api_client/CMakeLists.txt

Repository Updates

• Updated README.md with REST API section
• Fixed include path in include/hlv/spacetime_modulation_types.hpp
• Updated .gitignore to exclude build directories

---

Testing & Validation

• All endpoints tested with curl
• Python client validated (stdlib only)
• Error handling verified (404, 405)
• SIL tests: 100% pass rate
• CMake build successful
• All code review feedback addressed

The API is stable, deterministic, and ready for integration.

---

Security Considerations

Designed for trusted LAN environments:

• Read‑only
• No authentication
• No encryption (HTTP)
• Minimal attack surface
• Thread‑safe snapshot access

For production flight systems, deploy on isolated networks or behind authenticated gateways.

---

Integration Example

raps::api::RestApiServer api_server;
api_server.set_snapshot_provider( {

return create_system_snapshot();  // User-defined snapshot

});
api_server.start(8080, "0.0.0.0");

// Runs in background, non-blocking

---

Summary

HLV‑RAPS v3.0.0 delivers a complete, flight‑safe observability layer through a lightweight, deterministic REST API. It exposes the full internal state of the RAPS governance loop — PDT, DSM, supervisor, rollback, ITL, and dual‑state modeling — without compromising safety or timing guarantees.

This release makes RAPS easier to integrate, test, validate, and monitor across SIL, HIL, and flight‑ready environments.

HLV-RAPS

Version 2.7.0 — Release Notes

Overview

Version 2.7.0 delivers critical fixes to the propulsion physics engine and HIL rig server, ensuring correct validation of spacecraft velocity states and restoring compatibility with standard C++ time utilities. Additional repository hygiene improvements were included to maintain a clean development environment. All changes were minimal, targeted, and fully backward‑compatible.

---

Bugs Fixed

Velocity Validation Logic Bug

Files: src/physics/propulsion_physics_engine.cpp (lines 173–176)
Header Update: include/PropulsionPhysicsEngine.hpp

Problem:
Velocity components were validated using a comparison against MIN_VELOCITY_M_S (−20000 m/s).
This logic incorrectly rejected:

• All positive velocities
• All negative velocities greater than −20000 m/s

Impact:
The safety monitor would incorrectly reject valid spacecraft states, including normal forward motion and small negative velocities.

Fix:

• Replaced directional checks with absolute‑value validation against MAX_VELOCITY_M_S (20000 m/s).
• Ensures velocity bounds are enforced symmetrically, regardless of direction.
• Moved MAX_VELOCITY_M_S constant to class scope for consistency with other physics constants.

---

Steady Clock Bug

File: examples/hil/hil_rig_server.cpp (lines 44–46)

Problem:
The code attempted to call steady_clock::now().time_since_epoch(), which is not supported by std::steady_clock.

Impact:
Compilation failure when building the HIL rig server.

Fix:
Replaced steady_clock with system_clock, which correctly supports time_since_epoch().

---

Additional Improvements

Repository Hygiene

• Added a comprehensive .gitignore to exclude build artifacts, IDE files, and temporary files.
• Ensures a clean repository with only source‑level files tracked.

---

Verification

• All existing SIL fault‑injection tests pass
• Code compiles cleanly with no errors
• CodeQL security scan reports zero vulnerabilities
• All code review feedback addressed

---

Files Changed

• .gitignore — new file added
• include/PropulsionPhysicsEngine.hpp — added MAX_VELOCITY_M_S constant
• src/physics/propulsion_physics_engine.cpp — corrected velocity validation logic
• examples/hil/hil_rig_server.cpp — replaced steady_clock with system_clock

---

Summary

Version 2.7.0 resolves all identified issues with minimal, targeted modifications.
The physics engine now validates velocity correctly, the HIL rig server builds successfully, and the repository is cleaner and more maintainable.

v2.6.0

Motivation

Reduce redundant square-root computations and improve numeric robustness in the propulsion physics hot path, while preserving existing safety and plausibility semantics.

Description

• Introduced normalize_with_mag(...) using a squared epsilon (kNormalizeEpsilonSq) to compute both the unit vector and magnitude in a single pass, eliminating redundant sqrt calls.
• Reused the magnitude returned from normalization for gravity and drag calculations, reducing duplicate work and improving behavior near zero-length vectors.
• Normalized thrust direction once prior to the integration loop instead of repeatedly calling a standalone normalization routine.
• Updated the plausibility radius check to use a squared-distance comparison, avoiding an unnecessary square-root operation.
• All changes are contained within src/physics/propulsion_physics_engine.cpp.

Testing

• Configured the SIL test suite with:

  cmake -S tests/sil -B tests/sil/build

• Built the SIL tests using:

  cmake --build tests/sil/build

  (completed successfully with unrelated test-file warnings)

• Executed the test suite with:

  ctest --test-dir tests/sil/build

• Verified successful execution of the SIL test:

  • raps_sil_fault_injection ✅

Release v2.5.0

Motivation

Correct a unit-scale error in PID integral accumulation caused by using milliseconds instead of seconds, which resulted in incorrect controller gain scaling.
Additionally, prevent integral and derivative updates when the timestep is non-positive to avoid undefined or unstable control behavior.

Description

• Updated compute_pid_output in src/control/pid_controller.hpp to compute a seconds-based timestep (dt_s = elapsed_ms / 1000.0f).
• Use dt_s consistently for:
  • Integral accumulation
  • Derivative calculation
• Guard integral and derivative updates so they only execute when dt_s > 0.0f, preventing divide-by-zero and invalid state updates.
• Preserved the existing anti-windup behavior via integral_limit.

Impact

This change corrects PID controller scaling and improves numerical stability.
Controller behavior may differ from previous versions due to corrected time integration; PID gains may require retuning.

Testing

No automated tests were executed for this change.
The update was reviewed via code inspection.

RAPS v2.4.0 — Deterministic Safety Hardening

Previous Version: v2.3.1
Current Version: v2.4.0

---

Summary

This release strengthens the Deterministic Safety Monitor (DSM) to ensure fail-safe behavior in the presence of corrupted, undefined, or non-finite telemetry inputs.

RAPS now explicitly detects NaN and Inf values and forces a full shutdown rather than continuing evaluation with unsafe internal state. This improves determinism and safety under real-world sensor fault conditions.

---

Motivation

• Prevent unsafe evaluation paths when telemetry contains NaN or Inf
• Ensure the DSM fails safe instead of propagating invalid internal computations
• Eliminate undefined or misleading calculations caused by corrupted sensor data
• Improve resilience against faulty sensor channels and upstream data corruption

---

Changes

Deterministic Safety Monitor Hardening

• Added hasInvalidInputs() helper using std::isfinite to validate telemetry inputs
• Short-circuited evaluateSafety() to:
  • Log an alert
  • Activate safing_sequence_active_
  • Return ACTION_FULL_SHUTDOWN immediately when invalid inputs are detected
• Explicitly validated the following telemetry fields for finiteness:
  • measured_proper_time_dilation
  • measured_oscillatory_prefactor_A_t
  • measured_tcc_coupling_J
  • current_resonance_amplitude

Files Modified

• include/raps/safety/deterministic_safety_monitor.hpp

---

Testing

• No automated tests were executed for this change
• Logic is deterministic and isolated to input validation
• Recommended follow-up testing:
  • Unit tests with injected NaN / Inf values
  • Verification that shutdown behavior triggers consistently

---

Safety Impact

High (Positive)

This release reduces systemic risk by ensuring corrupted telemetry cannot propagate into unsafe control decisions. Fail-safe shutdown is now guaranteed when invalid inputs are detected.

---

Versioning Rationale

A minor version bump (v2.3.1 → v2.4.0) is appropriate because:

• No public API was broken
• Safety behavior was materially strengthened
• System guarantees were improved beyond a simple bug fix

RAPS-HLV 2.3.1 — Release Notes

Release Focus: Build stability, SIL test reliability, and core definition cleanup.

Highlights

• SIL build reliability improved by linking the PlatformHAL implementation into the SIL test target, eliminating unresolved HAL symbols at link time.

• Compile-time safety checks fixed for SIL fault injection configuration by replacing invalid preprocessor float comparisons with constexpr + static_assert validation.

• Header wiring compatibility improved via a shim header for raps/core/raps_definitions.hpp, ensuring builds resolve the correct definitions across include paths.

Internal Fixes / Maintenance

• Consolidated and clarified build plumbing for SIL tests.

• Strengthened fault injection configuration validation without runtime overhead.

• Improved include stability for the RAPS definitions API across modules and tests.

Test Results

• SIL build config: cmake -S tests/sil -B tests/sil/build

• SIL build: cmake --build tests/sil/build

• SIL tests: ctest --test-dir tests/sil/build (1/1 passed)

RAPS v2.3.0 — Telemetry & Observability Hardening

Release Type: Minor (non-behavioral)
Scope: Observability, diagnostics, and operational clarity
Compatibility: Fully backward-compatible
Runtime Behavior: No changes

---

Overview

RAPS v2.3.0 introduces a production-hardened telemetry and observability subsystem designed to provide deep post-run insight without impacting runtime determinism, safety, or control behavior.

Telemetry is formally defined as a strictly observational layer:
it records what happens, but never influences execution.

No control logic, safety thresholds, or actuation pathways were modified.

---

Key Additions

Telemetry Core (Runtime)

• Bounded, allocation-free telemetry logger
• Fixed-capacity ring buffer with explicit drop accounting
• Non-blocking, best-effort event emission
• Deterministic monotonic timestamps (wall time optional, disabled by default)
• Explicit severity, subsystem, and event typing

Telemetry failure is non-fatal by design.

---

Storage Model & Contracts

• Standardized, per-run telemetry directory structure
• Append-only JSON Lines event log (telemetry.jsonl)
• Optional human-readable summary (summary.txt)
• Immutable run metadata (meta.json)
• Best-effort latest symlink for tooling

A formal, normative storage contract now governs telemetry behavior:

docs/contracts/TELEMETRY_STORAGE_CONTRACT.md

---

SIL & HIL Integration

Telemetry is now integrated cleanly into both execution environments:

Software-in-the-Loop (SIL)

• Deterministic timing harness
• Explicit lifecycle events (start / stop)
• Deadline monitoring (observational only)

Hardware-in-the-Loop (HIL)

• Hardware bring-up visibility
• Actuation and timing diagnostics
• Deadline miss tracking

Integration is entry-point scoped and does not touch HAL, supervisor, or control logic.

---

Dashboard & Tooling

• Hardened post-run telemetry report tool
• Safe, read-only parsing of JSONL event logs
• Aggregated counts by severity and event type
• Explicit reporting of dropped events

Dashboard tools read telemetry only and never modify runtime artifacts.

---

Documentation & Discoverability

• Telemetry dashboard guide
• Data directory README for operators
• Clear separation between contracts, guides, and tooling
• No ambiguity between observability and control responsibilities

---

Safety & Determinism Guarantees

This release explicitly guarantees:

• Telemetry never blocks the control loop
• Telemetry failures do not alter execution
• No telemetry-driven decisions
• Bounded memory usage
• No file corruption or overwrite
• Multiple readers are always safe

Telemetry is a passive witness, not a participant.

---

What Did Not Change

• Control algorithms
• Safety thresholds
• Actuation logic
• Scheduling or timing semantics
• SIL/HIL behavior
• Hardware abstraction layers

This release is observability-only.

---

Migration & Usage

No migration is required.

Existing deployments may opt-in to telemetry by enabling the provided entry-point integrations. Telemetry artifacts are self-contained and portable.

---

Closing Notes

v2.3.0 establishes a clear observability boundary for RAPS:

Deep insight. Zero interference.

This foundation enables future diagnostic, audit, and analysis tooling while preserving the system’s core safety and determinism guarantees.