Primitives catalog

Primitives are the typed, zero-completion building blocks of the query machine. Assured operations freeze chains over them. This page catalogs engine ops and labels what an agent can call vs what is internal composition.

Parent: Retrieval. Shipped HTTP: API reference.

Rules that apply to every primitive

1. No LLM completion on the hot path (semantic channels may embed the query).
2. No write side effects — reads never enqueue work.
3. Grain is declared where an envelope is returned.
4. Temporal params valid_at / believed_at compose where validity exists.
5. Query-engine results hydrate through Postgres except pure mount reads.

Prefer these public surfaces first

Do not invent /fuse, /rerank, /scan, etc. unless the API reference lists them.

Catalog (engine ops)

Legend: Public = stable agent call path today · Internal = used inside operations / engine · Design = specified, not a public agent surface yet

resolve

lookup

Relation and observation lookups include facts whose incomplete world dates might match the requested time, marked temporal_match: possible. These are useful evidence, but do not establish a confirmed temporal count. The strict memory_v1.facts_current view and live graph exclude possible matches.

search

Shipped P1 notes:

• Chunk hits are evidence grain with typed chunk payload; body vs location header stay separate.
• Generation-safe across re-embed cutovers where implemented.
• Cross-modal media segment search is design-complete / not the default public target — do not document it as a callable search target until API lists it.

graph

fuse / rerank / combine_evidence

hydrate

transcript

Choosing the fact time scope

Use history for biographies and achievements: a completed tournament win remains part of someone's history. Use current for what holds now, at for a particular instant, and overlap for a bounded interval. History excludes known future starts; future planning uses an explicit future at or overlap request.

The library's enumerated aggregate accepts the same time selector. Counts and groups report count/total for confirmed matches and possible_count/possible_total for incomplete-date candidates separately. A nonzero possible total or truncation prevents an exact-count claim. Timeline buckets use chosen world dates, with an undated bucket rather than an ingestion date fallback. delta_top_entities remains a system change feed.

delta / pages_about / aggregate / scan

How assured ops use them

claims_and_sources_context (evidence)

Conceptual chain:

1. Semantic + lexical claim nomination → fuse → hydrate once
2. Semantic + lexical chunk nomination → fuse → hydrate once
3. combine_evidence under one evidence envelope

facts_context (fact)

Conceptual chain:

1. Resolve names separately and pass the unambiguous entity_ids
2. For current / at, walk one hop by default with empty predicates (all RELATES, including other:*)
3. Nominate relation labels and observation statements inside the capped anchor + neighbor IDs
4. Hydrate live relations/observations and attach testimony under a hard evidence budget
5. Package graph nodes separately from facts, plus fact_evidence, exact totals, contradictions, support markers

hops is 1–2. predicate is optional and may be any stored predicate; it is passed unchanged to the live graph and re-confirmed on relation rows in Postgres. It is an exact relation-only filter, so observations are excluded when it is present; unfiltered observations remain facts and never become graph nodes. Unavailable live-graph authority or a current anchor absent from it is a typed boundary; a neighbor that becomes stale across the bounded reads is omitted and counted in dropped_by_hydration. The combined entity cap is explicit in truncation. overlap and history retain the explicit anchor scope because graph traversal requires a single world-time instant.

Without entity_ids, profile prose is a second bounded nomination path for fact text. “List banks” can therefore reach a bank observation; no type argument or query-path completion model exists.

combined_context (ContextBundle/v2)

Purely composes the complete claims_and_sources_context and facts_context responses under separate named fields. It adds no retrieval, ranking, hydration, or flattening.

resolve_entity

Typed veneer over resolve with envelope packaging.

Temporal composition pattern

1) search/lookup event → read its world timestamp from the envelope
2) lookup/graph/search with valid_at = that timestamp

Belief horizons and boundaries

Querying past a finite horizon → boundary negative with workaround.

Related

• Retrieval overview
• Envelope
• Open query
• API reference