# Tokyo research and measured results

September 5, 2026. Research and measurement handoff for the Astra Ultra implementation.

The full frozen Tokyo road network is in a production-readable packet, with sparse names and preserved source identities. **The 100,000-byte goal was not reached.** The selected road packet is 2,735,678 bytes. Roads, supplemental geography and the profile total 2,860,968 bytes before ordinary compression. Including the identified Tokyo-specific content embedded in renderer source brings the current accounting figure to 2,866,103 bytes.

The useful result is a working representation and a measured set of tradeoffs. Coarsening the roads damaged geometry long before it approached the target. Structural encodings helped, but their best offline result still needs over 2.4 MB and lacks the adopted streaming format. A late spatial partition experiment improved native cold-query latency at a small byte cost. None of these results proves that 100 KB is mathematically impossible.

This report consolidates the original [execution plan](tokyo-astra-ultra-plan.md), independent fidelity checks, source investigations and codec experiments. It does not replace the final delivery README's tested revision, export receipt, PR, build links or gameplay captures. The integrator supplied `b956834` as an integration checkpoint while final verification was still running. Earlier runtime measurements below retain their own file hashes and packet revisions.

Download the [evidence index](tokyo-evidence-index.json), [independent fidelity archive](tokyo-fidelity-evidence.tar.gz), [codec rebuild archive](tokyo-codec-rebuild-final.tar.gz) and [source evidence archive](tokyo-source-evidence.tar.gz). Extract the fidelity archive beside this report to open the relative `tokyo-fidelity-evidence/` links. The index maps supporting claims to portable archive paths and hashes. The fidelity archive contains scripts, tests and results, without a duplicate road corpus.

## Scope and what is implemented

The geographic reference is the frozen OSM JP-13 road acquisition, including Tokyo's remote islands and full ways that touch the selected administrative area. It retains 158,235 ways. The inherited selection excludes service roads and footpaths; neither is silently added or deleted to improve the comparison. It is not the whole Greater Tokyo region. The uncompressed frozen-source SHA256 is `cb7e75c4df23ec2dec7dc9fb24d76aa37a18f828d22dbce307f056ce1e1a0833`, with OSM base timestamp `2026-09-05T04:48:40Z`.

Supplemental data has narrower coverage. The selected packet contains 3,746 building-way records around Tokyo Station, 24 station-area relations and parts, 491 rail/water/park constraints, and 100 selected landmark descriptors. The source package documents the exact supplemental boxes. Rail covers the Station reference box; water and park acquisition covers selected areas and anchors. This is not a complete JP-13 building, rail, water or park inventory. Supplemental snapshots were acquired later than the road snapshot and retain separate timestamps.

| Work | Current disposition | Evidence boundary |
| --- | --- | --- |
| Versioned full-road atlas and Godot decoder | Integrated PWTOKY01, 0.5 m grid, spatial blocks capped at 256 ways, stable source way IDs | Complete independent final-packet decode; real Godot provider audit |
| Supplemental feature decoder | Integrated PWTFEA01 at 0.25 m | Python/Godot comparison over 4,361 records, 15,452 metadata fields and 40,572 referenced vertices |
| Survey names | 25 street names and 25 landmark names; all 100 landmark anchors retained | Explicit source-way mapping; six-label visible cap and names-off option are runtime policy |
| Ground and survey integration | Tokyo profile, nearby district materialization, source-based roads and footprints, survey/orbit representation, travel and rebase support | Focused native checks and earlier actual-main-scene probe; final delivery gates remain separate |
| Appearance and interiors | Generated facades and inferred architecture use existing procedural mechanisms; source rings and holes receive dedicated handling | Architecture, missing heights and room details remain approximations; no citywide visual parity certificate |
| Column encodings and exact shape recipes | Offline research candidates | Actual local reconstruction tests, with format and accounting limits below |
| Source-node exception sidecar | Verified prototype, not consumed by the renderer | Exact kept-node equivalence for one earlier packet; no runtime routing claim |
| Fitted district street grammar, mixed-precision production codec and learned seed search | Not implemented | Research ideas, without measured winning full-city packets |

The renderer keeps bridge, tunnel and layer information in the data. Its current three-dimensional view excludes underground tunnel roads. This atlas is not a vehicle-routing engine. Source flags do not establish that every rendered crossing, clearance or legal turn is correct.

