Pipeline

How the number is computed

Five steps turn raw company data into a score. The last step, scoring, reads its rubric from a config file.

The ETL pipeline

enrich is opt-in: it must be explicitly requested for the features step to see freshly enriched data, since features always reads from enrich's output directory.

The score step is config-driven: its rubric, which signals count, how they're combined, how they're scaled, and how many points each is worth, lives in a YAML file the engine reads.

The scoring engine

Why YAML

The rubric lives in config/rubric_v2.yaml. Each bucket's cap and points value carries an inline comment explaining its rationale, the deep_tech bucket's cap: 2 comment reads “2+ tags = maximally deep-tech,” for example. That context stays attached to the number it explains.

Known limitations

• enrich must be requested explicitly. The pipeline orchestrator's default step list excludes it, but features always reads its output directory.
• Team-size correlation is weak. complexity_score correlates with log(team size) at r≈0.10, roughly half the dataset carries no deep-tech signal at all, which caps how strongly team size can track the score.
• Complexity does not predict success. Point-biserial correlation with the topCompany badge is r≈0 (n=91), and with Acquired or Public status is r≈−0.11 (n=598). A confound-controlled logistic regression traces that negative reading to batch vintage and team growth, not to complexity itself, complexity's own coefficient is not significant once those are controlled for. See the dashboard's success section and notebooks/complexity_analysis.ipynb, section 11.