Scenario and run manifest
Scenario identifier, target selection, swarm configuration, trial number, timestamps, software version, and run status.
Glossary
Terms used in the protocol.
- Preservation orbit
- A stable holding orbit used to keep captured orbital material controlled, traceable, and available for future handling rather than immediately deorbiting or destroying it.
- Orbital debris
- A human-made object or fragment no longer serving a useful function in orbit, including derelict spacecraft, rocket bodies, and fragments.
- Conjunction
- A predicted close approach between two tracked or modeled orbital objects that must be evaluated against separation and collision thresholds; it is not itself a collision or a live alert.
- Proof artifact
- A recorded input, trace, log, or result from a modeled run that makes a protocol claim inspectable and reproducible; it is not evidence of flight or live operations.
01 / Objective
Prove the preservation loop, not a disposal shortcut.
The protocol tests whether an autonomous five-drone OLE v2.0 swarm can identify a target in the 1–10 kg class, coordinate safely around it, capture it, relocate it to a stable holding orbit, and preserve a traceable inventory record rather than destroy the material.
Success condition
A modeled run is useful only when safety and preservation are evaluated together: the swarm must control relative motion, respect collision and separation constraints, complete the disposition maneuver within its delta-v budget, and leave an auditable record of what was captured and where it was placed.
02 / Validation sequence
Run the same question through increasingly difficult conditions.
The sequence starts with the existing seeded catalog and adds controlled stressors so each claim can be inspected against a known baseline. The public debris-field simulation and the open-source simulation source are reference artifacts for modeled exploration, not flight feeds.
-
Define the orbital scenario and target set
Select representative 1–10 kg targets from the seeded catalog, set the orbital shell, initial formation geometry, mission clock, and environmental assumptions. Record every input before a run begins.
-
Establish a collision-risk baseline
Run the scenario without capture or relocation actions to establish the relative-motion, conjunction, and near-miss baseline against which swarm interventions can be compared.
-
Exercise navigation and target identification
Propagate relative states, exercise decentralized relative navigation, and test whether the swarm can classify and maintain a target track while staying inside the prescribed approach corridor.
-
Inject uncertainty and member loss
Introduce communication latency, sensor uncertainty, and one or more unavailable swarm members. Inspect whether the remaining drones coordinate without a single point of control and enter a fail-safe state when limits are exceeded.
-
Model capture and relocation
Model the capture interface, separation clearance, transfer trajectory, and delta-v consumption. Check that the target remains controlled and that the proposed holding orbit is stable within the stated maneuver and propellant constraints.
-
Repeat trials and compare criteria
Repeat across target states, uncertainty levels, latency profiles, and member-loss cases. Compare each outcome to the safety, coordination, capture, relocation, and preservation criteria, preserving both passes and failures in the run record.
03 / Evidence outputs
Make every modeled claim inspectable.
The protocol is intended to produce the following evidence formats. These are modeled outputs and reporting structures—not unrun measurements or claims that a live mission has generated them.
Deterministic inputs and assumptions
Seed values, initial states, noise and latency models, environmental simplifications, thresholds, and declared limits.
Target state and orbital-element traces
Modeled position, velocity, attitude or state estimates, and orbital-element series for the target and swarm.
Formation error and latency series
Relative-position error, approach corridor margins, message delay, stale-state intervals, and coordination responses.
Collision, near-miss, and fail-safe log
Threshold crossings, avoidance actions, member-loss responses, abort conditions, and recovery or safe-hold events.
Delta-v and propellant budget
Planned and modeled maneuver cost, remaining margin, separation reserve, and any budget exceedance.
Before/after orbit disposition
Initial target orbit, modeled holding-orbit state, transfer summary, separation geometry, and stability checks.
Inventory record and pass/fail summary
Traceable target identity, custody and disposition fields, plus a criterion-by-criterion summary of modeled results.
04 / Evidence checklist
Set the review gate before interpreting a result.
Required evidence is the review gate for each claim. Illustrative examples are non-authoritative placeholders that show the expected shape of a record; they are not live mission evidence.
-
Orbital-state assumptions
Required evidenceReference frame and epoch, propagation model, environmental assumptions, and uncertainty bounds used for the state.
Illustrative exampleNon-authoritative placeholder: a modeled state in J2000 at a declared epoch with a stated propagator, drag assumption, and position/velocity bounds.
-
Observation inputs
Required evidenceObservation source, timestamp and coverage, units or frame, and sensor, noise, and latency assumptions.
Illustrative exampleNon-authoritative placeholder: a modeled observation window with a named source, UTC timestamps, declared units, and injected sensor noise and latency.
-
Maneuver records
Required evidencePlanned and realized state changes, delta-v and burn timing, separation, budget, and abort details.
Illustrative exampleNon-authoritative placeholder: a modeled burn plan compared with realized state change, including separation margin, delta-v reserve, and any abort trigger.
-
Pass/fail review criteria
Required evidenceThreshold, observed result, criterion status, reviewer, and run or artifact reference for each decision.
Illustrative exampleNon-authoritative placeholder: a modeled threshold comparison marked pass or fail with a reviewer name and link to the run artifact.
05 / Evidence boundary
What this proves / what it does not.
Read the status label literally.
This page and its linked artifacts describe software simulations and seeded or modeled data only. They are not telemetry from an operating spacecraft, a flight qualification, a regulatory approval, a live collision alert, or a guarantee of mission performance.
Simulated validation is one stage in an evidence chain. Hardware-in-the-loop testing, ground testing, independent safety review, regulatory work, and an on-orbit demonstration each require separate test plans and separate evidence. None of those later-stage results should be inferred from this protocol.