# RFC-TESSERA-3.0-PALEO-001 ## Palaeoenvironmental Sea Level Correction ### Status: Draft v0.1 ### Date: 2026-04-26 ### Supersedes: nothing — first RFC in PALEO series ### Referenced by: RFC-TESSERA-3.0-OCC-001 Section 8, tesserav3 README ### Note: Canonical copy lives in tesserav3 ssot/docs/v3/. This is a reference copy. --- ## Abstract TESSERA `elev_cm` values are referenced to modern mean sea level (MSL = 0), sourced from GEBCO 2025 using the EGM2008 geoid as vertical datum. This is physically correct and immutable. It must not be modified. Sea level has not been constant. At the Last Glacial Maximum (~20,000 BCE) global MSL was approximately 120m below present. At 8000 BCE (CIVICVS simulation period) it was approximately 20–30m below present and rising rapidly. At 0 CE (OTIVM Roman period) it was within ~1m of present. This RFC specifies: - A named epoch table with sea level offsets relative to TESSERA baseline - The canonical query by which any consumer (OTIVM, CIVICVS, future systems) derives land/sea classification at a given epoch without modifying the baseline - The pipeline work required to validate the offset values against the palaeoclimate literature - The scope boundary between TESSERA (physical reality) and consumers (interpretation and rendering) The sea level offset is never stored in `otivm.sqlite3` or `tessera.db`. It is applied at query time by the consumer. The baseline is inviolate. --- ## 1. Design Principles ### 1.1 The baseline is immutable `elev_cm` in `tessera_cells` records the physical elevation of each H9 cell centroid relative to modern MSL as measured by GEBCO 2025. It is not adjusted for epoch, not corrected for isostatic rebound, not modified by any scenario. It is a physical measurement. It does not change. Any correction applied to it — for sea level, for isostasy, for sediment accumulation — is an interpretation layer. Interpretation layers live in consumer code, not in TESSERA. ### 1.2 The epoch table is the contract The named epoch table defined in Section 3 is the shared contract between TESSERA and its consumers. OTIVM reads it. CIVICVS reads it. Any future system reads it. The offsets in this table are derived from the palaeoclimate literature and are citable. When the literature is updated or refined, the epoch table is updated — not the baseline data. ### 1.3 The offset is a threshold, not a transform Sea level correction does not require modifying elevation values. It requires shifting the threshold at which a cell is classified as land or sea: ``` land = elev_cm > sea_level_offset_cm ``` Where `sea_level_offset_cm` is negative (sea was lower in the past, so the land/sea boundary moves downward — more cells become land). This is a scalar comparison. No geometry is modified. No data is rewritten. ### 1.4 Isostatic rebound is deferred Glacial isostatic adjustment (GIA) — the rebound of landmasses after ice sheet removal — is spatially variable and adds significant complexity. Scandinavia was depressed by ~200m under the Fennoscandian ice sheet; the Mediterranean was largely unaffected. GIA correction requires a spatially varying offset per H9 cell, not a single scalar. GIA is acknowledged here and deferred to RFC-TESSERA-3.0-PALEO-002. For OTIVM purposes (Mediterranean basin, Roman and Mesolithic periods), the GIA effect is small relative to eustatic sea level change and can be treated as zero in the initial implementation without material error. For CIVICVS (Spree-Havel valley, 8000 BCE), GIA is more significant — northern Germany experienced ~10–20m of rebound between 10,000 BCE and 6,000 BCE. This is noted but does not block OTIVM-II delivery. ### 1.5 Relative sea level is not global sea level TESSERA records absolute elevation relative to a global geoid. Sea level at any specific location is the global eustatic signal plus local isostatic adjustment plus local sediment compaction. The epoch table in Section 3 provides eustatic offsets only — global average sea level change. Local corrections require GIA data (deferred) and sediment models (future work). For the Mediterranean, eustatic offsets alone are sufficient for a defensible first approximation. For the North Sea and Baltic, they are not. This distinction must be surfaced to the player when relevant. --- ## 2. Vertical Datum `elev_cm` in TESSERA is referenced to: - **Datum:** EGM2008 geoid (approximately equivalent to global MSL) - **Source:** GEBCO 2025 Grid - **Unit:** signed integer centimetres - **Range:** approximately −11,000m to +8,850m (full Earth surface) - **Zero:** modern mean sea level GEBCO 2025 uses a unified global grid at 15 arc-second resolution (~460m), resampled to H9 centroids (~180m) during TESSERA pipeline stage 00–01. The resampling introduces sub-metre error in areas of high terrain gradient. For coastline rendering this is acceptable at H7 and H5 resolution; at H9 resolution in steep coastal terrain (e.g. fjords, cliffs) visible artefacts may occur. This datum is consistent with the ICE-5G and ICE-6G palaeoclimate sea level reconstructions, which express past sea levels as offsets from present-day MSL. No datum conversion is required when applying offsets from Section 3. --- ## 3. Named Epoch Table The canonical set of epochs, their sea level offsets relative to TESSERA baseline (modern MSL = 0), confidence grades, and primary citations. All offsets are **eustatic only** — global average, no isostatic correction. Negative values = sea was lower = more land area than today. | epoch_key | label | approx_date | sl_offset_cm | confidence | primary_citation | |---|---|---|---|---|---| | `present` | Present day | 2025 CE | 0 | measured | GEBCO 2025 | | `roman_14bce` | Roman period, 14 BCE | ~14 BCE | −10 | indicated | Lambeck et al. 2004 | | `subboreal_3000bce` | Sub-Boreal, 3000 BCE | ~3000 BCE | −200 | indicated | Lambeck et al. 2014 | | `atlantic_6000bce` | Atlantic optimum, 6000 BCE | ~6000 BCE | −500 | indicated | Lambeck et al. 2014 | | `mesolithic_8000bce` | Mesolithic, 8000 BCE | ~8000 BCE | −2500 | indicated | Lambeck et al. 2014 | | `preboreal_10000bce` | Pre-Boreal, 10000 BCE | ~10000 BCE | −5000 | indicated | Lambeck et al. 2014 | | `younger_dryas_11000bce` | Younger Dryas, 11000 BCE | ~11000 BCE | −7000 | inferred | Lambeck et al. 2014 | | `lgm_20000bce` | Last Glacial Maximum, 20000 BCE | ~20000 BCE | −12000 | indicated | Clark et al. 2009 | | `eem_125000bce` | Eemian interglacial, 125000 BCE | ~125000 BCE | +600 | inferred | Dutton & Lambeck 2012 | **Note on `roman_14bce`:** Mediterranean relative sea level at the Roman period was within ~0.1m of present. The −10cm offset is within measurement uncertainty and may be treated as zero for rendering purposes. It is included for completeness and to prevent consumers from assuming present-day MSL is wrong for Roman-period content. **Note on `mesolithic_8000bce`:** This is the primary epoch for CIVICVS. At −25m, significant coastal areas are exposed relative to today — the Adriatic was shallower, the Po Valley more extensive, parts of the Aegean shelf were land. For the Mediterranean specifically, the effect is most visible in the Adriatic, the Gulf of Gabes (Tunisia), and the Nile delta. **Note on `lgm_20000bce`:** At −120m, the Mediterranean was dramatically different. The Sicilian Channel was partially exposed. Cyprus was larger. The Nile delta extended much further north. This epoch is included for future use; it is not required for OTIVM-II or CIVICVS v1. ### 3.1 Interpolation between epochs Consumers may interpolate linearly between adjacent epochs for animation or continuous temporal regression. Linear interpolation is not physically accurate — sea level rise was non-linear and punctuated by meltwater pulses (notably Meltwater Pulse 1A at ~14,600 BCE, ~20m rise in ~500 years). For game purposes, linear interpolation between the named epochs in Section 3 is sufficient and defensible as an approximation. When CIVICVS requires higher temporal resolution (decadal or centennial), RFC-TESSERA-3.0-PALEO-002 will specify a continuous curve derived from the Lambeck et al. 2014 far-field reconstruction. --- ## 4. Canonical Consumer Query Any consumer deriving land/sea classification for a given epoch queries `tessera_cells` as follows. This query is normative — consumers must not implement alternative logic. ```sql -- Land/sea classification at a named epoch -- :h5 = H3 res-5 integer ID of the waypoint hex -- :sl_offset_cm = sea_level_offset_cm from the epoch table (Section 3) -- negative = sea was lower = more land SELECT h9, lat, lon, elev_cm, CASE WHEN elev_cm > :sl_offset_cm THEN 1 -- land at this epoch ELSE 0 -- sea at this epoch END AS is_land FROM tessera_cells WHERE h5 = :h5 AND status = 2 ORDER BY h9; ``` For coastline rendering at reduced resolution (H7 or H5), aggregate by the parent cell and classify as land if the majority of H9 children are land: ```sql -- H7-aggregated land/sea classification at a named epoch SELECT h7, COUNT(*) AS h9_total, SUM(CASE WHEN elev_cm > :sl_offset_cm THEN 1 ELSE 0 END) AS h9_land, CASE WHEN SUM(CASE WHEN elev_cm > :sl_offset_cm THEN 1 ELSE 0 END) * 2 > COUNT(*) THEN 1 ELSE 0 END AS is_land_majority FROM tessera_cells WHERE h5 = :h5 AND status = 2 GROUP BY h7; ``` The majority rule (>50% of H9 children are land → H7 cell is land) is the default. Consumers may use a higher threshold (e.g. 75%) for a more conservative coastline that errs toward sea. This is a rendering decision, not a data decision, and is not specified here. ### 4.1 What consumers must not do - Modify `elev_cm` values in the database - Store derived land/sea classification in the database - Cache epoch offsets inside the baseline schema - Treat the epoch table as immutable — it will be updated as the literature is refined, and consumers must read it fresh rather than hardcoding offsets --- ## 5. Epoch Table Storage The epoch table in Section 3 is the authoritative record. It is stored in two places: **In `otivm.sqlite3`** — as a read-only lookup table `paleo_epochs`, created by the schema script (`data/create_otivm_db.sql`). The OTIVM game server reads this table to resolve named epochs to `sl_offset_cm` values at runtime. **In this RFC** — as the normative definition. If the table in the database diverges from the RFC, the RFC takes precedence and the database must be corrected. ### 5.1 `paleo_epochs` table schema ```sql CREATE TABLE paleo_epochs ( epoch_key TEXT PRIMARY KEY, label TEXT NOT NULL, approx_date_bce INTEGER NOT NULL, -- years BCE, positive; years CE, negative sl_offset_cm INTEGER NOT NULL, -- offset from modern MSL, negative = lower confidence INTEGER NOT NULL -- FK to confidence_grades(id) REFERENCES confidence_grades(id), primary_citation TEXT NOT NULL, notes TEXT ); ``` This table is populated once at database creation and updated only when the RFC is updated. It is not a pipeline output — it is authored data derived from the palaeoclimate literature. ### 5.2 Work order for TESSERA assistant The following SQL insert block is the work order. It populates `paleo_epochs` in `otivm.sqlite3`. The TESSERA assistant must: 1. Verify the offset values against the cited literature before inserting 2. Add this INSERT block to `data/create_otivm_db.sql` in the OTIVM repo 3. Confirm that `confidence_grades` IDs match (1=measured, 2=indicated, 3=inferred, 4=no_data) as defined in `data/create_otivm_db.sql` 4. Commit to OTIVM `main` branch with message: "Add paleo_epochs table to create_otivm_db.sql per RFC-TESSERA-3.0-PALEO-001" ```sql INSERT INTO paleo_epochs (epoch_key, label, approx_date_bce, sl_offset_cm, confidence, primary_citation, notes) VALUES ('present', 'Present day', -2025, 0, 1, 'GEBCO Compilation Group (2025) GEBCO 2025 Grid (doi:10.5285/a29c5465-b138-234d-e053-6c86abc0dc7f)', 'Baseline. EGM2008 geoid, modern MSL = 0. No correction applied.'), ('roman_14bce', 'Roman period, 14 BCE', 14, -10, 2, 'Lambeck et al. (2004) Sea-level change through the last glacial cycle. Science 292(5517).', 'Mediterranean RSL within measurement uncertainty of present. Treat as 0 for rendering.'), ('subboreal_3000bce', 'Sub-Boreal, 3000 BCE', 3000, -200, 2, 'Lambeck et al. (2014) Sea level and global ice volumes from the Last Glacial Maximum to the Holocene. PNAS 111(43).', NULL), ('atlantic_6000bce', 'Atlantic optimum, 6000 BCE', 6000, -500, 2, 'Lambeck et al. (2014) Sea level and global ice volumes from the Last Glacial Maximum to the Holocene. PNAS 111(43).', NULL), ('mesolithic_8000bce', 'Mesolithic, 8000 BCE', 8000, -2500, 2, 'Lambeck et al. (2014) Sea level and global ice volumes from the Last Glacial Maximum to the Holocene. PNAS 111(43).', 'Primary epoch for CIVICVS simulation. Adriatic, Gulf of Gabes, Nile delta visibly affected.'), ('preboreal_10000bce', 'Pre-Boreal, 10000 BCE', 10000, -5000, 2, 'Lambeck et al. (2014) Sea level and global ice volumes from the Last Glacial Maximum to the Holocene. PNAS 111(43).', NULL), ('younger_dryas_11000bce', 'Younger Dryas, 11000 BCE', 11000, -7000, 3, 'Lambeck et al. (2014) Sea level and global ice volumes from the Last Glacial Maximum to the Holocene. PNAS 111(43).', 'Rapid sea level fall during Younger Dryas stadial. Offset is approximate.'), ('lgm_20000bce', 'Last Glacial Maximum, 20000 BCE', 20000, -12000, 2, 'Clark et al. (2009) The Last Glacial Maximum. Science 325(5941).', 'Sicilian Channel partially exposed. Cyprus enlarged. Reserved for future use.'), ('eem_125000bce', 'Eemian interglacial, 125000 BCE', 125000, 600, 3, 'Dutton & Lambeck (2012) Ice volume and sea level during the last interglacial. Science 337(6091).', 'Positive offset: sea was higher than today. Reserved for future use.'); ``` --- ## 6. OTIVM-Specific Requirements This section is addressed to the OTIVM game development assistant and documents the game-side requirements that drove this RFC. ### 6.1 Map rendering epochs OTIVM-II (current) renders the Mediterranean at the modern epoch (`present`, offset = 0). The coastline query uses the canonical SQL in Section 4. For OTIVM-III and beyond, the map must support rendering at any named epoch. The epoch is passed as a parameter; the SQL is unchanged. The UI does not need to expose epoch selection to the player in early releases — the epoch is set by the game narrative (Roman period = `roman_14bce`). ### 6.2 Fog-of-war cell classification When a galley travels a route, H3 cells along the route are revealed. The revealed cells must be classified as land or sea at the active epoch before rendering. The canonical query in Section 4 produces this classification. Cells classified as sea are rendered as water. Cells classified as land are rendered with terrain colour derived from `elev_cm` (relative to the epoch offset, not absolute). ### 6.3 Sea level as a game mechanic In future releases, the player may observe the coastline changing as the narrative moves through time. The epoch table in Section 3 provides the anchor points. The game transitions between epochs by interpolating `sl_offset_cm` and re-running the canonical query. No data changes — only the threshold changes. This is not a gimmick. A player who reaches Alexandria in the Roman period and later encounters journal entries referencing the Mesolithic shore is experiencing the same physical geography at two different sea levels, derived from the same `elev_cm` data, with a scalar offset that is citable to Lambeck et al. 2014. --- ## 7. What This RFC Does Not Cover | Topic | Future RFC | |---|---| | Glacial isostatic adjustment (GIA) | RFC-TESSERA-3.0-PALEO-002 | | Meltwater pulse events (non-linear SL change) | RFC-TESSERA-3.0-PALEO-002 | | Palaeoclimate terrain correction (vegetation, river courses) | RFC-TESSERA-3.0-PALEO-003 | | Hydrological restoration (palaeo-drainage networks) | RFC-TESSERA-3.0-HYD-001 | | Simulation temporal regression state | CIVICVS RFC stack | | Player-facing epoch UI | OTIVM game code | --- ## 8. Primary Literature All offset values in Section 3 must be verified against these sources before the epoch table is committed to `otivm.sqlite3`. This is the responsibility of the TESSERA pipeline assistant. - **Lambeck et al. 2014** — "Sea level and global ice volumes from the Last Glacial Maximum to the Holocene." *PNAS* 111(43): 15296–15303. doi:10.1073/pnas.1411762111. Far-field reconstruction, globally applicable, primary source for Holocene offsets. - **Lambeck et al. 2004** — "Sea-level change through the last glacial cycle." *Science* 292(5517): 679–686. doi:10.1126/science.1059549. Mediterranean regional reconstruction, primary source for Roman period. - **Clark et al. 2009** — "The Last Glacial Maximum." *Science* 325(5941): 710–714. doi:10.1126/science.1172873. LGM sea level −120m, primary source for `lgm_20000bce`. - **Dutton & Lambeck 2012** — "Ice Volume and Sea Level During the Last Interglacial." *Science* 337(6091): 216–219. doi:10.1126/science.1205749. Eemian +6m, primary source for `eem_125000bce`. - **GEBCO 2025** — doi:10.5285/a29c5465-b138-234d-e053-6c86abc0dc7f. Vertical datum reference. CC-BY 4.0. --- *RFC-TESSERA-3.0-PALEO-001 Draft v0.1 — 2026-04-26* *Produced by: OTIVM game development assistant* *Work order to: TESSERA pipeline assistant* *Status: Draft — pending literature verification of offset values before paleo_epochs INSERT is committed to data/create_otivm_db.sql* *Next action: TESSERA assistant verifies Lambeck et al. 2014 offsets, then adds paleo_epochs schema and INSERT to data/create_otivm_db.sql*