Mindbridge · track status

EDGE-TRUTH

The v2 graph's edge vocabulary does not mean what it says — one edge type carries three unrelated relationships, a merge routine repoints edges onto nodes their own name forbids, and nothing validates the (edge_type, source node_type, target node_type) triple at any point in its life.

Opened 2026-08-06 · re-measured against production 2026-08-08 · plan · ledger. Verify before starting: every count here decays with each merge — re-derive from the plan's stage table and production, never quote this page.

Next → #1465 relationship typing is structurally wrong — the graph inverts families (a sister typed as spouse) Decision → family disclosure (D20): AMA surfaces family relationships the person page hides — pick one policy

Silent data loss (D23) — worst open defect, still homeless: pending_attribution.target_node_id is ON DELETE CASCADE, so a twin-merge silently destroys an in-flight forward-reference attribution, and drain_pending never consults the merge-redirect resolver. A PRIME-DIRECTIVE item sitting in no stage and no issue. Unmeasured.

Audit done, remediation open — 6 defects fixed+live (D1, D5, D10, D13, D14, D21) · 18 live edge types still carry a defect verdict, findings running to D25 · 4 owner rulings open · 1 silent-data-loss finding unfiled.

5open issues

58/59types adjudicated

6defects fixed + live

9 of 9rules choke-pointed

16,231MENTIONED_ENTITY rows (08-08)

2,312AUTHORED rows (08-08)

Open work Owner rulings Standing rulings History & forensics

Open work

Wrong edges — user-visible

p1 #1465 fix(extraction): relationship typing structurally wrong — sister typed as spouse, PARENT both-directions, no reconciliation family structure inverted by extraction All

Read-only audit of the owner's tenant, checked against ground truth: Yasmine (sister) typed SPOUSE; Rama (spouse) nearly missed; Hana and Uschi (children) direction-inverted; an ex-partner's phone number typed SPOUSE. Three layers, none constraining relationship semantics: the extraction prompt is a flat type list (no disambiguation, no direction); the schema's person_a/person_b is positional (no parent/child direction); the materializer is a pass-through (no symmetry canonicalization, no PARENT↔CHILD unification, no per-pair conflict resolution). Fix is eval-gated re-extraction, not manual data edits. Pairs with the D20 ruling below.

Stale content — v2 recency

p1 #2994 node_viewer_scoped_repository orders entity nodes by nodes_v2.created_at — a rebuild timestamp, not content recency rebuild order, not content recency All

_ENTITY_NODES_BY_TYPE_SQL ends ORDER BY n.created_at DESC — on v2 that is the materialization timestamp, identical across a full rebuild, so it collapses to the n.id tiebreak and surfaces year-old items as "recent". Deliberately deferred as "parity with the prior client read"; the fix already exists in find_recent_by_type, which ranks by provenance-conversation activity and is live in three resolvers. Related: #1467 (person-card stale items), #1483 (same substrate cause).

p1 #1483 suggested-questions v2: personalized ranker uses placeholder recency on v2 (provenance-conversation cutover) no staleness filter on v2 All

The personalized ranker opts into a per-type recency cliff, but build_cliff_sql_filter deliberately raises under v2 (edges_v2.last_seen is the rebuild timestamp, not content recency), so it degrades to a Python pass-through with no real staleness filter. PR9-flip blocker: after the default-to-v2 flip, home feed + onboarding rank without real recency. Fix: cut over to provenance-conversation recency (MAX(conversations.last_activity_at)), mirroring surface_open_questions / now_feed.

Write & read-path gaps

✅ CLOSED #3307 edges_v2 concurrent upserts deadlock in a 4-way cycle — CI retries and swallows it, production has no such retry closed 08-31, root cause was elsewhere — see History All

Closed 2026-08-31 after a verification pass, independently re-derived rather than accepted on triage. The issue's stated mechanism was wrong: the cure it asked for — an edge coalescer collapsing every within-pass emission of one edge key to a single deterministic upsert — was already live in edge_coalescer.py before this issue was even filed (landed in f9f154ccc, #2219, ADR-112 §E²). The real cause was diagnosed and fixed under the duplicate issue #3598: unsorted endpoint lock order in the edge_count triggers produced the AB-BA cycle, fixed by #3619 (migration 20260827113208_edge_count_trigger_sorted_lock_order.sql). Verified reachable in production: pg_proc shows both nodes_v2_maintain_edge_count_ins/_del carrying the sorted pre-lock, not just the migration file. One residual not verified: whether the CI pg-lock-incident reporter has stayed quiet on edges_v2 since the fix deployed — that detector must stay wired regardless.

