SLW · Future AI · 1 of 8

How information moves through the system

Four layers, read bottom-up: tools ingest raw material, the registry connects and enriches it into one interlinked graph, each app formats it for its audience — and on top, you just ask.

Layer 4 · Ask
Future AI — "Ask"
One question box over everything below.
Ask anything across every record, doc, and link…
Which LPs care about AI infra? Who do we know at this company? What themes are heating up?
Answers, drawn from every layer›››
Layer 3 · Output
Visualization
One surface per app — and one record can have several cards: a company’s new Terminal profile need not match its existing VC card.

LP Flow LP / investor pipeline

Entity cards
Card 1
Card 2
Person cards
Card 1
Card 2
Two cards per record type — two views of the same record

DealFlow Company pipeline

Company cards
Card 1
Card 2
Person cards
Card 1
Card 2
Two cards per record type — two views of the same record

Terminal Research surface

IPO card
Company card

Quill Writing surface

Firm Brief
Topics
+ New Next surface plugs in here
Format + Output›››
Layer 2 · Registry
Data
One shared registry every app reads from and writes to.
Entities
CompanyPeopleVCLPOther
Classification
SectorsTopicsThemes
Connect + Enrich — incoming material is matched to existing entities, deduped, and enriched before any app sees it.
Ingestion · Extraction · Metadata · Content›››
Layer 1 · Capture
Tools
Where raw material enters the system.

Terminal Tools

Research sessions surface companies, people, and intel.

Podcast Tools

Episodes and transcripts mined for topics, themes, mentions.

Ford Tools

The engine — classifies and routes everything sent to it.

Email Tools

Inbound mail mined for entities, intel, and context.

Source: whiteboard sketch + markups, 2026-08-04 Terminal appears twice by design — it both captures (layer 1) and visualizes (layer 3).
SLW · Future AI · 2 of 8

The data layer, up close

Everything else stripped away. One layer, one job: every piece of material that arrives makes some entity — or some theme — richer than it was.

Layer 2 · Registry
Data
Its job is simple to say: add context. Every piece of material that comes in makes some entity — or some theme — richer than it was.

EntitiesBuild accumulating profiles — People · Companies · VCs · LPs · Other

  • every place it was mentioned, and when
  • what was discussed there
  • investments, rounds, portfolio membership
  • person ↔ firm ↔ company associations
  • groups and segments it belongs to
  • which apps hold it (LP Flow, DealFlow…) — embedded detail, not the headline
What to build
  • Cover every entity type — extend the registry beyond people & firms to VCs, LPs, companies, with typed relationships (investor-in, partner-at, led-round)
  • Recognize entities inside documents — today matching runs on app records; docs don’t yet name who they mention
  • The enrichment writer — when a doc mentions a known entity, append the mention, discussion, and relationships to its profile; unsure ones go to a confirm queue
  • Profile timeline — each entity shows what was added, from where, when

ClassificationBuild accumulating threads — Sectors · Topics · Themes

  • one controlled vocabulary — shared everywhere, not per-app labels
  • auto-tagged at ingest — content suggests, you confirm (same pattern as record matching)
  • hierarchy: sectors are stable · topics evolve · themes are curated theses
  • every mention attaches to its thread — a theme becomes a running story
  • momentum: mentions over time show what’s heating up
  • applies to entities and documents alike — the cross-links
What to build — three problems, not one
  • SimpleThemes — your curated theses, a hand-picked list; the system only attaches mentions, never invents them. Ship first.
  • SimpleTopics — flat open tags, multi-label, auto-suggested; wrong tags are cheap, clean up with merge / rename later.
  • SimpleSectors v1 — just collect — record the sector language as it appears in the incoming material — reports, memos, transcripts — attached to each mention. No tree, no cleanup, no ontology debates.
  • LaterSectors v2 — build from usage — once enough mentions have accumulated, build the real taxonomy from what the recorded information actually says — not from a guess up front.
  • Principle — hierarchy is a view, not storage: store flat tags with an optional parent, render trees later.
