Glossary — The Forward Deployed Engineer Track

Forward Deployed Engineer — FDE: An engineer who embeds with a customer and builds production software directly on that customer's problems — "half engineer, half consultant, full owner." Unlike a product engineer (one capability for many customers), an FDE enables many capabilities for a single customer. In 2026 the role centers on deploying AI systems: prototypes, agents, integrations, and the evals that prove they work.
FDSE — Forward Deployed Software Engineer: Palantir's original name for the role (internally "Deltas"), embedded on customer sites configuring and extending the product against real operational problems. The template every AI-era FDE role descends from.
Solutions architect — SA, vs FDE: A customer-facing technical role that advises, designs, and demos — but typically does not write production code on customer infrastructure. The FDE boundary line: an FDE ships working code into the customer's world; an SA guides someone else's hands.
AI judgment: The competency of telling when AI is the wrong answer — recognizing that models are persuasive even when incorrect, and having the courage to say so to a customer. A named thread of this course: it shows up in scoping ("don't build this"), in hardening (confidently-wrong outputs), and in the capstone's required "what we recommended NOT to build" section.
Problem discovery: Finding the real problem behind what the customer asks for — separating what they think they want from what they actually need, then articulating it clearly. The make-or-break FDE interview round (often called the decomposition round), and the fastest-growing requirement in FDE job postings.
The deployment gap: The 2026 finding, from an analysis of 1,000 FDE job posts, that ~95% of enterprise GenAI pilots show no measurable impact — model capability isn't the bottleneck, deployment is. The market force behind FDE hiring: someone has to close the gap between what models can do and what actually ships inside an enterprise.
Field practice: The small real-workplace reps at the end of every lesson: asking "why" before a ticket, volunteering for unscoped work, explaining a trade-off to a non-technical colleague. Labs simulate FDE work; field practice builds the same muscles inside the job you already have.
Portfolio artifact: The tangible output of each lab — working code, an eval harness, a demo, a scoping doc — accumulated in your portfolio repo. Each doubles as hiring evidence and an interview story; the capstone assembles them into a full engagement case study.
Context engineering: Deliberately curating everything the model sees — instructions, retrieved documents, tool definitions, history — treating the context window as a finite budget. Subsumes prompt engineering: the question shifts from "what do I say?" to "what does the model need in view, and what must stay out?"
Agent — vs workflow: An LLM system that directs its own tool use in a loop to pursue a goal, versus a workflow where code orchestrates fixed LLM steps. The canonical guidance: use the simplest thing that works — workflows for predictable tasks, agents where paths can't be enumerated in advance.
MCP — Model Context Protocol: The open protocol for connecting AI applications to tools and data sources through a standard interface. For an FDE, MCP servers are the integration seam: wrap the customer's messy systems once, and any MCP-capable model or app can use them.
RAG — retrieval-augmented generation: Answering with the model grounded in retrieved documents rather than parametric memory. Quality lives in the retrieval half — chunking, contextual retrieval, reranking — not the generation half. Not always the right tool: sometimes long context, tools, or "don't use AI" wins.
Grounding: Constraining model output to verifiable sources — mandatory citations, direct quotes, and an explicit "allow I don't know" escape hatch. The primary defense against hallucination in customer-facing systems.
Eval — evaluation: A repeatable, graded test of an LLM system against defined success criteria — exact-match checks, similarity scores, or an LLM judge. The FDE's real deliverable: a demo shows it can work once; an eval proves it keeps working. Evals gate every change made in the field.
LLM-as-judge: Using a model to grade another model's outputs against a rubric. Powerful and dangerous: the judge must itself be validated against human judgments (critique shadowing) before its scores mean anything.
Guardrail: A layer that constrains what goes into or comes out of a model — input filtering, output validation, citation checks, human-in-the-loop gates. Placed around the model because prompting alone cannot make a persuasive model safe.
Prompt injection: Adversarial instructions smuggled into content the model processes — a document, an email, a tool result — that hijack its behavior. The signature security failure of LLM systems, and unsolved in the general case: assume any untrusted content the model reads is potentially hostile.
Synthetic data: Model-generated data shaped like the customer's real data — fake patient records, consult transcripts, claims. A core FDE skill: you rarely get production data in week one, and regulated domains may never hand it over. You demo and eval on synthetic data that is realistic where it matters.
Engagement: The full arc of FDE fieldwork with one customer: discovery → scoping → prototype → evals → hardening → deployment → case study. The capstone runs one end-to-end for a fictional virtual-care provider.

Context rot

The gradual degradation of model quality as a conversation grows long — older, less-relevant turns crowd out the instructions and data the model actually needs. The fix is deliberate context management: summarise, trim, or re-inject rather than letting the window fill passively.

Compaction

Replacing earlier conversation turns with a summary to free context-window space without discarding all prior information. A technique for long-running agents and multi-turn workflows where verbatim history is too expensive to keep in view.

Tool schema

The JSON description — name, description, parameter types and constraints — that tells a model what a tool does, when to call it, and how to pass arguments. The tool schema is an engineering artifact: vague descriptions produce wrong calls; tight descriptions produce reliable ones.

Sub-agent

An agent spawned by a parent orchestrator to handle a scoped sub-task. The parent delegates and waits; the sub-agent has its own context, tools, and goal. Useful for parallelism and specialisation, but each hop adds latency and a new failure point — add them only when a single agent genuinely can't do the job.

Chunking

Splitting source documents into pieces small enough to embed and retrieve. Chunk size is a retrieval knob: too large and retrieved chunks carry irrelevant noise; too small and individual chunks lose context. Good chunking respects document structure (sections, paragraphs) rather than naive character counts.

Contextual retrieval

