System overview
Varaha Constellation Designer is a Rust workspace of focused crates plus a web visualization application. The split exists so each domain evolves independently, and so that one crate owns each kind of truth.
One rule governs the whole architecture: the Rust backend owns all physics, and the web frontend performs no orbital mechanics. The viewer renders results that the backend computed. A number that appears on the globe was not calculated in the browser.
Analysis flow
The diagram shows requirements entering at the top through one of three design paths, converging on a single constellation definition. That definition is propagated once into a time-indexed set of satellite states, which then fans out to the three analysis families. All of them converge again on a common export bundle, which feeds either the globe viewer or an external toolchain.
The important property is the single convergence point in the middle: coverage, link, and scenario analysis all read the same timeline, so a change to an orbit ripples through all three without anything being re-modeled by hand.
Data ownership
Each kind of data has exactly one owning crate. Crates may read another’s output but do not redefine it.
| Data | Owner |
|---|---|
| Units, time types, constants, frame tags | orbitforge-core |
| Coordinate transforms and propagation | orbitforge-orbits |
| Satellite and constellation definitions | orbitforge-constellation |
| Timeline state | orbitforge-sim |
| Coverage statistics | orbitforge-coverage |
| Link statistics | orbitforge-link |
| Access, AER, Doppler, ISL topology | orbitforge-scenario |
| CZML, GeoJSON, and file-format schemas | orbitforge-io |
| HTTP contracts | orbitforge-api |
| Globe rendering | orbitforge-web |
Everything may depend on orbitforge-core. Nothing depends on orbitforge-web.
Interfaces
Three interfaces expose the same engine, and they are not equivalent in every detail.
| Interface | Crate | Intended user |
|---|---|---|
| Command line | orbitforge-cli | Engineers working interactively or scripting |
| HTTP API | orbitforge-api | Services, the web UI, and integrations |
| Rust libraries | every crate | Callers embedding the engine |
The CLI and the HTTP API do not use identical vocabulary. The CLI spells the default
propagation model two-body with a hyphen; the API field is propagation_model and
spells the value two_body with an underscore. Treat the two surfaces as separate
contracts and read the reference page for the one you are using.
Time and frames
User-facing scenario times are UTC. Internally a deterministic epoch plus elapsed seconds is used, so a run is reproducible.
Every simulation records its start time, step size, duration, propagation model, Earth model, coordinate frame, and software version. That metadata is what makes a result auditable months later.
Supported frames are ECI, ECEF, and LLA. Frame-conversion fidelity is selectable: a fast GMST-only path, or a full IAU-76/FK5 path with leap seconds that also rotates SGP4 TEME output into GCRF.
Decision records
Architectural decisions and their consequences are recorded rather than remembered.
main (pre-release)