Palantir Ontology Scenarios: Let Agents Fail Safely in Sandboxes Before Production

Scenario: A Sandbox for Decisions, Not Just Data

Palantir defines a Scenario as a sandbox layered on top of the current Ontology data. Humans or agents apply one or more Actions to edit objects and relationships in this sandbox; those edits do not affect the main Ontology. Conceptually: current real state + a set of candidate edits = a comparable future . The sandbox does not duplicate the entire enterprise dataset — it stores only deltas relative to the baseline: modified attributes, created or deleted objects, added or removed relationships. When a Function reads the Ontology inside a Scenario, it sees the state with those deltas applied. Any edits the Function produces also stay inside the Scenario.

Crucially, a Scenario is not a standalone result table; it is a temporary business state where objects, relationships, rules, and applications continue to operate under the same semantics.

It Is Not a Historical Snapshot, Nor a Development Branch

The terms "sandbox," "fork," and "branch" can cause confusion with two other capabilities:

Not a data versioning tool. Official documentation states Scenarios cannot provide an Ontology snapshot at a past moment. They answer "what if we do this now?" not "what was the data three months ago?"

Not Global Branching. Global Branching serves builders developing and testing end-to-end workflows that may affect production. Scenarios serve workflow users — people and agents — letting them compare business choices without disturbing main Ontology data. One governs "how to build the workflow," the other "how to test options after it's built."

One Port Congestion, Three Simulated Futures

The article walks through a supply-chain example. The Ontology already contains objects like Port, Route, Shipment, Customer Order, Warehouse, Inventory, and Production Plan, plus reusable Functions for delay risk, stock-out risk, and transport cost. The operations team creates three Scenarios:

Scenario A: Prioritize air freight. Modify transport mode and planned arrival time, then recalculate order delay risk, freight cost, and margin impact.

Scenario B: Cross-warehouse transfer. Pull inventory from another warehouse; the current order's risk drops, but the system must check whether the source region now faces a new gap.

Scenario C: Split order and negotiate with customer. Guarantee the must-have quantity, defer the remainder, and adjust order commitments and production schedules accordingly.

The three options should not be reduced to a single score. The team must compare on-time delivery, transport cost, inventory gaps, production disruption, and customer priority together. Scenario A may deliver most reliably but at highest cost. Scenario B appears cheaper but may shift risk to another region. Scenario C looks like a compromise but requires customer acceptance of a new commitment.

Note: This example is a conceptual composition based on Palantir Scenario, Action, Function, and Ontology relationships, not an official customer case study.

Scenarios Don't Automatically Tell You Which Option Is Best

A key boundary: a Scenario is a container for holding a simulated state, not a simulation engine that invents business causality. Why transferring inventory affects another region's stock-out rate, or why changing a route alters cost and arrival time, still requires explicit relationships, rules, Functions, prediction models, or optimizers. If those logics are incomplete, the Scenario merely wraps incomplete assumptions in a more orderly package.

A credible what-if workflow therefore needs at least four layers:

Mutable business objects and relationships;

Actions that express alternative decisions;

Functions or models that compute outcomes and ripple effects;

Unified metrics that allow comparison across multiple Scenarios.

Missing any layer turns "simulation" into a demo that only changes surface numbers.

For Agents, a Cheap Error Boundary

Human analysts pick options; agents can enumerate them faster. An agent can generate several parameter sets from the current object state, apply corresponding Actions to different Scenarios, invoke Functions to recompute metrics, and hand the trade-offs and evidence to a human. This is far more robust than letting an agent mutate production objects directly.

However, "sandbox doesn't affect production" does not mean "anything goes in the sandbox." Agents still only see objects they have permission to see, and can only call exposed Functions and Actions. The objective functions, constraints, and comparison metrics used in the simulation must be defined by the business team. Moreover, agents should not lightly be granted permission to merge a Scenario back into the main Ontology. Proposing a plan, running the simulation, explaining trade-offs, and approving the write-back are four separable authorization steps.

Temporary vs. Persistent Scenarios Solve Different Problems

