Black-Box Audit of the IARPA.org Planetary Atlas Globe Context Menu and Fictional-Event Lifecycle

Full report

On this page

Executive summary

This audit is based strictly on browser-observable evidence from the deployed public site and its public support pages. I did not inspect source code, repositories, build artifacts, server files, or development conversations, and I do not claim to have changed or fixed anything. The evidence available to me shows that the site’s published product intent is unusually explicit: the homepage and guide text say that a single click on empty globe space should do nothing; right-click, double-click, or Shift+F10 on a focused globe should pause the simulation and open a fictional-event menu; the chosen point should become a synthetic cell; exact coordinates should not be exposed to OpenAI; the deterministic browser-local simulation should create the outcome first; and an optional OpenAI consequence brief may follow without changing numeric state. The site also publicly claims keyboard support, visible focus, reduced-motion support, narrow-width reflow, touch/pinch input, and a non-WebGL fallback.

The strongest confirmed issue is not a visual rendering failure that I can prove from remote interaction, but a semantic exposure failure in the browser-readable page stream: on initial load, the deployed homepage already exposes text for a large number of surfaces that appear to be inactive or context-specific, including the event-creation dialog, publication overlay, atlas guide, branch-comparison surface, projection notice, consequence panel, selected synthetic cell panel, and even WebXR-related copy. In a black-box accessibility and interaction audit, that is material evidence of a likely hidden-surface, focus-order, or inert-state problem, even though I cannot conclusively prove from this tooling whether every one of those surfaces is also exposed identically in the runtime accessibility tree.

A second major issue is an observability gap around the globe context menu itself. The site’s help text clearly says the menu exists and names the gestures that should open it, but the browser-observable page representation available here does not expose the required nested taxonomy the assignment expects, such as “Military Action,” “Biological Event,” “Political Change,” “Natural Disaster,” and the full Natural Disaster submenu. Searches for several of those labels on the deployed homepage return no matches, while the event dialog itself exposes only a generic “Fictional event” category in this representation. That does not prove the menu is absent visually, but it does prove that the category system is not externally verifiable from the observable text representation and is therefore weak from an accessibility-audit and black-box testability standpoint.

A third major issue is a reliability and recovery ambiguity. The site publicly promises that the deterministic engine is authoritative, that OpenAI may only explain results, and that a deterministic local fallback exists. At the same time, the homepage exposes startup copy such as “AI consequences on” and “Checking bounded consequence service…,” without any corresponding observable timeout budget, degraded-mode banner, user-facing retry state, or explicit recovery copy in the same startup experience. Because the requested audit specifically includes event submission while the optional AI provider is unavailable, this missing black-box evidence should be treated as a high-priority specification gap until verified interactively.

My overall conclusion is that the public product narrative is coherent and safety-aware, but the deployed surface needs a stricter, more explicit implementation contract for hidden-state management, focus and keyboard semantics, menu discoverability, mobile drill-down behavior, z-index guarantees, and deterministic timeout/recovery behavior. The remainder of this report separates what I directly observed from what I recommend as the implementation specification needed to make the globe context menu and fictional-event lifecycle auditable, robust, and accessible.

Test environment and limitations

Environment used. The audit used remote browser-fetch and page-inspection tooling against the public deployed site and related public pages. The homepage loaded in a mode where the site itself reported that WebGL was unavailable and that it had switched to an accessible two-dimensional globe renderer. Public support pages for Accessibility, Privacy, Safety, Help, and the homepage’s own “Use the Atlas” guide were also inspected because they describe intended controls, boundaries, and fallback behavior.

What I could directly observe. I could inspect the browser-fetched page text, linked public pages, image assets referenced by the event-creation surface, and the presence of control labels and instructional copy on the deployed site. I could also search the loaded page text for specific strings such as gesture instructions, disaster-related phrases, and AI-boundary language. This was sufficient to confirm a substantial amount of product intent and to identify several semantic and observability defects.

What I could not directly verify in this environment. I could not perform true pointer-level right-clicks, double-clicks, long-presses, real viewport resizing to the exact requested device sizes, real browser zoom changes, developer-tools z-index inspection, network-payload inspection, runtime accessibility-tree traversal, or live keyboard focus traversal inside the running JavaScript UI. I therefore cannot truthfully claim that I verified menu placement, actual z-order, touch timing thresholds, worker timing, or AI-outage handling by direct runtime interaction. Wherever this report discusses those items, I label them either as a browser-observable defect in semantics or as a design recommendation required to satisfy the expected behavior.

