Generate-pass methods and decision record

Documentation index · Generation guide · Prerequisites

Scope and preservation policy

This is the central decision record for work whose proposed deliverable is a src.generate/generate-*.cc pass or infrastructure that selects generate-* Make targets. It intentionally excludes projection-algorithm, WebAssembly, browser, and general documentation evaluations.

The repository does not retain chat transcripts. It retains two durable forms of the generation discussions:

• converge-generation.md is the raw request and stage ledger; and
• this document and the pass-specific implementation notes summarize evaluation conclusions that can be supported by implemented code, profiles, data snapshots, tests, and committed documentation.

An evaluation request is not treated as an approved design. Where a proposed pass has no confirmed plan or implementation in the repository, the ledger below says so explicitly. This avoids turning an exploratory prompt into a decision after the fact.

Generate-pass evaluation ledger

The unnumbered solar/high-energy, atmosphere/cloud, and small-body/mission lines in the raw ledger are taxonomy notes, not extra passes beyond the numbered stages. Astronomy owns celestial solar, high-energy, and representative small-body content; Cloud-atmosphere owns terrestrial solar illumination and physical atmosphere observations.

Implemented evaluation conclusions

Stage 4.1: astronomy

The evaluation concluded that an astronomy pass is feasible for visualization and atlas placement, provided it does not claim observatory- or navigation-grade ephemerides. The implemented choices were:

• use the same six spherical projection implementations as terrestrial maps, with declination mapped to latitude and profile-oriented right ascension mapped to synthetic longitude;
• produce complementary all-sky, explicitly named ground-observer, and Hubble-observer products rather than one ambiguous view;
• make ground and Hubble JSON profiles the sole authorities for calculation timestamp, platform, orientation, instrument bands, transient window, source paths, and display budgets;
• keep normal generation offline through bounded, checked-in snapshots;
• use NASA Planetary Data for discovery/provenance, not as a universal sky catalog; use Gaia for stars, the NASA Exoplanet Archive for confirmed host systems, JPL elements and SBDB for Solar System bodies, and curated GCN/NSSDC/HEASARC context for persistent and transient high-energy sources, plus a checked CelesTrak OMM and SGP4 for Hubble;
• give each major planet a dotted true-apparent-angular-size outline while doubling the separate fixed legibility glyph; and
• state the approximation boundary: linear Gaia proper motion, approximate major-planet and lunar elements, two-body small-body propagation, simplified sidereal/visibility calculations, and no atmospheric or terrain model.

JAXA Earth data is not a source of celestial coordinates and is now consumed by the separate Stage 4.1a pass. The astronomy implementation, exact formulas, source-role table, validation, and deferred precision work are recorded in astro-implementation-notes.md.

Stage 4.1a: Cloud-atmosphere

The evaluation concluded that a physical atmosphere pass is feasible if it preserves source coverage and time rather than filling gaps or presenting a mixed-age mosaic as simultaneous. The confirmed and implemented choices were:

• use credentialed P-Tree Himawari-9 L2 Cloud Property 1.0 for physical cloud fraction, optical thickness, top height, and ISCCP type;
• keep P-Tree’s regional and daytime-only coverage visible, with missing cells defined as unobserved rather than clear or zero;
• calculate subsolar position and twilight at one process-start instant, sharing the exact solar ephemeris with astronomy without duplicating celestial sources or observer-horizon layers;
• use public JAXA Earth STAC COGs for GCOM-C daytime AOD at 500 nm, GSMaP daily gauge-adjusted precipitation rate, and JASMES daily surface shortwave radiation, while retaining each source interval and a latest-not-after rule;
• keep AOD distinct from observed smoke and PM2.5 exposure, and precipitation distinct from floods and extreme-event counts;
• normalize QA-filtered raster samples into resolution-3 H3 cells before the six shared projection implementations; and
• keep credentialed network refresh and large local observations outside make all, with explicit fetch, prepare, verify, SVG, and artifact targets.

