Forward Deployed Engineer
Capstone Challenge

Build Your FDE Scoping Document

You have covered the full FDE lifecycle: discovery, building, demo, handoff, and career growth. Now apply the framework to a real problem. This capstone asks you to produce two outputs that an FDE would actually create at the end of a discovery sprint: a one-page scoping document and a sketch of the pilot architecture.

Capstone Brief
Your Two-Part Deliverable
Choose a real enterprise AI problem you have encountered (or use one of the provided scenarios below). Produce both outputs as you would at the end of a 72-hour discovery sprint.
  • 01
    FDE Scoping DocumentUse the one-page template from Module 2. Include problem statement, success criteria, in-scope items, out-of-scope items, dependencies, and constraints. The document should be specific enough that a junior FDE could build to it without asking clarifying questions.
  • 02
    Pilot Architecture SketchUsing the three-layer model from Module 3 (data layer, AI processing layer, interface layer), describe the components of the pilot. Name the specific tools or APIs you would use for each layer. Identify the one component that carries the most technical risk and explain why.

Scenario Options

If you do not have a real problem to work with, choose one of these scenarios. Each is grounded in common FDE deployment patterns:

Scenario A
Legal contract review at a mid-size law firm
A 200-person law firm reviews approximately 1,400 vendor contracts per year. Senior associates spend an estimated 40 percent of their review time on standard clause verification that varies minimally across contracts. The firm wants to automate that portion. Data is stored in their document management system and cannot leave the on-premises environment. The managing partner is enthusiastic. The compliance team has not been briefed yet. A previous attempt with a general-purpose document tool was abandoned after three months due to inaccurate extraction on non-standard clauses.
Scenario B
Customer support ticket triage at an insurance carrier
A regional insurance carrier receives approximately 3,000 customer support tickets per week. Current triage: a team of six analysts manually categorizes each ticket and routes it to the correct specialist. Average triage time is 8 minutes per ticket. The carrier wants to automate categorization for the 70 percent of tickets that fall into standard categories, while flagging edge cases for human review. The carrier has 14 months of historical tickets with manual category labels available for fine-tuning or few-shot prompting. The IT team is understaffed and cannot support a complex integration during the pilot phase.
Scenario C
Internal knowledge retrieval at a pharmaceutical company
A pharmaceutical company has 12 years of internal research reports, regulatory filings, and clinical study summaries stored across three internal SharePoint instances. Scientists currently spend significant time searching for relevant precedent before starting new research directions. The head of research wants a conversational interface that can answer questions against this corpus. The data contains highly sensitive compound information and cannot be processed by external APIs. The IT security team requires that any AI system handling this data be approved through a formal review process that takes a minimum of six weeks.

Evaluation Rubric

Your scoping document and architecture should satisfy these criteria
SC
Success criteria are quantified where possible. "Faster" is not a success criterion. "Review cycle reduced from 4 days to 1 day" is.
OO
Out-of-scope items are explicit. Name at least three things the pilot will not include. This is as important as defining what is in scope.
HK
Hard constraints are respected. The scoping document must not propose a pilot that violates the stated hard constraints (data residency, security approvals, integration restrictions).
RL
Real problem, not stated problem. Apply the first discovery question: does the success criterion address the underlying business impact, not just the symptom?
AR
Architecture names specific components. Not "a retrieval layer" but "FAISS local vector store with text-embedding-3-small embeddings, chunk size 400, overlap 50." Specificity is a proxy for having actually built it.
RK
Technical risk is identified. Every pilot has a component that is most likely to fail or require the most iteration. Name it and explain why it carries the most risk.
Share your work If you complete the capstone and want feedback, share your scoping document and architecture sketch with Arjun Jaggi via the contact form or on LinkedIn. Strong submissions will receive specific written feedback. This is not a guarantee for all submissions, but detailed, well-reasoned work typically receives a response.

Template: Start Here

Text · Blank Capstone Template
PART 1: FDE SCOPING DOCUMENT
================================
Scenario: [A / B / C or your own]
Date: [Date]

PROBLEM STATEMENT
[2-3 sentences describing the business problem, not the technical
solution. Use the customer's language, not yours.]

SUCCESS CRITERIA
Primary: [The single metric that determines pilot success]
Secondary: [1-2 additional positive indicators]

IN SCOPE
1.
2.
3.
[Keep this list to 3-5 items maximum]

OUT OF SCOPE (explicit)
1.
2.
3.
[Name at least three things the pilot will NOT include]

DEPENDENCIES
Customer provides:
- [List specific data, access, or time commitments]
FDE provides:
- [List what the FDE is responsible for]

CONSTRAINTS
Hard (non-negotiable): [List each hard constraint]
Soft (can be renegotiated): [List each soft constraint]

PART 2: PILOT ARCHITECTURE SKETCH
================================
LAYER 1 — DATA
Input: [What data, in what format, from where]
Preprocessing: [How it will be normalized for the AI layer]
Storage: [Where processed data will live during the pilot]

LAYER 2 — AI PROCESSING
Core model: [Specific model or API]
Retrieval: [If RAG: embedding model, vector store, top-k]
Prompt design: [Describe the prompt strategy, not the full prompt]
Output parsing: [How model output becomes structured data]

LAYER 3 — INTERFACE
Interface type: [Web UI / API / CLI / spreadsheet / other]
Who uses it: [Describe the end user and their workflow]
What they see: [Describe the output as the user experiences it]

HIGHEST RISK COMPONENT
Component: [Name it]
Why: [Explain why this component is most likely to require
iteration or cause the pilot to fail if it underperforms]
Mitigation: [What you would do if this component fails]
Interactive: Capstone Complexity Estimator Assess

Rate your chosen scenario on these dimensions to estimate how long a real FDE pilot would take. More complex scenarios make richer learning material but require more careful scoping.

5
5
5
Estimated pilot duration: 3-4 weeks

Certificate of Completion

Certificate of Completion
This certifies that
Your Name
has completed
Forward Deployed Engineer
Free AI University · arjunjaggi.com
Date
Arjun Jaggi
Instructor, arjunjaggi.com
Cert ID
Work with Arjun Jaggi
Need an FDE for a real enterprise AI deployment?
Arjun Jaggi works directly with enterprise teams on AI pilot scoping, rapid prototyping, and handoff. If you have a real problem that needs a real FDE, schedule a conversation.
Schedule a call
← Module 6: Growing as an FDE Course Index →