Interface Management in the Void: How ISAM Programs Are Engineering Standards from Scratch

When Northrop Grumman’s Mission Extension Vehicle-1 docked with Intelsat 901 in February 2020, the engineering team celebrated something genuinely historic: the first commercial life-extension servicing of a geostationary satellite. What didn’t make the press releases was the years of painstaking interface analysis required to mate a purpose-built servicer with a spacecraft launched in 2001 with no intention of ever being touched again.

That docking maneuver required Northrop’s engineers to reverse-engineer interface documentation for a spacecraft designed under a different regulatory era, operated by a different company, and built to no servicing standard whatsoever. Intelsat 901’s apogee kick motor nozzle became the capture point — not because it was designed for that purpose, but because it was the most mechanically predictable target on the vehicle. That is the defining challenge of in-space servicing, assembly, and manufacturing (ISAM): you are writing interface requirements for a system you don’t fully control, interacting with a client you didn’t design.

The Non-Cooperative Target Problem

Conventional docking — the kind practiced on ISS for decades — relies on cooperative interfaces. Both vehicles are designed to mate. Androgynous Peripheral Attach System (APAS) ports, Common Berthing Mechanisms, NDS docking ports: these are engineered contact points with known tolerances, controlled approach velocities, and defined load paths. When both parties know the handshake, interface requirements are tractable.

Non-cooperative servicing inverts this entirely. The servicer must define interface requirements against a target whose geometry is known only from orbital observation, historical manufacturing data of uncertain accuracy, and whatever the client operator still has in their own documentation archives. Tolerances that a manufacturer may have held to ±0.5mm in a cleanroom are now the input assumptions for a capture mechanism that must work at relative velocities measured in centimeters per second, in thermal environments that cycle over hundreds of degrees, after decades of micrometeorite bombardment.

Northrop’s MEV solved this with a proprietary capture tool designed specifically for the liquid apogee engine bell geometry common across several geostationary bus families. It works — MEV-1 and MEV-2 are operational — but it works because Northrop essentially wrote a requirements specification for a subset of client spacecraft, then built a servicer to match. Scaling that approach to a general servicing market requires something the industry does not yet have: shared interface standards.

Astroscale’s approach to non-cooperative targets differs in philosophy. Their ELSA-M program initially targeted clients pre-equipped with a magnetic capture plate — effectively converting the non-cooperative problem into a cooperative one for future spacecraft. This is intellectually clean, but it acknowledges the limitation: it only works for spacecraft launched after the agreement to install the docking plate. The legacy population — thousands of satellites already on orbit — remains outside that envelope.

Propellant Transfer: The Hardest Interface Problem

If mechanical capture is complex, propellant transfer is harder. Refueling requires not just a physical connection but compatibility across fluid type, pressure regime, contamination standards, material compatibility, and leak detection. In terrestrial fuel systems, decades of industry standardization have produced shared nozzle geometries, hose ratings, and safety interlocks. In orbit, none of this infrastructure exists.

Orbit Fab has approached this by developing its own Rapidly Attachable Fluid Transfer Interface (RAFTI) and actively marketing it as a de facto standard — supplying RAFTI ports to satellite manufacturers and operators willing to spec them in at build time. Several operators have adopted it. As of mid-2026, RAFTI ports have been integrated into programs from multiple satellite bus providers. But RAFTI adoption is still voluntary, and not universal. A satellite launched without a RAFTI port, or with a competitor’s interface, is not serviceable through that ecosystem.

The systems engineering challenge here is not merely mechanical. Propellant transfer requirements span multiple engineering disciplines simultaneously: structural loads during connection and disconnection, contamination control for sensitive optical payloads, thermal management of cryogenic or hypergolic propellants, fault isolation to ensure a leak in the transfer system cannot propagate into the client spacecraft’s own propellant supply. Writing these requirements in isolation — even correctly — misses the interaction effects. A mechanical interface that passes its own load test may introduce vibration that exceeds a client’s propellant management device qualification limits. An electrical ground loop introduced during mating can corrupt telemetry at the worst possible moment.

The requirement dependencies here are not linear. They form a graph, and managing that graph without appropriate tooling is the kind of problem that produces late-discovered integration failures.

Electrical and Data Interface Standards: Underspecified and Underappreciated

The mechanical and propellant interfaces attract most of the attention in ISAM discussions. Electrical and data interfaces are less dramatic but equally consequential.

When a servicer docks with a client spacecraft to extend its life or augment its capability, what electrical relationship exists between the two vehicles? Power sharing, if intended, requires matched bus voltages, defined inrush current limits, and fault isolation to prevent a servicer anomaly from taking down a client’s power system. Data interfaces for telemetry relay, command pass-through, or attitude control handoff require agreed protocols, defined latencies, and authentication structures that most geostationary operators have never had to specify because their spacecraft were designed as self-contained systems.

DARPA’s Robotic Servicing of Geosynchronous Satellites (RSGS) program, now transitioned in part to commercial follow-on through SSL/MDA’s efforts, produced the most detailed technical framework to date for these interfaces. RSGS defined a Spacecraft Interface Standard covering mechanical, electrical, and data connection requirements for GEO servicing scenarios. The document exists. It is not, however, a ratified standard. No standards body has adopted it. No regulatory agency requires adherence to it. Its influence on the commercial market is real but indirect — it informs internal decisions at organizations whose engineers have read it, rather than flowing down through contract requirements.

NASA’s On-orbit Servicing, Assembly, and Manufacturing (OSAM) program — the successor to Restore-L, now under significant budget pressure — has similarly generated substantial internal interface documentation. The challenge is translation from program-specific documentation to transferable, independently enforceable specifications. OSAM’s work on propellant transfer interfaces and robotic tool interfaces represents genuine engineering progress. Whether it becomes a published standard accessible to commercial developers without a NASA contract remains an open question.