Evidence references used throughout this report. Homepage primary evidence. The homepage browser representation is the main source for visible controls, help text, event-dialog copy, and lifecycle claims. Accessibility statement. The accessibility page is the primary source for keyboard, focus, reduced motion, and reflow claims. Privacy statement. The privacy page is the primary source for browser-local storage, no-account, no-analytics, and local-draft claims. Safety statement. The safety page is the primary source for prohibited operational detail and fictional-systems boundaries. Preview-image assets. The event dialog refers to globe imagery that resolves to public atlas image assets. Those assets confirm that the preview surface is wired to real raster resources, even though they do not prove full interaction flow by themselves.

Observed behavior and evidence

Exact observed behavior on homepage load. The homepage’s browser-readable representation loads with a large amount of simulation UI already present in the document stream. Observable items include the simulation date controls, a selected-marker panel, Atlas Overview, World Mode, a systems panel, Fictional Interventions, a “WHAT-IF MACHINE” laboratory, a view-layer panel, an event ledger, guided discovery controls, a selected synthetic cell panel, a consequence brief panel, a timeline with playback controls, a HUD panel, a complete “Create an abstract globe event” surface, a publication overlay, an atlas guide, a branch-comparison surface, and a no-JavaScript fallback notice. This is a significant observation because many of those surfaces appear to be context-specific overlays rather than startup-critical content.

Published gesture behavior. The site’s own guide text says that dragging rotates the globe, wheel or pinch zooms, arrow keys rotate, + and − zoom, 0 resets, and space plays or pauses. Most importantly for this audit, the guide explicitly states that a single click on empty globe space does nothing and that right-click, double-click, or Shift+F10 while the globe is focused pauses and opens the fictional event menu.

Published fictional-event behavior. The observable event-creation surface already contains Simple and Advanced Academic modes; a visible preview area; scenario preset, abstract size, type/configuration, initiating actor class, fictional actor, and consequence-horizon selectors; analyst-oriented advanced assumptions; an optional private browser-local note; and explicit Create, Cancel, Preview, Close, and Enter-submit copy. The same surface says the deterministic browser-local simulation creates the outcome first, OpenAI may then explain consequences, exact coordinates are neither displayed nor sent to the consequence service, and nuclear options are abstract normalized system pressure rather than operational calculations.

Published AI and fallback behavior. The consequence panel says OpenAI may supply bounded narrative only and that the deterministic engine remains authoritative. Elsewhere on the homepage, the AI section says that a bounded server service may supply a short consequence brief using only a synthetic-cell identifier and reviewed abstract choices, omitting exact coordinates and private notes, and that the model cannot change numeric state. The same section claims a deterministic local fallback. Yet the immediately observable startup copy still includes “AI consequences on” and “Checking bounded consequence service…,” which means the product publicly exposes both an authoritative local core and an external dependency check on the same surface.

Accessibility, privacy, and safety claims. The accessibility page says the atlas is designed for keyboard use, visible focus, text enlargement, mobile reflow, reduced motion, right-to-left content, semantic headings, printable reports, and a non-WebGL globe fallback; it further says reduced-motion preferences stop automatic globe rotation and that the globe supports pointer, touch, wheel, pinch, and keyboard controls. The privacy page says the public site requires no account and uses no advertising, analytics, remote fonts, or embedded third-party forms, while local browser storage may be used for appearance settings and optional editorial drafts. The safety page says the site does not provide practical targeting, weapon construction, intrusion, clandestine communication, or physical-harm procedures.

Evidence references for screenshots or equivalent observable artifacts. I could not capture live interactive screenshots of the running page in this environment, but the event surface does reference public globe image assets that resolve successfully: a high-quality Earth texture and a “Natural Earth” planet-state texture. These are not proof of menu correctness, but they are useful evidence that the preview surface is backed by concrete media assets.

Defect report

