AI for Forward Deployed Engineers

Learning objectives

• Can explain forward-deployed ownership: why an FDE sits at the seam of product, field, and engineering, and owns outcomes rather than tickets.
• Can trace how value actually lands in a customer, from a signed problem to a measurable change in the customer's own numbers.
• Can distinguish an FDE's remit from a pure builder's and from a pure consultant's.

Key concepts

• The forward-deployed model: embedded with the customer, short feedback loops, bias to a working artifact over a document.
• Outcome ownership versus output ownership. What "done" means when the customer has to run it after you leave.
• The three hats (product sense, field empathy, engineering craft) and when each one leads.
• Value realisation: the gap between a demo that impresses and a change the customer can bank. Leading versus lagging indicators of value.
• The delivery lifecycle at a glance: frame, prototype, build, integrate, deploy, operate, hand over. Where FDEs most often lose the thread.

Assignment

(1 to 2 hrs) — Map a real product you know to three plausible customer problems it could solve. Score each on "who feels the pain, how often, and what it costs them today," then pick the one worth solving and write two sentences on why.

Deliverable

a one-page problem-selection note.

Feeds

P1 (sets the framing habit the one-pager depends on).

Learning objectives

• Can run a full design-thinking loop (empathize, define, ideate, prototype, test) against an AI brief.
• Can write a sharp problem statement that names the user, the job, and the current pain, with no solution smuggled in.
• Can generate and prune ideas without falling in love with the first one.

Key concepts

• The five stages applied to AI: what "empathize" looks like when the user does not know what a model can do, and what "prototype" means when the cheapest prototype is often a prompt.
• Problem statements as contracts: user plus job plus pain plus success signal.
• Divergent then convergent thinking. How to ideate wide and then cut on feasibility and value.
• The trap of solutioning first: reaching for RAG or an agent before the problem is even framed.
• Framing AI-specific failure modes early: hallucination risk, data gaps, and trust as a first-class design concern.

Assignment

(2 to 3 hrs) — Run one design-thinking loop on a provided brief.

Deliverable

a problem statement plus three framed ideas, each with a one-line feasibility and value read.

Feeds

P1 (the framed idea becomes the PoC target).

Learning objectives

• Can run a discovery conversation that surfaces real requirements, not the customer's pre-baked solution.
• Can capture jobs-to-be-done, map stakeholders, and trace value to a metric the customer already tracks.
• Can turn a messy ask into a crisp, testable scope.

Key concepts

• Functional analysis: decomposing a business ask into the functions a solution must perform, independent of technology.
• Jobs-to-be-done framing: the progress a customer is trying to make, the circumstances, and the competing alternatives.
• Stakeholder mapping: economic buyer, champion, end user, blocker, and the quiet veto. Who has to say yes.
• Requirements elicitation without leading the witness. Open questions, the "five whys," and separating stated wants from real needs.
• Value mapping: connecting the solution to a number the customer will notice moving. The solution one-pager as the artifact that captures all of this.

Assignment

(2 to 3 hrs) — Given a deliberately messy customer ask, write a discovery brief (stakeholders, jobs-to-be-done, requirements, value hypothesis) and a first solution one-pager.

Deliverable

discovery brief plus solution one-pager.

Feeds

P1 (the one-pager is a graded P1 artifact).

Learning objectives

• Can decide whether a problem is even an AI problem, and say so before any code is written.
• Can triage feasibility, data readiness, ROI, and risk on a shared grid.
• Can write a defensible go or no-go recommendation.

Key concepts

• The "is this AI at all" filter: deterministic rules, plain automation, or a model. Choosing the least clever tool that works.
• Feasibility signals: is the task within reach of current models, is there ground truth, is the input available at inference time.
• Data readiness: does the customer have the data, is it accessible, is it clean enough, who owns it, and what is the residency constraint.
• ROI intuition: value per solved instance times volume, minus build and run cost. Why a high-accuracy solution to a rare problem can still be a no-go.
• Risk triage: cost of a wrong answer, reversibility, regulatory exposure, and where a human must stay in the loop.

