the framework
The Applied AI Book
From the book
Forward Deployed covers this framework end to end, with Palantir as the case study — from finding the real problem to owning the handoff into daily production use.
Buy on Amazon →This is a framework for applied AI — the seven steps that decide whether an AI effort ends in something people use every day or in another demo nobody adopted. Almost none of it is about the model. The model is the part that already works. What determines the outcome is whether you found a real problem, whether you can measure it, whether you found the cause rather than a pattern, and whether the work you just did makes the next round cheaper.
Forward Deployed covers this whole framework as one continuous argument, with Palantir as the case study and a single deployment followed from the first conversation to daily use. This page is the skeleton of it. Against several of the steps below there is one book that goes deeper on that step than any general book can. Some steps have no book, because nothing published does the job better than the plain explanation.
- 01
Signal — where problems come from
Most applied-AI work begins with a solution somebody has already chosen. The first move is to go back and find the problem, and the problem is usually already being reported somewhere in the organization, inside documents nobody reads as a list of problems. There are five lenses. Each one detects a different kind of trouble, and each has its own paperwork.
- Strategic gaps — results diverging from goals. Found in board decks, OKR reviews, quarterly business reviews, financial reports.
- Operational friction — work that does not flow. Found in support tickets, incident reports, runbooks, SLA dashboards.
- Data anomalies — behaviour that stops matching the expected pattern. Found in cohort dashboards, segmentation reports, growth analytics.
- Systemic risks — signs the system is becoming unsafe. Found in fraud dashboards, compliance reports, dispute and chargeback monitoring.
- Hidden opportunities — unmet demand rather than a fault. Found in customer interviews, frontline feedback, partner conversations.
Two things are worth knowing before you start looking. In less mature organizations several of these artifacts do not exist, or live informally in one person's head. That absence is itself a finding, and it usually tells you what the first version of the work has to build. And of the five lenses, anomalies and risks tend to produce the most valuable work. A strategic gap is already on a slide, which means it is already being argued about by people more senior than you. An anomaly is a fact nobody has explained yet.
- 02
Expand — map the whole problem before you touch any of it
Take the candidate and write it as a single sentence describing the unwanted outcome. Then decompose it. Fault Tree Analysis breaks that outcome into branches, breaks each branch into narrower causes, and keeps going until it reaches events specific enough to measure. The technique came out of Bell Laboratories in 1962, built for the US Air Force to map every way a missile launch control system could fail before any of it was built.
It pays for itself twice. First, it forces you to write down the explanations you do not believe, which is the only reliable defence against confirmation bias — the most common way an investigation ends early with a confident wrong answer. Second, the bottom of the tree is your metric list. The map is an instrumentation plan, not documentation, and that is what separates depth from analysis paralysis. Without it, the investigation that follows is a search with no map of the territory.
- 03
Narrow — choose one
The lenses and the tree generate more candidates than any team can work. Choosing between them needs a filter, not a meeting. Three questions do it. Impact: if this were fixed, what changes, and by how much? Controllability: can this team actually change it, or does it sit with a regulator, a partner, or another company? Observability: can it be seen in data that already exists?
Observability is the question teams skip and the one that decides the outcome. If measuring the problem is itself a six-month project, you will never be able to show that the work moved anything, and inside an organization deciding whether to fund the next phase, unmeasurable success is indistinguishable from failure. A high-impact problem you cannot observe is a second or third use case. It is never a first one.
Read deeper
Evidence-Guided: Creating High Impact Products in the Face of Uncertainty
Itamar Gilad · 2023
Gilad's subject is exactly this step: how to rank competing ideas by the evidence behind them rather than by who proposed them, and how to keep raising confidence cheaply before committing real money. It is the discipline that stops the loudest candidate winning the slot.
View on Amazon → - 04
Prove — instrument, then investigate
Instrumentation turns each event at the bottom of the tree into a definition: what it means, how it is measured, and which system it comes from. The definitions are the durable artifact; the queries are disposable. Any ambiguity left in a definition here comes back later as an argument about whether the result is real, at the exact moment you need the result to settle something.
Then the investigation runs from two directions at once. The fault tree is top-down and deductive — these are the failure modes I expect. Clustering is bottom-up and inductive — these are the groups the data actually forms. Profile each cluster against the events from the tree and the tree becomes a labelling dictionary for clusters that otherwise mean nothing. A cluster matching no branch is a failure mode you never hypothesised. A branch matching no cluster is either good news or a hole in your features. This only works if both share a vocabulary, which is why the tree should drive the feature engineering rather than arrive after it. The tree defines what you are looking for, the data shows what is there, and the gap between them is where the learning is.
Read deeper
How to Measure Anything: Finding the Value of Intangibles in Business
Douglas W. Hubbard · Wiley, 3rd edition 2014
The objection that something cannot be measured arrives at precisely this step, and it is usually accepted. Hubbard's answer is that immeasurability is a claim about effort and imagination, not about the thing, and he supplies the methods for the cases that look hopeless.
View on Amazon → - 05
The 5 Whys — a pattern is not a cause
Investigation produces patterns. A pattern describes what the data looks like. A cause is the mechanism producing it. You cannot intervene on a description, and teams that ship at this point build something that correlates with the problem and moves nothing. The 5 Whys, from Sakichi Toyoda and Taiichi Ohno at Toyota, is the discipline for closing that gap: keep asking why until the answer is a mechanism somebody can change.
It pairs with step two. The fault tree maps the entire failure space; the 5 Whys drives depth down a single path. Run it on several paths and they frequently converge on the same root cause, and that convergence point is the thing worth building against, because fixing it closes several branches at once. Most of the answers come from people rather than queries, which is where the method quietly fails — asked badly, people answer the question they think you want answered.
Read deeper
The Mom Test
Rob Fitzpatrick · 2013
The shortest usable guide to conversations that produce facts instead of encouragement. Ask about what people already do rather than about whether your explanation sounds right, and the whys return mechanisms rather than politeness.
View on Amazon → - 06
Act, then decide
The intervention runs as an experiment: treatment group, control group, a success metric, and guardrail metrics. The guardrails are what determine whether a success is real, because an intervention can move its target and damage something next to it at the same time. Then monitoring, and one of three decisions — scale it, iterate on it, or stop. Stopping is the cheapest outcome available and the one teams take least often.
None of this needs a platform. It needs seven artifacts: a north-star metric, a system health dashboard, a problem backlog, the fault tree, metric definitions, a hypothesis log, and an experiment record. Seven files, and the loop holds together. Where organizations fail, they fail by breaking a specific link: endless analysis because nothing is ever tested, random experiments because the problem space was never structured, missed anomalies because observability was never built, and repeated mistakes because nothing was written down.
- 07
Compound
Everything above is one turn of a loop. Whether a team gets faster or stays where it is depends on one thing: does each turn make the next one cheaper? Every's compound engineering states it plainly — each unit of work should make subsequent units easier, and the loop runs plan, work, review, compound. The fourth step is the one that gets dropped under deadline, and dropping it leaves you doing ordinary work with AI assistance.
In practice compounding means putting judgment into the system instead of into review, so standards live in configuration, schemas and automated checks rather than in one person's inspection. It means teaching the system rather than doing the work, because context you give an agent pays off repeatedly while work you type solves only the task in front of you. It means building safety nets rather than review processes. And it means treating the plan as the primary artifact, since fixing an idea on paper costs almost nothing compared with fixing it in production. The allocation that makes it real is roughly half your time on the work and half on the system that makes the next round faster. Most teams run ninety-ten and treat the remaining tenth as a distraction, which is exactly why their tenth deployment costs what their first one did.
Who this is for
The person accountable for making AI deliver inside an organization that already exists — with legacy systems, a compliance function, and people whose jobs change if the thing works. Operators and product leaders handed a stalled programme. Engineers who have realised the hard part is not the model. Teams and educators running applied-AI programmes who want a transferable framework rather than another demo.
It is not for you if you want model architecture, prompt technique, or benchmark results — none of that is here. It is also not an ethics or policy book about Palantir. Those are real debates, and this is not the work making them.
Where the framework comes from
Forward Deployed is written by Riste Gramatikov as an independent analysis of the Palantir operating model, drawn from Palantir's own engineering writing, public sources, and the deployment patterns that repeatedly get AI into production. It is not authorized or sponsored by Palantir. The case study running through it is a composite, built from real implementations and labelled as such wherever it appears, because a composite can be followed all the way down to the furnace reading and the approval gate, which a real client reference never permits.
The books above are the specialised layer. The five books Palantir gives new hires covers the cultural half of the same problem, and the forward deployed engineer reading list collects the primary sources behind the role itself.
Forward Deployed runs the whole framework end to end on one deployment — the forward-deployed model, the deployment discipline, stakeholder sequencing, and the platform architecture that makes each deployment cheaper than the last.