Architecture

Your model does the maths. STEER carries the meaning.

Three layers, each with one job. Your Internal Model calculates. Palantir Foundry governs the data underneath. STEER carries assumptions, rationale and approvals all the way to the board paper. Keeping those jobs separate is what keeps the result trustworthy.

The stack

Three layers, clear boundaries

Decision layer

STEER

OwnsThe business concepts people actually make decisions about (scenarios, model runs, capital breakdowns, decisions), the workflow that connects them, and the screens that management and actuaries use day to day.
Does notCalculate capital. STEER reshapes, compares and presents model output. It never builds a competing calculation of its own.
Built withFoundry’s Ontology, which models business objects and the links between them; Actions, which make controlled, logged changes such as request a run or approve a decision; and Workshop, Foundry’s application layer.
Calculation layer

Internal Model

OwnsEvery capital number, including SCR, VaR and TVaR, standalone and allocated capital, diversification benefit and reinsurance recoveries.
Does notChange. Your model keeps its own code, tests and validation. STEER adds a thin adapter that feeds it approved inputs and collects its outputs.
How it runsAs a batch job, either on Foundry compute or in your existing environment. Each run produces one complete, permanent output pack.
Foundation

Palantir Foundry

OwnsStorage, permissions, versioning and lineage.
DoesKeeps raw evidence untouched, applies cleaning and reshaping in recorded steps, enforces data-quality checks on every build, and traces every figure back to its source.
{{ L.tag }} {{ L.name }}
{{ stackActive.tag }} {{ stackActive.name }}
{{ stackActive.desc }}
Sends → {{ stackActive.to }} {{ stackActive.contract }}
Interfaces

Clean contracts between layers

Model → Foundry

Each run delivers a fixed output pack: a run record, capital breakdowns, reconciliation checks, reinsurance summaries, tail diagnostics and simulation-level results. Every row is stamped with its run ID, so nothing can be mixed up between runs.

Foundry → STEER

Curated tables become business objects that people can navigate and act on. High-volume data, such as 50,000 simulated years broken down by class and risk, stays in scalable datasets. Only the things people make decisions about become objects.

STEER → Model

A versioned run request records the scenario, the model version and the requester. The model runs in the background, and STEER shows its real status at every stage rather than a loading spinner.

Integration

What it takes to connect

Model environments
STEER is designed around Python-based Internal Models, which can run directly on Foundry compute through a thin adapter, with no rewrite. Models that run elsewhere connect through a standard per-run output pack, so STEER can govern their results from day one.
Data onboarding
Exposure, claims, market and reinsurance data land as versioned raw datasets. They are typed and checked in recorded pipelines, then mapped to business objects. Start with one governed run and add sources as you go.
Deployment
STEER runs inside your own Foundry environment. Hosting, data residency and tenancy follow your existing Foundry arrangements, so your data stays inside the perimeter you have already approved.
Security
Access follows Foundry’s project roles, so viewing, editing and approving are separate permissions. Approval actions are restricted to named roles, and every change to a record is logged with the user and time. STEER inherits Foundry’s platform security rather than adding a new perimeter to assess.

No rip and replace.

STEER is purpose-built for capital decisions. It is not a pricing tool bent into shape, and not a reason to rebuild your model.

Delivery

Implementation path

Each phase delivers value on its own, and your model keeps running throughout.

  1. 1ConnectLoad existing governed runs into Foundry. Your model keeps running where it does today.
  2. 2GovernAdd data checks, lineage and business objects. Every run becomes traceable.
  3. 3OperatePut scenario comparison, decision records and approval workflow into live use.
  4. 4ExtendRun the model on Foundry, request governed runs from the meeting, and add portfolio steering.
Walkthrough deck

The same build, slide by slide.

Seventeen slides following the STEER Foundry Implementation Handbook: architecture rules, the data layer, ontology, Workshop, governed execution and the roadmap. Speaker notes included.