Hamburg remains an appearance and interaction reference at a real Earth anchor, with a fictional local district. Tulsa's prior 95,144-byte playable packet covers a downtown slice. Those references justify reusing rendering and controls; they do not establish a 100 KB precedent for the full Tokyo road scope. The execution plan records the earlier Hamburg, Tulsa and CRT integration commits. Final ancestry and newly included capabilities belong to the delivery record, rather than assumptions about another thread's merge status.

## Honest byte accounting and reuse

The budget is 100,000 decimal bytes of city-specific encoded content before general-purpose gzip, Brotli or Zstd. All required runtime shards, names, indices, checksums, fitted parameters and geographic exceptions count. Offline source snapshots do not count when play does not require them. Extra runtime comparison packets would count if shipped.

| Selected runtime data | Raw bytes | Deterministic gzip bytes |
| --- | ---: | ---: |
| Roads, curated 25 names | 2,735,678 | 2,370,348 |
| Supplemental features and 25 landmark names | 124,649 | 93,901 |
| Tokyo profile | 641 | 366 |
| Data total | 2,860,968 | 2,464,615 |
| Identified embedded Tokyo source, additional raw charge | 5,135 | Separate source accounting |
| Data plus identified embedded content | 2,866,103 | Not a transport measurement |
| Conservative total charging all mixed runtime source | 2,939,964 | Not an additional charge on the previous row |

The data-only total is already 28.61 times the goal. The feature packet alone is 124,649 raw bytes even though its gzip size is below 100 KB. Summing individually gzipped files is a reproducible transport comparison, not the measured HTTP transfer size of the final export.

The accounting script scans every file under the Tokyo runtime data directory. It also charges the complete station building/roof functions and the city palette as a conservative way to catch Tokyo dimensions and art constants embedded in code. Those excerpts belong to the larger mixed-source total and must not be counted twice. These tables use the [pinned current-file ledger](tokyo-fidelity-evidence/results/final-receipts/tokyo-byte-ledger-pinned.json), copied unchanged from `tokyo-byte-ledger.json` at SHA256 `d23cd8f9469905f603315d587fca9dd5d1500aa19374ba78ad426e92445bc83b`. The integrator will rerun the final delivery ledger after the last capture and source changes; this snapshot is not a claim that those later totals are frozen.

| Reuse category | Recorded source bytes | Meaning |
| --- | ---: | --- |
| New generic runtime modules | 57,245 | Five data-driven decoder, mesh, shader or projection modules; separate from Tokyo content |
| New mixed runtime modules | 78,996 | Four files combining generic behavior and city-specific integration; not silently declared fully shared |
| Changes to existing runtime files | +8,767 net | Six files with verified baseline sizes; net source growth does not mean every added byte is generic |
| Existing interior-generation files | 23,465 | Eight files matched both the pre-Tokyo SHA256 inventory and canonical Git blob IDs; measured Tokyo delta was zero |
| Offline build and measurement tools | 72,539 | Thirteen tools, excluded from runtime city bytes |

These source byte counts answer the request to track reusable code. They are not exported-resource sizes, and a generic API does not prove that many cities already consume it. The existing-file delta now records game/world/input integration growth separately. Engine WASM, exported PCK, decoded memory and generated GPU resources remain separate measurements. Preserve those distinctions when comparing later cities.

The adopted separation makes two observed changes local. Spatial partitioning changed the packet while the renderer continued consuming the same road descriptors. Curating street labels changed only dictionary/reference data while every geometry and grade field remained equal. All eight measured existing interior files have zero Tokyo delta at their pinned hashes. These are concrete integration results.

## What the independent oracle found

The independent implementation recreated the old PWLINE01 baseline byte for byte: 2,785,712 bytes, SHA256 `9b4004c62f0f76798c21c025491ff0e53ed1bb0173965e8a3ddfd8b6024ef79c`. It imports neither the frozen encoder nor the new codec implementation.

The old simplifier changed repeated-node incidence in 105 ways. It pinned nodes shared between ways but could remove a repeated node within one way. Comparing connected-component counts alone missed that defect. Pinning repeated source occurrences repairs the incidence sequences and increases the retained vertex count from 738,726 to 738,822, a net addition of 96.

The repaired canonical representation preserves all 232,054 anchor-node identities and every per-way anchor incidence sequence. Source and candidate have 370 connected components, and the complete component partition matches. Every road class, bridge/tunnel flag and layer matches. A bridge approach sharing an actual OSM node stays connected even when the adjoining segments have different layer tags. Unrelated two-dimensional crossings are not inferred to be junctions.

