Some assembly required

An AI model is one part of a working service. A business can buy a ready-made application, connect its own software to a hosted model, or operate and adapt an open-weight model. Each route involves choices about information, permissions, cost and responsibility. This guide explains how the parts fit together and what those choices mean in practice.

What the model labels mean

The labels used to describe AI models answer different questions. “Frontier” concerns capability, “open-weight” concerns access to the trained model, and “hosted” concerns how it is operated. A frontier model can have open weights, and an open-weight model can be supplied as a hosted service.

Access to weights does not necessarily include the original training data or unrestricted rights to build a business from the model. Open source goes further than access to weights. The Open Source Initiative’s definition requires freedoms to use, study, modify and share, supported by code, model parameters and information about training data.¹

A worked example: handling a refund

A customer writes: “I returned two items, but only one has been refunded.” The company needs to establish what happened, explain it and, if money is owed, arrange payment.

An LLM can help interpret the message and compose a response. The order records, refund rules and authority to move money come from elsewhere. The following illustrative design shows how these parts can work together.

1. Identify the customer and obtain the records. The application is the software coordinating this refund service. It can be bought, configured or built by the business. Here, it checks which records the customer may access. It looks up the order, returned items and payments. This might use an order number to query a database. Finding a relevant policy passage might instead involve searching documents.

2. Give the model the information it needs. The request, selected records, policy and instructions become part of its context: the information available to it when generating a response. Finding information to supply in this way is often called retrieval. The method matters: a search result is not automatically the current policy, and a similar order is not the customer’s order. The application needs suitable sources, access checks and ways to handle missing or conflicting information.²

3. Check and authorise the refund. In this design, software checks what was paid, what has already been refunded and whether the request meets the company’s rules. Cases outside those rules go to an authorised person. A tool is a software function the model can request, for example, to look up a payment or submit a refund request. The application executes the function and enforces its limits. A tool can retrieve information or take an action; retrieval and tools are not mutually exclusive approaches.

4. Make the payment and report the result. The payment service accepts only an authorised instruction, checks the amount and destination, and records the outcome. The application supplies the result to the LLM so it can explain to the customer what happened. Approval and successful payment are separate events.

The permissions here are specific: who may see the customer’s records, who may approve a refund and which software may issue it. Asking the LLM to obey a policy does not itself prevent access to another customer’s records or block an unauthorised payment. Those restrictions need to be enforced by the surrounding software.³

New purchases and refunds change the company’s records. The application supplies current records when needed; the model does not have to be retrained each time a customer buys or returns something.

What an ontology adds

In computing, an ontology defines concepts, their properties and relationships within a domain. It makes meanings explicit so that people and software can use them consistently. The concept predates Palantir and is not confined to its products.⁴

In the refund example, those meanings include:

• Buyer and user: the person who bought a product may not be the person using it.
• Order and payment: one payment may cover several orders.
• Approval and completion: a refund can be authorised before any money has been returned.

These distinctions can be represented in databases and application code. An ontology provides an explicit, shared model of them. If customer service and finance both use it, they have a common definition of an approved refund rather than maintaining incompatible meanings in separate applications.

People still decide what the definitions mean and how exceptions are represented. Conflicting records do not become reliable because they have been connected. A definition can preserve an important distinction or hide it. The value lies partly in making those choices available for examination and change.

Definitions also need software to apply them. If the company extends its refund window, someone must update the eligibility check as well as the policy supplied to the assistant. Otherwise, the assistant could describe the new policy while the payment software applies the old one.

Where Palantir fits

The companion Signal What the company knows examines Palantir’s proposition specifically. In that context, it is useful to distinguish its platform, its Ontology and the AI models used within them.

Foundry is Palantir’s platform for integrating data and building operational applications. Its Ontology connects defined business concepts and relationships to data and to functions that act on them. AIP, its Artificial Intelligence Platform, brings AI models into that environment.⁴⁵

