Runtime

Black-Box Visual Audit and Future Consequence-Visualization Specification for the IARPA.org Planetary Atlas

Report summary

The deployed IARPA.org Planetary Atlas presents itself as an independent fictional educational simulation with a browser-local deterministic simulation core. In the audited session, the site explicitly reported that WebGL was unavailable and that it had switched to its accessible two-dimensional glo

Status
Research archive item
Category
Runtime
Length
6,187 words
Reading time
29 minutes
Report type
evaluation

Key topics

  • Runtime
  • AI
  • Privacy
  • Semantic Systems
  • Research Archive
  • Strategy
  • Audit
  • Architecture

Research provenance

Archive status
Research archive item
Content identity
sha256:49bc881ded89369a8e619c9999e5de16eea9a09d5ac2d475d73c51a639c5771a

For citation, use the report title and canonical URL. Archival presence does not establish authorship or promote report statements into portfolio evidence.

Source availability: 49 citation markers in the source export have no recoverable source links. Those markers are omitted from this reader; any supplied bibliography and ordinary links remain. Check the original sources before relying on the cited claims.

This page renders the archived Markdown as safe, formatted HTML. It is background research and does not become a portfolio claim without evidence review.

Full report

On this page

Executive summary

The deployed IARPA.org Planetary Atlas presents itself as an independent fictional educational simulation with a browser-local deterministic simulation core. In the audited session, the site explicitly reported that WebGL was unavailable and that it had switched to its accessible two-dimensional globe renderer. The public documentation also says the deterministic browser-local simulation creates outcomes first, while OpenAI may provide only a bounded narrative brief that cannot change numeric state, and that a deterministic fallback exists for consequence text. Those statements are important because they mean event visuals are supposed to be architecturally separable from any AI service.

The strongest black-box evidence for the current visual gap is a documented preview/commit mismatch. The site says that Preview on globe “shows the abstract footprint and temporarily fades the selected supplied planet-state image over the regular Earth texture without changing simulation state.” By contrast, the public text does not make a comparable promise that a successfully created event commits a persistent local effect, footprint, symbol, leader line, blurb, and world-state layer into the live renderer. That gap is the most plausible reason visuals can feel missing, too subtle, or disconnected: the preview path is documented, but the persistent post-create consequence path is not.

Asset evidence also points in the same direction. In the audited session, the event UI exposed two image links, and those links fetched only the normal photographic Earth texture at /assets/atlas/earth-satellite-high-quality.png and one planet-state image at /assets/atlas/planet-states/natural-earth.png. No other alternative planet-state textures were directly requested in the accessible session I could observe. That does not prove the remaining supplied textures are absent, but it does show that they were not surfaced as eagerly loaded or plainly requested assets during this pass. If the remaining 15 textures are only lazily discovered after niche interactions, or if only one selected preview texture is ever loaded, first-use failures, weak transitions, or “nothing happened” moments become very plausible.

The current public copy also suggests that today’s visual grammar is intentionally generic. Historical nuclear events are described as abstract animations rather than physical effects, and the scenario system describes rings, intensities, and textures as normalized educational visuals, not operational calculations. The site further says abstract event symbols are “approximate context markers, never targeting graphics.” That is consistent with a conservative, safety-bounded design, but it also explains why users may perceive the visuals as insufficiently event-specific unless the renderer adds a richer, distinctly non-operational symbolic language.

My recommendation is therefore not to replace the site’s safety posture, but to modernize the consequence renderer around five hard guarantees: every created event must paint an immediate local effect without waiting for OpenAI; every event must materialize as a selectable symbol with a readable connected blurb and dossier; every event must leave a persistent footprint; justified events must also drive a gradual, alpha-composited planet-state layer over the normal Earth texture; and the same logic must run in both WebGL and the accessible 2D fallback. That redesign is fully compatible with the Atlas’s published deterministic-first architecture, local-browser posture, and non-operational safety boundaries.

Research method and test environments

This audit was performed under strict black-box constraints. I did not claim access to source code, repositories, build logs, package files, or server-side internals. The evidence base came from the deployed site itself, public help and policy pages, directly fetched site assets, and the rendered accessible session exposed by the browser crawler. Because the crawler environment could not exercise rich pointer-driven JavaScript controls like a live desktop browser with DevTools, I treat some conclusions as high-confidence inferences from observable behavior rather than exhaustive runtime proofs.

The executed environments and what each one revealed are summarized below.