p2 #3256 BOUND_READ_VOCABULARIES is a convention with no enforcing hook — bind a literal for any of 77 edge types and nothing fails 77 types bind, nothing fails Dev only

contract.py::BOUND_READ_VOCABULARIES exists so the read/write parity gate survives a bound SQL literal, but nothing enforces registration: check.py has zero references to it, and the one test inspects only a single allowlisted type (INVOLVES_SKILL, 1 of 78). Recommended: a NewType returned only from the register functions, so mypy becomes the hook across ~28 call sites — structural, not prose. This is the gap #3246 hit, caught only because INVOLVES_SKILL happened to be allowlisted.

p3 #3102 EDGE-TRUTH: persist the matched SKILL on MATCHES_OPPORTUNITY_CAPABILITY edges card shows name, not skill All

D1's fix surfaces opportunity↔capability pairs, but the matched SKILL that makes the suggestion meaningful is not persisted — the "who should connect" card renders the partner's name ("Amira: … ↔ Kareem: Kareem"). One nullable JSONB field, one kwarg, one read; no migration. Explicitly rejected: re-deriving the skill at read time (fabrication). The existing rows keep the name fallback; a backfill is possible but not obviously worth it.

p3 #3003 graph_expand's target_type / _filter_by_target_type is unreachable from production dead filter, nothing reaches it Dev only

graph_expand(target_type=…) and _filter_by_target_type have one call site, and the only production caller (traverse_graph.py:92) never passes target_type — so the filter is dead in production and nothing catches a regression in it (proven: making it raise left all 6 e2e tests green). Decision: wire it (if "show me pictures" should route through it) or delete it — effective_target_types already covers the intent-driven case.

What the audit found — generated

⚠︎ The prose above cites 2 issues that are no longer open

#2994, #1483. A closed issue named as current work is the drift this section exists to surface — re-derive the prose, or move the reference into History.

Evidence below is generated from the read-only audit of 2026-08-29 and reconciled against the open issues at build time. Every claim cites the issue it came from. Nothing here is a decision — rulings stay in the prose above, which is written by hand.

#1263 [L2-s8,L2-s9] fix(graph): reap orphan person nodes (10% of person nodes have no edges)prodhigh confidence

Prod (Supabase MCP execute_sql, 2026-08-29): `select count(*) filter (where coalesce(edge_count,0)=0), count(*) from public.nodes_v2 where node_type='person'` → 686 orphans / 5,044 person nodes = 13.60%. Cross-checked against the real edge table, not the denormalized counter: `not exists (select 1 from public.edges_v2 e where e.source_id=n.id or e.target_id=n.id)` → 686, identical, so the counter is not stale. No remediation script exists: `git ls-tree -r --name-only origin/main | grep -i 'reap_orphan|orphan_person'` → zero hits (population = every tracked file on origin/main); the only `keep_orphan` string on origin/main is inside the generator that authored this issue text (docs/investigations/model-eval-artifacts/experimental-scripts/file_graph_quality_issues.py:366).

#1465 fix(extraction): relationship typing structurally wrong — sister typed as spouse, PARENT…prodhigh confidence