This is not an alternative to using LLMs: it is a way of using them alongside business definitions, rules and actions. AIP can use OpenAI and Anthropic models, including through Microsoft Azure and Amazon Web Services. The model developer, the company hosting it and the application provider need not be the same company.⁵

Notes to the diagram

The boxes distinguish product roles. They do not show separate infrastructure or specify where the software runs.

The models shown are examples. See the model-list endnote for the developers and model families listed in Palantir’s public catalogue on 22 October 2026.⁶

A business can also assemble its own applications, shared definitions and controls. Buying a platform and building those parts involve different costs and responsibilities. Neither route removes the work of deciding whose information is authoritative, what actions are permitted or who can change the rules.

Supplying information or training the model?

A model can use information supplied for a particular response without being retrained. Fine-tuning changes its learned behaviour through further training. Supplying an order record or a policy document does not, by itself, update the model’s weights.¹

For example, a company could train a model on past customer messages to improve how it distinguishes a new refund request from someone chasing a refund already approved. With a method called Low-Rank Adaptation (LoRA), training changes a small set of added numerical values while leaving the original model’s weights fixed. Those learned adjustments form an adapter. The original (or base) model and adapter work together to produce responses: the base weights stay fixed, but the combined behaviour changes.

Training only the added values reduces training requirements. Keeping adapters separate avoids storing a complete model for each specialism. This can be the intended way to run the model, not just a temporary stage before changing its weights. The adapter still needs its compatible base model; it cannot work alone.⁷

The service would still need to look up this customer’s order to find out whether the refund had actually been paid. Training on earlier examples cannot tell it what happened to a payment this morning.

An adapter is optional in the refund example. Some providers offer fine-tuning and host the adapted model; a company with suitable open weights and licence rights can also arrange its own adaptation.¹

How the parts fit together

The diagram brings the refund example together. The application supplies information and executes permitted tool requests. The model helps interpret the request and prepare the response; separate checks govern whether money can move.

Note to the diagram: Paths for declined requests or cases requiring human review are not shown.

Worked application: NVIDIA’s supply chain

NVIDIA’s supply-chain work shows how a business can train an adapter to give an open-weight model a specialism based on its own experience. The adapted model works alongside current operational data, mathematical allocation software and human planners. NVIDIA described the implementation in its Technical Blog on 10 September 2026.

The operation involves millions of parts, thousands of suppliers and dozens of manufacturers. A missing component can leave other material waiting at a factory. NVIDIA wants to shorten that wait and get assembled systems into use sooner.

Palantir’s Foundry brings the operational records and signals together through its Ontology. NVIDIA uses cuOpt, a mathematical solver: software that calculates how to meet an objective within specified constraints. Here, it calculates how much of each constrained material to send to each manufacturing site, and when, taking account of supplies, production capacity and commitments. It aims to minimise Time of Ownership: how long material remains at a site before leaving in a component or finished product. It also identifies bottlenecks and lets planners explore alternatives: what changes if supplies fall or another manufacturing site becomes available?

NVIDIA’s review of past allocations found that planners made better decisions than the mathematical solver. They also considered supplier conversations, disruption warnings and experience that the solver’s inputs did not capture. NVIDIA recorded their decisions, explanations and outcomes, then trained a LoRA adapter for an open-weight LLM from its Nemotron family, leaving the base model’s weights fixed.

The base model and adapter work together, using current operational information to recommend allocations with supporting reasons and risks. Past decisions inform the training; current information informs each new recommendation. Planners make the final decision. NVIDIA reports that planners spend less time reconstructing routine decisions and can cover more sites and products. Capturing their expertise also helps new colleagues learn. Planners’ corrections and subsequent production outcomes are retained for later evaluation and training.

To test the adaptation, NVIDIA replayed historical situations using only information available at the time. The adapted model achieved 86.7% allocation-decision accuracy, compared with 17.5% before adaptation and 55.5% for the larger Nemotron 3 Ultra. Specialist training made the smaller model outperform the larger model on this task.⁸

The adapter holds learned adjustments; the retained records explain the decisions and provide material for testing and further training. Neither replaces the connections to current information, the allocation software or the planners’ judgement. Together, these make up the capability the business is developing.