EnvironmentWhat was observedAudit value
Accessible crawler session on the homepageThe site reported “WebGL is unavailable” and switched to its accessible two-dimensional globe renderer. The page exposed the world mode controls, event creation UI, replay controls, HUD, consequence brief panel, and help text.Established the fallback renderer, visible control surfaces, and the documented event-creation flow.
Direct image fetch from image links exposed in the event menuThe session fetched the base photographic Earth texture and one planet-state overlay image named natural-earth.png.Established concrete asset-loading evidence for what was actually requested in this pass.
Public policy and help pagesAccessibility, privacy, and safety pages documented reduced motion behavior, the non-WebGL fallback, local preference storage, and the site’s exclusion of operational harm details.Confirmed architecture constraints and accessibility/safety boundaries the redesign must preserve.

For a subsequent manual pass, the minimum additional matrix should include desktop Chrome, Firefox, and Safari with full browser DevTools; mobile Safari and Android Chrome; one low-memory device class; one reduced-motion OS profile; and one forced-WebGL-context-loss test. Those follow-up environments are necessary because the public site already documents both WebGL and 2D rendering paths, reduced-motion behavior, and replay controls, and because modern canvas/WebGL systems need explicit handling for context loss, preload/decode timing, and device-class adaptation.

Observed evidence and findings

Asset-loading evidence

The most concrete asset evidence surfaced in the event creation panel itself. In the audited home session, the modal-like event area displayed two image links next to the text “Normalized consequence intensity 1.00×” and “Illustrative globe state Natural Earth.” Clicking them fetched the regular Earth texture and a single planet-state texture. The fetched URLs were:

  • /assets/atlas/earth-satellite-high-quality.png
  • /assets/atlas/planet-states/natural-earth.png

That is useful evidence for two reasons. First, it confirms that the site already has at least one separate planet-state image asset and already understands the concept of compositing a supplied state image over the regular Earth texture during preview. Second, because no additional supplied planet-state textures were directly surfaced in this session, there is no observed proof that the remaining alternative world-state images are preloaded, requested on startup, or requested immediately after event creation in the current implementation. In a consequence system meant to feel immediate, that is a likely weak point. MDN and web.dev both recommend explicit preload/decode strategies when assets are needed very early in the rendering lifecycle, precisely to avoid late discovery and empty-frame behavior.

Observed event visual behavior by event type

What I could directly verify is that the current public UX advertises a generic fictional-event preview pipeline: the deterministic local simulation creates the outcome first; the user can preview on the globe; the preview is qualitative and non-physical; and the preview temporarily fades the selected supplied planet-state image over the regular Earth texture. That behavior is documented for the scenario system broadly, including advanced assumptions for nuclear and radiological emergencies, space weather, asteroid impacts, climate warming, fire, earthquakes, water disasters, volcanoes, storms, biological events, and dependency scenarios.

What I could not directly verify in the black-box session is any currently distinct rendered sequence for the user’s requested families such as nuclear-facility emergency versus detonation, solar flare versus asteroid impact, wildfire versus drought, or earthquake versus flood. The publicly visible text did not expose type-specific image requests, type-specific symbol glyphs, or type-specific consequence layers for those families during this pass. That absence is itself a meaningful finding: the public evidence points to a shared qualitative preview mechanism, not to a fully differentiated consequence-visualization system.

The one currently differentiated event family that the homepage foregrounds is historical nuclear activity. The reviewed-history section states that every cataloged test and wartime detonation is shown, but it immediately qualifies the visual by saying the animation size is abstract and not a blast, fallout, casualty, damage, or targeting radius. That wording is sensible from a safety perspective, but it also supports the user’s concern that existing visuals may look too abstract or too weakly coupled to the event unless they are supplemented by richer symbolic, local, and persistent consequence layers.

Event blurb and leader-line visibility findings

The public documentation says that selecting a dot or event draws a leader line to a compact label, and that offscreen event pointers terminate on the visible globe edge rather than floating outside the map. Those are solid foundations. The same page also exposes the relevant UI surfaces that can interfere with that compact label: a world mode panel, a timeline/playback control area, a consequence brief panel, a movable HUD that can show or hide panels, and a right-click or keyboard-opened fictional event menu tied to globe focus.

What is not publicly documented is any collision-avoidance guarantee for those labels. The site promises that panels are movable and that “Focus globe” can hide nonessential panels, but that is user-managed mitigation, not automated annotation layout. In a panel-dense interface, that means a compact label may be technically present yet visually compromised by overlap, edge clipping, or poor placement relative to the menu, world-mode controls, or playback HUD. The current architecture therefore appears to have leader-line semantics but no explicit occlusion-management contract.

Reproduction steps for missing or weak effects

