Materialize extracted assertions
Persist captured source claims through the platform claim runtime
You need a Semogram account with access to the workspace and a project in it. Definition and binding changes, query publication, execution and assertion review require their respective permissions. External reads and writes also require the selected plugin installation's credentials and access.
What this path does
Ingress → Assertion mapping → Assertion materializer turns source rows into proposed extracted claims. It uses a source plugin for reading, then Semogram's built-in governed assertion persistence. It does not select a Postgres/Jena ontology fact-store endpoint.
Extracted claims require evidence links. A pipeline run ID, source record ID or citation alone does not satisfy the captured-evidence requirement.
Prepare one real receipt capture
Use a supported project evidence collector to preserve the JSON receipt {"order_id":"O-001","delivered":true}. Inspect its real capture ID, project/workspace scope, preserved bytes/hash and completeness. The selector /delivered must refer to boolean true in those exact bytes. For this value the selector hash is SHA-256 of the UTF-8 text true, which is JSON.stringify(true). That differs from hashing the entire receipt.
This example requires an existing verified project capture. A workspace-only uploaded capture is not automatically a project claim's evidence; verify its scope. Generic public API/MCP capture-to-claim creation is not assumed here. If you cannot obtain a project-scoped preserved capture through your deployment's collector, complete that prerequisite before running this example.
Prepare the bounded source
In a reachable test PostgreSQL database, create the following table using its SQL client. Replace the capture placeholder with the actual capture UUID before executing the INSERT; all other example fields are fully specified.
CREATE TABLE public.ontology_demo_receipts (
entity_id text PRIMARY KEY,
delivered boolean NOT NULL,
capture_id uuid NOT NULL,
selector jsonb NOT NULL
);
INSERT INTO public.ontology_demo_receipts VALUES (
'https://example.com/orders/1', true, '<REAL_PROJECT_CAPTURE_UUID>',
'{"kind":"structured_path","jsonPointer":"/delivered","valueSha256":"b5bea41b6c623f7c09f1bf24dcae58ebab3c0cdd90ad966bc43a45b44867e12b"}'::jsonb
);Install Postgres read in workspace Plugins → Explore. Enter Host, Port, Database, User, Password and Ssl in protected installation settings; its database user must read this table. Create endpoint demo_receipts, namespace ontology_demo, direction Ingress, contract source_stream, Schema public, Table ontology_demo_receipts. Check its one row and that selector is an object (not an unparsed arbitrary text value).
Configure the three nodes
In Pipeline Studio create Ingress using demo_receipts, Full load/parser, output receipts. Connect to Assertion mapping and then Assertion materializer. The rule preserves the entity ID, emits boolean delivered and links the exact receipt capture/selector.
On Assertion mapping, bind input receipts, subject from entity_id, predicate literal https://example.com/operations#delivered, value from delivered, type Property, confidence literal 0.9. Add a supports evidence link with capture ID from capture_id and selector from selector. On Assertion materializer select insert, reject_batch, transactional atomicity and the shown conflict policies. Review evidence before saving.
Read the one verified receipt row from ontology_demo.demo_receipts. Prepare a proposed extracted property claim for delivered using the exact entity_id and full predicate IRI, boolean value and captured evidence link. Validate the real project capture and selector. Persist through the assertion materializer with the policies on this page; do not approve the claim.{
"inputs": {
"receipts": "receipts"
},
"output": "delivery_claims",
"assertions": [
{
"source": "receipts",
"subjectRef": {
"from": "entity_id"
},
"predicate": {
"literal": "https://example.com/operations#delivered"
},
"value": {
"from": "delivered"
},
"assertionType": "property",
"confidence": {
"literal": 0.9
},
"evidenceLinks": [
{
"captureId": {
"from": "capture_id"
},
"relation": "supports",
"selector": {
"from": "selector"
}
}
]
}
]
}{
"inputs": {
"assertions": "delivery_claims"
},
"mode": "insert",
"invalidRecords": "reject_batch",
"atomicity": "transactional",
"policy": {
"duplicate": "merge",
"unreviewedConflict": "supersede",
"reviewedConflict": "preserve_and_flag",
"correction": "link_only"
}
}These sections belong inside a complete pipeline graph with ports and edges. Validate/save a version, inspect the active graph and run once using UI or the supported pipeline execution action. Preflight checks configuration; real execution verifies capture selectors and persists claims.
Verify and review
Inspect the materializer result and project Assertions list. Expect one Proposed property claim for entity https://example.com/orders/1, delivered true, and a verified supports link to the real capture. Use MCP claim_get to inspect the claim's actual links/history. Approval is a separate reviewer action.
Inspect duplicate/conflict counts before rerunning. Reviewed conflicting claims should be preserved/flagged under the selected policy; this does not adjudicate which statement is true. A missing capture, wrong project, mismatched selector/hash or unavailable bytes should fail rather than produce an evidence-backed-looking claim.