Check changes against explicit rules before they reach a shared branch.
Validation rules state what a valid record or change must contain. Use shapes and constraints to express requirements such as a loan having a borrower, or a date using the expected datatype.
Rules live with the knowledge they govern. Version and review them alongside changes to the data.
A staging branch can report violations while a contributor completes an import or edits related records. A strict target applies its validation policy when the work is published.
The distinction matters: accepting unfinished work on a staging branch does not mean accepting it into production.
Suppose an import adds policies without policyholders. Validation identifies the offending records and failed rules. Correct them on the staging branch, rerun the checks, and submit the completed change.
Validation checks stated constraints. Reasoning derives what facts imply. Branching supplies the review and publication workflow.
Developer reference
A validation rule binds W3C SHACL shapes to covered RDF graphs. Shape storage alone installs no gate. Target selection produces focus nodes; property paths and constraint components produce typed violations.
@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix ex: <https://example.org/> .
ex:PolicyShape a sh:NodeShape ;
sh:targetClass ex:Policy ;
sh:property [
sh:path ex:policyholder ;
sh:minCount 1 ;
sh:nodeKind sh:IRI
] .
For ex:p1 a ex:Policy without a policyholder, the focus node is ex:p1; the report identifies ex:policyholder and sh:MinCountConstraintComponent.
Strict rejects violations, leaving HEAD unchanged. Lenient publishes and returns warnings; staging defaults to Lenient unless overridden. Merge checks execute against the combined graph under destination rules. Source-branch success cannot certify a changed destination. Constraint satisfaction establishes structural conformance, not source truth.