A black-box reproducer for the current likely failure mode is straightforward. Load the homepage, ensure the globe is focused, and open the fictional event menu using the site’s documented right-click, double-click, or Shift+F10 interaction. Choose a scenario preset and qualitative parameters, then run Preview on globe followed by Create fictional event & analyze. If the preview displays a temporary footprint and a temporary state-image fade, but the created event does not leave behind a visible symbol, pinned selection state, readable connected blurb, persistent footprint, and committed world-state transition, the visual-commit defect has been reproduced. That step sequence comes directly from the site’s published help and event-creation flow.

A second reproducible weakness concerns AI separation. The consequence brief panel says OpenAI may supply bounded narrative only, that the deterministic engine remains authoritative, and that a deterministic brief exists as an alternative. If the user can create an event while the AI consequence service is unavailable, but no immediate on-globe effect appears until a brief is generated or a remote service recovers, the implementation is violating the site’s own published design contract.

A third reproducer concerns annotation clashes. Open the world mode panel, the timeline controls, and the consequence brief panel simultaneously, then trigger event creation near the screen quadrant most occupied by those panels. If the event label or blurb appears underneath any of those surfaces, is clipped by the viewport, or detaches from the symbol without a rerouted leader line, the readability/occlusion defect has been reproduced. The Atlas’s panelized HUD and its current “compact label” pattern make this especially likely without a dedicated placement engine.

Root-cause analysis

The highest-confidence root cause is a preview-to-persistent-state gap. The public copy explicitly documents a preview that temporarily fades a selected supplied planet-state image over the regular Earth texture and says that preview does not change simulation state. That language strongly suggests a helper preview renderer is already present. What is missing from the public contract is a corresponding persistent render path that automatically commits a created event into immediate local FX, a persistent footprint, and a durable world-state layer. If the product currently relies on preview logic instead of a proper consequence-state machine, missing or weak post-create visuals are exactly what users would observe.

A second likely root cause is insufficient texture lifecycle management. In the audited session, I observed only the base Earth image and natural-earth.png. If the alternative 15 supplied textures are not preloaded, decoded, and staged before first use, then a create-event action can easily race ahead of image readiness. That pattern causes late transitions, blank frames, or fallback-to-base-Earth no-ops. Web guidance is very clear that preload, decode(), and createImageBitmap() are appropriate tools when images must be ready at the moment of interaction, and that off-main-thread preparation is preferable for heavier image work.

A third likely root cause is over-reliance on generic symbolic language. The site’s own phrasing emphasizes approximate markers, normalized intensities, and non-physical educational visuals. That is correct and desirable from a safety standpoint, but it also means the current renderer may be using one abstract footprint vocabulary for many event families. If detonation, facility emergency, geomagnetic storm, wildfire, drought, earthquake, flood, tsunami, volcano, and severe storm all collapse into the same ring-and-fade grammar, users will reasonably read the visuals as disconnected from the selected scenario. The fix is not to become operational or realistic; the fix is to become more semantically distinct while staying synthetic and non-targetable.

A fourth likely root cause is annotation architecture that is label-capable but not occlusion-aware. The site already has a leader-line concept and offscreen clamping, but it also has many concurrent movable HUD panels. Without a layout manager that treats those panels, the context menu, and mobile safe areas as occluders, compact labels and blurbs will inevitably disappear behind controls or choose poor quadrants. WCAG guidance and the site’s own accessibility commitments both push toward visible focus, reflow, reduced motion, and narrow-width usability; a consequence labeling system needs the same rigor.

A fifth, narrower root cause is possible false coupling between visual success and narrative success. The documentation is crystal clear that OpenAI may explain deterministic results but cannot change the underlying state, and that the model is optional for narrative. If the site presently treats “brief completed” as the moment to fully reveal a consequence, users will experience exactly the failure described in the prompt: event visuals missing or delayed whenever the AI layer is slow, unavailable, or disabled. The remediation here is straightforward: event rendering must commit synchronously from local state, and AI narration must be treated as an optional parallel enhancement only.

Consequence-visualization architecture and state machine

Target architecture

The redesigned system should be built around a single authoritative VisualConsequenceState per created event and one aggregate PlanetVisualState for the globe. The Atlas already has the right philosophical ingredients—browser-local authority, a supplied planet-state image concept, a restore/replay control surface, and both WebGL and 2D renderer paths. The missing piece is a renderer contract that guarantees a committed visual outcome for every event creation.

The layer stack should be implemented as follows:

Topmost DOM/SVG annotation plane
  - Pinned event blurbs
  - Leader lines
  - Offscreen edge pointers
  - Focus rings and keyboard highlights

Interactive event-symbol plane
  - Accessible hit targets
  - Shape-coded event glyphs
  - Selected/pinned halos
  - Status badges

Transient local-effects plane
  - Flash, glow, rings, arcs, sparks, smoke veils, service-pressure pulses
  - Strictly qualitative and synthetic
  - Time-bounded and replayable

