God’s Eye View: a globe, AI interaction and honest data boundaries
God’s Eye View architecture: shared constructors, injected sources and owned cleanup
Trace scene, controls, data and tools through startup and teardown, while distinguishing reusable contracts from page-scoped standalone state.
What you will learn
- Composition starts inactive
- Cleanup order encodes a dependency
- Reusable controllers do not erase standalone constraints
Before you start
- Basic JavaScript and JSON
- Understanding of coordinates and source timestamps
Explain how source records, validation, layer presentation and optional AI interaction differ, using synthetic examples.
Key takeaways
- Construction is inactive until start.
- Teardown order preserves data while controls cancel restoration.
- A reusable controller does not prove a multi-viewer standalone shell.
Composition starts inactive
The application export accepts four constructors: scene, controls, data and tools. Its guide says import and construction do not create a viewer or start requests; start begins the ordered initialization. Earlier component objects and a shared abort signal are passed to later constructors.
Configuration belongs to caller closures. The lifecycle controller does not discover modules or interpret environment variables and provider endpoints. This separation makes it possible to supply a synthetic source for a test without rewriting the globe renderer or pretending a test fixture is live data.
Cleanup order encodes a dependency
Startup follows scene, controls, data, tools, but teardown is tools, controls, data, scene. It is not simply the reverse list: controls must cancel restoration while the data manager and viewer still exist. Within a phase, registered cleanup callbacks run in reverse order.
Constructors should register cleanup immediately after acquiring a resource and before awaiting more work. Destroy aborts the shared signal, waits for an in-flight constructor and runs registered cleanup. A dependency that ignores cancellation can delay teardown; returning a promise does not make resources disappear instantly.
Reusable controllers do not erase standalone constraints
The guide says repeated start and destroy calls reuse their respective promises, and destruction is terminal. Ready means constructors returned, not that every background feed has completed. A frozen component snapshot is shallow: component instances themselves remain mutable.
The standalone implementation still has page-scoped owners and allows one standalone app per page, with reload required to start again after shutdown. It is not automatically a removable multi-viewer widget. We inspected the controller and guide but did not execute its browser lifecycle or shared renderer.
Decision guide
| Criterion | Option A | Option B |
|---|---|---|
| Best when | You need predictable behavior and easy auditing | You need adaptive optimization and have reliable telemetry |
| Main risk | May leave performance on the table | Can become difficult to explain or debug |
Implementation steps
- 1
Map the four constructor dependencies.
- 2
Register cleanup when each resource is acquired.
- 3
Forward cancellation through awaited work.
- 4
Test terminal destruction separately from feed readiness.
Copy-ready example
{
"architectureWorksheet": true,
"startOrder": [
"scene",
"controls",
"data",
"tools"
],
"stopOrder": [
"tools",
"controls",
"data",
"scene"
],
"readyMeansAllFeedsLoaded": false,
"standaloneInstancesPerPage": 1,
"lifecycleExecuted": false
}Frequently asked questions
Is teardown exactly reverse startup order?
No. Controls are stopped before data so restoration can be canceled safely.
Does ready mean every public feed finished loading?
No. The guide defines it as all constructors having returned.
Sources
- God’s Eye View / docs/APPLICATION.mdSource checked 2026-09-14
- God’s Eye View / src/app/application.jsSource checked 2026-09-14
- God’s Eye View / src/services/application.jsSource checked 2026-09-14
- God’s Eye View / docs/CURRENT-STATE.mdSource checked 2026-09-14