Defect A — inactive or context-specific surfaces appear exposed in the initial browser-readable page stream. Severity: critical for accessibility semantics, high for keyboard usability, medium for general users. Expected behavior versus actual behavior. Expected: only currently visible, currently actionable surfaces should appear in the reading order and accessible semantics; inactive dialogs and overlays should be hidden from reading order, removed from tab order, and treated as inert until opened. Actual: on initial homepage load, the browser-readable stream already includes text for the event-creation dialog, publication overlay, atlas guide, branch comparison, selected synthetic cell, consequence brief, WebXR overlay text, and other surfaces that appear to be inactive or conditional. User impact. This creates a real risk of polluted focus order, confusing screen-reader navigation, misleading search indexing, ambiguous Escape behavior, and hidden-surface interactions competing with the visible surface. Even for sighted keyboard users, it strongly suggests that inert-state management may not be strict enough. Reproduction steps. Load the deployed homepage in the browser-fetch tool. Without performing any event-creation gesture, inspect the returned page stream. Observe that multiple modal or context-specific surfaces are present in the initial stream, including “Create an abstract globe event,” “Publication,” “Use the Atlas,” “Fictional branch comparison,” “Selected synthetic cell,” and “Immersive session active.”

Defect B — the required context-menu taxonomy is not externally verifiable in browser-observable semantics. Severity: high for accessibility and auditability, medium for sighted mouse users if the visual menu works, critical if it also fails for keyboard users. Expected behavior versus actual behavior. Expected: the context menu and nested categories should be discoverable from browser-observable semantics when present, with stable accessible names for categories and submenus, particularly because the guide explicitly advertises keyboard invocation with Shift+F10. Actual: the product guide says the fictional event menu opens from the globe, but searches of the deployed homepage representation do not reveal labels such as “Military Action,” “Biological Event,” “Political Change,” “Natural Disaster,” or “Other Fictional Event.” Meanwhile, the dialog itself exposes only a generic event category label of “Fictional event” in this representation. User impact. This blocks black-box verification of the most important menu functionality in the assignment and strongly suggests either missing accessible labels, menu content rendered only visually, or a discoverability gap between the context menu and the dialog. Reproduction steps. Load the homepage representation and search for the required menu category names. Observe that the required category labels are not returned in the page stream, while the on-page event dialog remains generic.

Defect C — AI service preflight is observable, but timeout and degraded-mode recovery are not. Severity: high. Expected behavior versus actual behavior. Expected: if the deterministic simulation is authoritative and the AI brief is optional, the interface should make the fallback path visible and finite, especially during service checks or outages. Actual: the page exposes “AI consequences on” and “Checking bounded consequence service…” while separately claiming that the deterministic engine remains authoritative and has a deterministic local fallback, but no explicit timeout budget, failure banner, or “event created despite AI outage” message is observable from startup state. User impact. If the AI narrative service is slow or unavailable, users may be unable to distinguish “event failed,” “brief pending,” and “event succeeded but narrative degraded,” which is exactly the ambiguity the assignment prohibits. Reproduction steps. Load the homepage, inspect the consequences and AI sections, and compare the observable startup language. The system claims local authority and fallback but exposes only a service-check state, not a user-facing timeout/recovery contract.

Defect D — Escape and current-surface responsibility are underspecified in the observable startup experience. Severity: high. Expected behavior versus actual behavior. Expected: only one transient surface should be “current” at a time, and Escape should close that exact current surface in a predictable stack order. Actual: the guide says Escape closes the current surface, but the initial document stream exposes multiple simultaneous closable surfaces and overlays, making the meaning of “current surface” semantically ambiguous in black-box inspection. User impact. Users can encounter unpredictable close order, focus restoration bugs, and accidental dismissal of the wrong overlay if the surface stack is not formalized. Reproduction steps. Load the homepage representation, note the repeated close buttons and concurrent overlay copy, then compare that with the single documented Escape rule.

Defect E — WebXR wording appears in the initial page stream in a way that can misrepresent current state. Severity: medium. Expected behavior versus actual behavior. Expected: immersive-session copy and an “Exit VR” affordance should only appear when an immersive session is actually active. Actual: the homepage text stream includes “SIMULATION EARTH · FICTIONAL · WEBXR,” “Immersive session active,” and an “Exit VR” button in the same document representation that also says the site is checking WebXR availability. That is at minimum a semantic-state inconsistency. User impact. This can confuse assistive technology, automated auditing, and users trying to understand whether they are actually in VR mode. Reproduction steps. Load the homepage representation and compare the WebXR checking text with the “immersive session active” block that is already present later in the same stream.

Interaction and layering specification