Persistent footprint plane
  - Surface stain, crater, scorch zone, plume veil, drought field, flood field, crack field
  - Independent from transient FX
  - Slowly decaying or recoverable

Planet-state consequence overlay plane
  - Current consequence texture
  - Next consequence texture
  - Alpha-composited over the normal Earth texture
  - Controlled by transition progress and overlay opacity
  - Masked by globality and geographic influence

Base Earth plane
  - Normal photographic Earth texture

Optional atmosphere/cloud/orbital accents
  - Existing atmosphere/effects toggle compatibility

This architecture follows standard web rendering guidance: use preloaded and decoded textures; prepare them asynchronously where possible; keep the heavy compositing in canvas/WebGL; preserve a separate DOM/SVG plane for readable, accessible annotation; and treat WebGL context loss as a recoverable state rather than a fatal failure.

Compositing rules

Every created event should populate these fields at minimum:

baseEarthTexture
currentConsequenceTexture
nextConsequenceTexture
transitionProgress
overlayOpacity
localInfluenceMask
transientEffectQueue
persistentFootprint
createdAt
activationDuration
decayProfile
recoveryState
selectedEventId
reducedMotionMode
rendererMode
assetLoadStatus

The blend model should stay simple and interpretable:

  • baseEarthTexture is always present.
  • currentConsequenceTexture and nextConsequenceTexture are alpha overlays only.
  • transitionProgress moves from 0 to 1 gradually over visual time.
  • overlayOpacity is the qualitative consequence strength.
  • localInfluenceMask controls how much of the overlay is globally visible versus regionally concentrated.
  • persistentFootprint survives the transient FX and can outlast the symbol if the event is archived.
  • recoveryState can swap nextConsequenceTexture to a recovery-oriented image without erasing the footprint instantly.

The implementation should use standard WebGL blending primitives, but should keep the normal Earth visible under most overlays by design. On the 2D path, the same effect can be achieved with offscreen compositing and globalAlpha, preserving visual parity without requiring identical internal plumbing.

Opacity model

The overlay should be driven by qualitative variables exactly as requested, but it should do so through bounded aesthetic bands rather than through any physical or operational model. A safe and effective internal model is:

overlayStrength =
  scaleBand
× persistenceBand
× preparednessModifier
× responseCapacityModifier
× infrastructureResilienceModifier
× environmentalPressureBand
× cascadeComplexityBand
× globalityBand

Where more preparedness, stronger response capacity, and higher resilience reduce apparent overlay strength, while scale, persistence, environmental pressure, and cascade complexity increase it. This should be clamped to a narrow range for localized events and a broader—but still translucent—range for systemic events. The purpose is not prediction. It is visual legibility and internally consistent consequence storytelling. The site already frames these scenario controls as qualitative educational indices rather than physical models, so this use is aligned with the product’s published safety posture.

I recommend these global opacity bands:

Scenario classPlanet-state overlay alpha
Very localized0.04–0.08
Localized but persistent0.08–0.14
Regional/systemic0.14–0.28
Near-global/high-cascade0.28–0.45
Extreme fictional planetary stress0.45–0.60

Those bands intentionally keep the normal Earth texture visible beneath most overlays.

Complete visual state machine

The visual state machine should be explicit and shared by both renderers.

normal
  -> preview
  -> immediate_event
  -> persistent_consequence
  -> recovery
  -> normal_or_archived

Normal The globe shows the normal Earth texture, any historical/reviewed symbols, and no active transient synthetic event effect. The event panels may be open, but nothing is visually committed.

Preview A synthetic location is created. A preview symbol appears immediately. A disposable leader line and preview blurb appear in an occlusion-safe location. A faint local mask appears. The selected nextConsequenceTexture fades in temporarily over the regular Earth texture, but no durable simulation state is written. This formalizes the behavior the site already documents.

Immediate event This state begins the instant the user confirms creation. It must not wait for OpenAI. The symbol becomes selected and pinned. The local transient effect starts within the target response time. The blurb converts from preview to committed event blurb. The leader line becomes durable. The dossier becomes available. If asset preparation is incomplete, the system must still show a placeholder local effect and a visible symbol while the texture layer finishes loading. That behavior follows directly from the site’s deterministic-first design and from standard image decode guidance.

Persistent consequence The transient burst tapers off, but a persistent footprint remains. The globe-level layer transitions from currentConsequenceTexture toward nextConsequenceTexture using transitionProgress. The event remains pinned until deliberately dismissed or superseded. The consequence brief can arrive at any time, but it never controls whether the event is visually present.

