GIS data lake
content(gis): GIS/location-intelligence cluster consolidation (final of 5 flagged clusters) — merged the one genuine duplicate (pointsav-gis-engine.md into location-intelligence-substrate.md; its own body said its core logic lives in app-orchestration-gis). More significant: found and fixed a corpus-wide wikilink collision — 7 articles cited [[co-location-methodology]] as the retail-cluster tier-scoring methodology, but that slug resolves to a real, unrelated article about data-center FACILITY co-location siting. No article for the real retail methodology existed under any slug, and the one place a scoring mechanism WAS described in detail (app-orchestration-gis.md) described a Haversine formula the real SCORING-METHODOLOGY.md V3 confirms was replaced by a 4-tier gate system — with 2 more articles describing the mechanism differently again, none matching each other or reality. Created substrate/retail-co-location-tier-methodology.md as the single source of truth (facts from the verified real methodology doc) and repointed all 7 citing articles (14 files EN+ES) to it. Fixed architecture/_index.md's MOC description, which had also mischaracterized the real co-location-methodology.md article. All content-matrix clusters now resolved.
@@ -39,7 +39,7 @@ As the stateful layer of the platform, `service-fs` is responsible for data pers ## Unikernel Implementation (Planned) The target production deployment is a low-overhead unikernel providing a restricted API for the [[service-business-clustering|`service-business`]] and [[service-places-filtering|`service-places`]] intelligence layers to read raw data and write back processed results, enforcing clean separation between storage and analysis concerns. **Current state**: the unikernel envelope does not exist yet — the landing zones described above are plain host-filesystem directories, read and written directly by the GIS ingestion and analysis scripts (verified against `app-orchestration-gis`'s own ingestion scripts, which read/write these paths with ordinary file I/O). The [[co-location-methodology|co-location methodology]] describes how the clustering output is used to generate tier rankings, once that analysis layer is built. The target production deployment is a low-overhead unikernel providing a restricted API for the [[service-business-clustering|`service-business`]] and [[service-places-filtering|`service-places`]] intelligence layers to read raw data and write back processed results, enforcing clean separation between storage and analysis concerns. **Current state**: the unikernel envelope does not exist yet — the landing zones described above are plain host-filesystem directories, read and written directly by the GIS ingestion and analysis scripts (verified against `app-orchestration-gis`'s own ingestion scripts, which read/write these paths with ordinary file I/O). The [[retail-co-location-tier-methodology|retail co-location tier methodology]] describes how the clustering output is used to generate tier rankings, once that analysis layer is built. ## See also