canonical(knowledge): two functions named content_hash return different values — full digest vs 16-char truncation #15722

Summary

content_hash exists twice in autobot-backend/knowledge/, with the same name and different return values:

A same-name/different-semantics pair is worse than a plain duplicate: a caller who imports the wrong one gets a silently wrong key rather than an error. For the dedup key specifically, a full-digest value never matches an existing content_hash:<h> Redis index entry, so every fact would read as new — the duplicate-creating direction.

The truncation is also still written inline, three times

fact_store.content_hash() was added by #15663 as the canonical computation, but the literal it replaced still stands at three call sites:

• knowledge/fact_projection.py:132 — hexdigest()[:_CONTENT_HASH_WIDTH] (a second constant for the same 16)
• knowledge/facts.py:586 — hexdigest()[:16]
• knowledge/facts.py:1175 — hexdigest()[:16], in _cleanup_fact_mappings, which computes the key to delete it

That last one is the sharp edge: the write path and the cleanup path derive the same Redis key independently. If one width changes, deletes stop matching writes and the dedup index leaks entries pointing at facts that no longer exist — which then resolve as duplicates on the next create.

This is the exact anti-pattern #13916 tracks, left behind by the change that introduced the canonical function. Reported by review of the work rather than found later.

Acceptance criteria

1. One definition of the fact dedup key. The three inline computations import it; _CONTENT_HASH_WIDTH exists once, beside that definition, not in two modules.
2. The connector helper and the fact-dedup helper no longer share a name, or are shown to be the same concept and merged — whichever the code supports. Same name, different width is not an option.
3. A guard in the shape of repo_tests/audio_extension_allowlist_test.py::test_no_fourth_literal_copy_exists fails when the truncation is written as a literal outside its home.
4. autobot_shared/store_authority.py's knowledge_facts entry states that the dedup index is derived from this one function, since a projection rebuilt from a differently-computed key is not the same projection.

Related

• canonical(state): knowledge_facts dedup keys are advisory — no uniqueness on content_hash or unique_key #15673 — whether this key should be a database-enforced invariant at all (it is 64 bits; a collision would reject a legitimately different fact).

• Umbrella: canonical-source duplication — concepts with no single definition, where the copies have already drifted #13916 — the umbrella this pattern belongs to.

• autobot-backend/agent_loop/fingerprint.py content_hash delegates to autobot_shared.content_digest.content_digest(normalize_content(content)), with byte-identical output and an equivalence test. Same primitive, different input, so it is a third copy of the digest. It lands on the canonical(knowledge): two functions named content_hash return different values — full digest vs 16-char truncation #15722 branch after tech-debt(backend): six regex concepts are forked across 2–8 files each, and one fork is a no-op #18093 (which owns fingerprint.py until it merges) is on main.

• autobot-backend/code_intelligence/pattern_analysis/analyzer.py: the literal EMBEDDING_MODEL = "nomic-embed-text" is removed; the cache key and the generator resolve from one source, the recorded index space (knowledge/index_embedding_space.py index_embedding_space("code_patterns") → space_id / model_id). Amended 2026-10-12 by owner ruling: the analyzer is index-bound (its stored vectors must be queried in the space they were built in), so it resolves from the recorded space rather than active_embedding_model(); the original wording would reintroduce the fix(knowledge): one active embedding model resolver, model-aware cache keys, and search refuses rather than embed in another space (#18143, #18185) #18230 defect.