These are undirected source-identity graph checks. One-way restrictions, legal turn restrictions and excluded roads are outside the contract. Source node IDs are retained in the offline canonical fixture, while source way IDs are encoded for runtime identity. Matching this graph does not prove that all segment-interior crossings or collision meshes preserve reachability.

The repaired 0.5 m candidate has source-vertex-to-corresponding-segment p95 error 0.619 m and maximum 1.279 m. Compared with the old baseline, p99 added vertex error is zero and maximum added error is 0.977 m. The largest whole-way length change is 0.181%. These checks cover all 1,126,725 raw source vertices and all 738,726 baseline vertices. Corresponding-segment distances are conservative nearest-polyline bounds. They are not a symmetric continuous Hausdorff certificate or a shortest-route proof.

The final curated road packet matches the independent decoder on every ID, point, selected name, flag and layer. Its SHA256 is `c1928a720ef7613a28c182a74ddb70baaba475a43125f56d8651c231129178b9`. Its canonical line SHA256 is `31fa85d0c7bd442453840faad0919122d97a45e5f4e57cb665f0b20326d4e91a`. Comparing it with the preceding spatial-block packet also proves unchanged coordinate frame and record order.

Evidence: [full fidelity report](tokyo-fidelity-evidence/results/tokyo-independent-fidelity.md), [final packet receipt](tokyo-fidelity-evidence/results/independent-curated25-packet-decode.json), [topology receipt](tokyo-fidelity-evidence/results/canonical-topology.fidelity.json).

## Resolution experiments

All experiments keep physical scale in metres. Integer coordinate steps are encoding choices. The game was not globally rescaled to make integers smaller. Candidates were generated from the same frozen source, rather than repeatedly rounding an already lossy packet.

The road coordinate sweep fixes repeated-node pinning, the existing class-dependent simplification and 50 experimental street names. These rows are controlled comparisons, not the final 25-name packet. The adopted simplification uses 1.0 m for the lower road classes and 0.6 m for higher classes.

| Road grid | Raw road bytes | Added vertex p95 / max, metres | Same-grade coordinate collision groups |
| --- | ---: | ---: | ---: |
| 0.125 m | 3,237,088 | 0.280 / 0.944 | 0 |
| 0.25 m | 2,987,186 | 0.354 / 0.953 | 0 |
| 0.5 m | 2,712,046 | 0.000 / 0.977 | 2 |
| 1 m | 2,461,067 | 0.707 / 1.202 | 54 |
| 2 m | 2,318,903 | 1.118 / 1.578 | 331 |
| 4 m | 2,246,867 | 2.236 / 2.828 | 2,663 |

Distinct source nodes sometimes round to identical coordinates. These groups would become false joins if a consumer used coordinate equality as graph identity. The explicit offline identity graph remains unchanged at every grid. Finer quantization does not remove the earlier simplification error or create better source surveying accuracy.

Moving from 0.5 m to 4 m saves only 17.2% of road bytes. The 4 m candidate still exceeds 22 times the entire city budget. Short ways also expose large percentage changes with small denominators: one 0.5 m baseline way becomes 5.657 m at the 4 m grid. That is a serious local distortion, not evidence of a thousand-percent long-route error.

![Road size, added error and rounded-node collisions](tokyo-fidelity-evidence/results/tokyo-resolution-tradeoffs.png)

Uniform simplification was swept separately at a fixed 0.5 m coordinate grid. Every row has an encoder round trip; the independent geometry lane fully audited the 2 m and 8 m stress candidates in addition to the adopted baseline.

| Uniform tolerance | Retained vertices | Raw road bytes | Independent added-error finding |
| --- | ---: | ---: | --- |
| 0 m | 1,126,725 | 3,432,146 | Encoder measurement; not a full separate oracle run |
| 0.5 m | 810,581 | 2,843,669 | Encoder measurement |
| 1 m | 726,523 | 2,688,968 | Encoder measurement |
| 2 m | 648,596 | 2,547,401 | Actual counterexample reaches 2.524 m |
| 4 m | 588,320 | 2,434,828 | Encoder measurement |
| 8 m | 547,946 | 2,352,358 | Actual counterexample reaches 8.414 m; one way loses all geometric length |

The 2 m result exceeds the plan's proposed 2 m added-error ceiling. The 8 m result shows why preserved graph identities cannot substitute for shape checks. Exact nearest-segment checks confirmed the listed counterexamples; they are not artifacts of a loose bound. The proposed ceiling was a planning criterion, not permission to relax source fidelity.

