Read reviewed assertions

An asserted binding reads a term's values from project assertion records. Use it for a reviewed statement such as “this order was delivered,” independently of the source system's status column. The assertion subject must match the root entity identity, and its predicate must match the bound term.

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 you need

A compiled definition with https://example.com/operations#Order and boolean property https://example.com/operations#delivered; an Active root binding with actual orders; a compatible ontology fact-store endpoint (required for asserted binding configuration); and assertions in this project. The complete model file declares those terms. Install Postgres ontology-store with reachable connection credentials and create a Materialization endpoint with ontology_fact_store to supply store context. Assertions themselves are stored by the platform claim workflow, not in that external store.

Example: delivered evidence for one order

For the root entity https://example.com/orders/1, create/review a Property assertion whose predicate is https://example.com/operations#delivered and value is JSON boolean true. Do not use the string "true". In the project Assertions workflow, inspect the subject, evidence and validity before approving. A delivery claim must refer to that order, not merely mention a customer's name.

Create an Active Asserted Property binding for delivered, selecting the actual compiled package/version and fact-store endpoint, cardinality One. Its resolution is:

{
  "source": "assertions",
  "statuses": [
    "approved",
    "corrected"
  ],
  "minConfidence": 0.8,
  "conflict": "error"
}

This example requires confidence at least 0.8; an approved assertion with null/lower confidence does not qualify. Set the threshold deliberately. Optional validAt and provenance selectors can narrow eligible claims.

Include it in a query

Add output mapping delivered: { term_ref: "https://example.com/operations#delivered" } to a complete query whose root is Order and whose root binding returns the same subject IDs. Declare delivered as boolean-or-null if a missing eligible claim is expected. This is a query-definition change: validate/save/publish a new release before consumers use it.

An approved true claim should yield true; absence of an eligible claim is not proof of false. Proposed/rejected/superseded claims are excluded by the explicit statuses above. For differing eligible scalar values, conflict: error reports ambiguity. latest or highest_confidence are explicit alternative policies, not a substitute for reviewing contradictory evidence. many cardinality returns the eligible values as a collection.

Verify what was selected

Compare query values with assertion status, confidence, validity, predicate and subject. Review conflict diagnostics and the query's resolved asserted binding. Approving a claim does not rewrite the raw source status, and changing a read filter does not change the claim's review decision.