Bindings

How a typed Object instance is projected from a real source — managed table, knowledge-base page, process-flow task, or manual entry.

A binding is the rule that tells the ontology how to materialise a typed Object instance from a real source. Bindings are the bridge between L2 (schema) and the underlying data layer.

Projection on read

A binding does not copy rows into a new table:

   regulated_entities (managed table)
   ┌─────────────────────────────────────────┐
   │ EntityID │ LegalName    │ RiskClass    │
   ├─────────────────────────────────────────┤
   │ e1...01  │ Acme Holdings│ medium       │
   │ e1...02  │ Neptune Cap. │ high         │
   └─────────────────────────────────────────┘
                 │
                 │   binding (silver_table)
                 │   columnMap:
                 │     id              ← EntityID
                 │     legalName       ← LegalName
                 │     riskClass…      ← RiskClass
                 ▼
   RegulatedEntity (typed Object — projected on demand)
   { id: "e1...01", legalName: "Acme…", riskClassification: "medium" }

When a caller reads a RegulatedEntity, the binding's projection runs against the source table and returns typed instances. Re-uploading the source CSV is reflected on the next read.

Binding kinds

Kind	Source	Status
`silver_table`	A managed table — your CSV / JSON uploads	shipped
`memex_page`	A knowledge-base page	shipped
`process_flow_task`	A process-flow task instance	shipped
`manual`	SDK / workbench writes — no upstream	shipped
`process_flow_action`, `extraction`, `stream`	Entity-link actions, extraction pipelines, pub/sub topics	preview

A pack can ship bindings of any kind. Bindings can also be authored directly from the workbench's Bindings tab without touching the SDK.

Column map

For a silver_table binding, the column map declares which source column populates each Object property:

Object property      Source column
─────────────────    ─────────────────
id              ←    EntityID
legalName       ←    LegalName
riskClass…      ←    RiskClass

The column map is editable from the Bindings tab. The picker accepts both the physical column name (fius_fiu_id) and the display name (fius.fiu_id) — see Column names for how the two are kept in sync.

Ready vs. not ready

A binding shows one of three status badges in the workbench:

Badge	Meaning	What to do
Ready	Source resolved, every column-map value matches a column on the bound table.	Use it.
Not ready — table not registered	The pack ships a logical source name; no matching table exists in this workspace yet.	Click Pick table, choose the right managed table — the picker highlights an exact name match.
Not ready — missing columns	The bound table doesn't have every column the column map references.	Edit the column map — pick the right column for each property.

The Ready check is a live probe, not a cache. It re-runs on every list, so a binding that flips from Ready to Not ready means something changed upstream (table archived, columns renamed).

DLP labels and masking

Every projected instance carries the DLP labels of its source:

A property bound to a column classified confidential inherits that classification.
A masking strategy applied to the source column also applies to the projected property.
A caller without clearance for the column sees the masked value in the projected Object, not the raw value.

This is what makes the ontology safely exposable to agents — there is no way for an agent to read a typed Object and bypass the column-level governance on its source.

Provenance

Every projected instance carries provenance:

Field	Value
`bindingId`	Which binding produced this instance
`bindingVersion`	Which version of that binding
`sourceRef`	A reference to the source row (e.g. `EntityID="e1...01"`)
`materializedAt`	The timestamp of the projection
`dlpLabels`	The DLP labels that flowed through

Workflow tools and the analyst surface this provenance alongside the data, so the user can always answer "where did this come from?".

Provenance is read-only at the binding layer — it's emitted by the projection, never authored by the user. Bindings authored manually in the workbench still carry provenance referring to the workbench itself as the source.

Object types — what bindings produce instances of.
Analytics → Column names — how source-column lookup works.
Branches & proposals — bindings are versioned with the schema.