Assets
The Assets panel is the browser over the console's unified asset registry: one scene graph that holds every object on the globe regardless of where it came from. The operator fleet, third-party ground station sites, catalog constellations, your uploads, chat-ingested assets, and synthetic what-if objects are all the same kind of thing: an asset with provenance and capabilities.
This design has one rule with real consequences: provenance is metadata, never behavior. Nothing downstream branches on where an asset came from. What an asset can do (telemetry, links, predictions, propagation, coverage analysis, editing) is derived from its data, and every surface, from the globe renderer to the assistant, consumes those capabilities. Upload a TLE and your satellite animates with exactly the same propagation and interpolation as the operator fleet.
The Assets panel showing the Satellites, Gateways, and Data centers segments, with vendor groups, provenance badges, and visibility toggles.
Sources
| Source badge | Origin | Typical contents |
|---|---|---|
oneweb | Operator fleet from the platform API | Satellites, gateways, feeder links, live and replay telemetry |
gsaas | Ground-station-as-a-service catalog | Provider sites (KSAT, AWS Ground Station, and others), grouped by vendor |
catalog | TLE catalog constellation groups | Starlink, Kuiper, Iridium NEXT, GPS, Galileo, weather constellations, and more |
import | Files you uploaded | Satellites and ground stations from TLE, CSV, JSON, NDJSON |
chat | Ingested through the assistant | Same as import, attached in conversation |
synthetic | Generated what-if objects | Mission-sandbox satellites, Walker constellations, candidate ground stations |
Capabilities and what each unlocks
Each asset carries a capability set derived from its data. Capabilities decide which analyses the entity card and the assistant offer for it:
| Capability | Meaning | Unlocks |
|---|---|---|
| Telemetry (live / recorded / none) | Real operator samples, recorded or synthetic samples, or display-only | Health analytics, utilization statistics |
| Links | Participates in link topology | Link budgets, link statistics |
| Predictions | Production models are trained for its links | The predictions panel and prediction tools (operator fleet only today) |
| Orbital elements | TLE-backed propagation | Orbital elements, ground track, pass prediction, coverage analysis, beam planning, service availability |
| Coverage analysis | Orbital elements or a ground site | Access windows, siting, network optimization |
| Editable | User-owned | Rename, delete, group visibility control |
| Synthetic | Generated, never real hardware | Permanent provenance flag in every answer |
Catalog constellation objects are the honest edge case: real orbits, display and geometry only. They propagate, they can be selected and inspected for orbital elements, but they carry no telemetry, no links, and no predictions, and the console never pretends otherwise.
Visibility and groups
The browser organizes assets into three segments (Satellites, Gateways, Data centers), then by vendor or dataset within each. Curated operator vendors lead, unknown constellations sort alphabetically, and user-supplied groups (Imported, Chat, Synthetic) trail.
- Toggle a whole group or an individual asset; hidden assets leave the globe but stay in the registry.
- Catalog constellations toggle as groups from the constellation catalog, organized by category (Commercial LEO, Navigation, Weather and Earth, and so on).
- Visibility state is remembered per asset, and survives re-imports (see dedupe below).
- Group visibility is a rendering decision, not a filter: analytics scope follows the active filters, and the assistant reports exactly which assets an action matched.
Dedupe on re-import
Re-importing an identical TLE (re-uploading a file, re-running a chat scenario) updates the existing asset in place instead of minting a duplicate. The scene keeps one asset per physical orbit definition; the asset's id, selection state, and visibility (including a deliberate hide) survive the re-import. Genuinely new records are added and made visible immediately.
Editing, renaming, deleting
Assets with the editable capability (import, chat, synthetic) can be renamed and deleted from the browser. Operator fleet, GSaaS, and catalog assets are read-only: they mirror an authoritative upstream source, and the console does not fork them.
Provenance in answers
Every assistant answer that touches an asset states its provenance. A coverage number computed for a synthetic constellation says so; a statistic scoped to imported assets names the dataset. This is deliberate: the registry makes all assets equal in capability, so provenance labeling is what keeps synthetic and real from blurring.
Common workflows
| Task | How |
|---|---|
| Browse everything on the globe | Rail, Assets panel |
| Import files | Assets panel import, or drop a file into chat and ask the assistant to ingest it |
| Show Starlink next to your fleet | Constellation catalog toggle, or ask "show Starlink" |
| Hide all synthetic assets after an experiment | Toggle the Synthetic group off, or delete them |
| Verify an import | Ask "how many assets are on the globe by source" or select the new assets directly |
| Rename a synthetic satellite | Edit action on the asset row |
Example scenarios
Comparing against a competitor constellation. An analyst toggles on the Starlink catalog group next to the operator fleet, filters to a matching altitude band, and asks the assistant for a per-constellation breakdown. Catalog objects contribute orbits and counts; the assistant is explicit that they carry no telemetry.
A recurring planning file. A mission planner re-uploads the weekly TLE drop from their flight dynamics team. The 40 unchanged satellites update in place, keeping their groups and visibility; the two new ones appear on the globe immediately with fresh provenance badges.