# What is the Geospatial Medallion Architecture?

The Geospatial Medallion Architecture is a five-stage lifecycle for geospatial data, extending bronze, silver, and gold with explicit acquisition and serving stages.

Guide

The Geospatial Medallion Architecture is a five-stage lifecycle for geospatial data, extending bronze, silver, and gold with explicit acquisition and serving stages.

![Five translucent data planes rising as steps from rough terrain to an ordered table grid, threaded by one luminous line.](https://lakegeo.ai/_astro/what-is-the-geospatial-medallion-architecture.CsQyi9vE_Z1B0aVq.webp)

By [Sean Knight](https://www.linkedin.com/in/thatsean/) Published July 31, 2026

Most data teams already separate source records from cleaned data and finished outputs. That progression helps protect evidence, clarify quality, and keep unfinished work away from consumers. Geospatial data adds responsibilities that the familiar progression does not fully describe.

A source may require discovery, licensing, tasking, or a large transfer before storage begins. A finished product may still need a different representation before a map, application, analyst, or partner can use it. When those responsibilities remain implicit, ownership, cost, and quality requirements become difficult to govern.

The Geospatial Medallion Architecture makes the full lifecycle explicit while preserving the useful distinctions that teams already know.

![Five colored medallion stages with glyphs and guarantees, a brace marking bronze, silver, and gold as the familiar medallion, and the hatched acquire and serve stages extending it](https://lakegeo.ai/_astro/learn-thematic-medallion-v2.DLc3yo07_Z16Kd3e.webp)

_The five stages of the Geospatial Medallion Architecture: the familiar bronze, silver, and gold, extended by acquisition before them and serving after them, each stage with its own guarantee._

## What does the Geospatial Medallion Architecture include?

The Geospatial Medallion Architecture is a five-stage data lifecycle for geospatial systems: acquire, raw store as bronze, analysis-ready as silver, product as gold, and serve. It extends the familiar three-stage medallion convention, which organizes data into progressively refined bronze, silver, and gold layers.

The additional stages account for meaningful work on both sides of those layers. Acquisition covers how an organization obtains a source and establishes the conditions for using it. Serving covers how a governed product reaches a particular consumer. These stages have their own owners, costs, acceptance criteria, and operational risks.

This wider lifecycle is especially important in a [geospatial lakehouse](https://lakegeo.ai/learn/what-is-a-geospatial-lakehouse/), where data may support distributed analysis, maps, applications, and external sharing from related representations. Each representation needs a clear purpose without becoming a separate source of truth.

## What happens across the five stages?

**Acquire.** The first stage covers discovering, licensing, tasking, receiving, or transferring data from a provider. Tasking means requesting that a provider collect data for a specified place or time. Acquisition records the source identity, collection time, license terms, redistribution constraints, expected volume, transfer method, and delivery completeness.

These records establish whether the expected source arrived and whether the organization may retain and use it as intended. They also make acquisition work visible to downstream teams. If this stage is skipped, a file may enter storage without reliable evidence of its identity, completeness, or permitted use. Later processing cannot repair missing license terms or prove that an incomplete delivery was complete.

**Raw store as bronze.** Bronze preserves the received source faithfully. It is append-only, which means existing records are retained rather than silently overwritten. Provider metadata stays with the source, along with checksums. A checksum is a calculated value used to detect whether a file has changed or become corrupted.

Corrections create new records instead of replacing evidence used by an earlier result. Skipping faithful preservation removes the stable starting point needed to investigate past outputs or rebuild them after processing logic changes.

**Analysis-ready as silver.** Silver validates geometry and metadata, then normalizes coordinate reference systems where the intended analysis requires it. A coordinate reference system defines how coordinates correspond to positions on Earth. Silver acceptance criteria also cover documented assumptions about quality and intended use.

For spatial data, correctness alone does not make a dataset ready for analysis. Physical layout determines whether remote and distributed systems can use valid data efficiently. Partitioning divides data into manageable groups. Tiling divides spatial coverage into bounded areas. Indexing adds structures that help systems locate relevant records. Cloud-native formats allow systems to read needed portions of remotely stored data without retrieving every file in full, the concern at the center of [How does raster data work in a lakehouse](https://lakegeo.ai/learn/raster-data-in-the-lakehouse/).

A silver representation must therefore satisfy both data-quality and access requirements. If physical layout remains untreated, formally valid data may still be impractical for its intended analysis.

**Product as gold.** Gold creates an output with explicit business meaning. It identifies quality criteria, an owner, a consumer, and the inputs and processes behind the result. Lineage is the recorded connection between a result, its source representations, and the logic that produced it.

A gold product may be a feature table, exposure measure, change record, prediction, or another governed assertion. It does not need to be a visual map. Without defined meaning and ownership, a refined dataset can circulate without a clear statement of what it asserts or who is responsible for it.

**Serve.** The final stage derives representations for consumer access. A map client may need tiles. An application may need a lookup with low latency, meaning a short response time. An analyst may need a representation suited to scanning many records. A partner may need a governed share, which is a controlled form of data distribution with defined access conditions.

Several serving surfaces may represent one gold product. Each surface must meet its consumer’s requirements for latency, scale, security, freshness, and format. Serving remains distinct from gold because business meaning and access form are different responsibilities. If serving is omitted, consumers may create informal copies or interfaces that are difficult to govern and may outlive the product that produced them.

![Hand-drawn diagram of the geospatial medallion showing the acquire, raw store, analysis-ready, product, and serve stages with concrete examples inside each](https://lakegeo.ai/_astro/learn-geospatial-medallion.DfV09G2V_BdYy1.webp)

_The five stages with concrete examples: what acquisition records, what the raw store preserves, what analysis-ready adds, what a product asserts, and the forms serving takes._

## How does data move from one stage to the next?

The risk in any staged lifecycle is quiet promotion, where a dataset starts being treated as analysis-ready because it sits in the right place rather than because anyone verified it. The architecture closes that gap with a written acceptance test at each stage boundary. The move from acquire to bronze verifies that the expected source arrived, its identity and integrity were recorded, and its license permits the intended retention and use.

The move from bronze to silver tests geometry, coordinates, metadata, quality, and physical layout against the assumptions of the intended analysis. The move from silver to gold verifies the product’s business assertion, owner, consumer, lineage, and quality checks. The move from gold to serve confirms that the access representation meets consumer requirements without becoming an ungoverned source of truth.

The outcome of those tests belongs in the data catalog. A catalog is a managed record of available datasets and their properties. Folder names alone do not provide enough information for governance or discovery.

Catalog records should identify the lifecycle stage, steward, source lineage, creation process, quality checks, update cadence, coordinate reference system, spatial extent, temporal extent, and license constraints. Gold products should also state the business assertion they make and the consumer they support.

## How does the lifecycle handle corrections and change?

The hard case for any data lifecycle arrives months after publication, when a result is questioned and the preparation logic has changed since. The architecture prepares for that case with one strict rule: everything downstream of bronze must be reproducible from the preserved source and versioned processing logic. Bronze remains append-only. Silver, gold, and serving representations remain derivable and replaceable.

This rule makes corrections observable. A corrected source becomes a new record rather than a silent replacement. A new preparation method can create a new silver representation without erasing the one used by an earlier product. Lineage then connects each product and serving surface to the exact source representation and process used to create it.

Several lifecycle stages can coexist. Keeping bronze does not require freezing silver or gold. Teams can improve preparation methods, product definitions, and serving forms while retaining the evidence needed to explain previous results.

## Does adopting the lifecycle mean renaming everything?

A team that already runs bronze, silver, and gold tables may read a five-stage lifecycle as a renaming project. The architecture asks for something narrower. It requires that source preservation, analysis readiness, product meaning, and serving ownership each be explicit, and it leaves the labels to the team. A team may keep its own layer names so long as one label does not cover several incompatible guarantees.

The architecture also does not prescribe one serving surface or one permanent silver representation. Consumer needs may justify several serving forms, while new preparation methods may justify several silver versions. The constraint is that every governed representation records its purpose, state, ownership, and lineage.

Readers who need the normative requirements can consult the [medallion page of the LakeGeo architecture](https://lakegeo.ai/architecture/medallion/).

## Where should a team begin?

The wrong first project is an inventory of every spatial dataset the organization owns. Begin instead with one path from source to decision: a governed product tied to a defined consumer and business decision, with a bounded set of spatial sources.

Inventory every current representation along that path and label what is acquired, faithfully preserved, analysis-ready, productized, and served. Write boundary tests for source integrity, analysis readiness, product meaning, and serving fitness. Then rebuild one downstream representation from bronze and verify that its lineage identifies the exact source and transformation.

## About the author

Sean Knight is a serial entrepreneur in the San Francisco Bay Area who builds products and companies around AI and geospatial data. He opened his first business, a retail computer shop, at 17, then began his career as an astrophysicist. From there he moved into remote sensing and machine learning, eventually flying drones over glaciers in Alaska and New Zealand to build 3D point clouds. Today he runs LakeGeo, consults on AI, and builds AI agents that run geospatial pipelines on platforms like Databricks. Find him on [LinkedIn](https://www.linkedin.com/in/thatsean/).

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)

Learn

## Continue reading

[guide

### How do you build a geospatial lakehouse on Google Cloud?

Build a geospatial lakehouse on Google Cloud with BigQuery and S2 for vector work, Earth Engine for managed raster analysis, and governance across the composition.

](https://lakegeo.ai/learn/build-a-geospatial-lakehouse-on-google-cloud/)[guide

### How do you build a geospatial lakehouse on Snowflake?

Build a geospatial lakehouse on Snowflake with native spatial SQL and H3 in a governed center, plus Snowpark and container attachments for raster and graph work.

](https://lakegeo.ai/learn/build-a-geospatial-lakehouse-on-snowflake/)

LakeGeo

## Build geospatial work that can run in production.

Read the open architecture guidance or talk to LakeGeo about a geospatial strategy and delivery engagement.

[Read the publications](https://lakegeo.ai/architecture/) [Discuss an engagement](https://lakegeo.ai/contact/)

Canonical URL: https://lakegeo.ai/learn/what-is-the-geospatial-medallion-architecture/