Skip to content

Constraints & SHACL

Methodology → governance

If a rule matters, it must be enforceable.

Constraints move governance out of “prompt etiquette” and into a layer that can validate, block, and explain. SHACL is one practical way to formalize those constraints for graph-shaped data.

brCausalGraphRAG LLM + Tool + RAG Governance approach

The problem with prompt-only governance

Editable

Instructions can be changed, ignored, or diluted by competing context.

Bypassable

A sufficiently clever prompt can route around “guidelines”.

Hard to audit

You can’t reliably prove which rule was applied, or why an output was allowed.

Not deterministic

Governance becomes a probabilistic behavior, not a system guarantee.

Not portable

Rules don’t travel cleanly across teams, products, and model upgrades; they decay into prompt folklore.

Unclear failure mode

When outputs violate policy, you get excuses instead of a crisp violation report tied to a specific rule.

The constraint approach

Encode rules as constraints that validate actions and outputs.

The model can propose; the system decides what is allowed.

flowchart TB
%% Styles (brModel Standard)
classDef i fill:#D3D3D3,stroke-width:0px,color:#000;
classDef p fill:#B3D9FF,stroke-width:0px,color:#000;
classDef r fill:#FFFFB3,stroke-width:0px,color:#000;
classDef o fill:#C1F0C1,stroke-width:0px,color:#000;
classDef s fill:#FFB3B3,stroke-width:0px,color:#000;

I_D(["🗣️ Draft answer / proposed action"]):::i
P_V("🔒 Validate constraints"):::p
R_R(["🧾 Validation report (what rule, what edge)"]):::r
D_OK{"✅ Allowed?"}:::s
O_O(["✅ Allowed + execute + trace"]):::o
S_X(["🛑 Block + abstain + explain"]):::i

I_D --> P_V --> R_R
R_R --> D_OK
D_OK -->|"Yes"| O_O
D_OK -->|"No"| S_X

%% Clickable nodes
click P_V "/methodology/constraints/" "Constraints & SHACL"
click O_O "/methodology/brcausalgraphrag/" "brCausalGraphRAG"

Decision mechanism: a proposal becomes a 🧾 validation report, then the ✅ allowed? gate decides. Passing yields ✅ execute + trace; failing yields 🛑 block/abstain plus an explanation tied to the violated rule and edge.

What SHACL gives you (practically)

Shape validation

"This claim must have these fields"; "this edge is only allowed between these types".

Policy-as-data

Rules live next to the schema and can be versioned, tested, and reviewed.

Machine-verifiable failures

When the system refuses, it can point to the violated shape and the offending node/edge.

Composable governance

Multiple rule sets (domain, safety, org policy) can be applied as separate validation layers.

Deterministic enforcement

Conformance is a yes/no property of the data. That makes “allowed vs blocked” predictable and testable.

Reviewable change control

Constraint changes can be code-reviewed and versioned like any other policy artifact, with diffs and rollbacks.

Diagram: SHACL validation pipeline (conceptual)

 flowchart TB
%% Styles (brModel Standard)
classDef i fill:#D3D3D3,stroke-width:0px,color:#000;
classDef p fill:#B3D9FF,stroke-width:0px,color:#000;
classDef r fill:#FFFFB3,stroke-width:0px,color:#000;
classDef o fill:#C1F0C1,stroke-width:0px,color:#000;
classDef s fill:#FFB3B3,stroke-width:0px,color:#000;

I_G(["🕸️ Graph state"]):::i
P_U("✍️ Proposed update (claim / edge / action)"):::p
P_S("📐 SHACL shapes (versioned policy)"):::p
R_R(["🧾 Validation report"]):::r
D_Conf{"✅ Conforms?"}:::s
O_C(["✅ Commit update + audit event"]):::o
S_B(["🛑 Block + return violations"]):::i

I_G --> P_U --> P_S --> R_R
R_R --> D_Conf
D_Conf -->|"Yes"| O_C
D_Conf -->|"No"| S_B

%% Clickable nodes
click P_S "/methodology/constraints/" "Constraints & SHACL"
click R_R "/reasoners/governance/" "Governance"

Pipeline meaning: governance is applied to a ✍️ proposed update using 📐 versioned SHACL shapes. The result is a 🧾 report and a ✅ conforms? decision: either ✅ commit + audit event or 🛑 block + return violations.

Examples of enforceable constraints

  • Role-based prohibitions: certain actions cannot be executed under a role.
  • Sector restrictions: domain-specific rules (e.g., medical, legal, finance) must gate outputs.
  • Required provenance: high-stakes claims must link to source objects and versions.
  • Threshold limits: numeric or confidence thresholds for allowed decisions.
  • Mandatory escalation: some cases must route to human review.

Operational result

A system that refuses to cross boundaries and produces a machine-verifiable reason when it abstains. This turns governance from “best effort” into an actual property of the system.