The source matrix, QA bits, profile schema, time contract, acquisition and preparation workflow, layer contract, terms, validation, and deferred water-vapor/GOSAT/EarthCARE classifications are recorded in cloud-atmosphere-implementation-notes.md.

Stage 4.2: Orbital Technosphere

The evaluation concluded that a human-made orbit pass is feasible at visualization scale, but that no single requested NASA source supplies the complete current Earth-orbit population. The implemented choices were:

• use Orbital Technosphere for public output and metadata while retaining generate-orbiting as the concise Make and source namespace;
• use CelesTrak OMM CSV as the broad population and category-membership feed, the Vallado/CelesTrak SGP4 reference implementation for propagation, and NASA SSCWeb positions as independent checks for selected spacecraft;
• treat the supplied Wikipedia pages and Starlink infrastructure essay as terminology and design context, not reproducible catalog truth;
• store the exact calculation instant, make-invocation reference location, catalog roles, freshness rules, visibility rules, and budgets in a JSON profile rather than reading host time or inferring location;
• produce a global terrestrial-subpoint product and an above-horizon observer product for every projection; and
• bound the claim to visualization: public-element age and uncertainty, simplified Earth orientation and illumination, and absence of covariance, maneuvers, photometry, weather, or operational safety guarantees remain explicit limitations.

The naming alternatives, source matrix, OMM/SGP4 conversions, coordinate pipeline, detiling layers, tests, and accuracy boundary are recorded in orbital-technosphere-implementation-notes.md.

Stage 4.4: cumulative network-swarm

The evaluation concluded that the corrected cumulative aggregate is feasible as a density atlas, but not as a graph because its Point features contain no edge or route semantics. The confirmed and implemented choices were:

• pin the corrected house-of-the-dragon-301 ZIP and both compressed and uncompressed SHA-256 digests while retaining a variable local source;
• validate the cumulative FeatureCollection, all ten unsigned downloader fields, unique resolution-5 H3 cells, coordinates, and source metadata;
• group under H3 resolution-3 parents, split groups at projection-native cells, and use Izzi center-filled radial hexagon positions;
• attach optional displacement tethers to true projected coordinates without representing them as traffic links;
• treat the overlapping specialized counts as independent semantic layers, with fixed log/p99 scales and raw values preserved in the SVG;
• generate one layered network-swarm map on each production projection and export all six SVG/PDF/PNG products; and
• bound interpretation to cumulative, source-defined aggregate observations, not simultaneity, rates, bandwidth, endpoints, causality, or peer flows.

The input audit, visual-reference conclusions, profile, clustering formulas, Izzi lattice safeguard, layer grammar, verification, previews, and deferred edge-data work are recorded in network-swarm-implementation-notes.md.

Stage 4.5: Bathymetry Roulette

The evaluation concluded that a roulette bathymetry pass is feasible by reusing the twelve nested Natural Earth depth polygons as projection-safe SVG clips and Izzi’s closed roulette paths as explicit page-space form fields. Stage 13 revised the confirmed choices to:

• use the canonical name bathymetry-roulette, while accepting the requested bathymetry-rolette spelling and historical art-agua-roulette name as generation-profile aliases;
• start at the cycloid boundary d/r = 1, prohibit lower values, and increase the exact point-distance ratio strictly with depth to 5.00;
• use even-odd-filled forms at every depth with fill and stroke fixed at 30% opacity;
• restore the original twelve-step Natural Earth blue ramp as a redundant depth cue;
• expand each representative depth curve into twelve deterministic diameter, phase, and center-offset variations without spatially perturbing d/r;
• assign nearby field cells through 24 jittered projected-page Voronoi sites, with two regions per variation and no hard curve clip at region boundaries;
• place those curves on staggered 1.10-unit projected-page cells with overlapping diameters, producing a continuous field rather than an icon grid;
• serialize every curve instance instead of using SVG pattern references, with no artifact-size constraint on this generative pass;
• paint nested thresholds shallow to deep with a common opaque ground, making visible exclusive bands without polygon differences;
• retain the six-production-projection topology and a complete visible key; and
• accept dense interference and moiré as intentional artwork while making clear that neither encodes additional bathymetric measurements.

