3.4.0

HLV‑RAPS — Version 3.4.0 Release Notes

Release Date: May 7, 2026
Maintainer: Don Feeney
Scope: Wave‑Native Network (WNN) Telemetry Integration + DSM Hard‑Invariant Safing + Rollback Path Hardening

---

Overview

Version 3.4.0 introduces the first full integration of the Wave‑Native Network telemetry substrate into the Recursive Autonomous Projection System (RAPS). WNN now feeds curvature proxies, oscillatory prefactors, and coherence‑aware metrics directly into the Deterministic Safety Monitor (DSM).

RAPS 3.4.0 enforces a hard‑invariant safety contract:

If any WNN metric breaches its threshold or arrives malformed, DSM triggers an immediate rollback to the last known safe state using the new statically allocated StateSnapshotBuffer (backed by TelemetryRingBuffer).

No graceful degradation. No negotiation.
Rollback is deterministic, allocation‑free, and fully logged to the Immutable Telemetry Ledger (ITL).

This release also hardens the WNN→DSM safing path, ensuring malformed telemetry, non‑finite values, and rollback‑store edge cases all fail closed and remain fully auditable.

---

Key Changes

---

1. WNN Telemetry Validation & Safing Behavior

• Added explicit non‑finite (NaN/Inf) detection for all WnnTelemetry fields before threshold evaluation.
• Unified WNN breach handling so invalid telemetry and threshold violations both drive deterministic rollback safing.
• Added DSM diagnostics for WNN‑triggered safing events, including curvature‑breach and oscillatory‑prefactor guardrail violations.
• Hardened DSM to fail closed on:
  • negative curvature estimates,
  • non‑finite oscillatory prefactors,
  • malformed telemetry shapes.

---

2. ITL Logging Hardening for Invalid Telemetry

• Sanitized non‑finite WNN telemetry values before ITL commit using the named sentinel:
  DSM_Config::INVALID_TELEMETRY_SENTINEL
  to avoid ambiguous raw invalid values in the ledger.
• Preserved WNN alert + rollback commit emission for audit continuity.
• Implemented full ITL lifecycle for WNN DSM events:
  • payload sizing,
  • entry hashing,
  • flash‑backed commit,
  • Merkle batching,
  • flush behavior,
  • success‑returning rollback event logging.

---

3. Rollback‑Path Safety Guards

• Hardened trigger_wnn_immediate_rollback(...) to safely return when:
  • rollback_store == nullptr,
  • rollback_count == 0,
  • rollback plan is invalid or out‑of‑range.
• Eliminated unsafe dereference assumptions in WNN‑triggered rollback flow.
• Added validation for non‑finite thrust/gimbal values before rollback execution.

Updated rollback guard:

inline bool trigger_wnn_immediate_rollback(
    const RollbackPlan* rollback_store,
    uint32_t rollback_count,
    PhysicsState& active_state_pointer
) {
    if (rollback_count == 0 || rollback_store == nullptr) {
        return false;
    }
    // existing rollback execution path...
}

---

4. Statically Allocated Rollback Storage

• Introduced StateSnapshotBuffer backed by TelemetryRingBuffer for allocation‑free rollback storage.
• Ensures deterministic timing and eliminates dynamic memory from the safing path.
• Guarantees that rollback always targets a validated, last‑known‑safe state.

---

5. SIL Coverage Expansion

Added extensive SIL coverage for WNN‑integrated DSM behavior:

• Nominal WNN telemetry → DSM pass‑through.
• Threshold‑triggered rollback.
• Invalid telemetry fail‑closed behavior.
• Reversed‑dilation full‑shutdown behavior.
• Null rollback store with non‑zero count.
• Empty rollback store behavior.
• Out‑of‑range rollback count hardening.
• Non‑finite thrust/gimbal rollback validation.
• Registered new DSM WNN SIL test target in CMake.

---

Impact

RAPS 3.4.0 establishes the first physics‑informed, wave‑native safing substrate in the HLV ecosystem.
The DSM now enforces WNN coherence metrics as hard invariants, ensuring that any deviation—numeric, physical, or malformed—results in a deterministic, auditable rollback to a safe state.

This release significantly increases safety, observability, and determinism across the entire flight stack.

3.3.2 MIT

🚀 The Transition to 100% Open Source (MIT)

Effective with this release, HLV-RAPS is transitioning from a hybrid licensing model to the pure, permissive MIT License.

The goal of this project has always been to push the boundaries of computational architecture. By removing commercial licensing friction, this technology is now completely open for unrestricted adoption, integration, and scaling by the broader research and enterprise community.

💼 Enterprise Consulting & Integration

While the core frameworks are now freely available, deploying complex architectures at an enterprise level requires precision.

If your organization requires custom scaling, proprietary integration, or dedicated technical consulting to deploy these models into your tech stack, I am officially opening my calendar for commercial consulting.

Contact for implementation and advisory roles: dfeen87@gmail.com

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 ✅