Verify the complete ontology flow
Check structure, data, evidence and released consumers independently
Ontology verification is a chain of checks. A green definition validator, completed pipeline or successful HTTP response answers only part of the question.
A bounded acceptance fixture
Use a dedicated test project and two orders: O-001/open/120 with entity ID https://example.com/orders/1, and O-002/delivered/75.5 with ID /2. The complete first example defines that fixture and every required model/binding/query setting. A stored-flow test additionally needs a fact-store capability and materialization run.
| Layer | Check | Evidence to retain |
|---|---|---|
| Definition | Classes/properties/relationships and full identifiers are correct | Saved version, model files, compilation/validation |
| Endpoint | The selected installation reaches the intended target | Connection/sample results and endpoint identity |
| Binding | Active package/version, identity/field resolution and policy match | Binding IDs and validation |
| Mapping | Each known row maps to the intended entity/value | Node output, source identity and provenance |
| Materialization | Facts actually persisted under supported policy | Store readback, run ID, counts/errors |
| Assertion | Correct entity/predicate/value and actual review/evidence | Claim revision, evidence selectors and decision |
| Query release | Reviewed logic and dependency contract are published | Release number and saved query version |
| Execution | Completed rows match known values | Job/result, diagnostics, completeness and snapshots |
Test disagreement and failure
Do not test only the happy path. Try a wrong term identifier, withdrawn binding, missing scalar, two conflicting scalar values, denied caller, partial source result and changed endpoint configuration. Expect an explicit validation/runtime issue or declared null/masking behavior. None should quietly turn into a confident business answer.
For assertion outputs, test a proposed versus approved claim and a claim outside its validity window. Missing eligible evidence is not false. For identity joins, reorder rows and include another entity; values must remain attached to the correct ID.
After a change
Classify the change first: model structure, endpoint configuration, source records, mapping logic, assertion decision or query release. Revalidate affected layers and execute the same fixture again. A changed model/endpoint contract may require a new query release. A source-data update generally changes a future live result without editing the query. A materialized result needs the relevant producing run to update it.
Check pinned consumers, especially forecasters. Publishing a new query does not update all of them. Retain the versions, sources and decision evidence needed to explain a past answer.