Explicit Publish Steps

Summary

When lakehouse-derived data becomes operational serving state, the transition should be visible as a publish step rather than hidden in a UI query or pipeline side effect.

Problem

Analytics transforms are rebuildable and batch-oriented. Operational surfaces need stable read models, ownership, and often audit context. If every consumer pulls directly from gold or silver, the boundary between analytical truth and interactive state becomes unclear.

Principle

Publish intentionally. A publish step says which data product is ready for which consumer and what shape downstream code can rely on.

Platform Shape

The architecture guidance says pipelines should not mutate OLTP state directly except through explicit publish steps. The lakehouse docs include a serving snapshot publication job in the core incremental DAG sequence and list jobs/lakehouse/publish_serving_snapshots/run.py as the job boundary.

Publishing is also a documentation point. It gives engineers a place to look for freshness assumptions, serving contracts, and downstream dependencies.

Source Evidence

• docs/reference/architecture.md
• docs/domains/lakehouse.md
• jobs/lakehouse/publish_serving_snapshots/run.py

Related Reading

• docs/engineering/architecture/serving-snapshots.md
• docs/engineering/concepts/freshness-and-data-ready-checks.md