[ HELIOS PRIME · PROTOTYPE LABORATORY ]
We build software
that answers questions
nobody asked us to answer.
Helios Prime is an experimental software laboratory. We prototype systems in space, intelligence, and cyber domains, not because someone asked us to, but because the questions are just too interesting to ignore.
"Can security reasoning be fully automated? We're finding out. Slowly."
"What does orbital analytics look like when nobody is watching? Selene is trying to answer that."
"Is 'good enough' a form of wisdom or a form of laziness? The lab votes: depends on the deadline."
"What if the prototype was the point all along?"
[ what_is_this.md ]
A lab. Specifically, a software prototype lab.
Most software gets built because someone needs it. We build software because a question demands an answer.
Helios Prime is a small, independent prototype laboratory. We take hard problems in software, particularly in space systems, intelligence engineering, and cyber, and we build experimental systems to explore them. Some of these become useful tools. Some become cautionary tales. Most become both.
We think carefully, build deliberately, and document honestly. Including the parts that didn't work.
[ currently_running.log ]
The Experiments
Our active prototypes. Each one is answering a question, or multiple questions, or generating more questions. Some of the answers are surprising.
EXP-001
flip for detailsVanguard
Static Analysis for RMF-First Engineering.
Vanguard
"Can a static analysis engine generate continuous, audit-ready RMF evidence as developers build, accelerating toward ATO?"
An automated code analysis engine that maps software behavior against NIST control families, patterns, and threat models. It triages its own findings before surfacing them.
EXP-002
flip for detailsSoteria
RMF Compliance Engine.
Soteria
"What if federal cybersecurity compliance was automated, continuous, and machine-verifiable, from developer commit through production?"
A continuous evidence engine that treats assurance artifacts as data streams rather than static reports. Audit state is always current.
EXP-003
flip for detailsSelene
Experimental SDA analytics.
Selene
"Can residual analysis (i.e., bias, drift, discontinuities, and non-random structure) serve as a sensor-agnostic, transparent, and explainable foundation for SDA?"
Sensor-agnostic indicators of maneuvers, anomalies, and sensor/track degradation in a transparent, explainable environment.
EXP-004
flip for detailsKairos
An Experiment in Mission Containers.
Kairos
"Can an event become an operational container, not a calendar entry, and can a workspace unify planning, metadata, logs, attachments, and mission‑relevant assets into one continuous operational context?"
A multi-node operational timing engine. Not a calendar. A system that treats sequencing and coordination as a first-class design constraint.
EXP-005
flip for detailsSENTINEL-Ω
An Experiment in AI-Enabled Threat Fusion.
SENTINEL-Ω
"Can an AI-enabled fusion engine unify OSINT, indicators, sentiment, and multi-domain threat classification into a single workflow?"
A multi-source intelligence fusion engine to ingest, correlate, and generate assessments.
EXP-006
flip for detailsHelios
From orbital data to operational awareness.
Helios
“We built Helios because we could. We simply wanted a cool 3D space SSA tool.”
An interactive 3D globe built to answer the questions operators ask in real time: Where is it? What can it see? What can we see? What’s changing? What needs attention now?
[ failure_log.md — not redacted ]
Things That Didn't Work
FL-001
"We tried to auto-generate compliance narratives with an LLM."
The output was syntactically flawless but substantively hollow. It read like someone had asked a very confident person who had never worked in security to write about security.
FL-002
"We modeled Selene using orbital regime baselines."
Reality based dynamics destroyed these assumptions. Our model had regime intuitions baked in at a level we hadn't considered until the data disagreed loudly.
FL-003
"We built an over-engineered orchestration layer for Kairos before validating the core timing primitive."
Spent six weeks on infrastructure for a mechanism we hadn't confirmed was the right mechanism. Classic. We teach this mistake to people and then made it ourselves.
More failures available upon request. We have a long list.
[ signal_archive ]
Lab Notes
When the prototype teaches us something worth writing down, we write it down.
RMF-First Engineering
Compliance as an Engineering Discipline: How RMF-First Engineering Redefines the Relationship Between Evidence, Architecture, and Continuous Security.
Automated Reasoning and the Confidence Problem
A system that is wrong and confident is more dangerous than one that is wrong and uncertain. Here's how we're thinking about it.
The Geometry of False Positives
When we mapped SENTINEL-Ω's false positive distribution, it looked almost deliberate. It wasn't. That distinction matters enormously.
Compliance Is Not Security (And Everybody Knows This)
Everyone says compliance isn't security. Very few people build systems that reflect this understanding. We're trying.
What Selene Taught Us About Residuals
Selene began as an SDA analytics prototype. It became a lesson in what happens when you stop staring at the orbit and start listening to the residuals instead.
"When the Prototype Is the Point"
"We keep asking when the prototype becomes a product. We have started to wonder if that is the wrong question entirely."
Every prototype we build at Helios Prime eventually generates a conversation about graduation. When does this become a product? When is it ready to ship? When does the experiment end and the thing begin? These are reasonable questions. They are also, we have come to suspect, the wrong questions, or at least questions that carry a hidden assumption about what prototypes are actually for.
Read[ open_questions.board ]
Questions We Don't Have Answers To
These are the questions driving the current work. If you have thoughts, we are genuinely interested.
"At what level of abstraction does automated security reasoning become reliable?"
We're building Vanguard toward an answer, but the target keeps moving as capabilities improve.
"Is threat intelligence fusion fundamentally a compression problem?"
If you treat signals as data and assessments as output, the architecture starts to look like it. SENTINEL-Ω is exploring this.
"What is the minimum viable sensor package for persistent space domain awareness?"
Selene is exploring this, slowly and expensively.
"Does timing analysis generalize across domains, or is it domain-specific by nature?"
Chronos is our attempt to find out. Early signs: complicated.
"Can you engineer continuous assurance without creating a false sense of security?"
Soteria's hardest design problem. More philosophical than technical, which was unexpected.
"How many prototypes does it take before the lab has a point of view?"
We think we're getting there. Check back next quarter.
Board updated as questions are answered, replaced, or determined to be the wrong questions entirely.
[ about.txt ]
The lab is in Colorado Springs. The questions are everywhere.
[ open_channel.md ]
Let's Talk About a Hard Problem
If you're working on something technically interesting in space, intelligence, or cyber, or if one of the experiments sparked a thought, we'd genuinely like to hear it. This is not a sales form.
Response time: 48–72h. We read everything. We reply to the interesting ones. We try to make everything interesting.