3.3.1

HLV‑RAPS — Version 3.3.1 Release Notes

Release Date: April 11, 2026
Maintainer: Don Feeney
Scope: Supervisor Failure‑Mode Normalization Patch

Overview

Version 3.3.1 delivers a targeted corrective patch addressing inconsistency bugs in supervisor failure‑mode naming. Divergent spellings of the prediction‑mismatch failure mode across active components resulted in inconsistent reason strings, enum semantics, and log/metric outputs. This patch normalizes the naming to a single canonical value to ensure coherence across runtime behavior, diagnostics, and API‑facing failure reporting.

---

Key Fixes

1. Failure‑Mode Normalization

A misspelled enum value (MISMATED_PREDICTION) was present in active supervisor logic, causing mismatch failures to emit inconsistent identifiers.

Corrected enum name:

MISMATED_PREDICTION  →  MISMATCHED_PREDICTION

Updated in:

• include/supervisor/redundant_supervisor.hpp

This ensures all components reference the same canonical failure mode.

---

2. Reason‑String Alignment

The supervisor failure‑string mapping has been updated to match the normalized enum and emitted text.

Updated in:

• src/supervisor/supervisor_failure_strings.hpp

Before:

case RedundantSupervisor::FailureMode::MISMATED_PREDICTION:
    return "MISMATED_PREDICTION";

After:

case RedundantSupervisor::FailureMode::MISMATCHED_PREDICTION:
    return "MISMATCHED_PREDICTION";

This ensures all mismatch‑prediction failures emit a consistent, canonical string across logs, metrics, and API surfaces.

---

Scope

• Changes are limited to active runtime headers and source files involved in supervisor failure typing and stringification.
• Reference‑only artifacts were intentionally left unchanged to avoid unnecessary churn.
• No behavioral changes beyond naming normalization.

---

Impact

This is a non‑breaking patch release.
It improves consistency, observability, and downstream analytics without altering supervisor logic or external APIs.

3.3.0

HLV‑RAPS — Version 3.3.0 Release Notes

Release Date: April 11, 2026
Maintainer: Don Feeney
Scope: Stability Layer Upgrade + System‑wide Version Standardization

Overview

Version 3.3.0 delivers a focused upgrade to the RAPS stability layer, strengthening coherence‑aware flight handling and improving deterministic safety behavior across the HLV stack. This release introduces maneuver‑aware Stability Indicator constraints, hysteresis‑based state tracking, and rate‑of‑change guardrails, all integrated directly into DSM event logic. The entire repository has been standardized to version 3.3.0 for consistency.

---

Key Changes

1. Upgraded Stability Indicator Subsystem

The Stability Indicator has been enhanced to support aggressive maneuver envelopes and maintain coherence integrity under dynamic conditions.

Enhancements include:

• Maneuver‑aware coherence thresholds
  Adaptive Sᵤ bounds based on flight regime (cruise, mild, aggressive).

• Hysteresis state‑tracking
  Prevents mode‑flapping near boundary conditions and stabilizes transitions.

• Rate‑of‑change limits
  Enforces |dSᵤ/dt| ceilings to detect coherence collapse before it propagates.

• DSM event integration
  New structured events emitted for:

  • low‑stability conditions
  • rate‑violation detection
  • hysteresis transitions

These improvements strengthen predictive safing and enhance replay determinism.

---

2. Repository‑wide Version Standardization

All version references across the RAPS codebase, documentation, manifests, and configuration files have been updated to:

3.3.0

This ensures consistency across modules and aligns the stability‑layer upgrade with the unified release cadence.

---

Impact

This release is backward‑compatible and does not modify external APIs.
It improves safety, coherence tracking, and maneuver‑response fidelity without altering existing mission profiles.

---

Next Steps

The upcoming 3.4.0 release will introduce the new HLV‑Battery RAPS module.

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