Independent Acceptance Report for the Next IARPA.org Planetary Atlas Release

Full report

On this page

Scope and executive summary

Executive summary. I performed a black-box public-site review of the deployed IARPA.org experience using only publicly reachable pages, rendered route content, and directly openable public assets. The strongest positive finding is that the deployment is visibly and repeatedly labeled as an independent fictional educational simulation, not a government service, with clear separation between read-only research surfaces and fictional simulation surfaces. I directly observed the homepage rendering in a non-WebGL mode with an accessible two-dimensional fallback message, visible globe controls, visible Simulation Earth controls, a visible event-creation dialog surface, visible deterministic-brief fallback controls, and a large amount of public research content across About, Programs, Research, World, History, Learn, Projects, Contact, Search, Factbook, historical, profile, report, and comparison routes.

Overall acceptance recommendation. Reject pending fixes. That recommendation is driven by directly observed public inconsistencies that are material for release acceptance: the same site presents conflicting route identities and footer language across routes; the same /international/ route surfaced materially different record totals across observations; the Search page links to /site-map/, which returned a public 404 in this test; the comparison route URL suggests countries=denmark while the rendered page showed three different selected profiles; and the project directory simultaneously exposed a populated directory and a “No matching records” empty state. These are not speculative repository issues; they are public runtime findings.

Evidence model used in this report. Direct evidence means I saw the page, control text, route result, redirect, or asset URL in the deployed public experience. Inference means I am interpreting externally visible inconsistencies that are consistent with stale caches, mixed templates, or partial rollout. Recommendation means the action I would require before production acceptance. Where a requested area could not be verified through this black-box environment, I mark it inconclusive rather than passing it. That matters especially for right-click behavior, real double-click behavior, keyboard focus traps, pointer containment, mobile touch execution, browser matrix execution, performance timing, service GET/POST inspection, worker timeout recovery, and cache-control headers. The environment visibly reported WebGL unavailable, and the browsing tooling did not provide HAR/header capture or controlled browser/viewport switching.

Test conditions.

High-level status by acceptance area.

Release coherence and route health

Release-coherence findings. I did not find a single globally visible software build ID, release string, or version marker on the homepage, About, or Search surfaces. A text search for “version” on the homepage extracted no match. What I did find were route-level content freshness markers such as “reviewed 22 July 2026” on the Project Directory and “research cutoff 2026-07-20 UTC” on profile and report pages. That means public readers can see editorial freshness markers, but not a coherent release marker for the deployed software itself.

Direct evidence of runtime inconsistency. Public route identity is inconsistent in ways that are difficult to explain as harmless copy variation. The homepage and About route use Integrated Artificial Reality Planetary Atlas and “fictional educational simulation,” while the /sources/ and /news/ routes present IARPA.org Fictional Education Portal, and their footer language shifts to FICTIONAL EDUCATIONAL RPG. Programs and Research also use Research Earth remains factual, while the homepage and About route use Current Statistics remains factual and read-only. From a black-box acceptance standpoint, that is strong evidence of route-template drift or a partial release that left older route shells live.

Possible stale-route or mixed-deployment symptom. I observed the same public /international/ route produce materially different counts across observations. One observation reported “Search 1,950 public research records,” while a later observation of the same route reported “Search 5,113 public research records” plus Factbook counts. A public route that changes its core headline count this sharply during one acceptance pass is not version-coherent enough for clean sign-off without explanation. I cannot prove whether the cause is stale HTML, hydration replacement, cached fragments, or test-tool rendering variance, but the public result is inconsistent.

Cache-busting and stale-asset risk. Two directly opened atlas image assets were served from stable, readable same-origin paths: /assets/atlas/earth-satellite-high-quality.png and /assets/atlas/planet-states/natural-earth.png. Neither observed URL contained a content hash, build token, or version query string. I could not inspect HTTP cache-control headers in this environment, so I cannot confirm cache policy, but the observed asset naming scheme does not provide URL-level cache busting for these assets. That increases the risk of stale texture mixes after cutover unless cache headers or purge discipline are exceptionally strong.

Host routing. https://www.iarpa.org/ redirected to https://iarpa.org/ in the public runtime. That is good and reduces duplicate-host ambiguity.

Basic route health. The following public routes loaded successfully during black-box traversal: Home, About, Programs, Research, World/International, History, Learn, Projects, Contact, Search, and multiple representative content routes including a Factbook entry, a historical series page, a country profile, a long-form report listing page, and a compare page.