Worked example

A doc arrives saying Redpoint led a round in a company. The company doesn’t exist yet → a record is created, with the mention and what was discussed. Redpoint’s record gains the investment — its portfolio grows. And when a Redpoint partner is named alongside a company we track, that association lands on the partner, the firm, and the company at once.

1 · ArriveMaterial comes ina doc, an email, a transcript, a research session
Build2 · RecognizeEntities spottedthe people, companies, VCs, LPs it mentions
Build3 · Create or enrichNew → created · Known → enrichednothing is ever filed twice
4 · AttachContext recordedwhere mentioned · what was discussed · relationships · group / segment
SLW · Future AI · 3 of 8

Layer 2 — what needs to be done

The data layer, execution view — read bottom-up. The real work is at the base: AI extracting each document properly. Extraction feeds the tags and entity matches, and those feed the writing. All three stages are new builds — each reuses a live piece, but none of them exists yet. Nothing above can be better than the extraction underneath it.

Stage 3

WritingBuild

records get richer

✓ reuses the live confirm queue
  • Create-or-enrich writer — unknown → new record; known → append the mention, discussion, and typed relationships (investor-in · partner-at · led-round)
  • Threads update — the same write lands on themes and topics, so a theme stays a running story
  • Uncertain → confirm queue — the suggest/confirm pattern that already works; nothing auto-merges
feeds the writing
Stage 2

Match & tagBuild

connect what was extracted

✓ reuses live record linking
  • Entity matching — extracted mentions resolved against existing records; new ones suggested
  • Tags attach — sector language kept verbatim, flat topics multi-label, themes from your curated list
  • Stamp the doc — every document carries the entity IDs and tags it mentions; two silos become one graph
feeds the matching
Stage 1
The real work

ExtractionBuild

AI reads every doc properly

✓ reuses the doc ingest plumbing
  • Pull the right things from each doc, email, transcript — who is mentioned, what happened (rounds, investments, associations), what it’s about (sector language, topics), and where it was said
  • Provenance on everything — each extracted fact points back to its page or passage, so every enrichment upstream is checkable
  • Quality is proven, not assumed — an eval set of real docs gates it, per document type; this is where the AI effort and iteration actually go
Measure of done: a new doc arrives and, with no extra work, the right records get richer — and you can click any fact back to the passage it came from.
SLW · Future AI · 4 of 8

What it takes — audited against the actual system

A code audit of all seven repos changed the estimate. Most of the extraction already exists — newsletters, deals, facts, podcast entities, even the email door. What’s genuinely missing is the shared spine: one place where mentions, relationships, and typed tags land, and the wiring that points the existing machinery at it. Only step 1 is strictly sequential — once the spine exists, 2 and 3 run in parallel, and 4 lands last. Mostly integration, not new AI.

Audit: already built & running — newsletter → structured deal/fact extraction with verbatim source passages (Terminal) · the ford@ email door, live on cron, classifying 13 doc types with sector/company scope at capture · podcast entity + topic extraction · company→CRM matching with an AI tiebreaker · doc→record extraction with page provenance and a review flow (LP Flow Intel Workbench) · locked company + firm cards · staged-import writers · two live confirm queues.
1 · First — everything depends on it

The shared spine

  • Mention store — “doc X mentions entity Y” exists nowhere today
  • Typed tag store (sector / topic / theme) — every app has flat per-app tags only
  • Registry learns to create entities and hold relationships (investor-in · partner-at) — today it links, never creates
then, in parallel
2 · In parallel

Point the extractors at it

  • Terminal’s newsletter + literature extraction writes mentions/tags to the spine
  • Podcast entities join the shared registry (today a private table)
  • Add the one truly missing extractor: people from docs
3 · In parallel

Close the routing + writing

  • Ford adapters for the 4 held destinations — mail classifies correctly today, then just sits
  • Create-or-enrich writer through the existing staged-import + confirm-queue rails
last
4 · Last — needs 2 and 3 flowing