Codec grouping edges were swept at 96, 192, 384, 768, 1,536, 3,072 and 6,144 m. Raw sizes ranged from 5,750,444 bytes at 96 m to 2,658,002 bytes at 6,144 m. Larger groups reduced directory overhead but increased local decoding work. Rendering chunks remain independently sized. The late spatial-block result below addresses that measured tradeoff.

Supplemental polygons were encoded at four coordinate grids. These are comparisons with the normalized source, rather than added error against the road baseline.

| Feature grid | Raw feature bytes | Max vertex movement | P95 ring area change | Collapsed polygons / added proper self-intersections |
| --- | ---: | ---: | ---: | ---: |
| 0.25 m, adopted | 124,649 | 0.176 m | 3.24% | 0 / 0 |
| 0.5 m | 117,728 | 0.352 m | 6.56% | 0 / 0 |
| 1 m | 114,732 | 0.704 m | 13.04% | 0 / 1 |
| 2 m | 113,387 | 1.408 m | 25.40% | 2 / 0 |

The adopted 0.25 m grid still has eight consecutive vertex pairs that coincide after rounding. Removing consecutive duplicates before triangulation is a renderer concern. The polygon analysis does not certify overlaps between separate features, entrances or road clearances. Saving another 11,262 bytes by moving to 2 m did not justify the measured polygon damage.

Building-envelope experiments covered all 16 combinations of 0.25, 0.5, 1 and 2 m dimensions with 0.5, 1, 2 and 5 degree yaw. The dominant error came before rounding. Replacing arbitrary footprints with minimum-area rectangles produced p95 sampled boundary error of 8.95 m and a 66.92 m maximum, although the median was only 0.0084 m. A blanket rectangle conversion was rejected. The numeric recipe streams measured 28,532 to 30,574 bytes, but exclude identity, metadata, landmarks, constraints and integrity overhead and therefore cannot be presented as complete city packets.

At 0.25 m dimensions, changing yaw from 0.5 to 5 degrees increased p95 rounding-only corner movement from 0.119 to 0.765 m, with 6.63 m maximum at 5 degrees. Boundary comparisons sampled vertices and edge midpoints in both directions. They are not continuous geometric certificates. The split between nearly rectangular and highly irregular footprints suggests a future bounded hybrid experiment with literal exceptions; no such winner was shipped.

The source lane also rounded 114 known or mapped heights at 0.25, 0.5, 1 and 2 m, producing maximum numeric errors of 0.12, 0.22, 0.5 and 1 m. Height precision does not resolve disagreements about which roof, podium or tower a source measures. Only 34 of the 100 landmark descriptors have a chosen source height. Missing heights remain null in the data, with any runtime inference counted and disclosed separately.

Interior precision was tested on 16 dimensions read from the pinned shared stair, ladder and room-graphics code. Grids of 1, 2.5, 5 and 10 cm respectively collapsed 0, 3, 5 and 7 sampled dimensions to zero. At 10 cm the lost dimensions include rail-post thickness and handrail radius. This was a numerical source-dimension experiment, not a generated-room traversal test. The shared interior code did not adopt a coarse universal grid.

The planned 0.5×/1×/2× procedural surface-detail sweep and matched 320×180/640×360 visual comparison were not completed as controlled experiments in these research lanes. Renderer diagnostics and final captures must not be presented as those sweeps. A mixed-precision production format and a full cross-city perceptual recognition study also remain unrun. The report retains these gaps instead of inferring visibility from pixel size alone.

## Sparse labels and discovery

The stored default has 25 street names plus 25 landmark names. The other 75 landmark descriptors remain present and unnamed. The runtime may show fewer labels than it stores; the current visible cap is six, with a names-off option. This follows the request to let shapes and geography do more of the orientation work.

The street curation targets exactly 3,710 explicit source way IDs. Every native Japanese name matches the mapping guard. Every chosen English label occurs verbatim on at least one mapped source way for that corridor. Of those ways, 1,414 already use the chosen English spelling, 2,213 use another nonempty English spelling, and 83 have no English tag. The latter two groups use the selected corridor spelling after their native identity is checked. This is sourced normalization, not a claim that every source segment carries the exact final English string.

Homonyms are scoped by IDs. The selection excludes 36 unrelated Chuo-dori ways, two Showa-dori ways and seven Sakurada-dori ways. It does not add guessed Takeshita Street geometry or label a Shinjuku Nakamise-dori way as the famous Asakusa approach. The selection is an editorial set of orientation aids, not an empirically ranked list of Tokyo's most recognizable streets.

