Skip to content
OpenDome

Governance & the cell

Governance in OpenDome is not a feature bolted onto the query path — it is the query path. OSL emits the facts, the cell’s policy enforcement point (PEP) applies them, and every decision is audited.

Access & capabilitiesThe full capability model — delegation chains composed by MEET, per-node grants, named redaction versions, fail-closed. This page covers how it plugs into the cell; that one covers the model.

Policy as facts

Section titled “Policy as facts”

osl compile denormalizes the project into policy facts — one tuple per governed object:

(fqn, owner, sensitivity, pii, acl_source, cell_hints)

The policy decision point (PDP, provided by the cell-model) indexes these facts. OSL does not invent a parallel access semantics; it describes what exists and how sensitive it is, and the PDP decides allow/deny in its 4-D tuple (data, action, actor, context).

Fail-closed enforcement

Section titled “Fail-closed enforcement”
  • A governed query with no PDP snapshot available is denied (E2001, 503), not served — fail-closed by construction.
  • Unstructured retrieval and content previews are deny-by-default: an actor with no roles gets zero passages.
  • Redaction happens in the cell, never client-side. An un-granted column comes back as the ⟦redacted⟧ sentinel (the column survives with a governed value, it doesn’t become NULL), an obligated one as ***, and the response lists exactly what was redacted. Content facets are served at the subject’s required redaction version.

One audit chain

Section titled “One audit chain”

Every request — allowed or denied — produces an immutable, hash-chained audit entry. There is one decision point and one trail, which is what makes downstream compliance (EU AI Act, DORA, GDPR) tractable.

Enterprise The compliance pack adds the audit chain export, framework-specific artifacts and evidence tooling on top of the OSS enforcement and audit primitives.

Section titled “Related”