Who operates the model?

The location of the computers and responsibility for the service are separate choices.

Owning equipment does not mean the company does all the work. Renting computing does not necessarily mean the cloud provider manages the model. Operating an open-weight model can give a company more control over where information is processed and when versions change; buying a service can reduce the expertise and operating work it needs to supply.

The same named model can deliver different results

Choosing a model does not settle how it will work in practice. The choices made when running it also affect its responses. Two services offering the same named model can therefore deliver different results.

Whoever runs the model sets limits on how much information it can receive and how much output it can generate, within what the model, software and computing capacity support. If a business runs the model itself, including on rented computing capacity, its team makes those choices. If it buys access through a hosting company, that company sets the available limits and options.

Another choice is numerical precision. Using lower precision means storing the model’s numerical values in a more compact form. This reduces memory requirements and can make the model cheaper or faster to run, but it can also affect its responses.

Artificial Analysis, a company that independently evaluates AI models and services, has tested what these differences mean in practice. In August 2026, it reported that some hosting companies’ response limits cut off the GLM-5.2 model before it finished reasoning. On a test of difficult academic questions, the most restrictive services achieved half the reference deployment’s score or less. The reference was the same model run by Artificial Analysis using its developer’s recommended configuration.⁹

The same model was available, but some services cut its response short. This does not mean every business needs the most demanding configuration. Limits that are sufficient for short enquiries may be unsuitable for analysing long documents or working through complex problems. A cheaper service can be good value when it completes the work reliably; retries, incomplete answers and human corrections can erode that saving.

Artificial Analysis provides comparisons worth investigating. Whether the business runs the model itself or uses a hosting company, it still needs to test the configuration it will actually use on its own work. Without checking results against what a satisfactory outcome requires, it may not know whether it has made suitable choices or whether a saving in price or time comes at the expense of results it needs. Control over the settings is useful; testing shows whether those settings work for the task.

Data terms and operating costs

A promise not to use customer data for training does not mean the data is never stored or accessed during processing. Nor does it establish what can be exported. Those commitments need checking for each company processing the information.¹⁰

Tokens are the units into which a model divides its inputs and outputs. A token price gives a rate, not the cost of completing a refund correctly. That cost also depends on repeated attempts, human review, computing, software and staff.¹

What does the licence allow the business to do?

Three uses can require different permissions:

1. Internal use: staff use a model to analyse the company’s refund records.
2. A customer feature: the business integrates an LLM into a customer-facing application, for example, to help customers request refunds.
3. Selling model access: the business gives other businesses access to the model so they can use it in their own applications.

In the second example, the customer uses the business’s refund application. In the third, the customer obtains model access to develop or operate applications of its own.

Moonshot AI’s Kimi K3 licence illustrates the distinction. Giving third parties meaningful control over model inputs, parameters or training data can constitute “Model as a Service”. If a company or affiliate operates such a business and combined group revenue exceeds US$20 million over any consecutive twelve months, commercial use requires a separate agreement. Embedded end-user features, such as the refund application, are excluded from that category. Sharing outputs with customers, however, is not internal use.¹¹

The earlier K2.5 licence permits commercial use without K3’s separate-agreement requirement for model services, although it retains a naming requirement for commercial products and services above specified thresholds. That difference illustrates the reason to check the licence for each release against the intended use.¹¹

A business may own the application or specialist work it develops while using the underlying model and software under licence. Its rights in that work do not remove the conditions attached to those components. Both matter when selling the resulting service or taking the work to another supplier.¹²

What can you take with you?

Spotify helped take music streaming mainstream. As the service grew, listeners spent years building playlists and teaching Spotify what they liked. Both the collections they assembled and the recommendations shaped by their listening gave them reasons to stay.

