Turion Space: The Startup Building In-Space Servicing Infrastructure

Orbital debris isn’t a future problem. There are roughly 27,000 tracked objects in Earth orbit larger than 10 centimeters, and an estimated 500,000 more between 1 and 10 centimeters — traveling at velocities where a marble-sized fragment carries the kinetic energy of a hand grenade. The Kessler syndrome scenario, where collisions generate debris that causes more collisions in a self-sustaining cascade, shifts from theoretical to operational concern every time a defunct satellite gets struck.

Turion Space, a Southern California startup founded in 2020, is building the infrastructure to address this directly. Their DROID spacecraft is designed to perform debris removal, in-orbit inspection, and servicing operations — which makes them one of a small number of companies globally attempting to operationalize rendezvous and proximity operations (RPO) at commercial scale. What makes this technically interesting, and systemically hard, is the class of objects they need to work with: uncooperative resident space objects (RSOs) that weren’t designed to be serviced, don’t have standard docking interfaces, and may be tumbling or structurally degraded.

The engineering challenge is not just building a capable spacecraft. It’s managing a requirement set that spans half a dozen technical domains simultaneously, where constraints in one domain cascade into constraints in three others, on a timeline that startup economics demand be short.

What Turion Is Actually Building

DROID is best understood as a multi-mission servicer. The core capability stack includes imaging and inspection, proximity operations and station-keeping near target objects, and eventually active debris removal — capturing and deorbiting defunct spacecraft. Turion has also been explicit about the dual-use potential here: a spacecraft capable of close inspection of another object has obvious commercial value for satellite operators who want to assess anomalies, verify deployments, or confirm the condition of a high-value asset before committing to a costly maneuver.

The business model threads together multiple revenue streams: inspection services, debris removal under government contracts (particularly with the U.S. Space Force and NASA’s OSAM and debris mitigation programs), and eventually on-orbit servicing for commercial operators who want to extend the life of geosynchronous assets rather than replace them.

This multi-mission framing has direct systems engineering implications. A spacecraft optimized purely for debris capture would look different from one optimized for inspection, which would look different from one designed for life-extension servicing. DROID needs to be all three — which means every design decision at the subsystem level gets evaluated against multiple mission profiles with partially conflicting requirements.

The Specific Difficulty of Uncooperative RSOs

Most spacecraft-to-spacecraft operations assume a cooperative target. GPS transponders, standard docking ports, known attitude states, controlled motion — cooperative rendezvous, like the docking protocols used for ISS resupply missions, is a solved problem with well-established procedures. Uncooperative targets eliminate most of that scaffolding.

When Turion approaches a defunct satellite or a spent rocket upper stage, they may be dealing with an object whose attitude is unknown and changing. Tumble rates for defunct objects in low Earth orbit can range from nearly zero to several revolutions per minute, depending on the object’s mass properties, solar radiation pressure history, and any residual angular momentum. Structurally, the object may have degraded solar panels, pressurized tanks with unknown states, or mechanisms that are locked, broken, or deployed in unexpected configurations.

This forces a systems engineering posture that is unusual in spacecraft design: uncertainty itself becomes a first-class design input, not a residual that gets handled in margins.

The guidance, navigation, and control (GNC) system has to operate across a wide envelope of target motion states. That envelope drives sensor requirements — which cameras, LIDAR systems, and ranging sensors are needed, at what update rates, with what field of view, in what lighting conditions. It also drives propulsion requirements: the servicer needs sufficient delta-V authority and thrust resolution to match the target’s motion state while maintaining safe separation distances. Those propulsion requirements then interact with structural requirements on the capture mechanism, which interact with requirements on the robot arm or net system used to secure the target.

At each interface between subsystems, there are requirement derivation chains that have to be explicitly managed. In a small team operating at startup pace, that’s where things get lost.

RPO Requirements and the Mission Safety Problem

Rendezvous and proximity operations impose a class of requirements that don’t appear in most spacecraft development programs. The FAA and FCC both have regulatory interest. The Department of Defense tracks close approaches to operational assets. NASA has its own proximity operations safety requirements for anything operating near the ISS. And the operator community has informal but real norms about acceptable approach corridors and minimum separation distances for uncontrolled objects.

