The Forensic Registry
🏛️ The Forensic Registry System
Status: ACTIVE (Jan 2026) Role: The “Librarian” Pattern
1. The Scaling Problem
We have 50+ projects containing heavy forensic data (PDFs, Emails, CAD).
- Previous Model (Flat): Attempting to load all raw data into one context window. Result: Token overflow, amnesia.
- New Model (Hierarchical): The “Librarian” Pattern. The AI knows where the book is, but doesn’t memorize every page.
2. The 3-Tier Architecture
Tier 1: The Detail Pods (Restricted)
- What: Individual NotebookLM notebooks for each project (e.g., “C24 Pod”).
- Content: Raw emails, PDDs, specific dimensions.
- Access: Air Gapped. The Master Gem cannot see inside. Only the User can open them via URL.
Tier 2: The Registry (PROJECT_INDEX.md)
- What: A single Index File injected into the Master Gem.
- Content:
- Project Title & Role.
- Forensic Summary: A high-density “Bolus” (100 words max) capturing the core “Win” (e.g., “Vertical Hanging Fixture”).
- Notebook URL: The link to the Tier 1 Pod.
- Function: This is the “Card Catalog.” It allows the Gem to say: “I know about C24. It involved a thermal crisis. For details, go to Shelf 3 (URL).”
Tier 3: The Portfolio Gem (The Interface)
- What: The conversational agent (“Forensic Portfolio Architect”).
- Instruction: “You are the Librarian. Consult the Registry. Summarize the Bolus. If detail is needed, point to the URL.”
3. Operations
Adding a New Project
- Create Notebook: Feed it the raw data.
- Generate Bolus: Ask the Notebook for a “Forensic Summary.”
- Update MDX: Add
notebook_urlandforensic_summaryto the project’s MDX file. - Compile Registry: Run
python scripts/compile_registry.py. - Refresh Gem: Upload the new
PROJECT_INDEX.mdto the Master Gem.
4. The “Air Gap” Law
We deliberately DO NOT use generic “Link Reader” plugins to read the notebooks. The separation ensures that sensitive commercial data (Vendor Pricing, Emails) remains behind the user’s Google Login auth wall (Restricted Access) and is never ingested into a public model context.