The exact twelve-row catalogue, SVG layer contract, products, verification, and interpretation boundary are recorded in bathymetry-roulette-implementation-notes.md.

Stage 4.6: Bathymetry Hamonshū

The second art pass retains the revised depth clips, blue ramp, 30% opacity, field spacing, Voronoi grouping, shallow-to-deep replacement, explicit path serialization, and accepted-moiré policy. It replaces the roulette engine with twelve source-indexed wave motifs from Izzi’s procedural interpretation of Mori Yūzan’s 1903 Hamonshū, volume 2. Depth increases Izzi’s native density and curvature parameters instead of inventing a d/r analogue; motifs remain stroke linework because many source forms are open polylines. The canonical standard-pass name is bathymetry-hamonshu, with hamonshu and art-agua-hamonshu profile aliases.

The source selection, exact depth table, field/layer contract, provenance, commands, verification, and interpretation limits are in the Bathymetry Hamonshū implementation notes.

Stage 6a: World Game resources (historical method record)

The evaluation found an inspectable primary scan for Fuller and McHale’s 1963 Inventory of World Resources, Human Trends, and Needs, but no licensed, machine-readable corpus covering every World Game archival resource. The confirmed and implemented bounded product therefore:

• transcribes all 40 headings, world totals, and asterisk-marked leaders from the report’s explicitly selected 1960 production matrix;
• retains source units and page pointers, preserves Thorium’s N.A. as null, and does not infer values from blank country cells;
• records historical country labels while mapping only documented representative points, never extraction sites or modern boundary claims;
• checks in the factual profile but neither the rights-restricted scan nor its page images, and provides no automated BFI fetch;
• treats OCR as a human-audit aid rather than profile authority; and
• adds selected fisheries, aquatic production, primary-crop, and installed solar indicators as visibly separate, year- and source-labelled modern context rather than a continuation of the 1960 matrix.

This result is retained here only as the historical method and feasibility record. Stage 6b does not reuse its values, categories, representative leader points, profile, or rendering model. The cutover removed the old generated files and generation rules rather than retaining an opt-in compatibility product.

Stage 6b baseline and Stage 12 resources expansion

The re-evaluation concluded that “resources” is not one comparable scalar and must not be represented by a collection of country-leader points. Stage 12 retains the Stage 6b metric-separation rule and implements six target families:

• resources-energy for capacity, generation, extraction, refining, and explicitly scoped processing;
• resources-food for crops, livestock, fisheries, aquaculture, and separately defined dietary-energy or protein supply;
• resources-fauna for fisheries and spatially explicit reef condition or threat data;
• resources-flora for land cover, forest density and change, biome classes, and sampling-aware plant biodiversity;
• resources-mineral for current mine/refined production, reserves, processing, and trade by commodity; and
• resources-human for literacy, ISCED attainment, age structure, patents, equality, mobility, and defensibly named quality-of-life measures.

The canonical flora spelling is resources-flora; ressources-flora is an input alias only. Each family produces metric-specific artifacts so unlike units are not combined into an invented score. Country choropleths and global fields provide the non-sparse baseline; audited facilities, deposits, occurrences, and legal-policy observations are supplemental unless they pass a documented coverage gate.

The released v3 catalogue contains four energy products (solar, wind, nuclear, and precisely labelled petroleum-refinery throughput), food production, fisheries production, a 7,215-cell field derived from actual WRI reef geometry, forest-area percentage, rare-earth mine production, and five human products: population under 30, population over 60, upper-secondary attainment, bachelor’s attainment, and resident patent applications per million. Literacy and advanced-degree candidates remain documented failed coverage attempts rather than sparse release maps. The source catalogue, normalized country/spatial schema, explicit refresh workflow, and release thresholds are recorded in the Resources Stage 12 enrichment plan and implementation notes.