The 50 selected street and landmark strings contain 813 UTF-8 bytes. Strings are only part of the cost: the final road name dictionary and references occupy 4,073 bytes. In the controlled road-format comparison, retaining 50 instead of all 3,959 names saved 113,845 bytes across strings and references. This is editorial savings, kept separate from codec efficiency and geometry loss.

The Latin-script display set needs the macrons `ō` and `ū`. The source lane's native Godot fallback-font probe found all required characters available without an extra font file. That is a glyph-availability result, not a browser layout or Japanese-font certificate. Japanese native names and the full provenance mapping remain offline.

Evidence: [independent curated mapping receipt](tokyo-fidelity-evidence/results/independent-curated25-source-mapping.json), plus `curated-street-names.json` and `curated-street-names-notes.md` in the source archive.

## Old-school and modern compression ideas tested

The early research suggested storing construction rules for repeated art and compact literal information for geography. Farbrausch's procedural tooling, TopoJSON's shared arcs, MapLibre's integer streams and meshoptimizer's ordering ideas informed the candidate list. None supplied a demonstrated 28-fold reduction for this frozen real-world road corpus. The primary sources are listed below.

| Idea and measured candidate | Result | Decision |
| --- | --- | --- |
| Compatible degree-two road chains | 142,720 chains; 2,599,443-byte chain packet plus 144,350-byte membership stream, total 2,743,793 | Reject for size; omitting membership would break the identity contract |
| Morton or XY row order | 2,911,278 or 2,923,839 bytes versus 2,712,046 baseline | Reject; smaller coordinate starts were outweighed by larger source-ID deltas |
| Adaptive literal/bit-packed/RLE integer columns | 2,451,000 bytes; 2,433,799 with delta of deltas | Best measured exact offline column result; no streaming directory or production consumer |
| Exact per-way construction recipes | Projected complete size 2,640,677 bytes including mode bits and unchanged sections | Actual recipe blob reconstructs geometry; complete projected packet was not emitted or integrated |
| Repeated identical step recipe | Preferred by only 72 ways | Tokyo does not contain enough exact repetition for this to explain most geometry |
| Literal source-node IDs | Additional 2,592,908 bytes | Too expensive as a default extra runtime table |
| Explicit sparse shared-junction index | Additional 1,944,595 bytes | Motivated the much smaller exception experiment below |

The recipe selector kept literal vectors for 106,621 ways, delta-of-deltas for 29,940, and endpoint-line residuals for 21,602. Its projected 71,369-byte saving counts every mode bit. It is a useful exact modeling result, but not a delivered smaller runtime atlas. A minimum-description-length district grammar, facade fitting and neighboring-road prediction remain hypotheses from the plan, with no hidden fitted Tokyo data placed in a shared decoder.

## Free Space results after the initial measurements

The exploration period followed concrete findings instead of selecting every experiment in advance. It produced both a useful runtime choice and useful negative results.

First, the directory sweep showed wasted decoding in large blocks. The codec lane divided dense regions spatially within the existing format. Directory predictions used 100 seeded source-way starts and a 200 m query radius. A 6,144 m grouping reduced raw bytes by 54,044 but raised mean candidate ways from 1,103 to 5,634. Spatial splitting to 256 ways reduced mean candidate ways to 730 while adding 26,975 bytes to the controlled 50-name baseline.

The lane then measured the actual Godot 4.6.1 provider at the same 100 queries for three passes.

| Partition | Cold median / p95 | Warm median / p95 | Median Godot query allocation |
| --- | ---: | ---: | ---: |
| Standard, up to 512 ways | 12.598 / 25.351 ms | 0.595 / 1.118 ms | 2.321 MB |
| Spatial, up to 256 ways | 8.673 / 14.666 ms | 0.568 / 0.934 ms | 2.218 MB |
| Spatial, up to 128 ways | 6.048 / 10.332 ms | 0.633 / 0.915 ms | 2.755 MB |

Every query returned the same source IDs. The adopted 256-way split cut cold p95 by 42.1%. The 128-way split was faster cold, but its directory grew from 1.313 to 2.137 MB and total measured allocation increased. The integrator chose 256 as the measured memory/latency compromise. This does not establish the optimal partition for every device.

Cold means a new provider with an empty decoded block cache. The OS file cache may be warm. These timings exclude mesh generation, gameplay, browser download, rendering and exported-game startup. The allocation metric is Godot `MEMORY_STATIC`, not process RSS or GPU memory. The timed candidates all stored the same 50 experimental names; the adopted 25-name packet has a separate full-data audit. No claim depends on treating its changed labels as a measured timing improvement.

