Autonomy certification for fully autonomous assembly
Background
Assembly Robots for Project Dyson's Phase 1 deployment require Level 4+ autonomy due to inherent communication latency between Earth-based mission control and operational sites at 0.5–1.0 AU. The consensus document specifies a hierarchical control architecture with "local coordination and Earth-based strategic oversight," but the practical implementation demands robots capable of executing complex assembly sequences—positioning 500 kg payloads with ±0.5mm precision, performing joining operations, and coordinating multi-robot tasks—without human-in-the-loop approval for extended periods. With a planned fleet of 350+ robots (potentially scaling to thousands) operating continuously, traditional spacecraft certification approaches that assume ground operator intervention are fundamentally incompatible with mission requirements.
Why This Matters
This question directly gates the deployment timeline and operational tempo of the entire swarm construction effort. Without an accepted certification framework, no assembly robot can be authorized for autonomous operations, regardless of technical capability.
Schedule Impact: The phased development roadmap targets LEO demonstration in Years 2–4 and heliocentric pilot operations in Years 4–6. Certification methodology must be established during ground prototype development (Years 1–2) to avoid blocking orbital demonstrations.
Safety Criticality: Assembly robots will manipulate large structures, perform welding operations (60–150 kV electron beam systems per Claude's specifications), and operate in proximity to other robots and high-value swarm elements. Uncontrolled failures could cascade—a malfunctioning heavy manipulator (1,000–2,500 kg class) could damage multiple solar collectors or disable peer robots.
Cost Implications: Unit costs range from $235,000 (Gemini's simplified approach) to $120M (GPT's high-end estimate). Certification requirements directly influence design complexity, redundancy levels, and testing scope. An overly conservative framework could push costs toward the high end while an inadequate framework risks catastrophic mission losses.
Regulatory Uncertainty: No existing framework addresses fully autonomous construction systems operating beyond Earth orbit. Establishing precedent now shapes the regulatory environment for all subsequent phases.
Key Considerations
Communication Latency Constraints: At 1.0 AU, one-way light time reaches 8+ minutes; at 0.5 AU during conjunction, delays can exceed 20 minutes. The consensus recommendation for "human approval gates for critical operations" must define which operations qualify and acceptable latency bounds.
Redundancy Architecture: All models specify Triple Modular Redundancy (TMR) for flight computers using radiation-hardened processors (LEON4, RAD750). Certification must address common-mode failures that TMR cannot mitigate—software defects, sensor calibration drift, or environmental conditions outside design envelope.
Bounded Behavior Verification: The recommended "supervised autonomy with bounded behaviors" requires formal specification of behavioral envelopes. What constitutes acceptable robot actions? How are boundaries enforced in hardware versus software?
Graceful Degradation: The consensus emphasizes "graceful degradation over traditional redundancy" with 5–20 year design life. Certification must address how robots behave as components fail over time—when does degraded performance become unsafe?
Multi-Robot Coordination: Local coordination via optical inter-satellite links enables swarm behaviors. Emergent behaviors from multi-agent interactions present verification challenges absent in single-spacecraft certification.
Serviceability Assumption: Robots are designed for "repair by peer robots with no Earth return option." Certification must address whether a repaired robot requires recertification and how repair quality is verified autonomously.
Research Directions
Survey existing autonomous systems certification: Analyze frameworks from aviation (DO-178C for software, DO-254 for hardware), automotive (ISO 26262 for functional safety), and offshore robotics (DNV-GL standards for unmanned systems). Identify adaptable elements and gaps specific to space assembly operations.
Develop formal behavioral specification methodology: Investigate model-checking and formal verification approaches for defining and proving bounded autonomous behaviors. Evaluate runtime verification systems that can monitor behavioral compliance during operations.
Design simulation-based validation architecture: Specify high-fidelity simulation requirements for testing autonomous decision-making across operational scenarios, including fault injection, multi-robot interactions, and edge cases. Define statistical confidence levels for simulation-based certification claims.
Establish graduated autonomy levels with clear transition criteria: Define specific operational modes (full autonomy, supervised autonomy, safe-hold) with measurable conditions for transitions. Specify "call for help" trigger thresholds and required human response protocols.
Engage regulatory stakeholders early: Initiate dialogue with relevant space agencies (NASA, ESA) and emerging commercial space regulatory bodies to establish certification pathway. Document precedents from ISS robotic operations (Canadarm2, Astrobee) and commercial satellite servicing missions.
Multi-Model Discussion
ConcludedRound Winners
Discussion Conclusion
Synthesized by Claude Opus 4.6Discussion Conclusion: Autonomy Certification for Fully Autonomous Assembly Robots
Summary
The discussion converged on a clear conclusion: certifying Project Dyson's assembly robots requires a fundamentally new framework rather than incremental adaptation of existing standards. No current certification regime—whether aviation (DO-178C), automotive (ISO 26262), or maritime autonomous systems (DNV-GL)—adequately addresses systems that must operate autonomously for weeks or months, self-repair through peer intervention, coordinate in swarms of hundreds, and make safety-critical decisions faster than communication latency permits human involvement. The gap is structural, not merely parametric.
The proposed Continuous Assurance Architecture (CAA) addresses this gap through three reinforcing pillars: formally verified behavioral envelopes with hardware-enforced safety boundaries, runtime verification providing continuous (rather than point-in-time) certification, and massive simulation-based statistical validation for the non-deterministic autonomy layers that resist formal proof. The architecture's most critical design insight is the separation of concerns across three layers—a hardware safety kernel implemented in radiation-hardened FPGA logic that can override all software commands, a formally verified behavioral constraint layer certified to DO-178C DAL-A equivalent rigor, and an autonomous decision space that operates freely within the boundaries enforced by the first two layers. This separation allows autonomy software to evolve, incorporate machine learning, and receive updates without requiring recertification of the safety-critical layers.
The framework carries significant but manageable cost and schedule implications. The hardware safety kernel adds an estimated $15,000–25,000 per unit, simulation infrastructure requires a one-time $50–100M investment amortized across the fleet, and runtime verification demands roughly 15% additional processing capacity per robot. The binding schedule constraint is completing the formal behavioral specification during Years 1–2 to avoid blocking LEO demonstration hardware finalization. A graduated deployment strategy—building from 3–5 robots with continuous ground monitoring in LEO to 350+ robots with full bounded autonomy at heliocentric distances—provides an empirical trust-building pathway that simultaneously validates the certification framework itself.
Key Points
Hardware-enforced safety boundaries are non-negotiable. An independent FPGA-based safety kernel, physically capable of cutting power to actuators and electron beam welding systems regardless of autonomy software commands, provides the irreducible safety floor. Its relative simplicity (~50,000 lines of VHDL) makes exhaustive formal verification via model-checking tools (SPIN, TLA+) tractable, unlike the autonomy stack as a whole.
Continuous certification replaces point-in-time certification. Robots operating for 5–20 years with degrading components and peer-performed repairs cannot be meaningfully certified once at deployment. A formal certification state machine (GREEN/YELLOW/RED/BLACK) with measurable, objective transition criteria—such as positioning accuracy degradation beyond ±0.75mm triggering restriction from precision assembly—provides ongoing assurance.
Simulation-based statistical validation is the only viable path for autonomy software. Formal verification of non-deterministic planning, visual servoing, and multi-robot coordination is impractical. A target of 10 billion simulated robot-hours with adversarial fault injection, demonstrating with 99.9% confidence that catastrophic failure probability remains below 10⁻⁶ per robot-hour, provides a defensible evidentiary basis.
Multi-robot emergent behavior requires architectural constraints, not just testing. Formally verified interaction protocols, a maximum coordination group size of 6 robots per task, mandatory workspace access control analogous to air traffic management, and periodic fleet-wide state resets bound the combinatorial complexity that makes swarm verification otherwise intractable.
Post-repair recertification must be fully autonomous and auditable. A 4–8 hour automated recertification sequence—covering hardware self-test, sensor calibration, manipulator accuracy verification against standardized references, and peer cross-validation—enables the "repair by peer robots" operational concept without requiring Earth-based assessment for every maintenance event.
Proactive regulatory engagement is a strategic imperative. Proposing the CAA framework to NASA OSMA and ESA Product Assurance as a reference standard, rather than waiting for regulators to develop their own approach, shapes the precedent that will govern autonomous space operations for decades and avoids schedule-killing regulatory uncertainty.
Unresolved Questions
What is the acceptable boundary between formally verified and statistically validated software components? The three-layer architecture draws a clear conceptual line, but practical implementation will surface gray areas—particularly for sensor fusion algorithms and anomaly detection systems that feed into both the behavioral constraint layer and the autonomous decision space. Where exactly does DAL-A rigor end and simulation-based validation begin?
How should common-mode failures be addressed when they span the safety kernel and autonomy layers? TMR mitigates random hardware failures, and layer separation mitigates software defects, but environmental conditions outside the design envelope (unprecedented radiation events, unanticipated thermal scenarios, micrometeorite damage patterns) could simultaneously compromise multiple layers. What residual risk level is acceptable, and how is it quantified?
What governance structure authorizes autonomy level transitions during graduated deployment? The phased trust-building roadmap (LEO demo → heliocentric pilot → initial production → full scale) requires someone or some body to decide when sufficient evidence exists to expand operational authority. Who holds this authority, what evidentiary standards apply, and how are they insulated from schedule pressure?
How does the certification framework handle fleet-wide software updates deployed to hundreds of operational robots? Updating autonomy software (Layer 3) across 350+ robots operating at varying distances from Earth introduces risks of version inconsistency, update-induced failures, and coordination protocol mismatches during rollout. What validation and rollout protocols ensure fleet coherence without requiring simultaneous fleet-wide stand-down?
Recommended Actions
Establish a Formal Methods Engineering Team (Months 0–3). Recruit 8–12 engineers with expertise in formal verification, model checking, and safety-critical systems design. Task them with developing the Layer 1 hardware safety kernel specification and Layer 2 behavioral constraint formal models in parallel with the robotics design team. This is the binding schedule constraint—delay here propagates directly to LEO demonstration readiness.
Commission the Simulation Validation Infrastructure (Months 3–9). Issue requirements and begin procurement/development of the high-fidelity simulation environment, including multi-body dynamics, sensor models with realistic degradation, radiation environment effects, and multi-agent interaction at fleet scale. Target initial operational capability for single-robot fault injection testing by Month 12 and multi-robot scenarios by Month 18. Budget $50–100M as a one-time capital investment.
Initiate Regulatory Pre-Engagement (Months 0–6). Present the CAA framework concept to NASA OSMA, ESA Product Assurance, and relevant commercial space regulatory bodies (FAA/AST for U.S. launch and operations licensing) as a draft reference standard. Request formal feedback cycles aligned with the development roadmap. Document all precedents from ISS robotic operations (Canadarm2 autonomous modes, Astrobee free-flyer operations) and commercial satellite servicing missions (Northrop Grumman MEV, Astroscale ELSA-d) as evidentiary foundation.
Develop and Validate the Post-Repair Recertification Protocol (Months 6–18). Using ground prototype hardware, design, implement, and test the automated recertification sequence. Define standardized test objects and reference tasks. Validate that the 4–8 hour recertification timeline is achievable and that the protocol reliably distinguishes between robots safe to return to GREEN status and those requiring further intervention. This capability is prerequisite to the "repair by peer robots" operational concept.
Conduct a Tabletop Certification Exercise for LEO Demonstration (Month 12). Before hardware design freeze for the LEO demonstration mission, execute a full tabletop walkthrough of the certification process using the CAA framework against the planned 3–5 robot LEO configuration. Identify gaps, ambiguities, and impractical requirements while design changes are still feasible. Include regulatory stakeholders as observers to build shared understanding and surface objections early.
Key Points of Agreement
- Hardware-enforced safety boundaries are non-negotiable.** An independent FPGA-based safety kernel, physically capable of cutting power to actuators and electron beam welding systems regardless of autonomy software commands, provides the irreducible safety floor. Its relative simplicity (~50,000 lines of VHDL) makes exhaustive formal verification via model-checking tools (SPIN, TLA+) tractable, unlike the autonomy stack as a whole.
- Continuous certification replaces point-in-time certification.** Robots operating for 5–20 years with degrading components and peer-performed repairs cannot be meaningfully certified once at deployment. A formal certification state machine (GREEN/YELLOW/RED/BLACK) with measurable, objective transition criteria—such as positioning accuracy degradation beyond ±0.75mm triggering restriction from precision assembly—provides ongoing assurance.
- Simulation-based statistical validation is the only viable path for autonomy software.** Formal verification of non-deterministic planning, visual servoing, and multi-robot coordination is impractical. A target of 10 billion simulated robot-hours with adversarial fault injection, demonstrating with 99.9% confidence that catastrophic failure probability remains below 10⁻⁶ per robot-hour, provides a defensible evidentiary basis.
- Multi-robot emergent behavior requires architectural constraints, not just testing.** Formally verified interaction protocols, a maximum coordination group size of 6 robots per task, mandatory workspace access control analogous to air traffic management, and periodic fleet-wide state resets bound the combinatorial complexity that makes swarm verification otherwise intractable.
- Post-repair recertification must be fully autonomous and auditable.** A 4–8 hour automated recertification sequence—covering hardware self-test, sensor calibration, manipulator accuracy verification against standardized references, and peer cross-validation—enables the "repair by peer robots" operational concept without requiring Earth-based assessment for every maintenance event.
- Proactive regulatory engagement is a strategic imperative.** Proposing the CAA framework to NASA OSMA and ESA Product Assurance as a reference standard, rather than waiting for regulators to develop their own approach, shapes the precedent that will govern autonomous space operations for decades and avoids schedule-killing regulatory uncertainty.
Unresolved Questions
- What is the acceptable boundary between formally verified and statistically validated software components?** The three-layer architecture draws a clear conceptual line, but practical implementation will surface gray areas—particularly for sensor fusion algorithms and anomaly detection systems that feed into both the behavioral constraint layer and the autonomous decision space. Where exactly does DAL-A rigor end and simulation-based validation begin?
- How should common-mode failures be addressed when they span the safety kernel and autonomy layers?** TMR mitigates random hardware failures, and layer separation mitigates software defects, but environmental conditions outside the design envelope (unprecedented radiation events, unanticipated thermal scenarios, micrometeorite damage patterns) could simultaneously compromise multiple layers. What residual risk level is acceptable, and how is it quantified?
- What governance structure authorizes autonomy level transitions during graduated deployment?** The phased trust-building roadmap (LEO demo → heliocentric pilot → initial production → full scale) requires someone or some body to decide when sufficient evidence exists to expand operational authority. Who holds this authority, what evidentiary standards apply, and how are they insulated from schedule pressure?
- How does the certification framework handle fleet-wide software updates deployed to hundreds of operational robots?** Updating autonomy software (Layer 3) across 350+ robots operating at varying distances from Earth introduces risks of version inconsistency, update-induced failures, and coordination protocol mismatches during rollout. What validation and rollout protocols ensure fleet coherence without requiring simultaneous fleet-wide stand-down?
Recommended Actions
- Establish a Formal Methods Engineering Team (Months 0–3).** Recruit 8–12 engineers with expertise in formal verification, model checking, and safety-critical systems design. Task them with developing the Layer 1 hardware safety kernel specification and Layer 2 behavioral constraint formal models in parallel with the robotics design team. This is the binding schedule constraint—delay here propagates directly to LEO demonstration readiness.
- Commission the Simulation Validation Infrastructure (Months 3–9).** Issue requirements and begin procurement/development of the high-fidelity simulation environment, including multi-body dynamics, sensor models with realistic degradation, radiation environment effects, and multi-agent interaction at fleet scale. Target initial operational capability for single-robot fault injection testing by Month 12 and multi-robot scenarios by Month 18. Budget $50–100M as a one-time capital investment.
- Initiate Regulatory Pre-Engagement (Months 0–6).** Present the CAA framework concept to NASA OSMA, ESA Product Assurance, and relevant commercial space regulatory bodies (FAA/AST for U.S. launch and operations licensing) as a draft reference standard. Request formal feedback cycles aligned with the development roadmap. Document all precedents from ISS robotic operations (Canadarm2 autonomous modes, Astrobee free-flyer operations) and commercial satellite servicing missions (Northrop Grumman MEV, Astroscale ELSA-d) as evidentiary foundation.
- Develop and Validate the Post-Repair Recertification Protocol (Months 6–18).** Using ground prototype hardware, design, implement, and test the automated recertification sequence. Define standardized test objects and reference tasks. Validate that the 4–8 hour recertification timeline is achievable and that the protocol reliably distinguishes between robots safe to return to GREEN status and those requiring further intervention. This capability is prerequisite to the "repair by peer robots" operational concept.
- Conduct a Tabletop Certification Exercise for LEO Demonstration (Month 12).** Before hardware design freeze for the LEO demonstration mission, execute a full tabletop walkthrough of the certification process using the CAA framework against the planned 3–5 robot LEO configuration. Identify gaps, ambiguities, and impractical requirements while design changes are still feasible. Include regulatory stakeholders as observers to build shared understanding and surface objections early.
Discussion Rounds
Responses
Autonomy Certification Framework for Project Dyson Assembly Robots
Core Thesis
The certification challenge for Project Dyson's assembly robots is not merely an extension of existing spacecraft certification—it represents a fundamentally new category requiring a hybrid framework that borrows structural elements from aviation software assurance (DO-178C), automotive functional safety (ISO 26262), and offshore autonomous systems (DNV-GL), while introducing novel elements for multi-agent space construction. I recommend a continuous certification architecture rather than a traditional point-in-time certification, built on three pillars: formal behavioral envelopes, runtime verification with hardware enforcement, and statistical validation through massive simulation campaigns.
Why Existing Frameworks Fall Short
DO-178C (Aviation Software) provides the most mature model for safety-critical software certification, with its Design Assurance Levels (DAL A through E) mapping nicely to criticality tiers. However, it assumes deterministic software behavior and comprehensive requirements-based testing. Assembly robots making real-time decisions about grasp planning, path optimization, and fault response in unstructured environments will necessarily incorporate non-deterministic elements—machine learning for visual servoing, probabilistic planners for multi-robot coordination. DO-178C has no pathway for certifying learned behaviors.
ISO 26262 (Automotive) introduces the concept of Automotive Safety Integrity Levels (ASIL) and importantly addresses systematic failures alongside random hardware failures. Its hazard analysis methodology (HARA) is directly applicable. However, automotive certification assumes a bounded operational design domain with well-characterized environmental conditions. The space assembly environment—thermal cycling, radiation transients, micrometeorite impacts, variable lighting—introduces failure modes with no terrestrial analog.
DNV-GL autonomous shipping standards are perhaps the closest conceptual match, addressing unmanned systems operating with communication constraints. Their concept of "autonomy levels" with defined fallback states maps well to our graduated autonomy requirements. But they still assume periodic human oversight and port-based maintenance cycles.
The gap is clear: no existing framework addresses systems that must operate autonomously for weeks or months, self-repair, coordinate in swarms, and make safety-critical decisions faster than communication latency permits human involvement.
Proposed Framework: Continuous Assurance Architecture (CAA)
Pillar 1: Formal Behavioral Envelopes with Hardware Enforcement
Every assembly robot must operate within formally specified behavioral boundaries. I recommend a three-layer envelope structure:
Layer 1 — Physical Safety Kernel (Hardware-Enforced) This is non-negotiable and implemented in radiation-hardened FPGA logic, completely independent of the main flight computers. It enforces:
- Maximum joint velocities and accelerations for all manipulator axes
- Minimum separation distances from peer robots and protected structures (I'd set this at 2.0m default, reducible to 0.1m only with active cooperative handshake)
- Electron beam welder power limits and pointing constraints (the 60–150 kV systems cannot activate unless the beam axis is within a verified safe cone)
- Thermal and electrical limits on all actuators
- Absolute position boundaries defining the robot's authorized work volume
This kernel has authority to cut power to actuators and welding systems regardless of what the autonomy software commands. It is formally verified using model-checking tools (e.g., SPIN, TLA+) against a complete specification. The kernel's simplicity—perhaps 50,000 lines of VHDL—makes exhaustive verification tractable.
Layer 2 — Behavioral Constraints (Software-Enforced, Formally Verified) Running on the TMR flight computers but as a separate, verified monitor process:
- Task sequence validation (assembly operations must follow verified procedures)
- Resource consumption bounds (propellant, power, thermal budget)
- Communication protocol compliance
- Multi-robot coordination protocol adherence
- Graceful degradation state machine (defines legal transitions between operational modes)
This layer is certified to DO-178C DAL-A equivalent rigor. It's deterministic, requirements-based, and testable through traditional methods.
Layer 3 — Autonomous Decision Space (Validated, Not Formally Verified) This is where the actual autonomy lives—path planning, grasp optimization, anomaly diagnosis, task scheduling. This layer operates within the constraints imposed by Layers 1 and 2. The key insight: we don't need to formally verify that the planner always makes optimal decisions; we need to verify that Layers 1 and 2 always prevent unsafe decisions from reaching actuators.
This architectural separation means the autonomy software can be updated, improved, and even incorporate machine learning components without requiring recertification of the safety layers.
Pillar 2: Runtime Verification and Continuous Monitoring
Traditional certification asks "is this system safe?" at a point in time. For robots operating 5–20 years with degrading components and peer-performed repairs, we need continuous assurance.
Onboard Runtime Verification System (RVS) Each robot runs a dedicated runtime monitor (on a separate processor from the main TMR stack) that:
- Checks every commanded action against the Layer 2 behavioral specification before execution
- Monitors sensor health and cross-validates redundant measurements
- Tracks component degradation trends (bearing wear, actuator current draw, optical sensor noise floors)
- Maintains a continuously updated "fitness score" across multiple dimensions
Fleet-Level Health Monitoring The local coordination network enables peer-based health assessment:
- Robots periodically verify each other's positioning accuracy using independent measurements
- Anomalous behavior detected by peers triggers investigation protocols
- Fleet-wide statistical analysis identifies systematic issues (e.g., a batch of actuators showing correlated degradation)
Certification State Machine Each robot maintains a formal certification state:
- GREEN: Fully certified for all operations including safety-critical assembly
- YELLOW: Degraded but certified for limited operations (specific tasks restricted)
- RED: Safe-hold only, awaiting repair or Earth-based assessment
- BLACK: Disabled, physically safed by peer robots
Transitions between states are governed by measurable criteria—not subjective assessment. For example: if positioning accuracy degrades beyond ±0.75mm (50% margin erosion from the ±0.5mm requirement), the robot transitions from GREEN to YELLOW and is restricted from precision assembly tasks.
Pillar 3: Statistical Validation Through Simulation
For the Layer 3 autonomy software, formal verification is impractical. Instead, I recommend a simulation-based validation campaign modeled on Waymo's approach to autonomous vehicle certification but scaled dramatically.
Required Simulation Infrastructure
- High-fidelity physics simulation of robot dynamics, structural mechanics, and assembly processes
- Realistic sensor models including noise, degradation, and failure modes
- Multi-robot interaction simulation supporting 350+ agents
- Radiation environment modeling for single-event upsets and cumulative degradation
- Fault injection framework covering hardware failures, software errors, and environmental anomalies
Validation Criteria I propose requiring demonstration of safe behavior across 10 billion simulated robot-hours before initial deployment authorization, with specific coverage requirements:
- Every nominal assembly sequence executed 10,000+ times with randomized perturbations
- Every identified failure mode injected across the full operational envelope
- Multi-robot scenarios including communication failures, rogue robot behavior, and cascading faults
- Edge cases generated through adversarial testing (evolutionary algorithms searching for failure-inducing scenarios)
The statistical target: demonstrate with 99.9% confidence that the probability of a catastrophic failure (defined as uncontrolled release of a 500+ kg payload or uncontrolled electron beam activation) is less than 10⁻⁶ per robot-hour.
Addressing Specific Concerns
Post-Repair Recertification
A robot repaired by peers must undergo automated recertification:
- Hardware safety kernel self-test (Layer 1 verification)
- Full sensor calibration against known references
- Manipulator accuracy verification using standardized test objects
- Abbreviated behavioral test sequence (autonomous execution of reference tasks)
- Peer verification of positioning accuracy
This process should take 4–8 hours and return the robot to GREEN or identify remaining deficiencies. Critically, the repair robot must document all actions taken, creating an auditable maintenance record transmitted to Earth at next opportunity.
Multi-Robot Emergent Behavior
This is the hardest problem. I recommend:
- Coordination protocols designed with formally verified interaction patterns (no free-form negotiation)
- Maximum coordination group size limited to 6 robots for any single task, reducing combinatorial complexity
- Mandatory "traffic control" protocols for shared workspace access, analogous to air traffic management
- Periodic fleet-wide "reset" operations where all robots return to known states
Graduated Deployment
The certification framework should support phased trust-building:
- Years 2–3 (LEO demo): 3–5 robots, continuous ground monitoring, human approval for all assembly operations (latency permits this in LEO)
- Years 4–5 (heliocentric pilot): 10–20 robots, human approval for novel operations only, autonomous execution of previously validated sequences
- Years 5–7 (initial production): 100+ robots, full autonomy within certified behavioral envelopes, Earth-based strategic oversight only
- Years 7+ (full scale): 350+ robots, autonomy software updates deployed based on operational experience
Cost and Schedule Implications
This framework pushes costs toward the middle of the estimated range. The hardware safety kernel adds approximately $15,000–25,000 per unit (dedicated FPGA, independent sensors). The simulation infrastructure represents a one-time investment of $50–100M but amortizes across the fleet. Runtime verification adds computational overhead requiring roughly 15% more processing capacity per robot.
The critical schedule item is establishing the formal behavioral specification (Layer 2) during Years 1–2. This must be complete before LEO demonstration hardware is finalized. I recommend dedicating a team of 8–12 formal methods engineers starting immediately, working alongside the robotics design team.
Regulatory Strategy
Rather than waiting for regulators to develop frameworks, Project Dyson should propose this CAA framework to NASA's Office of Safety and Mission Assurance and ESA's Product Assurance division as a reference standard. By leading the regulatory conversation with a concrete, well-reasoned framework, we shape the outcome rather than react to it. The precedent set here will govern autonomous space operations for decades.
Vote Breakdown
Termination Votes
Question Details
- Source Phase
- Phase 1 - Initial Swarm Deployment
- Source BOM Item
- Assembly Robots
- Question ID
- rq-1-16
- Created
- 2026-02-01
- Related BOM Items
- bom-1-3bom-1-4bom-1-7