Prod (Supabase execute_sql, 2026-08-29, schema-qualified public.edges_v2 over the kinship set SPOUSE/SIBLING/PARENT/CHILD/FAMILY/PARTNER/COUSIN/IN_LAW): 54 unordered node pairs carry MORE THAN ONE kinship type; 5 pairs hold SPOUSE and SIBLING simultaneously — the exact defect in the issue title; 18 PARENT rows exist in both directions over the same pair (9 mutual pairs, each person the other's parent); 5 PARENT/CHILD inverse rows persist unmerged. Layer-by-layer on origin/main: (A) prompt UNCHANGED — mizo_conversation_prompts.py:71-74 is still a flat type list plus 'Each relationship needs evidence: a direct quote or paraphrase', no disambiguation, no anti-promotion, no direction rule. (B) schema UNCHANGED and now WORSE — conversation_extraction.py:467-489 ConversationRelationship is person_a/person_b/relationship_type/confidence with no direction field and no `evidence` field at all, so layer D's provenance is not merely at risk, the evidence string is no longer a model field. (C) PARTIALLY fixed — a new aggregator, backend/app/slices/graph_building/aggregators/relationship.py, canonicalizes SYMMETRIC types order-independently via _pair_key (line 43) and dedups by (pair, type) with RELATIONSHIP_MIN_CORROBORATION=1 (constants.py:26). It does NOT unify PARENT with CHILD-inverse and does NOT do per-pair conflict resolution — matching the 18/5/54 prod counts exactly.

#3003 graph_expand's target_type / _filter_by_target_type is unreachable from productioncodehigh confidence

origin/main backend/app/services/ask/graph_traversal.py:571-575 defines `_filter_by_target_type`, called only at line 664-665 under `if target_type:`. The sole production caller of `graph_expand` is backend/app/services/ask/tools/traverse_graph.py:96-103, which passes entities, traversal_repo, graph_query_repo, query, limit, max_tier — and NOT target_type. Population for the absence claim: `git grep -n "graph_expand(" origin/main -- backend` — every hit enumerated; non-test, non-script hits are exactly traverse_graph.py:96 plus graph_traversal.py's own definition/doc lines. The other callers are backend/scripts/poc/poc_soma_capture{,_v2,_v3}.py (ad-hoc scripts, verified at poc_soma_capture.py:50 to omit target_type) and test files. The `effective_target_types` path (lines 256-264, 362-363) is live and unaffected.

#3102 EDGE-TRUTH: persist the matched SKILL on MATCHES_OPPORTUNITY_CAPABILITY edgescodehigh confidence

origin/main:backend/app/slices/edge/properties.py:517 `MatchingEdgeProperties` still declares exactly one field, `edge_type: str`, with the docstring "there is no per-type property to model". origin/main:backend/app/slices/edge/matching.py `matching_edge_intent` signature is still (tenant_id, source_id, target_id, edge_type, match_score, provenance_conversations) — no skill kwarg, docstring still says "Property-less on purpose". origin/main:backend/app/services/ask/connection_resolver.py:489 still states "``MatchingEdgeProperties`` has no ...". Prod: `select count(*), count(*) filter (where properties is not null) from public.edges_v2 where edge_type='MATCHES_OPPORTUNITY_CAPABILITY'` → 112 edges, all with properties, and sampled rows are `{}` — zero skill data persisted.

#3256 BOUND_READ_VOCABULARIES is a convention with no enforcing hook — bind a literal for any…codehigh confidence

`git show origin/main:backend/scripts/hooks/check.py | grep -c 'BOUND_READ\|bound_read'` -> 0: no hook references the registry or `register_bound_read_vocabulary`. The proposed structural fix is absent: `git grep -n BoundEdgeVocabulary origin/main -- backend` returns nothing (population = whole backend tree on origin/main), so no NewType carries the registration and mypy enforces nothing. The registry itself is unchanged at `backend/app/slices/edge/contract.py:429-505` — still a plain `dict[str, tuple[str, ...]]` whose docstring states 'Binding a literal DISARMS that gate unless the vocabulary lands here.' The only consumer is the parity test's `_read_edge_types()` (`backend/app/slices/graph_building/edge_traversal_parity_test.py:129-138`), which resolves a registration by literal substring of either leg of `module::SYMBOL` against the 4 `_READ_FILES` — exactly the mechanism the issue describes, with no detector for a bind that never registers. Only registered site on main is `SKILL_CONCEPT_EDGE_TYPES` (attribution_vocabulary.py:210).

Open questions — what the audit could not settle

#1263 Which of the 686 are name-resolution misses vs legitimately-not-yet-linked people — the classification the issue asks for is unbuilt, so I cannot say what fraction is deletable. Closes with: `select n.id, n.canonical_name, n.source_type, n.created_at, exists(select 1 from person_identities pi where pi.person_node_id=n.id) has_identity, exists(select 1 from messages m where m.sender_person_id=n.id) has_messages from nodes_v2 n where n.node_type='person' and coalesce(n.edge_count,0)=0` — the has_identity/has_messages split IS the decision tree. Also unknown: the 'hh baseline' tenant in the body does not exist in prod (35 tenants, Regina/aeldaly); no command closes that, the referent is gone.
#1465 (1) Whether the symmetric-fold aggregator is what is actually running in prod versus a stale materialized set — the 54 conflicted pairs prove the CONFLICT layer is absent but not that the symmetric fold is deployed. Close with: select count(*) from public.edges_v2 a join public.edges_v2 b on a.tenant_id=b.tenant_id and a.source_id=b.target_id and a.target_id=b.source_id and a.edge_type=b.edge_type and a.edge_type in ('SPOUSE','SIBLING','FAMILY'); (2) the aeldaly ground-truth pairs named in the body (Yasmine, Rama, Hana, Uschi) were not individually re-checked. Close with: select a.canonical_name, b.canonical_name, e.edge_type, e.corroboration_count from public.edges_v2 e join public.nodes_v2 a on a.id=e.source_id join public.nodes_v2 b on b.id=e.target_id where e.tenant_id='23d86e0d-9b8a-4b24-a0fa-cd1909ed6c68' and e.edge_type in ('SPOUSE','SIBLING','PARENT','CHILD');
#3003 Whether the 'show me pictures' intent is meant to be served — that is an owner/product decision between wire-it and delete-it. Nothing mechanical closes it. To bound the cost of option 2, run `git grep -n "target_type" origin/main -- backend/app/services/ask/` to enumerate the parameter's reach before deleting.
#3102 Whether the matcher still computes `source_judge_text` at opportunity_capability_matcher.py:190 (the value the fix would thread). Closed by: `git show origin/main:backend/app/services/.../opportunity_capability_matcher.py | grep -n source_judge_text`.
#3256 Whether the 28 `edge_type = ANY(...)` call-site count in the issue body still holds on today's main — I did not re-census it. Closable with: `git grep -n "edge_type\s*=\s*ANY" origin/main -- backend/app/slices | wc -l`.

15 assessed issues closed since the audit and are not shown — a closed issue's evidence is history, and printing it as current is how a page starts lying.

Open owner rulings — four

41 retyped edges— D5 is forward-only: re-point, drop, or flag?

ORGANIZED vs ORGANIZED_BY— collapse to one edge, or union at the read seam? The last type left unaudited.

Calendar provenance (1c)— populate it and 2,583 calendar events appear in the now-feed at once.

Family relationships (D20)— AMA surfaces family relationships the person page hides; pick one policy.

Why is it in this order?

Order: user-visible wrong edges first, then stale-content surfaces, then structural write/read gaps — and within a cohort by priority (p1 → p2 → p3) then oldest-first. It ignores what blocks what (GitHub carries no dependency edge we populate), how long anything takes, and which commitment an issue serves. The 08-14 ruling that the upsert deadlock (#3307) does not outrank the rest of the track is now moot — #3307 closed 08-31, its real cause fixed under #3598/#3619.

Standing rulings

The edges_v2 upsert deadlock (#3307) does not outrank the rest of the track (track-order.json, 2026-08-14) — moot since 08-31: the issue is closed, real cause was trigger lock order, fixed by #3598/#3619.
Sharing counts on a list surface, not the single-owner lookup — distinct documents per person 261 → 13,489, people with any 207 → 1,872, across 15 tenants (08-08).
Interaction signals out of assistant traversal and the entity detail surface; the person page keeps them — one derived source, default withholds rather than discloses (08-08).
HHI_AUTHORED: ship, and log it open — the flip takes five tenants to exactly 0; the metric is internal-only and measurement is owner-deferred (08-08).
Content concentration: ruled out of this track — admin-only, does not feed the tenant-visible composite; ADR-143 says otherwise and is wrong (08-07).
Client-side AUTHORED filter (1x): decided against — correctness by "every caller remembers"; stage 5 shipped instead.

History & forensics

Discovery, stage 1–2, and the AUTHORED split — done

Rounds 1+2 censused 59 live edge types and adjudicated 58 (ORGANIZED/ORGANIZED_BY held back — a design decision, not a defect). Round 2 changed what the track is about: round 1 found wrong edges, round 2 mostly found wrong readers — contracts honoured by one consumer and silently absent from another. Six defects fixed and live: D1 (connection resolver dropped all 109 MATCHES_OPPORTUNITY_CAPABILITY rows — #3104), D5 (reconciliation retyped pinned edges — #3098; forward-only, 41 rows still wrong), D10 (intent-less AMA traversal hit the DB unfiltered — #3097), D13 (completed actions listed as open — #3114), D14 (met needs / resolved problems offered as open — #3120), D21 (skill 2-hop dispatched for three types its SQL can never match — #3246).

Stage 2 (#3160, issue #3140) landed the contract, the consumer half, the attribution vocabulary and the reader census as one release with nine choke-point rows. Its third adversarial panel — run after the fixes — found six more defects plus the same comment-stripper failure in three security gates, all previously failing open.

The AUTHORED split (ADR-143, accepted 08-07) minted MENTIONED_ENTITY for the entity-mention meaning. Stage 5a shipped across #3129 (reader prep), #3210 (remaining readers + intent-map reachability), and #3222 (the flip + reclassification). 5a-live, measured on prod after the deploy: AUTHORED now means authorship in 100% of its rows (was 1.3%); MENTIONED_ENTITY 16,169, AUTHORED 2,303, rollout residue 0; the producer was OBSERVED writing the new spelling (14:40–14:48Z, Regina). A 4-lens panel before merge found silent data loss in the migration: the DELETE lacked the UPDATE's collision guard, so a row committed between the two statements was destroyed and counted as a duplicate. Also fixed: a provenance merge, a guard test that was vacuous by execution, and a MENTIONED_ENTITY label missing from both locales. The 2c nightly gate's runner was structurally dead since 2026-05-13 (87 "success" runs, 0 rows) and was repaired (#3225); 2c's precondition is a row in invariant_runs, not a green workflow run.

Remaining open defect verdicts — D6–D25, unfiled

D6 ANSWERED direction diverges from ADR-071 (1,957 rows) · D7 ATTACHED_TO/CALLED have live producers and zero rows · D8 8 dead enum members + a wrong types.py header · D9 fetchPersonEdges shares one LIMIT 200 across all 15 edge types · D11 personal names typed node_type='company' (≥3 in ~140 sampled) · D12 intent matcher fed the entity name, not the query (1f — the obvious fix activates a banned English lexical matcher, needs an ADR) · D15 ATTENDED_BY 7,482 rows, zero consumers · D15b use-entity spreads OUTGOING unfiltered → 404 links · D16 INVOLVED_IN 309 rows, no consumer · D17 MEMBER_OF 731 rows drive access-control, unreachable from any surface · D19 MANAGER=REPORT=124 exactly (one few-shot example mints both); PARENT/CHILD drift 33/5 · D22 match cards render a 0.70 guess identically to a 1.0 match (1j, unblocked, cheap) · D23 pending_attribution silent data loss (surfaced above, unfiled) · D24 SHARED_JOB_POSTING 259 rows, zero readers · D25 INVOLVES_SKILL has no producer, types.py claims otherwise. Not-started stages: 2c nightly drift gate (use created_at DESC, never ORDER BY id — edges_v2.id is a random v4 UUID), 3 comment + dead-code corrections (trivial), 5b/5c/5e/6 (retyped targets, the six render surfaces — narrower than the plan implies after the flip — the shared 200-row budget, corrected-vocabulary consumers).

#3307 edges_v2 deadlock — closed 08-31, cause was elsewhere

Closed after independent re-verification, not on the triage pass alone. The fix this issue asked for (an edge coalescer) already existed and predated the issue by weeks — edge_coalescer.py landed in f9f154ccc (#2219, ADR-112 §E²). The actual deadlock cause was diagnosed under duplicate issue #3598: unsorted endpoint lock order in the edge_count triggers, fixed by #3619 (migration 20260827113208_edge_count_trigger_sorted_lock_order.sql), verified live in prod pg_proc. Not verified at close time: whether the CI pg-lock-incident reporter has stayed quiet since the fix deployed — leave that detector wired.

Verified against production — do not re-derive

The unique index is (tenant_id, source_id, target_id, edge_type) — a unique index with no named constraint. edge_count triggers fire on INSERT and DELETE only, so an edge_type-only UPDATE leaves the counter untouched. No live SQL reads AUTHORED at all (zero function bodies, views, matviews). Measured 08-08 21:00Z in one snapshot: AUTHORED 2,312 rows / 12 tenants (answer 2,048, document 264), MENTIONED_ENTITY 16,231 / 17 (company 7,811, location 4,639, product 3,414, project 367), edges_v2 173,417 / 22. The migration moved 16,169 (16,166 predicted + 3 minted, the ~400/day rate). The contract still holds against the live producer: zero rows of either type outside their declared target set. The six-vocabulary survey undercounted — the stage-2f census found more, and by 08-08 register_attribution_vocabulary is called 10 times with _UNCONVERTED_FORKS at zero.