Recall a mention by its name vector so a short form or another script meets its entity

[WaylandYang]

0041 decision 3 names three recall channels; today only the first exists (a literal match of the mention's name against name facts). This lands the second: the mention's name vector against the name vectors of the base, so 海探1 finds 海洋探测器1号 and a name written in another script finds its entity (#709) without either being spelled the same.

What it does, and deliberately does not do

• Recall proposes; nothing new decides. A near name is never attached. It becomes a name_vector|<cosine> pair for the batch adjudicator, which already judges pairs from two profiles and precedent. Evidence-based deciding is 0041 cut 3 and is not touched. So this change can only add questions, not silent merges.
• Candidates the literal channel already handled are not re-proposed (same lowercase name → skipped), and a candidate whose type_family is known and differs from the mention's is skipped. An unknown family blocks nothing: when unsure, ask.
• With no embedding model configured the channel is simply absent and extraction behaves exactly as before.

Pieces

• migrations/0073_a_name_has_a_vector.sql — name_vectors(fact_id PK, kb_id, entity_id, embedding vector), one row per name fact; composite same-KB foreign keys and the kb_ownership_is_not_reassigned trigger per 0070. A side table rather than a column on facts (every SELECT * … Fact would have to change) or on entities (an entity has as many vectors as it has names).
• utopia_store::name_vectors — pending, set (registers the HNSW build with vector_index, new Target::NameVectors), nearest (0035's two rules: casts on both sides of <=>, vector_dims predicate; outer re-sort qualified to the CTE).
• resolution::resolve_mention gains name_vector: Option<&[f32]>; the old body is resolve_by_name unchanged. All callers updated; mapping paths pass None.
• extraction_open::run_open embeds each chunk's named entities in one batch before resolving them (failure → warn, chunk falls back to literal recall), and after the document tops up name facts that have no vector yet (embed_pending_names, batched, failure → warn, never fails the document).
• i18n name_vector reason in both packs; design/identity.md and 0041's status line updated.

Verified

Against pgvector/pgvector:pg16 on a fresh database migrated through 0073:

• cargo test -p utopia-store: 333 passed, 0 failed (4 new in a_similar_name_is_proposed_not_merged.rs: near name → new entity + adjudicator pair; other family → not proposed; far / no vector → nothing; literal hit → not re-proposed)
• cargo test -p utopia-server: 384 passed, 0 failed
• cargo clippy --workspace --all-targets -D warnings clean; cargo fmt --check clean
• web: tsc, pnpm guard (99 files), pnpm test 132 passed

End-to-end, five rounds

Real server from this branch (port 1518) against a fresh Postgres, a deterministic OpenAI-compatible stub standing in for the models (character-hash embeddings, canned open-extraction replies, a batch adjudicator that answers from a per-round alias list), one new knowledge base per round, documents pushed through /kbs/{id}/ingest and jobs left to run:

Round	Documents	name_vectors	Outcome
R1 full name → short form	海洋探测器1号 …, then 海探1 …	4	pair proposed → adjudicated same → merged; survivor holds both name facts
R2 short form → full name	reverse order	4	same result, order-independent
R3 Chinese → English (alias known to the stub embedder)	海洋探测器1号 …, then Ocean Probe No. 1 …	5	both cross-script pairs merged (probe and manufacturer)
R4 namesake control	张伟 ×2 in different departments + an unrelated device	6	two 张伟 entities, no channel-2 pair; nothing spurious
R5 no embedding model configured	same documents as R1	0	no pairs, extraction unaffected — the controlled negative for R1

The first E2E pass found a bug the unit tests could not: name_vectors::pending ordered by facts.created_at, a column that does not exist, so the end-of-document top-up failed on every document (logged, swallowed) and channel 2 never fired. Fixed to order by id (uuid v7) in the second commit, with a pending → set → pending round-trip test. Every server warning was clean on the final pass.

The harness (stub + driver) is deliberately outside the repository, per the project's rule on harnesses; it is available on request.

Not verified here, and needs a maintainer run

scripts/bench/identity.mjs has not been run: this machine has no embedding endpoint configured (llm_settings.embed_model is null), and the bench needs one. TOP_K = 8 and SIM_FLOOR = 0.60 are provisional values with their reasoning in the comments; the bench should set them. Retiring recall_keys and the generic-suffix lists once channel 2 finds what they found is cut 4, not this PR.

Two small costs worth knowing: names resolved in a chunk are embedded again by the end-of-document top-up (the resolver does not learn the name fact's id; one extra embed call per document), and nearest fetches 4·k rows inside the CTE to leave room for the status filters outside it.

Migration number: 0073. This started as 0072 and collided with #878, which took 0072 on dev while this was open, exactly the case CONTRIBUTING warns about: git merges the two files without complaint and sqlx refuses to run. Renumbered and merged dev back in; the 版本号不得重复 check and _sqlx_migrations on a fresh database (72 rows, max 73) both confirm. 0071 is still held by #861. utopia-cli's CURRENT_SCHEMA_VERSION is pinned by test to the count of files in migrations/, so it is 72 here (70 + #878's 0072 + this 0073); its comment now describes the gap rule without quoting a number that moves.

Full cargo test --workspace against Postgres, the way the backend job now runs it: 1042 passed, 0 failed.

🤖 Generated with Claude Code

[WaylandYang]

The design is right for cut 2 of 0041 decision 3: channel 2 proposes a pair with its cosine and decides nothing, the literal channel keeps its ground, a family mismatch is a skip and an unknown family is a question. The store module follows 0035's two rules and 0070's same-base keys, and the extraction path degrades to literal recall on every failure rather than failing the document. One thing blocks the merge and one is a question.

Blocking: the migration number collided again. dev now has 0073_a_statement_shape_implies_a_fact.sql (#882, merged after this PR was renumbered), and #885 takes 0074. Git will merge both 0073 files without a word and sqlx will refuse to run, exactly the case the PR body describes. Please renumber to 0080: that is the first number of the range the identity track holds (A holds 0072 to 0079, B 0080 to 0089, per the coordination note), so it cannot collide with anything still open on the alignment side. CURRENT_SCHEMA_VERSION in utopia-cli is the count of files: with 0072, 0073 and 0074 on dev plus 0080 it is 74. The 版本号不得重复 check and a fresh _sqlx_migrations will confirm as before.

Question, not blocking: nearest joins entities … AND e.description IS NULL. The comment says a described thing has no name fact, which is true and makes the predicate redundant for those rows; but if an entity can carry both a name and a description (a named thing the document also describes), the predicate would drop its names from recall. If description is set only for unnamed things, say so in the comment and keep it; otherwise drop the predicate, since the join on a live name fact already excludes the unnamed.

Everything else read cleanly: the break on the floor is sound because nearest orders by distance ascending, the seen set keeps the literal hit and the excluded ids out, and the end-of-document top-up is the right place to pay the one extra embed call.

[WaylandYang]

Both taken, in b9dccec (rebased onto #886's single-binary test layout):

• Migration is 0080, CURRENT_SCHEMA_VERSION is 74 (0001–0070 + 0072/0073/0074 on dev + 0080). A fresh database migrates to 74 rows with max version 80, the duplicate-number check is empty, and schema_version_policy_compares_against_current passes. Noted the range split — identity track 0080–0089 — so this cannot collide with anything still open on the alignment side.
• e.description IS NULL is gone from nearest. You are right that it was redundant today and would be wrong tomorrow: the JOIN facts … known_as already excludes a described thing (it has no name fact, 0044), so the predicate filtered nothing — and if a named entity ever also carries a description, its names must still be recallable. The comment on nearest now says that instead.

Also in this revision: the E2E pass (five rounds against the real server, described in the body) found that pending ordered by a column facts does not have, so the end-of-document top-up had been failing silently; fixed to ORDER BY f.id, with a pending → set → pending round-trip test. The new test file lives in tests/store/ and is in main.rs's module list; cargo test -p utopia-store on a fresh database is 345/0 with all five of its cases running inside the store binary.