Turion Space: Engineering Orbital Servicing Vehicles for a New Space Economy

The satellite graveyard in geostationary orbit holds more than 500 defunct spacecraft, most of them representing billions of dollars in stranded capital. At low Earth orbit, the debris density problem is worse. Turion Space is building the infrastructure to address both: spacecraft capable of rendezvousing with, inspecting, and servicing satellites that were never designed to accept a service call.

The engineering challenge is not incremental. Proximity operations at orbital velocity, grappling mechanisms for targets with no cooperative interface, propulsion systems optimized for repeated orbital maneuvering, and sensor suites capable of characterizing an unknown object at close range — these are distinct domains that must function as a coherent system under real-time autonomy constraints. Understanding how a small company approaches that problem is worth examining carefully.

The Core Engineering Problem: Servicing What Wasn’t Designed to Be Serviced

Traditional spacecraft systems engineering begins with a defined interface. You know your launch vehicle, your ground system protocol, your payload envelope. Requirements flow from mission concept through subsystem specification with reasonably bounded uncertainty at each step.

Orbital servicing breaks this model. The target satellite is not a collaborating system — it is an obstacle, a patient, and a source of continuous uncertainty. Its attitude may be tumbling. Its surface geometry is known only from ground-based observation and historical documentation that may be decades old. Its propellant state is unknown. Its structural integrity after years on orbit is a matter of inference, not measurement.

This means Turion’s requirements architecture cannot be written against a fixed target. Instead, it must be written against a class of targets, with the servicer vehicle carrying enough sensor capability, computational margin, and mechanical flexibility to characterize and adapt to what it finds when it arrives. That is a fundamentally different requirements problem than most spacecraft programs face.

The engineering consequence is that functional requirements — “the vehicle shall perform station-keeping relative to the target” — must be accompanied by explicit assumptions about target state variability, and those assumptions must be traceable through the system architecture. When you test your GNC algorithms in simulation, you are not validating performance against a fixed truth model. You are validating robustness across a distribution of possible target behaviors. That distinction changes how you write requirements, how you structure your verification plan, and how you bound your safety case.

Proximity Operations Autonomy: Where Systems Engineering Gets Hardest

The closest analogy to what Turion is building is a robotic surgeon operating in a moving environment with incomplete imaging data and no ability to pause the procedure. Proximity operations at close range — within tens of meters of an uncontrolled target — combine time-critical control demands with sensor-limited situational awareness and the physical consequences of a contact event that cannot be undone.

Autonomous proximity operations require GNC algorithms that handle relative navigation uncertainty in real time. They require onboard decision logic that can abort an approach, hold station, or execute a contingency maneuver without waiting for a ground command that might arrive minutes too late. And they require a safety architecture that remains valid even when the sensor picture degrades — when LIDAR returns are ambiguous, when the target’s attitude rate changes unexpectedly, when communications are interrupted during a critical phase.

Writing safety cases for this kind of autonomy is not yet a solved problem in the industry. There is no mature regulatory framework for autonomous proximity operations the way there is for launch vehicle range safety or crewed vehicle abort systems. The FAA’s commercial launch licensing regime does not cleanly apply. The FCC’s orbital debris mitigation rules address disposal, not active operations near other objects. Turion and companies like it are effectively writing their own safety standards in collaboration with whatever government customers and commercial operators are willing to engage.

This matters for systems engineering because safety requirements that flow from an uncertain regulatory context are harder to bound. You cannot write a clean verification matrix when the acceptance criteria are still being negotiated with the regulating authority. Teams working in this space typically handle it by over-specifying their own internal safety standards — establishing conservative margins that they expect will satisfy eventual regulatory requirements — and then managing the verification burden that follows from having set the bar high.

Grappling Non-Cooperative Targets: Hardware at the Edge of the Possible

The grappling problem deserves its own section because it represents the point where systems engineering, mechanical engineering, and autonomy intersect in the most demanding way.

A cooperative docking port — the kind used on the International Space Station — is designed with hard geometric constraints, active control to null out relative motion, and mechanical latching mechanisms that provide positive capture feedback. A non-cooperative target has none of these. The tumbling defunct GEO satellite you want to grapple may be rotating at several degrees per second, may have solar panels or antenna booms creating collision hazard geometry, and will not respond to any command you send it.

