Memory router

Memory Router

Decides where new content belongs in D Rage's JoVE knowledge system: Obsidian vault (RAM) for what changes, Pinecone (jove-memory index) for what doesn't. Apply this BEFORE writing any new artifact — not after.

The one routing rule

Ask: "Will this be edited again?"

• Yes → Obsidian vault (RAM)
• No → Pinecone jove-memory (HD)

That's it. Everything below is tiebreakers and namespace-routing for when the answer isn't obvious.

Why this rule works

Obsidian and Pinecone are complementary, not competing — they serve different cognitive layers:

• Vault = reasoning surface. Mutable. Wiki-linked. Indexed by [[index]] + MOCs. The shape of D's thinking lives here. Every Claude session pays a token tax to load index.md + CLAUDE.md, so the vault should stay lean.
• Pinecone = perfect-recall archive. Immutable. Semantic search via E5 embeddings. Cost is flat regardless of size. Conversations, books, meetings, deep-research snapshots — everything that happened but isn't current belongs here.

Mixing them fails both ways: if you put archive content in the vault, the wiki bloats and the token tax grows linearly with content volume. If you put active strategy in Pinecone, you lose the wiki-link graph that makes reasoning possible.

Tiebreakers (apply in order when "Will this be edited again?" is ambiguous)

1. Will it be searched semantically? ("Find anything we ever discussed about X.") → Pinecone. Vector search is the point.
2. Will it be wiki-linked from MOCs or other notes? → Vault. The graph is the value.
3. Is it a snapshot of state on a specific date? (e.g., "as of 2026-05-23, competitor X has Y features") → Pinecone with as_of metadata.
4. Does it represent the current authoritative position? (e.g., "this is the PI persona we're going with") → Vault.
5. Is it >2,000 words? → Strongly consider Pinecone chunking. Vault notes >2K words become unreadable.
6. Does the user need to edit it by hand in Obsidian? → Vault.
7. Is it generated by a deep-research / book-digest / meeting-transcript flow? → Pinecone (default for these flows).

Vault routing (when Obsidian wins)

The vault at ~/Obsidian/JoVE/ uses Johnny.Decimal numbered folders. Place per content type:

Folder	Content
10 — Company/	JoVE company-wide notes (about, history, org structure)
20 — Product Lines/	Research / Education / Business products + product anchors
30 — Customers & Market/	Personas, competitors, market intel (the CURRENT view; archived deep-dives → Pinecone)
40 — People/	Internal JoVE colleagues + External customers/partners
50 — Decisions & Bets/	One note per significant decision (review_date frontmatter)
60 — Meetings/	One short stub per meeting; full transcripts → Pinecone meetings
70 — Daily Notes/	Today's + last ~30 days; older rolls to Pinecone daily-archive
80 — Resources & Reference/	Glossary, books (as pointer stubs), tools, raw/ archive
99 — Meta/	Templates, scripts, vault meta (log.md, Lint Playbook, etc.)

Every vault note needs: YAML frontmatter (type, status, domain, tags, created, updated, source_urls, confidence) per [[CLAUDE]].

Pinecone routing (when Pinecone wins)

Index: jove-memory. Embedding: multilingual-e5-large (integrated; 1024-dim; truncates at 512 tokens — keep chunks ≤350 words).

Pick the namespace:

Namespace	What goes here	ID prefix pattern
conversations	Wrap-ups of Claude sessions (≤350 words each)	convo-{YYYY-MM-DD}-{kebab-title}
meetings	Granola meeting transcripts + summaries (post-D-joins-JoVE)	meeting-{YYYY-MM-DD}-{kebab-title}
emails	Customer / Slack / institutional Gmail archives	email-{YYYY-MM-DD}-{kebab-title}
research	Deep-research outputs (competitive scans, market reports)	research-{topic-slug}-{YYYY-MM-DD}-{section}
books	Book digests (chunked by chapter/concept)	book-{title-slug}-{YYYY-MM-DD}-{section}
daily-archive	Daily notes >30 days old	daily-{YYYY-MM-DD}
bootstrap-research	FROZEN — 8 original research streams; do not write here	bootstrap-{stream}-{section}
crawl-source	FROZEN — JoVE website crawl; do not write here	crawl-{branch}-{key}

Always include rich metadata per record: as_of, topic, tags[], source_urls[], plus any namespace-specific fields (e.g., branch for crawl, author for books, attendees for meetings).

Verify upserts: after upserting, do one mcp__pinecone__search-records round-trip on a query the record should match. Confirm hit at ≥0.80 similarity. If lower, the chunk is probably too noisy or too long.

