FDE Learning Path: 24-Week Standard Track

The FDE referred to on this page is Forward Deployed Engineer (前沿部署工程师 / 前线部署工程师), not Full Disk Encryption. This is not a checklist of "learn the technical buzzwords and you can apply": the core of the role is turning ambiguous problems into systems that can be accepted, operated, and handed over, on-site at customers or in near-customer environments.

Palantir's FDSE job description emphasizes end-to-end execution, customer collaboration, architecture design, data processing, and deployment; Anthropic's FDE job description further emphasizes production-grade LLM applications, MCP, evals, enterprise deployment, and continuous discovery of opportunities. Therefore, this track is organized around deliverable evidence, not around hours of course watching.

Course North Star: Strategy, Frontline, and Engineering Must Be Connected

Title "Course North Star: Strategy, Frontline, and Engineering Must Be Connected"

The direction of this track does not change with technology trends. By the end, learners must be able to do all of the following:

• Understand business upward: discuss with business decision-makers why now, what decision it supports, how value is realized, and what risks are unacceptable;
• Go down to the frontline: walk real tasks with frontline staff, recording system usage, judgments, workarounds, anomalies, rework, and accountability;
• Do the engineering hands-on: turn traceable evidence from both sides into data, permissions, implementation, evals, deployment, operations, and handover.

All weeks follow this rule:

战略目标 → 业务决定与价值机制 → 一线任务与异常 → 证据与约束         → 工程取舍与交付 → 采用、运营、交接与产品反馈

The boss's requirements cannot directly become facts, frontline complaints cannot directly become features, and trending technologies cannot directly become course goals. Unless the course owner explicitly changes direction, subsequent content can only refine this page's North Star, phase order, and evidence thresholds — never bypass them.

Who This Is For

Title "Who This Is For"

This track uses 24 weeks as the standard; it is compressed to 20 weeks or extended to 28 weeks only when the corresponding prerequisites are met. It assumes you can already:

• Independently build a small-to-medium service in Python, TypeScript, Java, or a similar language;
• Use Git, and understand HTTP APIs, SQL, basic testing, and the command line;
• Read English technical documentation, and are willing to interview real users;
• Commit a steady 8–12 hours per week.

If you cannot yet independently write an API, design data tables, or debug common runtime errors, first fill in your software engineering fundamentals. FDE is not an AI shortcut around engineering fundamentals.

Evidence You Should Produce by Graduation

Title "Evidence You Should Produce by Graduation"

Completion is marked not by "having watched everything," but by the following evidence appearing together in your portfolio:

• A Discovery Brief based on real or credible simulated interviews, covering the current state, users, constraints, success metrics, and non-goals;
• A deployable system, including authentication and authorization, data boundaries, automated tests, release and rollback;
• A versioned eval set, plus baseline, improvement, and failure sample analysis;
• A threat model covering prompt injection, unauthorized access, tool misuse, secret leakage, and replay;
• Observability and operations evidence: logs, metrics, traces, SLOs, alerting, and incident drills;
• A customer-facing demo, a launch decision, an operations manual, and handover records.

You can choose exercises from the project overview; in the end you must complete the "Enterprise RAG + MCP Assistant" Capstone.

First Choose Your Pace

Title "First Choose Your Pace"

What gets compressed is the number of exercises and parallelization, not the acceptance criteria. If a phase is not passed, do not pretend to have graduated based on calendar dates.

The 24-Week Standard Track

Title "The 24-Week Standard Track"

Published Tutorial Index

Title "Published Tutorial Index"

Weeks 1–24 have all been expanded into tutorials that learners can follow step by step. The engineering tutorials from Week 5 onward provide complete behavioral contracts, synthetic inputs, expected states, failure recovery, and acceptance criteria, but the repository currently does not include code starters for a fixed tech stack; you need to complete the implementation with a tech stack you know, and keep your actual results separate from the synthetic completion examples in the pages. Week 24 counts as complete only when the evidence thresholds are passed; calendar dates cannot cover up

NO-GO

incomplete items.

Week 1: Establish the baseline and target roles

Title "Week 1: Establish the baseline and target roles"

Official tutorial: Week 1: Lock in the target role and the two-layer conversation baseline. This week, incorporate both "being able to discuss strategic outcomes with business decision-makers" and "being able to reconstruct real processes with frontline staff" into the capability baseline, but do not start system design early.

