Validation, modes and write effects
Choose supported storage behavior and verify partial or repeated work
Materialization writes a mapped fact set through the installed fact-store capability. Both the runtime and the plugin contract constrain what it can do. A mode in serialized configuration does not make an unsupported operation available.
Modes and enforcement
| Setting | What to inspect |
|---|---|
| upsert | Which identity/value keys the selected store updates or inserts |
| snapshot | The store's declared snapshot scope and treatment of absent records |
| delta | The store's supported change operations and required input semantics |
| unknownTerms | Reject or supported quarantine behavior for undeclared terms |
| invalidRecords | Reject or supported quarantine behavior for bad records |
| cardinality / datatype | Whether the intended constraints are enforced |
| atomicity | Transactional or per-unit behavior supported by the store |
Select package, endpoint, mode and validation on the materializer separately from the mapping. A query read binding does not set write policy.
Verify a bounded fixture
Use a dedicated test store and the two-order materialization example. Record the selected package/version, endpoint, graph version, run ID and known source IDs. Run once and inspect inserted/updated/rejected/quarantined counts and stored values. Repeat under the same supported policy and inspect whether entities and relationships duplicate or update.
Then try a deliberately invalid record in this test fixture. Inspect the specific rejection/quarantine output and what was already committed. Do not infer transactional rollback from a failed run status. Confirm store guarantees through its installed contract and actual results.
Assertions use a different writer
Assertion materialization persists claims to platform assertion storage and applies duplicate, reviewed-conflict and correction policies. Pipeline-origin extracted claims require precise evidence links to real captures. It is not a write to the Postgres/Jena ontology fact store and does not need a fact-store endpoint for persistence.
Inspect assertion inserted/merged/superseded/conflict counts and lifecycle events. A machine-generated claim starts as proposed; a high confidence score does not make it human-approved.
Recovery
A failure may occur after some external effects completed. Cancellation stops work where supported; it does not reverse completed writes. Check the store and run outputs before retrying. Use supported idempotency and conflict handling at each layer; an idempotent dispatch key does not promise every plugin performs an exactly-once external write.