Taking that accumulated value elsewhere became a matter of tools, rights and commercial restrictions. Spotify introduced Download My Data in 2018 to help meet GDPR access requirements.¹³ Yet in 2020 it required the transfer app SongShift to stop moving playlists to competing services. Users protested, including by invoking GDPR rights. Spotify subsequently permitted transfers of users’ own playlists, while continuing to exclude Spotify-created playlists.¹⁴

That boundary remains relevant. Soundiiz’s current guidance excludes direct transfers of Spotify-created playlists, including personalised selections such as Discover Weekly and Your Top Songs. These reflect the listener’s choices, but are treated as Spotify-owned. Listeners can copy the tracks into their own playlist and transfer that copy. They preserve the selection, but not its continuing updates.¹⁵

Spotify’s data download also includes listening history and, where available, summaries of the listener’s tastes. A replacement service would still need to make use of that information and generate its own recommendations.¹⁵

Keeping the accumulated work and keeping the service running are different achievements.

For a business, value also builds through use: instructions staff refine, work they check and retain, workflows they improve, and examples they select for further training. None of this requires the model to learn automatically from every interaction. It does require the business to recognise what is worth keeping.

The table distinguishes the work built up from the software needed to use it. Several rows can apply to one service; the original source records remain important throughout.

Two different export problems

A business’s definitions and rules may be held in an ontology, database structures, application code or configuration. Wherever they sit, taking them elsewhere means establishing what the replacement can use and what must be rebuilt.

An ontology export: exporting definitions can preserve how the business describes its customers, products, relationships and rules. It does not automatically transfer the applications that use them. Palantir, for example, supports exporting ontology definitions, editing them and importing them back into Foundry. Other interfaces provide access to data, metadata and code. Recreating a working application elsewhere still requires connections to records, permissions, calculations and actions.¹⁶

A model adapter: the learned adjustments need a compatible base model and software. They cannot simply be attached to an unrelated model. Retained training examples and tests may help develop and assess a replacement, but its performance still needs checking.⁷

Some knowledge will remain outside the files: why an exception was retained, what failed before or which apparent anomaly an experienced operator knows to leave alone. A team can inherit a rule without the discussion that explains it.

Political conditions can make these questions urgent. A local model may remain usable while access to hardware, updates or expertise becomes constrained. A supplier may become politically unacceptable while its software still performs well. Export rights are useful, but the company also needs to know what it would take to keep working.

Four practical tests

Choose a manageable piece of real work and test the following changes in a controlled environment. They apply to improving an existing service as well as moving elsewhere.

Palantir’s ontology-design guidance suggests testing real business questions that participants have not seen in advance, with people who did not build the ontology. The four tests above apply that principle more broadly to the model, software and team.¹⁷

For each of the four tests, record:

• What the team could do itself. What could it understand, reuse and change without outside help?
• What it needed to proceed. Supplier assistance, missing documentation, specialist knowledge or additional permission. If none was needed, record that too.
• What the change would take. The time, cost and disruption, including other work that would have to wait.

Employees’ contributions

Employees’ decisions, corrections and explanations can help develop an AI system without those employees necessarily understanding how their contributions will be used. A business needs to consider what it has explained to them, what influence they have over that use, and the implications for their roles. Ownership of the resulting material does not settle those questions. The companion Signal What the company knows explores the incentives and stakeholder interests in more depth.

---

Whether the business buys a service or builds one, it needs to understand what makes it work, what it has built up through use and what it would take to develop it further. A failed test can justify improving the existing service rather than changing suppliers. A successful test can make staying a better-informed decision. The point is to discover which choices the organisation has paid to keep, and which it has only been told are available.

Related Signals

The risk is shared. The race is not. examines who can require restraint when countries and companies are competing for the benefits of advanced AI.

The terms of access can change follows how political decisions reach technology a business already uses, including the AI services on which its work depends.

What the company knows examines how AI changes the use of organisational knowledge, whose priorities it reflects and what the organisation itself continues to learn.

Open models. Competing ambitions. examines what businesses can develop from available models, how that changes competition and who benefits as models are used across borders.

Sovereignty in a world of layered dependencies examines what countries seek to develop, retain and influence across payments, cloud services and AI.

