Defense organizations run on checklists, regulations and written procedure, often in places with no connectivity at all. Helixor runs inside the enclave, applies that procedure the same way every time, and leaves a record that an inspector can follow later.
These are examples, not a complete list. A decision usually fits when it has written criteria, pulls from several systems, happens often, and someone may later ask why it went the way it did. Pick one to jump to it.
Whether an aircraft or vehicle is ready depends on its maintenance records, open write-ups, inspections coming due, parts on order and deferred items. Maintainers and controllers pull that together from the maintenance information system and their own knowledge. Status boards can lag reality.
Readiness criteria become a pack. Each asset comes back fully mission capable, partially mission capable with the limiting items listed, or not mission capable with the reason. The remedy lists exactly what has to be cleared. Because it's the same pack across units, a status means the same thing everywhere.
{
"asset": "TAIL-0417",
"receipt": "hx_proof_c5e81a3f0b92d47e61a0fb38",
"pack": "wing.readiness_rules v22",
"action": "not_mission_capable",
"rules": ["RDY-INSP-OVERDUE-200HR"],
"input_sha256": "7d2e...c611",
"remedy": ["complete 200-hour inspection"],
"logged_at": "2026-09-28T05:48:20Z"
}A plan has to respect crew duty and rest limits, fuel reserves, maintenance status, weather minimums and airspace windows. Planners check these by hand under time pressure, and when something changes late, the checks have to be redone.
Helixor checks each plan against the written limits and returns approved, approved pending a waiver, or rejected with the limits it breaks. When conditions change, the plan is checked again in microseconds on GPU servers inside the enclave. Constraint solvers (currently in Preview) can suggest the smallest change that fixes a broken plan.
Before a document or dataset is shared with a partner, someone checks its markings, distribution statement, export classification and what the recipient is cleared to receive. It's slow, and mistakes in either direction are costly.
Helixor checks the item against the release rules and returns releasable, releasable after redaction, refer to the disclosure officer, or not releasable. When redaction would make it releasable, the remedy produces the redacted version, and only that version moves on.
Maintenance planners juggle inspection due dates, hangar space, maintainer qualifications, parts on hand and the flying schedule. Pulling an aircraft in early costs availability; pulling it in late risks grounding. The plan usually lives on a whiteboard and in a planner's head.
Due dates, hangar capacity, qualifications and parts rules go into the pack, and the goal is the most mission capable aircraft on the days the schedule needs them. The solver slots each inspection and work package, and repairs the plan when a part is late or an aircraft breaks. It runs on GPU servers inside the enclave. The pack holds the hard rules and the goal. The solver searches for the best plan that satisfies every hard rule, working from the same typed state the decision core uses. If no plan can satisfy them all, it tells you so instead of quietly breaking one. The solvers are built for GPUs, and that's where large plans solve fastest. Solvers are in Preview today.
| Decision | What Helixor decides |
|---|---|
| Supply requisition priority | Rank and fill requisitions by priority, readiness impact and stock on hand. |
| Training and qualification currency | Check that each person on a roster is current for the task. |
| Workload | Pattern |
|---|---|
| Enclaves and forward sites | Air-gapped. Packs and a license cross once, licenses verify offline, nothing calls out |
| Systems of record | Loopback sidecar next to the maintenance or planning system |
Helixor is for procedural and logistics decisions like the ones above. It doesn't make targeting or use-of-force decisions. We also don't claim any accreditation on this page. Authorization to operate belongs to your program's own process, and the receipts and pack versions give assessors something concrete to review.
Go deeper on helixor.dev: Deployment patterns ↗ • Core concepts ↗ • Receipts ↗
Bring a written policy and a handful of past cases. We'll turn it into a pack and run it next to your current process so you can compare.