Recovery If the event’s qualitative assumptions justify stabilization, remediation, or social recovery, the planet-state layer should gradually crossfade toward a recovery image, not snap instantly back to baseline. The local footprint should shrink, lighten, or fragment before disappearing. The symbol should change from active-incident styling to archived-incident styling if the user keeps historical traces visible.

Event-subtype mapping

The following mapping is the recommended default spec for the required subtypes. These are qualitative visual defaults, not physical models.

Event subtypeLocal effectPersistent footprintPlanet-state imageDefault opacity bandTransition durationRecovery behavior
Nuclear detonationFlash + abstract rings + disturbance haloSurface disturbance stainScorched / severe stress / ash winter when justified0.12–0.451.2–6 s to first state, slower deepening afterLong fade to stress or recovery image; footprint lingers
Abstract nuclear emergencyPulse beacon + disrupted service haloNonphysical institutional-pressure fieldSevere stress only if justified0.10–0.301–4 sRecovery reduces pressure before visual clear
Nuclear-facility emergencyFacility-alert pulse + containment ring + abstract plume veilMonitoring/remediation zoneSevere stress or recovery0.10–0.282–8 sLong remediation path, slow return
Solar flare / geomagnetic stormSolar arc + magnetic sweep + connectivity flickerGrid/connectivity pressure fieldStress or deep-cold/auroral tint only in extreme fictional mode0.08–0.351–5 sRecovery by redundancy and preparedness
Meteorite / asteroid impactIncoming trace + flash + debris + ringsCrater / ejecta markCratered / red impact / brown impact / polar impact0.12–0.401–6 sRecovery texture optional; crater remains longest
WildfireFire-front glow + ember drift + smoke veilBurn scarScorched regions0.08–0.242–10 sBurn scar retreats gradually, smoke clears first
DroughtHeat shimmer + dry-cell outlineDryness fieldDry Earth0.08–0.228–30 sSlow recovery with patchy persistence
HeatwaveHeat pulse + atmospheric stress veilHeat-stress fieldDry Earth or reduced ice if cumulative0.08–0.244–20 sRecovery quicker than drought unless compounded
Global warming pressureLong-wave heat bands + polar stressPersistent climate-pressure fieldDry Earth + reduced ice0.16–0.4520–60 s staged transitionsRecovery only through slow staged easing
EarthquakeSeismic ripple + fault zigzag pulseCrack/disturbance fieldNone by default0.00–0.08 unless cascades justify more0.6–3 sFootprint softens, no broad overlay normally
VolcanoGlow vent + ash plume + pressure ringAsh/tephra fieldAsh winter only when justified; otherwise none or subtle stress0.06–0.281–8 sLong atmospheric recovery if ash layer used
FloodExpanding water sheen + inundation pulseWater fieldNone by default; stress only if broad cascading failure0.00–0.141–6 sWater recedes, service-pressure fades later
TsunamiCoast-linked wave arc + arrival ringCoastal impact traceNone by default; regional stress only if compounded0.00–0.161–5 sCoastal trace fades after service restoration
Severe stormSpiral cell + lightning flicker + rain veilStorm track pressure fieldStress only if prolonged or multi-region0.04–0.181–6 sTrack fades, service-pressure clears later

Event sequence specification

Nuclear and radiological visuals with explicit non-operational boundaries

The site already states that nuclear options use abstract normalized system pressure only and never yield, delivery, blast, thermal, fallout, casualty, damage, or targeting calculations. That boundary should remain absolute. No geographic radius in kilometers, no facility- or target-specific vulnerability logic, no dose maps, no casualty counters, no evacuation routing, and no plume or fallout prediction should appear anywhere in the renderer or dossier. The user should only ever see synthetic location anchoring, qualitative pressure descriptions, and normalized consequence visuals.

For nuclear detonation or abstract nuclear emergency, the sequence should be: a very short white flash localized to the synthetic site; two or three expanding abstract disturbance rings; a lingering local disturbance stain; a second-order nonphysical consequence footprint representing service, health, environmental, and institutional pressure; and then, only when the qualitative assumptions justify it, a gradual fade into a scorched, severe-stress, or ash-winter world layer. The dossier should explicitly state that all visuals are educational consequence symbols rather than physical effects. The symbol should be an eight-point abstract burst for detonation, and a shielded pulse icon for abstract nuclear emergency, so that the two are visually distinct even in monochrome.

For a nuclear-facility emergency or meltdown, the symbol must not reuse the detonation glyph. It should look like an interrupted containment ring around a core node. The immediate local effect should be a containment-status pulse, followed by an abstract environmental-persistence veil that is visibly different from a blast ring. That veil should be slightly asymmetric and atmospheric but must not imply real plume modeling or wind-derived prediction. The longer tail of the sequence should emphasize monitoring, service disruption, trust erosion, remediation, and recovery rather than detonation-like suddenness.

