The FDE discussed on this page refers to Forward Deployed Engineer, not Full Disk Encryption. An FDE project is not a collection of feature screenshots; a qualified project as defined by this tutorial should answer: why the customer needs it, where the data comes from, what success means, what happens when it fails, who can perform which actions, and who operates it after launch.
It is recommended to complete at least one of the first two projects in order, then complete the Capstone. See the FDE learning roadmap for the full schedule.
How to Choose Among the Three Projects
Heading "How to Choose Among the Three Projects"
| Project | Core Capabilities | Suggested Duration | Relative Difficulty Within the Course | Best for Demonstrating |
|---|---|---|---|---|
| Customer Support Ticket Escalation and Root Cause Workbench | Discovery, data integration, metrics, permissions, application delivery | 3–4 weeks | 2/5 | Turning a vague operational problem into reliable software |
| Supply Chain Anomaly Handling Workflow | Events, rules, approvals, idempotency, recovery, audit | 4–5 weeks | 4/5 | Safely turning recommendations into business actions |
| Enterprise RAG + MCP Assistant | Retrieval, agent tools, evals, security, operations, handover | 6–8 weeks | 5/5 | Full enterprise AI/FDE delivery capability |
All three projects use synthetic data or data you are authorized to make public. Do not put real sensitive information from employers, customers, or individuals into public repositories.
The Evidence Package Shared by All Projects
Heading "The Evidence Package Shared by All Projects"
Whichever project you choose, the repository should include:
- Discovery Brief: users, current process, pain point evidence, constraints, success metrics, and non-goals;
- Data dictionary and data source documentation, including owners, update frequency, quality rules, and retention policies;
- Architecture diagrams, trust boundaries, key ADRs, and rejected alternatives;
- Repeatable deployment and rollback steps;
- Automated tests, acceptance data, and failure samples;
- Threat model, permission matrix, and audit samples;
- SLOs, dashboards, alerts, runbooks, and incident drill records;
- A 5–10 minute demo, launch recommendations, retrospective, and handover checklist.
Project One: Customer Support Ticket Escalation and Root Cause Workbench
Heading "Project One: Customer Support Ticket Escalation and Root Cause Workbench"
Scenario
A B2B software team's tickets are scattered across the support system, product defect tracker, and customer success records. Escalation rules rely on personal experience, and managers don't discover high-risk customers until the weekly meeting. Your task is to deliver a unified workbench that lets support supervisors identify tickets needing escalation, review evidence, and assign owners.
Must Complete
- Interview support representatives, supervisors, and product staff, and document the current escalation process and responsibility boundaries;
- Map at least three synthetic data sources into a unified ticket model, preserving source and update time;
- Build the risk score with transparent rules first; an optional model classifier must not override manual rules;
- Provide queues, filters, evidence details, owner assignment, and status history;
- Implement role-based permissions on the server side, and log every status change;
- Compare the new process with the original using replayed data; do not treat UI completeness as business success.
Acceptance Criteria
- Repeated ingestion of the same batch of inputs must not generate duplicate tickets; the explainable discrepancy between total source counts and the unified model must not exceed the course-set 0.5%;
- Recall on pre-labeled high-risk tickets must reach the target agreed in your Discovery Brief, with false positives reported alongside;
- Regular support agents must not modify restricted tickets owned by others; supervisor actions must record user, time, old value, and new value;
- All five core user tasks have end-to-end tests and one real user walkthrough;
- You can demonstrate prompts, retries, and manual handling paths when data sources are delayed or missing.
0.5%
This is the project target the course uses to force you to do reconciliation, not a general industry benchmark. If business risk is higher, set stricter thresholds with stakeholders.
Project Two: Supply Chain Anomaly Handling Workflow
Heading "Project Two: Supply Chain Anomaly Handling Workflow"
Scenario
A procurement team handles delays, inventory shortages, and price anomalies every day. Multiple systems send duplicate events, and supplier APIs may time out. Your task is not to build a prettier dashboard, but to turn "detect anomaly—collect evidence—recommend action—human approval—execute—reconcile" into a recoverable workflow.
Must Complete
- Define data contracts for anomaly events, handling cases, approvals, external actions, and audit records;
- Use a rules engine to produce deterministic recommendations; models may only interpret or supplement unstructured information;
- Provide a preview for every external action, executing only after approval;
- Handle duplicate or ambiguous-outcome calls with idempotency keys, retry limits, and reconciliation jobs;
- Design states for cancellation, timeout, partial success, and manual takeover;
- Deliver an operations queue, SLOs, alerts, and a runbook for supplier dependency failures.
Acceptance Criteria
- Replaying the same event 10 times generates exactly one valid case and at most one external business effect;
- Approvals are bound to a specific user, case, action, parameter summary, and validity period; old approvals become invalid when parameters change;
- Timeouts, rate limits, deterministic failures, and ambiguous outcomes each receive distinct handling, with no infinite retries;
- Interrupted workflows can be recovered from persisted state, with proof that external effects are not duplicated;
- A manager can reconstruct the request, decision, approval, execution, and reconciliation of an action using a correlation ID.
Project Three: Enterprise RAG + MCP Assistant (Capstone)
Heading "Project Three: Enterprise RAG + MCP Assistant (Capstone)"
Scenario and Boundaries
Heading "Scenario and Boundaries"
Internal employees need cited answers from policies, product manuals, and operating procedures, and need to create service requests when necessary. The system must filter documents by tenant and role; refuse to answer when knowledge is insufficient; and require preview followed by per-action user approval for any write operation.
The goal here is not to build the "most autonomous" agent. The default topology is one agent plus deterministic retrieval, policy, and tools. Only add complexity when evals prove that parallel or multi-agent setups clearly improve quality, isolation, or latency.
See the Enterprise RAG + MCP Project README for the full project contract.
When following the 24-week standard roadmap, start from Week 19 Capstone M0 and continue through Week 24 Controlled Pilot and Handover. Use the same problem contract, corpus version, and risk boundaries for all six weeks; do not switch projects at each milestone.
If your team is evaluating a similar RAG or MCP deployment but cannot yet pin down the scenario, scope, or acceptance criteria, you can book a project diagnosis with your existing process. First determine whether the problem is worth solving, then decide whether to move into prototyping and production delivery.
Required Vertical Slice
Heading "Required Vertical Slice"
- Discovery and scope: three user roles, five high-value tasks, baseline time costs, guardrail metrics, and the go-live decision maker;
- Data and access: document owners, versions, validity dates, tenants, and ACL metadata carried through ingestion, indexing, retrieval, and caching;
- RAG: a reproducible keyword or hybrid retrieval baseline, citations, conflict handling, and refusal to answer;
- MCP tools: at least one read-only tool, one preview tool, and one approved write tool;
- Policy and approval: the model only proposes actions, an external policy component authorizes them, and the executor produces effects;
- Evals and validation: versioned datasets, deterministic checks, calibrated human scoring, and release gates;
- Production operations: tracing, logs, metrics, cost, SLOs, alerting, degradation, rollback, and handover.
Capstone acceptance dataset
Title "Capstone acceptance dataset"
Build at least 100 de-identified or synthetic samples and pin their version:
| Type | Minimum count | Questions to validate |
|---|---|---|
| Answerable questions | 50 | Retrieval, facts, citations, freshness, and multi-document synthesis |
| Unanswerable questions | 20 | Whether the system explicitly refuses rather than fabricating an answer |
| Permission and cross-tenant questions | 15 | Whether filtering is enforced at the data layer and whether caches are isolated |
| Prompt injection and tool abuse | 15 | Whether malicious content can change policy or trigger unauthorized effects |
Each sample must record at least:
case_id
, user/tenant, question, expected sources, allowed outcomes, expected tool behavior, risk labels, and review rationale. Split training, debugging, and final acceptance samples, and avoid hand-tuning against the test questions.
Capstone release gates
Title "Capstone release gates"
The table below shows the first-version course gates, not an industry-wide benchmark. On delivery you must also report sample counts, confidence intervals or margins of error, failure distributions, model/prompt/index/tool/policy versions, and per-task cost.
| Dimension | First-version gate | Evidence |
|---|---|---|
| Retrieval | Recall@5 ≥ 0.85 on the answerable set | Fixed corpus and retrieval result snapshots |
| Answers | End-to-end task success rate ≥ 0.80 | Deterministic rules plus calibrated human scoring |
| Citations | Key facts cited, citation support rate ≥ 0.90 | Claim–source mapping table |
| Refusal | Correct refusal rate ≥ 0.90 on the unanswerable set | At least 20 independent samples |
| Permissions | 0 cross-tenant or privilege-escalation leaks | At least 15 negative cases; any failure blocks release |
| Tool safety | 0 unapproved writes, 0 reusing approvals after parameter changes, 0 duplicate external effects | Adversarial and replay tests; any failure blocks release |
| Latency | Q&A p95 ≤ 8 seconds with 10 concurrent users | Record load, hardware, model, and network conditions |
| Observability | 100% of acceptance runs can link model, retrieval, policy, and tool steps via run_id | Trace sampling and field checks |
| Recovery | A single-point failure of the model, index, or MCP triggers a defined degradation path | Drill records for the three failure types |
| Cost | Each accepted task stays within the budget in the Discovery Brief | Including model, retrieval, tools, retries, and human review |
Meeting the average scores does not mean you can go live. Cross-tenant leaks, unauthorized writes, secret exposure, or inability to roll back are hard blockers.
Milestones
| Milestone | Output | Exit criteria |
|---|---|---|
| M0 Problem contract | Discovery Brief, current-state process, data classification, success metrics | Customer representative and technical reviewers approve the scope |
| M1 Retrieval baseline | Data pipeline, ACL filtering, fixed eval set, baseline report | Results reproducible, failures classifiable |
| M2 Safe Q&A | Citations, refusal, conflict/staleness handling | Answer and safety gates meet baseline requirements |
| M3 MCP actions | Tool contracts, policy, preview, approval, idempotency, and audit | Unauthorized paths cannot produce effects |
| M4 Evals and threat validation | Sealed blind tests, human scoring, injection/privilege-escalation/leak tests | Results traceable with no security hard blockers |
| M5 Production and recovery | Load, cost, tracing, alerting, failure and recovery drills | Release checklist has no hard blockers |
| M6 Controlled pilot | Authorized pilot or clearly labeled course simulation, tasks, and failure observations | Continue/shrink/stop recommendation has evidence boundaries |
| M7 Handover and retrospective | Demo, ADRs, runbook, deployment, recovery, and handover package | New maintainers can deploy, operate on-call, and roll back |
How to review the project, not the demo
Title "How to review the project, not the demo"
Reviewers should randomly select eval samples from the repository, reproduce one success path and one failure path; switch user roles to attempt privilege escalation; replay a write request; take down one dependency; then deploy from a fresh environment following the documentation. Watching only the author's prepared "golden path" video cannot prove the project is complete.
The numbers in the project description are only initial course gates. For real customer projects, you must first measure the current state, then have the business owner, security lead, and technical lead jointly set the release thresholds.
After the project passes acceptance, continue with the FDE portfolio, organizing the Discovery Brief, architecture decisions, eval reports, security gates, and operations evidence into a case that recruiters can verify.
Authoritative sources and verification record
Title "Authoritative sources and verification record"
The following pages were all verified on 2026-08-19:
- Model Context Protocol: Specification — at verification time, latest resolved to the 2026-07-28 version; used for MCP roles, capabilities, and protocol boundaries.
- Model Context Protocol: Security Best Practices — reference for authorization, tokens, sessions, and remote server risks.
- Palantir: Forward Deployed Software Engineer — used to verify that the project must cover customer collaboration, architecture, data, application building, and end-to-end deployment, not just model demos.
- Anthropic: Forward Deployed Engineer — used to verify job evidence such as production LLM applications, MCP, evals, enterprise deployment, customer discovery, and long-term delivery.
- NIST: AI RMF Generative AI Profile — reference for generative AI risk governance.
- OWASP: Top 10 for LLM Applications — threat categories such as prompt injection, sensitive information, supply chain, permissions, and excessive agency.
- OpenTelemetry: Generative AI Semantic Conventions — reference for generative AI call and AI agent observability fields; check field stability before adopting.
- Google SRE: Monitoring Distributed Systems — monitoring methodology based on latency, traffic, errors, and saturation.
- RAGAS (EACL 2024 Demo) — a research reference for RAG eval dimensions; the course thresholds are set separately by this project.
These sources provide the basis for responsibilities, protocols, risks, and methods; the project scenarios, week counts, sample allocations, and numerical thresholds on this page are original course design.