Complete interaction state machine from globe gesture to committed event. The product needs one authoritative state machine, because the homepage already shows that multiple panels, notices, and overlays may coexist. The deterministic event path should be: Idle Playing → Globe Focused → Qualifying Gesture Detected → Candidate Point Latched → Simulation Pause Requested → Pause Confirmed → Context Menu Open → Category/Submenu Navigation → Event Type Selected → Configuration Dialog Open → Valid Draft Ready → Create Requested → Deterministic Commit In Progress → Event Committed → Event Selected and Pinned → Marker/Blurb/Leader Line Rendered → Consequence Panel Open → optional AI Brief Pending → either AI Brief Ready or AI Brief Timeout With Local Fallback. Cancel and Close branches should be explicit from both the menu and the dialog, and every branch should restore focus either to the globe anchor point or to the newly created event, never to an arbitrary panel. This recommendation is driven by the site’s own gesture claims, deterministic-first claims, optional-AI claims, and multi-surface interface complexity.

Proposed z-index and protected-layer hierarchy. Because the homepage exposes World Mode, date and playback controls, HUD toggles, Current Statistics, event-related surfaces, leader-line language, dossiers, and the event dialog, the product needs a documented layering contract rather than ad hoc stacking. I recommend: base globe canvas 0; noninteractive atmospherics 50; selectable points and event markers 100; leader lines and geographic hit targets 150; event blurbs and Current Statistics cards 200; movable panels such as World Mode, Systems, Timeline, and HUD 300; the globe context menu root 800; nested submenus 810; a menu-placement debug overlay if enabled 850; the modal scrim for event configuration 900; the event configuration dialog 910; toast or status banners 950; and emergency diagnostics or accessibility alerts 1000. The critical contract is that the context menu and submenus must outrank all panels and cards, while the event dialog must outrank the context menu once opened.

Menu placement and collision-avoidance rules. The context menu should anchor to the pointer location for mouse gestures and to the projected focus point for keyboard invocation. The menu must apply a minimum viewport inset of 12 px on desktop and 8 px on mobile, measure itself before final placement, and choose a quadrant that avoids clipping. If the primary placement would overflow, the menu should flip horizontally first, then vertically, then shrink to a max-height with internal scroll. Submenus should inherit the same rules, preferring outward expansion away from the nearest viewport edge; if both directions would overflow, the submenu should convert into an in-place replacement panel rather than a detached flyout. On mobile, nested flyouts should be replaced entirely with a drill-down sheet. This is necessary because the site claims support for narrow widths, touch input, keyboard invocation, and a dense floating-panel environment.

Accessibility, mobile, and recovery specification

Focus-management and keyboard-navigation requirements. The globe needs a focusable composite root with a visible focus ring. Shift+F10 and the context-menu key must open the same menu that right-click and double-click open. The context menu should use role="menu", top-level items should use role="menuitem" or menuitemradio/menuitemcheckbox only where semantically appropriate, submenu triggers should expose aria-haspopup="menu" and aria-expanded, and keyboard navigation should support arrows, Home, End, Enter, Space, and Escape. The event configuration surface should be a true modal dialog with role="dialog" or alertdialog only if justified, aria-modal="true", a programmatic title, a predictable initial focus target, and robust focus trapping. Escape must close only the topmost dismissible surface and restore focus to the invoking element or the newly created event marker. These requirements directly implement the site’s own accessibility promise of keyboard use and visible focus and its guide rule that Escape closes the current surface.

Touch and mobile requirements. Touch input should support long-press on empty unoccupied globe space with a fixed threshold, I recommend 550 ms, canceled by movement beyond a small slop radius. Because hover is absent on touch devices, nested categories should not be flyout-only on mobile. Instead, touching a category should push a drill-down list or bottom sheet with a Back affordance, a clear title, and preserved synthetic-location context. The dialog should become a full-height sheet on the 390 × 844 class of viewport, with sticky action buttons, sticky title and close controls, and internal scrolling that never hides the Create action. Reduced-motion mode must suppress auto-rotation, menu animation, dialog spring motion, and visual effect flash transitions beyond a minimal opacity fade. These requirements follow directly from the site’s claims about mobile reflow, reduced motion, touch and pinch support, and nonessential-panel hiding.

Event-submission timeout and recovery requirements. The event-creation lifecycle must separate local deterministic commit from optional AI narration. On Create or Enter from a valid state, the product should first write the event to local authoritative state, immediately render the selected/pinned event marker, blurb, leader line, and consequence panel, and only then enqueue the optional AI brief. The AI request should carry only the synthetic-cell identifier and reviewed abstract settings, not exact coordinates or private notes, matching the site’s published boundary. I recommend a visible brief-pending state with a hard timeout of 8 seconds, a single silent retry only if the request was never sent, and then a visible fallback state reading, in substance, “Event created. Deterministic consequence view is available. Narrative service unavailable.” Once the timeout fires, the event must remain committed and visible.

