Principles

Principle

Evolution

CORE evolves in releases: v1 → v2 → v3. After cutover, products read the latest Conform shape through one Publish — with v1 history replayed into that shape (CORE→CORE), not left on a parallel endpoint and not rebuilt from wiped adaptor input. Auditors use LEGACY_Rn / archive when they need the literal old layout.

CORE v1 → v2 release

The canonical form changes (new columns, remodelled links, corrected Rules). Products still want one Publish — in the v2 shape — that can answer questions about facts first stored under v1.

Before · CORE v1

Conform

v1 table shape

Publish

products live here

History already in Conform — SRC may already be wiped

Cutover · CORE→CORE

1. CLONE → LEGACY_R1
2. Apply v2 DDL + successor Rules
3. Rebuild affected tables from clone + extensions

Not a TRUNCATE + reload from adaptor input

After · CORE v2

Conform

v2 shape · uplifted history

Publish

single consumer surface

LEGACY_R1

read-only audit snapshot

Same header_key values · v1 belief carried in v2 rows · no permanent dual Publish

Consumers always bind to the latest CORE shape. v1 history is replayed into v2 tables (same header keys); LEGACY_Rn keeps the pre-cutover snapshot for audit — not a second product endpoint.

What counts as a CORE change?

What counts as a CORE change

CORE is how Conform tables are formed — including Rules applied at load — not only the physical DDL.

Class	Examples
Conform DDL	Add column, rename, new entity, drop/replace link table
Rules (SPEC)	Wrong crosswalk, sign rule, vocabulary, type map
Promotion	Move `extensions` → typed column or child entity
Structural remodel	Domain-specific join tables → generic `_ROLE` / `_LINK` with `link_to_*`

A Rules correction is a CORE correction. Forward ingest alone does not fix history already stamped under the old rule.

Rules and Identity

Change surfaces

Conform

DDL · SPEC replay · promotion · remodel

Full-table rebuild on affected facts

Rules

Close wrong rule · insert successor

Rebuild every table that used that rule

Identity

Close/insert hubs & members

Re-run match jobs — Conform keys usually stay

Span / Publish

Projection DDL when joins change

Redeploy views — no historic row migration

Rules and Conform share one evolution surface. Identity can rebuild sameness without rewriting native Conform keys.

Rules — close the wrong catalogue row (system_to), insert a successor, then rebuild every Conform table on the release manifest that used that rule — replay natives from extensions.
Identity — close/insert hub and member versions; re-run match jobs. Identity rebuilds can run without rewriting Conform native keys. Header keys stay stable unless governance changes identity grain.
Additive domains — new entities with unchanged shared SPEC do not force a full rebuild of untouched tables.

What happens on a full-table rebuild?

Full-table rebuild

When a release affects a table, migrate the whole history that must stay queryable — not forward-only rows and not per-row schema versioning.

Table is…	Action
Not affected	No migration — leave as-is
Affected	`CLONE` → `LEGACY_Rn` → DDL → full rebuild from clone + `extensions` + Rules replay

Unmappable rows go to quarantine; the legacy clone remains evidence. Standard consumers bind to one current Publish — not parallel v1/v2 product endpoints.

Release motion (sketch)

# Manifest lists affected_tables for this core_release
CLONE SP_CORE_CONFORM → SP_CORE_CONFORM__LEGACY_Rn

for table in affected_tables:
  apply_ddl(table)                         # current shape
  close archive rows on live table         # do not DELETE
  insert uplifted successors               # replay extensions + successor Rules
  # warehouse_from on successors = migration acceptance time

rebuild_identity(affected_subjects)        # if sameness contracts changed
redeploy SP_CORE_SPAN / SP_CORE_PUBLISH    # one latest consumer surface

What changes between archive and uplift reads?

Archive vs uplift

After a shape uplift, the same header keys have two queryable lineages — not one overwritten history. That is how CRISP keeps tritemporal questions honest across releases.

Archive vs uplift

Migration closes the old-shaped row (does not delete it) and inserts a successor in the current shape. Default as-of APIs read the uplifted chain; archive APIs prove what was literally stored.

Archive chain

v1-shaped assertion · closed on uplift

literal as loaded

AS_WAS_AT_ARCHIVE(window)

Strict audit — old columns / old layout

Uplifted chain

v2-shaped successor · lineage → archive

default consumers

AS_WAS_AT(window) · AS_WAS · AS_IS

Platform belief in today’s contract

header_keystable across both chains

After a shape uplift, the same header keys have two lineages: literal archive rows and uplifted successors in today’s contract.

Entry point	Reads
AS_IS	Open uplifted chain — what we assert now
AS_WAS(T)	Valid slice on uplifted chain + current cluster — restatement
AS_WAS_AT(W)	Uplifted belief in window — today’s contract (default historical API)
AS_WAS_AT_ARCHIVE(W)	Archive chain @ window — literal shape as stored (compliance / forensic)

What's the checklist? Revisit Tritemporal

Checklist

Treat Rules corrections as CORE changes — close + successor + rebuild.
List affected tables on a release manifest; leave others untouched.
Clone before cutover; never silent UPDATE of legacy belief.
Keep one current Publish for products; archive/LEGACY for audit.
Default analysts to AS_WAS_AT; use AS_WAS_AT_ARCHIVE for old layout proof.

Next: Extensions Learn more about Governance