Cislunar is a different game. The two-body assumption that holds for LEO and GEO operations breaks down the moment you cross the Hill sphere — Sun and Moon gravity, near-rectilinear halo orbits, ballistic-lunar transfers, all of it. Operators planning lunar relay missions, NRHO insertions, and L1/L2 staging have been working around our two-body solver with handwritten patches. We've heard them, and we shipped.
What changed
Native multi-body dynamics. The solver now treats Earth, Moon, and Sun gravity as first-class inputs. JPL DE440 ephemeris by default; configurable per mission. Transfers from GEO to NRHO, EML2 staging, and weak-stability boundary insertions are now planned in TACK directly — no external preprocessing.
New constraint engine. Mission constraints have been promoted from solver parameters to first-class objects. Each constraint has a name, an evaluator, a severity, and an audit trail. The same constraint engine drives both planning and validation, which means you can author a power-envelope check once and have it enforced at both ends of the pipeline.
Redesigned approval workflow. The approval flow has been rebuilt around a UI operators actually want to use. Plans can be staged, peer-reviewed inline, and approved with hardware-key signatures in a single tab. The old multi-page approval flow is retired.
What it changes for you
- Cislunar planning works. You no longer have to leave TACK to plan a lunar-side transfer. Three pilot customers ran their first NRHO insertion plans in the closed beta — average solver runtime: 84 seconds.
- Constraint authoring is git-native. Constraints are YAML, reviewed in pull request, evaluated identically in planning and validation. We've migrated every default constraint to the new schema; legacy constraints still work for one major version.
- The approval surface is faster. 31% fewer clicks to ship a typical plan based on the beta cohort. Hardware-key signing is now inline rather than redirected.
Under the hood
The solver is a fresh implementation in Rust, replacing the original Julia codebase. The same multi-objective formulation (ΔV, time, propellant, composite), but with proper support for time-varying gravity, eclipse calculation against the Moon and Earth simultaneously, and a redesigned trust-region step that converges faster on multi-body problems.
// New: native cislunar transfer call
let plan = client.plans().create(
asset: "TUG-04",
objective: PlanObjective::Transfer {
target: Orbit::nrho_l2_southern(),
deadline: "2026-09-15T00:00:00Z".parse()?,
},
dynamics: Dynamics::FourBody {
primaries: vec![Body::Earth, Body::Moon, Body::Sun],
ephemeris: Ephemeris::Jpl(DE440),
},
optimize_for: Objective::Propellant,
).await?;Rollout
TACK 2.0 is live in all production regions as of 09:00 UTC today. The legacy two-body solver remains available behind a feature flag for one full major version (until TACK 3.0 ships, planned for Q4 2026). Customer-facing docs are updated. Migration guide for self-authored constraints is in the docs portal under Migrations → 1.x to 2.0.
What's next
The cooperative-autonomy primitives we've been previewing in the customer council are next in line — coordinated multi-asset planning for swarm and tug-and-payload missions. The first internal preview goes to council members in two weeks. If you want in on that early loop, ping your TAM or reach out.