Observed route failure and 404 behavior. The Search page explicitly offered “the site map” as a fallback route when interactive search needs JavaScript, but clicking that live link attempted to fetch /site-map/ and returned 404 Not Found in the browsing runtime. This is the clearest directly observed route-health failure in the acceptance pass. It also means the Search page’s no-JavaScript fallback guidance currently points users to a broken route.

Public status/health routes. I did not discover a public status or health endpoint during menu traversal or visible trust/help navigation. Because this browsing environment could not safely probe arbitrary unlinked URLs, I cannot conclude such a route does not exist; I can only conclude that no public status/health route was obtained in this acceptance pass. That is a deployment-readiness gap because it prevents independent confirmation of release coherence from public health metadata.

Route-health summary.

Globe, events, visuals, and current statistics

Globe and rendering findings. The homepage directly rendered with a visible message that WebGL is unavailable, and that the atlas is using its accessible two-dimensional globe renderer while keeping research routes and simulation controls available. I therefore treat the 2D fallback as directly observed and working at least to the point of page render. I did not independently observe the WebGL path, so the WebGL acceptance area remains inconclusive.

Visible globe controls. The homepage exposes visible control text for rotate, zoom, reset, pause, fullscreen, information density, visual detail, borders, event symbols, historical tour, and HUD panel control. The instrument guide also lists arrow-key rotation, +/- zoom, 0 reset, Space play/pause, and Shift+F10 for menu invocation when the globe is focused. These controls are therefore part of the public runtime surface, but I did not independently execute drag, wheel, pinch, reset, or off-globe pointer containment behaviors in this environment.

Context-menu findings. The public instrument guide states that a focused globe should open the fictional event menu on right-click, double-click, or Shift+F10, and that a click on empty globe space should do nothing. It also states that offscreen event pointers terminate on the visible globe edge and that selecting a dot or event draws a leader line to a compact label. Those are valuable UI contracts, but in this acceptance pass they remain documented behavior, not independently executed behavior. I did not observe the natural-disaster submenu, viewport collision handling, escape dismissal, or highest-layer stacking through direct pointer or keyboard invocation.

Event-builder findings. I directly observed a rendered event-creation surface titled Create an abstract globe event with visible mode toggles for Simple and Advanced academic, visible controls for scenario preset, abstract size, type/configuration, actor class, fictional actor, horizon, qualitative advanced assumptions, and an optional Private browser-local note field. I also observed visible buttons for Preview on globe, Cancel, and Create fictional event & analyze. That establishes that the public runtime exposes the builder UI, but it does not establish that every option opens a valid dialog, that preview actually renders, that submission succeeds, that results are deterministic, or that replay/restore behaves correctly under repetition or worker timeout.

Deterministic and non-targeting safety language is strong. The builder explicitly says the clicked point becomes an invented synthetic cell, exact coordinates are neither displayed nor sent to the consequence service, and nuclear options use abstract normalized system pressure only rather than yield, delivery, blast, fallout, casualty, damage, or targeting calculations. The consequence area also exposes both Generate consequence brief and Use deterministic brief, which makes the deterministic-local-fallback model visible in the UI. Historically reviewed events are also labeled as never rewritten by the model. That is a meaningful trust-positive observation.

Planet-state visual findings. I directly opened two public atlas image assets: a high-quality Earth texture and a planet-state texture labeled natural-earth. The event-builder help text says preview-on-globe temporarily fades the selected supplied planet-state image over the regular Earth texture without changing simulation state, and scenario descriptions explicitly mention nuclear/radiological emergencies, asteroid impacts, climate warming, fire, earthquakes, water disasters, volcanoes, storms, biological events, and other dependencies. However, I did not directly observe the specific nuclear/radiological, asteroid, wildfire, solar-storm, or climate image sequences being requested one by one, nor did I verify reduced-motion parity or WebGL/2D parity for those sequences.

Current Statistics findings. The homepage visibly offers Current Statistics and labels it read-only. It exposes borders, political-state language, statistics source labeling, category filters, and the claim that up to 20 front-facing entities nearest the center of the globe receive connected summary cards. About and Factbook/profile pages reinforce that Current Statistics is factual/read-only and distinct from Simulation Earth. I did not independently exercise the “up to 20 nearest cards” behavior, card/point interaction, rotation updates, leader lines in Current Statistics mode, empty-data diagnostics, or fictional successor-state behavior after a simulated branch. Those remain acceptance gaps.

OpenAI-service findings. The homepage visibly showed a consequence-service state surface: “AI consequences on” and “Checking bounded consequence service…”. The consequence panel also labels itself FICTIONAL NARRATIVE ONLY, states that generated consequence text is fictional and cannot alter authoritative history or metrics, and exposes Generate consequence brief, Use deterministic brief, Replay event visual, and Restore Earth visual. I could not directly inspect a capability GET, event POST, safe status reason, credential exposure, or failure behavior under provider outage at the network level. The local deterministic fallback is therefore UI-visible but not packet-verified.

