Mission Types

mission.kind selects the intent modeled inside a RunSpec. Astraeus currently supports two mission families:

• service for communications availability and delivery
• observe for collection, product generation, and delivery

The mission stage creates domain truth. The shared transport stage then moves the resulting traffic or products through the configured network.

flowchart LR INPUT["Mission intent"] --> TRUTH["Service points or observation products"] TRUTH --> TRANSPORT["Links, scheduling, routing, and delivery"] TRANSPORT --> KPI["Mission-specific outcomes"]

Choose The Mission Family

Question	service	observe
Primary intent	Serve user or demand locations	Collect target data
Geographic unit	Service points, grids, or regions	Target areas and target grids
Mission truth	Availability, offered demand, and service KPIs	Opportunities, captures, and data products
Transport work	Service traffic	Observation products
Typical outcomes	served fraction, capacity, latency, backlog	capture, delivery, timeliness, usefulness, revisit
Example baseline	service-downlink.yaml	observation-to-delivery.yaml

Choose service when the main question concerns users, demand, gateways, capacity, scheduling, routing, or delivery. Choose observe when it concerns target visibility, collection qualification, data products, delivery, or revisit.

Service Missions

A service mission begins with geography and a communications profile:

mission:
  kind: service
  service:
    profile_id: nr_baseline
    ue:
      min_elevation_deg: 10
      min_access_s: 45

Typical supporting inputs define:

• service regions, grids, population, or terminal cohorts under geography and mission.service
• ground gateways under ground
• link, beam, scheduling, routing, and ISL policy under transport
• reusable communications and component profiles through imports

Mission artifacts describe the service points and regional or directional KPIs. Transport artifacts then describe admitted and delivered traffic, capacity, latency, routes, and backlog. Use the Communications and service guide for model details and limitations.

Start with:

• astraeus-resources/examples/user/service-downlink.yaml
• astraeus-resources/examples/user/population-service.yaml
• astraeus-resources/examples/user/isl-routed-network.yaml

Spatial service summaries distinguish where demand was offered from where the selected access, gateway, and scheduling chain served it.

Observation Missions

An observation mission defines sensor behavior and targets:

mission:
  kind: observe
  observe:
    default_sensor_profile_id: regional_eo
    collection_pointing_mode: ground_track
    sensor_profiles:
      regional_eo:
        sensor_kind: generic_eo
        fov_half_angle_deg: 25
        max_off_nadir_deg: 35
        product_kind: observation_product
        product_size_bytes: 8000000
    targets:
      - target_id: target-region
        area_id: target-region

Typical supporting inputs define:

• target geometry under geography
• sensor field of view, off-nadir, dwell, and visible-fraction gates
• ground sites and transport policy for product delivery
• attitude and finite-slew realization when pointing feasibility matters
• activity and power coupling when capture, processing, or downlink loads matter

The mission produces opportunities, qualified captures, and data products. Transport reports whether and when those products reached their destination. Observation results can then summarize usefulness and revisit by target.

Start with:

• astraeus-resources/examples/user/observation-to-delivery.yaml
• astraeus-resources/examples/user/integrated-constellation-study.yaml

The observation model supports first-order collection and delivery studies. Its resolution covers access, pointing realization, collection, and delivery rather than detailed sensor physics or collection optimization. See Attitude for pointing realization and its assumptions.

Shared Transport, Different Meaning

Service traffic and observation products use common connectivity, gateway, routing, scheduling, delivery, and backlog machinery. Similar transport files do not make the mission outcomes interchangeable:

• service asks how demand was served
• observation asks what was captured and delivered
• each mission family owns its own summary and KPI interpretation

Keep mission and transport stages together when end-to-end delivery matters. Add attitude, power, or propulsion only when the engineering question requires those couplings.

Run the curated baselines with:

astraeus run astraeus-resources/examples/user/service-downlink.yaml --run-id ex-service
astraeus run astraeus-resources/examples/user/observation-to-delivery.yaml --run-id ex-observe

For exact input fields, use the RunSpec reference.