Choose an industry scenario, such as customer service, supply chain, financial operations, or R&D knowledge management. Collect 5–10 target job descriptions and use a single table to annotate recurring capabilities, evidence, and experience gaps.

Deliverables for this week:

• Target role card: company, role type, customer audience, tech stack, and delivery method;
• Capability gap table: current evidence, gaps, and planned ways to close them;
• A measurable graduation goal, such as "being able to demonstrate a complete project from problem discovery to launch handover in 20 minutes."

Passing threshold: every learning topic maps to a job requirement or a Capstone deliverable; delete anything that "might be useful but cannot prove value."

Weeks 2–4: Customer discovery and problem definition

Title "Weeks 2–4: Customer discovery and problem definition"

Start with Week 2: Connecting strategic goals with real frontline work. Week 2 only completes the first cross-layer evidence loop; Weeks 3–4 continue with follow-up interviews, data verification, and forming the final

Discovery Brief

。

The starting point of an FDE is not the model, but the business decision. Interview 3–5 target users; if you cannot reach enterprise users, substitute open-source community maintainers, small team leads, or people with similar processes, and make clear this is a simulated environment.

Exercise content:

• Interview the current process, pain point frequency, existing alternatives, decision-makers, and sources of resistance;
• Map the current process and the target process, marking data sources, manual handoffs, and failure points;
• Rewrite "build an AI assistant" into business outcomes, leading indicators, lagging indicators, and guardrail metrics;
• Clarify non-goals, data constraints, budget, timeline, and the launch decision-maker.

Deliverables for this phase: interview notes, stakeholder map, process diagrams,

Discovery Brief

, risk register, and acceptance draft.

Passing threshold: someone unfamiliar with the implementation details can judge whether the project is worth doing; success metrics do not rely on vague statements like "users think it's smart."

Weeks 5–8: Data and application engineering foundation

Title "Weeks 5–8: Data and application engineering foundation"

Use ordinary software to first complete a verifiable business loop, then decide where the model should intervene. Build a modular monolith rather than splitting into microservices for the sake of a portfolio.

Exercise content:

• Design versioned APIs, relational data models, migrations, and idempotent writes;
• Integrate authentication and enforce role- or attribute-based authorization on the server side;
• Build data ingestion, quality validation, lineage, and failure replay;
• Write unit, integration, and end-to-end tests;
• Use containers, CI/CD, and isolated environments to achieve repeatable deployments;
• Generate structured logs, basic metrics, and correlation IDs from day one.

Deliverables for this phase: deployable application, API contracts, data dictionary, test reports, deployment instructions, and a one-page ADR.

Passing threshold: a new environment can be deployed following the documentation; repeated requests do not produce duplicate business outcomes; unauthorized users cannot escalate privileges by merely modifying frontend requests.

Weeks 9–12: RAG baseline and evals

Title "Weeks 9–12: RAG baseline and evals"

First build a naive, measurable retrieval baseline, then introduce complex orchestration. Do not just show three successful questions.

Exercise content:

• Define document sources, update frequency, owners, retention policies, and access control metadata;
• Compare keyword, vector, or hybrid retrieval, and record chunking, ranking, and filtering strategies;
• Build an eval set containing answerable, unanswerable, permission-restricted, conflicting, and outdated information;
• Measure retrieval, answering, citations, refusals, and end-to-end task success separately;
• Save failure samples, and record the hypothesis, cost, latency, and quality results of every change.

Deliverables for this phase: versioned corpus documentation, retrieval baseline, at least 60 representative eval samples, eval script interfaces, and the first results report.

Passing threshold: you can explain "whether the failure occurred in retrieval, context, generation, permissions, or the product flow," rather than just tweaking prompts and hoping for luck.

Weeks 13–15: MCP, tools, and security boundaries

Title "Weeks 13–15: MCP, tools, and security boundaries"

MCP standardizes capability exchange between hosts, clients, and servers, but it does not replace authorization, approval, scheduling, or completion verification. Use a controlled host, implement read-only tools first, then implement one write tool that requires approval.

Exercise content:

