Draper's edge lives in two partners' judgment, and it was being spent reading inbound decks. I designed an engine that scores a startup before anyone takes the meeting and returns an expected multiple with a call: Pass, Flag or Strong Flag. The harder design question was what to leave out.
The engine triages and surfaces. It does not pick investments, and it doesn't claim to: the partners make every call. Accuracy figures from the cross-validation runs aren't published here.
Draper Associates has backed more than 60 unicorns in 40 years, mostly on conviction about founders other investors passed on. Inbound deals were screened entirely by people. Strong decks competed with weak ones for the same partner attention, with no consistent first pass.
The second problem was slower. Why Draper backs a founder lived in two people's heads. Nobody could audit it, scale it across a growing team or hand it to the next generation of investors.
Both problems needed the same thing: a written rubric for the firm's judgment. I built one with five pillars and 38 sub-factors, and it was too big to train. Against about 440 companies with only a few dozen big winners, 38 features meant roughly one success case per feature, and a model that memorises noise.
So the rubric exists twice. The full 38 factors are for after a meeting, when a partner is in the loop. A slim version of ten parameters, each sourceable the same way for every company, is for triage before it.
I tested every sub-factor with one question: does this data exist outside a meeting? Founder track record, patents and market size do. A founder's conviction in the room does not, and no public source recorded a partner's reaction to a demo in 2009.
Letting the model guess at those would launder hallucination as signal. So five factors are carved out entirely and stay with the partners.
| Tier | What it means | Who scores it |
|---|---|---|
| T1 | Publicly observable | The engine, at full training weight |
| T2 | Sometimes in interviews or press | The engine, with human review, at 0.7 weight |
| T3 | Only visible in a meeting | The partners. Model guesses enter training at 0.3 weight until a partner overrides them. |
The engine from data intake to the partners, with the offline loop that trains it. One scoring pass feeds two prediction paths that never feed each other. Dashed pieces are designed but not live, and dotted ones are built but not deployed.
Data in
Scoring · one pass, ten parameters
Path A · what kind of outcome
Path B · what multiple
Partners
Offline · training and governance
OverviewOne company from intake to the partners. Press play or step through.
The Path B math, as the live Scenario tab runs it with the Phase-1 table. Move the pillars or the price and watch the call change. Exits use the SaaS defaults: $5B in the bull case and $300M in the base case, after dilution.
The multiples don't depend on check size: a bigger check at the same price buys a bigger slice of the same exit. The live tab interpolates between table bands, so it can differ by a point or two of probability.
| Scenario | Odds | Multiple | Adds |
|---|
No pillar below 0.4
over one model judging all ten freely
My first version let the model read everything and score all ten parameters its own way. Scores moved between runs, it cost too much, and nobody could say why a company got a 7. Now eight parameters follow point rules with strict inputs, and judgment is kept for contrarian thesis and product differentiation. Cost fell about 1,000x and the variance went with it.
over a weighted average
A big market shouldn't hide a broken team, so a deal has to clear every bar. The cost is that a bet that is brilliant on one axis and weak on another lands next to a deal that is mediocre everywhere. The Phase-2 model is meant to fix that.
over waiting for a trained model
Seven bands built from the Top-40 portfolio outcomes gave partners odds they could read on day one. The learned model is trained and backtested against the table, and isn't serving yet.
over feeding the outcome model into the multiple
"What kind of outcome is this?" and "what return at this price?" are different questions, and the models mature at different speeds. Each reads the scores directly, so one can fail without taking the other down.
over showing the ensemble and calibration
My instinct was to show the sophisticated part. The 21 slides cover the problem, the rubric and how the firm would use it. The partners needed to trust that the rubric captured their judgment, not audit gradient boosting.
"The engine triages and surfaces. The partners make every investment decision."
"A missing label is recoverable. A wrong one is poison."
The problem, the rubric and how the firm would use it. The ensemble, calibration and SHAP plan stayed out.
The two senior partners score the Top 40 portfolio companies on the five meeting-only factors, as of the investment date. Each score needs a specific memory or quote, a blank beats a guess, and unicorns go first.
Rubric changes and a quarterly SHAP review of what drives predictions. The model learns weights but never rewrites the rubric, and any weight that won't settle falls back to the Phase-1 prior.
Designed, not built.
Partners disagree with the engine all the time, and today that disagreement disappears when the meeting ends. The labels the model most needs are the ones partners produce for free in every meeting.
See it on the mapEvery override records the engine's score, the partner's score and one line on why. That record feeds the next training run.
The study set leans on companies Draper funded, so the model can learn what got funded instead of what succeeded. Documented passes and other funds' portfolios fix that from the start.
One model for "would Draper invest?" and another for "given an investment, what return?", so survivorship is modelled instead of hidden inside one classifier.
Trying to get your experts' judgment into a system without asking them to trust a black box? I'd like to hear about it.
pattanayakspandan@