Definitions & scoring reference

The data model

Thunder Graph tracks four kinds of records. Understanding the difference explains why some searches and scores apply to one but not another.

Warmth score

Warmth is a 0–100 measure of how strong a relationship is, computed identically for every person and every firm from real interaction history (Gmail, Calendar, Fireflies meetings, HubSpot, WhatsApp, LinkedIn, Luma events). It is the sum of four components, each capturing a different dimension of a real relationship. graph/warmth.mjs · score-warmth.mjs

The four components (sum to 0–100)

1 · Recency (0–30) — how recently did you last interact?

A straight-line decay over three years. A contact touched today scores the full 30; one last touched exactly three years ago scores 0. This deliberately long horizon lets genuinely strong but dormant relationships still surface across the team.

e.g. last touch 6 months ago → 30 × (1 − 182/1095) = 25.0. One year ago → 20.0. Two years ago → 10.0.

2 · Frequency (0–30) — how often, recently?

Counts interactions in the last 6 months (180 days), worth 6 points each, capped at 30. So five or more touches in six months maxes this component.

3 · Depth (0–25) — was it substantive?

Not all contact is equal — a meeting means far more than a one-line email. Depth is a weighted sum of interaction quality over the last 12 months, capped at 25.

4 · Directionality (0–15) — did they reach out to you?

An inbound message (them → you) is a much stronger signal than outbound alone. Reciprocity earns the most.

Maximum 15. When warmth is derived from aggregate rollups (no per-message direction available), directionality is 0 — the score is conservative rather than guessed.

The labels

The 0–100 score maps to a label used everywhere in the UI:

Whose relationship? — the warmth owner

A contact's warmth is the maximum over every Thunder teammate of that teammate's own interaction history with the person. The teammate who produces the max is the warmth owner — the best intro path, shown as "best intro via …" on the record. So warmth answers two questions at once: how strong is this relationship and who on our team owns it.

Firm-level warmth

A firm is as warm as its warmest person — or a direct firm-level relationship edge, whichever is stronger.

Two details that keep it honest

• De-duplication. HubSpot auto-logs Gmail and Calendar, so one real email or meeting can appear 2–3 times across sources. Before scoring, same-type events within a short window (email/call ≤ 3 min, meeting ≤ 30 min) are merged, so Frequency and Depth reflect real interactions, not double-counts.
• Durable community bonuses. Some cohorts carry a manual boost that survives the nightly recompute, added on top of any interaction score: Post-Exit Founders (PEF) +20 · $100M Exits podcast guest +50. They stack — warmth_bonus is the sum of a contact's community tags, so a guest who is also a PEF member gets +70. A no-touch member floors at their bonus value; a touched member gets score + bonus, capped at 100.

Relevance & compatibility

When you run Find intros, every candidate firm gets a relevance score (0–100) measuring how well the firm's investment criteria fit the company — a faithful re-implementation of Thunder's production matching model over our mirrored data. graph/compatibility.mjs

Two lanes, two weight tables

A capital raise and a company sale are scored by different weight tables, because the signals that predict a good investor are not the signals that predict a good acquirer. The mandate's intent picks the lane automatically — you never choose it.

Why they differ (2026-08-03): funding stage is a VC-round concept driven by a dropdown that sell-side clients leave blank, so on a sale the dominant component scored a flat 0 for everyone. The sell-side lane replaces it with evidence a banker would actually ask for.

Raise lane — the eleven components (raw points)

Each criterion contributes raw points. Sector dominates; the rest refine. compatibility.mjs · W

Five of these can go negative: a thesis mismatch actively counts against a firm. Sector −40 (no thematic overlap at all), acquisition alignment −20 (disqualified type), data confidence −15 (a record with no web domain or no firm type — usually not a firm at all), product stage −3, geography −3 (they list geographies and none match), check size −2. A profitable, non-growing company also loses a further 6 product-stage points against a pure VC. Product stage can reach 18 — an advanced product paired with an early capital stage earns +3 ("further along than the round implies").

Sell-side lane — the fifteen components

The sell-side lane keeps every raise component (re-weighted) and adds five that only make sense when someone is buying the company. compatibility.mjs · W_MA

Sector is the gate