Space-weather and impact visuals

For a solar flare or geomagnetic storm, the visual should begin with a solar-side arc or magnetospheric sweep visible across a broad section of the globe, followed by global or regional connectivity indicators on satellites, navigation, communications, and grid-pressure channels. These should look like network dimming, orbital hazard badges, auroral stress bands, or grid pulse interruptions, not like weapon or attack effects. Recovery should be governed by redundancy and preparedness: high redundancy yields brief flicker and fast restoration; low redundancy yields longer dimmed pathways and lingering service-pressure halos. The site already names orbital safety and related systemic indicators, which gives this family a natural place in the UI without needing any operational fidelity.

For a meteorite or asteroid impact, the sequence should use a visible incoming trajectory, impact flash, debris spray, expanding abstract rings, and a persistent crater or surface marking. The planetary overlay should depend on qualitative scenario choice: cratered, red impact, brown impact, or polar impact. The incoming trajectory should terminate in the synthetic cell but should never expose exact coordinates, energy, diameter, or casualty outputs. A regional service-pressure field can follow if the event is marked systemic or high-cascade.

Fire, heat, drought, and climate-pressure visuals

For wildfire, local visual language should include fire-front glow, ember activity, smoke or atmospheric stress, and a persistent burn scar. The broader world layer should use a scorched-regions image only when the qualitative scenario implies enough persistence or geographic breadth to justify it. A small localized fire should use mostly local effects, a faint smoke veil, and little to no global overlay. That preserves the required distinction between local and systemic events.

For drought, heatwave, or global warming pressure, the key requirement is a slow-developing transition. Drought should show dry-cell maps, vegetation fade, and a quiet water-stress field. Heatwave should show atmospheric heat shimmer and service stress, but should recover more quickly unless compounded. Global warming pressure should unfold through staged transitions from baseline toward Dry Earth and Reduced Ice imagery, with a visibly long horizon and no claim that the rendering is a physical forecast. The blurb and dossier should explicitly label the visualization as a qualitative pressure depiction.

Earth-system hazard visuals

For earthquake, use a sharp but brief seismic ripple and a fault-line pulse anchored to the synthetic cell. The persistent layer should be a crack/disturbance field only, with no broad world-state image unless cascading infrastructure or environmental assumptions warrant expansion.

For volcano, use a vent glow, ash plume, and an ashfall field. A global ash-winter image should be reserved only for the most extreme fictional assumptions; most volcanoes should remain local-to-regional in visual consequence.

For flood, use a rising water sheen, inundation pulse, and a receding water field. Avoid broad world-state imagery by default.

For tsunami, use a coast-linked arrival arc and an abstract coastal trace. No real wave-height or routing information should appear.

For severe storm, use a spiral cell, lightning flicker if desired, and a storm-track field. A global stress layer should be reserved for prolonged, multi-region, or cascading scenarios only.

These distinctions matter because they fix the current likely problem of many event families sharing too much generic visual grammar.

Acceptance tests, backlog, and delivery priorities

WebGL and 2D-fallback parity requirements

The site already documents an accessible non-WebGL globe fallback and reduced-motion behavior. The new consequence system should therefore have logic parity rather than merely “best effort” parity. The same event state, same symbol classes, same blurb/leader-line logic, same replay and restore behavior, and same world-state transitions must exist in both renderers. Differences should be quantitative only: fewer particles, lower texture resolution, or simpler shaders on the 2D path. Canvas and OffscreenCanvas are mature enough for this arrangement, and WebGL context loss must degrade to either self-recovery or 2D continuation without erasing event history.

Accessibility and reduced-motion requirements

The accessibility baseline should be strict. Event meaning must never rely on color alone; every symbol class needs a unique shape silhouette. Pinned blurbs must meet text contrast guidance, focus indicators must be conspicuous, and pointer/keyboard targets should meet WCAG sizing guidance. At narrow widths and 400% zoom equivalent, blurbs must reflow instead of clipping or forcing horizontal scroll. Reduced-motion mode should suppress auto-rotation, replace pulses and particle travel with calmer fades, and eliminate nonessential animation loops; this is already directionally consistent with the site’s accessibility policy.

Performance targets for desktop and mobile

The new system should ship with explicit budgets. Static consequence textures should use fingerprinted asset URLs and long-lived cache headers, ideally with immutable, because these are classic static-subresource cases. Startup should preload the base Earth texture and the currently active baseline consequence texture, and it should eagerly stage the next likely texture at the moment the user opens the event menu. Image decode should be asynchronous; image-to-bitmap conversion should happen ahead of first draw; and low-memory device classes should use fewer resident textures and lower resolutions, with thresholds informed by navigator.deviceMemory and available storage estimates.