Cards read the spine

  • Existing locked company/firm cards show enriched mentions + tags
  • Card 1 / Card 2 badge wiring in DealFlow and LP Flow
Also on the list, from the audit
  • Extraction-accuracy evals — nothing gates extraction quality today, only retrieval
  • Body-only capture — a pasted note or plain forwarded email has nowhere to land
  • Join the newsletter inbox to the ford@ door — two separate doors today
  • Wire up DealFlow’s importer — built, never connected
  • Registry badges into working checkouts — merged on main, stale locally
Deliberately later
  • Sector taxonomy v2 — built from what collection mode records
  • Card-system registry — doc type → template mapping; bespoke pages are fine for now
  • Ask — thin layer once the graph is filled
Process, every phase Brief Build in a workstream Eval gate Ship behind a flag You review the queue Flip the flag
Biggest audited risk: three matchers (Terminal, LP Flow, DealFlow) each match against their own app and never against the registry — the spine must become the one they all use.
SLW · Future AI · 5 of 8

Two views can coexist — one record underneath

For a while we will deliberately have more than one visualization of the same thing. The existing DealFlow company view keeps working; a new Terminal view — say, initiated by a new venture deal appearing — lives beside it. Both sit above the data layer, both carry the same details and classification, and DealFlow simply shows a badge that a second view exists. Same pattern for people.

DealFlow company viewthe one that exists today Card 1
AI infraRoboticsTheme: Automation
Terminal viewinitiated by a new deal appearing Card 2New
AI infraRoboticsTheme: Automation
+ Future improved view

Built whenever it earns its place — plugs in above the record without touching it. Old views retire when the new one wins.

One record: Acme Robotics
Every view reads the same mentions, relationships, details, and tags — views are disposable, the record is permanent.
AI infraRoboticsTheme: Automation
Same pattern for people: an LP contact card and a founder profile can coexist over one person record. The Card 1 / Card 2 labels are how DealFlow signals a second card exists without changing anything else.
SLW · Future AI · 6 of 8

The same pattern for a person

The LP Flow contact view keeps working. When a deal names the same person — a partner leading a round, a founder we start tracking — a Terminal view appears beside it. Both sit above the data layer, both carry the same details and classification, and LP Flow shows the badge that a second view exists.

LP Flow contact viewthe one that exists today Card 1
VCRedpointTheme: Automation
Terminal viewinitiated by a deal naming them Card 2New
VCRedpointTheme: Automation
+ Future improved view

A better person profile plugs in above the record whenever it earns its place — the record never changes.

One record: Jordan Lee — Partner, Redpoint
Every view reads the same mentions, associations (partner-at · led-round · board seat), and tags. The person is one entity everywhere — LP contact in one book, deal-maker in another.
VCRedpointTheme: Automation
Jordan Lee is a placeholder name — swap in a real example when presenting. The Card 1 / Card 2 labels work in both books — whichever app you’re in tells you the other card exists.
SLW · Future AI · 7 of 8

AI enrichment areas

The material the extraction pipeline works on. Every area flows through the same Stage 1 extraction — one pipeline, evaluated per document type — and lands on the same records, threads, and tags.

1

Newsletters, research documents, LP content

market newsletters · research reports · LP letters and updates
2

Search + scrape

targeted web search and site scrapes to fill what the docs don’t say
3

People — bios and emails

On demand
bios · role and title detail · email addresses
4

Other

the next enrichment area plugs in here
Every area flows through the same Stage 1 extraction — one pipeline, its own eval per area.
SLW · Future AI · 8 of 8

New hooks — when something happens, the system acts

Most of the pieces below already exist as capabilities. The hook is what’s new: an automatic trigger, a filter, and no button to press.

