Asset identification and purpose

Initial implementation: September 19, 2026; original-file coverage expanded October 18. The Art Atlas at /tile-library/ displays descriptions, purposes and searchable IDs. The checked-in metadata registry ../tile-library/catalog-metadata.json now contains 8,303 individual image records, retaining the original 3,251 IDs and adding maintained production sources, prototypes, references, named exports and runtime derivatives. Local registration is not evidence of deployment or remote backup. Staging, generators and QA output remain excluded. Classic previews open production PNG files directly; derivatives remain in their own collection. SVG dimensions come from declared size/viewBox, with no claimed raster alpha channel.

Identity

source-originals/manifest.json records 1,273 project-referenced generator source records using portable installed paths, SHA-256 hashes and receipt filenames. It reuses 1,228 existing byte-identical images and preserves 45 additional original outputs without conversion. A missing generator pathname was resolved from its recorded checksum against an existing library file. provenance.generatorOriginal and the preview badge appear only for exact content matches; these files are searchable as untouched generator original. Historical receipts, including rejected work, do not confer production approval. Unrecorded generator outputs elsewhere on disk are outside this verified set.

• assetId: permanent file ID, initially WOG-A-000001 onward. Never renumber or reuse an ID. A new art version is a new file record. When explicitly renaming a file, migrate its existing record and retain the ID.
• entryId: collection-qualified catalog identity, such as WOG:places:town/market-town. Classic and illustrated versions of the same subject have different entry IDs. This also fixes ambiguity when expanding variations from either collection.
• file: exact image path. Entries can contain multiple files; each file's ID and metadata are available in the card's expandable metadata section.

Initial purpose classification

Purpose is separate from the existing production/pending/archive/reference usage filter. Both filters can be combined and are reflected in the URL. Search includes entry IDs, file IDs, descriptions, purposes, tags, checksums, profiles, related definitions and bound production resources. The JSON download includes the full registered inventory regardless of current filters. Advanced filters select compatible terrain, scene layer, image format, gameplay connection and specific metadata/art gaps. Combined metadata filters must match the same file within an entry.

Town and city art represents settlements formed from buildings and systems; the whole painting is not one destructible object. Lumber Village is classified as a forestry settlement and links conceptually to the implemented lumbermill definition, which consumes logs and produces timber. There is no dedicated lumbermill image in this inventory: its implemented prototype recipe shares the farm-shed motif with other industries. Verified operational motif mappings from public/dynamic-recipes.json are recorded separately as gameplayBindings; conceptual associations use relatedDefinition. A town's ground/detail companions are still scenery. The catalog's “World structures” collection refers to rivers, ridges, coasts and transitions, not construction-game structures.

The 20 runtime images in /assets/hex-landmarks/runtime/ are gameplay site portraits used by Region/Hex presentation and now appear in their own Hex landmarks collection. Their source PNGs, contact sheet and the two art-direction references remain reference assets; a shared public-assets directory no longer incorrectly makes the runtime landmarks reference-only.

Descriptions are initial editorial drafts based on manifest names, categories and existing design decisions; they are not a new visual audit. gameplayStatus explains the current role without declaring planned mechanics implemented. metadataStatus is separate from art approval. collection, family and usage preserve the initial catalog context.

Maintenance

tile-library/asset-metadata.js supplies initial entry descriptions and purpose rules. node scripts/update-asset-metadata.js registers new inventoried files in the JSON registry, preserving existing IDs and edited file descriptions. It never deletes historic records. Review existing records explicitly when changing their role or approval; the registry preserves editorial content instead of silently regenerating it. Newly discovered files remain browseable with draft descriptions and an unambiguous temporary path ID until registered. Missing registry data is reported by the browser while the rest of the library stays usable.

The generator also runs src/asset-metadata-enrichment.js to remeasure actual image bytes and refresh schema-2 derived sections from the frozen catalog manifests, the declarative Hex library, prototype recipes, structure definitions and family evidence. Creator, license, rights status, generation date, reviewer and approval date retain manually supplied values. Other fields in the generated sections refresh; edit their source declarations to change them. Original IDs, names, descriptions, purposes and editorial role records remain intact.

Expanded schema, September 19, 2026

Every record now includes these sections; unknown values use null, not guessed defaults. Empty lists mean no recorded matches. File format and alpha capability are measured from PNG/WebP headers; an alpha channel does not prove that any pixel is transparent. SHA-256 is computed from actual local bytes and compared with the frozen release inventory.

Shared gameplayDefinitions stores all 18 authoritative structure definitions once, including family, footprint, construction resources/work, staffing/labor, terrain/resource requirements, production inputs/outputs, rebuild/salvage factors, construction stages, supported command kinds, operational motif and stage fallbacks. The file record distinguishes a verified prototype binding from a related gameplay concept. A static settlement portrait does not acquire construction commands merely because a related definition is available.

Profile-specific Hero variants retain their own declared profile. Companion profiles come from explicit parent connectorMotifs relationships; prototype motif profiles come from the union of their bound recipes, with per-structure constraints kept separately. No filename-based profile guess becomes a routing permission. Exact family IDs and declared companion identities are preferred; filename family associations are labeled for review.

Source/runtime relationships for the 20 Hex landmarks use their declared paired paths. Identical-content relationships require matching complete-file SHA-256; files retain separate IDs. Higher filename version numbers do not automatically supersede or approve older images. Family receipts are explicitly historical context; only source entries whose SHA-256 matches the measured file become exact-content evidence. Private absolute generation paths and full prompts are not copied into this registry.