A noteworthy compare-route defect in the world surface. The compare page URL I opened was .../compare/?countries=denmark, but the visible page stated 3 profiles selected and rendered a comparison table for United States, Türkiye, and Holy See and Vatican City State. For an atlas that exposes “copy comparison link,” this is a serious trust failure because the public URL and rendered state do not align. That defect affects shareability, reproducibility, and regression baselining.

Accessibility, responsive coverage, and performance

Accessibility findings. Public accessibility intent is well documented. The Accessibility route explicitly 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 fallback. I also directly observed accessible route structures such as Skip to main content on multiple routes, semantic heading levels, text-labeled controls, and no-account/no-third-party-form language on Privacy and Contact surfaces. Those are good public signs. What I did not independently execute here are keyboard-only globe operation, logical focus order, dialog focus traps, escape semantics, ARIA menu-role validation, screen-reader announcements, color contrast measurement, high-zoom behavior, or touch target measurement. Those remain inconclusive until exercised in real browsers and assistive technology.

Responsive and mobile findings. The public accessibility copy promises narrow-width reflow, wrapping identifiers, and reduced-motion support. The homepage help also documents pointer, touch, wheel, pinch, and keyboard controls. But I did not have tooling that exposed real viewport control for the required matrix of 1920×1080, 1440×900, 1365×768, 1280×720, 1024×768, 768×1024, 430×932, 390×844, and 360×800. Likewise, I did not exercise mobile Chromium or Mobile Safari. From an acceptance standpoint, responsive/mobile coverage is therefore not passed; it is a required post-fix validation area.

Browser coverage findings. The only directly observed rendering path in this acceptance pass was the browsing runtime’s extracted page renderer with WebGL unavailable. I therefore cannot claim Chrome/Chromium, Firefox, Safari/WebKit, Edge, Mobile Chromium, or Mobile Safari passes. This is a strict limitation of evidence, not a statement that those browsers fail. No browser matrix execution means browser compatibility remains a release gate.

Performance findings. I could not produce trustworthy timings for initial load, largest contentful paint, texture load time, layout shift, memory growth, long tasks, detached-element symptoms, or repeated rendering regressions because this black-box environment did not provide DevTools timings, console output, or memory instrumentation. I did directly observe a placeholder-like “Planetary systems— fps” label with no numeric frame-rate value surfaced in the extracted page, and I directly opened two large PNG texture assets. That is enough to say that performance telemetry is not externally evident in this path and that texture payloads are visually heavyweight, but not enough to assign exact performance numbers.

Search and local-processing trust signals. The Search and Privacy pages state that search queries stay in the browser, that international atlas search is processed on the page using a local index, and that the site uses no advertising, analytics, remote fonts, or embedded third-party forms. These are positive privacy and performance-adjacent signals, but without network inspection I treat them as visible policy claims, not fully verified transport facts.

Safety, trust, and deployment readiness

Safety and trust findings. The site strongly and repeatedly labels itself as fictional, educational, independent, and non-governmental. About, Safety, Privacy, Help, History, Learn, and many content pages all reinforce that boundary. The event-builder and scenario text also strongly reject targetable or operational outputs: no real-country targeting, no exact coordinates to OpenAI, no practical weapon/evasion/intrusion detail, and no casualty or physical-effects modeling. The difference between source years and simulation years is also visibly explained through 1999 startup, projection-horizon notices, “reviewed history” labeling, and the host UTC calendar explanation. This is one of the strongest aspects of the public deployment.

Trust weaknesses that still matter. Trust is not only about content boundaries; it is also about runtime coherence and reproducibility. The compare-link/query mismatch, route-brand drift, same-route count drift, broken site-map fallback, and simultaneous populated-plus-empty state in the Project Directory all reduce user confidence that public state is deterministic and shareable. That is especially damaging in a product that visibly emphasizes evidence, correction history, and reproducible comparison.

Deployment-readiness assessment. Based on direct public evidence, the deployment does not yet appear internally version-consistent enough for final acceptance. I cannot prove stale JavaScript/CSS/worker mixtures because I could not inspect network headers or bundle manifests, but the externally visible symptoms are consistent with partial rollout or stale route fragments: inconsistent branding across route shells, inconsistent naming of the principal read-only mode, same-route content drift, a broken fallback route, and a share-link mismatch on the compare surface. I also did not discover a public release marker or public health endpoint that could help an independent observer validate a clean cutover.

