Assertion mapping
Turn source rows into evidence-linked truth claims
Assertion mapping creates entity, property, relationship, classification or claim assertions from records. It can preserve source record IDs, captured-document links, reliability, confidence and identity metadata. A materializer persists the mapped assertions; mapping alone does not approve them.
Before using it
Create or select the real resources described above in the pipeline’s project/workspace, inspect the upstream data shape and ensure your actor can perform this operation. A configuration fragment cannot create those resources. Read First pipeline for a complete graph and fixture.
Fields and bindings
| Field | Meaning |
|---|---|
inputs / output | Named source pools and assertion output |
assertions[].source | Source pool to map |
subjectRef / predicate | Field, template or literal expression |
objectRef / value | Relationship target or claim/property value |
assertionType | entity, property, relationship, classification or claim |
evidenceLinks | Actual capture ID, relation and selector expressions |
sourceRecordId / confidence | Source provenance and separate claim assessment |
Configure
Prepare the assertion mapping node for the selected test resources. Use the operation and fields shown in this example. Show actual resource bindings, upstream/downstream ports and any write/model effects before applying the draft.Bind the input records, configure subject/predicate/value expressions and connect the assertions output to an Assertion materializer. Use real capture IDs for document evidence, and keep confidence, source reliability and forecast probability separate.
Put this section under assertionMapping on a full node of kind assertion-mapping. It is not a standalone API or MCP request. Replace resource placeholders, and provide the full node ports/policy and graph edges.
{
"inputs": {
"orders": "orders"
},
"output": "order_assertions",
"assertions": [
{
"source": "orders",
"subjectRef": {
"template": "order-{order_id}"
},
"predicate": {
"literal": "total"
},
"value": {
"from": "total"
},
"assertionType": "property",
"sourceRecordId": {
"from": "order_id"
}
}
]
}Verify a bounded run
Inspect the two subjects, totals, source record IDs and evidence links. Test a missing source key and invalid value. Follow the persisted review status separately.
Validate, save a version and run a small known fixture. Inspect the actual node result and downstream consumer, not only the graph preview.
Limits and failure behavior
A citation URL is not a capture identity. Machine-created claims are not automatically human-approved. IdentityRevision/canonicalEntityId should reference actual reconciled identity state, not invented labels.