Product Requirements Document

One Agentic — Thesis Capture (Stage 01)

Fund-level investment thesis configuration. Defines the criteria against which every deal is evaluated — replacing generic rubrics with a specific, fund-owned mandate that evolves over time.

Status
Draft
Date
June 2026
Owner
Product · Engineering
Pipeline stage
01
Downstream
Stage 02 — VC Deep Research Agent

Problem & Goal

North star: Every deal evaluation produces a verdict specific to this fund's thesis — never "this is a good startup," always "this is or isn't a fit for how we invest, and here is why."

Without a configured thesis, the Research Agent defaults to a generic early-stage rubric that is meaningless in practice. A deep tech fund and a consumer fund would score the same company identically — which makes the score useless to both. Thesis Capture gives each fund a structured, owned definition of what they invest in, which flows into every downstream evaluation automatically.

What we're solving

  • Generic rubrics produce scores that don't reflect how a specific fund actually invests
  • Thesis lives in partners' heads — inconsistent across the team and lost when people leave
  • Claim Validation has no baseline without a thesis — it can't know what "traction" means for this fund
  • New analysts can't calibrate to fund mandate without a structured reference

Who uses this

  • GP / Managing Partner — configures and owns the fund-level thesis
  • VC Analyst — inherits the thesis; optionally narrows it per run
  • Research Agent (Stage 02) — consumes the thesis to score fit and generate thesis-driven claims

User Stories

1
As a GP, I configure the fund's thesis once using pre-defined primitives and optional free-text criteria, so that every downstream evaluation reflects our specific mandate without me being involved in each run.
2
As a GP, I update the thesis as our conviction evolves, and historical evaluations remain attached to the thesis version that was active at run time — so the audit trail is never corrupted.
3
As an analyst, I inherit the fund's thesis automatically and can add per-run primitives to narrow it for a specific deal (e.g. "must have MENA traction") without modifying the fund baseline.
4
As an analyst, when no fund thesis is configured, I am prompted to confirm a default primitive set or define a temporary thesis before research begins — I am never silently evaluated against an invisible rubric.
5
As a GP or analyst, I can review which thesis version was active for any past evaluation, so I can understand why a company scored the way it did even if the thesis has since changed.

F1 — Thesis Primitives

Required

The thesis is built from a library of pre-defined primitives organised by category. The GP selects the primitives that match the fund's mandate. Each selected primitive becomes a thesis-driven claim that the Research Agent validates against every company evaluated.

Stage
Pre-seed Seed Series A Series B+
Sector
Fintech Deep Tech SaaS Consumer Healthcare Climate Marketplace
Geography
MENA EU US Emerging Markets Global
Business Model
B2B B2C SaaS Recurring Marketplace Hardware + Software
Traction Signals
Revenue required Pilot customers Active users Pre-revenue OK
Team Signals
Technical founder Repeat founder Domain expert Solo founder OK
Deal Parameters
Lead investor Follow-on OK Pro-rata rights
Free-text (custom)
+ Add criterion
Free-text primitives: When a fund's mandate cannot be expressed through the pre-defined library, the GP can add free-text criteria (e.g. "founder must have previously worked in financial services"). The system stores these verbatim and surfaces them as thesis-driven claims for the Research Agent to validate. The format and validation mechanism for free-text primitives is an open question — see Q3.

Acceptance criteria

  • The GP can select any combination of primitives across all categories
  • At least one primitive must be selected before a thesis can be saved
  • Free-text criteria are stored verbatim and surfaced in the Research Agent as thesis-driven claims
  • The full primitive library is visible to analysts in read-only mode even when they cannot modify the fund thesis
  • Pre-defined primitive library can be extended by the product team without a code deploy

F2 — Fund Thesis vs. Analyst Override

Required

Two thesis scopes exist: the fund-level thesis owned by the GP, and a per-run analyst override that narrows it for a specific deal. The two scopes are strictly isolated — analyst overrides never modify the fund baseline.

ScopeWho can editPersistsEffect on research
Fund thesis GP Permanently — versioned Applies to all runs by all analysts unless overridden
Analyst override Analyst Per run only Adds primitives on top of fund thesis; cannot remove fund primitives
Constraint: Analysts can add primitives to narrow the thesis for a specific run but cannot remove or override primitives set by the GP. If the fund thesis says "B2B only," an analyst cannot run an evaluation without that constraint in scope.