Public exposure review. I did not directly observe public ZIP downloads, source bundles, server file indexes, or secret files exposed through the browsed routes. The Project Directory explicitly states that external links are labeled and that no external script, font, pixel, or widget is loaded on that directory page. That said, because I could not probe arbitrary sensitive paths or inspect headers, exposed-file assessment remains bounded to the public pages I traversed.

Remaining unknowns and the evidence required to close them.

Defect register, regression suite, and cutover plan

Defect register.

Regression suite. The following Given/When/Then tests should be executed after fixes. They are written as production-facing acceptance tests, not code-level unit tests.

Release blockers.

1. Resolve cross-route identity drift so that all public routes present the same product name, footer family, and mode vocabulary.
2. Fix the live Search-page site-map link and provide a branded 404 experience for truly missing routes.
3. Fix compare-link/query-state reproduction so URL state exactly matches rendered state.
4. Resolve the same-route /international/ record-count inconsistency.
5. Remove simultaneous populated/empty state leakage from the Project Directory.
6. Add a visible release/build marker and a public status/health signal suitable for independent acceptance.
7. Complete real-browser verification for the unproven core features: WebGL, context menu invocation, event submission, replay/restore, provider fallback, texture sequences, accessibility execution, responsive matrix, browser matrix, and performance traces.

Prioritized remediation backlog.

Production smoke-test checklist.

1. Confirm the homepage loads on apex and www redirects cleanly to apex.
2. Confirm the visible release/build marker matches the release candidate sheet.
3. Open Home, About, Programs, Research, World, History, Learn, Projects, Contact, and Search; confirm identical product identity and fiction/non-government banner.
4. Open Search and verify the site map link works.
5. Request a guaranteed-missing route and verify branded 404 behavior.
6. Open World and confirm counts remain stable across refresh.
7. Open a compare link with known parameters and confirm rendered selections match URL exactly.
8. Open Project Directory and confirm no hidden empty state is exposed.
9. Verify 2D fallback path with WebGL disabled.
10. Verify WebGL path in a WebGL-capable browser.
11. Invoke context menu by right-click, double-click, and Shift+F10.
12. Create a fictional event, preview it, create it, replay it, and restore Earth visuals.
13. Run provider-available and provider-unavailable consequence checks.
14. Validate one nuclear/radiological preview, one asteroid preview, one wildfire preview, one solar-storm preview, and one climate preview.
15. Validate Current Statistics card/point/dossier synchronization.
16. Run one keyboard-only traversal and one screen-reader smoke pass.
17. Record one desktop and one mobile capture for final evidence retention.

Cache-purge and post-cutover checklist.

1. Purge CDN/cache entries for route shells that showed branding drift: Home-adjacent trust pages, /sources/, /news/, /programs/, /research/, /international/, and compare routes.
2. Purge globe texture assets and any planet-state overlays if content changed.
3. If a service worker exists in production, bump its version and verify old clients update cleanly.
4. Confirm new build marker appears on the homepage and trust pages after purge.
5. Open the two previously observed texture assets and confirm the current release is being served.
6. Re-run compare-link round-trip tests from a cold browser profile.
7. Re-run the Search → site map path from a cold browser profile.
8. Re-open /international/ from multiple entry points and confirm count stability.
9. Validate no stale footer identity remains on /sources/ or /news/.
10. Capture dated screenshots and a short route-health log immediately after cutover.

Rollback-validation checklist.

1. Confirm rollback target release/build marker is documented before traffic change.
2. After rollback, confirm apex and www hosts both expose the rollback marker consistently.
3. Re-open the previously broken routes and ensure the rollback state is coherent and intentionally known.
4. Re-test compare-link parameter rendering from the rollback build.
5. Re-test /international/ count stability in the rollback build.
6. Re-test Project Directory default and empty-state rendering in the rollback build.
7. Purge caches again after rollback so mixed forward/backward route shells do not remain.
8. Retain pre-rollback and post-rollback screenshots, route titles, and build-marker evidence for audit.

Final acceptance position. The deployed public site already demonstrates a thoughtful trust boundary, strong fictional labeling, a visible 2D fallback, substantial public content coverage, and a visible deterministic-vs-OpenAI narrative separation. But a release this interaction-heavy and trust-sensitive cannot be accepted while route identity drifts, a no-JS fallback link returns 404, the compare page ignores or overrides its public URL state, the Project Directory leaks contradictory states, and multiple critical interaction areas remain unproven in real browsers. On the evidence available today, the correct decision is Reject pending fixes.