Stage 8: Anthropocene observation atlas

The evaluation concluded that a multi-source climate-impact observation atlas is feasible, but a generic point count cannot attribute each mapped event to human-caused climate change. The confirmed and implemented choices were:

• fix the default duration to literal calendar year 2026 in JSON, retain a source-specific partial-snapshot date, and never infer either from the host clock;
• aggregate positive unique source-reporting days into resolution-4 H3 cells, preserve raw counts and source roles, and define absence as unobserved or unavailable rather than zero;
• keep temperature highs, temperature lows, precipitation records, heavy precipitation, active fire, observed smoke, flood/heavy-rain reports, severe-weather reports, and PM2.5 exposure as independent semantic layers;
• use EPA AirData for the enabled-by-default air-quality-exposure:pm25-exceedance-days layer and keep it categorically and visually distinct from NOAA HMS observed smoke;
• use public CWFIS daily hotspots as the default Canada/North America fire feed, support credentialed NASA FIRMS as the global/Russian point source, and retain Copernicus Sentinel-3 and Rosleskhoz as validation sources rather than pretending CAL FIRE supplies northern coverage;
• keep normal generation offline from a checksum-pinned normalized snapshot, with explicit raw fetch and candidate-preparation targets that cannot overwrite checked data; and
• classify ocean-heat:coral-bleaching-stress-days as scientifically valuable but require a separate reef-mask/raster phase, with Stage 8 verification rejecting an accidental coral metric group.

The source matrix, exact station-record and precipitation formulas, snapshot audit, additional resource classifications, fire-source research, SVG layer grammar, refresh procedure, products, and interpretation limits are recorded in anthropocene-implementation-notes.md.

The accepted Stage 15 revision replaces the unqualified v1 product with complete-2025 and partial-2026 particulate editions and retains the separate NOAA CPC analysis-field family for both years. The four pass IDs serialize global resolution-3 H3 fields where applicable, retain valid-day denominators, and distinguish an analyzed zero-record cell from missing or outside-domain cells. Year aliases generate all six projections. Observation refreshes still require credentialed NASA FIRMS input and must pass reporting-date plus world-region audits; the checked particulate snapshots explicitly contain zero FIRMS rows and are not relabelled as global fire coverage. Stage 15 also implements a credential-free synthetic PurpleAir-interface review and a bounded five-station water-debris experiment, both exploration-only. CAMS, observed PurpleAir, and broader ocean decisions remain in the Stage 8b enrichment plan and Stage 15 ledger.

Stage 9: network infrastructure

The evaluation concluded that a network-infrastructure atlas is feasible when cloud/CDN sites, physical submarine routes, and logical exchange membership remain distinct evidence classes. The confirmed and implemented choices were:

• rename the cumulative H3 pass to network-swarm, reserving network-infrastructure for infrastructure records and topology;
• read variable external Git checkouts through commit-, path-, digest-, and count-pinned profiles rather than copying upstream data into this repository;
• make the cloud/CDN site atlas a normal six-projection pass and keep all null geometries in provenance without inventing coordinates;
• put TeleGeography cable and exchange layers behind the explicit generate-network-infrastructure-topology rule, outside make all and generation-profile "all", with visible CC BY-NC-SA 3.0 attribution;
• render submarine paths as source-backed physical routes and exchange spokes as source-backed logical membership, never inferred fiber, peering, traffic, or cross-source connectivity;
• split and densify routes before shared projection seam processing, while all point families share a deterministic Izzi radial-hexagon collision layout; and
• reject source drift, malformed geometries, duplicate identifiers, profile count mismatches, topology without the license opt-in, and invalid SVG/XML metadata.