Detailed sections are built only when a card's metadata is expanded. The roughly 11 MB uncompressed registry is delivered with Brotli/gzip using the metadata-specific cache budget (32 MiB ceiling, Brotli quality 4); other static files keep their existing budget. This prevents richer metadata from producing a large uncompressed browser transfer or rendering thousands of closed detail rows at load.

In-game tile metadata overlay

The map's Metadata: Off / On button enables an inspection overlay, off by default. Region labels identify the rendered tile source by permanent asset ID, name, background/gameplay role and hex coordinates. Hovering or selecting a tile shows its purpose, terrain profile, canonical cell ID, scene layer and a link to the full catalog record. Live structures additionally show definition, stage, staffing and condition. Runtime derivatives resolve through declared source aliases, retaining the source artwork's ID.

Labels track the map camera, avoid collisions and are capped at 64. Global uses sparse strategic labels and identifies its vector representation without inventing painted asset IDs. Hex detail describes the parent hex portrait and explicitly identifies local sites as concepts. Labels do not intercept map input. Turning the overlay off immediately clears it without rebuilding scene caches or changing simulation state.

scripts/update-asset-metadata.js also generates public/tile-metadata-index.json, a compact projection containing only inspection fields and explicit runtime aliases. The game fetches this index once on first enable; it does not load the full catalog or preload artwork. A failed fetch preserves tile information and can be retried by switching off and on.

Remaining metadata to curate

• Creator, ownership/license and approval attribution where no reliable records exist.
• Intentional supersession links and semantic relationships not declared in a manifest.
• Placement constraints for unbound source history and future gameplay objects.
• Dedicated construction, damage and ruin artwork where current recipes use shared fallbacks.

The living world design remains the primary design entry point.

AI approval and sorting — October 7, 2026

The Art Atlas exposes a separate 100% approved by AI value for each file in review.aiApproval. It is false by default, including production, archived, reference, missing and unreviewed files. Approval records the exact SHA-256, reviewer, date, reason and decision evidence. A different measured checksum or missing file makes the approval ineffective. This is an editorial judgment of artwork for its declared map role; it does not certify new mechanics, performance or ownership rights. Metadata regeneration preserves the review, while new records start false.

The October 7 review initially accepted 31 local files: 16 terrain paintings across eight profiles and 15 compatible one-hex landmark portraits. Five landmark portraits with painted water or pronounced relief and six superseded forest/mountain/wetland paintings remain explicitly unapproved. Missing newer sources and runtime derivatives remain unapproved. See file decisions and hashes art-direction/ai-asset-approval-20261007.json. Terrain for forest, mountain and wetlands uses procedural geography until a suitable painting is reviewed.

AI approval and Availability combine with the existing filters. File filters must match the same file; previews and expanded metadata display only those matching files, including mixed approved/unapproved entries. Cards show approved-file counts. Sort by has 19 criteria: catalog order, name, permanent file ID, collection, family, purpose, review status, image format, scene layer, width, height, pixels, byte size, variants, compatible terrain count, gameplay binding count, metadata gap count, AI approval fraction and review date. Order selects ascending or descending. Sizes use the largest matching file; missing values sort last in both directions. All selections survive in the shareable URL, and sorting precedes the 48-card page limit. Clear filters restores catalog order and ascending direction.

Apply explicit decisions with node scripts/review-asset-approval.js docs/art-direction/ai-asset-approval-20261007.json; this command checks approved bytes before writing. Then run npm run assets:world to regenerate public/approved-world-art.json and npm run assets:check to verify both current bytes and generated output. New reviews need a new decision file; never auto-approve by production status or filename. The generated whitelist is the map's artwork contract. Source approval grants no permission to load a WebP derivative, packed sprite sheet or companion: those files require their own review. Keep map and registry updates together.

Composition review — October 10, 2026

The current approval set is 27 files: 16 terrain paintings and 11 landmark subjects. The forest shrine, lumber camp, iron mine and stone quarry lost approval after contextual blending checks. Retained landmarks require landmark-contact-1 composition and an explicit allowedProfiles list: ten use fields, and the caravanserai uses desert. In particular, the observatory and sacred spring are not approved on mountain/forest/wetland ground. The original byte hashes stay unchanged; this is stricter editorial suitability, not an image rewrite. Full opaque ground plates are not approved for map placement. See the October 10 decisions art-direction/landmark-blending-decisions-20261010.json and visual audit. Regenerate and check the world whitelist after any such decision; file IDs remain stable.

Uploaded input and safe synchronization — 18 October 2026

The 8,303-file uploaded atlas snapshot is the authoritative input for the remaining quality goal. Local recovery checks every file against its recorded SHA-256 and size and refuses to overwrite divergent local bytes. New corrections use versioned native files, independent permanent IDs and explicit original links. Four earlier unpublished local IDs were remapped after the upload; uploaded IDs were retained. A signature-first measurement pass corrects raster facts without changing approval or editorial provenance.

Publication includes the new native assets, registry records and checksum entries in one isolated atlas change over the current remote head. Before publishing, verify that the remote input has not changed; afterward read the live inventory, metadata and new files back and verify their hashes. The 322-entry deployed game whitelist remains separate from 326 local source approvals and ten additional unapproved context candidates.

Source-review synchronization batch — 19 October 2026

This update preserves all 8,317 published identities/hashes and adds two versioned native grounds. The 329-source catalog snapshot is separate from the deployed 322-source game whitelist. Eight additional individually inspected quiet-ground originals link to compatible reviewed outputs without granting approval to the originals. Fifty exact classic runtime reviews and their intended native-source bindings retain artist identity and unknown generation history. Rendering-support, role, contact, lifecycle and production gates remain explicit.