Repeated queries confirmed the value of a bounded decoded cache. A separate 30-open experiment measured whole-packet integrity cost: checked median 10.630 ms versus 1.639 ms without that optional whole-file verification in the benchmark. The decision was to retain one verification per packet open and mandatory block CRCs. The faster unchecked number is not the promised load time.

Changing the render anchor after a query cleared six cached blocks before the next query. All 32 nearby source IDs matched and the maximum local float32 rendering difference from translation was 0.000311 m. This validates cache invalidation and local reanchoring for that query, not geodesic ground scale across the entire administrative region.

Second, the fidelity oracle found only two same-grade rounded-coordinate collisions at 0.5 m. That observation suggested storing exceptions instead of a complete node table. A **57-byte packet-bound sidecar** with three assignments and two split tokens reconstructs all 476,573 kept source-node equivalence classes across 738,822 vertex occurrences. The independent parser rejects wrong-packet, truncated and trailing overlays. It is tied to the earlier 50-name packet and is not shipped or used by the runtime; a new packet requires rebuilding the binding. It does not provide directional routing or certify segment-interior clearance.

Third, the focused actual-main-scene review found integration defects that byte measurements would miss. The responsible implementation lanes repaired them, and the retained probe passed 12 checks at its recorded source hashes.

| Finding | Observed correction |
| --- | --- |
| Facade material seed depended on which building first filled a shared cache | Seed now derives from the bounded material family; opposite visit orders are checked |
| A far survey pan could leave the player's ground chunk absent on landing | Ground state changes before pose refresh; the collision chunk is resident immediately and eight neighbors remain queued |
| Invisible ground geometry continued to build during orbit | A real queue stayed at six pending and three resident chunks across the observed frames |
| Authoritative rebase accumulation used float32 vectors | Double scalar origins produced zero accumulated error across 1,000 actual isolated rebase calls; former arithmetic drifted 1.639 m |

The earlier source-position rebase and revisit checks each measured zero absolute-position error. The probe also verified stable chunk fingerprints after the queue settled. It used an earlier 25-name packet and pinned production file hashes; this result is not silently promoted to the final export revision. See the [runtime review](tokyo-fidelity-evidence/results/tokyo-runtime-review.md) and [probe receipt](tokyo-fidelity-evidence/results/tokyo-integration-probe.json).

Late capture work measured static interior batching. Boxes sharing geometry and material were grouped into per-chunk MultiMesh instances. The [renderer receipt](tokyo-fidelity-evidence/results/final-receipts/interior-batching-results.json) compares all 80 matched physical stair frames. Median draw calls fell from 4,908 to 1,317 and measured static memory from 196,995,957 to 157,842,863 bytes. Submitted primitives increased from 150,283 to 201,271 because each instance group is culled together. The software capture interval changed from 89.951 to 85.7045 ms on Mesa llvmpipe. At most 42 of 230,400 pixels changed in any matched frame, about 0.01823%; maximum mean channel difference was 0.000775 on the 0-to-255 scale. Both traversals followed identical coverage and ascended 3.160226 m.

The [graphical invariance probe](tokyo-fidelity-evidence/results/final-receipts/interior_batch_probe_graphical.log) passes 3,263 checks over 320 source boxes, four rooms and 58 unchanged collision shapes. Geometry remains 3,840 triangles before and after; 31 instance batches reduce the counted mesh nodes from 320 to 44. These are the renderer lane's source-hash-pinned graphical receipts, copied unchanged into this archive. They were not independently rerun by the geography oracle. The development captures were not taken from published immutable review commits. PNG readback, software rendering and scheduling contribute to capture intervals, so these figures do not establish browser/phone FPS, all-room equivalence or the unrun surface-density sweep.

The [bridge receipt](tokyo-fidelity-evidence/results/final-receipts/bridge-deck-results.json) records a separate readability repair. The original deck triangles existed at about 15.025 m and supported the player; the bare deck lacked clear edges and markings. Generic inferred edge skins, barriers and markings were added while retaining the sourced centerline, layer and approach profile. The observed player remained supported over 2.8 m of horizontal movement, with no physical rise. This is one diagnostic bridge route, with human review still pending. It is not a whole-atlas clearance or bridge-architecture proof.

