Speaking to the Map

God's Eye View's voice feature is not a second intelligence system placed above the globe. It is a language interface to the sources, scopes, camera owners, and rendering operations already in the application. This chapter traces how a spoken request becomes either an answer, a controlled map mutation, or an explicitly bounded failure. The result is a useful test of the whole design: if voice is to be trusted, fluency must never outrun the state and evidence underneath it.

Voice controls existing state through a narrow boundary

The session begins with a security decision. The browser asks the local server for a short-lived Realtime client secret. The server holds the real OPENAI_API_KEY, constructs the session configuration, and sends the secret back. The browser then establishes the audio connection to OpenAI over WebRTC. The long-lived private key never needs to enter the page, while the page still receives a real-time conversational channel.

That arrangement does not make the feature autonomous. The server supplies a fixed set of 28 tools covering the application's existing surfaces: navigation, layer visibility, display settings, context, tracking, analysis, camera motion, CCTV, cockpit, radio, scenes, and annotations. The model is instructed to use those tools rather than inventing operations or arguments. A request to “show the datacenter layer” is different from a request to turn that layer on. A request to “open Contacts” is different from opening the parent Context panel. These distinctions are part of the tool contract.

The tool surface separates reading from changing. A scene-context request can gather the selected entity, the basemap target, active layers, place labels, nearby places, view scale, and other structured context. An analyst query can answer a question about loaded aircraft, ships, fires, or earthquakes. A tracking action changes camera ownership and selects a stable entity. A layer action changes visibility. A camera action moves the view. The model may combine several operations when the user asks for several changes, but each operation returns an explicit result.

That result is the voice feature's real authority. The system is designed to confirm only what actually happened. If a layer was unavailable, a camera move was refused because Cockpit owns the view, or an analysis could not answer from its loaded data, the spoken response must say so. It must not treat the model's intention to call a tool as evidence that the tool succeeded. This matters especially for camera actions: a command such as “fly there” can release tracking, start a navigation transaction, and then be superseded by a newer user action. The resulting state, not the original sentence, determines the confirmation.

A multi-part request makes that rule more demanding. “Switch to night vision, show flights, and take me to the nearest aircraft” is not one indivisible act: it touches visual state, layer visibility, navigation, and selection. The voice controller must let the relevant operations settle, preserve their ownership boundaries, and report a mixed outcome if one succeeds while another fails. It cannot confirm the whole sentence because the model began the sequence, nor can it silently discard a successful first operation because a later one was refused.

Cancellation is part of the control plane, not just a way to stop waiting.