Product Boundaries And Support

This page collects the cross-cutting boundaries that apply when evaluating or using Astraeus. Model-specific assumptions remain on the relevant engineering pages; this page should not be read as overriding them.

Status And Supported Platforms

Astraeus is currently alpha, pre-release software intended for controlled engineering evaluation and traceable trade studies.

The source-free product bundle is qualified by target. Current delivery targets are:

Platform	Required runtime
Linux x86-64 (manylinux_2_28)	CPython 3.11 x86-64
Windows x86-64	CPython 3.11 x86-64

Qualification applies only to the listed platform, architecture, Python version, bundle, and supplied installer combination.

Supported Product Interfaces

The supported user interfaces are:

• the installed astraeus CLI;
• runspec_v8 and the documented campaign request;
• documented core, grouped-study, and campaign artifacts;
• the packaged local Console and Run Monitor;
• deterministic review and scenario-report commands;
• bundled user resources and the ten user AI skills.

Together, these interfaces cover authoring, execution, monitoring, review, and reporting for the supported study and campaign workflows.

Cross-Cutting Limitations

Area	Current boundary
Propagation	Near-Earth SGP4 is the supported propagator; deep-space and high-fidelity numerical orbit determination are outside the present scope
Geometry	Access and revisit are sampled at the configured cadence; the calculation uses ellipsoid geometry and sampled events, excluding terrain, local horizons, refraction, and continuous event roots
Coverage	Results depend on grid, region, mask, cadence, and selected equal-point or represented-surface aggregation
Communications	Link budgets, capacity, beams, demand, deterministic scheduling/routing, and selected interference models support aggregate service studies; packet protocols and universal RF emulation require separate tools
Attitude	Finite slew provides a reduced-order envelope and optional calibrated timing model; flight-dynamics and controller qualification require separate evidence
Power	The deterministic lumped model supports energy-balance studies under explicit assumptions; transient electrical and thermal behavior require separate models
Propulsion	Finite/impulsive engineering propagation and accounting operate within documented burn assumptions; guidance, navigation, and maneuver certification require separate evidence
Campaigns	Supported deployment campaign types evaluate assignment, sequencing, mission burden, and closure within explicit candidate strategies
Console	Broad local configuration and review are available, but advanced RunSpec fields and result families remain CLI/artifact workflows
Operation	Current services are local and single-user; distributed queues and multi-user collaboration require separate infrastructure
Extensibility	Extensibility currently uses documented RunSpec modules; a stable user plug-in surface is planned for a later release

See Scientific Validation for the evidence-backed claim envelope rather than assuming every available configuration has equal validation depth.

Compatibility And Upgrades

Versioned inputs and primary artifacts carry their contract version explicitly. Compatibility protects the documented author-run-inspect-report workflow:

Surface	Protected behavior
RunSpecs and campaign requests	Accepted schema versions retain their field meaning and units within the support window
Results	Documented core, grouped-study, and campaign contracts remain consumable by their supported tools
Installed tools	Documented CLI commands retain their purpose, while supported saved runs remain usable by Console, review, report, and bundled AI-skill workflows
Product lifecycle	Update and rollback preserve user-owned RunSpecs, runs, workspaces, configuration, and logs

The first externally supplied release establishes the initial compatibility baseline. From that baseline:

• patch releases continue to accept the stable inputs and protected artifacts of their minor release;
• a minor release directly supports its own contracts and those of the immediately preceding externally supplied minor release;
• older data may require stepwise migration through an intermediate supported release;
• a major release may introduce an explicitly documented migration boundary.

Compatibility includes meaning, units, and status interpretation, not only file readability. A validated model correction may intentionally change numerical results; the release must retain the contract meaning, pass the applicable scientific validation, and disclose the change.

A stable behavior scheduled for removal is announced in one release, retained with a visible warning in the next, and may be removed in the following release. When an older supported format requires conversion, the converter writes a new copy so the original remains available.

Retain the authored input, complete result bundle, product version, and any imported profiles or external datasets needed to reproduce an important study. Use python install.py status, python install.py doctor, and astraeus --version to identify the active installation before diagnosing a compatibility problem.

Local Data And Security

Runs, workspaces, configuration, and logs are stored in user-controlled locations under the current local, single-user operating model.

The Console binds to loopback by default. The Run Monitor also defaults to loopback and requires bearer-token protection for normal non-loopback use. Exposing either service can reveal RunSpecs, identifiers, paths, metrics, logs, and engineering results. Use an authenticated private network, tunnel, or HTTPS proxy appropriate for the data.

Maintain independent backups of important RunSpecs, results, reports, and configuration according to your organization's data policy.

Licensing Boundary

Astraeus is proprietary software. Rights to use, evaluate, deploy, redistribute, provide as a service, or access source code derive solely from the written terms supplied with the product or repository.

The repository's evaluation license permits only the stated internal evaluation, testing, and feedback use. Production or commercial use requires a separate written license. A standard product bundle is source-free: editable RunSpecs, examples, profiles, skills, and user documentation are included, while proprietary runtime code is delivered as compiled components. Source-code rights require an explicit written grant.

The installer verifies and installs a supplied target-specific bundle. A source-free installation verifies a signed local entitlement before starting new simulation or planning execution. Authorization can be provisioned online with an activation key, offline with a signed entitlement file, or through an invitation-based trial. Online activation and refresh cache signed authorization locally, so ordinary execution does not make a per-run service request.

astraeus license status reports the redacted authorization state and next action. If authorization ends, new execution is blocked while validation, preflight, help, Monitor, review, reporting, and existing result access remain available. See Installation and Lifecycle for the supported activation and renewal flows.

Requesting Support

Only the applicable written agreement defines support channels, response times, eligible users, production obligations, and any service-level commitment.

For a reproducible technical request, preserve and provide as appropriate:

• astraeus --version and the installer status/doctor output;
• platform, CPython, memory, and storage context;
• the smallest non-confidential RunSpec or campaign request that reproduces the behavior;
• run_manifest.json, metrics_summary.json, and relevant warnings;
• the exact failing command and its log or error text;
• whether the result reproduces with the nearest bundled example.

Remove credentials and unrelated confidential inputs before sharing evidence. Do not modify hashes, schema versions, or required artifact files to make a bundle appear healthy.