Further reading

AI models and organisational knowledge: selected resources brings together introductions to LLMs and open weights, explanations of the software around a model and Palantir’s own architectural documentation. Each entry identifies its audience, contribution and limitations.

Notes

Footnotes

1. IBM, What are large language models?, sections on training, inference, retrieval and deployment; Georgetown CSET, Open Foundation Models, 12 March 2024, terminology section. “Frontier” is a relative capability description here, not a fixed class of hosting or licence. Open weights do not automatically include training data, unrestricted reuse rights or an explanation of each output. Running a model and adapting it are separate operations; using private context does not itself update its weights. AWS, Model customisation in Amazon Bedrock, also documents hosted fine-tuning; availability depends on the model and service. Open Source Initiative, Open Source AI Definition 1.0, sets out the freedoms and required materials. Its data-information requirement is not a requirement to publish every item of training data. ↩ ↩² ↩³ ↩⁴

2. Anthropic, Effective context engineering for AI agents, 29 September 2025, on context, tools, retrieval and persistent notes; OpenAI, Retrieval, on searchable external files. The architectural comparison concerns where meaning and control are implemented, not a universal performance advantage for one design. ↩

3. Palantir, Ontology permissions, distinguishing permissions on ontology definitions from access to the underlying object data. The need to enforce access and action permissions applies beyond Palantir. OWASP, LLM06:2025 Excessive Agency, recommends enforcing permissions in downstream systems and checking authorisation independently of the LLM. Permissions must be configured and enforced; an ontology does not make a system secure by itself. ↩

4. Natalya F. Noy and Deborah L. McGuinness, Ontology Development 101, Stanford, 2001, pp. 1–3, defines domain concepts, properties and relationships independently of any vendor product. Palantir, Ontology overview and Ontology system. The refund scenario and its optional adaptation are QURKI’s architectural illustrations, not accounts of an actual deployment. ↩ ↩²

5. Palantir, AIP architecture, Bring your own model, and Model Catalog. The catalog names OpenAI through Azure and Anthropic through AWS as examples of creator/provider combinations; model access varies by deployment. The diagram summarises product roles, not a specific deployment. AIP connects models to wider operational capabilities; an LLM and an ontology can be complementary parts of one system. ↩ ↩²

6. Model developers and families listed by Palantir, checked 22 October 2026. The Supported LLMs page lists xAI (Grok), OpenAI (GPT and o-series), Anthropic (Claude), Mistral AI (Mistral), Meta (Llama), NVIDIA (Nemotron, including Llama-based adaptations), Google (Gemini and Gemma), DeepSeek, Moonshot AI (Kimi), Alibaba (Qwen) and Z.ai (GLM). Its separate embedding-model list also includes Snowflake (Arctic), alongside OpenAI and NVIDIA models; its audio list contains OpenAI models. This is the complete developer/family list on that public page at the check date, rather than every model version. The linked page lists individual releases and experimental status. Availability depends on deployment, region, permissions and accepted terms. Customer-registered models can extend the selection through Bring your own model. ↩

7. Full fine-tuning updates the original model parameters. LoRA trains added parameters while keeping the base weights fixed. A supported adapter can subsequently be merged into a local copy of its base weights, but this is optional and does not make it compatible with an unrelated model. Using an adapter does not remove the need to comply with the model’s licence.

   Sources: Hugging Face’s LoRA conceptual guide explains the method and its efficiency benefits. NVIDIA’s NeMo checkpointing and fine-tuning documentation describe saving and using adapters and full-model checkpoints. ↩ ↩²

8. NVIDIA, From Wafer-Out to First Token: Codifying Supply Chain Expertise with Nemotron and Palantir Foundry, 10 September 2026. The article provides the full implementation account. Its development benchmark compares model recommendations with planners’ decisions and actual outcomes, without publishing the complete scoring rules. Allocation reductions were much more common than increases. On a measure giving each decision type equal weight, the adapted model scored 58.6%, compared with 29.0% for its base model and 42.0% for Nemotron 3 Ultra. The results do not establish superiority over human planners; production-risk forecasting remained difficult. Wider planner coverage and shorter onboarding are reported without quantified measures. Further training uses accumulated feedback through a governed process; the model does not retrain itself during use. ↩

