V13 ARCHITECTURE
A swarm is the output of an industrial civilization.
V13 keeps the civilization, swarm, elevator/tether, R&D, spacecraft and transit models, then adds a Pareto strategy layer above the scalar optimizer, fleet architect, component-level vehicle designer and engineering-closure layer. It follows representative missions while also deciding which saved spacecraft architecture should mine, haul cargo, move propellant, bootstrap factories, service relays, support the Moon and Mars, or work close to the Sun.
INTERACTIVE CIVILIZATION MODEL
100-Year Swarm Simulator v13
MISSION CLOCK
2126
Scrub the century to inspect any modeled year.Solar-system industrial network
Orbital zones, settlements, resource nodes and logistics links at the selected year.
Power generation, demand and surplus
Delivered photonic power versus Earth + Moon + Mars modeled demand.
Industrial expansion
Collectors and factory nodes
Annual material sources
Earth launch, Moon, asteroid resources and elevator throughput
Technology readiness
R&D-dependent enabling systems
Settlements
Modeled supported population equivalents
Mining + cargo fleet expansion
Fleet-equivalents allocated to extraction and transport
Target cargo arrivals
Material that has completed its return transit and reached industry
Transit pipeline
Dispatched cargo, arrivals and material still between nodes
Propellant economy
Reserve, annual production and flight consumption
Selected-year transfer board
Route state after spacecraft mass-ratio, power, propellant, staging and transit constraints. Kepler propagation is still a simplified two-body model, not a navigation solution.
Model milestones
Derived from this run
Primary constraint
Strongest modeled bottleneck at the selected year
—
EVENT-DRIVEN MISSION OPERATIONS
Follow the ships, not just the tonnes.
The century model may imply millions of fleet-equivalents, so V13 keeps a capped representative roster of named hulls. Representative hulls now pass through construction queues, accumulate wear and radiation-dose proxies, experience light-time communications and fly on the same selected trajectory model used by the route layer.
Active flight map
Representative vessel positions along selected-year transfers.
Depot inventory
Modeled split of the shared propellant reserve across operational nodes.
Event log
Departures, arrivals, failures, repairs and retirements in the selected year.
Active mission manifest
Named representative hulls with destination, cargo, cohort scale and transfer progress.
Representative vessel roster
Current hull state, build origin, reuse cycles and next availability.
V13 SOLAR-SYSTEM DIGITAL TWIN
Trajectory, traffic, wear and logistics on one clock.
This layer is deliberately lighter than professional flight dynamics. It can numerically perturb target states and solve zero-revolution Lambert-style transfers, then couples those route estimates to representative spacecraft, dated operations, communications light-time, shipyard queues, depot flow and hardware-health proxies.
3D-ish traffic / trajectory view
Inclination-aware projection of target states and representative active flights. Visual geometry is illustrative; transfer planning uses the numerical state model.
Launch calendar
Next modeled favorable geometry with transfer Δv and time of flight.
Traffic + communications
Light-time is physical; relays and autonomy improve availability, not signal speed.
Shipyard construction queue
Representative hulls now require modeled construction time before entering service.
Depot flow ledger
Annualized production, consumption and modeled inventory movement by network node.
V13 ENGINEERING DIGITAL TWIN
Mass, power, heat, links and nodes must all close.
V13 adds a representative spacecraft engineering budget and a cislunar/planetary logistics-node network. These are systems-level sizing calculations, not hardware certification or mission flight plans.
Solar-system node network
Earth orbit, lunar surface, Earth–Moon L1/L2, Mars orbit/surface and deep-space staging nodes with modeled readiness, throughput and light-time.
Subsystem closure
Representative cargo-craft mass and margin accounting.
Communications link budget
Simplified free-space link calculation for the most demanding active route.
Logistics-node ledger
Representative operational state and throughput across the infrastructure graph.
Construction orders
Priority orders derived from current bottlenecks, fleet losses, depot needs and reserve policy.
Engineering closure over the century
Mass, power, thermal and communications closure scores. 100% means the representative design meets this simplified model's thresholds.
V13 MULTI-DESIGN FLEET ARCHITECT
Design a fleet, not one universal ship.
V13 maintains a library of spacecraft architectures. Pin designs to mission roles manually or let the Intellect choose among them as technology matures. The selected portfolio feeds mining productivity, cargo route closure, tanker logistics, shipyard mass demand and representative mission operations.
Mission-role portfolio
Active design for each mission role at the selected year.
Intellect allocation rationale
Saved design library
Use the component designer below to configure a vehicle, then save it into a custom slot. Custom slots persist in this browser and are included in scenario exports.
Fleet portfolio evolution
Weighted vehicle readiness, build-mass efficiency and role specialization across the century.
V13 INTELLECT EVOLUTION LAB
Breed spacecraft for the mission, not the brochure.
The optimizer evaluates component stacks against each mission role, preserves elites, crosses parent designs, mutates genes and carries role champions into later design cycles. Fitness is a planning score built from readiness, payload/build-mass efficiency, reuse, safety, power, communications, thermal capability and century-objective pressure—not a proof that a vehicle is flight-ready.
Selected-year design cycle
Run an extra optimizer pass at the selected mission-clock year, then optionally promote the eight champions into persistent evolved library slots.
Role champions
Best evolved architecture available at the selected year.
Latest generation log
Evolutionary fitness through the century
Average best champion fitness after each automated design cycle.
V13 PARETO CIVILIZATION LAB
There is no single best future.
V13 uses non-dominated sorting and diversity preservation to keep strategies that make genuinely different trade-offs. A strategy can remain on the frontier because it is safer, less Earth-dependent, more settlement-oriented, more science-oriented, less speculative, more powerful, or simply farther along toward the swarm—even when another strategy wins a different objective.
Multi-objective strategy search
Run a fresh deterministic Pareto search, select any frontier strategy for inspection, or apply it to the visible civilization controls. Auto-knee mode can drive the live simulation without overwriting your base controls.
Pareto frontier
Each row is non-dominated in the validated strategy set. Select one to inspect its genome.
Selected strategy
Policy/timing genome plus seven normalized objective scores.
Pareto trade-space
Parallel-coordinate view of the validated frontier. Higher is better on every axis; no weighting is used to decide dominance.
V12 SCALAR ARCHITECTURE LAB
Evolve the system that builds the swarm.
The retained V12 scalar optimizer searches one chosen objective at a time. It remains useful for comparison with V13's Pareto frontier, but its weighted objective can hide trade-offs that the Pareto lab keeps visible. This is policy optimization, not a prediction that social or technological choices can be centrally solved.
Scalar century strategy search
Run a fresh deterministic search from the current scenario, apply the champion to the visible strategy controls, or clear the cached/manual result.
Champion genome
Only policy/allocation/timing genes are evolved; mobilization and core capability remain user-defined.
Validated finalists
Architecture search convergence
Best and mean surrogate fitness by strategy generation. The live Century Goal remains an independent system-level check.
V13 COMPONENT-LEVEL VEHICLE WORKBENCH
Build the ship that moves the civilization.
Use this workbench to inspect or edit one spacecraft architecture. With the V13 fleet architect enabled, this design can be saved into a custom library slot and assigned to one or more fleet roles; otherwise it retains the V9-style single-vehicle behavior.
Vehicle architecture schematic
Systems-level representative layout. Geometry is illustrative, not a manufacturing drawing.
Component ledger
Compatibility + readiness
Vehicle family
Mission design consequences
Vehicle design maturity over the century
Component readiness and resulting design closure for the selected architecture.
SPACECRAFT + DEPOT LEDGER
Every tonne needs a ride.
V13 keeps aggregate role-specific fleet capacity for macro throughput while the operations console follows a capped representative set of reusable named vessels, tanker flights and mission events using the currently assigned cargo and tanker architectures.
DEEP-SPACE TARGET LEDGER
Real bodies, spacecraft-constrained routes.
The body names and orbital elements are reference data. V13 uses a bundled offline element snapshot and can import a user-prepared ephemeris/orbital JSON snapshot. The selected engine can use two-body Kepler propagation or an RK4 Sun+Earth+Mars+Jupiter local perturbation proxy, with optional Lambert-style transfer search. Recoverable reserves, mining economics, spacecraft architecture and trajectory cost remain scenario assumptions—not certified reserves or mission trajectories.
INFRASTRUCTURE LEDGER
Named hubs with real dependencies.
These are project-level scenario assets, not claims that such facilities currently exist. Each hub activates only after its prerequisite thresholds are reached.
RESOURCE LEDGER
Feedstock comes from different resource classes.
V13 counts asteroid feedstock only after scheduled cargo returns arrive; the operations console mirrors representative flights without pretending to enumerate every mature-scale spacecraft. Propellant production can divert part of Earth launch, lunar output and volatile-rich asteroid arrivals away from construction.
INTELLECT COORDINATION LAYER
Allocation changes with the state of the system.
Current resource allocation
Current power allocation
R&D portfolio
DYNAMIC TECHNOLOGY TREE
The path unlocks dependency by dependency.
“Unlocked” means the model’s readiness, year and infrastructure thresholds are met. It does not mean the technology is guaranteed to be feasible in reality.
V13 REFERENCE ROADMAP
Prototype → bootstrap → replicate → expand.
Demonstrate
Autonomous construction, lunar surface power, precision beaming, reusable launch, robotic ISRU and high-reliability orbital servicing.
Bootstrap
Lunar foundries, mass-driver experiments, orbital yards, closed-loop repair and early asteroid prospecting.
Replicate
Distributed factory nodes, NEO prospecting, route-qualified autonomous mining fleets, component-qualified reusable cargo tugs, propellant depots, mission-control automation, tanker flights, cislunar tether options and mature photonic links.
Move inward
Thermally capable collectors occupy closer solar orbits while main-belt depots, high-Isp cargo transport, refueling and traffic management scale.
Integrate
Planetary relays, industrial settlements, mature multi-target resource routing, standardized ship families, persistent event-driven cargo operations, traffic-control automation, shipyard/depot scheduling, reserve power for planetary-engineering research, and a swarm-scale grid.
RESEARCH ANCHORS · CHECKED 2026
Anchor the speculative model in real enabling work.
These sources support the orbital-data interface, trajectory concepts, radiation-reliability assumptions and enabling technology used by the model. V13 deliberately does not embed JPL SSD API calls directly in the site; JPL documentation notes API fair-use/CORS constraints, so the simulator uses bundled data plus explicit file import. They do not imply that industrial asteroid mining, a Dyson swarm, or an Earth space elevator is currently buildable.