The audited counts, source discrepancy decision, license boundary, spherical hub formula, clustering behavior, layer contract, previews, and verification are recorded in network-infrastructure-implementation-notes.md.

Stage 7 configured-selection outcome

Stage 7 adds a project-level JSON preference for the common development case: select one or more projections, select one or more generation passes, and let a bare make build only that cross-product. The checked-in default selects Cahill-Keyes plus the Earth and complementary physical-feature passes.

The implementation keeps the existing Make dependency graph authoritative. The profile resolver translates validated names into existing, public Make targets; the generators still own all geographic, astronomical, orbital, SVG, and embedded verification behavior.

This distinction is intentional: Stage 7 selects generation passes, not individual semantic layers inside one generated SVG. Internal layer sets are generator-specific contracts. Selecting them would require a different schema and generator API rather than a build-orchestration preference.

Stage 7 orchestration methods evaluated

The selected approach has one deliberate limitation: configured generation produces layered SVG source artifacts. PDF and PNG format selection was not added to schema version 1 because the request concerned projection and pass selection, and exports are cheap to express with existing explicit artifact or aggregate targets. A later schema can add formats without changing the meaning of the current fields.

Selected workflow

flowchart LR
  JSON["generation-profile.json"]
  RESOLVE["C++ validator and resolver"]
  TARGETS["Whitelisted Make targets"]
  MAKE["Existing Make dependency graph"]
  SVG["Selected checked SVG artifacts"]

  JSON --> RESOLVE --> TARGETS --> MAKE --> SVG

generation-profile.json is the default input. generation-profile.h owns schema validation, alias normalization, and target expansion. The thin resolve-generation-profile.cc entry point provides machine-readable target output and the human-readable plan. The Makefile compiles it, makes configured the default goal, and invokes a recursive Make with the resolved targets.

The recursion is a useful boundary rather than a second build system:

• the resolver cannot inject recipes or variables because it emits names from a fixed projection/pass table;
• Make still decides whether each artifact is current;
• command-line settings such as NATURAL_EARTH_DIR, ASTRO_PROFILE, ORBITING_PROFILE, RESOURCES_PROFILE, compiler options, -B, and -j propagate normally; and
• explicit targets and make all do not read or depend on the selection profile.

Profile schema version 1

{
  "schema_version": 1,
  "description": "Fast Cahill-Keyes terrestrial development profile",
  "projections": ["cahill_keyes"],
  "passes": ["earth", "ocean"]
}

schema_version, projections, and passes are required. description is optional. Unknown members are rejected so a misspelled selector cannot be silently ignored. Both selectors are nonempty arrays; "all" is valid only when it is the sole item.

Normalization is limited and deterministic:

• matching is case-insensitive and _ becomes -;
• cahill_keyes, cahillkeyes, and ck become cahill-keyes;
• star_x and starx become star-x;
• autha_graph becomes authagraph;
• voroni remains accepted as an alias for voronoi;
• graticule becomes graticules;
• astro becomes astronomy;
• orbiting becomes orbital-technosphere;
• the former network name and short swarm name become network-swarm;
• infrastructure becomes network-infrastructure;
• fiber and fiber-map become fiber-synthesized;
• resource and the historical request typo resouces expand to the six resources-* family passes;
• energy, food, fauna, flora, mineral/minerals, and human, plus the corresponding resource-* spellings, normalize to their canonical family; fisheries and reefs normalize to resources-fauna; the requested ressources-flora spelling becomes resources-flora;
• bathymetry-rolette and art-agua-roulette become bathymetry-roulette; and
• hamonshu and art-agua-hamonshu become bathymetry-hamonshu; and
• ocean becomes water, the current name of the complementary Natural Earth physical-feature generation pass.

Aliases are canonicalized before duplicate detection. For example, ["water", "ocean"] is rejected rather than generating the same artifact twice.

The supported cross-product is:

