Combine live, stored and reviewed values

One query can enumerate stored entities while reading some properties live, projecting reviewed assertions and computing other properties. The query root establishes the population; shared identity connects output terms to those entities.

Example: an order's current status and reviewed delivery

Use a compiled model declaring Order, status, delivered and isOpen under https://example.com/operations#. A fact store contains entity https://example.com/orders/1. A Postgres source contains {entity_id: "https://example.com/orders/1", status: "open"}. A project Property assertion has the same subject and predicate https://example.com/operations#delivered, value true, Approved status and confidence 0.9.

You need project query/binding access, the readable endpoint's Postgres read installation, the fact-store installation and a reviewer for the assertion. These are real prerequisites, not data invented by the query.

Create all bindings against the actual compiled package/version. Use full IRIs in Business term and Term identifier. For a live property from another source, explicitly supply the shared identity field so the join is by entity, not source row order.

Complete query

query_definition:
  name: Order decision context
  ontology_package_id: <COMPILED_PACKAGE_UUID>
  ontology_package_version: <COMPILED_PACKAGE_VERSION_NUMBER>
  target: { kind: materialized }
  input_schema: { type: object, additionalProperties: false }
  root:
    term_ref: https://example.com/operations#Order
    cardinality: many
  output_schema:
    type: object
    properties:
      id: { type: string }
      status: { type: [string, "null"] }
      delivered: { type: [boolean, "null"] }
      is_open: { type: [boolean, "null"] }
  output_mapping:
    id: { term_ref: "https://example.com/operations#Order" }
    status: { term_ref: "https://example.com/operations#status" }
    delivered: { term_ref: "https://example.com/operations#delivered" }
    is_open: { term_ref: "https://example.com/operations#isOpen" }

In Ontology → Queries, create this definition after replacing package values, validate, save and publish its reviewed version. Execute with empty input and limit 10 through UI, HTTP query execute or MCP query_execute. Expect id https://example.com/orders/1, status open, delivered true and is_open true. That apparent disagreement is possible: one field is a live operational record, another is a reviewed claim. Inspect evidence and timestamps instead of silently treating one as authoritative.

Prove the identity join

Add a live row for https://example.com/orders/2 with a different status. It must not change order 1's output. Reorder source rows and verify again. A matching Customer name or row index is not sufficient identity evidence.

If a property is absent, inspect its binding, class identity, source field projection, assertion eligibility and output null policy. If two scalar values conflict, inspect ambiguity rather than arbitrarily choosing the first. Restrictions and masks apply to the actual dependencies, including computed outputs.