9. Artificial Analysis, Launching the Endpoint Accuracy Index: Same Model, Different Accuracy, 4 August 2026; Endpoint Accuracy Index v1.0 methodology. The GLM-5.2 finding concerns HLE-250, a 250-question reasoning test, rather than the overall index. Artificial Analysis compares hosted services with its own reference deployment and reports statistical uncertainty. Its reference follows the model developer’s and serving software’s recommended settings. Wider tests also examine tool use and working with long documents. Results describe the services and configurations tested at a particular time. Response limits, numerical precision and other settings are separate factors; the example does not attribute the reported shortfall to reduced numerical precision. ↩

10. OpenAI, Data controls in the OpenAI platform; Anthropic, Does Anthropic act as a data processor or controller?. Terms and eligibility vary by service and configuration. No-training commitments do not by themselves establish zero retention, no processing access, portability or perpetual availability. Check the actual agreement rather than treating a provider-wide label as sufficient. ↩

11. Moonshot AI, Kimi K3 licence, §§1–4, and Kimi K2.5 licence, checked 22 October 2026. Both require retention of copyright and permission notices. K3 also excludes simple relays from its model-service definition. Its separate branding condition requires prominent “Kimi K3” display above 100 million monthly active users or US$20 million in monthly product/service revenue, not the annual group-revenue test. Internal use and access through Moonshot’s official products or certified inference partners are exempt from both requirements. K2.5 requires “Kimi K2.5” display at the same monthly thresholds but has no equivalent model-service clause. ↩ ↩²

12. Palantir, GCP Marketplace terms, §§1.1, 2.1 and 4, distinguish customer content, including specified customer-authored code and models, from Palantir’s products and materials, which carry separate licence restrictions. An applicable separate agreement takes precedence. The Kimi K3 licence likewise subjects modifications and derivative works to its conditions. These sources illustrate why rights in a business’s own development must be considered alongside permissions for the components it uses. ↩

13. Spotify, company timeline, October 2008 launch; 2018 Sustainability Report, printed p. 27, links Download My Data to GDPR access compliance. Third-party playlist transfers predated that download: Tidal’s Import your playlists to TIDAL, 16 April 2015, describes transfers from Spotify through Soundiiz. ↩

14. Digital Music News, Spotify Abruptly Shut Down SongShift’s API Access — Then SongShift’s Users Fought Back, 23 October 2020, reports the restriction and restoration of transfers of user-created playlists. Contemporary complaints appear in the Spotify Community discussion; a user’s Hacker News account, 13–14 October, describes invoking GDPR portability rights. The objections are documented; their precise influence on Spotify’s reversal is not established. SongShift’s original announcement is no longer accessible. ↩

15. Soundiiz, Why can’t I transfer playlists made by Spotify?, updated 23 August 2026, identifies the excluded personalised playlists and explains copying tracks into a user-created playlist before transfer. Spotify’s Developer Policy, §III.9, permits transfer of users’ personal data and playlist metadata within its wider restriction on transfers to competing services. Spotify, Understanding your data, describes playlist information, listening history and Taste Profiles in its download packages. These pages were checked on 22 October 2026. Copying a selection does not reproduce its future updates; downloading a taste profile does not establish that another service can import and use it. ↩ ↩²

16. Palantir, Export, edit and import an Ontology and Interoperability. These describe exporting definitions for reimport into Foundry and accessing data, metadata and code. Other products support related capabilities: C3 AI’s Type System connects data definitions with application behaviour; Stardog provides knowledge-graph and semantic modelling tools; and Graphwise’s PoolParty supports creating, managing and exchanging ontologies. ↩

17. Palantir, Ontology design: Validation. The guidance recommends testing unfamiliar business questions with people who did not build the ontology. ↩