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)

Corrected 11 Aug 2026: the JoVE vault is `~/dev/jove-hq/`, never `~/Obsidian/JoVE/`. The old Johnny.Decimal vault was migrated into jove-hq and no longer exists on this machine; every routing below that named a NN — folder silently pointed at nothing. Layout authority is ~/dev/jove-hq/CLAUDE.md rule 12. Place per content type:

Every vault note needs: YAML frontmatter per jove-hq convention (CLAUDE.md rule 5): type, status, links-in-frontmatter for entities, type and status tags only, no topic-tag sprawl. The old domain/confidence schema belonged to the migrated vault; do not reintroduce it.

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:

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 to follow (the named notes below lived in the migrated vault; the pattern is what to copy, and current live examples of it are the corpus-digest pointer notes under knowledge/jove-labs/corpus-digests/):

• 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: coupled note in knowledge/meetings/2026-MM/2026-MM-DD-ceo-1on1.md (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: knowledge/jove-labs/DECISION-MEMO-<topic>-<date>.md for Labs, knowledge/memory/ for cross-project calls. No manual Pinecone; the mirror ingests it.

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 live topic. Otherwise source-docs/ (raw reference, kept out of git pushes per jove-hq CLAUDE.md rule 8).

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)

• ~/dev/jove-hq/ARCHITECTURE.md § Memory tiering — the live namespace map and routing design
• ~/dev/jove-hq/CLAUDE.md rule 4 — the enforced two-layer rule: vault mutable, Pinecone = auto-mirror (vault namespace) plus immutable haystack
• ~/.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