Kloud Voyager

Independently validated against public Artemis II telemetry. Built for autonomy beyond continuous contact.

Mission:
Design bounded-autonomy architectures for systems that must act when oversight is out of reach.Problem:
Latency and intermittent contact demand local decision-making. Safety demands deterministic, bounded execution.Architecture:
Simulate → Detect → Navigate.

Mission 001: AROW 1

ARTEMIS II Validation

Using 3,262 publicly available Artemis II AROW state vectors, Kloud Voyager independently validated its autonomy-governance framework against a real crewed cislunar mission.Crucially, the framework discriminated between two physically distinct blackout mechanisms — a 41-minute lunar occultation and a ~6-minute reentry plasma blackout — through channel decomposition, not just total risk magnitude. Throughout, it held the core stability condition (dA/dρ ≤ 0): autonomy must not expand as mission risk increases. The study also identifies where deeper mission-specific telemetry could strengthen calibration before operational deployment.The same Simulate → Detect → Navigate architecture that governed this analysis is domain-independent by design. Cislunar space is simply the hardest place to prove it.Read the validation paper (SSRN) →
Sherwin Saballa, "Applied Validation of Bounded Autonomy Governance Using Artemis II Publicly Available Telemetry: From Cross-Domain Theory to Crewed Cislunar Operations." DOI: 10.2139/ssrn.6572018

Module 1

>kloud simulate

Model the operating environment and the system's possible futures under uncertainty — before and between missions. In the space instantiation: validating operational profiles across nominal, elevated, and extreme environmental scenarios.Status: In development

Module 2

>kloud detect

Fuse independent risk channels into a single composite index in real time — and decompose why risk is rising, not just that it is. In the space instantiation: dynamical proximity, epistemic uncertainty, and radiation regime, combined for early anomaly detection.Status: Validated against Artemis II telemetry

Module 3

>kloud navigate

Convert detected risk into bounded authority — deciding how much autonomy the system is allowed as conditions change, and degrading gracefully toward a pre-authorized safe state when oversight is out of reach. Authority never expands as risk rises (dA/dρ ≤ 0).Status: Prototype — first platform instantiationRoadmap: designed to extend to decentralized multi-agent operation — where each agent governs its own bounded authority, and individual stability guarantees compose into swarm-level safety with no central coordinator.

We have a lift off!!!

Simulate, Detect, and Navigate are three modules of one lightweight autonomy core — engineered for bounded, explainable operation when oversight is out of reach.Radiation-awareness is modeled, not yet hardware-implemented — a deferred capability pending hardware selection.The three modules are how the system is built. Plan → Survive → Adapt is how it behaves once deployed — a mission lifecycle, not an in-flight loop.

The current work spans a published governance architecture, a simulation study, and an early prototype. We rely on published radiation characterization data from CRaTER and established SPE fluence models for our calibration inputs. Hardware validation — including fault-injection testing and SEU-rate characterization — is explicitly scoped as future work.The Fermilab reference in the paper is specifically about the governance-architecture parallel — the beam-abort system as a physical instantiation of bounded autonomy — not as a radiation-testing facility for our work.

Current release focuses on simulation-validated architectures and early prototype modules; flight validation will follow phased partner programs.Independent work. Not affiliated with or endorsed by NASA or any government agency. Information provided is for technical and informational purposes only.

Frequently Asked Questions

