Capstone: A 6-Week Simulated Engagement

How to use this capstone

The capstone is a 6-week simulated engagement with Northbound Freight, the fictional logistics company that has run as a thread through the entire course. By the end, you will have produced the artifacts a real FDE produces and made the decisions a real FDE makes.

Two ways to take it:

Path A — Solo, paper-only (8-12 hours)

Read each week’s brief. Produce the named artifacts in plain prose, in a single working document. At the end, you have a 30-50 page artifact that walks through the engagement — a portfolio piece you can hand to an interviewer.

Path B — Solo, with a platform (40-60 hours)

Same as A, but actually build the data pipelines, ontology, and apps using a real platform (Foundry, AIP, Retool + Postgres, or any composition of tools that gives you typed objects, actions, and apps). At the end, you have a working pilot you can demo.

Either path works. Path A is the right starting point for most aspirants; do Path B once you have an actual platform you can build on.

The simulation rules

A few rules to keep the exercise honest:

1. Time-box every decision. Each week’s work has a wall-clock budget. When the time is up, commit to your artifacts and move on, even if you wish you had more time. Real engagements work this way.

2. No retroactive edits. Once you’ve shipped a week’s artifacts, you don’t go back and rewrite them. Subsequent weeks build on whatever you produced — including your mistakes. Real engagements work this way too.

3. Write down what you’d do differently. At the end of each week, in a “retro” section, capture what you’d change if you ran it again. This is the most valuable single output of the capstone.

4. Use the lesson links. Every week’s work maps to specific lessons. When you’re stuck, return to them.

5. Be honest about the trade-offs you make. Every choice has a cost. Name it.

The customer brief

Read this once before starting Week 1. Treat it as the single page you would receive from your sales team after a deal closes.

NORTHBOUND FREIGHT — FDE ENGAGEMENT BRIEF

Business
  • Mid-size US trucking and logistics company
  • Headquarters: Chicago, IL
  • Annual revenue: ~$420M
  • Fleet: 240 tractors, 380 trailers, 280 drivers
  • 4 hubs: Chicago (HQ), Cleveland (East — managed by Doug), Detroit, St. Louis
  • Customers: ~180 active commercial accounts, top 10 = 60% of revenue
  • Key accounts: Acme Corp, Riverpoint, Linden Logs

The problem (as sold)
  On-time delivery is at 78%. CEO has committed to the board to
  reach 92% by end of Q3 (12 weeks out). Internal projects to
  improve dispatch coordination have stalled. They've contracted
  us to deliver an operational platform that gives dispatchers
  real-time visibility and reassignment tools.

Stakeholders (as introduced by sales)
  • CEO — sponsor, has the board commitment
  • Linda Park, VP Operations — primary sponsor; will own the rollout
  • Maria Hernandez, senior dispatcher — operator champion candidate
  • Doug Reilly, East hub manager — operator, runs the morning call
  • Jim Tanaka, IT director — concerned about vendor sprawl, on-call burden
  • Priya Vohra, InfoSec lead — recently joined, wants to professionalize
                                  the security review process
  • Raj Mehta, senior ops analyst — would be the analyst-side power user

Existing systems
  • SAP ERP — orders, customers, contracts, weights, billing
  • Oracle HRMS — drivers, tractors, trailers, employment
  • RoutePilot GPS — vendor, REST API, vehicle positions, ETAs
  • LegacyTender — homegrown SOAP system for load tendering
  • Sharepoint — static refs (hubs, lanes, account managers)
  • Active Directory + SAML — identity
  • ServiceNow — internal ticketing

