Determinism
Determinism in Constellation OS is not an implementation preference; it is the property that makes the product trustworthy. An operational conclusion is only worth what its evidence trail is worth, and an evidence trail is only checkable if re-running the analysis produces the same numbers.
The contract
Every analysis engine in the console is deterministic and pure:
- Fixed steps. Time-window evaluations (coverage, passes, availability, siting) walk explicit windows at explicit step sizes, and the answer states both.
- No hidden randomness. There is no random weather, no stochastic jitter, no sampling that varies between runs. The one rain model is a deterministic ITU-R P.618 approximation driven by explicit rain-rate fields.
- Stable ordering. Iteration order, tie-breaking, and exclusion rules are fixed, so results do not depend on registry insertion order.
- Pure what-ifs. Scenario engines mutate a copy of the scene snapshot and reset cleanly; the live fleet is never edited by a hypothesis.
Same inputs, same numbers, every time. The console's test suite includes determinism tests to hold the line.
What determinism buys
Reproducible analyses
A coverage percentage quoted in a design review can be regenerated to the digit weeks later. Trend queries state their window and coverage, so two people asking the same question of the same window get identical answers rather than answers that depend on when they asked.
An auditable insight card trail
Analytical answers render as insight cards carrying the headline value, the scope line (operator, filter state, timeline mode, timestamp), the method, the exact calculation, sample sizes, exclusions with the rule that excluded them, and the actual participating assets. A card is only worth attaching to a decision because the deterministic engine behind it will produce the same card again. Reports inherit this: captured analyses keep their provenance, and charts keep the exact tool call that generated them so they can be regenerated rather than pasted. See Reports.
Saved scenarios that replay
A saved scenario persists the literal injected TLE text and station tables, the sim epoch, the what-if mutations, and the full evaluation config (window, step, elevation mask, weather). Because the engines are deterministic, restoring the scenario at its saved epoch reproduces every number in the original run. See Simulations and scenarios.
A repeatable agent
The assistant runs with temperature 0, so tool routing is repeatable across turns: the same question against the same scene plans the same tool calls. The language model never computes a number; it decides what to run, and the deterministic tools and named prediction models decide what is true. Simple requests short-circuit through a local intent layer into the same engines without touching the model at all. See How it works.
The boundary with ML
Trained models are not deterministic engines and are not presented as such. Prediction outputs carry their model version, tier, serving backend, and input window (on the live path, a full provenance block), and forecasts display their age. The discipline is separation, not pretense: deterministic numbers are reproducible, model outputs are attributable. See Predictions API.
The boundary with live data
Determinism applies to computation, not to the world. Live telemetry keeps arriving, so "the same question" in live mode is only identical if the underlying window is; replay mode and saved scenarios exist precisely to pin the data side down. Prediction caching follows the same spirit: forecasts refresh on 60-second buckets, so identical questions within a bucket get identical answers instead of racing the cache.
Why this matters for a control plane
A control plane for physical assets must be able to answer "why did the system say that?" months later, to a customer, a regulator, or an incident review. Deterministic engines, provenance-carrying predictions, and replayable scenarios are what turn that answer from archaeology into a lookup.