The same late work changed orbit publication to display completed tiles incrementally. The integrator reported first-mesh readiness of 6.11 ms warm and 17.76 ms cold in native headless runs, retaining 3,503 polygons, 159,954 vertices and nine tiles without skipped geometry, with 153 focused checks. Fog depth now follows survey altitude, and a Hamburg fog-state leak was repaired with 42 focused cross-city checks. Final revision, capture and test receipts belong to the delivery record; these updates have not been reclassified as independently audited data results here. The current runtime/shared-source ledger must be refreshed after these changes.

The projection audit found an inherited global-plane cost. Below 30 degrees latitude, source segment lengths in the frozen equirectangular frame differ in aggregate by 4.43% from mean-radius-sphere distances, with a 10.57% worst segment difference. The mainland band above 34 degrees differs by about 0.019% in aggregate. These errors precede codec quantization. The current evidence does not establish geodesically correct ground rendering on every remote island. A later local-geographic-frame comparison remains a concrete follow-up, with packet geography held fixed.

## Research guidance that survived implementation

For reusable visual assets, the useful old-school idea is a small set of procedural construction operations with stable inputs. It fits facades, roofs, rails, shutters and repeated material detail. It does not authorize inventing real road locations. The primary Farbrausch account and source repository explain that architectural distinction, without proving this project's target size. [S1, S2]

TopoJSON and MapLibre supplied concrete encoding mechanisms to test. Tokyo's chain membership and source-ID costs explain why a plausible topology or ordering idea can lose on this corpus. CGAL's topology-preserving simplification guidance explains why pinning visible endpoints is not a complete crossing test. These were design references; the implementation does not claim a full CGAL crossing certificate. [S3, S4, S6]

The inverse-procedural facade paper supports fitting repeated facade structure. It does not establish a street grammar for Tokyo. Only the abstract was available in the original research pass. Meshoptimizer and Godot MultiMesh remain references for spatial ordering and batching with explicit culling tradeoffs. Their existence does not certify the game's measured draw count or visual parity. [S5, S7, S8]

The engineering advice was applied as small interfaces and local changes. Matt Pocock's guidance favors hiding volatile implementation behind a cohesive interface. Fowler and Beck support a preparatory refactor for the immediate feature. Sandi Metz warns against forcing dissimilar behavior into a shared abstraction. The plan therefore used a common descriptor contract, one shared-runtime integrator and separate experiment paths, rather than a new general framework. Cursor PStack was workflow evidence for explicit implementation, parity review and independent verification, not proof that a particular orchestration stack is required. [S12-S16]

The Astra/Ultra prompting research in the original plan recommends explicit goals, initiative, instruction priority, bounded delegation and completion conditions. Mode selection belongs in the product controls; mentioning Ultra in the prompt does not configure it. The official guidance described Ultra in terms of parallel work and distinguished it from increasing effort on a single task. These are date-stamped findings from the planning pass, not a new model benchmark. [S10, S11]

For this project, the prompt specified one owner for shared runtime files, independent codecs and fidelity checks on frozen inputs, useful intermediate artifacts, and the fallback of completing a faithful build if 100 KB failed. It also made the Free Space phase explicit. Those instructions prevented a small downtown substitute, uncounted embedded geography or a transport-only size claim from being mistaken for the requested outcome. The plan contains the full copyable launch prompt.

## Acceptance limits and reproduction

The independent data checks are exhaustive for their stated retained records and vertices. Their limitations are equally specific. There is no full segment-interior crossing audit, all-pairs route distortion proof, global ground geodesic certificate or browser visual-fidelity certificate in this archive. Source footprints do not establish correct inferred heights, entrances, interiors or human recognizability. Native headless timings do not establish iPhone Safari, MacBook, browser frame time or GPU memory.

The source lane reports a native supplemental decode of about 73 ms and 9.78 MB additional Godot memory. The earlier main-scene probe recorded tens of milliseconds per generated chunk, with changing geometry counts during integration. Those runs cannot be combined into an apples-to-apples FPS trend. The final gameplay captures and repository verification must use the actual final integrated revision and remain tied to their own environment and artifacts.

Documentation has a separate incomplete gate. The [documentation validation receipt](tokyo-fidelity-evidence/results/final-receipts/tokyo-docs-validation.json) records zero Astro errors, warnings or hints, successful generation of 60 pages including Tokyo, and offline-worker generation. The complete build then fails the unchanged required-asset check at a historical audio file. The [canonical missing-media inventory](tokyo-fidelity-evidence/results/final-receipts/canonical-missing-required-or-linked-media.json) lists 54 required or linked files totaling 77,769,942 bytes. The recovery lane verified 122 canonical documentation files and recovered 47 exact media files plus five exact PWA icons. It did not delete historical references or weaken the gate. Generated pages are therefore not a claim of a complete, publishable documentation site. Both receipts are copied without modification, with original paths and hashes retained.

