Groundings: meaning travels, groundings don't¶

The concept registry serializes meaning only — definitions, relations, external anchors (registry.to_yaml()). That artifact is safe to publish, exchange, and version across organizational boundaries: a counterparty sends you their concepts file; they never send you their column names.

The groundings file is the complementary artifact: where each concept is physically realized in one specific deployment.

from semantido.exporters import to_groundings_file

to_groundings_file(layer, "groundings.yaml")

format: semantido/groundings
version: "1"
namespace: secmaster
groundings:
  isin:
    definition_checksum: "3f8a…"
    columns:
      - anna_dsb_reference.dsb_isin
      - bbg_instrument_feed.id_isin
      - security_master.primary_isin

Each entry records the concept's definition_checksum at recording time, so staleness is checkable in both directions by semantido.lint (SL007):

Schema drift — an anchor table or column no longer exists in the layer.
Meaning drift — the definition changed after the grounding was recorded, so the binding needs human re-review before the checksum is re-stamped.

The split, operationally¶

Artifact	Contains	Travels?	Checked by
`concepts.yaml` (`registry.to_yaml()`)	definitions, relations, external mappings, grain	yes — the unit of exchange	`registry.validate()`
`groundings.yaml` (`to_groundings_file()`)	concept → tables/columns, checksums	no — stays with the deployment	`semantido.lint` SL007

Regenerate the groundings file whenever the schema or bindings change; treat an SL007 checksum-drift error as a review task, not a regeneration task — the point is that meaning changed under a live binding.