The Systems Engineering Challenge: Requirements for Unknown Clients

The deepest engineering problem in ISAM is epistemological. How do you write a complete interface requirements specification for a system that must interact with clients you haven’t identified yet?

Traditional interface requirements assume you know both sides of the interface. ICD authorship is a bilateral exercise — each side defines its outputs, inputs, and limits, and the interface control document captures the agreement between them. ISAM servicers cannot do this. They must define requirements against a statistical population of client spacecraft, not a specific agreed counterpart.

This forces a different mode of requirements engineering. Rather than specifying “the mechanical capture interface shall withstand loads from Client Spacecraft X per ICD-001,” an ISAM servicer must specify performance envelopes: ranges of client mass properties, ranges of client geometry at anticipated capture points, ranges of residual tumble rates within which the capture system must operate. The requirements become probabilistic and population-bounded rather than deterministic and bilaterally negotiated.

This is not a failure of engineering rigor — it is an appropriate response to genuine uncertainty. But it demands that the requirements management infrastructure can represent this kind of conditional, range-bounded requirement and trace it coherently through to verification. A spreadsheet-based RTM is not the right tool for requirements that read “shall capture any client spacecraft with a mass between 1,500 and 7,000 kg, apogee engine nozzle diameter between 240mm and 380mm, and residual angular velocity below 2 deg/sec about any axis.” That requirement has multiple dimensions of variability, each of which drives design decisions in different subsystems — capture tool geometry, approach velocity profile, attitude control authority, structural load paths — and verification must address the full envelope, not a single point.

What the Standards Bodies Are Actually Doing

The Consultative Committee for Space Data Systems (CCSDS) has produced the most mature relevant work, primarily in communications and data protocols. CCSDS standards for proximity link communications and data formats are used across multiple ISAM programs, and they represent genuine interoperability achievements. The mechanical and fluid transfer domains are less mature.

The American Institute of Aeronautics and Astronautics (AIAA) has active working groups on space system interfaces, and ISAM-specific interface considerations have entered several standards revision cycles. Progress is real but slow — consensus standards development timelines are measured in years, while commercial ISAM programs are making irreversible interface choices today.

ISO TC 20/SC 14, which covers space systems and operations, has initiated work relevant to on-orbit servicing. The European Cooperation for Space Standardization (ECSS) has similarly active efforts. The challenge for all these bodies is that their output timelines don’t match commercial development cycles. By the time a ratified standard is published, the programs it would govern have already made their interface decisions.

The practical result is market-led de facto standardization — Orbit Fab’s RAFTI, Northrop’s capture geometry choices, Astroscale’s docking plate specification — rather than consensus-led formal standardization. This is not necessarily wrong. The internet’s application layer standardized through market adoption as much as through formal process. But it does create real fragmentation risk: a client spacecraft with a RAFTI port is not serviceable by a system designed for a different interface, and the cost of that incompatibility falls on the spacecraft operator.

How Modern Tools Are Being Applied

Given the complexity of ISAM interface requirements — multi-domain, conditionally specified, cross-system, with unknown future clients — the engineering teams navigating this space are learning which approaches to requirements management hold and which don’t.

Document-based requirements management, which remains standard practice at many established aerospace primes, struggles with the graph structure of ISAM interface dependencies. When a single interface requirement — say, a structural load limit at the capture point — drives design decisions in mechanisms, GN&C, propulsion, and thermal simultaneously, and when verification of that requirement requires analysis results from all four subsystems, a flat document structure obscures rather than clarifies the dependency web.

Graph-based, model-native approaches handle this better. Tools that represent requirements as nodes in a connected network — with explicit traceability links between requirements, design elements, analysis results, and verification events — allow ISAM engineering teams to query the impact of interface requirement changes across subsystems without manual cross-referencing. Flow Engineering, which takes this graph-native approach and applies it to complex systems programs, has been adopted by several advanced space programs precisely because its architecture reflects how ISAM interface requirements actually behave: as interconnected constraints across disciplinary boundaries, not as pages in a document.

The AI-assisted requirement decomposition capability matters here too. Generating the initial population-bounded requirements for a non-cooperative capture interface is a creative and analytical task; verifying that the full requirement set is internally consistent and covers the intended envelope is where AI analysis can reduce the risk of gaps. This is where requirements management tooling that integrates analysis at the requirement level — rather than treating requirements as text to be stored — provides genuine operational value.

Honest Assessment

ISAM interface management is in the productive chaos of early market formation. The programs that exist — MEV, ELSA-M, RAFTI-equipped servicers, the OSAM technology base — represent real engineering achievements. The interface approaches they’ve developed are functional for their specific applications. What the industry lacks is the cross-program interoperability that would make a general servicing market possible.

The standards work underway at DARPA, NASA, AIAA, CCSDS, and ISO is necessary and real, but it is running behind the commercial development pace. The result will likely be a period of de facto fragmentation followed by consolidation around whichever interface approaches achieve sufficient market penetration to become reference specifications. That process will be faster and less painful for programs whose requirements architecture can cleanly capture interface uncertainty and trace it to verification — and slower and more expensive for those locked into document paradigms that can’t represent conditional, population-bounded interface requirements coherently.

The spacecraft on orbit have no say in how this resolves. The clients that get serviced first will be those whose interface geometry most closely resembles the choices servicer developers made when no standard existed. That is a suboptimal way to develop a market, but it is the reality that ISAM interface engineers are working within today.