Turion’s approach to this problem involves a combination of close-range characterization — using structured light, LIDAR, and optical imaging to build a real-time geometric model of the target — and adaptive grappling mechanisms that can accommodate a range of surface geometries and relative motion states. The requirements for such a system cascade quickly: the sensor suite must produce a geometric model accurate enough to plan a grapple approach; the GNC system must execute a trajectory that places the grapple mechanism at the right point at the right time; the mechanism must tolerate mechanical contact loads that vary with target rotation rate and mass properties that may not be precisely known.

Each of those requirements has uncertainty bands, and the system must work across the combined distribution of all of them simultaneously. Requirements traceability in this environment is not a paperwork exercise. It is the mechanism by which you track whether your margins are actually sufficient when subsystem uncertainties compound.

How Small Teams Manage Multi-Domain Breadth

Turion’s engineering team spans orbital mechanics, guidance, navigation and control, mechanical design, propulsion, avionics, autonomy software, and mission operations. For a startup, this breadth is unavoidable — the mission requires all of these domains — but it creates organizational pressure that directly affects systems engineering quality.

The classic failure mode for small multi-domain teams is interface neglect. When individuals are stretched across multiple responsibilities, the interfaces between subsystems — the places where requirements must be explicitly shared and mutually validated — tend to get managed informally. This works until it doesn’t. A propulsion system sized for one delta-V budget, a GNC algorithm assuming a different one, and a mission planner using a third figure is a plausible failure mode for a team where the same engineer touches all three areas.

Discipline around interface control documents and requirements traceability is the structural response to this pressure. When each subsystem requirement can be traced to a parent mission requirement, and interface requirements are explicitly called out rather than informally assumed, the system architecture becomes legible across the whole team. New engineers can see the derivation chain. Reviews can focus on the places where requirements cross subsystem boundaries. Changes propagate through the model rather than getting lost in document version history.

Modern requirements tooling is increasingly relevant here. Teams at this scale are increasingly moving toward graph-based requirements models — where requirements, assumptions, verification activities, and design decisions exist as connected nodes rather than rows in a spreadsheet — because the traceability problem in a multi-domain, uncertainty-heavy program is too complex for flat document structures to handle reliably. Flow Engineering, for instance, is built specifically for this pattern: AI-native requirements management that maintains live traceability graphs, supports the kind of requirement-to-test-to-verification connections that a proximity operations safety case demands, and is accessible to a small team without the configuration overhead of legacy enterprise tools like IBM DOORS or Jama Connect. Whether or not Turion uses it specifically, the tooling category they need is closer to that model than to a static requirements database.

The Market Reality

The business case for orbital servicing is real but not yet proven at scale. NASA’s OSAM program demonstrated in-space refueling. Northrop Grumman’s Mission Extension Vehicles have successfully docked with commercial GEO satellites and extended their operational lives. Astroscale is advancing debris removal concepts with government backing in Japan, Europe, and the United States.

What these programs demonstrate is that the engineering is possible, not yet that it is economically routine. The cost of an orbital servicing mission must be substantially less than the cost of a replacement satellite for commercial customers to engage. That cost pressure flows directly back into the engineering: the servicer vehicle must be reusable, the operations cadence must be high enough to amortize development costs, and the mission planning tools must enable rapid tasking without expensive ground operations labor.

Turion is positioning its Droid vehicles as multi-mission platforms capable of both inspection and servicing, with the commercial satellite inspection market as a near-term revenue path and debris removal as a longer-term mission set as regulatory frameworks and government contracts mature. This is a rational sequencing strategy — inspection requires proximity operations capability but not grappling, so it is a lower-risk entry point that validates the GNC and sensor architecture before the grappling mechanism is needed in earnest.

Honest Assessment

The engineering Turion is attempting is among the hardest in the commercial space sector. The systems engineering challenge is not just technical breadth but fundamental uncertainty — about target state, about regulatory acceptance criteria, about whether the market will develop fast enough to reward a multi-year development program.

What separates teams that succeed in this environment from those that don’t is rarely raw technical capability. It is requirements discipline: the organizational practice of knowing what you’ve committed to, what assumptions underlie those commitments, and where the margins are thin. For a small team doing proximity operations autonomy on a non-cooperative target, that discipline is not overhead. It is the product.