Short answer: YC's Winter 2027 Requests for Startups asks research labs for small, zero-shot foundation models for manufacturing, energy and biology. The models train once; each deployment then brings its own history as context. The hard part YC names is data: rights, verifiable rewards, and clean, correctly defined history. A foundation model learns the patterns of a domain. A governed semantic layer supplies the point-in-time, scoped, permissioned history that applies them to your company. Colrows is that layer. It does not train models.
"AI's biggest bottlenecks are moving beyond the models." That is how Y Combinator opens its Winter 2027 Requests for Startups. Its Vertical Foundation Models item asks for small, cheap models for manufacturing, energy and biology. It also names the hard part: data rights, verifiable rewards, and the history each user feeds the model.
A foundation model learns the patterns of a domain. Applying those patterns to one company needs that company's history, under its definitions and its permissions. Colrows, an autonomous semantic layer, supplies that part. It does not train models.
The data side is harder than it looks. On BEAVER, a text-to-SQL benchmark built from real enterprise warehouses, agentic frameworks running GPT-5.2 answered 10.8% of questions correctly (arXiv:2409.02038). Getting the right data, at the right grain, under the right definitions and permissions, is a problem model capability alone has not solved. Here is how three approaches compare.
Three ways to put a model on enterprise data
| Decision point | General LLM on raw tables | Vertical model on ungoverned data | Vertical model + Colrows |
|---|---|---|---|
| History supplied at inference | Whatever the prompt or retrieval step pulls | Exported extracts; definitions drift between teams | Point-in-time history under versioned, scoped definitions |
| Outcome data for evaluation | Human spot checks | Ad hoc labels per project | Reproducible outcome datasets built on governed definitions |
| Access control | Prompt-level filters | Copies of data outside policy | RBAC, ABAC, row and column rules applied when the query is compiled |
| Audit | Chat logs | Notebook history, if anyone kept it | Audit traces and replayable past states of every definition |
The difference is not the model. It is whether the history reaching the model is defined, scoped, permissioned and reproducible.
What YC asked for in the Vertical Foundation Models RFS
The category appears in YC's Winter 2027 Requests for Startups, written by partner Diana Hu. The request is narrow and technical:
"I'd like to see more research labs build specialized foundation models for manufacturing, energy, and biology that work zero-shot or from a handful of examples. The bar is matching or beating general-purpose models at orders of magnitude less inference compute, so they're cheap enough to run on everything."
Two examples anchor the thesis. The first is Jev from TypeSafe AI, which "gives developers a typed decision and a probability instead of generated text." The second is Google's TimesFM-3, a 330M-parameter forecasting model that works across related time series with no task-specific fine-tuning.
Jev's appeal carries over to enterprise data: a typed answer with a calibrated probability is easier to check than generated text. Colrows applies the same idea to data questions. It returns SQL compiled and validated against governed definitions before it runs, so every answer can be checked and replayed. See deterministic vs. probabilistic text-to-SQL.
YC wants models for physical industries, with a compute bar set on inference cost. One passage describes how the model learns about you:
"Training happens once, and each new user brings their own history as context. The hard part is getting high-quality, vertical-specific, verifiable rewards. You'll need rights to the data and a clear win in accuracy and compute over existing specialist models."
The model is trained once. Every plant, utility or lab that uses it must then supply clean, correctly defined history.
Own the model, own the data: the Winter 2027 list as one thesis
Two other items in the same list speak to enterprise buyers more directly. Jon Xu's "Own Your Intelligence" opens with "Today, nearly every company building with AI rents its intelligence." It argues that "someone has to turn workflows into evals, expertise into training data, production failures into improvements, and carry all of it forward with each new base model."
Brad Flora's "AI for the Air-Gapped Economy" starts from where that data lives: "The most valuable data in the world isn't in the cloud." It covers on-premise models and deployment for defense, banks, hospitals and nuclear operators.
Read together, the three items say models are getting smaller and more specialized, while the data that feeds them, the outcomes that judge them, and the rules on who may use them stay with you. That is the work an autonomous semantic layer does.
Where domain-specific foundation models win, and where they lose
The case for a vertical foundation model is strongest where specialized training shows measurable gains on native domain data. Domain pretraining alone does not guarantee a win over a general model. YC's own bar reflects this: "a clear win in accuracy and compute over existing specialist models."
Text: general models caught up with domain LLMs
GPT-4 beat BloombergGPT, a finance LLM trained from scratch, on ConvFinQA by 76.48 to 43.41 (Li et al., EMNLP 2023). Treat that as indicative: GPT-4 ran on the ConvFinQA dev set because test labels are not public, and BloombergGPT's score came from its own earlier paper. In medicine, Microsoft's Medprompt took GPT-4 past 90% on MedQA with prompting alone and beat Med-PaLM 2.
Non-text: specialists beat classical incumbents
Google DeepMind's GenCast beat ECMWF's leading ensemble forecast on 97.2% of 1,320 targets (DeepMind, December 2024). TabPFN, published in Nature in January 2025, beat baselines tuned for 4 hours in 2.8 seconds on tabular datasets of up to 10,000 samples.
The winners share a profile: native data in grids, sequences or tables, a large clean training corpus, and a classical incumbent to beat. That is the profile of manufacturing, energy and biology.
A forecasting model still cannot tell which definition of yield applies, which line counts as "active", or whether a user may see a site's data. Something else has to answer that before the history reaches the model.
The hard part YC names: context, rewards and data rights
Gartner predicts that through 2026, organizations will abandon 60% of AI projects unsupported by AI-ready data (Gartner, February 2025). S&P Global found that the share of companies abandoning most of their AI initiatives rose to 42% in 2025, up from 17% a year earlier (CFO Dive). Vertical models draw on the same enterprise data, so they will meet the same readiness problem on the way to production.
YC's passage names three different things. Keep them apart.
1. Inference-time context needs scoped definitions and a point in time
TimesFM-3 reads your history when it makes a forecast. If "unplanned downtime" means one thing in the maintenance system and another in the ERP, and nobody records which one fed the series, the model forecasts a blend of both. Different sites can legitimately define downtime differently. What matters is that each definition is governed, versioned and explicitly scoped.
Time matters too. If a definition changed in August, a backtest built on today's definition will flatter the model. Finance researchers call the related risk lookahead bias. One recent study (He et al., 2025) found it "modest" in its own test, but noted it is model- and application-specific. You can only measure it if you can replay the data as it stood on a given date.
2. Verifiable rewards are a modelling task built on consistent data
A verifiable reward is a signal that tells a model, during training or optimization, whether an output deserves credit. Designing it is the model builder's job. A governed definition of downtime does not decide which forecast is right. It does make sure the outcome data a reward is computed from measures downtime the same way on every run, and that the dataset can be rebuilt later.
Evaluation ground truth, the reference outcomes a model is scored against, needs the same consistency. Xu's "turn workflows into evals" depends on it.
3. Rights to the data need policy enforced before the query runs
Banks, hospitals and plants will not ship raw history to a model vendor. They need access rules, masking and lineage applied where the data lives.
Business meaning is the gap model upgrades do not close
On Spider 2.0, an o1-preview agent solved 21.3% of tasks, against 91.2% on the older Spider 1.0 (arXiv:2411.07763). BEAVER's 10.8% on private warehouses, cited above, shows the same problem at enterprise scale.
Add business meaning and the numbers move. In data.world's insurance benchmark, GPT-4 zero-shot rose from 16% to 54% accuracy when questions ran over a knowledge graph (arXiv:2311.07509). We dig into why in the text-to-SQL accuracy cliff.
There is a catch. In a 2026 re-run of that benchmark by dbt Labs, a hand-built semantic layer scored up to 100% on questions it covered and 0% on questions that needed relationships it did not model (dbt Labs, April 2026). It is a small test of 11 questions run by a vendor. Still, the lesson holds: a semantic model that people maintain by hand stops at the edge of what someone remembered to define.
Peer-reviewed work points the same way. Microsoft researchers found that retrieval "consistently outperforms" unsupervised fine-tuning for adding knowledge (Ovadia et al.). Google and Technion researchers found that once a model learns new facts through fine-tuning, those facts "linearly increase the model's tendency to hallucinate" (Gekhman et al.). Train the model once. Put your changing facts in governed context.
What regulators ask for: data governance and traceability
Vertical models used in high-risk settings will meet data rules. What applies depends on how the system is classified and on your role, as provider or deployer.
EU AI Act Article 10 covers the training, validation and testing data of high-risk systems. It requires governance practices covering "data collection processes and the origin of data", "data-preparation processing operations", and "the formulation of assumptions, in particular with respect to the information that the data are supposed to measure." That last clause, in practice, asks you to document what each data field is meant to measure. Logging what a system does in production is a separate set of duties under Article 12. Under the Digital Omnibus, Annex III high-risk obligations now apply from 2 December 2027 and Annex I obligations from 2 August 2028 (Hunton Andrews Kurth).
US banks now follow SR 26-2 (April 2026) for model risk, and the FDA's January 2025 draft guidance asks AI device makers to separate and document training and validation data.
Colrows provides controls that can assist in meeting these requirements: documented definitions, lineage, access policy and replay of past states. Compliance itself depends on the whole system and the processes around it.
How Colrows serves vertical foundation models
Colrows is an autonomous semantic layer. It sits above your warehouses and source systems and works as a semantic execution layer: it compiles every request into governed SQL before anything runs. It decides what the data means, who may see it, and what any model or agent receives.
The foundation model learns domain patterns. Colrows supplies the governed enterprise meaning and history to apply them to your organization. One governed layer can feed several models and agents, so you do not build and maintain a separate data pipeline for each one.
| YC requirement | What breaks without it | What Colrows supplies |
|---|---|---|
| "Own history as context" | Mixed definitions and silent changes in the input series | Versioned, scoped definitions; past inputs can be rebuilt as they stood |
| "Verifiable rewards" and evaluation | Outcome data that measures different things on different runs | Consistent, reproducible outcome and evaluation datasets; reward design stays with the model builder |
| "Rights to the data" | Extracts copied outside policy | RBAC, ABAC, row- and column-level rules and masking applied at compile time; PII stripped before anything reaches an LLM |
Worked example: from warehouse tables to a forecast input
TimesFM-3 reads arrays of numbers. It never sees a SQL table. Take a plant that wants a zero-shot forecast of daily line yield. Before the model sees a single value, someone has to turn several source systems into one clean series:
- Resolve the definition. The MES records yield per shift. The ERP records it per production order. "Daily line yield" must bind to one governed definition for that plant's scope.
- Remove what is not production. Filter out test runs, trial batches and maintenance records.
- Normalize units. Convert kilograms and tonnes to one unit.
- Align time. Move every plant to one clock and roll shifts up to calendar days.
- Apply access policy. A regional manager's request returns only her sites.
- Pin the state. Record which definition and data state produced the series, so it can be rebuilt exactly for a backtest or an audit.
Colrows compiles each step into governed SQL. If a reference is ambiguous, compilation fails and nothing runs. It proves the join path between the MES and ERP tables before any SQL reaches the warehouse, then runs the query where the data lives. The output is one table at one grain (one row per line per day) with an audit trace. Your forecasting pipeline reads that table through the Colrows API or MCP endpoint and reshapes it into the array the model expects. That last step is mechanical. Steps 1 to 6 are where forecasts go wrong.
Training the model stays with the lab. The full pipeline is in the Colrows system architecture.
Worked example: a definition changes
Six months in, the ERP starts counting planned changeovers as downtime. The maintenance system does not.
- With a hand-maintained semantic model: nothing flags the change. The input series shifts, forecasts drift, and someone notices weeks later and edits the model by hand. Past forecasts can no longer be rebuilt on the old basis.
- With Colrows: monitors detect the schema change and the conflict between the two sources. Colrows resolves the conflict where its governed rules allow, or routes it to a reviewer for approval. The approved definition becomes a new versioned state. Earlier forecasts stay reproducible under the old definition, and the definition change is reported as its own effect, so it is not mistaken for a real shift in downtime.
You can test this in a proof of concept. Introduce a conflicting field, then check what Colrows flags, what it resolves, and what waits for approval.
Data stays in place, on-premise where required
Colrows queries sources in place, so history is not copied into a new store. It runs as SaaS on AWS, Azure and Google Cloud, or on-premise, with open-weight LLMs for air-gapped sites.
On the control boundary: Colrows enforces access policy on the queries it compiles and runs. Data copied out through other routes sits outside it, so route model inputs through the governed layer.
Use cases in manufacturing, energy and biology
These scenarios are illustrative.
- Manufacturing. The line-yield example above, extended to failure forecasting: one scoped definition of "unplanned downtime", with past forecasts reproducible after the definition changes.
- Energy. A utility forecasts load across meter, weather and billing systems. Colrows joins them in place, proves the join path, and records which data fed each forecast.
- Biology and pharma. A lab evaluates a protein or formulation model against its own assay results. Colrows reads scanned lab records with document intelligence, ties them to governed batch and assay entities, and keeps evaluation datasets traceable.
Regulated buyers will feel this first. Colrows runs in production under full audit at an Indian asset reconstruction company, across portfolio ingestion, recovery scoring and NPA valuation agents. Read how that works in auditable SQL for regulated industries.
What to expect from vertical foundation models in 2027
Gartner predicts that by 2027, more than 50% of the GenAI models enterprises use will be specific to an industry or business function, up from about 1% in 2023 (Gartner, December 2025).
The fair counter-argument: models keep getting better on raw schemas. In dbt's re-run, text-to-SQL on the original schema rose from 26.9% with GPT-4 in 2023 to 62.5% with a 2026 model. Accuracy alone will not justify a semantic layer forever. Data rights, consistent outcome data, point-in-time replay and audit will, because a better model creates none of them.
If you plan to deploy vertical models in 2027, start with three checks. Does every input series have a governed, versioned definition for its scope? Can you replay any series as it stood on a past date? Can you show an auditor which records fed a given output? If any answer is no, fix that before you pick a model. Our piece on knowledge drift and semantic decay explains why those answers degrade over time without an autonomous layer.
Frequently asked questions
What is the YC Vertical Foundation Models RFS?
A Winter 2027 Request for Startups by YC partner Diana Hu, asking research labs for small, zero-shot foundation models for manufacturing, energy and biology.
What does YC say is the hard part?
Getting "high-quality, vertical-specific, verifiable rewards", plus rights to the data and a clear win in accuracy and compute over existing specialist models.
Do vertical foundation models beat general-purpose LLMs?
Specialists have strong wins on non-text data such as weather and tables. On text, prompted general models caught up with domain LLMs.
Where does a semantic layer fit?
It supplies governed, point-in-time history as context and reproducible datasets for evaluation. It does not train the model or design its rewards.
Sources
Every figure is the cited source's own published claim. Benchmarks are dataset-specific and several evaluation sets are small or vendor-run; treat the numbers as evidence of a directional pattern, not universal constants.
- Y Combinator, Requests for Startups, Winter 2027
- Google Research, TimesFM-3 (Aug 2026)
- Li et al., GPT-4 vs BloombergGPT on financial text analytics (EMNLP 2023)
- Nori et al., Medprompt (Nov 2023)
- Google DeepMind, GenCast (Dec 2024)
- Hollmann et al., TabPFN, Nature 637 (Jan 2025)
- Gartner, Lack of AI-ready data puts AI projects at risk (Feb 2025)
- CFO Dive, S&P Global AI abandonment survey (Mar 2025)
- He et al., Chronologically Consistent Large Language Models (2025)
- Lei et al., Spider 2.0 (ICLR 2025)
- BEAVER enterprise text-to-SQL benchmark (v3, May 2026)
- Sequeda et al., Knowledge graphs and LLM accuracy on enterprise SQL (Nov 2023)
- dbt Labs, Semantic layer vs text-to-SQL (Apr 2026)
- Ovadia et al., Fine-tuning or retrieval? (EMNLP 2024)
- Gekhman et al., Fine-tuning on new knowledge and hallucination (EMNLP 2024)
- EU AI Act, Article 10: Data and data governance
- EU AI Act, Article 12: Record-keeping
- Hunton Andrews Kurth, Digital Omnibus on AI enters into force
- Federal Reserve, SR 26-2 Revised Guidance on Model Risk Management (Apr 2026)
- Gartner, 3 bold predictions for the future of GenAI (Dec 2025)