Assignment

(2 hrs) — Score three provided use-cases on a feasibility-by-value grid, then justify one go and one no-go in writing.

Deliverable

a scored grid plus a one-page qualification memo.

Feeds

P1 (locks the use-case the PoC will target).

Learning objectives

• Can explain tokens, context windows, temperature, and the shape of model latency and cost well enough to make solution trade-offs.
• Can call a model API and reason about the difference between a small fast model and a large capable one for a given task.
• Can build cost and latency intuition rather than guessing.

Key concepts

• How a language model produces text: tokens, next-token prediction, context windows, and why long context is not free.
• The model-choice axis: capability versus latency versus cost. When a smaller model is the right FDE call.
• Determinism and temperature: why the same prompt varies, and when to pin it down.
• Cost mechanics: input versus output tokens, and how prompt design moves the bill. A rough back-of-envelope cost per solved instance.
• What embeddings are, at a glance, as the bridge into retrieval next week.

Assignment

(2 to 3 hrs) — Solve one task three ways (small model, large model, and a prompt-tightened version) and compare quality, latency, and cost.

Deliverable

a short comparison table with a recommendation and the reasoning.

Feeds

P1 (informs the model choice inside the PoC).

Learning objectives

• Can turn a flaky prompt into a reliable one, and prove the improvement with a small test set.
• Can force structured output (JSON, function-call arguments) that downstream code can trust.
• Can evaluate a prompt instead of eyeballing it.

Key concepts

• Prompt as an engineered artifact: role, task, constraints, few-shot examples, and output contract.
• Structured outputs: JSON schemas, function or tool calling, and why a typed contract beats free text at a system boundary.
• Reliability techniques: few-shot examples, chain-of-thought where it helps, and explicit "if you cannot answer, say so" behaviour.
• Building a tiny eval set: a handful of inputs with expected outputs, scored automatically, so a prompt change is a measured change.
• Failure modes: prompt injection at the edges, format drift, and silent over-confidence.

Assignment

(2 to 3 hrs) — Take a provided flaky prompt, rewrite it to emit reliable structured output, and back it with a small test set that scores before and after.

Deliverable

the hardened prompt plus a pass-rate before-and-after.

Feeds

