Build assertions

This example maps two order totals into proposed property assertions. It uses Postgres read and Semogram's built-in assertion mapping/materialization path. Unlike ontology-store materialization, these assertions are persisted through the platform assertion runtime; this path does not select a Postgres fact-store endpoint.

What you need

You need a Semogram account with workspace membership, a project in that workspace and permission to create and run pipelines. Reading or writing also requires access to the selected endpoints and external systems. Creating a pipeline does not grant those permissions.

Use a reachable test PostgreSQL database and its SQL client. You need installation/endpoint management access as well as pipeline read/write/execute access. The connection must be reachable from the execution runtime, not only from your laptop.

Required captured evidence

Each extracted assertion requires at least one evidenceLinks entry with a real project capture UUID, relation and precise selector. The runtime verifies captured bytes and selector integrity. Source record/run metadata alone is insufficient; a citation URL is not a capture identity.

Use the complete captured-receipt example for the required source SQL, evidence selector, mapping, persistence and review workflow. Do not run the earlier two-total example without supplying actual captures and evidence links for each row.

Configure the assertion pipeline

The illustrative mapping below shows the total fields only; it is not executable until verified evidenceLinks are added for each source row. Prefer the complete captured-receipt example above. Create Ingress → Assertion mapping → Assertion materializer. Ingress uses demo_orders, Full load/parser, output orders. Configure one mapping rule for each source row:

Read demo_orders and prepare a property assertion for each order’s total. Use subject order-{order_id}, predicate total and the row’s total value. Preserve the source record ID and source evidence. Persist with duplicate merge and preserve-and-flag behavior for reviewed conflicts. Do not mark machine observations human-approved.

{
  "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"
      },
      "metadata": {
        "sourceSystem": {
          "literal": "pipeline-demo"
        }
      }
    }
  ]
}

Materializer definition:

{
  "inputs": {
    "assertions": "order_assertions"
  },
  "mode": "insert",
  "invalidRecords": "reject_batch",
  "atomicity": "per_unit",
  "policy": {
    "duplicate": "merge",
    "unreviewedConflict": "supersede",
    "reviewedConflict": "preserve_and_flag",
    "correction": "mark_original_corrected"
  }
}

Validate, save and run

Validate the draft and resolve errors. Preflight checks configuration only; it does not produce records or run a model. Save version, inspect the active saved graph and Run once. Open the run and compare the named step's output with the expected result below. Keep the run ID and inspect errors/counts, not only the assistant's response. Programmatic launch uses HTTP POST /api/v1/projects/<PROJECT_ID>/pipelines/<PIPELINE_ID>/execute with pipelines:execute and an Idempotency-Key, or MCP pipeline_execute with pipelineId, projectId and idempotencyKey.

If the Studio result only exposes an artifact handle, open the corresponding output/artifact inspection rather than treating that handle as a row preview. To persist rows externally, add an Egress endpoint and test its write semantics; the examples below do not silently create a destination.

Verify and review

Open the project's Assertions list and inspect the two resulting property assertions, subjects and values. Trace each to its source record/run evidence. A stored machine assertion is not automatically human-verified. Use the review workflow to approve, correct or reject it based on evidence.

Rerun only after inspecting duplicate and conflict behavior. Test a changed source total and verify that reviewed assertions are preserved/flagged according to policy. Captured evidence is required for extracted claims. Configure evidenceLinks with real capture IDs, relations and selectors before running; a citation URL alone is not a capture identity.