Astronomy resolves to generate-astro-PROJECTION, which intentionally makes all-sky, ground-observer, and Hubble-observer products. Orbital Technosphere resolves to generate-orbiting-PROJECTION, which makes both global and observer products. The four terrestrial passes resolve to uniform generate-PASS-PROJECTION targets.

Network-swarm resolves to generate-network-swarm-PROJECTION and makes the one cumulative swarm product. The two bathymetry art selectors resolve to generate-bathymetry-roulette-PROJECTION and generate-bathymetry-hamonshu-PROJECTION, each making one blue depth map. Each canonical resource-family selector resolves to generate-resources-FAMILY-PROJECTION and makes every released metric in that family as a deterministic .svg.gz archive. The aggregate resources selector expands to all six canonical passes and all 14 products before targets are emitted. Anthropocene resolves to generate-anthropocene-PROJECTION and makes the 2025 and 2026 temperature fields; the source-separated observation atlas remains under explicit generate-anthropocene-atlas-PROJECTION targets. Network infrastructure resolves to generate-network-infrastructure-PROJECTION and makes only the cloud/CDN site atlas; licensed topology is intentionally not a profile-selectable product. Fiber Synthesized resolves to generate-fiber-synthesized-PROJECTION and makes the standard cleaned union whose complete 20260805 snapshot is the default visible layer. See the implementation notes.

Stage 7 adds uniform Cahill-Keyes aliases for the terrestrial rule. In particular, generate-earth-cahill-keyes produces only the whole-map Earth SVG, whereas the older generate-earth-ck compatibility target also produces 12 Cahill-Keyes slices.

Available generation methods

Saved development selection

Preview the resolved names, then build them:

make generation-plan
make

make configured is the explicit spelling of the default goal. Use make -B to force regeneration of only the configured selection.

For an uncommitted personal profile, create generation-profile.local.json and select it on the command line:

make GENERATION_PROFILE=generation-profile.local.json generation-plan
make GENERATION_PROFILE=generation-profile.local.json

Complete release artifact suite

make all

This remains the release/review build. It creates the complete layered SVG, PDF, and opaque-PNG suite, including all 84 Stage 12 resource maps plus slice and perspective families outside the configurable matrix. A clean checkout makes 32 lower-resolution thumbnails per projection. Locally recorded JAXA or topology authorization adds the corresponding optional preview; the complete JAXA-authorized graph makes 33 per projection, including those linked from the generated snapshot. The aliases generate-projections, generated-projections, and make-generated retain the same full-suite behavior. Use make assets-resilient for the bounded parallel first pass plus serial completion workflow used to prepare a static release bundle.

Projection, pass, and product families

Existing family targets are useful when the desired selection does not need to be saved:

make generate-star-x
make generate-earth-projections
make generate-astro-observer
make generate-orbiting-global
make generate-anthropocene
make generate-resources
make generate-network-swarm
make generate-network-infrastructure
make generate-fiber-synthesized
make generate-bathymetry-roulette
make generate-bathymetry-hamonshu
make generate-water-myriahedral-perspectives
make generate-ck-slices

Projection family targets generate SVGs unless their documented target says artifacts; resources stores those SVGs as deterministic .svg.gz archives. generate-orbiting-artifacts, for example, adds PDF and PNG exports for that product family. generate-network-swarm-artifacts does the same for all six network-swarm products. generate-network-infrastructure-artifacts does the same for the six cloud/CDN site products. The separate generate-network-infrastructure-topology and generate-network-infrastructure-topology-artifacts targets begin as explicit CC BY-NC-SA 3.0 opt-ins. After a fully successful authorized generation, the local persisted pass state makes topology a dependency of that checkout’s make all graph. generate-fiber-synthesized-artifacts exports the six standard checked-union submarine-fiber products in all three formats; it is neither credential-gated nor optional. generate-anthropocene-artifacts does the same for all 24 default 2025 and 2026 particulate and temperature products; generate-anthropocene-atlas-artifacts is a compatibility alias that exports the 12 year-qualified particulate products, not a legacy unqualified artifact. generate-resources-artifacts adds PDF and PNG exports to all 84 compressed Stage 12 SVG products. generate-bathymetry-roulette-artifacts does the same for all six roulette bathymetry products. generate-bathymetry-hamonshu-artifacts does the same for all six Hamonshū bathymetry products.