P1 (the PoC's core prompt), later reused in P2 and Capstone.

Learning objectives

• Can build a small retrieval-augmented answerer over a document set and ground its answers with citations.
• Can reason about chunking, embeddings, and retrieval quality.
• Can measure whether an answer is actually grounded in the source.

Key concepts

• The RAG loop: chunk, embed, store, retrieve, ground. Why grounding beats fine-tuning for "answer from the customer's own documents."
• Chunking strategy: size, overlap, and structure-aware splitting. How bad chunking quietly wrecks retrieval.
• Embeddings and vector similarity: turning text into vectors and retrieving the nearest neighbours.
• Grounding and citation: forcing the model to answer only from retrieved context, and surfacing sources so the customer can trust it.
• Measuring grounding: retrieval hit rate and a simple faithfulness check. The difference between a fluent answer and a correct one.

Assignment

(2 to 3 hrs) — Build a small RAG answerer over a provided document set, return citations, and measure grounding on five test questions.

Deliverable

a working answerer plus a grounding score with notes.

Feeds

P1, then deepened into P2 (real ingestion) and Capstone.

Learning objectives

• Can scaffold a clickable, working prototype for a qualified use-case in hours.
• Can practise demo-driven development: build the thin slice that proves the value, and nothing else yet.
• Can show, not tell.

Key concepts

• Demo-driven development: start from the moment in the demo that lands, and build backward to just enough plumbing.
• Scaffolding fast: a minimal UI, a single happy path, mocked edges, and a real model call at the core.
• Scope discipline under time pressure: the one thing the PoC must prove, and the ten things it is allowed to fake.
• Reading a PoC honestly: what it demonstrates, what it does not, and what would break in the real environment.
• The PoC as a conversation tool, not a product. It exists to de-risk the next decision.

Assignment

(3 hrs) — Ship a clickable PoC for your qualified use-case, with one real end-to-end path working.

Deliverable

a running PoC plus a three-line "proves / fakes / would-break" note.

Feeds

P1 (this is the core P1 artifact).

Learning objectives

• Can sketch an end-to-end solution architecture at the right altitude for a customer conversation.
• Can tell the solution as a one-page story: problem, approach, value, and the path to production.
• Can connect the PoC to the real solution it points toward.

Key concepts

• The architecture sketch: boxes and arrows for data in, model in the middle, surface out, and the integrations at the edges. Just enough, not a blueprint.
• Storyboarding the solution: the before-and-after of a user's day, framed as a narrative a non-technical buyer follows.
• The one-page solution story as the FDE's core selling and aligning artifact.
• Naming the leap from PoC to production: what changes, what it costs, and what new risks appear.
• Design as communication: the same diagram read by an engineer and by a buyer.

Assignment

(2 to 3 hrs) — Storyboard your end-to-end solution and draw its architecture sketch, tied to the PoC you shipped.

Deliverable

a one-page solution story plus an architecture sketch.

Feeds

P1 (completes the P1 solution one-pager), and seeds P2 architecture.

Learning objectives

• Can give a solution a tool and let it act, safely and observably.
• Can reason about when going agentic earns its complexity and when it does not.
• Can read an agent's reasoning and tool-call trace to debug it.

Key concepts

• Function and tool calling: how a model chooses a tool, passes arguments, and consumes the result.
• The agent loop: perceive, decide, act, observe, repeat, with a stop condition.
• When to go agentic: multi-step tasks with branching, versus a single structured call that is cheaper and more reliable.
• Safety around action: scoping tools tightly, validating arguments, dry-run versus live, and never handing an agent an irreversible action without a gate.
• Observability from day one: logging the trace so failures are legible, not mysterious.

Assignment

(2 to 3 hrs) — Give your solution one real tool and let it act on a safe, reversible operation, with the full trace logged.

Deliverable

the tool-using solution plus a logged run showing the reasoning and calls.

Feeds

P3 (agentic workflow) and Capstone.

Learning objectives

• Can automate a real, multi-step business process end to end.
• Can decompose a workflow into steps, tools, decisions, and handback points.
• Can build in the checkpoints that keep an automated process trustworthy.

Key concepts

• Workflow decomposition: turning a back-office process into a sequence of steps, each with an input, an action, and a success check.
• Orchestration patterns: linear pipelines, branching on model output, retries, and where a human sign-off belongs.
• State and idempotency: making a step safe to re-run so a failure mid-way does not corrupt the process.
• Exception handling: what the workflow does when it is unsure, when a tool fails, or when the data is malformed.
• Measuring a workflow: throughput, straight-through rate, and the rate of escalation to a human.

Assignment

(3 hrs) — Automate a provided back-office workflow end to end against the sandbox, with an escalation path for the unsure cases.

Deliverable

a running automated workflow plus a straight-through-rate measurement.

Feeds

P3 (this is the P3 core), and Capstone.

Learning objectives

• Can wire a solution to real enterprise systems through their APIs.
• Can handle authentication, connectors, and webhooks without hand-waving.
• Can reason about the plumbing that makes an AI feature part of a workflow rather than a toy.

Key concepts

• Enterprise APIs: REST basics, pagination, rate limits, and reading someone else's API docs quickly.
• Authentication and identity: API keys, OAuth, service accounts, and single-sign-on at a level an FDE must integrate against.
• Connectors and webhooks: push versus pull, event-driven triggers, and keeping a solution reactive to the customer's systems.
• Data plumbing: mapping fields between systems, handling schema mismatches, and the "no accommodation shortcut" discipline of fixing data at the source.
• Failure and retry across a system boundary: timeouts, partial failures, and idempotent writes.

Assignment

(3 hrs) — Wire your solution to two sandbox systems (for example the CRM and the ticket queue), reading from one and writing to the other.

Deliverable

a working two-system integration with an auth flow.

Feeds

P2 (this is the P2 core), and Capstone.

Learning objectives

• Can build an ingestion pipeline over messy enterprise data and keep it fresh.
• Can choose and operate a vector store for retrieval at solution scale.
• Can reason about data freshness, deduplication, and pipeline reliability.

Key concepts

• Ingestion pipelines: extract, clean, chunk, embed, and load, run repeatably over documents and tickets.
• Vector stores in practice: indexing, metadata filters, and updating the store as source data changes.
• Freshness and change data capture: full re-index versus incremental, and how stale retrieval erodes trust.
• Handling messy inputs: mixed formats, duplicates, and partial records, fixed at ingestion rather than patched downstream.
• Operational concerns: pipeline monitoring, re-run safety, and cost of storage versus recompute.

Assignment

(3 hrs) — Build an ingestion pipeline over the sandbox's documents and tickets, with a re-run that only updates what changed.

Deliverable

a repeatable pipeline plus a freshness note.

Feeds

P2 (grounds the integrated solution's retrieval), and Capstone.

Learning objectives

• Can choose between prompt, RAG, fine-tune, and agent for a real problem and defend the choice.
• Can reason explicitly about cost, latency, and risk in an architecture.
• Can record a decision so the customer's team understands why, not just what.

Key concepts

• The four-way choice: plain prompting, retrieval grounding, fine-tuning, and agentic orchestration, and the questions that pick between them.
• Reference architectures: the common shapes of an enterprise AI solution and where each one fits.
• Trade-off reasoning: latency budgets, cost per request, accuracy needs, and the cost of being wrong, held together in one decision.
• The architecture decision record: the FDE Playbook artifact that captures the choice, the alternatives, and the reasons.
• Designing for change: which parts of the architecture you expect to swap, and keeping those seams clean.

Assignment

(2 to 3 hrs) — Produce an architecture decision record for your Capstone solution, comparing at least three options on cost, latency, and risk.

Deliverable

a one-page decision record with the chosen architecture and the trade-offs.

Feeds

Capstone directly, and firms up P2.

Learning objectives

• Can put a real, usable front door on a solution: a chat, a copilot, or a dashboard.
• Can choose the surface that fits the user's actual workflow.
• Can build an interface that a non-technical user can operate without a manual.

Key concepts

• Surface choices: conversational chat, an embedded copilot, or a dashboard, and matching the surface to the job-to-be-done.
• Interaction design for AI: showing sources, showing uncertainty, and making it obvious when the human is expected to act.
• The thin, honest interface: enough UI to make the value usable, not a reinvented product.
• Meeting the user where they work: embedding in an existing tool versus a standalone app.
• Accessibility and clarity basics so the surface is usable by the whole team, not just the champion.

Assignment

(3 hrs) — Put a real front door on your solution (chat, copilot, or dashboard) that a first-time user can operate.

Deliverable

a working delivery surface over your integrated solution.

Feeds

P2 (makes the integrated solution usable), and Capstone.

Learning objectives

• Can define success with the customer and write acceptance criteria that are testable.
• Can build an eval harness and run it against the build.
• Can add guardrails and probe the solution with basic red-teaming.

Key concepts

• Acceptance criteria as a contract: what the customer will check before they accept, written before the build is finished.
• The eval harness: a gold set of inputs and expected outputs, scored automatically, that turns "seems good" into a number.
• LLM-as-judge and rubric scoring for outputs that have no single right answer, and their limits.
• Guardrails: input and output checks, refusal behaviour, and blocking unsafe or out-of-scope requests.
• Red-teaming basics: adversarial inputs, prompt injection, and finding the failure before the customer does.

Assignment

(2 to 3 hrs) — Write acceptance criteria and a small eval set for your solution, then run the eval and record the score plus the top failure mode.

Deliverable

acceptance criteria plus an eval harness with a first result.

Feeds

P3 (the eval harness) and Capstone (the acceptance gate).

Learning objectives

• Can add a review and correction loop that measurably improves outputs.
• Can design where a human belongs in the loop and where they do not.
• Can capture feedback as data that drives improvement, not just comments.

Key concepts

• Human-in-the-loop patterns: review-before-send, approve-to-act, and sample-and-audit, matched to the risk of the task.
• Feedback capture: turning corrections and thumbs into structured signal a system can learn from or a team can triage.
• Closing the loop: feeding reviewed cases back into the prompt, the retrieval set, or the eval gold set.
• Measuring improvement: comparing output quality before and after the loop, so the value of review is visible.
• The economics of review: how much human time the loop costs and how to shrink it as trust grows.

Assignment

(2 to 3 hrs) — Add a review and feedback loop to your solution and show, with a before-and-after measure, that it improves outputs.

Deliverable

a working feedback loop plus the improvement measurement.

Feeds

P3 and Capstone (the operate-and-improve story).

Learning objectives

• Can find a solution's edge cases and failure modes, then make it hard to break.
• Can reason about reliability under real load and real messy input.
• Can turn "it worked in the demo" into "it holds in the field."

Key concepts

• Failure-mode hunting: adversarial inputs, empty and malformed data, long inputs, and the unhappy paths a demo skips.
• Reliability under load: concurrency, rate limits, timeouts, and graceful degradation when a dependency is slow or down.
• Defensive design: input validation, retries with backoff, circuit breakers, and safe fallbacks that fail loudly rather than silently.
• Regression protection: keeping the eval set and adding every found bug to it so it cannot come back.
• The hardening pass as an explicit step before anything is called ready.

Assignment

(2 to 3 hrs) — Deliberately break your solution, catalogue the failures, then harden it so the same inputs no longer break it.

Deliverable

a failure catalogue plus a hardened build that survives it.

Feeds

P2, P3, and Capstone (readiness for deployment).

Learning objectives

• Can deploy a solution into a target environment profile: cloud, VPC, or on-prem.
• Can containerise a solution and apply just-enough infrastructure as code.
• Can reason about the constraints of a customer's environment before shipping into it.

Key concepts

• Environment profiles: managed cloud, a customer's virtual private cloud, and fully on-prem, and what each one forbids.
• Containers: packaging a solution so it runs the same on your laptop and in the customer's environment.
• Just-enough infrastructure as code: reproducible deployment without building a platform team's worth of tooling.
• Configuration and secrets across environments: keeping keys, endpoints, and residency settings out of the code and under control.
• The deployment checklist: connectivity, resource limits, model access, and the rollback path before you flip it live.

Assignment

(3 hrs) — Deploy your solution into a given target environment profile as a container, configured for that environment.

Deliverable

a deployed, running solution plus a deployment runbook stub.

Feeds

Capstone (the deploy stage of the end-to-end story).

Learning objectives

• Can run a security and data-handling review of a solution.
• Can reason about compliance, privacy, and data residency in enterprise and regulated settings.
• Can spot where a solution leaks, over-collects, or crosses a boundary it should not.

Key concepts

• The threat surface of an AI solution: prompt injection, data exfiltration through outputs, over-broad tool permissions, and leaky logs.
• Privacy and data minimisation: collecting only what the job needs, redacting sensitive fields, and controlling what reaches the model.
• Data residency and sovereignty: keeping data within a required region or boundary, a real constraint for regulated customers in Bharat and elsewhere.
• Compliance posture: access control, audit trails, retention, and the paper trail an enterprise customer will demand.
• The security review as a repeatable FDE Playbook checklist, run before handover.

Assignment

(2 to 3 hrs) — Run a security and data-handling review of your solution against a provided checklist, and fix the top two findings.

Deliverable

a completed review with findings, severity, and the fixes made.

Feeds

Capstone (the panel will probe this) and the FDE Playbook.

Learning objectives

• Can instrument a solution for monitoring: cost, latency, and quality drift.
• Can set up observability and respond to an incident.
• Can operate an AI solution after it is live, not just build it.

Key concepts

• Field telemetry: token usage, latency, cost per request, and quality signals, captured as traces you can actually read.
• Drift and regression in the field: watching for quality decay as data, models, or usage shift, and catching it before the customer does.
• Cost control in operation: caching, model routing, and budget alerts.
• Incident response for AI: what an on-call runbook looks like when the failure is a bad answer rather than a crash, and how to triage it.
• Feeding production signal back into the eval set and the improvement loop.

Assignment

(2 to 3 hrs) — Instrument your solution with cost, latency, and quality telemetry, then simulate an incident and work it with a short runbook.

Deliverable

an instrumented solution plus an incident-response note.

Feeds

Capstone (the operate stage) and the FDE Playbook.

Learning objectives

• Can produce a handover pack a customer team could actually run with.
• Can write docs and runbooks that outlive your presence.
• Can train a customer's team to own the solution.

Key concepts

• The handover pack: architecture overview, runbooks, configuration guide, eval harness, known limits, and an escalation path.
• Runbooks that work at 2 a.m.: step-by-step, assuming no context, for the common operational tasks and failures.
• Enablement: training the customer's team, pairing, and a knowledge transfer plan so ownership actually moves.
• The acceptance and handover ceremony: how you confirm the customer accepts, and what "owned by them now" looks like.
• Designing for absence: writing everything down so the solution does not depend on you being reachable.

Assignment

(2 to 3 hrs) — Produce a handover pack for your solution that another pod could pick up and run cold.

Deliverable

a handover pack (runbook, config guide, known limits, escalation path).

Feeds

Capstone (the hand-over stage, defended to the panel) and the FDE Playbook.

Learning objectives

• Can manage stakeholders, scope a request, and say no well.
• Can deliver a crisp demo and tell a story with data.
• Can carry the consulting side of the FDE role, not just the engineering.

Key concepts

• Stakeholder management: reading the room, aligning the champion and the buyer, and keeping expectations honest.
• Scoping and saying no: protecting the outcome by cutting scope, and declining work that will not land value, without losing the relationship.
• The demo as a craft: opening on the value, showing the real thing, and handling the hard question in the room.
• Storytelling with data: turning eval numbers and telemetry into a narrative a non-technical stakeholder believes.
• Written communication: the status note, the decision memo, and the follow-up that keeps a delivery on track.

Assignment

(2 hrs) — Deliver a five-minute stakeholder demo of your solution, opening on value and closing on the ask.

Deliverable

a recorded or live-reviewed five-minute demo with a one-slide value framing.

Feeds

Capstone (the panel defense is this skill under pressure).

Learning objectives

• Can write the ROI narrative and the business case for a solution.
• Can reason about value realisation and expansion, light on pricing.
• Can connect a built solution to the number a customer cares about.

Key concepts

• The ROI narrative: value per solved instance, volume, and time-to-value, set against build and run cost.
• The business case: the one-page argument a buyer takes to their own approver, in their language, not yours.
• Value realisation over time: pilot to production to expansion, and the signals that a solution is ready to grow.
• Expansion thinking: the adjacent problem the same foundation could solve next.
• The honest value case: naming assumptions and risks so the number survives scrutiny.

Assignment

(2 to 3 hrs) — Write the one-page value case for your Capstone solution, with an ROI narrative and stated assumptions.

Deliverable

a one-page business and value case.

Feeds

Capstone (the commercial framing the panel expects).

Brief

Discover a real customer problem from a messy ask, qualify it as a genuine AI use-case, and stand up a working proof of concept, presented as a live demo. This is the frame-and-prototype loop end to end, at small scale.

Deliverables

• Discovery brief and solution one-pager (topics 03, 09).
• A qualification memo with a defensible go decision (topic 04).
• A clickable PoC with one real end-to-end path working (topic 08).
• An architecture sketch and a five-line demo script (topic 09).

Acceptance criteria

• The problem is framed as user, job, pain, and a value signal, with no solution smuggled into the statement.
• The go or no-go is justified on feasibility, data readiness, ROI, and risk.
• The PoC runs live and proves the one thing it claims to prove.
• The learner can state plainly what the PoC fakes and what would break in the real environment.

Brief

Turn the P1 PoC into a real, integrated solution wired to the messy enterprise sandbox: its CRM, documents, ticket queue, and database. The solution reads and writes real systems, grounds on real data, and wears a usable surface.

Deliverables

• A two-or-more system integration with a working auth flow (topic 12).
• An ingestion pipeline over the sandbox's documents and tickets, kept fresh (topic 13).
• An architecture decision record for the chosen shape (topic 14).
• A real delivery surface: chat, copilot, or dashboard (topic 15).
• A hardened build that survives a failure catalogue (topic 18).

Acceptance criteria

• The solution reads from and writes to the sandbox through real APIs and auth, not mocks.
• Retrieval is grounded on ingested data with citations, and the pipeline re-runs safely.
• The architecture choice is recorded with alternatives and trade-offs.
• A first-time user can operate the surface without a walkthrough.
• The solution holds against the catalogued edge cases and failures.

Brief

Automate a real, multi-step business process against the sandbox with an agent that uses tools, escalates when unsure, and is measured by an eval harness. This is the agentic build, held honest by evaluation.

Deliverables

• A tool-using agent acting on safe, reversible operations with full traces (topic 10).
• An end-to-end automated workflow with an escalation path (topic 11).
• An eval harness with acceptance criteria and a recorded score (topic 16).
• A human-in-the-loop feedback loop with a measured improvement (topic 17).

Acceptance criteria

• The workflow runs end to end and reports a straight-through rate and an escalation rate.
• Every agent action is logged as a legible trace, and no irreversible action runs without a gate.
• The eval harness produces a number and names the top failure mode.
• The feedback loop shows a before-and-after improvement, not just a claim.

Brief

For a simulated enterprise customer in a chosen vertical (for example fintech, healthcare, retail, or manufacturing), take a bespoke AI solution the whole way: discover, design, build, integrate, deploy, evaluate, and hand over. Then defend it to a customer panel of industry specialists who play the buyer.

Deliverables

• The full delivery trail: discovery brief and one-pager, architecture decision record, integrated and deployed solution, eval harness with results, security and data-handling review, handover pack, and a one-page value case.
• A deployed solution running in a target environment profile.
• A five-minute stakeholder demo and a defense of the solution to the panel.

Acceptance criteria

• Discover to hand over is coherent: each stage follows from the last, and the solution traces back to a framed customer problem and a value number.
• The solution is deployed and runs in a realistic environment profile, not only on a laptop.
• Evaluation is real: acceptance criteria, an eval score, and a named top failure mode.
• Security, privacy, and data residency are addressed, and the handover pack would let the customer's team run it without the builder.
• The value case is honest, with stated assumptions a buyer could scrutinise.

Panel defense

The panel plays the customer, not an examiner. Expect probing on scope and trade-offs ("why this architecture, why not that"), on trust ("how do we know it is right, what happens when it is wrong"), on operation ("who runs this after you leave, and what breaks first"), and on value ("what number moves, and how sure are you"). A strong defense reads like an FDE in the field: honest about limits, clear on value, and ready to hand the solution over. This builds readiness toward the FDE and AI solutions roles; it is never a placement promise. Companion to the curriculum overview, the day-by-day 8-week plan, and the session-by-session learning guide (40 sessions, 120 min, Mon to Fri). Keep the topic numbers, level bands, and project mapping in sync across all four when anything moves.