• Define closed input schemas, versions, timeouts, result limits, and typed errors for tools;
• Execute policy decisions outside the model; normalize parameters before authorization;
• Bind approvals to user, run, tool version, parameter digest, scope, and validity period;
• Use idempotency keys, audit records, and recovery plans for write operations;
• Treat retrieved content, MCP descriptions, and tool results as untrusted data;
• Pin server identity and version, and rehearse schema changes, revocation, and connection failures.

Deliverables for this phase: tool catalog, permission matrix, threat model, approval flow, audit samples, and an adversarial test set.

Passing threshold: a malicious document cannot grant tool permissions; without explicit authorization, the system can only preview write operations and cannot produce external effects.

Weeks 16–18: Productionization and operations

Title "Weeks 16–18: Productionization and operations"

Treat the system as a service that others must be able to operate. Design timeouts, retries, degradation, and kill switches separately for the model, retrieval, database, and MCP dependencies.

Exercise content:

• Define SLOs oriented toward user outcomes, not just whether servers are alive;
• Build a trace spanning request, model, retrieval, policy, tool, approval, and verification;
• Track success rate, p50/p95/p99 latency, cost, refusals, privilege escalation attempts, and duplicate effects;
• Rehearse model unavailability, stale indexes, MCP failures, cost overruns, and sensitive information leaking into logs;
• Create release gates, canary rollout plans, automatic rollback signals, and an operations manual.

Deliverables for this phase: SLOs, dashboards, alerts, failure drill records, rollback plans, cost budgets, and a runbook.

Passing threshold: with the model or MCP turned off, users receive a clear, predictable degraded outcome; operators can reconstruct from a single

run_id

what happened.

Weeks 19–24: Enterprise RAG + MCP Capstone

Title "Weeks 19–24: Enterprise RAG + MCP Capstone"

Complete the Enterprise RAG + MCP Project Brief. Don't start from a blank technical plan: carry over the customer problems, data contracts, evals, security controls, and operations baseline produced earlier.

Suggested cadence:

The final review must include a failure demo: show how the system rejects unauthorized questions, blocks unapproved write operations, or degrades safely when a dependency fails.

How to compress to 20 weeks

Heading "How to compress to 20 weeks"

Only content validated through diagnostics can be compressed:

If you also need to learn auth, database migrations, containers, or CI/CD along the way, 20 weeks is not a realistic plan.

How to extend to 28 weeks

Heading "How to extend to 28 weeks"

The 28-week roadmap equals the full 24-week standard roadmap plus weeks 25–28 reinforcement. Fill exactly one evidence gap per week:

• Week 25, multi-tenancy and permissions reinforcement: cross-tenant testing, cache key audits, and audit retention;
• Week 26, data quality reinforcement: incremental updates, staleness detection, rebuilds, and recovery drills;
• Week 27, security reinforcement: document poisoning, parameter smuggling, approval confusion, and secret leakage drills;
• Week 28, real pilot reinforcement: at least two rounds of user feedback, before-and-after metrics, and handover follow-ups.

Weekly working rhythm

Heading "Weekly working rhythm"

Allocate time by delivered value: roughly 60% building and testing, 20% user interviews and feedback, 10% evals and retrospectives, 10% writing docs and demos. At the end of each week, answer four questions:

• Which user or technical hypothesis did you validate this week?
• What evidence supports or refutes it?
• What is the biggest risk right now?
• What is the smallest, acceptable deliverable for next week?

Authoritative sources and verification record

Heading "Authoritative sources and verification record"

All pages below were verified on 2026-08-19. Role pages change over time, so check them again when using them.

• Palantir: Forward Deployed Software Engineer — end-to-end projects, customer collaboration, architecture, data, and deployment responsibilities.
• Palantir: Forward Deployed AI Engineer — LLM solutions, machine learning fundamentals, evals, and engineering requirements.
• Anthropic: Forward Deployed Engineer — production applications, MCP, Agent Skills, enterprise deployment, customer discovery, and delivery models.
• Model Context Protocol: Architecture — MCP hosts, clients, servers, and protocol boundaries; at verification time, latest corresponded to the 2026-07-28 version.
• NIST: AI RMF Generative AI Profile — a reference for generative AI risk identification and governance.

The week counts, sample sizes, and project gates in this roadmap are course design targets, not a unified industry standard published by any organization, and they do not constitute any commitment regarding hiring, salary, or employment.