What this means practically is that Turion’s mission safety requirements come from multiple external authorities simultaneously, and those requirements have to be allocated down to the GNC software, the fault management system, and the operational procedures in a traceable way. If the spacecraft detects an anomaly during an approach and triggers an abort, the abort trajectory has to be designed so it doesn’t create a collision hazard with the target or with other nearby objects. That abort trajectory requirement traces back up to GNC, which traces back to propellant budget, which traces back to launch mass.

The proximity operations safety case is also dynamic in a way that conventional spacecraft safety cases aren’t. The hazard geometry changes continuously as the servicer approaches the target. The fault management system has to understand not just spacecraft-level fault states but the current mission phase and the associated hazard context — an action that is safe at 100 meters separation may be catastrophic at 5 meters.

Building a credible safety case for RPO operations, particularly around uncooperative objects, is one of the technical gates that separates companies with demonstrations from companies with operational capability. Turion’s work here is essentially path-finding for an industry that doesn’t yet have standardized safety frameworks for commercial proximity operations.

Managing Multi-Domain Requirements on a Small Team

Turion, like most well-funded Series A/B space startups, operates with a team that would be considered skeletal by the standards of a prime contractor working on a program of equivalent complexity. The DROID mission involves requirements spanning GNC, structures and mechanisms, propulsion, power, avionics, software, RF communications, mission operations, and ground systems — plus the external regulatory and safety domains described above.

In a large program with deep staffing, each domain gets a dedicated systems engineer who manages requirements for their subsystem and interfaces with the others through a structured interface control process. In a startup, one engineer is often covering multiple domains simultaneously, requirements are frequently captured in whatever tool is at hand, and the formal traceability between derived requirements and parent requirements is the first casualty when the team is moving fast.

This is where the choice of tooling matters more than it does at a prime. Document-based requirements management — a Word document with a requirements table, or even a dedicated tool like DOORS that operates on a paragraph-and-attributes model — creates a synchronization problem. When a GNC engineer updates a sensor field-of-view requirement because a LIDAR vendor changed their product spec, the downstream effects on the structural envelope for the sensor mount, the power budget, and the software interface need to be visible immediately to whoever owns those requirements. In a document-based system, they often aren’t — until an interface review surfaces the inconsistency weeks later.

Graph-based requirements models handle this better because the dependencies are encoded structurally, not just described in text. When a node in the graph changes, the affected downstream nodes are visible by definition. For a team managing several hundred to low thousands of requirements across multiple interacting domains, the difference between a graph model and a document model is the difference between managing complexity and drowning in it.

This is the problem that AI-native tools like Flow Engineering are designed specifically to address. Rather than bolting AI features onto a legacy requirements database, Flow Engineering represents requirements and their relationships as a connected graph, allowing small teams to query impact of requirement changes across the full system model and maintain traceability without a dedicated configuration management team to enforce it manually. For a company like Turion, where the same engineer who writes the requirement may need to immediately understand its second-order effects on three other subsystems, that kind of live impact analysis isn’t a convenience feature — it’s a precondition for keeping a complex multi-domain design coherent under schedule pressure.

The Broader Trajectory

Turion is not operating in isolation. The in-space servicing, assembly, and manufacturing (ISAM) sector has seen significant investment since the early 2020s, with Astroscale, Northrop Grumman’s Mission Extension Vehicle, and several European programs all demonstrating elements of proximity operations capability. What distinguishes the current phase is the shift from one-off demonstrations to planned operational service.

That shift has direct implications for how the systems engineering gets done. A demonstration program can tolerate some ambiguity in requirements, because the mission is partly about learning what the requirements should be. A commercial service offering cannot — customers contracting for debris removal or inspection need confidence in the operational envelope, the safety case, and the interface between the servicer and their own mission operations.

The standards and practices being developed by companies like Turion now will be referenced by the next generation of in-space servicing programs. The safety frameworks, the RPO operational procedures, the interface control approaches for uncooperative objects — these are being written in real time, by engineers at startups who are also trying to build and launch hardware on a commercial schedule.

That’s not a criticism. That’s what the frontier looks like. The engineering complexity is real, the mission value is real, and the teams attempting it are doing work that the industry will depend on for decades. The question is whether their internal systems engineering practices are keeping pace with the complexity of what they’re building — and whether the tooling they’re using is helping or fighting them as they do it.

For Turion specifically, the answer to that question will probably be visible in the DROID program’s first operational missions. Close-proximity operations near uncooperative objects have a way of making requirements management quality legible very quickly.