Refined relationship graph and managed PR cleanup
Public
Refined relationship graph and managed PR cleanup
Agent
Claude Code
Model
Claude Opus 4.8
Shared
Jun 17, 7:09 AM
Messages683
Downloads0
Workspace
Repo
Investigated false and duplicate graph edges and junk entities.
UnderstandFixed extraction logic and added filtering for promotional data.
EditImplemented a strength model for relationship intelligence.
BuildUpdated UI with you-centered relationship graph and contact details.
EditValidated model and UI with live data and tests.
VerifyLet me look at those screenshots and understand the relationship graph problems.
I can see the problems clearly in both screenshots:
Let me investigate the graph extraction, resolution, and display code to find the root causes.
I launched an exploration agent to map the graph code. While it works, let me look at the key files directly.
Now let me read entity-resolution and find where edges get written.
I now understand the data layer. Let me read the relationships page to see how edges are rendered, and check the DB to confirm what's actually stored.
Let me check the layout component and whether I can query the live DB to see the actual edge data.
Let me query the live DB to see the actual edge data — confirm duplicates, confidence values, and the junk entities.
Let me write a temp query script and run it with the env sourced.
The explore agent confirms the root causes. Let me fix the ws resolution and run the live inspection to ground the fix in real data.
Now I have the real picture — and it's more revealing than "low confidence." Let me check the Gmail connector and ingestion to confirm where the junk originates.
The Gmail connector stores labelIds in metadata — Gmail's category labels (CATEGORY_PROMOTIONS, CATEGORY_UPDATES, etc.) are exactly what mark newsletters and broadcast mail. Let me verify the junk edges trace back to those categories.
This is conclusive. Every junk edge traces to CATEGORY_PROMOTIONS / CATEGORY_UPDATES Gmail mail — Borrowell loan promos, Devpost hackathon digests, CoinGecko API newsletters. And of the ~100 Gmail items that produced edges, 57 are UPDATES + 43 are PROMOTIONS — the graph is mostly built from broadcast mail, not real correspondence. Those describe third-party facts ("Devpost hosts FIND EVIL!"), not the founder's orbit.
Here's my diagnosis and fix plan. Let me confirm the call site, then implement in a worktree.
Diagnosis is conclusive and grounded in live data. Let me enter a worktree to implement the fixes.
Let me verify the worktree has the current graph code (it branches fresh from origin/main).
Worktree matches main. Now implementing. First, the root-cause fix in triple-extraction.ts — a bulk/promotional gate plus a tightened prompt.
Now the file is read. Let me apply the edits.
Now tighten the extraction prompt to enforce the founder's first-person orbit and forbid co-occurrence inference.
Now wire the gate into extractAndResolve. Let me read the worktree's entity-resolution.ts region.
Now Fix 2: dedup edges and add a confidence floor in the graph API. Let me read the worktree route.
Now rewrite the edge handling: confidence floor at the DB query, then collapse duplicate (subject, relation, object) rows into one corroborated edge.
Let me also filter returned entities to those that actually appear in a surviving edge — this guarantees no floating junk nodes regardless of leftover DB state.
Now add count to the GraphEdge type and surface corroboration in the detail panel for trust. Let me update layout.ts and the page.
Now surface corroboration in the panel signals. Let me read and update the worktree page.
The code fixes prevent recurrence, but the existing bulk-promotional edges are already in the DB at high confidence (0.85–0.95) — they'll still render until removed. Let me write a cleanup script (shared logic, dry-run by default) and run it.
Let me run the cleanup as a dry run from the worktree.
The worktree has no node_modules; module resolution walks up to the main checkout. Let me invoke tsx directly from the main repo's binary.
275 of 285 edges flag as bulk — but that's too blunt: it would also delete the true, valuable "Dhravya founded Supermemory" (his mail lands in CATEGORY_UPDATES), which the user wants kept. Category/sender can't tell "Dhravya founded Supermemory" (keep) from "Devpost hosts FIND EVIL!" (drop) — only the founder-perspective LLM judgment can. So the right cleanup for existing data is re-extraction under the new prompt, not a blunt category delete.
Let me confirm the RawItem shape before building the reprocessor.
The principled cleanup is re-extraction under the new prompt. Let me replace the blunt script with a reprocessor that re-runs extraction on edge-producing items (deleting stale edges first), so the new founder-perspective prompt naturally drops Devpost-style third-party facts while re-affirming real edges.
Before running anything destructive, let me typecheck the edits and run the graph tests.
Tests pass, typecheck clean. Now let me validate the new prompt actually drops the Devpost junk on real items before mass-reprocessing. Quick probe (read-only, no DB writes):
The gate works — but it reveals something important: this demo mailbox is almost entirely automated signups and newsletters. Even "Welcome to supermemory" (where "Dhravya founded Supermemory" comes from) is a CATEGORY_PROMOTIONS marketing email, not personal correspondence. So a strict gate would shrink the graph dramatically. Let me quantify exactly what survives under different strictness levels before doing anything destructive.
This is the crux. Concrete numbers (deduped, conf ≥ 0.75 — 234 logical edges):
CATEGORY_UPDATES): 159 edges — but Devpost and similar survive.CATEGORY_UPDATES mail, 76 from promotions/social, only 10 from genuine correspondence.The finding: this demo inbox is almost entirely automated signups and newsletters. The graph looks rich because it's full of newsletter-derived facts. An honest graph from this data is small. Gating CATEGORY_UPDATES wholesale is too blunt (it'd kill real product-mail relationships too) — the founder-perspective prompt should judge that gray zone. Let me refine the gate accordingly and sample-estimate the balanced outcome before doing anything destructive.
Now let me sample-estimate the Balanced outcome: run the new prompt on a sample of CATEGORY_UPDATES items (no longer gated) to see how many edges survive and whether Devpost-style junk is dropped.
Balanced is clearly the right call — and it's not empty. The new prompt correctly drops the junk while keeping real relationships:
Result: ~234 mostly-junk edges → ~26 trustworthy ones. The false "Dhravya works_with Venus" came from a CATEGORY_PROMOTIONS Supermemory email (now gated) and is also below the 0.75 floor. This matches your intent exactly, so I'll proceed with it. Let me dry-run the reprocessor end-to-end, then apply.
Dry-run is clean: 285 edges, 113 items, 80 gated. Now applying the rebuild (33 LLM re-extractions, rewrites edges):
The destructive DB rewrite was blocked by the safety classifier — reasonably, since it mass-rewrites shared Supabase state across tenants. That needs your explicit go-ahead, which I'll ask for below. The code fixes are done and safe; let me finish them properly with tests, then hand you the cleanup decision.
Let me look at the existing test style and add coverage for the new gate.
Now a test for extractAndResolve skipping bulk mail. Let me check the existing resolution test's mocking style.
All 19 graph tests pass. Let me typecheck the full worktree once more (tests included) to be safe.
Typecheck passes. Let me review the full diff, then commit the code changes (the data cleanup stays pending your approval).
That staged a large amount of pre-existing divergence (the worktree branched from origin/main, which is behind the local work). I only want to commit my graph changes. Let me unstage and inspect.
Let me verify the page.tsx diff is only my change (not absorbing unrelated divergence).
Clean — my corroboration change plus two harmless prettier reflows. Let me commit exactly the graph files plus the reprocess script.
Only my 8 files are staged. Committing.
Code is committed. Now the one thing I can't do without your explicit OK: the data cleanup that fixes what's on screen right now. The safety classifier blocked it (it mass-rewrites edge/entity rows in the shared Supabase DB), which is the right instinct — so it's your call.
Here's exactly what it does and what you'd see:
You approved it — running the rewrite now.
The rewrite ran: 285 edges → 30, and 228 orphaned entities removed. Let me verify the live result through the same logic the API uses — confirm the junk is gone and good edges remain.
The result is exactly what we wanted. Let me record this as a durable project insight for future sessions.