Campaign Request Reference¶

campaign_plan_request_v1 is the supported input contract for constellation deployment and rollout planning.

Minimum Shape¶

schema_version: campaign_plan_request_v1
campaign:
  campaign_id: deployment-study
  type: constellation_deployment
deployment_assets:
  - asset_id: insertion-1
    asset_type: launcher_insertion
satellite_groups:
  - satellite_id_prefix: SAT
    count: 4
target_structure:
  planes:
    - plane_id: plane-1
      slot_count: 2
    - plane_id: plane-2
      slot_count: 2
assignment:
  mode: auto
solver:
  mission_artifact_detail: summary

Required top-level fields are schema_version, campaign, deployment_assets, and target_structure. The request must also define satellites or satellite_groups.

Top-Level Blocks¶

Block	Required	Purpose
`schema_version`	Yes	Must be `campaign_plan_request_v1`
`campaign`	Yes	Identifier, campaign type, objective, and constraints
`deployment_assets`	Yes	Launcher insertion, OTV, or carrier resources
`satellites`	Conditional	Explicit per-satellite definitions
`satellite_groups`	Conditional	Repeated spacecraft definitions with generated identifiers
`target_structure`	Yes	Planes, slots, and desired orbital structure
`assignment`	No	Automatic, overridden, or explicit assignments
`environment`	No	Reference epoch and environment settings
`solver`	No	Strategy and execution policy

Campaign¶

Supported campaign.type values are:

constellation_deployment
otv_deployment
in_plane_phasing

campaign.constraints can bound duration, event volume, or other campaign-level behavior applicable to the selected type. Validation establishes request consistency; execution determines feasibility within those constraints.

Deployment Assets¶

At least one deployment asset is required. Supported asset types are:

launcher_insertion
otv
carrier

An asset may define availability, release timing, spacecraft or propulsion assumptions, and an initial state. The initial state requires epoch_utc and frame, plus exactly one of orbit_elements or cartesian_state. The current campaign initial-state frame is TEME.

Carrier Delivery Envelope¶

An otv or carrier with a circular orbit-elements initial state can define a bounded delivery transfer under capabilities.delivery_transfer:

capabilities:
  delivery_transfer:
    model: circular_hohmann_envelope_v1
    target_sma_km: 6918.137
    payload_capacity_kg: 300
    delta_v_capacity_m_s: 550
    operations_duration_s: 43200

The planner computes a two-impulse Hohmann transfer from the asset's initial circular orbit, advances the release state through transfer and operations, and checks assigned wet payload mass and required delta-v against the declared envelope. operations_duration_s and departure_at_utc are optional.

The result records asset_transfer, asset_operations, and asset_ready events where applicable, plus a campaign_asset_delivery_summary diagnostic with transfer timing, payload margin, and delta-v margin. The envelope keeps those carrier-level measures separate from client-spacecraft mission burden.

Satellites And Groups¶

Use satellites when each spacecraft needs its own identifier, asset relation, or spacecraft definition. Use satellite_groups when several spacecraft share one template. A group normally defines a satellite_id_prefix, positive count, and shared spacecraft properties.

Expanded satellite identities and assignments are preserved in the result.

Target Structure¶

target_structure.planes defines the desired orbital planes and slot counts. Plane targets can include orbit or phasing coordinates applicable to the campaign type, such as semi-major axis, altitude bounds, inclination, RAAN, LTAN, phase offset, or tolerances.

The target is the closure authority. Review final target positions and residuals in addition to assignment counts when determining whether the requested structure was achieved.

Assignment¶

assignment.mode accepts:

Mode	Meaning
`auto`	Planner selects assignments
`auto_with_overrides`	Planner selects assignments subject to explicit overrides
`explicit`	Request supplies the assignments

Overrides are engineering constraints and should be reviewed as carefully as the target itself. They can make a campaign infeasible or force a higher-burden solution.

Solver¶

Common solver controls include strategy selection, refinement limits, mission worker policy, exact mission-solve reuse, and mission artifact detail.

Long-duration electric slot acquisition can use a stricter terminal stationkeeping handoff after a broader candidate search:

solver:
  parameters:
    slot_acquisition_stationkeeping_handoff_enabled: true
    slot_acquisition_stationkeeping_handoff_radial_tolerance_km: 2

When enabled, the selected endpoint must satisfy the configured apoapsis and periapsis radial residual before the mission is accepted. The handoff currently applies to electric-propulsion slot acquisition. Keep the target tolerances and the handoff bound explicit when interpreting closure.

mission_artifact_detail accepts:

Value	Result
`summary`	Mission outcomes remain embedded in the campaign result
`full`	Additional per-satellite mission request/result bundles are persisted

Summary is the normal first run. Full detail can be large for a campaign with many satellites.

Validate¶

astraeus campaign-plan validate --input <request.yaml>

Validation checks the versioned structure and campaign semantics without executing the plan. Begin from the copied deployment-campaign.yaml example for a complete supported baseline.