Understanding Outputs

Every execution writes artifacts before they are shown in a Console, review, or report. The filesystem bundle is the durable result and carries enough context to identify the input, product version, execution outcome, and available result families.

Console-launched runs are retained beneath the configured Console workspace; imported runs remain in their original trusted result folder. The Console's Export loaded results action creates a portable ZIP copy while leaving either source bundle unchanged; the adjacent Browse files action opens the source bundle directly in the system file explorer.

Core Run Bundle

runs/core/<run_id>/
|-- run_manifest.json
|-- metrics_summary.json
|-- environment_summary.json
|-- runspec.json
|-- config/
|-- states/
`-- <stage-specific families>/

Read the four top-level contracts first:

Artifact	Purpose
run_manifest.json	Status, product and execution provenance, stage plan, warnings, artifact inventory, and hashes
metrics_summary.json	Compact engineering outcomes and execution health
environment_summary.json	Simulation and operational context
runspec.json	Canonical expanded input that was executed

Source snapshots and execution-normalized forms may also appear under runspec/. Imported component-profile provenance is recorded under config/.

Common Result Families

Directory	Typical contents
states/	satellite inventory, timestamps, and propagated state timelines
geometry/	ground or inter-satellite access samples and windows
coverage/	point, regional, and aggregation outputs
mission/	service or observation definitions, events, and KPIs
transport/	delivery, backlog, latency, gateways, beams, ISLs, and routes
activity/	spacecraft-facing activity and operating-state timelines
attitude/	commanded and realized pointing or mode histories
power/	generation, load, battery, margin, and sizing results
propulsion/	burn, state-change, mass, and propellant accounting
diagnostics/	optional execution or resource diagnostics

Not every run contains every family. Absence normally means the corresponding stage or detailed artifact option was not requested. Use the owning model page to interpret its files and units.

Compact Transport Analysis

To keep service histories and delivery totals without full link/routing diagnostics, enable this option in a run that executes transport:

artifacts:
  detail: summary
  write_transport_analysis: true

This works with conventional and EFC grids, including large_sparse_exact runs. It is off by default and does not change scheduling or link calculations. The additional files in transport/analysis/ are compressed Parquet, without CSV copies even when other CSV exports are enabled:

File	Contents
service_samples.parquet	One row per execution point and timestamp, including unreachable samples; selected path/beam, latency and bytes served during that step when available.
delivery_by_source.parquet	Whole-run admitted, delivered and remaining bytes per source, plus item counts. Includes zero-demand points.
manifest.json	Counts, units, joins, time conventions and availability information.

Use point_id to join the run's point/population mapping; it is not necessarily the EFC cell_id. Reachability means a selected service path, not geometric visibility or proof that traffic was delivered. Sample-based coverage includes the final timestamp; gaps at the start and end are censored. served_bytes is the floating-point step accounting, not a reception-time trace; it is null when unavailable. Its sum can differ from delivered_bytes, which is rounded per item before aggregation. Do not distribute whole-run delivery totals across reachable samples. Check the parent run completed successfully before using these files; the analysis manifest alone does not establish run success.

State Timelines

Propagation-capable runs normally include states/timeline_state_vectors_teme.parquet plus a timeline summary, satellite inventory, and timestamps. Read the metadata before treating table columns as a different frame or timescale. The artifact reference defines the durable contract.

Grouped Bundles

Sweeps and batches wrap standard child runs with grouped artifacts:

Layer	Sweep	Batch
Plan	sweep_plan.json	batch_plan.json
Attempts	sweep_attempts.json	batch_attempts.json
Current results	sweep_results.json	batch_results.json
Comparison	sweep_summary.json	batch_summary.json
Optional table	sweep_summary.csv	batch_summary.csv

Child executions live under cases/<case_id>/attempts/<attempt_id>/. The grouped result identifies the current/latest attempt; older attempts remain available for provenance.

Inspection Pattern

For one run:

1. confirm status, warnings, and provenance in run_manifest.json
2. inspect headline outcomes in metrics_summary.json
3. compare the canonical runspec.json with the intended assumptions
4. open the relevant model summary
5. inspect detailed tables or plots only as needed

For a sweep or batch, read its plan, current results, attempt history, and summary before opening child run bundles.

Deterministic Reviews And Reports

Use a review when you need a compact health and engineering assessment:

astraeus review run --run-dir runs/core/<run_id>

The default output is <run_dir>/run_review.md. It summarizes the run contract, status, warnings, available evidence, important metrics, and review findings.

Campaign results use the corresponding command:

astraeus review campaign \
  --result runs/campaign/<campaign_id>/campaign_plan_result.json

Use a scenario report when you need a broader decision document and curated plot pack:

astraeus report scenario --run-dir runs/core/<run_id>

This writes scenario_report.md and supported figures under report_plots/ by default. Plot availability follows the artifact families in the run; absent plots normally mean that the required evidence was not emitted.

Depending on the run, the plot pack can include orbit and gateway maps, coverage and revisit heatmaps, beam projections, scheduling evidence, latency distributions, and link-margin or ISL figures. Use --skip-plot-export for a markdown-only report; --beam-source and --satellite-id select a focused view when the relevant artifacts exist.

These commands are deterministic artifact readers: the same saved evidence produces the same review or report, missing evidence remains explicit, and the underlying run stays unchanged. User AI skills may invoke the same commands and then help explain their outputs.

The Console is best for interactive exploration; reviews are best for concise checks; reports are best for a shareable engineering narrative.

Next: Console And Visualization.