The embedding fabric

build_embed_text(): prefer the human-authored label/description when present, then always append the humanized IRI so the structural signal survives when they're NULL — the overwhelming case for LLM-minted predicates.

An entity is embedded by what is said about it, not just its name — so two records of the same person with different spellings land close because their described relations overlap. The signature: the name line, up to 3 pinned rdf:type lines, then up to 14 salient relations ranked by data-driven IDF (from the materialized view donto_predicate_idf): a predicate on nearly every subject carries no information and sinks; a rare discriminating relation floats up. Predicates minted once for one subject are demoted — they describe but can never match. Capped at 600 chars (short text embeds ~3× faster with no measured loss of matching power). A real live signature:

[SIG] ex:caroline-rose-brown
  Brown | needs cross reference with caroline birth registration |
  possible father brown roberts | previous identified as Caroline Molloy |
  previous identified as Caroline Davis | is progeny of brown roberts |
  has death date 1975-07-06 | has birth date 1887-06-10 |
  is sister of david molloy | has alias kitchay | has birth year 1887

Embedding is tiered by richness (most of the 4.1M subjects are 1-statement singletons with near-zero identity value): the daemon backfills richest-first through descending minimum-statement tiers (50 → 20 → 10 → 5). A sig_hash per entity means re-runs only re-embed entities whose signature actually changed.

Episodic chunks embed their raw prose, truncated to CHUNK_TEXT_CAP = 1200 chars (~300 tokens) — a measured cap: raising it to 2048 gave zero recall gain on LongMemEval while costing ~33% throughput; the signal sits in the first ~300 tokens. Semantic claims embed a humanized rendering of the triple — "ajax occupation software engineer" — which is what lets "where does he work?" reach an ex:occupation engineer claim that shares no substring with the query.

donto_suggest_alignments_semantic() runs an HNSW-accelerated nearest-neighbour scan. Real live output:

SET hnsw.ef_search = 100;
SELECT target_iri, sim FROM donto_suggest_alignments_semantic('someMembersMurderedBy', 0.80, 8);

 hadMembersKilled    0.9322
 murderedByGroup     0.9042
 wasMurderedByGroup  0.8991
 someMembersDied     0.8990
 killedOneMemberOf   0.8850 …

A hybrid generator combines this with trigram-lexical similarity (catching morphological variants like bornIn/wasBornIn that embeddings alone might rank lower); production floors: semantic ≥ 0.82, combined ≥ 0.88 to register a candidate. The daemon's LLM step adjudicates candidates into accepted alignments, which are flattened into donto_predicate_closure (~1.01M rows; ~9.8K real expansion edges: close_match, exact_equivalent, inverse_equivalent, sub_property_of). At query time, donto_match_aligned() returns direct matches plus everything reachable through the closure — re-orienting inverse-swapped rows — so a claim stored under ex:workplace answers a query about ex:employer. The emit-free / defer-joining promise, made real. Details in alignment & identity.

SELECT target_iri, sim FROM donto_suggest_entity_matches('ex:caroline-rose-brown', 0.75, 6);

 ex:caroline-rose-davis   0.8483   <- same person, married name
 ex:caroline              0.8227
 ctx:genealogy/…/f7bc7b…  0.8222 …

The fingerprint approach working as designed: differently-spelled records of one person surface because what is said about them overlaps. Accepted pairs become governed identity proposals — identity stays a reversible hypothesis; nothing is ever merged.

Recall fuses a lexical arm (FTS) and a vector arm (these embeddings, holder-scoped) with Reciprocal Rank Fusion (k=60). Measured on LongMemEval: adding the vector arm lifted overall hit@10 from 0.85 → 0.98 — and rescued exactly the question types where lexical recall is blind (preference questions 0.38 → 0.88, assistant-knowledge 0.62 → 1.00). The full recall pipeline is in how it solves things.

-- nearest entities, cosine distance via pgvector
SELECT e.iri, 1 - (e.embedding <=> (SELECT embedding FROM donto_entity_embedding
                                    WHERE iri = 'ex:caroline-rose-brown')) AS cos_sim
FROM donto_entity_embedding e
ORDER BY e.embedding <=> (SELECT embedding FROM donto_entity_embedding
                          WHERE iri = 'ex:caroline-rose-brown')
LIMIT 5;
-- the operand must be a scalar subquery/constant for the HNSW index to be used