generate-snapshot-ck builds the 32 clean-graph 480-pixel-wide contact-sheet thumbnails and their Cahill-Keyes SVG prerequisites. Recorded JAXA or topology authorization extends the sheet with the corresponding optional product; the JAXA-authorized graph therefore has 33. authorize-external performs read-only credential/terms-boundary checks for selected optional P-Tree, NASA FIRMS, and network-topology passes; it does not fetch source data or accept provider terms. Its explicit mutating companion, generate-authorized-external, authorizes the entire selection first, then runs the P-Tree and licensed-topology full-artifact workflows and stages the FIRMS-backed Anthropocene review candidate. It never promotes or renders that candidate automatically. Its default pass list is filtered by local netrc, map-key, and license-acknowledgement presence with explicit skip notices; overriding EXTERNAL_PASSES requests strict behavior. A discovered P-Tree account gets the pinned per-user trust anchor automatically when missing. After every selected workflow succeeds, the driver atomically records only canonical pass names in .cartofreako/authorized-external-passes. Later make all runs include recorded JAXA and topology artifact graphs; FIRMS remains a review-only acquisition because it has no promoted renderer.

Exact targets and artifact paths

Multiple explicit targets already express an ad hoc matrix:

make generate-earth-cahill-keyes generate-water-cahill-keyes
make generate-geometry-star-x generate-graticules-voronoi

Generated PDF and PNG paths are also direct Make targets. Their pattern rules first update the corresponding checked SVG and then invoke Inkscape:

make assets.generated/cahill-keyes/png/earth-ck-44-22.png
make assets.generated/star-x/pdf/astro-observer-hubble-star-x-34-44.pdf

Input acquisition and verification

Acquisition remains explicit because it changes reproducibility inputs:

make fetch-natural-earth-10m
make fetch-astro-data
make fetch-orbiting-data
make fetch-anthropocene-data
make prepare-anthropocene-data
make refresh-resources-data
make prepare-network-swarm-data
make check-network-infrastructure-sources
make check-network-infrastructure-topology-sources

These are maintainer acquisition/preparation operations, not prerequisites automatically pulled into generation. In particular, normal astronomy uses the checked-in snapshots with make generate-astro; fetch-astro-data neither runs before it nor invokes it afterward.

refresh-resources-data is an explicit network-and-preparation maintainer operation. It stages upstream files in a temporary directory and rewrites the checked v2 candidates; normal generation never depends on it. See the resources implementation notes.

make check compiles and runs the native algorithm/API suite, including generation-profile schema and alias tests. SVG generators instead run their own structural validation whenever their generation target executes.

Scope boundaries and future extensions

The generation profile does not override astronomical, orbital, resources, Anthropocene, network-swarm, or network-infrastructure calculation properties. Their pass-specific profiles remain the sole authorities for source state, calculation or clustering choices, and display budgets. Stage 7 only decides which Make branches to enter.

The following remain explicit rather than configurable in schema version 1:

• SVG/PDF/PNG format selection;
• one astronomy product instead of both;
• one Orbital Technosphere product instead of both;
• Cahill-Keyes four- and eight-slice generation;
• Myriahedral perspective and face-group slice generation;
• the CC BY-NC-SA 3.0 network-infrastructure topology product; and
• semantic layer enable/disable switches inside a generator.

If repeated workflows justify schema version 2, formats and product variants can be modeled as additional validated dimensions. Individual SVG layer selection should be designed separately, with a shared naming contract and generator-specific dependency analysis, rather than overloaded onto the pass selector.