Trigger New funding deal in Terminal filter: early-stage only · skip companies over $10bn
Have we talked to them? + sales stage Company brief generation Make it automatic — trigger + filter, no button
Trigger New IPO low frequency — a handful a month
IPO added to the record Pull the S-1 + brief it Decide the source: auto-pull from EDGAR, or — given the low frequency — you upload the PDF and the system notifies + briefs. Recommendation: start with upload-with-notification; add EDGAR later if volume justifies it.
Trigger BDC filings quarterly cadence
How to automate — open Suggestion: pull each BDC’s 10-Q/10-K on filing, extract the schedule of investments (holdings, marks, yields), and diff against last quarter — new names, markdowns, and overlaps with our book surface automatically.
Trigger Comps whenever a brief is created
How to build — open Suggestion: when a company brief is created, auto-assemble its comp set from sector-tagged peers — private names from our records plus public tickers — and keep it attached to the company card, refreshed as tags accumulate.
Already built To build Open question — every hook writes through the same data layer, so each brief enriches records and tags as a side effect.
SLW · Future AI

Appendix

SLW · Future AI · Appendix

How it works today — what’s already running

Same four layers as the map. The middle layer is one thing — the data layer — and most of it is already in production. It gets the room here.

Layer 4 · Ask
Ask
Seed liveQuill’s Ask already answers questions — but it only sees documents, inside one app.
GapLayer 4 is the same box widened: entities + tags + documents, from anywhere.
Layer 3 · Output
Visualization
LiveApps already consume the data layer behind flags: Quill’s search reads it in production; LP Flow and DealFlow show cross-book badges.
NextTerminal is the next consumer — the cards on slide 1 are this same pattern, one card per record type.
Layer 2 · Registry
Data
Its job is simple to say: add context. Every piece of material that comes in makes some entity — or some theme — richer than it was.

Entities accumulating profiles — People · Companies · VCs · LPs · Other

  • every place it was mentioned, and when
  • what was discussed there
  • investments, rounds, portfolio membership
  • person ↔ firm ↔ company associations
  • groups and segments it belongs to
  • which apps hold it (LP Flow, DealFlow…) — embedded detail, not the headline

Classification accumulating threads — Sectors · Topics · Themes

  • one controlled vocabulary — shared everywhere, not per-app labels
  • auto-tagged at ingest — content suggests, you confirm (same pattern as record matching)
  • hierarchy: sectors are stable · topics evolve · themes are curated theses
  • every mention attaches to its thread — a theme becomes a running story
  • momentum: mentions over time show what’s heating up
  • applies to entities and documents alike — the cross-links
Worked example

A doc arrives saying Redpoint led a round in a company. The company doesn’t exist yet → a record is created, with the mention and what was discussed. Redpoint’s record gains the investment — its portfolio grows. And when a Redpoint partner is named alongside a company we track, that association lands on the partner, the firm, and the company at once.

1 · ArriveMaterial comes ina doc, an email, a transcript, a research session
Build2 · RecognizeEntities spottedthe people, companies, VCs, LPs it mentions
Build3 · Create or enrichNew → created · Known → enrichednothing is ever filed twice
4 · AttachContext recordedwhere mentioned · what was discussed · relationships · group / segment
LiveRecognition and storage exist today (record linking, document extraction). The buildThe automatic create-or-enrich loop — today a doc becomes searchable, but doesn’t yet update the entities it mentions.
Layer 1 · Capture
Tools
DecidedFord is the one door — ford@rivent.dev — it classifies and routes everything sent to it. The Email box on slide 1 is Ford’s front door.
PartialTerminal and Podcast capture today, but into their own apps — routing through the shared layer is the change.

What it might mean

  1. The data layer is an enrichment engine, not a filing cabinet — its measure is: did this doc make some entity richer? Today the answer is “searchable, yes; richer, no.” Closing that is the core build.
  2. The pieces already run — record linking and one-time document extraction are live; the loop connects them.
  3. Tags ride the same loop — sectors / topics / themes get attached at the same moment mentions do, not as a separate project.
  4. Ask falls out at the end — once every mention, relationship, and tag lands on the right entity, “who do we know at Redpoint?” is just reading the record.
Plumbing footnote: records = Webster · documents = Dewey · engine = Ford. Internal names only — nothing user-facing ever says them.
1 / 2