Prepending a short document-level summary to each chunk before embedding, so that retrieval scores reflect the chunk's meaning in context rather than its isolated text. Anthropic's technique; reduces retrieval failures on chunks that only make sense relative to the surrounding document.

Reranking

A second-pass scoring step that takes the top-K vector-search results and re-orders them with a cross-encoder or LLM judge more accurate than the initial embedding similarity. Retrieval pipelines that skip reranking routinely promote plausible-but-wrong chunks into the context window.

Critique shadowing

Validating an LLM judge by comparing its scores to human judgements on the same set of examples. A judge that hasn't been critique-shadowed is an unvalidated black box — it can appear to gate quality while systematically missing the failures that matter most.

Eval set

The curated collection of inputs (and expected outputs or rubrics) against which an LLM system is measured. A good eval set is representative, adversarial where appropriate, and held back from prompt-tuning so it can catch regressions honestly. Writing the eval set is often more important than writing the prompt.

Regression gate

An automated check that blocks a change from shipping if it causes eval scores to fall below a threshold. The engineering practice that makes fast iteration safe: without a regression gate, every prompt tweak is a gamble on what it broke.

Vertical slice

A thin end-to-end path through a system — one real user action, one real data source, one real output — that proves the architecture works before broad feature coverage. The antidote to demo theatre: if the slice doesn't work, nothing else matters yet.

Demo script

A prepared, rehearsed run-through of the happy path — specific inputs chosen to land the key insight cleanly. Not the same as "fake demo": the system is real; the inputs are curated. A good demo script is written before the demo is built, because it doubles as a product spec.

Data-quality triage

The week-one FDE practice of rapidly profiling a customer's data sources for missing values, inconsistent formats, stale records, and PII exposure — before promising what the AI can do with it. Data quality is the most common reason a pilot stalls; triage it early.

PII minimisation

The practice of keeping personally identifiable information out of model context unless strictly necessary — masking, pseudonymising, or stripping fields before embedding or prompting. Essential in regulated domains (healthcare, finance) and a default hygiene practice everywhere else.

Lethal trifecta

The three conditions that together make prompt injection catastrophic: the model has access to sensitive data, the model can take irreversible actions, and the model processes untrusted content. Any system that checks all three boxes needs layered guardrails and human-in-the-loop gates before it ships.

Tracing

Recording every step of an LLM system's execution — prompts, tool calls, token counts, latencies, outputs — so that unknown failures can be reproduced and diagnosed. Without traces, debugging a production LLM system is guesswork. Langfuse is the course's example tracing tool.

Prompt caching

Reusing a cached prefix — system prompt, long document, few-shot examples — across multiple requests so those tokens are not re-processed and re-billed each time. Anthropic's prompt caching can cut costs by 90 % on repetitive-prefix workloads; the cache is keyed to the exact byte sequence of the prefix.

Model routing

Directing each query to the cheapest model capable of handling it — small/fast models for simple classification, larger models only for complex reasoning. A cost-latency pattern: routing decisions are themselves a system engineering choice and must be gated by evals to ensure the cheaper model actually meets the bar.

Latency budget

The maximum acceptable end-to-end response time for a user-facing LLM feature, broken down by component (retrieval, model call, post-processing). Setting an explicit budget forces trade-off decisions — streaming, caching, model tier — before they become production fires.

Scoping doc

A short written artefact that pins what is being built, what is explicitly out of scope, the success criteria, and the timeline — agreed with the customer before code is written. The FDE's primary tool for preventing scope creep and aligning stakeholders on what "done" means.

Decomposition round

The FDE interview format where a candidate is given a vague customer problem and must break it down live — clarifying questions, sub-problems, trade-offs, build-vs- buy calls — without being told the right answer in advance. Tests whether the candidate can run discovery under pressure, which is the core FDE skill.

Stakeholder map

A lightweight artefact identifying who is affected by a deployment, who must approve it, and who can block it — champion, buyer, end users, security/compliance, and any veto holders. Skipping the stakeholder map is the fastest way to get a working prototype killed at the last meeting.

Case study

A written account of a complete FDE engagement: the problem, the prototype built, the eval evidence, the hardening decisions, the outcome, and — critically — what was recommended NOT to build. The capstone artefact and the standard currency of FDE interviews: "walk me through an engagement."

Acceptance evidence

The eval results, demo recordings, or other artefacts that prove to a customer that a delivered system meets the agreed success criteria. Without acceptance evidence, "it's done" is a claim; with it, "it's done" is a proof.

Take-home

An FDE interview assignment completed outside the live session — typically a scoping doc, a working prototype, or an eval harness built against a provided scenario. Evaluated on problem framing and judgment, not just code correctness.

Engagement story

A structured narrative about a past (or capstone) FDE engagement, shaped for an interview: problem → approach → trade-offs → outcome → what you'd do differently. The format interviewers expect when they ask "walk me through a project."

Fine-tuning

Updating a model's weights on task-specific examples to change its default behaviour — as opposed to prompting, which steers an unchanged model at runtime. Warranted when prompt engineering is exhausted, latency or cost requires a smaller model, and a large, clean dataset exists. Not a shortcut: fine-tuning requires maintaining a separate model and a robust eval suite to catch regressions.

Source hygiene

The practice of knowing, tracking, and controlling what goes into a model's training data or retrieval index — provenance, licences, staleness, and PII exposure. Poor source hygiene produces models or retrieval systems that confidently cite outdated, biased, or legally problematic material.

Orchestrator–worker pattern

A multi-agent architecture where one orchestrator agent breaks down a goal and delegates sub-tasks to specialised worker agents. The orchestrator owns the plan and synthesises results; workers own execution. Justified when tasks are genuinely parallel or require different capabilities — not as a default structure for every workflow.