I recommend these product targets:

TierFirst visible local effect after createGlobe frame targetTexture strategy
Desktop high/medium≤ 150 ms warm, ≤ 300 ms cold60 fps target, 45 fps floor during heavy transitionsBase + current + next + one standby overlay resident
Mobile medium≤ 250 ms warm, ≤ 450 ms cold45 fps target, 30 fps floorLower-res overlay set, reduced particles
Mobile low-memory≤ 350 ms warm, ≤ 600 ms cold30 fps steadyBase + current + next only, sprite-based local FX

Given/When/Then acceptance tests

The following acceptance tests define the required behavior of the modern consequence renderer.

  1. Given OpenAI is unavailable, when the user creates any fictional event, then a visible on-globe local effect appears immediately without waiting for narrative generation.
  2. Given any event is created, when creation succeeds, then a geographic event point is stored and rendered.
  3. Given any event is created, when creation succeeds, then a visible event symbol appears at once.
  4. Given any event is created, when creation succeeds, then a connected event blurb appears at once.
  5. Given any event is created, when creation succeeds, then a leader line connects the symbol to the blurb.
  6. Given any event is created, when creation succeeds, then the event enters a selected or pinned state.
  7. Given any event is created, when the user opens its details, then a detailed dossier is available.
  8. Given the context menu is open, when a blurb is placed, then the blurb is not hidden beneath the context menu.
  9. Given playback controls are visible, when a blurb is placed, then the blurb is not hidden beneath playback controls.
  10. Given the world mode panel is visible, when a blurb is placed, then the blurb is not hidden beneath the world mode panel.
  11. Given an event anchor is near the viewport edge, when the label would clip, then the system reroutes the leader line and repositions the blurb within the safe area.
  12. Given an event moves offscreen due to globe rotation, when it is still selected, then an offscreen edge pointer remains visible.
  13. Given an event is created, when the transient effect ends, then a persistent footprint remains.
  14. Given an event is localized, when it is rendered, then any planet-state overlay remains in the subtle alpha band.
  15. Given an event is systemic or global, when it is rendered, then the overlay moves into a stronger alpha band.
  16. Given a consequence overlay is active, when it is rendered, then the normal Earth texture remains visible beneath it.
  17. Given a planet-state transition is triggered, when it starts, then it develops over time instead of switching instantly.
  18. Given the selected consequence texture is not yet decoded, when the user creates the event, then a placeholder local effect and symbol still appear immediately.
  19. Given an overlay image fails to load, when the event is created, then the event still shows local effect, footprint, symbol, blurb, and dossier using graceful fallback visuals.
  20. Given the user presses Replay event visual, when replay starts, then the transient sequence restarts without duplicating the event record.
  21. Given the user presses Restore Earth visual, when restore runs, then the active overlay is cleared or eased out without deleting the event ledger entry.
  22. Given a nuclear detonation scenario, when creation succeeds, then the sequence shows immediate flash, expanding abstract rings, persistent local disturbance, and optional scorched/stress/ash layer only when justified.
  23. Given an abstract nuclear emergency scenario, when creation succeeds, then the symbol is distinct from detonation and the system shows nonphysical institutional/service pressure rather than blast-like visuals.
  24. Given a nuclear-facility emergency scenario, when creation succeeds, then the system shows a containment or monitoring status effect and a long remediation sequence.
  25. Given a nuclear-facility emergency scenario, when the dossier is opened, then it contains no plant-specific operating instructions, dose map, or evacuation routing.
  26. Given a solar flare scenario, when creation succeeds, then the system shows a solar or magnetospheric arc plus connectivity pressure indicators.
  27. Given a solar flare scenario with high redundancy, when recovery begins, then the connectivity indicators resolve faster than in low-redundancy cases.
  28. Given an impact scenario, when creation succeeds, then the sequence shows incoming trajectory, flash, debris, expanding abstract rings, and a persistent crater or surface marking.
  29. Given an impact scenario, when the qualitative choice is polar impact, then the selected planet-state image is the polar-impact variant.
  30. Given a wildfire scenario, when creation succeeds, then the system shows local fronts or glow, smoke or atmospheric stress, and a burn scar footprint.
  31. Given a drought scenario, when creation succeeds, then the system shows dry-cell stress and transitions toward a Dry Earth image over time.
  32. Given a global warming pressure scenario, when persistence is high, then Dry Earth and Reduced Ice can transition in staged sequence rather than with a single swap.
  33. Given an earthquake scenario, when creation succeeds, then the system shows a distinct seismic symbol and local ripple without a broad world overlay by default.
  34. Given a volcano scenario, when creation succeeds, then the system shows a distinct volcanic symbol, plume, and ash field, reserving ash-winter overlays for only the most extreme fictional cases.
  35. Given a flood scenario, when creation succeeds, then the system shows a water field and recession sequence with no physical inundation-depth claims.
  36. Given a tsunami scenario, when creation succeeds, then the system shows a coast-linked arrival arc and coastal trace without routing or wave-height outputs.
  37. Given a severe storm scenario, when creation succeeds, then the system shows a storm-track field with a distinct severe-storm symbol.
  38. Given reduced-motion is enabled at the OS level, when the user creates an event, then the system replaces nonessential motion with calmer fades and still communicates the consequence clearly.
  39. Given the app is running in the 2D fallback, when an event is created, then the same symbol, blurb, leader line, footprint, and replay/restore behavior are available.
  40. Given a WebGL context is lost, when the browser restores it or the app falls back to 2D, then active events and their visual states are reconstructed without data loss.
  41. Given keyboard-only navigation, when the user tabs to an event symbol, then the focus indicator is visible and the event can be opened without a pointer.
  42. Given a small-screen or 400%-zoom viewport, when a selected event blurb is shown, then it reflows within the safe region without horizontal scroll.
  43. Given a low-memory device class, when multiple events are active, then the renderer automatically reduces texture resolution and particle density before frame rate collapses.
  44. Given any event category, when the dossier is opened, then it contains explicit language that visuals are qualitative educational consequences rather than physical forecasts or operational guidance.

