Shapes and validation
Describe record constraints and understand which validation actually runs
Shapes describe expectations on instances of the model: required values, datatypes, cardinality and other supported constraints. They are separate from declaring a class or property.
Example: orders must have an ID and total
You need a Semogram account, project definition authoring access and a definition containing Order, orderId and total under https://example.com/operations#. The complete model can be downloaded here; include it as model.ttl in this example package, so the shape has its own complete model context.
Add shapes.ttl with the content below. Keep modelEntrypoints: ["model.ttl"] and set shapeEntrypoints: ["shapes.ttl"] in the manifest. Include both files when committing a definition version. The shape name is another model identifier, not a data endpoint.
Open the definition model/file editor, add the shape file and update the manifest entrypoints. Review the shape in the schema view and the validation report before saving the version.
Add OrderShape to the operations demo definition. Require exactly one string orderId and one decimal total per Order, using the full property IRIs. Include model.ttl and shapes.ttl in the package and validate before saving. Explain which checks run at materialization.@prefix ex: <https://example.com/operations#> .
@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
ex:OrderShape a sh:NodeShape ;
sh:targetClass ex:Order ;
sh:property [ sh:path ex:orderId ; sh:datatype xsd:string ; sh:minCount 1 ; sh:maxCount 1 ] ;
sh:property [ sh:path ex:total ; sh:datatype xsd:decimal ; sh:minCount 1 ; sh:maxCount 1 ] .Three checks answer different questions
| Check | What it establishes | What it does not establish |
|---|---|---|
| Definition validation | The package parses and its model/shape definition passes supported checks | Existing business records meet the shape |
| Binding/query validation | Terms, bindings, expressions and query schemas can resolve | A real endpoint returned usable data |
| Materializer/run validation | Facts pass the configured term, datatype and cardinality checks | Every external write is rolled back on failure |
Choose enforcement explicitly on the materializer; inspect the installed store's contract and any rejected/quarantined records. Do not assume adding a SHACL file causes every live connector read to undergo arbitrary SHACL validation. Query input/output JSON schemas provide another distinct layer of validation.
Verify with a bad fixture
In a test pipeline, map an Order with no orderId or an incompatible total. Run a bounded fixture under the intended validation policy and inspect the specific issue and rejected or quarantined count. Compare that with a valid Order. A green model validation badge alone cannot prove this behavior.