# The Geospatial Lakehouse Stack The six-layer production stack and five-stage data lifecycle for governed geospatial systems. Foundations - [The Geospatial Lakehouse](https://lakegeo.ai/architecture/) - [Geospatial Lakehouse Stack](https://lakegeo.ai/architecture/models/) - [Geospatial medallion architecture](https://lakegeo.ai/architecture/medallion/) Platform guides - [Build on Databricks](https://lakegeo.ai/architecture/databricks/) - [Build on Snowflake](https://lakegeo.ai/architecture/snowflake/) - [Build on Google Cloud](https://lakegeo.ai/architecture/google-cloud/) Publication contents Foundations - [The Geospatial Lakehouse](https://lakegeo.ai/architecture/) - [Geospatial Lakehouse Stack](https://lakegeo.ai/architecture/models/) - [Geospatial medallion architecture](https://lakegeo.ai/architecture/medallion/) Platform guides - [Build on Databricks](https://lakegeo.ai/architecture/databricks/) - [Build on Snowflake](https://lakegeo.ai/architecture/snowflake/) - [Build on Google Cloud](https://lakegeo.ai/architecture/google-cloud/) On this page 1. [Stack overview](#two-axes) 2. [Capability model](#capability-model) 3. [Lifecycle model](#lifecycle-model) 4. [Using both models](#composition) 5. [Application](#application) 6. [Frequently asked questions](#faq) Overview ## The Geospatial Lakehouse Stack The capability model describes what the production system must do. The lifecycle model describes the state of data as it moves through that system. Architecture diagrams often mix services, processing steps, and data states in one stack, which obscures ownership. Separating them shows who provides each capability and whether a dataset is raw, prepared, or ready for a consumer. Capability axis Which capability performs and owns the work? Lifecycle axis What state is the data in, and what can use it? Capability model ## Six capabilities form the production system. The model states what a geospatial data platform must provide without prescribing one vendor, product, or service layout. L1 #### Ingestion Managed incremental file ingestion from object storage, connectors for databases and applications, and a streaming path for live feeds. Vector, tabular, raster, and scientific array data enter through the same governed front door. L2 #### Storage and governance Governed tables for spatial values, a governed file store for raster and point-cloud data, one catalog with lineage and access control across tables and files, and a sharing mechanism that avoids unmanaged export. L3 #### Spatial compute Vector spatial SQL, a discrete global grid index such as H3 or S2, graph analytics, and a raster path using distributed libraries or a managed raster service. L4 #### Machine learning and AI Governed feature management, experiment tracking, a model registry, scalable inference, model serving, and vector search reading and writing the same governed data. L5 #### Orchestration Declarative or scheduled pipelines expressing the bronze, silver, and gold flow, incremental refresh, and streaming jobs that remain active for operational workloads. L6 #### Consumption Dashboards with map rendering, natural-language query, custom applications, governed sharing, and low-latency serving to operational systems. ![Layered diagram of the generalized geospatial lakehouse stack, showing ingestion, storage and governance, spatial compute, machine learning and AI, orchestration, and consumption.](https://lakegeo.ai/_astro/generalized-stack.DOATjWw5_2vLaAV.webp) **Figure 1** The platform-neutral geospatial lakehouse expressed as six capability bands. ### The layers assign responsibility. One managed service may cover several layers, while a specialist engine may supply part of one layer. Every capability still needs an owner, an operating boundary, and a governed relationship to the rest of the system. **Review rule.** Every source, store, processing engine, model, orchestrator, and serving surface should map to a capability layer. Components that map nowhere or duplicate another owner require an explicit reason. Lifecycle model ## Five states connect a provider to a consumer. Geospatial data moves through acquisition, preservation, preparation, product creation, and serving. Each state carries different guarantees and responsibilities. 1. 01**Acquire** Discover, license, task, receive, or transfer data from its provider. 2. 02**Preserve** Retain the source faithfully enough to reproduce every downstream representation. 3. 03**Prepare** Validate, normalize, index, and physically arrange data for its intended analysis. 4. 04**Productize** Create a governed output with explicit business meaning, quality, ownership, and lineage. 5. 05**Serve** Deliver fit-for-purpose representations to maps, applications, analysts, models, and partners. ### State must be visible in metadata. A valid source file is not necessarily analysis-ready, and an analysis-ready dataset is not automatically a business product. Catalog metadata should record the lifecycle state, producer, quality gates, and lineage of each governed representation. Using both models ## Map each workload across both models. A workload is a path through capability layers that moves data through lifecycle states. Point-to-polygon enrichment, for example, acquires reference polygons and located records, preserves both sources, validates and indexes geometry into prepared data, runs spatial compute to create a product, orchestrates the flow, and serves the result. The lifecycle axis describes the changing data state. The capability axis identifies what performs each step. ### Native capabilities and operated workflows An implementation may satisfy a capability with a native service, a governed workflow, or a specialist engine connected to the primary data platform. The choice changes ownership, cost, reliability, and required skill. It does not change the lifecycle state the workload must produce. Application ## Begin with one product. 1. 1. ### Name the decision and consumer. Choose an output tied to a real business action instead of starting with a platform-wide migration. 2. 2. ### Map the capabilities. Assign every source, store, engine, model, orchestrator, and serving surface to a layer and owner. 3. 3. ### Record lifecycle state. State the quality, lineage, and reproducibility gate required before each dataset moves forward. 4. 4. ### Expose operating boundaries. Label what the platform operates and what the implementation team must build and maintain. See more LakeGeo in your Google Search and AI results. [Make LakeGeo a preferred source on Google](https://www.google.com/preferences/source?q=lakegeo.ai) Questions ## Frequently asked questions ### Why are capability and lifecycle separate models? They answer different questions. Capability identifies which part of the system performs and owns work. Lifecycle identifies the state of data as it moves from a provider to a consumer. A single workload crosses both axes. ### Does every workload use all six capability layers? A production workload usually touches most layers, but it may not require a distinct component for every layer. One platform service can satisfy several capabilities as long as ownership and behavior remain clear. ### Is the lifecycle model the same as bronze, silver, and gold? The lifecycle model is broader. It identifies acquisition and serving as explicit states around preservation, preparation, and product creation. The separate Geospatial Medallion Architecture maps those states to acquire, bronze, silver, gold, and serve. ### Can one dataset exist in several lifecycle states? Yes. A source can remain preserved while analysis-ready and product representations are derived from it. Each representation should record its state and lineage so consumers know which guarantees apply. ### How should a team start using these models? Choose one bounded geospatial product. Map each system component to a capability layer, then record the lifecycle state of every important dataset. Missing ownership, duplicated components, and unstated quality gates become visible quickly. Publication details Identifier LGP-MOD-001 Version 0.1, public draft Published July 2026 License [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/) Suggested citation: LakeGeo, The Geospatial Lakehouse Stack, v0.1, public draft, 2026, https://lakegeo.ai/architecture/models/. Release history v0.1 July 2026 First public draft of the Geospatial Lakehouse Stack, including its capability layers, lifecycle stages, and adoption sequence. Canonical URL: https://lakegeo.ai/architecture/models/