Sector is treated as the imperative signal, co-equal with funding stage. Any core (primary) sector overlap earns near-full credit; no thematic overlap at all is a −40 penalty (−34 on the sell-side lane, keeping the gate proportional to that lane's sector weight). Firms listing more than 12 sectors are treated as generalists and dampened — down to half credit — so a match has to be a specific theme, not a firm that "invests in everything." Secondary/adjacent sectors expand recall but count at 40% weight, never as a core match.

From raw points to a 0–100 score

The summed raw points are squashed through a logistic (sigmoid) curve — this compresses the extremes the way the production model does, so scores cluster meaningfully instead of spreading linearly. Each lane has its own midpoint, because the sell-side lane has a higher positive ceiling (~173 raw points vs ~147); reusing the raise midpoint saturated every decent buyer into the high 90s.

The raise midpoint moved 45 → 35 on 2026-08-13, alongside the funding-stage cut. It is not a free parameter: it re-centres the squash so that removing 18 points of stage weight does not shift every client-visible score downward. Measured across the 1,446 firms on the seven scored raise lists, the median relevance is unchanged at 71.

The sell-side midpoint of 85 was calibrated by sweep, not guessed: at 85 a demonstrated control buyer with capacity lands ~97, a minority-only fund on a full-exit mandate ~61, a sub-scale strategic ~50, a firm with zero recorded acquisitions ~38, a disqualified VC ~15. It is a function of the weight table — any weight change requires re-running the sweep. graph/compat-test.mjs

Firm-type weighting

The score is then multiplied by a firm-type weight (0–1) set by the deal's intent. A firm that is the wrong type for the deal ("off-type", weight 0) is floored at 0.05 — deep-demoted and sorted to the bottom, flagged, but never deleted (it may still be a useful sounding board). An unknown firm type is neutral: 0.5 on a raise, 0.2–0.3 elsewhere. recommend.mjs · FIRMTYPE_WEIGHTS

On a raise, the weight is not set by intent alone — it is set by the instrument the company selected at intake (venture equity, buyout equity, or debt). This is the real VC-vs-PE-vs-lender separator: a venture fund is not a weaker fit for a debt raise, it is no fit, so it scores 0 and is demoted out of the list rather than docked a few points.

The debt column was retuned on 2026-08-13 from the curation record: family offices 0.7 → 0.4 and commercial banks 1.0 → 0.8. On the two debt mandates in the data, family offices were a third of the list and the reviewer dismissed 66 of the 67 they looked at. A family office does occasionally write private debt, so this is a demotion below the credit funds that do it routinely — not a zero.

How results are ranked

The score is relevance and nothing else. Warmth and the owner path are computed for every firm and shown on each card, but they are never folded into the number.

This is a deliberate decision (2026-06-29): an earlier version blended in relationship warmth and the owner path, which buried genuinely relevant firms behind whoever we happened to know. Now the number answers one question — "is this firm a fit for the deal?" — and you sort or filter by warmth separately when you want to prioritize who's easiest to reach. graph/recommend.mjs

The list order is not just the score

Sorting purely by score put a well-documented generic buyer above a partner the client actually asked for, because the partner is privately held and loses on data richness. So the list applies four deterministic keys before the score — a rule, not another round of weight tuning (2026-08-04):

Keys 3 and 4 are the only place relationship data touches ordering, and only as a tie-break inside a tier — it never changes the score itself.

Fit tiers

Because a raw relevance score can look high on thin data, candidates are also sorted into fit tiers that require multi-dimensional confirmation — a tier is never a single threshold. This is what the 🎯 / tier-2 badges on target-list cards mean.

Tier 1 is criteria-driven, not score-threshold-driven: sparse firm tag data caps scores, so a hard relevance bar would make the top tier depend on data density instead of actual fit. The production match-score prior (which tends to make everything look 82–100) can never mint a slam dunk by itself. graph/recommend.mjs

Mandate verification

After matching, each top candidate is screened against the firm's own written thesis plus reality data (real ticket window, 36-month activity, true investor type from Inven) to answer: would this firm actually do this deal? Screening runs per lane, derived from the mandate's intent + financing type + structure. graph/verify-mandate.mjs

Hard reality checks run first with no LLM (e.g. a firm whose minimum ticket is $193M is excluded from a $60M deal instantly, for free). What survives goes to a Sonnet screen. Each firm gets a verdict:

✓ covers the firm's thesis + reality credibly cover this mandate   ✗ excludes a concrete reason it won't (auto-demoted to Other)   ? unclear not enough signal to decide

Verdicts cache for 60 days (invalidated when fresher reality data lands), keyed by firm + lane + deal-size bucket, so the same firm isn't re-screened across deals of the same shape.

Origination score

The Origination engine surfaces companies that look like they're about to need a banker. Each prospect's score is an additive sum of independent signals — the higher the score, the more reasons to reach out now. graph/originate.mjs

Every prospect card lists exactly which signals fired and why, so the score is always explainable — never just a number.

Learned ranker

The matcher improves over time by learning from real outcomes. Every recommendation stores the exact per-component scores that produced it (the "why-breakdown"), so when a firm later progresses down the funnel — or passes — we can measure which components actually separate winners from losers. graph/learn.mjs

Outcomes are weighted by depth

A closed deal tells us far more about a good match than a bare reply; an informed pass tells us more than silence. Each outcome is weighted by how far it got:

A dismissal during curation is the weakest negative in the set — the market never saw the firm, so it reflects our judgment rather than theirs.

For each compatibility sub-weight it computes a magnitude-weighted lift — how much higher that component scores among firms that progressed versus firms that passed — and writes a proposal to nudge the weight. Nothing is applied automatically. A human reviews each proposal on the Portfolio tab and clicks Adopt or Reject; adopting applies a bounded step (at most ±20% per adoption). The 100%-relevance ranking decision is never touched — only the compatibility sub-weights inside relevance.

Personas & the AI prompts behind them

Every contact can carry one or more personas — their professional role(s). A person can be several (a post-exit founder who now angel-invests is Founder + Angel). The canonical taxonomy:

Founder Operator Angel VC LP PE/Buyout Corporate/Strategic Advisor Banker Recruiter Service Provider Board Member

Personas are set in priority order: a human edit always wins; then a HubSpot self-selection ("What best describes you"); then AI inference. Provenance and a confidence value are stored on every contact so you can see where a label came from. graph/enrich.mjs

Prompt A — normalize a HubSpot self-selection confidence 0.95

When a contact answered HubSpot's "What best describes you", the AI just maps their words to our taxonomy.

You are a data normalizer. Map HubSpot "What best describes you"
selections to this canonical taxonomy:
Founder, Operator, Angel, VC, LP, PE/Buyout, Corporate/Strategic,
Advisor, Banker, Recruiter, Service Provider, Board Member.

Input may be: comma-separated, pipe-separated, JSON array, or free
text. Output ONLY a JSON array of canonical labels (exact
case-sensitive match). If empty or unmappable, return [].

Prompt B — post-exit founder (PEF community) confidence 0.80

PEF members come with a rich roster profile (exit company/title/year, current status, industry). Because they founded and exited a company by definition, "Founder" always applies; the AI adds today's roles from their current-status text.

You classify a post-exit founder's professional personas from their
community-roster profile. This person is a member of the "Post-Exit
Founders" (PEF) community — they founded and exited (sold or took
public) a company, so "Founder" ALWAYS applies. Add any ADDITIONAL
personas their CURRENT activity clearly supports.
Canonical taxonomy (use exact labels): Founder, Operator, Angel, VC,
LP, PE/Buyout, Corporate/Strategic, Advisor, Banker, Recruiter,
Service Provider, Board Member.
Mapping guidance for the "current status" text:
- "VC", "investor", "fund", "general partner" => VC ; "angel",
  "angel investing" => Angel ; "LP", "limited partner" => LP.