Acceptance criteria

  • Analyst override primitives are visible in the report header, clearly distinguished from fund-level primitives
  • Analyst overrides are discarded after the run — they do not persist to the next run
  • Fund thesis changes require GP credentials — analyst role cannot access the fund thesis editor
  • When no fund thesis is configured, the analyst is prompted to confirm a default primitive set before the run begins; the system does not silently apply a rubric

F3 — Thesis Versioning

Required

The thesis is a living configuration. Funds evolve their mandate — sectors added, geographies narrowed, stage focus shifted. Each change must be traceable without corrupting the audit trail of past evaluations.

What is versioned

  • Full primitive selection at time of save
  • All free-text criteria
  • Timestamp and GP who saved
  • Version label (auto-incremented; GP can add a note)

What is NOT versioned

  • Analyst per-run overrides — these are ephemeral
  • UI display preferences
  • Research Agent configuration (separate system)

Acceptance criteria

  • Every saved thesis change creates a new immutable version — existing versions cannot be edited
  • Each Research Agent run records the thesis version ID it used — this is stored with the report permanently
  • The GP can view the full version history and see the diff between any two versions
  • Past reports always display the thesis that was active when they were generated, even if the thesis has since changed

F4 — Thesis Output Schema

Required

The thesis is consumed by the Research Agent as a structured FundThesis object. This schema is the contract between Stage 01 and Stage 02 — changes to it require coordination across both PRDs.

FieldTypePurpose
thesisVersionIdstringImmutable ID of the version used for this evaluation
stagesstring[]Accepted investment stages (e.g. ["Pre-seed", "Seed"])
sectorsstring[]Target sectors from the pre-defined library
geographiesstring[]Geographic focus from the pre-defined library
businessModelsstring[]Accepted business model types
requiredSignalsstring[]Traction and team primitives marked as required
dealParamsobjectLead/follow preference, pro-rata expectation
freeTextCriteriastring[]Verbatim free-text primitives added by the GP
analystOverridesstring[]Per-run additions by the analyst (ephemeral)

Acceptance criteria

  • The Research Agent receives the full FundThesis object at run start — it never queries the thesis system mid-run
  • If the thesis system is unavailable at run start, the run does not begin — no silent fallback to a generic rubric for a fund that has already configured a thesis
  • Schema changes are versioned and backward-compatible; old reports remain readable

Success Metrics

<15 min
First thesis configuration for a new GP
0%
Runs evaluated against generic rubric once a thesis is saved
100%
Analyst overrides isolated from fund baseline
100%
Past reports referencing their original thesis version
>80%
GPs able to complete thesis config without support
0
Analyst overrides that modified the fund baseline

Constraints & Non-Goals

Known constraints

  • Free-text criteria are stored verbatim — the system does not parse or normalise them for v1. Translation into validatable claims is handled by the Research Agent's Claim Validation agent.
  • The primitive library is product-defined at launch. Funds cannot add new primitive categories — only new values within existing categories via free-text.
  • Thesis configuration does not determine which data sources the Research Agent queries. Source selection is fully product-controlled.

Non-goals (this PRD)

  • Conversational thesis creation via NEO — separate interaction layer
  • Workflow Design (how the fund structures its diligence steps) — separate system
  • Multi-fund or multi-thesis per account — out of scope for v1
  • Thesis-to-source mapping (thesis influencing which sources are queried)
  • Sharing thesis across funds or with portfolio companies

Open Questions

5 unresolved
Q1
Thesis model — inheritance and scope. Should analysts define their own thesis per run, inherit the fund's saved thesis and narrow it down, or both? Who controls the fund-level thesis — the GP only, or any team member? Not yet decided.
Q2
Thesis configuration interface. Should thesis setup happen through a structured form (select primitives from a UI), conversationally through NEO ("we invest in B2B SaaS at Seed in MENA"), or both with the form as a fallback? The foundation document specifies NEO as the primary interface, but a form may be necessary as a fallback and for reviewing the current state.
Q3
Default primitive set. When no thesis is configured and the analyst is prompted to confirm a default before a run, what should that default primitive set contain? Should it be the most common early-stage VC profile (Seed · B2B SaaS · Global), or should the system require an explicit selection with no default at all?
Q4
Free-text guardrails. Should free-text criteria have any constraints at input time — e.g. a character limit, a required subject-predicate structure, or a confirmation step before saving? Without guardrails, a GP could enter criteria too vague to validate ("must be a good team") or too specific to ever match public data ("founder must have appeared on Forbes 30 Under 30"). Should the system warn, block, or silently accept?
Q5
Team access model. Can junior analysts view the fund thesis in full (read-only), or is it visible only to GPs and senior analysts? If analysts can see the thesis, can they also see the version history and change log?