A May 2026 research preprint tested whether Product Hunt launch signals could help predict which startups would raise a Series A round. The researchers began with 67,292 launches from 2019 to 2025 but found only 528 verified Series A outcomes within 18 months. That left a positive class of just 0.78%.
The strongest ensemble used 61 engineered features and reached an average precision of 0.037 on the private test set. Although that represented 4.7 times the random baseline, the absolute result remained modest. The confidence interval was also wide at 0.024 to 0.072, showing how unstable private-market predictions can become when successful outcomes are rare.
This is the central engineering problem behind a deal-scoring model architecture. Raw private-market information does not arrive as a clean training matrix. It arrives as revised financing records, inconsistent company names, duplicated announcements, persuasive pitch-deck language, incomplete founder histories, and market data recorded at different frequencies.
One careless transformation can make a weak signal look predictive. One incorrect entity match can turn two companies into one. Likewise, one current database value inserted into a historical training row can contaminate an entire backtest.
How should developers convert funding events, team histories, documents, and market conditions into a reproducible feature vector?
A production-grade architecture should preserve event time, entity identity, source provenance, transformation logic, missingness state, and feature version. Only then should the scoring model consume the data.
For the wider model-development framework, including validation and known failure limits, read the AI deal-screening validation framework.
Build a Point-in-Time Evidence Layer
Anthropic provides a clear 2026 example of why a deal-scoring system must preserve historical company snapshots instead of joining every training record to the latest profile.
On January 15, 2024, a valid Anthropic feature vector could record Amazon’s initial $1.25 billion investment and its announced plan to invest up to $4 billion. It could not include the remaining $2.75 billion that Amazon completed on March 27, 2024, because that capital event occurred after the January screening cutoff.
The company’s financial profile changed substantially over the next two years. On February 12, 2026, Anthropic raised $30 billion at a $380 billion post-money valuation. At that point, the company reported a $14 billion annualized revenue run rate, while Claude Code alone had surpassed a $2.5 billion run rate. Those facts could enter a model scored after the announcement, but they would be future information for any training record dated before February 12.
The difference became even larger on May 28, 2026. Anthropic raised another $65 billion in a Series H round at a $965 billion post-money valuation. The company also said its annualized revenue run rate had crossed $47 billion earlier that month. Therefore, a database refreshed after May could show a valuation and commercial profile that did not exist during Anthropic’s earlier investment rounds.
A further event arrived on July 6, 2026, when TeraWulf disclosed a 20-year data-center lease with Anthropic. TeraWulf said the agreement was expected to generate approximately $19 billion in contracted revenue for TeraWulf and support about 401 megawatts of critical IT load. This is an infrastructure commitment linked to Anthropic, not Anthropic revenue or a new equity-financing round. A feature pipeline must classify it accordingly rather than add $19 billion to Anthropic’s funding or sales totals.
These dated events create four different versions of the same company:
- January 2024 snapshot with Amazon’s initial investment and announced commitment
- February 2026 snapshot with a $380 billion valuation and $14 billion revenue run rate
- May 2026 snapshot with a $965 billion valuation and revenue run rate above $47 billion
- July 2026 snapshot with a newly disclosed long-term infrastructure obligation
A model trained to reproduce the January 2024 decision must use only the first snapshot. Adding the February, May or July information would create look-ahead leakage and make the historical model appear more accurate than it could have been in production.
The ingestion layer should therefore separate the business event from the date on which the market could observe it. It should also preserve later corrections without deleting the original record.
source_id
source_event_id
entity_id
event_type
effective_at
published_at
observed_at
ingested_at
valid_from
valid_to
raw_object_hash
schema_version
parser_version
currency
source_confidence
supersedes_record_id
For Anthropic’s May 2026 round, event_type might be primary_equity_financing. The July TeraWulf agreement would require a different classification, such as infrastructure_lease_commitment. Treating both events as generic “capital” would distort funding velocity, runway estimates and valuation features.
A simplified historical record could look like this:
{
"entity_id": "anthropic",
"as_of": "2024-01-15T23:59:59Z",
"included_events": [
{
"event_type": "strategic_investment_received",
"investor": "Amazon",
"amount_usd": 1250000000,
"effective_at": "2023-09-25"
}
],
"announced_commitments": [
{
"investor": "Amazon",
"maximum_amount_usd": 4000000000,
"status": "partially_funded"
}
],
"excluded_future_events": [
"amazon_investment_completion_2024_03_27",
"series_g_2026_02_12",
"series_h_2026_05_28",
"terawulf_lease_2026_07_06"
]
}
The example also shows why received capital, announced commitments, valuation changes, revenue estimates, and infrastructure obligations must remain separate feature classes. They describe different economic conditions and should not be collapsed into one lifetime-funding field.
A reliable point-in-time evidence layer answers one precise question for every feature:
What information about this company was actually available when the score was generated?
When the pipeline can answer that question from stored records, developers can reproduce a historical feature vector, audit a score change and test the model without contaminating the result with later company developments.
Resolve Entities Before Calculating Features
Private-market data rarely uses one stable identifier.
A company may appear under a trading name, legal name, former brand, domain, subsidiary or acquired entity. Founders can have abbreviated names or overlapping employment histories. A token project may migrate contracts or deploy versions across several chains.
Entity resolution should combine deterministic and probabilistic methods.
Deterministic keys may include:
- CIK and LEI identifiers
- Verified company domains
- Legal registration numbers
- Contract addresses
- Chain IDs
- Transaction hashes
- Verified professional-profile IDs
Probabilistic matching can compare names, locations, domains, role dates and associated investors. Low-confidence matches should enter a review queue rather than being forced into a canonical entity.
This control prevents one financing round from becoming several events and stops syndicated versions of one announcement from creating artificial momentum.
Corrections should create new versions rather than overwrite the original evidence. That design allows developers to reconstruct both what the source said and what the system knew at any previous decision date.
Engineer Capital Team and Market Features
Once the evidence layer is stable, the pipeline can begin constructing model-ready variables. The main feature groups normally cover capital formation, team and investor relationships, textual evidence, market conditions, and, where relevant, on-chain activity.
Measure Capital Formation Over Time
Lifetime funding is a weak standalone feature. A company that raised $30 million over eight years has a different capital profile from one that raised the same amount within nine months.
Funding velocity measures capital raised during a fixed historical window:
Funding Velocityw = ∑Capital Raised During Windoww / Length of Window in Months
Useful windows include 90, 180, and 365 days. Multiple windows allow the model to distinguish a recent funding surge from sustained capital formation.
Round cadence measures the interval between financing events:
Round Cadencet = Close Datet - Close Datet-1
Valuation step-up measures the change between successive post-money valuations:
Valuation StepUpt = log (PostMoneyt / PostMoneyt-1)
Before calculating those features, the pipeline should classify the financing event. Primary equity, venture debt, secondary share sales, grants, token sales, and convertible instruments do not represent the same type of capital.
For example, a secondary transaction may provide liquidity to an existing shareholder without adding operating cash to the company. Counting it as fresh funding would overstate funding velocity.
Valuation changes also require currency, security, and transaction-type normalization. Preferred share rights, liquidation preferences, bridge extensions, and secondary components can make two headline post-money figures economically different.
Other useful capital features include:
- Days since the previous financing
- Investor count by round
- New-investor ratio
- Follow-on investor retention
- Capital raised relative to company age
- Estimated runway
- Down-round indicators
- Debt-to-equity financing mix
Each value should retain the financing event IDs used in its calculation.
Convert Team Histories Into Temporal Graphs
A broad founder-pedigree score is difficult to inspect and can conceal bias. Developers should instead construct event-based variables that can be reproduced from dated records.
Examples include domain experience, previous operating roles, prior company outcomes, founder role continuity, cofounder tenure, team-size change and senior employee turnover.
Network features can then model relationships among founders, employees, companies and investors. Useful measures include:
- Founder-investor degree
- Betweenness centrality
- PageRank
- Shared-employer edges
- Previous cofounder edges
- Co-investor network density
- Distance to a prior successful venture
Research using Crunchbase data found that network effects varied by financing stage. Competition-related signals appeared more relevant during early fundraising, while investor-network features became more influential at later growth stages. This suggests that one global network score may hide important stage-specific relationships.
The graph must also be temporal. Every node and edge should carry an effective date, and a historical screening record should exclude relationships formed after its cutoff.
University, geography, employer brand, and gender-coded variables should not be accepted as unexplained quality signals. Each feature needs an economic rationale, an identified owner and subgroup stability tests.
Extract Text Signals Without Duplicating Claims
Pitch decks, regulatory filings, company websites, and news articles contain useful evidence, but they also contain repetition and promotional language.
A practical NLP flow is:
The claim-classification layer should distinguish:
- Verified facts
- Regulatory disclosures
- Independent reporting
- Management claims
- Forecasts
- Opinions
When 12 articles repeat the same company announcement, the system should create one underlying claim cluster connected to 12 references. It should not treat those articles as 12 independent confirmations.
Potential text features include product-category embeddings, evidence-to-claim ratio, regulatory-risk entities, forecast intensity, source diversity and sector sentiment.
Research using 20,172 Crunchbase profiles found that textual self-descriptions contributed materially to predictive performance when combined with structured company information. However, this result shows predictive association within the research dataset; it does not prove that promotional language independently predicts investment returns.
Developers working with news and funding announcements should also review failure modes in funding-news sentiment extraction.
Add Market and On-Chain Context
Company features do not operate independently of the market cycle. Interest rates, sector financing volume, public comparable valuations and exit conditions can change the meaning of a company-level signal.
Market variables should therefore be lagged and stored with their release vintage. A later revision to an economic series should not replace the version available during the original screening process.
Tokenized opportunities may require additional features covering wallet concentration, vesting exposure, liquidity depth, contract authority, governance participation, and bridge activity.
The lineage key for an on-chain event should include the chain ID, block number, block hash, transaction hash, contract address, and log index. Pipelines should also define a confirmation threshold and a method for handling chain reorganizations.
Feature class | Raw evidence | Main transformation | Model-ready output | Main failure risk | Lineage key |
Funding velocity | Dated financing events | Event classification and windowed aggregation | Capital rate | Revised or duplicated rounds | Financing event ID |
Team network | Founder, employee, and investor histories | Temporal graph construction | Centrality and relationship scores | Identity errors or future edges | Person, organization and edge IDs |
Text evidence | Dated filings, decks, and news | Claim extraction, deduplication, and embedding | Structured claims and vectors | Repeated promotion is counted as confirmation | Document hash and claim ID |
Market context | Rates, sector flows, and comparable valuations | Lagging and vintage normalization | Market-regime variables | Revised or misaligned series | Series ID and release vintage |
Token activity | Contract events and indexed transactions | Address classification and rolling aggregation | Concentration and liquidity measures | Exchange wallets, bridges or Sybil activity | Chain, block and transaction IDs |
Normalize Features Without Erasing Meaning
Capital values, network scores, categorical fields and embeddings have different scales and distributions. They cannot enter a shared model matrix without controlled transformation.
Capital amounts often require log1p transformation and robust scaling because a few large rounds can dominate the distribution. Round intervals may need capping and stage-relative scaling. Network centrality values may also require logarithmic transformation because a small number of investors sit at the center of many graphs.
Categorical data presents another trade-off.
One-hot encoding is transparent but can create high-dimensional sparse arrays when sectors, locations, and investor types contain many rare categories. Hashing reduces dimensionality but makes collisions harder to inspect. Target encoding can be compact, although it must be fitted inside the training period to prevent outcome leakage.
Text embeddings need similar restraint. A dense vector with hundreds or thousands of dimensions can overwhelm a dataset containing only a small number of mature outcomes. Regularization, controlled dimensional reduction, and feature-group ablation tests help determine whether the text representation contributes repeatable information.
Missing data should retain its meaning. A blank revenue value might represent:
- Confirmed zero revenue
- Revenue not disclosed
- A metric that does not apply
- A failed or unavailable source
Combining those states into one zero value removes important context. It can also teach the model to score disclosure behaviour instead of operating performance.
Transform parameters should be learned from the training sample and stored with a version identifier. The production service must use the same clipping rules, category maps, scaling statistics, and embedding model used during training.
The PHBench preprint provides a useful warning about model selection under severe class imbalance. Its validation results reflected a best-of-144 selection process conducted on a validation set containing only 53 positive outcomes. Performance declined on the private test set, where the strongest ensemble achieved an average precision of 0.037 across 103 positive outcomes.
The authors also identified performance changes across market periods. It includes the 2020-2021 funding boom and the contraction that followed. Therefore, feature relationships should be tested across multiple market vintages rather than accepted because they performed well during one development period.
For a deeper discussion of unstable labels and small samples, see data sparsity in private-market machine learning.
Preserve Lineage From Source to Score
A funding-velocity feature of $1.25 million per month should never exist as an unexplained number.
A reviewer should be able to trace it back to the financing events, original currencies, effective dates, source documents, and transformation code used in its calculation.
The lineage chain may look like this:
Each stage should preserve its timestamp, identifier, version, source hash, and transformation reference. For example, the normalized financing event should point back to the source document, while the calculated funding-velocity feature should identify every financing event included in its historical window.
The W3C PROV-O standard provides a useful structure for this process by representing provenance through entities, activities, and agents. Relationships such as wasGeneratedBy, wasDerivedFrom, hadPrimarySource, and wasRevisionOf can describe how source evidence becomes a model-ready feature.
A feature registry should contain both the business definition and the technical contract:
feature_name
business_definition
source_dependencies
event_timestamp_field
transform_version
code_commit
owner
freshness_sla
valid_range
ttl
null_policy
model_dependencies
retirement_status
Historical retrieval should reproduce feature values at the event timestamp. Feast describes this as a point-in-time-correct join. Its historical retrieval process scans backward from each entity timestamp within the configured time-to-live window rather than attaching the latest available value.
A platform-neutral feature record could look like this:
{
"entity_id": "org_12345",
"as_of": "2026-06-30T23:59:59Z",
"features": {
"funding_velocity_180d": 1250000,
"days_since_last_round": 74,
"founder_network_pagerank": 0.018,
"sector_sentiment_30d": -0.14
},
"missingness": {
"revenue_growth_yoy": "not_disclosed"
},
"lineage": {
"snapshot_id": "snap_20260630_88af",
"feature_set_version": "deal_features_v12",
"transform_commit": "7e3c4a1"
}
}
The values are illustrative and do not disclose IPO Genie’s production schema.
This structure allows an engineer to determine whether a score changed because of new evidence, corrected entity mapping, a revised transform or a different model version.
Public disclosures show that investment platforms are incorporating machine learning and language models into sourcing and evaluation workflows.
Reject Weak Features Before Production
A feature should not enter production only because it improved one historical metric.
Each candidate should pass schema validation, deterministic unit tests, null checks, range tests, freshness monitoring, duplicate-source detection, and train-serving consistency checks. It should also survive source outages, temporal stability tests, subgroup reviews, and reconstruction from a stored snapshot.
Reject a feature when:
- Its original evidence cannot be recovered
- Its meaning differs between training and inference
- It depends on a later revision
- It duplicates an existing signal
- Its contribution disappears across vintages
- Its source is too unstable for the required freshness level
- It acts mainly as an unjustified demographic or institutional proxy
Feature importance is not proof of validity. It shows that the model relied on a variable, not that the relationship is causal, fair, or durable.
Deterministic transformations are generally better suited to dates, financing amounts, contract events, ownership records, and vesting schedules. Learned representations are useful for documents and heterogeneous languages. However, embeddings should complement structured evidence rather than become the only explanation for a deal score.
A production-ready scoring record should answer five questions without requiring manual reconstruction:
- Which source produced the evidence?
- When was that evidence available?
- Which entity did it describe?
- Which transform created the feature?
- Which model version consumed it?
Reliable private-market signal detection starts with those answers. Model complexity cannot compensate for missing lineage, inconsistent entities or poorly defined features.
Disclaimer: A deal score should support structured investigation rather than replace investment judgment. It estimates relationships found in historical evidence; it does not guarantee that a company will raise capital, complete an IPO, produce returns, or avoid operational and market failure.
FAQs
What Features Belong in a Private-Market Deal-Scoring Model
The main classes include capital and financing signals, team and investor networks, textual evidence, market conditions, and relevant on-chain activity. Every feature should have a defined calculation, a historical timestamp, and a recoverable source.
How Is Funding Velocity Calculated
Funding velocity measures qualifying capital raised within a specified period divided by the length of that period. The calculation should distinguish primary equity from debt, grants, secondaries, and token sales.
How Should Team Signals Be Represented
Team signals should use dated operating histories and temporal relationship graphs. Reproducible variables are more defensible than a broad founder-pedigree score with no visible calculation.
How Do Point-in-Time Joins Protect Model Training
They retrieve the feature state that existed at each historical decision timestamp. This prevents current company records or later data revisions from entering older training rows.
How Should Missing Private-Market Data Be Encoded
Confirmed zero, non-disclosure, non-applicability, and source failure should remain separate states. They describe different conditions and should not be collapsed into one null value.
Can Text Embeddings Replace Structured Deal Features
No. Embeddings can represent product descriptions, technical documents, and market language, but they should be combined with dated capital, team, ownership, governance, and liquidity evidence.