The hybrid pattern (when both apply — the most common case)

For LARGE or IMMUTABLE content that also needs vault discoverability:

1. Pinecone: full content, chunked appropriately. This is the canonical store.
2. Vault: 1-page POINTER note that:
   • Has standard frontmatter PLUS pinecone_namespace and pinecone_id_prefix fields
   • Lists the Pinecone record IDs as bullets
   • Includes a teaser/synthesis paragraph (the "why this matters" condensed)
   • Wiki-links to relevant MOCs, personas, features
   • Cites 1 or 2 surprising findings ("the wedge insight")

Existing examples in vault to follow:

• [[Hooked — Nir Eyal]] — 1-page book pointer with 8 Pinecone IDs in books namespace
• [[Crawl Provenance]] — pointer to 287 records in crawl-source
• [[Competitors — AI Assessment for Science]] — competitor pointer with 6 records in research
• [[Competitors — Lab Hiring Funnels]] — same pattern

The pointer note is what shows up in the vault graph + MOC indexes; the Pinecone records are the answer-substrate for semantic queries.

Decision examples (apply the rule)

Example 1: User says "Ingest the 'Nature Protocols' deep-dive I just researched." → Will it be edited again? No (it's a snapshot of state on 2026-05-23). → Pinecone research namespace + vault pointer note Competitors — Nature Protocols.md. Hybrid.

Example 2: User says "Update the PI Persona note to add a 6th sub-persona." → Will it be edited again? Yes (personas evolve as PI conversations happen). → Vault edit only. No Pinecone.

Example 3: User says "Save this conversation about the architecture decision we just made." → Will it be edited again? No (conversation wraps are by definition done). → Pinecone conversations namespace via /wrap-up skill. Log entry to vault.

Example 4: User says "Create a Granola meeting note for today's call with the CEO." → Will it be edited again? The summary stub MAYBE (action items get checked off); transcript NO. → Hybrid: short stub in 60 — Meetings/2026-MM-DD — CEO 1:1.md (vault, action items + decisions + key quotes ≤200 words); full transcript in Pinecone meetings.

Example 5: User says "Help me draft a new strategic decision about JoVE Labs pricing." → Will it be edited again? Yes (decisions get refined; review_date is in frontmatter for a reason). → Vault decision note in 50 — Decisions & Bets/. No Pinecone.

Example 6: User says "Index Alex Hormozi's $100M Leads book." → Will it be edited again? No. → Pinecone books namespace + vault pointer stub. Hybrid.

Example 7: User says "Add this article I just read to the vault." → Apply tiebreaker 6: will user edit by hand? Probably not (it's a clipped source). → Pinecone research namespace + vault pointer if the article matters to a specific MOC. Otherwise just the raw archive at 80 — Resources & Reference/Raw/ (per [[CLAUDE]] §2).

Anti-patterns (do NOT do these)

• ❌ Don't put curated active strategy (MOCs, decisions, personas, product anchors) in Pinecone. Vault IS RAM; the point is mutation + wiki-link graph.
• ❌ Don't put full meeting transcripts in vault. They bloat the wiki. Stub-in-vault + transcript-in-Pinecone is the pattern.
• ❌ Don't create both a vault note AND a Pinecone record where the vault note IS the canonical state — that creates 2 sources of truth that drift. Use the hybrid pattern only when content is large + immutable AND needs vault discoverability.
• ❌ Don't backfill existing vault content into Pinecone. Vault is RAM; backfill would duplicate, not enrich.
• ❌ Don't write API keys, secrets, or credentials to either layer.
• ❌ Don't put a as_of snapshot into the vault as if it were current. Tag it as_of and route to Pinecone.

Output format

When applying this skill, state the routing decision EXPLICITLY before executing — one line:

Routing decision: <vault path> [+ Pinecone <namespace> <id-prefix>]. Why: <one-sentence reason citing the rule or tiebreaker>.

Then execute (write the file / upsert the records).

Source of truth (read these for deeper context)

• [[Memory Architecture]] in the vault — the full design doc with namespace map, wrap-up trigger logic, Granola pipeline plan
• [[CLAUDE]] §5 — enforced two-layer memory rule (rules 1-4 also relevant: log, raw archive, lint, index regen)
• ~/.claude/skills/wrap-up/SKILL.md — companion skill for the conversations namespace flow

When NOT to use this skill

Skip the explicit routing decision for:

• Single-question Q&A with no artifact produced
• Trivial vault edits (typo fixes, frontmatter date bumps)
• Reading existing content (search/recall path, not write path)
• Pure conversation that hasn't produced anything to store