//What is Kloud Voyager?Kloud Voyager builds a bounded-autonomy governance architecture — Simulate, Detect, Navigate — for autonomous systems that must operate safely when human oversight is out of reach. It is proven first in the hardest such environment, cislunar space, and is domain-independent by design.The work currently spans a published validation, a simulation study, and an early prototype. The present phase emphasizes architectural definition, simulation-based validation, and hardware-agnostic design. Environmental considerations such as radiation effects are intentionally deferred pending hardware selection and mission-profile definition.//Is this flight-proven software?Not yet — and we're precise about that distinction. Flight validation is scoped through future partner programs.What we have demonstrated is significant. During Artemis II — the first crewed lunar flyby since 1972 — we ran our bounded-autonomy framework in real time against NASA's publicly available AROW telemetry, entirely offline and network-independent. The framework correctly discriminated between two physically distinct communications blackouts — a 41-minute lunar occultation and a ~6-minute reentry plasma blackout — through channel decomposition, and held its core stability condition (dA/dρ ≤ 0) across every mission phase. The epistemic-uncertainty channel (σ²ₑ) rose sharply during the communications blackout, exactly as the model predicts when information about system state degrades.That is a real-world demonstration on real mission data — not a flight-proven system, but strong independent evidence that the architecture behaves correctly under genuine deep-space conditions.//What problem does Kloud Voyager address?Many spacecraft missions rely heavily on ground operations or fly with limited onboard autonomy due to cost, power, and reliability constraints. These limitations become more pronounced during communication delays, intermittent contact, or fault conditions.
Kloud Voyager supports bounded, explainable onboard autonomy — enabling a system to detect anomalies, maintain safe operational states, and execute limited autonomous responses when ground intervention is unavailable, while guaranteeing that its authority never expands as risk rises.//What types of missions is this intended for?
Kloud Voyager is intended for:1. CubeSat and SmallSat missions
Technology-demonstration payloads
2. University and research spacecraft
3. Cislunar and lunar-support missions
4. Missions operating with intermittent or delayed communicationsThe same autonomy and anomaly-detection capabilities also apply to Earth-observation missions where similar constraints exist — limited ground contact, reduced staffing, or strict power and bandwidth budgets. More broadly, the architecture is domain-independent by design; space is our beachhead, not our boundary.//What hardware platforms are supported?The software architecture is designed to be hardware-agnostic.
Initial validation targets widely adopted, developer-accessible edge-computing platforms (e.g., Jetson-class embedded GPUs) to accelerate simulation, verification, and fault characterization.Hardware-abstraction layers are designed to support future migration to lower-power systems-on-chip and space-qualified processors as mission requirements mature.
Final platform support will be informed by partner needs and mission constraints.//What does "radiation-aware" mean in this context?In the current phase, radiation-awareness refers to planned accommodation of radiation-mitigation strategies — not implemented capability.
Radiation effects are physical-layer concerns that depend on hardware selection, orbit, shielding, and mission duration. The present architecture is hardware-agnostic and simulation-focused, and does not yet implement radiation-specific fault models or mitigation mechanisms. This is not a claim of radiation-hardened hardware.Where radiation appears as a risk channel in our analysis, it is a modeled regime indicator drawn from published characterization data (e.g., CRaTER measurements and established SPE fluence models), not onboard sensing.
Radiation-mitigation strategies will be addressed in later phases once physical constraints are defined.//How does Kloud Voyager handle autonomy safely?The system is built around bounded autonomy and explicit safety constraints. Autonomous behaviors are limited in scope, explainable, and subject to predefined operational boundaries. Safety evaluation, anomaly detection, and operational execution are architecturally separated to support fault isolation and predictable degradation. As risk rises, authority contracts rather than expands; when oversight is unreachable, the system falls back to a pre-authorized safe state rather than awaiting a ground contact that may not be available.//Is telemetry shared publicly?No. Any telemetry or mission data shared with Kloud Voyager is handled under partner agreements and used solely for development, testing, and validation.//What are you looking for in beta partners?Kloud Voyager seeks early partners willing to:Share non-sensitive mission scenarios or telemetry
Provide operational feedback
Collaborate on defining real-world autonomy requirementsThese partnerships help ensure the system addresses practical mission needs rather than purely theoretical use cases.//How does this relate to NASA Artemis?Kloud Voyager is independent and is not affiliated with, or endorsed by, NASA. Our work uses only publicly available NASA data — the Artemis II AROW ephemeris.The design philosophy aligns with Artemis objectives — supporting autonomous operations, reducing ground-operational burden, and enabling resilient spacecraft behavior in cislunar environments — and we are building with future collaboration pathways in mind. We are not currently part of any active NASA flight program.//Is this an open-source project?Kloud Voyager follows an open-core philosophy. Certain foundational components may be released openly, while mission-specific or safety-critical components remain proprietary.
Cloud-based infrastructure is used for simulation, training, and validation. All mission-critical inference and decision execution are designed to run locally on spacecraft hardware, with no operational dependency on cloud connectivity during flight.//How can I become a beta partner?Interested organizations can express interest through the website. Kloud Voyager will follow up to understand mission profiles, constraints, and potential collaboration fit.
//What are the current development priorities?
Current priorities focus on:Simulation-based autonomy validation
Architectural refinement and verification
Anomaly detection and bounded decision logic
Hardware-agnostic design and abstractionEarth-observation and other terrestrial applications are pursued only where they align with these core technical objectives.

