Capstone: The Field Engagement

⏱ ~9 min read · 🎧 9 min listen · ✎ 3 quizzes · 🧪 ~180 min lab

This lesson is deliberately short on new theory and long on orchestration — that's the point. An engagement is not a new skill; it's the ten skills you already have, executed in the right order under real constraints. Palantir's own framing of the job is enabling many capabilities for a single customer, in delivery cycles measured in days to weeks¹⁵ — and the reason 95% of enterprise GenAI pilots show no measurable impact is rarely a missing technique. It's a broken sequence: prototype before scoping, demo before evals, deploy before hardening.³ Today you run the sequence properly, once, end to end. It's the single strongest interview story you'll build in this course.

The arc: one motion, not seven tasks

Here is the full arc, and where each phase's muscle came from. Notice that only two rows are new this lesson — everything else is assembly. Your job today is integration, not rebuilding: the summarizer from Lesson 02, the triage agent and MCP data layer from Lessons 03 and 07, the grounded Q&A from Lesson 04, the eval harness from Lessons 05 and 09, and the guardrails from Lesson 08 become one system with one story.

Synthetic data is a first-class FDE skill

Here's the field reality nobody puts in the job posting: you almost never get production data in week one. Security review takes weeks; legal takes longer; and in regulated domains — health, government, finance — you may never be handed the real thing. FDEs still ship in days-to-weeks cycles⁵, so the working answer is synthetic data: you sit with the model and generate patient records, consult transcripts, and triage protocols that are shaped like the customer's world. This is not a workaround to be embarrassed about — it's a named skill, and doing it well is a differentiator.

Two disciplines make synthetic data professional instead of toy. First: realistic where it matters. Your triage agent doesn't care whether patient names are plausible; it cares that symptom presentations are clinically coherent, that edge cases exist (ambiguous urgency, conflicting history, incomplete intake), and that the distribution roughly matches what discovery told you — if 30% of consults are repeat scripts, your dataset needs that. Spend your realism budget on the fields the system actually reasons over. Second: document what's synthetic. Every generated file carries a header saying it's synthetic, how it was generated, and what it deliberately does and doesn't model. That documentation is what lets your eval results be honest acceptance evidence — "the system passes on data with these documented properties" — instead of a quiet overclaim.⁸

Compliance is a scoping input, not a deploy-day surprise

Your capstone customer is Australian, and in Australian health that means two regimes shape the engagement from day one. The Privacy Act's Australian Privacy Principles govern how personal information is collected, used, stored, and disclosed — and health information is "sensitive information," the most protected category.⁶ And anything touching My Health Record operates under its own stricter access-and-disclosure framework with the OAIC as privacy regulator.⁷ You are not the customer's lawyer, and nothing here is legal advice — but the FDE instinct is to surface these constraints in scoping, where they shape the architecture cheaply: data residency in the model choices, no sensitive data in prompts sent to non-approved endpoints, synthetic data for the pilot, human review before anything clinical reaches a patient. A compliance constraint discovered at deploy time is a re-architecture; the same constraint honored in the scoping doc is a table row.

The case study outlives the engagement

When the engagement ends, the code stays behind the customer's firewall — what leaves with you is the case study. It's the artifact that renews the contract, feeds deployment patterns back to product and engineering², and doubles as your interview evidence: interviewers explicitly probe whether you can narrate a full engagement, trade-offs included.⁴ Yours has one non-negotiable section: "What we recommended NOT to build." This is the AI-judgment thread landing its final rep — models are persuasive when wrong, and the engineer who documents where AI was the wrong answer is more credible on every claim where it was the right one.⁹ An engagement writeup with no "no" in it reads as sales copy, and hiring managers know it.

🧪 Practical steps: the engagement (~180 min)

Your customer is the fictional virtual-care provider from Lesson 10's discovery: telehealth consults, a triage chat, clinical notes, claims. Everything you've shipped into D:\Projects\FDE-Portfolio so far is your parts bin. This lab is the capstone portfolio artifact — the one interviewers will actually read — and it's tracked in the course's artifact tracker. Full instructions in labs/0011-field-engagement.md; the shape:

1. Re-scope (15 min). Reuse your Lesson 10 scoping doc. Refine it: confirm the goal, the non-goals, and add a "compliance constraints" row — Privacy Act sensitive-data handling, My Health Record boundary, synthetic-data-only pilot.
2. Generate the synthetic dataset (40 min). With Claude, generate ~20 patient records, ~10 consult transcripts, and a triage protocol doc. Realistic where it matters (symptoms, urgency edge cases, distribution); every file headed with a "SYNTHETIC DATA" block documenting how it was made and what it doesn't model.
3. Assemble the prototype (60 min). Integration, not rebuild: your Lesson 03/07/08 triage agent reading through the MCP data layer, Lesson 04 grounded Q&A over the triage protocol, Lesson 02 note summarizer on consult transcripts. One entry point, one demo flow.
4. Run evals as acceptance evidence (30 min). Point your Lesson 05/09 harness at the assembled system. Record pass rates per criterion — these numbers go in the case study verbatim.
5. Confirm hardening holds (15 min). Rerun 5 of your Lesson 08 adversarial prompts against the assembled system — integration is where guardrails quietly regress. Record results, including any failures and fixes.
6. Write the case study (30 min). One document: problem → approach → architecture sketch → eval results → compliance constraints honored → what we recommended NOT to build (and why) → next-phase recommendation. Save everything to D:\Projects\FDE-Portfolio\l11-capstone\.

Feedback loop: bring the case study (and eval numbers) back to me in chat and I'll review it the way a hiring manager reads an engagement writeup — does the sequence cohere, do the eval results actually support the claims, and is the not-to-build section candid or decorative? Then re-score your Lesson 01 gap map against it: the before/after is an interview story in itself.

You are a Forward Deployed Engineering lead reviewing my capstone: a full simulated FDE engagement for a fictional Australian virtual-care provider. The deliverable is a case study covering problem, approach, architecture, eval results on a documented synthetic dataset, compliance constraints honored (Privacy Act / My Health Record framing), a "what we recommended NOT to build" section, and a next-phase recommendation.

Grade each criterion as Strong / Adequate / Missing, with one sentence of evidence:
- Engagement coherence: the phases connect — the scoping doc's success criteria are the same criteria the evals measure, and the case study's claims trace back to them.
- Eval-evidence quality: results are specific (pass rates per criterion, dataset documented as synthetic with its limits stated), not vibes like "worked well in testing".
- Candor of the not-to-build section: it names something the customer plausibly wanted, gives a real engineering or judgment reason to refuse, and isn't a strawman.

Be skeptical — find the weakest causal link between my eval numbers and my case study's claims first. Then ask me 2–3 questions a customer executive would ask before funding phase two. Finish with the one change that would most improve this as interview evidence.

My case study follows below.

Check yourself — think like an FDE

Scenarios, not recall. Diagnose from the mental model — don't scroll up. Wrong picks stay live.