Constraints
  • Hosting: customer cloud (Northbound's AWS account)
  • Identity: must integrate with their AD
  • PII handling: standard US commercial; no special regime
  • Budget: 6 weeks of full FDE engagement, then 12 months of
    25% retainer; option to renew
  • Reference customer interest: yes, willing to be a case study
    if the engagement succeeds

What sales already promised
  • A working dispatcher app within the engagement window
  • Measurable lift on on-time delivery
  • Hand-off to Northbound's team by month 6 of the year

What sales did NOT promise
  • Specific scope inside the dispatcher app (yours to define)
  • Anything customer-facing (would be a follow-on)
  • Replacing any existing system

That’s what you have. The CEO is excited. Linda is your sponsor. Jim is anxious. Priya wants to do this right. Maria, Doug, and Raj are the people whose lives you are about to change. You have 6 weeks.

Week 0 — Mobilization (4 hours)

You haven’t met the customer yet. The kickoff is Monday of Week 1. Use this week to prepare.

Activities

1. Re-read the customer brief and the relevant lessons:

   • What is a Forward Deploy Engineer?
   • The Embedded Delivery Model
   • The FDE Deployment Loop

2. Research Northbound’s industry. Spend 30 minutes reading about US trucking on-time delivery benchmarks, common operational metrics, the SAP transportation module, RoutePilot-class GPS vendors. You will not understand the domain in 30 minutes. You will start to recognize the vocabulary, which is what you need.

3. Pre-write your week-1 questions. For each of the seven named stakeholders, draft 5-7 questions you want to ask. Use the discovery lesson’s question shapes.

4. Prepare your one-minute self-introduction. Memorize it. You’ll deliver it 15 times in week 1.

5. Verify your laptop posture. Per Working on Customer Infrastructure Securely — encryption, MFA, password manager, separate browser profile. Get this right before you arrive.

Artifact 0 — Mobilization sheet

Produce a one-page sheet:

WEEK 0 — MOBILIZATION

Self-introduction (1 minute):
  [your script]

Top 3 things I expect to be wrong about Northbound:
  1.
  2.
  3.

Top 3 things I expect to be true regardless of what I'm told:
  1.
  2.
  3.

Stakeholder question lists:
  • Linda (VP Ops):
  • Jim (IT):
  • Priya (InfoSec):
  • Maria (dispatcher):
  • Doug (hub manager):
  • Raj (analyst):
  • CEO (if accessible):

Personal-laptop checklist:
  ☐ FDE
  ☐ Encrypted
  ☐ MFA on company accounts
  ☐ Customer browser profile created
  ☐ Password vault for this engagement created

You will use this sheet through week 1. Save it.

Time check

Wall-clock budget: 4 hours. When 4 hours is up, you go onsite Monday.

Week 1 — Discovery (8 hours of capstone work, simulating 5 days on site)

You arrive Monday. Linda greets you. The kickoff is at 10am with Linda, Jim, and Priya. The CEO drops in for 10 minutes. After lunch you meet Maria, Doug, and Raj, separately.

Simulated stakeholder responses

For the capstone, here is what each stakeholder tells you when you ask. Read the responses, take notes, look for contradictions.

Linda Park (VP Operations) — 45 min

“On-time delivery has been 78% for two quarters. Board commitment was made before I had a clear plan to hit 92%. I have three theories about where the gap is: (1) reassignments happen too late, (2) we miss capacity at the East hub, (3) certain customers — Acme especially — cause us pickups that slip and cascade. I think it’s mostly (1) and (2). The CEO thinks it’s (3). I want operators to have one screen instead of three. Maria is the right pilot user. I’d rather under-promise and over-deliver. I trust your team.”

Jim Tanaka (IT Director) — 30 min

“My team is fully booked through Q3. We can give you read-replica access to the Oracle HRMS and a daily SAP export to SFTP. We are not writing custom integrations for you. Our SSO is SAML via Azure AD. We have a CAB the second Tuesday of each month — anything that touches production has to go through it. Last vendor that came in here got stuck for 4 months on procurement; please don’t let that happen to you. Also: we have a vendor risk-rating process. You’ll need to fill out the SIG questionnaire.”

Priya Vohra (InfoSec) — 30 min

“I’m new — three months in. The previous InfoSec lead was lax. I’m tightening things up. Anything new gets a security review with me; I will be involved early so we don’t have surprises. I want a SOC 2 Type 2 from your company, a current pen test summary, and a data-flow diagram before we approve any production deploy. I’m reasonable but I’m not going to skip steps. Send me the SIG; I’ll be your single point of contact.”

Maria Hernandez (senior dispatcher) — 75 min

“I’m here at 5:30 AM every weekday. I open SAP, the RoutePilot GPS portal, and my spreadsheet. The spreadsheet is the master because nobody trusts SAP’s ETAs after 6 hours. I check 40-50 active loads each morning. I call Doug at 6:45 with anything slipping. We reroute 3-5 loads on a typical day; on a bad day, 10. The reassignment goes through SAP, but I’m always typing it manually because the SAP screen is the worst. Tuesday this week was a mess — RoutePilot was down for 90 minutes and I had to call drivers directly. If I had a magic wand, I’d have one screen. By 6:30. That tells me which loads are slipping enough that Doug needs to know.”

“There are three drivers I don’t fully trust to call in their delays. I keep notes on the side. The system has no idea who’s reliable. Watson is great. Adesina is fine. Petrov misses check-ins maybe twice a week.”

Doug Reilly (East hub manager) — 45 min

“I get Maria’s call at 6:45. I staff the morning shift between 6:50 and 7:15 based on what she tells me. If she’s right, we’re staffed. If she’s late or wrong, I’m scrambling. The biggest thing I’d want: I’d want her information before she calls me. Like, a screen I could check at 6:00. Then I’m pre-staffed by the time she calls and we just confirm.”

“About the East hub specifically — we have 12 dispatchers’ worth of loads coming through, and 3 main door-tenders. We’re capacity constrained on inbound docks. So a 30-min slip on inbound creates a backlog that takes 3 hours to clear. That’s why timely reassignment is so high-leverage.”

Raj Mehta (senior ops analyst) — 45 min

“I produce a weekly KPI dashboard for Linda. It takes me 6 hours every Friday because I have to pull from SAP, Oracle, and RoutePilot, reconcile the load IDs, and merge it all in Excel. The reconciliation is error-prone — last quarter I missed 30 loads because of a key mismatch. I would love a single source of truth. The exec dashboard is a nice-to-have for Linda; the daily operations data is what I need to actually do my job.”

“One thing nobody else has told you yet: we have a customer self-service tracking site that’s down half the time. The marketing team owns it. It’s not great. I bring it up because two of our top-10 customers — Acme and Riverpoint — keep asking when it’ll be fixed. That’s not your problem, but if your platform could ever be the source for that, it would be a big deal.”

CEO (10-min drop-in)

“I’m here for two reasons. One: I want this to work. Two: I want you to know I want this to work. The 92% number is real. The board sees it monthly. If we don’t hit it, we have a problem. If we do, you have a customer for the next ten years. Linda owns the day-to-day. I’ll see you at the steering committee.”

Activities — Week 1 deliverables

1. Build the stakeholder map. Three rings: sponsors, users, gatekeepers. Place every named person.

2. Write 30-minute write-ups for each interview. Capture verbatim quotes where they were striking.

3. Identify the lies and triangulations. For each stakeholder, name what is probably true vs. what they’re saying. (Example: Linda says “I trust your team” — but Jim is anxious and Priya is rigorous. Read across.)

4. Surface the discoveries that no spec writer would have given you. What did you learn that wouldn’t be in a sales doc?

5. Begin domain capture. Pull every noun and verb from the interviews into a list. Cluster synonyms. Identify the homonym candidates (warning: “load,” “stop,” “route,” “reassignment” — all worth scrutinizing).

Artifact 1 — The Week-1 Discovery Pack

Produce:

• A stakeholder map (one page, can be ASCII)
• Six interview write-ups (one paragraph each)
• A “things I learned that nobody told me” list (5-10 items)
• A noun/verb extraction (one page)
• A first-draft problem statement (one paragraph)

The problem statement is your week-1 thesis. It will be wrong in some way. Commit to it anyway.

Time check

Wall-clock budget: 8 hours. Stop when the budget is hit. Don’t keep polishing the problem statement past the buzzer.

Week 2 — Capture, Scope, and Plan (8 hours)

You’re back on site. The first interviews are done. You spent the weekend mulling. Monday you sit with Maria for 90 minutes, watching her actually do her morning batch.

Simulated sit-along observations

What you observe Monday morning between 5:30 and 7:15:

• Maria opens SAP first, the GPS portal second, the spreadsheet third. The spreadsheet is on her second monitor. SAP is on her left, GPS on her right.
• She copies load IDs into the spreadsheet by hand. About 47 loads today. Takes 22 minutes.
• She glances at her notes — a paper printout of “driver reliability” — twice during the batch.
• The GPS portal hangs at 6:18; she refreshes; it loads after 40 seconds. She mutters, “I hate this thing.”
• At 6:30 she’s flagged 4 loads as slipping (>15 min). Two are Acme loads (ironic given the CEO’s theory).
• At 6:45 she calls Doug. Reads him the 4 slipping loads. They agree on 2 reassignments and 2 monitor-only.
• At 6:55 she enters the 2 reassignments in SAP. This takes 8 minutes; she misclicks once and undoes it.
• At 7:15 she gets coffee. Total batch time: 95 minutes for a normal morning.

Activities

1. Refine the domain model. Use the domain capture lesson. Sketch on a whiteboard (or paper). Apply the homonym-split discipline. Identify the canonical names operators use vs. what executives say.

2. Validate the model. Walk it back through Maria mentally — does the model match what she does? Walk it through Linda — can her on-time KPI be a query against this model? Walk it through Jim — can the data sources you proposed back this model?

3. Pick the iteration-1 MVP. Apply the four filters: one user, one workflow, one week, one outcome. Write the MVP plan.

4. Draft the next-iteration roadmap. Three iterations beyond iteration 1, ranked, conditional on iteration 1 succeeding.

5. Surface the back-office work. What does Priya need? When does the SIG go in? What’s the SOC 2 question? Get the procurement onboarding submitted this week, not in week 4.

Artifact 2 — The Week-2 Build Pack

Produce:

• A v1 domain model (object types, link types, action types — see the semantic layer lesson for a reference shape)
• A glossary mapping business words to your model (one page)
• An MVP plan for iteration 1 (one page, see the MVP scoping lesson’s template)
• An iteration roadmap for iterations 2-4 (half a page)
• A back-office tracker (one page; questionnaires, contracts, procurement steps)
• A draft governance plan (steering committee membership, cadence)

Decision point — what is not in iteration 1?

A scoping muscle to flex: write down explicitly what you are choosing not to build in iteration 1. The “magic wand” features Maria mentioned. The customer-facing tracking Raj brought up. The driver-reliability scoring. Multi-dispatcher support. Everything. Make the cut visible.

Time check

Wall-clock budget: 8 hours.

Week 3 — Plumbing and the First Slice (8 hours)

The MVP is approved. Iteration 1 starts Monday. You’re on site Monday, Tuesday, Wednesday; remote Thursday, Friday.

Simulated technical reality

You discover, during plumbing:

• The SAP nightly export drops at 02:00. Schema is mostly stable but there’s a priority column that wasn’t in the sample export — Linda’s team added it last week.
• The RoutePilot REST API rate-limits at 60 req/min. The whole fleet has 240 tractors. You can paginate, but a full refresh takes 4 minutes minimum.
• The Oracle HRMS read replica has a 15-minute lag. Driver assignments are shown stale relative to dispatch reality.
• The Sharepoint hub-reference CSV uses a different hub naming convention than SAP. SAP has CHI, Sharepoint has Chicago-Main. You have to map.
• An emergency-override case surfaces in your sit-along: a driver checked in at the wrong hub yesterday and the SAP record is broken. Maria knows how to fix it manually. You realize your action surface needs an emergency override.

Activities

1. Wire the four datasources. SAP nightly SFTP, RoutePilot REST poll (every 5 min), Oracle HRMS hourly extract, Sharepoint static-refresh CSV. Use the patterns from the data plumbing lesson. Apply the validation discipline (row count, freshness, schema, domain, referential).

2. Commit the v1 ontology in your platform (or write it as a typed YAML if you’re on Path A). Bind to the datasources. Set freshness budgets per object type.

3. Build the morning view (read-only). Use the four building blocks from the operational apps lesson. Density-tuned. Freshness visible. Workflow-shaped.

4. Install on Maria’s laptop Thursday. Watch her use it Friday morning at 6:00. Take notes silently.

5. Demo Friday afternoon. Linda, Jim, Priya in the room. Maria in the front row.

Decision point — schema drift

You discover the new priority column on Tuesday. Three options:

• (A) Ignore it. Pipeline keeps working; column is unused.
• (B) Surface it as a property on Load immediately. Now your model has new shape iteration 1 didn’t plan for.
• (C) Log it loudly, capture the data, decide in iteration 2.

Pick one. Justify in writing. Real engagements force this kind of choice; commit and move on.

Decision point — the emergency override

The case Maria revealed (driver checked in at wrong hub) requires an action that bypasses normal validations. Three options:

• (A) Defer. Iteration 1 is read-only; she handles it manually for now.
• (B) Add a typed emergencyOverride action that requires a reason and audits everything.
• (C) Don’t formalize it. Tell Maria “we’ll work around it this iteration.”

(B) is what the semantic layer lesson would push you toward. Is it iteration 1 work or iteration 2 work? Decide.

Artifact 3 — The Week-3 Build Pack

Produce:

• A datasource registry (one page per source; see the API integration lesson)
• The v1 ontology, committed (in your platform or as a typed YAML doc)
• The morning view, deployed and accessible to Maria
• A short observation note from your Friday sit-along
• A Friday demo recap (what was shown, what landed, what the next ask is)
• Updated back-office tracker (SIG status, procurement status, contract status)

Time check

Wall-clock budget: 8 hours.

Week 4 — Iteration 2 and First Adoption Signals (8 hours)

The morning view is in pilot. Maria opened it Friday morning. She used it. She also opened the spreadsheet — old habits. Today is Monday of week 4. You meet at 9 AM with Maria for the iteration-1 retro.

Simulated week-3 measurements

What you can see:

• Maria opened the morning view 7 times last Friday morning (one open per ~10 minutes)
• The spreadsheet was still updated; Maria says “I’m not ready to trust it yet”
• The 6:45 call with Doug was 4 minutes shorter than her baseline. She explicitly attributed it to the morning view.
• One bug: the eta_calculated_at timestamp was showing in UTC, not Chicago time. Maria did not catch it; you did.
• A new request: Maria wants to see which customer the load belongs to without clicking. You currently show only the load ID.
• Doug has heard about the morning view and asked Maria if he can see it. (Iteration 3 candidate.)

Activities

1. Run the iteration-1 retro. What did you learn? What changes the next iteration’s plan?

2. Scope iteration 2. The MVP plan candidate: the stop reassignment workflow. From the morning view, Maria right-clicks a slipping row and reassigns the stop to a different driver. Action goes through the typed reassignStop in the ontology.

3. Build the reassignment workflow. Form, action, validation, audit. The action needs the emergency-override decision you made in week 3 to be resolved.

4. Add the customer-name column to the morning view. This is a small change, but you now decide: should it be done in low-code (workshop) or pro-code? Use the low-code/pro-code lesson’s ten-minute change test.

5. Begin training planning. You will train Maria’s two peers (Jorge, Carlos) in week 5. Draft the cheat sheet now.

6. First measurement of adoption metrics. DAR, workflow completion (still 0% reassignment on-platform — it’s iteration 2), old-path usage.

Decision point — the emergency override, revisited

Maria’s iteration-2 reassignment will need it sometimes. Now you have to ship it. Same three options as before, but now the iteration is sized to include it.

Decision point — Doug’s interest

Doug is sniffing around. The morning view was scoped to Maria. Three options:

• (A) Build Doug’s hub view in iteration 3 as planned.
• (B) Pull it forward to iteration 2.
• (C) Ignore him for now; tell Maria she can show him hers if she wants.

Each has a cost. Decide and justify.

Artifact 4 — The Week-4 Build Pack

Produce:

• An iteration-1 retro note (what worked, what didn’t, what the next plan is)
• The iteration-2 MVP plan (stop reassignment)
• The deployed reassignment workflow
• An updated cheat sheet for operators
• An adoption metrics snapshot
• A Friday demo recap
• An updated back-office tracker (procurement should be done; SIG should be in flight)

Time check

Wall-clock budget: 8 hours.

Week 5 — Multi-User Pilot and Pre-Cutover Prep (8 hours)

Iteration 2 shipped Friday of week 4. Maria has been reassigning loads in the morning view through this week. Time to widen the pilot.

Simulated week-4 measurements

• Maria reassigned 7 stops through the platform last week. 6 went through cleanly; 1 hit the emergency-override path (driver had moved hubs unannounced).
• The 6:45 call with Doug is now 5 min instead of 22. Linda has noticed.
• Maria has stopped opening the spreadsheet in the morning. She still has it open in the afternoon “for some other things” she does — you note this for follow-up.
• The audit trail correctly shows every action with user identity and reason. Priya checked it Tuesday and gave it a thumbs up.
• The SIG questionnaire is 60% answered; Priya wants the rest by Wednesday of week 5.
• Procurement onboarding is complete. The SOW is signed.

Activities

1. Train Jorge and Carlos (the morning- and night-shift dispatchers). Use the change management lesson’s discipline: 1-on-1, on real work, just before they need it. Maria is your trainer-in-training; have her co-teach.

2. Build Doug’s hub view. Now in iteration 3. Same building blocks; different filter (his hub) and a different summary footer (door capacity).

3. Pre-cutover work.

   • Write the cutover plan (use the production deploy lesson’s template)
   • Write the rollback procedure
   • Schedule the rollback dry-run for early week 6
   • Get Priya’s pre-cutover security sign-off

4. First exec-level update. Write a one-page status memo to Linda (and the CEO via Linda). Use the executive communication lesson’s BLUF discipline.

5. Plan the morning brief agent (iteration 4). This is a stretch goal — only build it if you have time after the cutover prep. If not, defer to iteration 5 (post-cutover).

Decision point — the 90% adoption bar

Linda asks: “What does it look like for me to declare success?” You need to give her a measurable bar that holds you accountable but is realistic. Draft your answer in the form of three numbers and a date.

Decision point — agent or no agent?

The morning brief agent is high-visibility. It’s also a different risk profile (LLM in production, customer cloud, a new vendor model relationship). Two options:

• (A) Ship it in iteration 4 (week 6, alongside cutover). Higher impact, higher risk.
• (B) Defer to iteration 5 (post-cutover). Cleaner cutover; agent has its own deliberate rollout.

The agentic workflows lesson says don’t ship agents in the same window as a major cutover. What do you do?

Artifact 5 — The Week-5 Build Pack

Produce:

• A cutover plan (named owners, dated steps)
• A rollback procedure (dry-run scheduled)
• Priya’s pre-cutover security sign-off (in the form of an email she’d send you)
• Operator training notes for Jorge and Carlos
• Doug’s hub view, deployed
• A one-page exec status memo to Linda
• Updated adoption metrics
• Decision log on the agent (defer or include)

Time check

Wall-clock budget: 8 hours.

Week 6 — Cutover, Hand-off Begins (8 hours)

Cutover week. You are on site Monday through Friday. Most of this week is operational, not creative. Show up early, be visible, communicate calmly.

Simulated cutover events

A list of things that happen during cutover week. Decide how you handle each, in writing.

Monday 06:00 — Cutover window opens. Morning view becomes the canonical screen for Maria, Jorge, and Carlos. Spreadsheet is officially deprecated. Doug’s hub view goes live.

Monday 06:30 — All three dispatchers using the morning view. Carlos has a question about the slip filter; you walk him through it at his desk in 5 minutes.

Monday 14:00 — The hourly Oracle HRMS sync runs over its 30-minute budget; your timeout kills it; alert fires. You investigate: a customer DBA is running an analytics query that’s slowing the replica. Coordinate with Jim. What do you do?

Tuesday 06:15 — RoutePilot is throwing 503s. About 10% of GPS pings missing. Morning view shows “GPS partial — last good ping 11 min ago” on affected loads. What do you do?

Tuesday 11:00 — Doug calls. He used the hub view this morning; he found one of his door-tenders pre-staffed wrong because the hub view had stale data. Stale data was 8 minutes old. What do you do?

Wednesday morning — Maria reassigns a stop and the action fails: the driver she picked is on a 10-hour rest cycle and the validator caught it. She didn’t know. What do you do?

Thursday — Priya does a security review of the audit log. Finds one place where a service account is logged as “system” instead of the actual integration name. Asks for a fix by end-of-day. What do you do?

Friday 06:00 — Cutover is one week in. Adoption metrics are good. No P1 incidents. Linda is happy. The CEO drops in to thank you.

Activities

1. Handle each cutover event above. Write a 2-sentence response for each: what you did, why, what changed in your runbook or design as a result.

2. Run daily 06:30 standups with Maria, Doug, and Jim. (Simulate by writing what each meeting’s notes would look like for two of the days.)

3. Send the daily end-of-day status post. (Simulate one of these.)

4. Begin the hand-off pair-programming sessions. With the customer’s senior engineer (you can name them; let’s call them Ethan), pair on adding a new property to Load. Ethan does it; you observe.

5. Write the cutover-complete memo. It is signed by you, Linda, and Jim.

6. Begin the 90-day post-cutover plan. Use the hand-off lesson’s template.

Decision point — declaring cutover complete

Friday 06:00. You need to decide whether to declare cutover complete on the original Monday-to-Monday window, or extend by a week. Use the criteria from the production deploy lesson. Justify your call.

Artifact 6 — The Week-6 Cutover Pack

Produce:

• A response to each of the seven cutover events
• Two simulated standup notes
• One simulated end-of-day status post
• A pair-programming session note from your hand-off training
• The cutover-complete memo (one page, three signatures)
• The first version of the 90-day post-cutover plan
• A weekly status memo to Linda

Time check

Wall-clock budget: 8 hours.

Week 6+ — Reflection and the Engagement Recap (4 hours)

The capstone’s final exercise. You have produced six weeks of artifacts. Now you reflect on what you would do differently.

The engagement recap document

A 5-10 page document that you would, in a real engagement, hand to your own management, your future replacement, and (in part) the customer. It is also the document you would hand to an interviewer.

Sections:

1. Executive summary. One paragraph. The headline outcome: on-time delivery moved, the platform is in production, hand-off is in motion.

2. The engagement arc. A weekly recap, two paragraphs each. Where the work was; what shipped; what was learned.

3. The artifacts. A list of every artifact produced, with one sentence on each.

4. The big decisions. Five to seven decisions you made and would defend. Format: situation, options, what you chose, why, what happened.

5. The mistakes. Three to five things you got wrong and what you would do differently. Be specific. Vague self-criticism is worthless; “I should have surfaced the SAP priority column to Linda in week 3 instead of week 5” is gold.

6. The mechanics that worked. Patterns from the course you applied that paid off. The lesson links if useful.

7. What’s next. Iteration 5+ candidates, the retainer plan, the year-2 outlook.

8. A personal reflection. What this engagement would do for your growth as an FDE. (One paragraph. Be honest.)

Time check

Wall-clock budget: 4 hours.

What you should have at the end

Six artifacts (or seven counting the engagement recap), totalling 30-50 pages. Each was produced under time pressure. Each captures real decisions. Each builds on the prior weeks’ commitments — including the mistakes.

This is the artifact you take to an FDE interview. When the interviewer asks “tell me about a complex engagement you’ve worked on,” you have an answer that is specific, structured, and demonstrates the disciplines of the role.

It is also the artifact you take to your first real engagement. When you’re at the customer’s office in week 1, drowning in interviews, you have a map of what week 6 looks like and what artifacts you produce along the way. The fog of the early weeks lifts faster.

Self-evaluation

A short rubric. Score yourself honestly.

If you can check 12 or more, you are ready for an FDE interview at any company. If you can check 14, you are ready to lead a real engagement.

Variations to try

If you want to extend the capstone:

Variation 1 — A different industry

Re-run the capstone for a healthcare customer (PHI, HIPAA, BAA), a defense customer (CUI, classified), or a financial customer (SOX, PCI). The phases stay the same; the constraints shift. Notice what changes.

Variation 2 — A failed engagement

Re-run the capstone with a deliberately hostile twist: the IT director is genuinely opposed; the budget is cut in week 4; the CEO replaces Linda mid-engagement. How does the discipline hold up? What breaks first?

Variation 3 — A second engagement at the same customer

Year 2 at Northbound. You’re back, with a year of operational data. The brief is now: external customer-facing tracking. The dispatch platform stays in place. What’s different the second time? Where do you save weeks?

Closing

You have completed the Forward Deploy Engineer Mastery course.

The discipline is now yours. Whether you are interviewing for FDE roles, leading your first engagement, or evaluating an existing engagement against the patterns above — you have the language, the moves, and the templates.

The technical work and the human work compound. The engineers who are great at both are rare, valuable, and have outsized impact on the systems and the organizations they work with.

Go ship.

Key terms to remember (course-wide)

• Embedded delivery model, deployment loop, stakeholder map, problem statement, MVP plan
• Domain capture, homonym split, semantic layer, typed action, idempotency
• Ingestion patterns, freshness budget, integration patterns, service identity
• Operational app, the four building blocks, low-code / pro-code boundary, agent tool surface
• Cutover plan, dual-run, rollback procedure, adoption trough, hand-off targets
• BLUF, decision memo, steering committee, the three gauntlets, vendor onboarding

Where to go next

• Practice a real engagement on a real platform — Foundry, AIP, Retool, or a stack you assemble.
• Interview for FDE roles. The capstone is your portfolio; the lessons are your vocabulary.
• Read the Ontology Builder course for deeper grounding in the semantic-layer primitives if you want to go further on that axis.
• Come back and re-take this course in 12 months. You will read it differently.

That’s the course. Now go and do the work.