Skip to main content
Version: v5.6.1

Regulatory binding packs (packs:bindings-<framework>)

packs:bindings-<framework>

A binding pack declares one regulatory framework's vocabulary over the generic classification vocabulary the platform already ships: the canonical core.* governance metadata themes (core.criticality, core.data_sensitivity, the core.rto_class/core.rpo_class recovery classes, and the rest — see node metadata). OpsChain deliberately holds no regulatory opinion in core — a binding pack is where that opinion lives: a framework (CPS 230/234, SOCI, DORA, …) ships its own metadata profile and maps the core fields into its determinations, so one classified estate answers many frameworks without re-classifying per regulator.

Each framework is its own entitlement — packs:bindings-dora, packs:bindings-cps230-234 — minted per customer, standalone-loadable and positioned atop the governance packs: a binding pack presumes the classification machinery (base platform) and composes with the governance packs' funnels and evidence surfaces (see the governance foundation) rather than replacing any of them.

The family shape​

The family is registered by shape, not by a per-framework registry row: any name of the form packs:bindings-<framework> with a non-empty framework suffix is a valid member. Licence minting accepts every pack-shaped name, and the vocabulary listing (opschain admin licence features, see opschain docs cli/admin-licence-features) answers a family member's query with the family row — "the regulatory binding pack for one framework's vocabulary" — carrying the queried name, pointed at opschain docs metadata.

The profile namespace is reserved to match: customer profiles must live under x-<org>.*, because non-x- field families are held for the base core.* themes and pack-shipped bindings — a binding pack's vocabulary can never collide with yours.

What the entitlement gates today​

Honestly: the server consults the family in two places, and no feature surface beyond them.

  • The vocabulary row — the family shape validates minted names and serves the listing row above, so a packs:bindings-<framework> grant on a licence resolves, lists and reports exactly like every canonical pack entitlement (entitlements).
  • The signed-pack manifest gate — a LimePoint-signed pack whose verified manifest declares a required entitlement is refused at mount and at use without it, with the typed refusal naming the pack (the pack-use gate on entitlements; installing and mounting packs is opschain docs getting-started/2-4-using-packs). A shipped binding pack rides exactly this mechanism: its manifest requires its own packs:bindings-<framework> grant, so the gate is the pack store's, not a bespoke code path.

There is no binding-specific enforcement seam in the server itself: the classification machinery the bindings declare over — profiles, values, inheritance, predicates, the register — is base platform and never consults this family (node metadata, hands-on: opschain learn governance-classification).

  • Node metadata — the core.* vocabulary and the x-<org> profile namespace bindings sit beside.
  • The governance foundation — the controls, evidence and campaign objects a framework's determinations feed.
  • Entitlements — resolution, minting and the pack-use gate.
  • opschain docs getting-started/2-4-using-packs — installing and mounting signed packs.