Error-message and diagnostic requirements. The current public text promises authoritative local state and bounded AI behavior, but the product needs corresponding diagnostic copy. Minimal user-facing messages should include: “No event type selected”; “This point is occupied—choose empty globe space”; “Menu unavailable because globe focus was lost”; “Simulation paused”; “Event created”; “Event created, narrative pending”; “Event created, narrative unavailable”; “Preview unavailable in reduced-motion mode”; and “Could not open submenu—use Enter to drill in.” For supportability, each user-visible failure should also expose a short diagnostic token, such as CTX-ANCHOR-LOST, CTX-COLLISION-RECOVERED, EVT-COMMIT-TIMEOUT, or AI-BRIEF-FALLBACK, without exposing sensitive internals. That requirement is justified by the site’s published support invitation for accessibility and navigation issues and by the visible ambiguity around AI preflight state.

Accessibility requirements beyond keyboarding. Every surface needs a programmatic name, close button name, and logical reading order. Hidden panels and dialogs must be truly hidden from semantics when inactive. The currently selected synthetic cell and event should be announced in a live region after creation, using non-coordinate language such as “Fictional event created in synthetic cell.” The menu should announce submenu expansion and collapse. The dialog should announce validation readiness when Enter becomes a valid submit action. Escape should announce what closed and where focus returned. Because the site explicitly promises semantic headings, visible focus, right-to-left support, and reduced motion, these semantics should be treated as must-have requirements rather than polish work.

Acceptance tests, backlog, and remaining unknowns

Acceptance tests. The following Given/When/Then tests are the minimum explicit contract I would require for the globe context menu and full fictional-event lifecycle. They are written to operationalize the product behavior published on the site and the defect risks identified above.

• Given the globe is focused and the pointer is over empty unoccupied globe space, when the user single-clicks once, then nothing opens, no point is latched, and simulation play state is unchanged.
• Given the globe is focused and the pointer is over empty unoccupied globe space, when the user right-clicks, then the simulation pauses and the globe context menu opens.
• Given the globe is focused and the pointer is over empty unoccupied globe space, when the user double-clicks with the primary button, then the simulation pauses and the same globe context menu opens.
• Given the globe is focused, when the user presses Shift+F10, then the context menu opens at the projected focus anchor and not at the page origin.
• Given the menu opens near the bottom-right viewport edge, when placement is calculated, then the menu remains fully inside the viewport with the required inset.
• Given a submenu would overflow the viewport, when it opens, then it flips or converts to an in-place panel instead of clipping.
• Given World Mode, Timeline, HUD, Current Statistics, and an event blurb are all visible, when the context menu opens, then the menu paints above all of them.
• Given the top-level menu is open, when the user navigates with arrow keys, then focus moves only among menu items in a predictable order.
• Given a menu item has children, when the user presses Right Arrow or Enter, then the submenu opens and focus moves into it.
• Given a submenu is open, when the user presses Left Arrow or Escape, then the submenu closes and focus returns to its parent item.
• Given the Natural Disaster category is opened, when the user inspects the submenu, then all required options are present: earthquake; solar flare or geomagnetic storm; forest or wildland fire; meteorite or asteroid impact; volcanic eruption; flood, storm surge, or tsunami; severe storm; drought, heatwave, or long-term warming pressure.
• Given any event subtype is selected from the menu, when selection completes, then the menu does not silently disappear without opening a configuration dialog.
• Given the configuration dialog opens, when it receives focus, then it exposes a programmatic title, a close control, and a visible initial focus target.
• Given the dialog is open, when the user toggles from Simple to Advanced Academic mode, then the mode changes without losing the selected event type or synthetic location.
• Given the dialog is open, when the user changes preset, abstract size, type/subtype, actor/cause, or horizon, then the preview updates immediately.
• Given reduced-motion mode is active, when the preview changes, then the update avoids nonessential motion and uses a minimal transition.
• Given the dialog is in a valid state, when the user presses Enter, then creation begins exactly once.
• Given the dialog is invalid, when the user presses Enter, then no event is created and the blocking validation message is announced.
• Given the user presses Cancel in the dialog, when cancellation completes, then no event is created and focus returns to the original globe anchor.
• Given the user presses Escape in the dialog, when the dialog closes, then no lower surface closes at the same time.
• Given the user clicks outside the open context menu, when dismissal occurs, then the menu closes and focus returns to the globe.
• Given the dialog is open, when the user clicks outside the dialog, then behavior follows one documented rule only, either ignore outside click or close with confirmation.
• Given the synthetic location has been chosen, when the event is submitted, then exact geographic coordinates are not displayed in the dialog or sent to the AI provider.
• Given the event is valid and Create is pressed, when submission begins, then the deterministic local simulation commits the event before any AI request is awaited.
• Given deterministic commit succeeds, when the UI updates, then the dialog closes and the new event becomes selected and pinned.
• Given deterministic commit succeeds, when the globe redraws, then a geographic event point is visible at the preserved synthetic location.
• Given deterministic commit succeeds, when the event becomes selected, then a connected event blurb appears and a leader line links point to blurb.
• Given deterministic commit succeeds, when the event enters active state, then the visual effect begins immediately without waiting for AI narration.
• Given deterministic commit succeeds, when the UI settles, then the consequence panel opens automatically.
• Given the AI consequence service is available, when the local event is already committed, then an AI brief may appear later without altering the event identity or numeric state.
• Given the AI consequence service is unavailable, when timeout expires, then the event remains visible and selected and the UI shows an explicit local-fallback message.
• Given a worker or background delay occurs after commit, when the UI recovers, then the event does not disappear and does not require recreation.
• Given the user opens the menu on mobile by long-press, when a category with children is chosen, then the UI uses a drill-down mobile pattern instead of a hover-dependent flyout.
• Given browser zoom is 150%, when the menu or dialog opens, then no control required for completion is clipped offscreen.
• Given Current Statistics cards are visible near the intended anchor, when the context menu opens, then card overlap does not hide or intercept the menu.
• Given an event blurb already occupies the intended menu area, when the menu opens, then menu placement resolves collision without clipping or burying the submenu.
• Given a nuclear or radiological fictional event is created, when the dialog and preview render, then no operational or real-world targeting data appears and the event remains abstract and normalized.
• Given touch, mouse, and keyboard each invoke the same event type, when the dialog opens, then the resulting configuration surface and validation rules are functionally equivalent across input methods.

