AutoResearch and the Fine-Tuning Ontology: Turning Institutional Workflows into an Owned Model Factory
A complete guide to Palantir's AutoResearch and Fine-Tuning Ontology, from datasets and SFT, DPO, and GRPO to an 11-step workflow for building, evaluating, and owning specialized models.
The enterprise asset may not be another stronger general-purpose model. It may be a system that continuously turns an institution's own workflows into training signal. Palantir's 22-page report argues that institutions should organize internal data, decisions, actions, and outcomes into trainable episodes. AutoResearch then searches across datasets, training techniques, base models, compute, and budget ceilings to produce a model specialized for a high-value workflow. The weights, data versions, evaluation sets, recipes, and experiment results remain in the Fine-Tuning Ontology as assets the institution can deploy and distribute.
The important idea is not simply automated hyperparameter tuning. The report tries to turn post-training from a one-off project into a closed production loop. Live operations create new data. AutoResearch reads studies, constraints, prior experiments, artifacts, evaluations, and scores to design the next run. Each run writes new experiments, events, artifacts, evaluations, and scores back into the system. Successful and failed attempts both make the next search better informed.
The report states that all example data is notional. This article preserves the structure and figures because they explain the method, but it does not present those product claims as independently verified benchmark results.
1. What AutoResearch automates
Palantir defines AutoResearch as automation of AI post-training for institutions. By using the Fine-Tuning Ontology, it aims to produce continually improving models faster and at lower cost, with outlier performance on the workflows an institution values most.
Traditional post-training is usually organized as a temporary project. A team collects data, cleans examples, builds preference data, chooses SFT, DPO, or GRPO, sets hyperparameters, runs training, inspects evaluations manually, and changes the next recipe by intuition. AutoResearch attempts to make this process stateful, traceable, and searchable.
Teams provide four inputs:
- select the relevant corpus from the Fine-Tuning Ontology;
- define the target capability;
- choose success criteria;
- set constraints on models, data, compute, and budget.
AutoResearch then uses this institutional context to design and execute the post-training loop: identify learnable patterns in proprietary data, generate targeted synthetic examples, select and configure post-training techniques, and evaluate every candidate against the defined objectives. Each iteration records data, method, model changes, evaluation results, compute use, and cost. According to the report, this visibility shows which changes create measurable capability gains and where more training can produce compounding return.
The five-step loop
- Identify the target workflow. Choose a high-value workflow and its specific tasks, such as engineering diagnostics on institutional systems, traversal of institutional documents, or correct use of proprietary tools.
- Select an Ontology cross-section. Choose the objects that contain useful training signal, including repair tickets, manuals, fault records, or tool logs.
- Generate measurable training signals. Convert the selected data into examples, labels, evaluations, and synthetic tasks that reflect the target workflow.
- Search the post-training space. Explore strategies across data mixtures, synthetic examples, training techniques, model parameters, and compute budgets.
- Deploy and iterate. Continue along the highest-performing, lowest-cost paths, discard ineffective ones, and produce a model optimized for the institution's workflow.
The central claim is not that AutoResearch can generate more data. It is that every step creates structured state. The system reads prior studies, constraints, experiments, artifacts, evaluations, and scores. Each run writes experiments, events, artifacts, evaluations, and scores. Palantir calls this read-write cycle the source of a compounding asset. The model is not the only durable output; the institution and system accumulate reusable context.
Four sources of value
| Value | Palantir's claim | What still needs proof |
|---|---|---|
| Accelerated compounding | Compress the cycle from idea to experiment, measurement, and value. Every iteration builds on an Ontology of prior outcomes, so models improve as data, techniques, and priorities change. | Whether search is faster than an experienced team without locking a bad evaluator or leaked data into later experiments. |
| AI model ownership | Build models around proprietary data, objectives, and success definitions while retaining control of the corpus, weights, constraints, evaluation criteria, and process. | Whether data rights, weight licenses, supply-chain dependencies, exit terms, and portability actually support the word "ownership." |
| Specialized performance | Find learnable patterns in proprietary data, generate targeted synthetic examples, and select techniques that improve a specific workflow rather than general competence. | Whether holdouts truly isolate asset, site, fault family, and period, and whether improvements survive the production distribution. |
| Controlled cost | Operate within model, data, compute, and budget constraints. Small probes remove weak directions, while detailed tracking maps capability gain to cost. | Whether cost accounting includes data construction, synthesis, evaluation, human review, inference, and failed experiments, not only GPU hours. |
The phrase "outlier capabilities" matters. The goal is not generalized competence. It is a model that is materially better on the small set of workflows that determine institutional value.
2. The Fine-Tuning Ontology: training assets need their own ontology
The Fine-Tuning Ontology is the full representation of training primitives: datasets, techniques or recipes, and models. The most important objects are the models themselves and their weights. Palantir argues that the sovereign institution should own this structure so that it can protect and compound its expertise, or white-label and distribute it on its own terms.
Invoking AutoResearch against a Foundry environment instantiates the Fine-Tuning Ontology. The data structure stores training primitives and connects them to the live institutional Ontology. It is not a static catalog. It is a persistent post-training state layer that keeps consuming production signal.
2.1 Dataset assets
The Ontology structures raw, disconnected data from systems such as ERP, MES, and CRM to improve decisions. That data and the decisions around it can be processed into specialized training sets, stored in the Fine-Tuning Ontology, and owned by the institution. The sets can train proprietary models or be distributed as market assets.
The report separates transactional data from kinetic decision data. Organizations hold transactional records in ERP, MES, CRM, PLM, quality, and maintenance systems. The Ontology connects those records to improve decisions. The decisions, actions, and records of whether the actions succeeded are also stored as Ontology objects. Transactional and kinetic data together become specialized datasets with high training signal for concrete workflows.
A dataset asset is described as having lineage, versioning, security markings, and access controls. It can train internal models or be licensed to other institutions. The report's data-to-asset workflow is:
- Connect. Integrate ERP, MES, CRM, PLM, QMS, and maintenance systems into Foundry, preserving full source history.
- Structure. Map records to asset, work order, fault record, and repair ticket objects and links so cross-system context is explicit.
- Curate. Select the Ontology cross-section, record outcomes, and amplify learnable patterns with synthetic generators.
- Package. Publish a versioned training set with schema, lineage, evaluation splits, and security markings.
- Monetize. Train proprietary models or license the set as a white-labeled data asset.
The example asset is called Repair-Diagnosis, version v3.2, with 1.24 million rows, a Trace+Outcome schema, an 80/10/10 split, lineage across six object types, and a Restricted marking. The example makes the value proposition concrete. The useful material is not a pile of repair tickets. It is the linked structure of fault records, repair actions, outcomes, success and failure labels, costs, and object relationships.
2.2 Technique assets
Palantir codifies post-training tradecraft as technique assets. Different workflows and datasets favor different methods. The report says repeated deployments produced opinionated knowledge about which techniques work for which class of workflow. In the Fine-Tuning Ontology, that knowledge becomes tested training code, recommended hyperparameters, and tooling that identifies an appropriate recipe.
The report groups problems and techniques into three classes:
| Objective | Typical problem | Technique | Training signal | What the model learns |
|---|---|---|---|---|
| Imitate | Execute complex, multi-argument tool calls exactly: checking weather, reading files, fixing failing tests, converting CSV to JSON, inspecting a SQL schema, confirming a booking. | SFT, Supervised Fine-Tuning | Curated demonstrations. | A gradient update on every token to reproduce curated trajectories. |
| Contrast | Minimize refusals while preserving the right, reduced set of guardrails. | DPO, Direct Preference Optimization | Preference pairs: chosen and rejected behaviors. | Move toward the correct behavior and away from a near miss. |
| Explore | Open-ended, multi-step problems with no single correct trace. | GRPO, Group Relative Policy Optimization | Rollouts scored by a judge model. | Reinforce decision paths that beat the group mean, including strategies absent from demonstrations. |
The reported library is broader. It includes continued pretraining, full SFT, LoRA SFT, QLoRA, prompt tuning, distillation, rejection, ORPO, KTO, SIMPO, DPO, PPO, RLAIF, and GRPO. Every candidate produced from the AutoResearch tree is expected to ship as runnable code with hyperparameter priors such as LoRA rank, learning rate, epochs, DPO beta, GRPO group size, and the real-to-synthetic ratio.
"Codified" means three layers:
- Training code: tested implementations that run on the data and compute inside the Fine-Tuning Ontology.
- Technique selector: tooling that reads the objective and success criteria and recommends a method or sequence of methods.
- Priors from experience: starting hyperparameters and pruning rules from prior Palantir runs so search is more efficient.
2.3 Model assets and the model factory
AutoResearch operating on the Fine-Tuning Ontology, combined with compute, becomes what Palantir calls a model factory. It creates custom frontier models for institutional workflows and leaves ownership with the sovereign institution. Each model is registered in Foundry with full lineage, including data mixture, recipe, cost, and evaluation metrics. Promoted models can enter production, learn from live operations, and be distributed or licensed under the institution's brand.
The inputs are training sets from the Ontology, codified techniques such as SFT, DPO, and GRPO, and compute and cost constraints. AutoResearch searches, trains, and evaluates candidates, then writes them to a versioned, scored, traceable model registry. Outputs can run production workflows and agents, or be sold, licensed, or rented.
Registering model, data, recipe, evaluation, and cost together turns a model from a file produced by a team into an auditable organizational asset. The "best gain per cost" criterion is also important. A slightly higher score at a much higher cost might not be the right production model.
3. A complete 11-step example
The report follows one notional spindle-overheating workflow from definition to ownership. The model is not asked to explain what might be wrong. It must recommend an action that can be measured, executed, and reviewed.
3.1 Define the workflow
The workflow recommends an action that clears an E214 spindle-overheating alarm. The model receives fault context: E214, flow of 5.1 L/min, and temperature of 89°C. The proposed action is to replace the coolant filter. Success is fixed in advance: flow must recover above 8 L/min, temperature must fall below 75°C within 30 minutes, and E214 must not recur.
This step fixes what the model receives, what it returns, and the rule that decides whether the returned action was correct. Ambiguous success criteria will later contaminate labels, evaluation, and promotion.
3.2 Represent the episode in the Ontology
An episode is not merely a question and answer. It is the case, the action taken by a user or agent, and the objects that measured what followed. Only episodes with a measured outcome can train the system.
The example combines asset CNC-042, fault E214, filter replacement, flow recovery to 10.2 L/min, and temperature of 72°C. Static or transactional data includes Machine, Part, the fault-code manual, and Procedure. Kinetic data is the action. Outcomes include readings, a load test, alarm state, and whether the fault recurred.
This representation makes action effectiveness queryable. Without outcomes, a model can learn only the language of a procedure. With outcomes, it has a chance to learn which action worked under which conditions.
3.3 Pass the objects into AutoResearch
The cross-section is the set of object types that carry signal for the workflow. The example includes fault records, tickets, readings, procedures, and manuals: 41,200 episodes with measured outcomes. AutoResearch reads which fields are inputs, targets, and success signals.
It also receives the compute location, such as cloud, on premises, or third party. Before training, the data is checked for isolated objects, contradictory records, incomplete records, and leakage.
3.4 Keep lighthouse cases unseen
Episodes are partitioned before training. The example uses 80/10/10, holding back 4,100 of 41,200 episodes, with machines that do not appear in the training set. The split runs along asset, site, fault family, and period so a recipe cannot score well by recognizing a case it has already seen.
Random row-level splitting is one of the most dangerous shortcuts. Records from the same machine, fault family, and adjacent periods can appear on both sides, producing attractive offline scores that fail in production. The requirement that evaluation machines be unseen determines whether the later numbers mean anything.
3.5 Mix real and synthetic episodes
A mixture is a weighted selection of episodes plus synthetic episodes for cases absent from the record. Each mixture is versioned.
- Mix A: successes only.
- Mix B: successes and failures.
- Mix C: rare faults upweighted, with synthetic cases added.
The notional Mix C is 45% tickets, 15% procedures, and 40% synthetic. One synthetic case uses CNC-208 at 34°C and 5.4 L/min, replaces the filter, and recovers to 9.8 L/min at 71°C. Synthesis is not treated as arbitrary text expansion. It combines real objects, operating conditions, and outcome patterns to fill long-tail cases.
3.6 Assemble the training recipes
A recipe contains one base model, one mixture, one technique, and its hyperparameters. Every recipe is written to the Fine-Tuning Ontology before it runs.
The example recipe is base-c, Mix C, LoRA SFT, rank 32, three epochs, and learning rate 2e-4. Base models are scored before training, so an experiment can compare the trained candidate with its starting point and compare different base models.
3.7 Evaluate every candidate
A run produces a checkpoint and a result. The result contains scores on held-back episodes and compares each dimension with thresholds set in advance. The example tracks correct action, load-test pass, recurrence, and unsafe recommendations.
| Candidate | Correct fix | Load test | Recurrence | Unsafe |
|---|---|---|---|---|
| v1.0 · base-a · full SFT | 0.71 | 0.86 | 0.09 | 0.031 |
| v1.1 · base-c · full SFT | 0.83 | 0.92 | 0.05 | 0.014 |
| v2.0 · base-c · LoRA r32 | 0.88 | 0.94 | 0.04 | 0.008 |
| Threshold | 0.90 | 0.97 | 0.02 | 0.010 |
The best example, v2.0, still misses several targets. Correct action is 0.88 against 0.90, load-test pass is 0.94 against 0.97, and recurrence is 0.04 against 0.02. Its unsafe rate of 0.008 beats the 0.010 threshold. This is why a multi-metric evaluation matters. A single aggregate cannot hide a regression in a safety-critical dimension.
3.8 Iterate to the threshold
A failed result should identify a failure mode. The system then changes the mixture, synthetic material, hyperparameters, or base model and runs another experiment.
The example finds only 76% correctness on high-ambient faults and 6% over-replacement. The next iteration upweights high-ambient episodes, synthesizes degraded filters at 34°C, raises LoRA rank from 32 to 64, adds two epochs, and retests the next base-model candidate. Structured feedback is necessary because a note in a chat cannot drive the next search.
3.9 Deploy into production
A model that clears every threshold is promoted. The gate also fixes which recommendations require human confirmation. In the example, a new E214 case arrives with flow at 5.2 L/min. The model recommends an action, the approval gate checks it, and an approved operator executes it.
The report says approval is required when the action is safety-critical or model confidence is low. The production model should recommend an action, cite the procedure, and escalate when unsure. The gate is not an optional UI hint. It is a control point between model output and a physical system.
3.10 Learn from live operations
Each production case creates a new episode: what was recommended, what was done, and what the readings showed afterward. Accepted, overridden, and failed outcomes all return to the system. Overrides and failures carry the strongest signal.
In the example, an accepted case reaches 10.1 L/min and passes the load test. An engineer overrides another recommendation to inspect the coolant pump. A failed case remains at 87°C with E214 active. The failure should return to step 3 and modify object inputs or the cross-section, not merely adjust a probability.
3.11 Own the asset
The Fine-Tuning Ontology now holds the model and weights, training data, evaluation set, and every experiment and result. The example asset, diag-agent v2.0, contains institution-controlled weights, Mix C v3.2, 4,900 synthetic episodes, 4,100 evaluation episodes, a base-c plus LoRA r32 recipe, and 38 experiments with results.
The asset can run production agents and workflows, or be distributed, rented, licensed, or white-labeled. Ownership terms, access controls, and commercial licenses determine whether post-training creates a durable institutional asset rather than another project deliverable.
4. What the system actually changes
The important shift is not a particular training algorithm. It is an expansion of what counts as a post-training asset. Conventional model development treats weights as the main object. The Fine-Tuning Ontology puts data lineage, decisions, success criteria, holdouts, failed experiments, and cost into the same queryable system. Weights are only one output.
The second shift is from documents to measured actions. Enterprise knowledge bases preserve manuals and answers, but often do not know whether a recommendation worked. ERP, MES, QMS, and maintenance systems record actions and consequences, but in separate objects. The Ontology connects recommendation, execution, result, and recurrence so the model can learn from outcomes rather than imitate wording.
The third shift is evaluation by design. Success criteria, unseen machines, separation by fault family and period, predeclared thresholds, and human approval are established before training. Without these controls, AutoResearch would only optimize an untrusted objective faster.
The structure is also relevant to robotics, embodied AI, and physical-AI teams. Robot logs usually contain task instructions, perception state, action trajectories, controller events, human takeovers, and safety anomalies. These can be organized as episodes. Physical systems add synchronization, sensor calibration, sim-to-real differences, contact events, safety constraints, and recovery behavior. Palantir's industrial-ticket example demonstrates an asset model; it does not prove that the same pipeline solves every data problem in robot foundation models.
5. Limits and assessment
This is a Palantir product thesis, not an independent evaluation. It offers a clear architecture, but it does not publish controlled comparisons, customer results, cost breakdowns, latency, data scale, or failure rates that establish AutoResearch's advantage over a skilled post-training team. The 0.88, 0.94, and 38 experiments are notional. They cannot support procurement or architecture decisions as benchmarks.
Several questions need independent evidence:
- Evaluation integrity: Are lighthouse cases genuinely unseen in production, are thresholds set independently of the training team, and is the judge model calibrated?
- Data rights: May tickets, manuals, operator behavior, and customer data legally be used for training, cross-institution licensing, and white-label distribution?
- Safety and accountability: Can the human gate be bypassed, does low confidence reliably trigger escalation, and are overrides and failures recorded completely?
- Cost: Does gain per cost include data cleaning, human labeling, synthetic review, evaluation, inference, and failed runs?
- Lock-in and portability: Can weights, data formats, recipes, and the Ontology be exported, and can training and deployment continue after leaving the platform?
The reasonable conclusion is that the Fine-Tuning Ontology points toward a serious architecture: post-training as an auditable production asset rather than a model file. Whether AutoResearch delivers on its automation claim will depend less on the number of candidates it can generate than on whether every experiment is tied to a correct objective, independent evidence, real cost, and clear accountability.
Search, training, and record-keeping can be automated. The definition of success, data rights, safety thresholds, and final accountability cannot be automated away.
Source: Palantir, AutoResearch and the Fine-Tuning Ontology, 2026.