For a quick calculation during a meeting, a temporary Scenario suffices. Palantir's current documentation says temporary Scenarios exist only for the current session; in Workshop and similar apps, their metadata is not retained after the session ends.

If a proposal needs cross-shift review, multi-team comparison, or an audit trail of who created it and why, a persistent Scenario is required. Persistent Scenarios store metadata as Ontology objects — they can have a name, author, description, and links to related orders, events, or plans. The proposal becomes a shareable, collaborative, governable decision asset rather than a transient set of numbers on one analyst's screen.

Merging Is Not "Copy to Production" — It's Another Controlled Action

After simulation, the team can do nothing or choose a Scenario to merge back into the main Ontology. In Palantir's design, the merge itself is implemented as an Action type. Teams can restrict which objects and relationships may be merged, and use permissions plus Submission Criteria to control who can execute. The selected Scenario's staged edits are submitted as a single transaction through this merge Action.

This creates a clear process boundary: inside the Scenario the team discusses possibilities; on the merge Action the organization assumes real responsibility.

Five Common Pitfalls When Building Scenarios

Treating Scenario as a historical query. It automatically rebases onto the latest baseline data; it was never designed to freeze a past moment.

Editing results instead of causes. Directly lowering "estimated delay days" is not simulation. You must change decision variables — route, transport mode, inventory allocation — and let Functions recompute results.

Looking at only one aggregate score. A single score hides trade-offs. Delay reduction comes at the expense of cost, inventory, or other customers' risk; those must be unpacked.

Using a stale baseline as reality. Documentation notes Scenarios default to auto-rebase every 10 minutes on the main or global branch. This keeps them current, but reviewers must record the comparison timestamp and key inputs.

Letting the agent create, score, and merge its own proposal. That lets the proposer define the scoring criteria and then self-approve. In high-risk workflows, these three steps should be separated.

When Is a Scenario Worth Creating?

Not every Action needs a sandbox. If you're just updating a low-risk note with clear validation and easy rollback, a regular Action is enough.

A Scenario adds value when all of the following conditions appear together:

A decision modifies multiple objects or relationships;

Impacts propagate through inventory, orders, production, or staffing;

The team genuinely has multiple alternative options, not just a single conclusion to validate;

Different options can be compared using the same set of metrics;

Real write-back, once executed, carries high reversal cost or triggers external side effects;

Humans or agents need to preserve the evidence chain for "why this option was chosen."

If none of these problems exist, don't add a Scenario just for technical completeness.

The Value of Simulation Is Not Predicting the Future

Scenarios won't give an enterprise a perfect digital twin. They don't eliminate model bias, data latency, or the incalculable human judgments in business.

Their practical value is letting a set of candidate actions be compared under the same business semantics, current state, and evaluation metrics. People and agents can expose errors in the sandbox instead of writing them directly into orders, warehouses, and production plans.

In the author's simplest terms: It doesn't predict the future for you; it makes different futures visible before you act.

Palantir currently marks Ontology Scenarios as Beta — functionality may change and may not be available in all environments. Official docs also note a default 30-day lifetime for Scenarios, plus constraints from related Actions and Functions. Before production use, teams must re-verify against their current tenant and documentation.

Next in the series: why the same Ontology can be consumed simultaneously by Object Views, Object Explorer, Workshop, and OSDK.

References

[1] Palantir Docs: Ontology Scenarios Overview —

https://www.palantir.com/docs/foundry/ontology/overview-ontology-scenario/

[2] Palantir Docs: Temporary Scenarios —

https://www.palantir.com/docs/foundry/ontology/temporary-scenario/

[3] Palantir Docs: Store Scenario Metadata as Objects —

https://www.palantir.com/docs/foundry/ontology/persisted-scenario/

[4] Palantir Docs: Merge Scenarios —

https://www.palantir.com/docs/foundry/ontology/merge-scenario/

[5] Palantir Docs: Workshop Scenarios Overview —

https://www.palantir.com/docs/foundry/workshop/scenarios-overview/

[6] Palantir Docs: Why Create an Ontology? —

https://www.palantir.com/docs/foundry/ontology/why-ontology/