Prioritized implementation backlog. Critical. Formalize transient-surface state ownership; ensure inactive dialogs, sheets, and overlays are truly hidden and inert; implement a documented topmost-surface close stack; guarantee deterministic-first commit before AI; add visible degraded-mode messaging for AI timeout and outage; and write a hard z-index contract for menu, submenu, dialog, card, and panel layers. These are the issues most directly tied to the semantic-overexposure defect and the reliability ambiguity observed on the deployed surface.

High. Add fully named and keyboard-traversable menu semantics for every top-level category and every Natural Disaster subtype; implement anchor-safe placement and collision flipping; add mobile drill-down behavior; announce synthetic-cell creation and focus restoration; and unify right-click, double-click, keyboard, and touch entry paths so they call the same state machine.

Medium. Provide diagnostics tokens and user-facing error copy; expose a deterministic-preview pending state separate from AI pending; refine reduced-motion behavior for preview and effects; ensure WebXR state is not semantically exposed while inactive; and add telemetry only if it can remain local and privacy-consistent with the site’s published no-analytics posture.

Polish. Improve discoverability of globe-event creation through an explicit tooltip or HUD hint; provide a rehearsal mode that previews menu placement without committing location; add optional haptic feedback on mobile long-press; and include a compact “why can’t I create here?” explanation for occupied points or focus-loss cases. These are quality improvements rather than blockers.

Remaining unknowns and the evidence needed to resolve them. I could not directly verify the live menu’s visual placement, the actual runtime z-index values, the real accessibility-tree exposure of hidden surfaces, actual pointer and touch behavior at the required viewports, browser-zoom clipping behavior, the exact network payload sent to the optional AI service, worker timing under delay, or whether the Natural Disaster submenu visually contains every required option. To resolve those unknowns, the next evidence needed would be a real browser session with viewport resizing, keyboard-only traversal, touch emulation, reduced-motion emulation, browser zoom changes, developer-tools inspection of computed stacking and focus states, network capture of the AI request payload, and a trace of dialog submission while the AI backend is intentionally unavailable. Until that evidence exists, the defects above should be treated as confirmed where they concern browser-observable semantics, and the rest of this report should be treated as the recommended implementation specification necessary to make the feature set testable and reliable end to end.