Use the [evidence index](tokyo-evidence-index.json) to locate exact inputs and receipts. After extracting the fidelity archive, `README.md` lists commands for the independent baseline reconstruction, coordinate and simplification audits, projection audit, packet reader, curated-name verification and ephemeral main-scene probe. `test_oracle.py` covers repeated-node incidence, valid bridge approaches, snapped distinct-node identity, the independent packet reader and malformed-packet rejection. Rebuilding road candidates requires the separately provided frozen source and codec archive; a fresh OSM query creates a new benchmark.

Map data is © OpenStreetMap contributors under ODbL 1.0. The source archive retains acquisition queries, attribution, per-snapshot hashes and the distinction between OSM and Wikidata evidence. The operator pages below support specific landmark form and height facts. They do not validate every dimension of the generated models.

## Primary references retained from the research

These URLs were documented and consulted in the original September 5 planning/source investigations. This consolidation uses their recorded findings and does not present them as newly rechecked web results.

- [S1. Fabian Giesen, Debris: Opening the box](https://fgiesen.wordpress.com/2012/02/13/debris-opening-the-box/), first-party account of procedural demo tooling.
- [S2. Farbrausch original source](https://github.com/farbrausch/fr_public), architecture reference, with licenses to review before any reuse.
- [S3. TopoJSON specification](https://github.com/topojson/topojson-specification), shared arcs, quantization and coordinate deltas.
- [S4. MapLibre Tile specification](https://maplibre.org/maplibre-tile-spec/specification/), geometry/property streams and integer encodings.
- [S5. Inverse procedural modeling of facade layouts](https://doi.org/10.1145/2601097.2601162), 2014 research paper; abstract-only access in the planning pass.
- [S6. CGAL polyline simplification](https://doc.cgal.org/latest/Polyline_simplification_2/index.html), topology preservation and error costs.
- [S7. meshoptimizer](https://meshoptimizer.org/), geometry ordering, quantization and runtime mesh compression.
- [S8. Godot 4.6 MultiMesh guidance](https://docs.godotengine.org/en/4.6/tutorials/performance/using_multimesh.html), batching and all-or-none visibility per MultiMesh.
- [S9. Godot 4.6 web export](https://docs.godotengine.org/en/4.6/tutorials/export/exporting_for_web.html), Compatibility/WebGL2 and export constraints.
- [S10. Official Astra model and prompting guidance](https://developers.openai.com/api/docs/guides/latest-model), the plan's model-specific source.
- [S11. Official model and effort guidance](https://learn.chatgpt.com/docs/models), the plan's Ultra/Max source.
- [S12. Matt Pocock's skills](https://github.com/mattpocock/skills), first-party workflow examples.
- [S13. Matt Pocock, codebase design](https://github.com/mattpocock/skills/blob/main/docs/engineering/codebase-design.md), cohesive interfaces and justified adapters.
- [S14. Martin Fowler, preparatory refactoring](https://martinfowler.com/articles/preparatory-refactoring-example.html), including Kent Beck's formulation.
- [S15. Sandi Metz, The Wrong Abstraction](https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction), evidence against forced reuse.
- [S16. Cursor PStack source](https://github.com/cursor/plugins/tree/main/pstack), workflow reference for explicit verification.
- [Hamburg integration](https://github.com/ThatGuySam/planetwide/commit/f18614c2c93a1e794cde7b7fdff6efcdda9af049), [Tulsa integration](https://github.com/ThatGuySam/planetwide/commit/5c6d5027c11cad87f65ef53fa05139fd3cfb62a4) and [CRT/desktop integration](https://github.com/ThatGuySam/planetwide/commit/e1b942da64ccaeae56b1c9bdc64f753a6ed4c7bd), historical planning anchors.
- [JR East restoration features](https://www.jreast.co.jp/en/e/press/20110903/index.html) and [restoration method](https://www.jreast.co.jp/en/e/press/20070501/index.html), facade floors and restored station domes.
- [Tokyo Station Gallery operator](https://www.ejrcf.or.jp/gallery/english/institution.html), station length and three-story form.
- [Tokyo Skytree operator](https://www.tokyo-skytree.jp/about/spec/structure/) and [Tokyo Tower operator](https://en.tokyotower.co.jp/plan/towerpedia/), sourced tower dimensions and form facts.