Prioritized backlog

The first priority is to close the preview/commit gap. The product already documents a preview renderer and already exposes replay/restore controls, so the fastest meaningful win is to convert event creation into a guaranteed visual commit with symbol, blurb, leader line, footprint, and state-layer activation.

The next priorities should be handled in this order:

PriorityWork itemWhy it matters first
P0Create committed VisualConsequenceState pipeline independent of OpenAIFixes the core “nothing happened” problem immediately
P0Add occlusion-safe annotation placementFixes hidden blurbs and leader-line readability
P0Preload/decode active and next consequence texturesFixes late or missing overlays
P1Build distinct event-symbol library per subtypeFixes disconnected/generic feeling
P1Implement persistent footprint layerCreates durable consequence memory
P1Implement current/next texture transition systemEnables gradual consequence development
P1Add replay, restore, and recovery-state persistenceMakes visuals inspectable and teachable
P2Match full behavior in 2D fallbackPreserves accessibility parity
P2Device-class quality manager and memory budgetsPrevents mobile degradation
P2Reduced-motion specializationPreserves meaning without excess motion
P3Local-only debug overlay for asset/state inspectionHelps audits without violating no-analytics posture

Because the site’s privacy page says it avoids analytics and keeps some preferences locally in the browser, any debugging instrumentation added for this work should itself remain local-only by default, exportable by the user when needed, and not phone home.

Risks, uncertainties, and evidence still required

The main uncertainty is not conceptual; it is evidentiary. This was a black-box audit conducted through the deployed site’s accessible session and public documents, not a full interactive desktop DevTools session. I therefore have high confidence in the preview/commit gap, the AI-separation requirement, the existence of the base and one planet-state texture, and the label-occlusion risk, but I do not have a full runtime waterfall proving the filenames and request timing of all 15 supplied alternative textures.

The most important evidence still required is a manual browser audit that captures: the exact network requests made when each event subtype is previewed and created; whether the supplied 15 textures are all present, hashed, and cacheable; whether the transition happens in WebGL, 2D canvas, DOM, or a mix; whether created events persist after reload/import/export; and whether blurbs collide with movable panels in real interaction. That manual pass should also include reduced-motion verification, focus testing, mobile viewport testing, and forced context-loss recovery. The need for those tests follows directly from the site’s documented fallback path, accessibility commitments, and replay/import/export surfaces.

There is also a content risk: once the renderer becomes more compelling, it must remain firmly within the site’s published safety boundary. That means no drift into real targeting, plant-specific guidance, blast or fallout calculation, operational routing, casualty estimation, or physical forecasting. The detailed sequences in this report are intentionally expressive but non-operational, and that boundary should be codified in both design review and acceptance testing.

The bottom line is that the current deployment already contains the seeds of the correct system: a browser-local authoritative engine, a preview pathway that can fade a supplied state image over the normal Earth texture, a 2D fallback, replay/restore affordances, and a leader-line model. What it appears to lack is a committed consequence renderer that consistently turns event creation into an unmistakable, persistent, readable, and event-specific visual outcome. This specification is designed to fill that exact gap without violating the Atlas’s fictional, educational, and non-operational mission.