Skip to main content
Preview A binding maps one exact ontology release to the physical data that implements it. The ontology says what a Customer is; the binding says that Customers live in retail.core.customers, one row per customer. An agent that asks for binding context gets both, then writes and runs its own query with its own connection.

​
Mapping types

A binding family groups the mappings from one ontology release to one source. It records the ontology release it is locked to, a Source scope that names the source, and a Versioning policy. Inside it, you declare three kinds of mapping:

​
What a mapping can point at

Physical names are declared as qualified names, such as catalog.schema.table.column. The binding stores them as governed text and never checks them against a live source. A SQL-backed relation suits a type that no single table holds, such as active customers only. The dialect is ANSI, BigQuery, Databricks SQL, PostgreSQL or Snowflake. The binding refuses wildcards, unnamed outputs, comments, parameters, and anything other than one read-only query. The SQL is versioned metadata: the binding never runs it.

​
Why a new ontology release needs a new binding release

A binding is locked to one exact ontology release, and each object and link mapping pins the exact version and checksum of the definition it maps. That way a mapping can never silently describe a definition that has since changed. When you publish ontology 1.1.0, binding releases for 1.0.0 keep working against 1.0.0. For 1.1.0:
  • Nothing you mapped changed. An agent can pass the newer release as ontology_release_id when it asks for binding context. Reuse works only when every definition the binding references has the same version and checksum in the newer release. Otherwise the request is refused with source_unavailable, never answered with stale mappings.
  • A mapped definition changed. In Data bindings, choose the new Ontology release, create a binding family and map it, then validate and publish a binding release. To carry existing mappings over, export the old binding release as portable JSON and import it against the new ontology release, which creates a new binding family from it.

​
Rules

  • Declarations, not verification. Validation checks that mappings resolve and agree with the ontology. It doesn’t confirm a table exists, a join is correct, or a query runs.
  • No credentials or endpoints. A binding holds qualified names, grain, joins and SQL text only. Agents use their own, separately governed connection.
  • Releases are fixed. Like ontology releases, a binding release has a semantic version and never changes. Saving a mapping adds a draft version; published releases keep theirs.
  • Gaps are reported. Binding context includes a handoff report that names each unmapped object, unmapped property or link with no join keys, with a fix for each.
  • Size. One binding release holds up to 5,000 mappings.