- "advisor", "consultant", "consulting", "coaching", "fractional"
  => Advisor ; "board", "board member", "director" => Board Member.
- "operator", "CxO at", "operating", "running/building a company",
  "founded a new company" => Operator (and Founder already applies).
- "PE", "private equity", "buyout", "search fund", "acquisition
  entrepreneur" => PE/Buyout.
Only add a persona the text actually supports. Return ONLY a JSON
array of 1-4 canonical labels, ALWAYS including "Founder".

Exited: Parallel Markets Inc as CEO (2025)
Current status: Founded a New Company, VC / Investor
Industry: B2B SaaS, Fintech
Functional expertise: Product, GTM
Current title: (none)

→ result: Founder Operator VC. "Founder" is guaranteed even if the model omits it.

Prompt C — infer from minimal signals confidence 0.60

For everyone else, the AI infers conservatively from title + email domain + firm — and returns nothing rather than guess when signals are too weak.

You are a data analyst inferring professional roles from minimal
signals. Be conservative; only include personas you are reasonably
confident about.

Infer role personas for this person.
Title: {title}
Email domain: {domain}
Firm: {firm}

Choose from: Founder, Operator, Angel, VC, LP, PE/Buyout,
Corporate/Strategic, Advisor, Banker, Recruiter, Service Provider,
Board Member.
Return a JSON array of 1-3 likely personas. If signals are too weak,
return [].