The story of kloud

> Why Kloud Voyager ExistsWhy Kloud Voyager ExistsI didn't start Kloud Voyager in a lab. I started it under trees.Nature has been my compass for as long as I can remember. It was the light through the leaves that drew my mother's rare smiles from her wheelchair. It was the stillness among the oaks that held me together when my world fractured.When my son was baptized, we walked out of the church and into the woods, because that felt like the truer cathedral. And it was in the forest that Liana and I gathered fallen twigs to weave a basket, not realizing she was weaving me back to life. She taught me that technology without reverence is just noise.So when I began building autonomy for spacecraft — software that has to survive blackouts, radiation, and deep isolation, far from any help — I didn't turn only to the equations. I returned to the forest.Because the forest is the original resilient system. It thrives in uncertainty. It recovers without panic. It adapts without losing what it is. That is the intelligence I'm building into Kloud: not just artificial, but resilient the way living systems are — bounded, aware, and responsible for itself when no one is watching.The forest taught me to endure. The old wayfinders taught me to navigate. For thousands of years, Pacific navigators crossed open ocean with no instruments and no sight of land — reading the swells, the stars, and the wind all at once, trusting a fused picture of many signals precisely when they could see nothing ahead. That is exactly what a spacecraft must do when Earth goes silent: read every channel it has, and find its way with confidence through the dark. It's how the system senses risk — not from any single reading, but from all of them together.That's the question I kept asking the trees, and then the ocean, and then the spacecraft: how do you endure — and find your way — alone, yet never truly isolated?Stewardship isn't about control. It's about care that persists, even in silence — whether the system is carrying a satellite through a lunar eclipse or watching wildfire scars from orbit. I build for space, but my roots stay in the soil: among the pines, with my son, in the memory of my mother's smile beneath the canopy.We're proving that space exploration was never really about leaving. The pale blue dot we're trying to protect doesn't begin in orbit. It begins right here.Exploration is homecoming. Rooted in Earth — reaching for the Moon.

Why KloudSpacecraft autonomy is often designed for ideal conditions — steady power, continuous communication, nominal system health. Real missions don't operate that way.Kloud Voyager is building an autonomy architecture — validated against real mission data and proven in early prototype — for environments where resources fluctuate, communication is intermittent, and systems must degrade predictably rather than fail abruptly. Instead of treating autonomy as all-or-nothing, Kloud governs onboard intelligence through explicit operating regimes — nominal, degraded, survival — with clear boundaries, explainable behavior, and conservative responses under uncertainty. As risk rises, authority contracts; it never expands.This approach prioritizes:1. Bounded, explainable autonomy over opaque decision-making
2. Graceful degradation over brittle optimization
3. Evidence through simulation and validation over premature claimsKloud is designed to sit alongside your existing flight software, not replace it — a governance layer that bounds what your autonomy is permitted to do, validated incrementally against your own mission profiles. For partners, that means deploying more ambitious autonomy with less operational risk, on a foundation built for safety, resilience, and long-duration operation beyond continuous ground contact.