Object Explorer

The Object Explorer is the typed instance browser onto the Nexma DataStore. Where the map shows objects in space, the Object Explorer shows them as structured records — query, filter, sort, and inspect every object by type. It is driven entirely by the active ontology, so the tabs, columns, and types you see are the ones your world is built from.

Core concepts

The Object Explorer is the tabular view onto the Nexma DataStore. It reads the same versioned files every other surface renders from — there is no separate index to keep in sync.

• Typed by the ontology. Each entity type in the active ontology becomes a tab; each property becomes a column. Load a different ontology and the Explorer reorganizes around it, with no configuration.
• Instance-level. The ontology defines the types; the Explorer browses the instances — every transformer, valve, waypoint, or zone currently in the DataStore.
• A view, not a copy. Rows are live reads of DataStore files. Edits and branch switches reflect immediately, because the Explorer is a renderer over the same source of truth.
• Org-scoped. The Explorer is scoped to your organization. You browse objects within projects your org owns, governed by Permissions.

How it works

The Explorer organizes objects the way the ontology organizes the world.

Select a tab to list every instance of that entity type. Filter by any property — status = planned, capacityKva > 500 — or by spatial predicate. Open a row to inspect the full record, follow its typed relationships to connected objects, and jump to its location on the globe.

Querying and filtering

The Explorer turns the DataStore into a queryable table without leaving the typed model.

• Filter by property. Narrow a list by any typed field, including enums and numeric ranges.
• Filter by geometry. Restrict to a drawn area or an existing zone, returning only objects within it.
• Follow relationships. From any object, traverse its link types to the entities it serves, contains, or depends-on.
• Sort and group. Order by any column and group by tier or type to read the world at the altitude you need.

Every filtered view is a query against the live DataStore. Switch branches and the same query re-runs against that branch's state — useful for comparing a scenario to Main.

High-cardinality handling

Real projects hold large object counts — a national network can carry millions of instances of a single type. The Explorer is built for that scale.

• Paged reads. Lists page through the DataStore rather than loading a whole type at once, keeping reads predictable and low-latency.
• High-cardinality gate. When a type exceeds a safe threshold, the Explorer requires a filter before materializing rows, so you narrow to a working set instead of attempting to render everything.
• Query-first, not scroll-first. Filters and spatial predicates run server-side against the store, returning only the matching, typed features.

Where to go next

• The Ontology — the typed model that drives the Explorer's tabs and columns.
• Nexma DataStore — the single source of truth the Explorer reads from.
• Spatial Branches — run the same queries against any branch's state.
• Permissions — how org scope and authorities gate what you can browse.