Forward deployed engineering glossary
56 terms, from the first week on the floor to the system still in use months later. Each has one sentence anyone can repeat, and the detail an engineer would check.
Written by the Verne engineering team.
Last reviewed
Forward deployed engineering (FDE)
A way of delivering software in which engineers work inside the client’s operation, build with its data and people, and leave when the client’s team can run what they built.
The model · related to 3 terms
56 terms
The model
Who does the work and how it is judged
- Forward deployed engineering (FDE) Also: forward-deployed engineering, FDE
A way of delivering software in which engineers work inside the client’s operation, build with its data and people, and leave when the client’s team can run what they built.
Technically A small team owns the path from discovery to production for one workflow, with production access inside an agreed decision boundary, and transfers operation against tested criteria.
- Forward deployed engineer Also: forward-deployed engineer, FDE engineer
An engineer who sits with the people doing the work, writes production code against what they find, and teaches the client’s team to run it.
Technically Combines software engineering, integration with the systems already in place, and domain discovery. Works one customer across many capabilities, where a core product engineer works one capability across many customers.
- Dev and Delta
Palantir’s internal names for its two engineering roles: Dev engineers build the core product, Delta engineers deploy it inside customers.
Technically The split the role is named after. Dev optimises one capability for every customer; Delta makes the whole product work for one customer, then feeds what it learns back to Dev.
- FDE squad Also: FDE pod, forward deployed team
The small team on one engagement: a lead engineer and engineers, with a designer, analyst or growth specialist when the work needs one.
Technically Roles cover domain translation, integration with existing systems and architecture. On a small engagement one person holds two of them. Verne sizes squads at two to six people.
- Decision boundary
The written line between what the engineers decide alone and what needs the client’s approval.
Technically Engineers choose libraries, models and first-week fixes. Schema changes in production, data leaving agreed systems and any change to budget need written client approval.
- Passive outsourcing
Building to a specification and billing for it, whether or not anyone uses the result. FDE measures success by daily use instead.
Technically Acceptance rests on a sign-off against the specification. In FDE, acceptance rests on adoption measures and a handover test run by the client’s team.
Discover
Learn how the work is really done
- The first 48 hours
Time spent meeting the people who do the work, before any technical discussion. The trust built here decides how much they show you later.
Technically No laptop, no architecture talk: lunch, the floor, the stories about the bad days. The output is a list of who to shadow and who is worried the project threatens their job.
- Psychological safety
The belief that telling the truth about how work is done will not get anyone in trouble. Without it, people show you the official process.
Technically A precondition for discovery. Engineers say what they will not report upward, and findings name steps, never people.
- Shadow session Also: contextual inquiry, job shadowing
Sitting beside someone while they do their job, as an apprentice rather than an inspector, to see the real steps.
Technically Two sessions per role at minimum, at a normal and a busy hour. Watch for double entry between systems, glances at side notes, and the screen that makes people sigh.
- SOP drift
The gap between the written procedure and how the work is really done. The cost usually hides in that gap.
Technically Measured step by step during shadow sessions: each step gets its procedure time and its observed time, and each undocumented shortcut gets written down.
- Shadow IT Also: workarounds, side spreadsheet
The side spreadsheets, chat threads and notebooks staff use because the official system does not fit. Each one marks a gap the new system must close.
Technically Inventoried during discovery with its owner, its inputs and what it decides. A workaround is often the most accurate specification the business has.
- Happy path
The route through a process when nothing goes wrong. Real operations spend much of their time off it, handling exceptions.
Technically Discovery maps the exceptions first: partial deliveries, overrides, missing documents, retries. The design covers the exceptions that cost the most, not only the happy path.
- Time accounting
Timing each step of a process twice: what the procedure says it takes, and what a stopwatch shows.
Technically Observed time per item, multiplied by daily volume, gives minutes lost a day per step. That number ranks the fixes.
- Bottleneck rule
A step that takes at least twice as long as the procedure says is the first candidate to fix.
Technically A manual step over the threshold is a candidate for automation; a system step over it is a candidate for infrastructure or query work.
- As-Is and To-Be maps Also: current state and future state
Today’s process and the target process, drawn side by side so management can see what changes.
Technically Each step carries its owner, its system and its timing. The To-Be map shows which steps disappear, which are automated and which stay with a person.
- Falsifiable success metric
One sentence a clock or a database can prove wrong: success means X falls from A to under B, measured by a named log.
Technically Pairs a baseline with a target and a data source the client already trusts. Phrases like ‘better visibility’ cannot fail, so they cannot succeed either.
- Baseline
The measured value of the metric before anything changes, so the improvement can be proved later.
Technically Taken from the system of record over a representative period, with the query saved so the same measure runs after go-live.
- Quick win
One visible fix shipped in the first week or two, chosen because it removes the most wasted time with the least risk.
Technically Ranked by minutes lost a day, weighted down when the business rules behind the step are unclear. It earns the trust the larger build needs.
- Discovery audit
Eight checks run before anything is built: people, procedure against reality, timings, the metric, privacy rules, network and hardware, the first fix, and the handover plan.
Technically Each check has an owner and evidence. A gap in any of them becomes a named dependency in the plan with a date.
Scope
Agree what phase one covers
- Scope creep
The steady stream of extra requests that stops a project from finishing.
Technically Controlled by testing each request against the agreed metric, not by refusing requests.
- Scope boundary Also: out-of-scope agreement
A one or two page agreement on what phase one covers and what it does not, signed before the build starts.
Technically Lists the workflow, the metric, the systems touched and the exclusions. New requests are checked against the metric; those that do not move it go to the phase-two list.
- Phase-two list
Where good ideas that do not move the agreed metric are parked, with a date and an owner, instead of being turned down.
Technically Reviewed at each weekly demo. It becomes the scope of the next workflow once the first one is handed over.
Deploy
Access, boundaries and where it runs
- Scoped access
Named accounts with only the permissions the work needs, which the client can remove at any time.
Technically Per-person identities, least privilege, production write access only through the deployment pipeline, and an access review at handover.
- On-premises deployment Also: on-prem, offline-first
Running the database, the application and any AI model on the client’s own servers, when privacy rules, unreliable connections or cloud cost require it.
Technically Small quantized language models run on CPU servers for classification and extraction. The system keeps working when the internet link drops and syncs when it returns.
- Hybrid architecture
Sensitive, real-time work stays on site; reporting and public-facing services run in the cloud.
Technically The boundary follows data classification. Only aggregated or approved data crosses it, through one audited path.
Build
One working loop, tested before it ships
- Domain sprint
A short session at the expert’s desk: one real example, the rule behind it, and a test written with the expert’s own numbers before any code.
Technically The expert’s calculation becomes an assert. The code, whether written by an engineer or an agent, must pass it, and the expert checks the output against their own working.
- Guardrails for coding agents
AI coding agents work fast inside three rules: the data schema is locked, nothing new is installed without approval, and the tests are written first.
Technically Typed schemas on every input and output, a dependency allow-list enforced in CI, and test-first prompts. Code that fails the tests is discarded, and an engineer reads every change before it merges.
- Vibe coding
Running code an AI wrote without understanding it. Fine for a prototype, risky in production.
Technically The failure mode guardrails and code review exist to prevent: untested paths, unreviewed dependencies and logic nobody on the team can explain.
- Code drift
The quiet changes a coding agent makes that nobody asked for: a new library, a renamed column, a deleted check.
Technically Caught by schema locks, dependency allow-lists, diff review and tests that pin existing behaviour.
- Evaluation harness Also: eval harness, evals
A test bench for an AI feature that runs on every change to the prompt, the model or the code, so quality never slips unnoticed.
Technically Scores a fixed set of labelled cases on output validity and task accuracy, compares runs item by item, and blocks a release that falls below the ship gate.
- Golden dataset Also: golden set, test set
A set of real, messy examples, labelled by a person, that every version of an AI feature must pass before it ships.
Technically Drawn from production data, including the hard and ambiguous cases. It starts at a few dozen items and grows as reviewers correct the system.
- Eval before build
Build the test for an AI feature before the feature itself, so everyone agrees what ‘working’ means first.
Technically The golden dataset and the scorer exist before the first prompt is written. Prompt and model choices are then made on measured results.
- Ship gate
The score a release must reach on the golden dataset before it goes live, agreed with the client for each workflow.
Technically Typically a hard floor on valid, schema-conforming output and a minimum accuracy per task, enforced in the deployment pipeline.
- Rules first, models second
Rules handle what the business already knows; a model only reads language or images; anything doubtful goes to a person.
Technically Deterministic checks (tolerances, codes, totals) decide. Model output is parsed into a typed record and validated by the same rules before anything is written.
- Three-way match Also: three-way reconciliation
Checking that three documents about the same transaction agree, such as the order, the invoice and the delivery record, and flagging only the ones that do not.
Technically Matched on keys and tolerances the client sets, such as a weight variance under 1% or identical product codes. Mismatches route to a named reviewer.
- Human approval step Also: human in the loop
A point where a named person approves what the system proposes before it takes effect. Nothing that moves money or records ships without one.
Technically The approval binds to the exact action and payload shown to the reviewer, on a screen the model cannot reach, and every decision becomes a test case.
- Idempotent write
A write that can be safely repeated: sending the same invoice twice records it once.
Technically Each write carries an idempotency key, so a retry after a timeout never posts twice to the ERP.
- Self-healing deploy Also: automatic rollback
After each release the system checks its own health, and if the check fails it goes back to the last working version on its own.
Technically The pipeline records the last healthy commit, runs a health check after deploy, and redeploys that commit when the check fails. The database is backed up before any schema change.
Transfer
Your team runs it without us
- Handover test Also: ownership test
The client’s team runs the system for two weeks without help before Verne steps back. The test decides the handover, not the calendar.
Technically Exercises with evidence: ship and roll back a change, investigate a failed job, rotate a credential, restore from backup, using only the runbook.
- Golden handover
Handover treated as a process that starts in week one: a shadow partner, a one-page runbook, a fire drill and a gradual exit.
Technically Ownership moves part by part (code changes, technical decisions, operations, on-call) as each part’s handover test passes.
- Shadow partner
An engineer on the client’s side who works beside Verne’s engineers every day and will own the system afterwards.
Technically Pairs from the first build week, reviews every change, and leads the handover exercises while Verne’s engineer watches.
- Runbook
One page that says how to start and restart the system, where the logs are, the first three things to try when it hangs, and when to call for help.
Technically Versioned with the code, tested in the fire drill, and updated every time someone needed to ask a question it did not answer.
- Fire drill Also: game day
Breaking something on purpose, with permission and a backup, so the client’s team practises bringing it back.
Technically Scheduled outside peak hours: stop a service, push a failing release or restore from backup. Time to recover is recorded as handover evidence.
- Hyper-care Also: hypercare
The first two or three weeks after go-live, when problems are found in the logs and fixed before the client notices them.
Technically Twice-daily checks of health logs, golden-dataset scores and response times, with a short note to the client whenever something was fixed.
- Truck factor Also: bus factor
How many people would have to leave before nobody can run the system. Handover raises it on the client’s side.
Technically Measured per component from who can change, deploy and recover it unaided. A factor of one on any component blocks handover.
- Indispensability trap
Keeping code, passwords or knowledge back so a client cannot leave. Verne hands over the code repository and IP at full delivery.
Technically Avoided by design: client-owned accounts, documented access, credentials rotated at handover, and a runbook the client’s team has tested.
Run
Keep it used, keep it healthy
- Health check
A small script that checks every few minutes that the system is up, has disk space and can reach its model, and raises one alert when something is wrong.
Technically Checks the service endpoint, disk, model service and database response time; alerts once per incident until resolved, and is itself pinged from a second machine.
- Silent failure
A full disk or a stopped service that nobody notices until the work piles up.
Technically Prevented with health checks that alert on absence of data as well as on errors: ‘no data’ never counts as ‘all clear’.
- Silent churn
Staff stop using the new system and go back to the old way without complaining. It shows up in usage data long before anyone says so.
Technically Watched through adoption rate and stagnant days per team, with an alert when either crosses the threshold agreed at handover.
- Adoption rate
The share of the people who should use the system who used it in the last 30 days. It matters more than server uptime.
Technically Active users in the window divided by intended users, reported per team and per role.
- Stagnant days
Days since anyone last entered anything. A rising count means the work has moved somewhere else.
Technically Days since the last transaction per workflow, read from the system of record.
- The 120-day check
A look at real use about four months after go-live. Acceptance sign-off on day one proves little about whether the system is still used.
Technically Reruns the baseline query, the adoption report and a short shadow session, and compares all three with the handover numbers.
- Field-to-core loop
Rules specific to one client go into configuration; logic other clients could use goes into a shared core, which makes the next engagement faster.
Technically Only generic logic moves to the core, never client data, credentials or identifiers, and every client configuration is re-tested against its golden dataset after a core change.
- Configuration-driven core
One engine, one configuration file per client, so a new site or branch is set up rather than rebuilt.
Technically Tolerances, thresholds, codes and routing live in validated configuration; the code path is shared and tested once.
- Pilot purgatory
AI projects that work in a demo and never reach daily use.
Technically Usually caused by missing integration, no owner for the workflow, or no agreed measure of success, which is what discovery and the handover test exist to fix.
- Digital red tape
Putting a broken process on screen without cutting its steps first, so four paper signatures become four clicks.
Technically Avoided by redesigning the To-Be process before automating it: remove steps, then digitise, then automate, and only then add AI where language or images need it.
Keep reading the guide
See the terms at work on one of your workflows
The two-week diagnostic runs the Discover stage on one process, with a written plan and a fixed build price at the end.