Focus tags

Some investment strategies aren't in the sector tree (a "search fund" isn't a sector). Focus tags capture those thesis concepts. An AI reads each firm's own written thesis and assigns tags from a fixed vocabulary — only what the firm itself focuses on backing, not words that merely appear in the text. These power niche searches like "firms that back search funds". graph/enrich.mjs · search.mjs

You tag investment firms with strategy/focus tags from this EXACT
vocabulary (never invent tags): search_funds,
entrepreneurship_through_acquisition, micro_pe, rollups,
buyouts_smb, b2b_saas, vertical_saas, marketplaces, deep_tech,
climate, defense, ai_native, cybersecurity, … (40+ tags).
Read each firm's own thesis text. Tag only what the FIRM ITSELF
focuses on investing in — e.g. tag search_funds only if they BACK
search funds / searchers, not if the text merely mentions the words.
0-6 tags per firm; [] when nothing clearly applies.

Where AI is used — and where it isn't

AI is used for language and classification tasks; all scoring math above is deterministic code, not an LLM. Models run on AWS Bedrock, tiered by task for cost and quality.

The golden rule holds everywhere AI touches outbound: the machine drafts, a human clicks send. No email, stage change on a judgment call, or weight adjustment is ever applied without explicit human approval. Every AI-written value is stored with its source label ("ai" vs "human" vs "hubspot") and a confidence, and a human edit always wins and is never overwritten.

Funnel stages

Once a firm is contacted for a live mandate, it moves through the investor process ladder. Every stage change writes an activity-log row — that's the compliance audit trail.

A passed outcome records a reason from a fixed taxonomy (too early/late, sector fit, geo fit, check size, valuation, portfolio conflict, no capacity, process timing, no response) — which feeds the learned ranker and the conversion analytics.

Glossary

GTM events

Go-To-Market → Events productizes Thunder's private-event motion — dinners (the founding case), breakfasts, roundtables, receptions (dinners.event_type; the invitation copy follows the type). Each event is a host engagement (engagements.intent = host_dinner, excluded from every deal list) plus a dinners row carrying date, city, metro (the hard location gate — a London dinner only considers London people), venue, theme, the ideal-attendee description, an optional Luma link, and priority clients (linked client engagements whose matched investors get a boost on the invite list).

Invite-list score (0–100), four components — computed by graph/dinner-recommend.mjs, breakdown stored per row in recommendations.score_breakdown. The only LLM call in the pipeline parses the ideal-attendee text into targeting (prompt dinner-targeting-parse); the ranking itself is deterministic. Location is a hard gate, not a score: a candidate must match the dinner's metro (contact-level first; firm-HQ fallback is flagged on the row).

The dinner funnel (v.65). Committing the shortlist creates one funnel row per guest (investor_process, source dinner, no mandate) and the 4-touch plan dinner_invite: email 1 → email 2 (+4 business days) → LinkedIn invite-or-DM by connection state (+3bd) → final email (+5bd), every draft approval-gated and sent by the same windowed scheduler as deal campaigns. The dinner stage ladder ends rsvp_yes | declined → attended; those stages sit outside the scheduler's arming gate, so an RSVP/decline/check-in automatically freezes the guest's remaining touches. RSVP state flows from the Luma guest CSV (luma_attendees) nightly, on every fresh import, and on demand; guests registering under an unknown email are linked by a human on the RSVPs tab. The capacity projection (guests × touches vs mailboxes ~40/day, a 0.5 share of the LinkedIn budgets, +12 business-day cadence span) is recomputed live and warns when the projected last touch lands within 3 days of the dinner.