Campaign Planning¶
astraeus campaign-plan evaluates constellation deployment and rollout plans.
A campaign request defines the objective, deployment assets, satellites, target
structure, and solver policy. Astraeus writes one self-contained result with the
selected strategy, assignments, sequence, mission outcomes, and target closure.
Use campaign planning to answer questions such as:
- Which deployment asset should place each satellite?
- How should satellites be distributed across planes and slots?
- Does the proposed sequence meet duration and event constraints?
- Which satellite missions are feasible, infeasible, or failed?
- What remains when the target is only partially achieved?
Campaign planning is a supported user workflow. It is distinct from the internal
standalone mission-planning command and from the service or observation
mission stage inside a RunSpec.
Supported Campaign Types¶
| Type | Purpose |
|---|---|
constellation_deployment |
Populate a multi-plane target structure. |
otv_deployment |
Plan delivery with an orbital-transfer-vehicle-style asset. |
in_plane_phasing |
Move toward a target phase or slot relationship within one plane. |
All types use the same top-level request contract but have different objectives, asset assumptions, and result interpretation.
Result Model¶
The primary output is:
runs/campaign/<campaign-id>/campaign_plan_result.json
It embeds the validated request and records complete, partial, or unsuccessful outcomes. A partial result is often the useful answer: it should identify the achieved positions and the assignment, sequencing, timing, or mission constraints that block the remainder.
Mission side bundles are optional. Use summary detail for normal campaign review and full detail only when individual satellite missions require deeper inspection.
Guide Map¶
Start with the first campaign run for a guided partial-success case.