Skip to main content

Safety and limits

The assistant is built to be wrong loudly rather than convincing quietly. This page collects the guards that enforce that, the plan gating that bounds who can run what, the hard caps on every turn, and the known limitations of the underlying models. If a number ever looks too good, this is the page that says where to check.

Honesty guards​

These behaviors are enforced by the system contract and, where possible, structurally by the tools themselves:

  • Never substitute metrics. When the operator names a metric, the answer is that metric or an explicit statement that it is not computable, with the closest real metric offered as a labeled alternative. Demand-family metrics (served or unserved demand, congestion, blocked traffic) are refused by the statistics tools with a deterministic wrong_tool result that redirects to analyze_network_capacity; throughput is never a stand-in for demand.
  • Never invent numbers. Every figure comes from a tool result. Empty scopes, zero matches, and unavailable data are reported plainly with the reason.
  • Zero-match outages stop the analysis. If simulate_gateway_outage matches no gateways ("Germany" when the fleet has no German gateway), the answer says so and stops. No hypothetical gateway, no estimated traffic-at-risk figures.
  • Never dead-end on missing data. When a metric returns nothing because the fleet is not loaded into a replay, the agent names the missing input, loads the replay, states that it did, and continues. A genuine "cannot compute" is reported only when there is no fleet at all.
  • Saturation is not zero gain. 100 percent access availability does not mean new gateways add nothing; they still add contact minutes and redundancy. A "zero marginal gain" answer is allowed only when the optimizer proves it in the objective's own units (zeroGainProof); saturation of a different metric is reported as a saturationNote with the correct framing.
  • Grid candidates are labeled infeasible-by-construction. Hypothetical lat/lon grid sites ignore land and infrastructure feasibility, and that caveat is repeated wherever one appears among picks or rankings.
  • Unresolved names are reported, never guessed. Site names that do not resolve against the scene, the OneWeb gateways, or the GSaaS catalog come back as unresolved. Unknown saved-scenario names return the list of what exists.
  • Provenance is always disclosed. Synthetic assets carry a SYNTHETIC label, the demand surface is always called a synthetic population-weighted model, modeled rain is always called a P.618 approximation, and recorded or synthetic telemetry is never presented as live.
  • Exclusions and truncation are surfaced. Assets dropped for missing elements are counted with the exclusion rule. Trend windows that exceed the stored data are flagged as truncated, and the answer states the real covered span.
  • No bare recommendations. Siting and optimization answers carry ranked alternatives, rejected candidates with reasons, and the candidate ledger, so no option disappears silently. See Response contract.

Plan gating and guest limits​

The tool catalog itself is plan-scoped: the model can only call what the plan allows.

  • Guest sessions get the deterministic scene, statistics, and scenario tools with a limited query count, but no ML prediction tools and no integration bundle export.
  • Standard unlocks all five ML domains (SNR, traffic demand, weather impact, RF jamming, collision risk) at the bronze fidelity tier.
  • Pro and above unlock silver and gold; tools default to their preferred tier (silver or gold depending on the domain) and the runtime clamps down to the best tier the plan allows.

Tier requests fail loudly, not silently: an explicit request for silver or gold on a plan that does not include it returns an upgrade note instead of quietly serving a lower tier. Every forecast card states the model tier that actually ran. Bronze, silver, and gold are console plan concepts describing inference fidelity; the models themselves are the production prediction backends documented at /api/predictions.

Hard caps​

CapValueBehavior at the cap
Tool rounds per turn8The console requests one final synthesis turn so the answer is written from results already gathered
Tool result size60,000 charactersTruncated with an explicit inline marker stating how much was cut
Chart digest fed back to the model24 points per seriesThe full chart still renders for the operator
Pinned context refs8 per turnAdditional pins are not carried
Attachments4 per messageFirst-class context on the latest message only
Synthetic constellation size48 satellites per create_orbit_scenario callLarger requests must be decomposed
Candidate site comparison2 to 8 sitesEnforced by compare_candidate_sites
Ground network station budget8 picks by default (max_stations)The greedy search stops after the budget
Leave-one-out satellite value40 satellitesanalyze_network_capacity focus satellite_value is skipped above 40 (the analysis is quadratic in fleet size) with guidance to scope the scene down via a filter or analyze a smaller uploaded or synthetic constellation

Known limitations​

Stated plainly, because every answer is scoped by them:

  • The demand surface is synthetic. Demand, unserved demand, congestion, and beam loading all derive from a deterministic population-weighted model, not real subscriber traffic. Every demand-coupled answer discloses this, and the confidence block downgrades for it.
  • Beam RF math is an operational approximation. Beam patterns use a parabolic 12*(theta/theta_3dB)^2 rolloff and DVB-S2X MODCOD efficiency tables. Good for trades and rankings; not a substitute for a payload-grade RF analysis.
  • Weather is a deterministic approximation. Rain coupling uses a P.618-style attenuation model applied to exactly the rain field the operator requested. It is a what-if instrument, not a forecast and not measured weather.
  • Answers are scene-scoped. Every engine evaluates the currently loaded scene: the fleet, catalog groups, uploads, and synthetics that are actually present. When a question implies the whole real-world network, the answer says the analysis covers only the loaded simulation.
  • Replay depth is limited. The demo replay window is about one hour, so a "last 24 hours" trend is truncated to what exists, and the answer says so.
  • No geographic overlays yet. Coverage, demand, and beam footprints come back as numbers, tables, and insight cards, not shaded map regions; "heatmap" requests get a ranked per-group breakdown and an honest note. There is also no geographic gateway filter: regional gateway questions are answered with camera framing plus named selections, stated as exactly that.
  • Excluded factors are constant. The deterministic engines never model cost, licensing and regulatory constraints, or terrestrial backhaul capacity, and weather is excluded whenever an evaluation ran clear-sky. These appear in every confidence block as excluded factors.

Turn safety​

Two more properties bound what a turn can do:

  • Cancellation is safe and honest. Stopping a turn keeps what already happened (the operator watched it) and appends a plain "Stopped." marker. Nothing is silently discarded or silently rolled back.
  • Mutations are reversible and inspectable. What-if mutations apply to the scene model, not to any real system; list_scenario shows what is active and reset_scenario restores the baseline. The assistant controls a simulation and its console, nothing beyond it.

Where to go next​