Instructor Handbook

Duration: 24 weeks • Contact time: 4.5 h/week (Lecture 90 min, Lab 120 min, Studio 60 min) • Self-study: ~6 h/week • Total learning hours: 252.0

Programme phases

Delivery modes

Each week can be delivered by a real instructor (use the lesson plans below), by the AI tutor (students follow the self-paced script in the LMS 'This Week' view), or blended (instructor runs the lecture; AI tutor supports labs and studio).

Grading scheme

Team deliverables are graded per role. Each student's team-phase average is multiplied by a peer-evaluation factor (their mean peer rating ÷ the team's mean, limited to 0.8–1.1, applied once at least two teammates have rated them). The Week 24 viva is recorded as its own score (0–100) in LMS → Peer Evaluation & Viva.

FDE team roles

FDE Engagement Lead

Component	Weight
Individual auto-graded labs	15%
Weekly quizzes (24)	5%
Weekly written assignments (24)	5%
Chapter worksheets	10%
Chapter certification-style assessments (best attempt)	20%
Course enterprise projects (Courses 1–4) — individual and team	20%
Mid-course team engagement — role deliverables (weeks 13–16)	5%
Capstone engagement — project, role deliverables and presentation	10%
Capstone individual viva (week 24)	10%

Deliverables: BRD + ADRs + steering-committee deck (document); Leads the team presentation

Data & Integration Engineer

Security & Compliance Engineer

Deliverables: Security component code (auto-tested); Threat model (document)

AI & Decision Engineer

Owns the decision/ranking logic and keeps LLMs away from maths they can't be trusted with.

Deliverables: Decision/ranking component code (auto-tested); Decision-logic note

Integration & QA Engineer

Deliverables: Integrated prototype code (auto-tested against all Jira tickets); UAT report (document)

Platform & Reliability Engineer (SRE)

Review rubrics

Code

Document

Presentation

How to run a cohort in the LMS

Criterion	Points	Guide
Correctness (auto-tests)	60	Proportion of acceptance tests passing.
Robustness & edge cases	15	Handles missing keys, zero/negative values, empty inputs without crashing.
Readability	15	Clear names, small functions, comments where the business rule is non-obvious.
Security & compliance	10	No PII leaks in outputs/logs, no unsafe constructs.

Criterion	Points	Guide
Completeness	35	All required sections present and specific to the client.
Technical accuracy	30	Numbers, thresholds and trade-offs are correct and justified.
Client-readiness	20	Clear for executives: BLUF, no jargon without explanation.
Risks & next steps	15	Honest risks with mitigations and owners.

Criterion	Points	Guide
Storyline & decision request	25	Problem → solution → evidence → risks → clear ask.
Evidence from the prototype	25	Live metrics and test results, not claims.
Security, cost & SLA coverage	20	Addresses CISO and CFO concerns with numbers.
Q&A handling	20	Accurate, concise, honest answers to executive questions.
Delivery & timing	10	Within time, every member contributes.

Week 1: Orientation, the FDE Role & Python Data Structures

Course 1 — Foundations • Modules 1

Learning objectives

Explain what a Forward Deployed Engineer does and how the role differs from SWE, Data Scientist and Solutions Architect.
Use Python lists, dicts, sets and tuples and pick the right one for a lookup, a dedupe and an ordered batch.
Reason about Big-O for membership tests (list O(N) vs set/dict O(1)).
Set up the course environment and run code inside the Tier-1 sandbox.

Pre-class reading

Module 1 — sections on data structures and Big-O
Portal Tab 1 → run every Module 1 live example
Read: 'Day in the life of an FDE' (Module 10 intro, skim only)

Session A — Lecture & Live Demo (90 min)

Min	Segment	What to do
10	Welcome & course contract	Explain the 24-week arc: Foundations → AI core → Applied FDE → Enterprise hardening → Capstone. Show the grading scheme and team-role model.
20	What is an FDE?	Contrast FDE vs SWE vs Solutions Architect using a real scenario: a bank wants AI loan triage in 6 weeks. Who talks to the CRO? Who touches the dirty data? (The FDE does both.)
25	Python containers	Live-code list/dict/set/tuple. Emphasise mutability, hashability and why dict keys must be immutable.
25	Big-O with a stopwatch	Time `x in list` vs `x in set` for 1,000,000 items. Students predict before you run it.
10	Exit ticket	Each student writes one sentence: 'An FDE is different from a SWE because…'. Collect for Week 2 discussion.

Session B — Hands-On Lab (120 min)

Min	Segment	What to do
15	Environment check	Students open the portal, run the Module 1 examples, and confirm the sandbox blocks `import os`.
60	Guided exercises	Dedupe 10,000 customer IDs with a set; build an invoice lookup dict; group invoices by vendor with `dict.setdefault`.
30	Debugging clinic	Instructor injects a KeyError; students fix it with `.get()` and explain the difference.
15	Wrap-up	Students push their notebook/script and note one question for the AI Tutor.

Session C — Studio / Team Project (60 min)

Min	Segment	What to do
20	Meet your future teams	Explain the 6 FDE roles (Lead, Data, Security, AI, QA/Integration, SRE). Students self-rate skills 1–5 per role (used by the AI instructor to form teams in Week 13).
40	Case reading	In pairs, read the CrestFin client inbox (Tab 6) and list every requirement hidden in the messages.

Key talking points

FDEs are measured on client outcomes in production, not on code elegance.
Most enterprise data problems are lookup/dedupe problems — choosing set/dict correctly is a real production skill.
Membership in a set is O(1) average because of hashing; in a list it is O(N).
Dict keys must be hashable (immutable): strings, numbers, tuples — never lists.

Live demo script

Open Portal Tab 1 → Module 1. Run the Big-O live example with 10k, then 100k, then 1M items. Ask students to predict the list timing before each run, then show the set timing staying flat.

Whiteboard derivation

Draw a hash table with 8 buckets. Insert 'INV-01', 'INV-02', 'INV-09' via hash(key) % 8. Show lookup = compute bucket + compare. Then draw a list scan touching every element. Conclude: O(1) average vs O(N).

Discussion questions & model answers

Q: Why would an FDE, not a data scientist, be the one to fix a duplicate-invoice bug at a client site?
A: Because the FDE owns the end-to-end deployment at the client: integration, data quality, and the business outcome. The bug sits between the client's system and the AI pipeline, which is exactly the FDE's surface area.

Q: When would you use a tuple instead of a list?
A: When the record is fixed-shape and should not change (e.g. (vendor, amount) pairs), or when you need it as a dict key/set member because tuples are hashable.

Common misconceptions

'Sets keep insertion order like lists.' → Sets are unordered; if order matters, use a dict (insertion-ordered since Python 3.7) or keep a separate list.
'dict.get() is slower so avoid it.' → The difference is negligible; .get() prevents KeyError crashes on dirty enterprise data and is preferred at system boundaries.

Weekly quiz (answer key)

What is the average time complexity of `'INV-9' in invoice_set`?
Answer: O(1) — Sets are hash tables: one hash computation and a bucket check.
Which type CANNOT be a dict key?
Answer: list — Lists are mutable and therefore unhashable.
An FDE's primary success metric is…
Answer: Client outcome in production — FDEs are judged by business impact at the client.

Written assignment (min 250 words)

In 250–400 words: describe the FDE role to a non-technical friend, then explain with one concrete example why choosing a set over a list mattered for a business process.

Look for: Role definition; Concrete example; Big-O reasoning

Tasks assigned this week

quiz:w1, essay:w1

Week 2: Defensive Python: Errors, JSON/File I/O & Regex for KYC Data

Course 1 — Foundations • Modules 1

Learning objectives

Handle exceptions deliberately with try/except/else/finally and never swallow errors silently.
Read and write JSON files with encoding and validate shapes before use.
Write regular expressions to extract taxpayer ID, national ID and tax ID identifiers.
Complete Foundation Lab F1 independently.

Pre-class reading

Module 1 — JSON, exceptions and regex sections
Python docs: `re` module quick reference

Session A — Lecture & Live Demo (90 min)

Min	Segment	What to do
15	Week 1 exit-ticket debrief	Read 3 anonymous exit tickets aloud; refine the FDE definition together.
25	Exceptions as contracts	Show bad `except: pass` vs targeted `except (KeyError, ValueError) as e` with logging and a quarantine list.
20	JSON in, JSON out	Load an ERP export, show what happens with a trailing comma, show `encoding='utf-8'` for Spanish vendor names.
25	Regex for KYC	Build the taxpayer ID regex `TP\d{8}` character by character; then national ID with optional spaces; then tax ID.
5	Preview lab	Show the Lab F1 TODO template and explain progressive hints.

Session B — Hands-On Lab (120 min)

Min	Segment	What to do
10	Lab briefing	Explain auto-grader: 4 unit tests, sandboxed execution, unlimited resubmits.
80	Lab F1 — KYC cleaner	Students complete Lab F1 in the LMS. Instructor circulates; AI Tutor available for hints.
30	Peer code review	Pairs swap code and review against: naming, error handling, regex anchors (`\b`).

Session C — Studio / Team Project (60 min)

Min	Segment	What to do
60	Regex golf	Teams race to write the shortest correct tax ID regex, then discuss why readability beats brevity in client code.

Key talking points

Errors are data: at a client, a bad row should be quarantined with a reason, not crash the nightly batch.
Always specify encoding when reading files — vendor names often contain non-ASCII characters.
Use word boundaries `\b` so a taxpayer ID regex does not match inside a longer token.
Regex extracts candidates; validation (checksums, lookups) is a separate step.

Live demo script

Paste a messy KYC note into the Module 1 regex example. Run without `\b`, show a false match inside a longer string, then add `\b` and rerun.

Whiteboard derivation

Write the taxpayer ID format on the board: TP78738832. Map each block to regex tokens: [A-Z]{5} → \d{4} → [A-Z]. Then add \b at both ends and explain what 'boundary' means between \w and \W characters.

Discussion questions & model answers

Q: Is it ever OK to use a bare `except:`?
A: Almost never in production. It hides KeyboardInterrupt/SystemExit and real bugs. Catch specific exceptions and log the context.

Q: Why separate extraction (regex) from validation?
A: Regex only checks shape. A taxpayer ID-shaped string can still be invalid or belong to someone else; validation needs business rules or external verification.

Common misconceptions

're.match searches the whole string.' → re.match only anchors at the start; use re.search to find a pattern anywhere.
'JSON numbers are always floats in Python.' → json.load returns int for integer literals and float for decimals; comma-formatted strings like '125,000' stay strings until you parse them.

Weekly quiz (answer key)

Which regex matches a taxpayer ID like TP21376729 as a whole token?
Answer: \bTP\d{8}\b — Word boundaries prevent matches inside longer tokens.
re.match('taxpayer ID', 'My taxpayer ID') returns…
Answer: None — re.match only checks the start of the string.
Best practice for a corrupt row in a nightly batch is…
Answer: Quarantine it with a reason — Quarantine preserves auditability without stopping good rows.

Written assignment (min 300 words)

Write a 300-word 'data quality incident note' for a client: a nightly KYC job failed because of malformed JSON and unexpected taxpayer ID formats. Explain root cause, the fix (exceptions + regex), and how you prevent recurrence.

Look for: Root cause; Fix; Prevention

Tasks assigned this week

lab:lab_f1, quiz:w2, essay:w2

Week 3: Object-Oriented Python, Dataclasses & Pydantic-Style Validation

Course 1 — Foundations • Modules 2

Learning objectives

Model enterprise entities with classes, inheritance and abstract base classes.
Use @dataclass and type hints to make records explicit.
Build runtime validation that rejects bad records with clear error messages.
Explain why typed schemas are the contract between an FDE pipeline and an LLM.

Pre-class reading

Module 2 — all sections and live examples

Session A — Lecture & Live Demo (90 min)

Min	Segment	What to do
15	Why objects at a client?	Show a 400-line dict-soup script from a real pilot; ask students where bugs hide.
25	Classes & ABCs	Define `ExecutionSandbox(ABC)` with subclasses — mirror the course's own sandbox_engine.py.
20	Dataclasses	Convert an invoice dict into `@dataclass Invoice`; show __repr__, defaults, frozen=True.
25	Validation	Write `validate()` raising ValueError for negative amounts and bad currency; compare with Pydantic models.
5	Wrap	Connect to Week 13: schemas are how we force LLM output into structured JSON.

Session B — Hands-On Lab (120 min)

Min	Segment	What to do
100	Guided build	Students build `Invoice`, `Vendor`, `LedgerEntry` dataclasses with validation, then load the ERP sample and count valid vs invalid records.
20	Show & tell	Two students demo how their validator reports errors.

Session C — Studio / Team Project (60 min)

Min	Segment	What to do
60	Design critique	Groups design the class model for the MedShield claims engagement and present a 3-minute diagram.

Key talking points

Abstract base classes let us swap implementations (local → Docker → cloud sandbox) without changing callers.
Dataclasses remove boilerplate and make records self-documenting.
Validate at boundaries: when data enters from a client system or leaves an LLM.
Error messages are user interface — make them specific enough for a client's IT team to act on.

Live demo script

Open sandbox_engine.py in the repo and walk through `ExecutionSandbox` and `create_sandbox()`. Show how changing `mode` swaps the implementation without changing the caller.

Whiteboard derivation

Draw a UML box: ExecutionSandbox (abstract execute_python) with three arrows to LocalPrototypeSandbox, DockerContainerSandbox, E2BCloudSandbox. Label it 'Strategy pattern'.

Discussion questions & model answers

Q: When would inheritance be the wrong choice?
A: When subclasses don't truly share behaviour ('is-a'); prefer composition, e.g. a Pipeline that HAS a Redactor instead of IS a Redactor.

Q: Why validate LLM outputs with a schema?
A: LLMs are probabilistic; a schema turns 'probably right' into 'guaranteed shape or rejected', which downstream systems require.

Common misconceptions

'Type hints are enforced at runtime.' → Plain type hints are not enforced; you need validation code or a library like Pydantic.
'frozen dataclasses are deeply immutable.' → frozen prevents attribute reassignment, but a list field can still be mutated in place.

Weekly quiz (answer key)

What does @abstractmethod guarantee?
Answer: Subclasses must implement it before instantiation — A class with unimplemented abstract methods cannot be instantiated.
Are Python type hints enforced at runtime by default?
Answer: No — They are hints for tools; enforcement needs explicit validation.
Where should validation happen in an FDE pipeline?
Answer: At system boundaries — Validate wherever untrusted data enters or leaves.

Written assignment (min 250 words)

Design (in prose + a simple class list) the data model for a hospital claims pipeline. Justify one inheritance decision and one composition decision, and list 3 validation rules.

Look for: Class design; Inheritance vs composition; Validation rules

Tasks assigned this week

quiz:w3, essay:w3

Week 4: Relational Databases & SQL for Enterprise Ledgers

Course 1 — Foundations • Modules 3

Learning objectives

Design tables with primary and foreign keys for a vendor ledger.
Write INNER/LEFT JOINs and GROUP BY/HAVING aggregations.
Prevent SQL injection with parameterized queries.
Use transactions (BEGIN/COMMIT/ROLLBACK) for atomic multi-row updates.

Pre-class reading

Module 3 — all sections
Run every Module 3 live example in the portal

Session A — Lecture & Live Demo (90 min)

Min	Segment	What to do
15	Why SQL still runs the enterprise	SAP, LedgerOne, core banking — all relational. FDEs must read them.
25	Keys & joins	Build vendors + invoices tables; show INNER vs LEFT JOIN results on vendors with no invoices.
20	Aggregation	Total spend per vendor, HAVING to filter big vendors.
20	SQL injection live	Concatenate user input into SQL and drop a table; then fix with `?` placeholders.
10	Transactions	Transfer funds between two ledgers; crash mid-way; show ROLLBACK keeps books balanced.

Session B — Hands-On Lab (120 min)

Min	Segment	What to do
10	Lab briefing	Lab F2 overview.
80	Lab F2 — vendor spend aggregation	Students complete Lab F2 in the LMS.
30	Stretch	Add a LEFT JOIN report of vendors with zero spend; discuss why the CFO cares.

Session C — Studio / Team Project (60 min)

Min	Segment	What to do
60	Schema review	Teams draw the ledger schema for IndoAuto's purchase orders and identify which column is the idempotency key.

Key talking points

Parameterized queries are non-negotiable — treat string-built SQL as a security incident.
LEFT JOIN answers 'who is missing?', a frequent client question.
Transactions guarantee all-or-nothing; financial clients audit this.
SQLite is a perfect local prototype; the same SQL ports to Postgres in production.

Live demo script

In Module 3, run the SQL injection example first in its vulnerable form (explain), then the parameterized version. Ask: 'which version would pass the bank's CISO review?'

Whiteboard derivation

Draw two tables vendors(id PK, name) and invoices(id PK, vendor_id FK, amount). Draw the INNER JOIN result vs the LEFT JOIN result showing NULL rows for vendors without invoices.

Discussion questions & model answers

Q: Why is `INSERT OR REPLACE` useful but dangerous?
A: Useful for idempotent upserts on retries; dangerous because it silently overwrites — you need to be sure the key truly identifies the same business event.

Q: What does ACID give a bank?
A: Atomicity, Consistency, Isolation, Durability — e.g. a payout and its ledger entry either both happen or neither does.

Common misconceptions

'Escaping quotes manually is as good as parameters.' → Manual escaping misses edge cases and encodings; always use driver parameters.
'GROUP BY filters rows.' → WHERE filters rows before grouping; HAVING filters groups after aggregation.

Weekly quiz (answer key)

Which clause filters AFTER aggregation?
Answer: HAVING — HAVING filters grouped results.
Safe way to pass min_amount into a query?
Answer: `?` placeholder with a tuple — Placeholders let the driver handle escaping.
ROLLBACK is used to…
Answer: Undo an uncommitted transaction — It restores the state before BEGIN.

Written assignment (min 300 words)

A client asks: 'Can your AI just read our database directly?' Write a 300-word reply covering read-only access, parameterized queries, least privilege, and transactions for any writes.

Look for: Access control; Injection safety; Transactions

Tasks assigned this week

lab:lab_f2, quiz:w4, essay:w4

Week 5: How the Web Works: HTTP, REST, Idempotency Keys & JWT

Course 1 — Foundations • Modules 4

Learning objectives

Read HTTP requests/responses and interpret status codes 200/400/401/403/404/429/500/503.
Design REST endpoints and explain idempotent vs non-idempotent methods.
Verify an HMAC-SHA256 JWT and explain what the signature does and does not protect.
Explain why idempotency keys prevent duplicate payments on retries.

Pre-class reading

Module 4 — all sections and live examples

Session A — Lecture & Live Demo (90 min)

Min	Segment	What to do
20	Anatomy of a request	Use browser dev tools on the portal itself: show the POST to /api/grade-lab, headers, body, status.
20	Status codes as a language	Map each code to an FDE action: 429 → back off; 503 → retry later; 401 vs 403.
20	Idempotency	Act out a payment retry with two students; show how an idempotency key prevents a double charge.
25	JWT	Decode a JWT, change one claim, show the signature check failing.
5	Wrap	Preview Week 12 resilience patterns.

Session B — Hands-On Lab (120 min)

Min	Segment	What to do
90	Build a mini API client	Students write functions to classify status codes into actions and verify JWTs using the Module 4 examples as reference.
30	Debug session	Instructor hands out 5 real-looking error responses; students diagnose each.

Session C — Studio / Team Project (60 min)

Min	Segment	What to do
60	Client call role-play	One student plays the SAP basis admin reporting 503s; the team must ask the right questions.

Key talking points

Every client integration is HTTP; status codes tell you what to do next.
POST is not idempotent by default; an idempotency key makes retries safe.
JWT signatures prove integrity and issuer, not confidentiality — the payload is readable.
401 = who are you? 403 = I know you, but no.

Live demo script

Open the browser network tab on http://localhost:8080 and submit a lab. Walk through the request headers, JSON body and response timing. Then run the Module 4 JWT tamper example.

Whiteboard derivation

Draw JWT = base64(header).base64(payload).HMAC(secret, header.payload). Show that changing the payload changes the expected signature, so verification fails without the secret.

Discussion questions & model answers

Q: Can you put a national ID number in a JWT payload?
A: No — JWT payloads are only base64-encoded, not encrypted. Anyone holding the token can read it.

Q: Why is PUT idempotent but POST is not?
A: PUT sets a resource to a state (same result if repeated); POST typically creates something new each time.

Common misconceptions

'JWTs are encrypted.' → Standard JWS tokens are signed, not encrypted.
'Retrying on any error is safe.' → Retrying non-idempotent operations without a key can duplicate side effects.

Weekly quiz (answer key)

HTTP 429 means…
Answer: Too many requests — back off — Rate limit; respect Retry-After and back off.
A JWT signature protects…
Answer: Integrity of header+payload — It detects tampering.
401 vs 403?
Answer: 401 unauthenticated, 403 authenticated but forbidden — Identity vs permission.

Written assignment (min 300 words)

Write an integration design note (300 words) for calling a bank's loan API: endpoints, status code handling table, idempotency strategy, and how you verify tokens.

Look for: Status handling; Idempotency; Auth

Tasks assigned this week

quiz:w5, essay:w5

Week 6: Asynchronous Python & Concurrency + Course 1 Assessment

Course 1 — Foundations • Modules 5

Learning objectives

Explain the event loop, coroutines and await.
Fan out I/O calls with asyncio.gather and bound concurrency with a Semaphore.
Estimate latency savings from concurrent retrieval.
Demonstrate Course 1 mastery in the Course 1 assessment.

Pre-class reading

Module 5 — all sections
Revise Modules 1–4 for the assessment

Session A — Lecture & Live Demo (90 min)

Min	Segment	What to do
20	Why async at a client	A RAG call needs vector search + keyword search + policy lookup; sequential = slow.
25	Event loop	Visualise one waiter serving many tables. Live-code coroutines with asyncio.sleep.
20	gather & Semaphore	Run 10 fake API calls sequentially vs gathered; then cap at 3 with a Semaphore for a rate-limited client API.
25	Assessment review	Rapid recap of Modules 1–4 with cold-call questions.

Session B — Hands-On Lab (120 min)

Min	Segment	What to do
60	Async lab	Students rewrite a sequential 3-source retrieval into asyncio.gather and measure speedup.
60	Course 1 assessment (practical)	Timed: students re-solve Lab F1 and F2 from a blank template without hints.

Session C — Studio / Team Project (60 min)

Min	Segment	What to do
60	Course 1 retrospective	What was hardest? Collect feedback; instructor adjusts pacing for Course 2.

Key talking points

Async helps I/O-bound work (network, disk), not CPU-bound maths.
gather runs coroutines concurrently; total time ≈ the slowest call, not the sum.
Semaphores protect client APIs from being overwhelmed — respecting their rate limits is part of being a good guest.
This is the basis for the Week 11 latency budget.

Live demo script

Run the Module 5 gather example. Show 3 × 1s calls finishing in ~1s. Then wrap them in a Semaphore(1) and show it reverts to ~3s.

Whiteboard derivation

Draw a timeline: three bars sequentially (350 + 280 + 180 ms = 810 ms) vs stacked concurrently (max = 350 ms). Label the saved time.

Discussion questions & model answers

Q: Would async speed up computing DSCR for 1,000 loans?
A: No, that's CPU-bound arithmetic; async helps waiting on I/O. Use vectorisation or multiprocessing for CPU work.

Q: Why cap concurrency against a client's SAP gateway?
A: To avoid triggering 429/503 and to respect their capacity — overloading the client's system can cause an outage you are blamed for.

Common misconceptions

'async makes code run in parallel on multiple cores.' → asyncio is single-threaded cooperative concurrency.
'Calling a coroutine runs it.' → Calling returns a coroutine object; it runs only when awaited or scheduled.

Weekly quiz (answer key)

Three concurrent calls of 350, 280, 180 ms take about…
Answer: 350 ms — Concurrent time ≈ slowest call.
asyncio.Semaphore(3) is used to…
Answer: Limit concurrent tasks to 3 — It bounds concurrency.
async is most useful for…
Answer: I/O-bound waiting — It overlaps waiting time.

Written assignment (min 300 words)

Course 1 reflection (300 words): which foundation skill do you expect to use most as an FDE, and give one concrete client scenario where async concurrency would save the SLA.

Look for: Skill reflection; Async scenario; SLA awareness

Tasks assigned this week

quiz:w6, essay:w6

Week 7: Machine Learning from First Principles: Neurons, Loss & Gradient Descent

Course 2 — AI & LLM Core • Modules 6

Learning objectives

Distinguish AI, ML and deep learning with examples.
Compute a neuron's output with weights, bias and an activation function.
Explain loss and gradient descent and run one training loop by hand.
Recognise overfitting and why evaluation data must be held out.

Pre-class reading

Module 6 — all sections and live examples

Session A — Lecture & Live Demo (90 min)

Min	Segment	What to do
15	AI vs ML vs DL	Classify 6 products (spam filter, ChatGPT, rule-based fraud check…) as AI/ML/DL.
25	A single neuron	y = activation(w·x + b) with numbers; students compute on paper.
25	Loss & gradient descent	Plot loss vs weight on the board; take 3 gradient steps with learning rate 0.1.
20	Overfitting	Show a model memorising training data; introduce train/validation/test splits.
5	Wrap	Bridge: LLMs are the same idea with billions of weights.

Session B — Hands-On Lab (120 min)

Min	Segment	What to do
90	Train a neuron	Students modify the Module 6 example to learn a loan-default rule from 20 rows and report final loss.
30	Learning-rate experiment	Try lr = 0.001, 0.1, 5.0 and describe convergence vs divergence.

Session C — Studio / Team Project (60 min)

Min	Segment	What to do
60	Explain it to the CFO	Each student gives a 2-minute non-technical explanation of 'training' to a peer playing a CFO.

Key talking points

Training = adjusting weights to reduce a loss function using gradients.
Learning rate too high diverges; too low is slow.
Hold-out data is how we honestly measure performance — the same principle as Ragas evals in Week 19.
FDEs rarely train foundation models but must explain them credibly to clients.

Live demo script

Run the Module 6 neuron-training example and print loss every 10 epochs. Then set the learning rate to 5.0 and show the loss exploding.

Whiteboard derivation

Draw a parabola L(w) = (w − 3)². Start at w = 0, gradient = 2(w − 3) = −6, step w ← w − 0.1·(−6) = 0.6. Repeat twice: 1.08, 1.464. Show convergence toward 3.

Discussion questions & model answers

Q: Why can't we evaluate a model on its training data?
A: It may have memorised it; performance on unseen data is what matters at the client.

Q: Is a rules engine 'AI'?
A: Under a broad definition yes, but not ML — it doesn't learn from data. Many FDE solutions wisely combine rules with ML.

Common misconceptions

'More epochs is always better.' → Past a point the model overfits; monitor validation loss.
'Neural networks understand meaning like humans.' → They learn statistical patterns; treat outputs as probabilistic.

Weekly quiz (answer key)

Gradient descent updates weights by…
Answer: Subtracting learning_rate × gradient — Move opposite to the gradient.
A learning rate that is too high will likely…
Answer: Diverge/oscillate — Steps overshoot the minimum.
Why hold out a test set?
Answer: To measure performance on unseen data — Honest evaluation.

Written assignment (min 300 words)

Explain gradient descent to a bank's credit committee in 300 words using a loan-scoring example. Include what could go wrong (overfitting, bias) and how you would detect it.

Look for: Clear explanation; Risks; Detection

Tasks assigned this week

quiz:w7, essay:w7

Week 8: Tokenization (BPE), Embeddings & Cosine Similarity

Course 2 — AI & LLM Core • Modules 7

Learning objectives

Explain subword tokenization and run a BPE merge by hand.
Estimate token costs and the 'fertility tax' on non-English languages and JSON.
Represent text as embedding vectors and compute cosine similarity.
Complete Lab F3 (cosine ranking from scratch).

Pre-class reading

Module 7 — all sections and live examples

Session A — Lecture & Live Demo (90 min)

Min	Segment	What to do
25	Tokens are money	Show token counts for an English vs Spanish vs JSON sentence; connect to API pricing.
20	BPE by hand	Merge the most frequent pair in 'low lower lowest' three times on the board.
25	Embeddings	Words as points in space; 'invoice' near 'bill', far from 'holiday'.
20	Cosine similarity	Derive cos θ = a·b/(\|a\|\|b\|); compute for 2-D vectors.

Session B — Hands-On Lab (120 min)

Min	Segment	What to do
10	Lab briefing	Lab F3 overview and zero-vector edge case.
90	Lab F3	Students implement rank_documents_by_cosine in the LMS.
20	Extension	Rank 5 policy snippets for a query using toy embeddings.

Session C — Studio / Team Project (60 min)

Min	Segment	What to do
60	Cost estimation drill	Teams estimate monthly token cost for MedShield (25,000 claims/day × 2,000 tokens) and present assumptions.

Key talking points

Clients pay per token — FDEs must estimate costs before promising a solution.
Embeddings capture meaning as geometry; cosine measures direction, not length.
Always guard against zero vectors in production code.
Vector databases are just fast cosine/dot-product search at scale.

Live demo script

Run the Module 7 BPE example, then the cosine example. Change one vector to [0,0] and show the guard preventing ZeroDivisionError.

Whiteboard derivation

Draw vectors a = (1,0), b = (1,1). a·b = 1, |a| = 1, |b| = √2 → cos = 0.7071 (45°). Then c = (0,5): a·c = 0 → orthogonal → 0.

Discussion questions & model answers

Q: Why might Spanish text cost more tokens than English?
A: Tokenizers are trained mostly on English, so Spanish splits into more subword pieces — higher cost and shorter effective context.

Q: Why cosine instead of Euclidean distance?
A: Cosine ignores vector magnitude (document length) and focuses on direction (meaning).

Common misconceptions

'One word = one token.' → Tokens are subwords; one word can be several tokens.
'Higher cosine always means the answer is correct.' → Similarity ≠ correctness; retrieval must be evaluated.

Weekly quiz (answer key)

cos between (1,0) and (1,1) is…
Answer: 0.7071 — 1 / √2.
BPE merges…
Answer: The most frequent adjacent pair — Greedy frequency-based merging.
Two orthogonal embedding vectors have cosine…
Answer: 0 — Dot product is zero.

Written assignment (min 300 words)

Write a cost memo (300 words) for a client: estimate monthly token costs for a document Q&A system, explain the fertility tax on Spanish documents, and propose two cost reductions.

Look for: Estimate; Fertility tax; Reductions

Tasks assigned this week

lab:lab_f3, quiz:w8, essay:w8

Week 9: Inside the Transformer: Self-Attention, KV-Cache & Sampling

Course 2 — AI & LLM Core • Modules 8

Learning objectives

Compute scaled dot-product attention softmax(QKᵀ/√d)V on a tiny example.
Explain causal masking and why the KV-cache speeds generation.
Control output randomness with temperature and top-p.
Complete Lab F4 (temperature-scaled softmax).

Pre-class reading

Module 8 — all sections and live examples

Session A — Lecture & Live Demo (90 min)

Min	Segment	What to do
25	Attention intuition	'The bank of the river' vs 'the bank approved the loan' — context changes meaning.
25	Q, K, V maths	Compute a 2-token attention matrix on the board.
20	KV-cache	Why generating token 500 doesn't recompute tokens 1–499; memory cost per user.
20	Sampling	Temperature 0.1 vs 1.5 on the same logits; when to use T=0 for enterprise extraction.

Session B — Hands-On Lab (120 min)

Min	Segment	What to do
90	Lab F4	Students implement sample_token_distribution in the LMS.
30	Experiment	Plot probabilities at T = 0.2, 1.0, 2.0 and write two sentences on enterprise implications.

Session C — Studio / Team Project (60 min)

Min	Segment	What to do
60	Teach-back	Each team teaches attention to another team using only a whiteboard (no slides).

Key talking points

Attention lets each token weigh every previous token by relevance.
√d scaling keeps softmax from saturating.
Low temperature for extraction and compliance tasks; higher temperature only for creative tasks.
KV-cache memory grows with context length × concurrent users — it drives GPU sizing in Week 20.

Live demo script

Run the Module 8 attention example and print the attention matrix. Then run the temperature example at T = 0.2 and T = 2.0.

Whiteboard derivation

Write logits [4.2, 2.1, −1.5]. Compute softmax at T = 1 and at T = 0.5 (divide logits by 0.5 first). Show the top probability rising from ~0.89 to ~0.98.

Discussion questions & model answers

Q: Why does a bank's extraction pipeline use temperature 0?
A: To make outputs as deterministic and reproducible as possible for audit.

Q: Why does a longer context cost more GPU memory?
A: The KV-cache stores keys and values for every token in context, for every layer and every concurrent user.

Common misconceptions

'Temperature 0 guarantees identical outputs.' → It's greedy decoding, but hardware/batching nondeterminism can still cause small differences.
'Attention looks at future tokens during generation.' → Causal masking blocks future tokens in decoder models.

Weekly quiz (answer key)

Dividing logits by a small temperature makes the distribution…
Answer: Sharper — Differences between logits grow.
The √d term in attention…
Answer: Prevents large dot products from saturating softmax — Keeps gradients/probabilities well-behaved.
KV-cache speeds generation by…
Answer: Reusing past keys/values instead of recomputing — Avoids recomputation.

Written assignment (min 300 words)

Write a 300-word explainer for a client CISO on why the system uses temperature 0, what nondeterminism remains, and how you make outputs auditable.

Look for: Temperature; Residual risk; Auditability

Tasks assigned this week

lab:lab_f4, quiz:w9, essay:w9

Week 10: Prompt Engineering, Tool Calling (ReAct) & Multi-Provider SDKs

Course 2 — AI & LLM Core • Modules 9

Learning objectives

Write system/user prompts with explicit roles, constraints and output schemas.
Design a ReAct loop that calls deterministic tools instead of doing mental maths.
Abstract multiple LLM providers behind one interface.
Critique prompts for injection risk.

Pre-class reading

Module 9 — all sections and live examples

Session A — Lecture & Live Demo (90 min)

Min	Segment	What to do
20	Prompt anatomy	Role, task, constraints, examples, output format. Rewrite a vague prompt live.
25	Few-shot & CoT	When examples help; why hidden reasoning is still not a guarantee.
25	ReAct & tools	Thought → Action → Observation; the LLM asks a calculator for DSCR.
20	Provider adapters	One interface, many vendors (OpenAI, Anthropic, Gemini, local vLLM).

Session B — Hands-On Lab (120 min)

Min	Segment	What to do
90	Build a ReAct tool loop	Students extend the Module 9 example with a tax ID validator tool and a DSCR calculator tool.
30	Red-team your prompt	Pairs try to inject 'ignore previous instructions' into each other's agent.

Session C — Studio / Team Project (60 min)

Min	Segment	What to do
60	Prompt review board	Teams submit their best extraction prompt; the class scores clarity, constraints and schema.

Key talking points

Prompts are specifications; vague prompts produce vague systems.
Never let the LLM do arithmetic that matters — call a tool.
Provider abstraction protects the client from vendor lock-in and outages.
Prompt instructions are NOT security controls — Week 17 covers real controls.

Live demo script

Run the Module 9 ReAct example and print each Thought/Action/Observation step. Then change the tool to return an error and show the agent recovering.

Whiteboard derivation

Draw the ReAct loop as a cycle: LLM → (Action: tool name + args) → Tool executes in sandbox → Observation → back to LLM → final answer. Mark the trust boundary around the tool.

Discussion questions & model answers

Q: Why is 'Please do not reveal PII' in a system prompt insufficient?
A: Prompts can be overridden by injection; PII must be removed deterministically before the model sees it.

Q: When is few-shot prompting worse than zero-shot?
A: When examples are unrepresentative or bias the model toward copying their surface form.

Common misconceptions

'Chain-of-thought makes answers correct.' → It can improve reasoning but does not guarantee correctness; validate outputs.
'Tool calling means the model executes code.' → The model emits a structured request; your system decides whether and how to execute it.

Weekly quiz (answer key)

In ReAct, the 'Observation' is…
Answer: The tool's returned result — Tool output fed back to the model.
Best place to compute DSCR in an agent?
Answer: In a deterministic tool — Deterministic tools are auditable.
Why abstract LLM providers?
Answer: Avoid lock-in and handle outages — Resilience and flexibility.

Written assignment (min 250 words)

Submit a production extraction prompt for invoice JSON (system + user + schema), then in 200+ words explain each design choice and one injection risk you mitigated outside the prompt.

Look for: Prompt structure; Design rationale; Injection mitigation

Tasks assigned this week

quiz:w10, essay:w10

Week 11: The FDE Role in Depth: Compound Reliability & Latency SLAs + Course 2 Assessment

Course 3 — Applied FDE Systems • Modules 10

Learning objectives

Compute end-to-end reliability of multi-stage pipelines and the effect of retries.
Build a latency budget and identify the critical path.
Translate client SLAs into engineering constraints.
Demonstrate Course 2 mastery.

Pre-class reading

Module 10 — all sections
Revise Modules 6–9

Session A — Lecture & Live Demo (90 min)

Min	Segment	What to do
25	Compound reliability	0.9⁵ = 59%. Why demos work and production fails.
20	Retries change the maths	1 − 0.1³ = 0.999 per stage; recompute end to end.
25	Latency budgets	Auth 35 ms + retrieval + rerank + LLM; parallelise retrieval.
20	Course 2 review	Rapid-fire questions on tokens, embeddings, attention, prompting.

Session B — Hands-On Lab (120 min)

Min	Segment	What to do
40	Playground 1	Students use the SLA playground to hit 99% reliability and < 2 s latency.
80	Course 2 assessment (practical)	Re-solve Labs F3 and F4 from blank templates, timed, no hints.

Session C — Studio / Team Project (60 min)

Min	Segment	What to do
60	SLA negotiation role-play	A client demands 99.9% accuracy in 1 s; teams negotiate a realistic SLA with evidence.

Key talking points

Reliability multiplies across stages; every extra LLM call is a risk.
Retries and self-correction loops are how FDEs recover reliability.
Parallelising independent stages is the cheapest latency win.
SLAs are negotiated with evidence, not promised in optimism.

Live demo script

Open Playground 1 (Tab 4). Start with 5 stages at 0.90 and 1 attempt; then 3 attempts; then toggle parallel retrieval. Narrate each number's business meaning.

Whiteboard derivation

Write R = p^n. With p = 0.9, n = 5 → 0.59. With retries, p' = 1 − (1 − p)^k = 1 − 0.1³ = 0.999 → R = 0.999⁵ ≈ 0.995.

Discussion questions & model answers

Q: Why do impressive demos fail in production?
A: Demos test one happy path; production compounds small per-stage error rates across thousands of requests and dirty inputs.

Q: What do you do if the SLA can't be met?
A: Reduce stages, add deterministic steps, cache, parallelise, or renegotiate scope with data.

Common misconceptions

'99% per stage means 99% overall.' → Overall reliability is the product of the stages.
'Retries are free.' → Retries add latency and cost; budget them.

Weekly quiz (answer key)

Five stages at 90% each give overall…
Answer: 59% — 0.9⁵ ≈ 0.59.
With 3 attempts at 90%, single-stage success is…
Answer: 99.9% — 1 − 0.1³.
Cheapest latency win for independent retrievals?
Answer: Run them concurrently — Critical path = slowest call.

Written assignment (min 300 words)

Write an SLA proposal (300 words) for MedShield's discharge triage: target latency, reliability maths, retries/self-correction plan, and what you will NOT promise.

Look for: Reliability math; Latency budget; Honest scope

Tasks assigned this week

quiz:w11, essay:w11

Week 12: Production Resilience: Idempotency Stores & Circuit Breakers

Course 3 — Applied FDE Systems • Modules 11

Learning objectives

Implement an idempotency store that makes retries safe.
Implement a 3-state circuit breaker (CLOSED → OPEN → HALF_OPEN).
Design exponential backoff with jitter.
Complete FDE Lab 1.

Pre-class reading

Module 11 — all sections and live examples

Session A — Lecture & Live Demo (90 min)

Min	Segment	What to do
20	War story	A retry loop charges a customer twice. Walk through the incident timeline.
25	Idempotency store	Key → cached result; return cache on repeat.
25	Circuit breaker	State machine on the board; fail fast to protect the client's mainframe.
20	Backoff & jitter	Why synchronized retries cause thundering herds.

Session B — Hands-On Lab (120 min)

Min	Segment	What to do
10	Lab briefing	FDE Lab 1 overview.
90	FDE Lab 1	Students complete Lab 1 in the LMS.
20	Chaos preview	Run Playground 6B with 429/503 injection.

Session C — Studio / Team Project (60 min)

Min	Segment	What to do
60	Team formation prep	Students review the 6 FDE roles and update their skill self-ratings; next week the instructor/AI instructor forms project teams.

Key talking points

Idempotency is how you make 'at-least-once' delivery behave like 'exactly-once' for side effects.
Circuit breakers protect the downstream system AND your own latency.
Cached idempotent results must be returned even while the breaker is open.
Jitter spreads retries so you don't DDoS your client.

Live demo script

Run the Module 11 circuit-breaker example, printing state transitions. Then run Playground 6B with fail_count = 3.

Whiteboard derivation

Draw the state machine: CLOSED --failures ≥ threshold--> OPEN --cooldown--> HALF_OPEN --success--> CLOSED / --failure--> OPEN.

Discussion questions & model answers

Q: Should a cached idempotent result be returned when the breaker is OPEN?
A: Yes — no downstream call is needed, so serving the cached result is safe and correct.

Q: Where should idempotency keys come from?
A: From the business event (e.g. PO number or a client-generated UUID), not from a timestamp generated on each retry.

Common misconceptions

'A circuit breaker retries for you.' → It stops calls when failing; retries are a separate policy.
'Idempotency keys can be random per attempt.' → Then every retry looks new; the key must be stable across retries.

Weekly quiz (answer key)

After the failure threshold is reached, the breaker moves to…
Answer: OPEN — Fail fast.
An idempotency key should be…
Answer: Stable for the same business event — Stable identity enables dedupe.
Jitter in backoff prevents…
Answer: Thundering-herd synchronized retries — It desynchronises retries.

Written assignment (min 300 words)

Write a post-incident review (300 words) for a duplicate PO incident at IndoAuto: timeline, root cause, fix (idempotency + breaker), and follow-up actions with owners.

Look for: Timeline & root cause; Fix; Actions

Tasks assigned this week

lab:lab1, quiz:w12, essay:w12

Week 13: Dirty Enterprise Data Engineering + Mid-Course Engagement Kickoff

Course 3 — Applied FDE Systems • Modules 12 • Project: Mid-course engagement — Week 1 of 4: Kickoff & discovery

Learning objectives

Build a Bronze → Silver → Gold pipeline with schema-drift healing and a dead-letter quarantine.
Normalise currencies, locale-specific number formats and missing tax fields.
Form a project team, accept a role, and read the client inbox for your engagement.
Complete FDE Lab 2.

Pre-class reading

Module 12 — all sections
Tab 6 → read your team's client inbox (Stage 1)
LMS → My Team → read your role charter

Session A — Lecture & Live Demo (90 min)

Min	Segment	What to do
20	Medallion architecture	Bronze = raw, Silver = cleaned & validated, Gold = business-ready aggregates.
25	Schema drift healing	'id' vs 'inv_no', 'supplier_title' vs 'vendor' — alias maps and why they must be logged.
20	Quarantine design	Every rejected row gets a reason code; quarantine is an audit artefact, not a bin.
25	Engagement kickoff	Announce teams and roles (instructor or AI instructor). Walk through the 4-week project calendar and grading rubric.

Session B — Hands-On Lab (120 min)

Min	Segment	What to do
80	FDE Lab 2	Students complete Lab 2 in the LMS.
40	Team charter	Teams meet, confirm roles, agree a stand-up time and a definition of done.

Session C — Studio / Team Project (60 min)

Min	Segment	What to do
60	Discovery workshop	The Lead runs a 45-minute requirements session; the instructor plays the client CRO/CISO using the inbox messages. Teams leave with open questions logged.

Key talking points

Messy data is the FDE's daily reality; the pipeline must heal, not crash.
Every healing action and quarantine must be explainable to the client's auditors.
Roles mirror real FDE pods: the Lead owns the client, specialists own their components, QA integrates.
Teams that over-communicate early ship on time.

Live demo script

Open Playground 2 (Tab 4). Run the default dirty batch; then add a row with 'supplier_title' and an amount like '$3,000' and narrate how it is healed and converted.

Whiteboard derivation

Draw three boxes Bronze → Silver → Gold with a side arrow from Silver to a red 'Dead-Letter Quarantine' box. Annotate each arrow with the rules (dedupe, alias map, FX, sales tax imputation).

Discussion questions & model answers

Q: Why not just drop bad rows?
A: Dropped rows disappear from audit trails; the client must be able to see and fix them upstream.

Q: Who should decide the alias map?
A: The FDE proposes it from data profiling, but the client's data owner must sign it off.

Common misconceptions

'Schema healing means guessing.' → Healing applies explicit, logged mappings agreed with the client — never silent guesses.
'The Lead doesn't write code.' → Leads often code too, but their primary deliverables are requirements, decisions and client communication.

Weekly quiz (answer key)

The Silver layer contains…
Answer: Cleaned, validated records — Validated and normalised data.
A quarantined row must have…
Answer: A reason code — Reason codes make it auditable.
Who owns client communication in an FDE pod?
Answer: Engagement Lead — The Lead is the client's single point of contact.

Written assignment (min 300 words)

Individual: write your role charter (300 words): your responsibilities on this engagement, the deliverables you own, who you depend on, and how you'll know you're done.

Look for: Responsibilities; Dependencies; Definition of done

Tasks assigned this week

lab:lab2, quiz:w13, essay:w13, project:mid

Week 14: Context Engineering, Structured Outputs & Self-Correction Loops

Course 3 — Applied FDE Systems • Modules 13 • Project: Mid-course engagement — Week 2 of 4: Sprint 1 (component build) & ADR review

Learning objectives

Design prompts and contexts that maximise KV-cache prefix reuse.
Force structured JSON outputs and validate them.
Implement a balance-sheet self-correction loop with HITL escalation.
Deliver Sprint 1 role tasks for the team engagement.

Pre-class reading

Module 13 — all sections
Your role task brief in the LMS

Session A — Lecture & Live Demo (90 min)

Min	Segment	What to do
25	Context engineering	Static prefix first, dynamic content last; why order matters for caching.
20	Structured output	Schema → generation → validation → repair.
25	Self-correction loops	Attempt, validate maths, feed errors back, cap retries, escalate to human.
20	Sprint 1 stand-up	Each role reports: done, next, blocked.

Session B — Hands-On Lab (120 min)

Min	Segment	What to do
60	FDE Lab 3	Students complete Lab 3 in the LMS.
60	Team sprint	Role owners work on their component code; QA starts integration scaffolding.

Session C — Studio / Team Project (60 min)

Min	Segment	What to do
60	Architecture review	Each Lead presents 2 ADRs (5 minutes); the instructor plays CISO/CFO and approves or rejects.

Key talking points

Prefix caching can cut input costs by up to ~90% — structure prompts for it.
Never trust model JSON without validation.
Self-correction must be bounded; unbounded loops burn money and time.
Escalation to a human is a feature, not a failure.

Live demo script

Run the Module 13 self-correction example. Show attempt 1 failing the balance-sheet check, attempt 2 passing, then a case escalating to HITL.

Whiteboard derivation

Draw the loop: Generate → Validate (sum(line_items)+tax == total?) → if fail and attempts < N: add error to context → Generate; else → HITL queue.

Discussion questions & model answers

Q: How many retries should a self-correction loop allow?
A: Usually 2–3; beyond that, success rarely improves while cost and latency grow — escalate instead.

Q: Why place the policy rubric before the user document in the prompt?
A: The rubric is identical across requests, so it forms a cacheable prefix.

Common misconceptions

'JSON mode guarantees correct values.' → It guarantees syntax, not semantic correctness.
'HITL means the AI failed.' → HITL is a designed control for high-risk or ambiguous cases.

Weekly quiz (answer key)

For best prefix caching, place…
Answer: Static instructions first — Shared prefix must be identical.
A self-correction loop should end with…
Answer: A capped retry count and HITL escalation — Bounded with a human fallback.
JSON-mode output still needs…
Answer: Semantic validation — Values can still be wrong.

Written assignment (min 250 words)

Sprint 1 status report (250 words) from your role: what you completed, test results, blockers, and what you need from teammates.

Look for: Progress; Evidence; Blockers & needs

Tasks assigned this week

lab:lab3, quiz:w14, essay:w14

Week 15: Enterprise Hybrid RAG: Chunking, Dense + BM25 & Reciprocal Rank Fusion

Course 3 — Applied FDE Systems • Modules 14 • Project: Mid-course engagement — Week 3 of 4: Integration & client UAT

Learning objectives

Choose chunking strategies for tables and long policy documents.
Combine dense and BM25 retrieval with RRF (k = 60).
Explain why exact codes (e.g. CB-2026-44) defeat pure dense search.
Integrate team components and run client UAT.

Pre-class reading

Module 14 — all sections
Tab 6 → Stage 4 (UAT) for your engagement

Session A — Lecture & Live Demo (90 min)

Min	Segment	What to do
25	Chunking	Fixed vs semantic vs table-aware chunking; overlap trade-offs.
25	Dense vs BM25	Run Playground 3 with an exact circular code vs a conceptual query.
20	RRF	Score = Σ 1/(k + rank); compute for two documents.
20	Integration stand-up	QA reports integration status; Lead updates the client.

Session B — Hands-On Lab (120 min)

Min	Segment	What to do
60	FDE Lab 4	Students complete Lab 4 in the LMS.
60	Integration & UAT	QA integrates all components into the team prototype; the team runs UAT edge cases and logs bugs.

Session C — Studio / Team Project (60 min)

Min	Segment	What to do
60	Client UAT session	The instructor (as client) brings 3 surprise edge cases; teams must run them live and explain the results.

Key talking points

Hybrid retrieval is the enterprise default because users search with both concepts and codes.
RRF needs only ranks, so it fuses scores from incomparable systems.
UAT is where the client tries to break your system — welcome it.
Integration bugs live at interfaces; agree data contracts early.

Live demo script

Run Playground 3 with 'CB-2026-44 SME 45 day vendor payment rule', then 'employee vacation leave policy'. Show which engine wins each time and how RRF picks the consensus document.

Whiteboard derivation

Doc A: dense rank 2, BM25 rank 1 → 1/62 + 1/61 = 0.016129 + 0.016393 = 0.032522. Doc B: ranks 1 and 1 → 2/61 = 0.032787. B wins.

Discussion questions & model answers

Q: Why k = 60 in RRF?
A: It dampens the influence of top ranks so one engine's #1 doesn't dominate; 60 is an empirically robust default.

Q: What if UAT reveals a bug the day before the demo?
A: Log it, assess severity, fix if critical, otherwise disclose it transparently with a mitigation plan in the presentation.

Common misconceptions

'Dense embeddings find exact IDs reliably.' → Embeddings blur exact alphanumeric codes; BM25 matches them precisely.
'Bigger chunks are always better.' → Large chunks dilute relevance and cost more tokens.

Weekly quiz (answer key)

RRF score for ranks (1,1) with k = 60 is…
Answer: 0.032787 — 2/61.
Which retriever handles 'CB-2026-44' best?
Answer: BM25 keyword — Exact token match.
Who runs integration in our team model?
Answer: Integration/QA engineer — QA owns the integrated prototype.

Written assignment (min 300 words)

UAT report (300 words, written by the whole team, submitted individually): test cases run, pass/fail, bugs found, severity, and fixes or mitigations.

Look for: Test cases; Results; Bugs & severity

Tasks assigned this week

lab:lab4, quiz:w15, essay:w15

Week 16: Agents, MCP & Code-Execution Sandboxes + Mid-Engagement Demo Day

Course 3 — Applied FDE Systems • Modules 15 • Project: Mid-course engagement — Week 4 of 4: Demo day & retrospective

Learning objectives

Explain the Model Context Protocol and JSON-RPC tool calls.
Choose the right sandbox tier (AST → container → microVM) for untrusted agent code.
Present your team's mid-course engagement to a simulated steering committee.
Complete FDE Lab 5.

Pre-class reading

Module 15 — all sections
Prepare your team presentation (Tab 6 → Stage 5 deck generator can produce a draft)

Session A — Lecture & Live Demo (90 min)

Min	Segment	What to do
25	MCP	Servers expose tools/resources; clients call tools/call over JSON-RPC 2.0. Use Playground 4.
20	Sandbox tiers	AST scan, subprocess timeouts, containers with --network none, microVMs for multi-tenant.
45	Demo Day (part 1)	Teams present (10 min + 5 min Q&A). Instructor + peers score with the presentation rubric.

Session B — Hands-On Lab (120 min)

Min	Segment	What to do
60	FDE Lab 5	Students complete Lab 5 in the LMS.
60	Demo Day (part 2)	Remaining teams present.

Session C — Studio / Team Project (60 min)

Min	Segment	What to do
60	Retrospective	Each team runs a blameless retro: what went well, what didn't, what we'll change for the capstone. Each student submits the peer evaluation in LMS → My Team & Role; check completion in Peer Evaluation & Viva.

Key talking points

MCP standardises how agents reach enterprise systems — FDEs write MCP servers for clients.
Any model-generated code is untrusted and must run sandboxed with timeouts.
A steering-committee presentation is a decision meeting, not a show-and-tell: end with a clear ask.
Retrospectives turn a team into a better team.

Live demo script

Use Playground 4 to call calculate_vendor_dscr and show the JSON-RPC request/response. Then run Sandbox Mission 3 (red-team escape) to show the AST scanner blocking `import os`.

Whiteboard derivation

Draw: Agent (LLM) → MCP client → JSON-RPC → MCP server → [tool] → enterprise DB. Draw the sandbox box around any code-execution tool.

Discussion questions & model answers

Q: Why not just run agent code with exec() on the server?
A: It would give the model (and any injected attacker) full host access — secrets, files, network.

Q: What should the last slide of a steering-committee deck contain?
A: A clear recommendation and decision request (go/no-go, budget, next phase) with risks.

Common misconceptions

'MCP is a model.' → MCP is a protocol between AI clients and tool/data servers.
'A timeout alone makes code safe.' → Timeouts stop runaway loops but not file/network access; you need isolation too.

Weekly quiz (answer key)

MCP tool calls use…
Answer: JSON-RPC 2.0 — MCP is built on JSON-RPC.
The safest tier for multi-tenant untrusted code is…
Answer: Firecracker-style microVM — Hardware-level isolation.
A steering deck should end with…
Answer: A clear decision request — Executives decide.

Written assignment (min 300 words)

Individual retrospective (300 words): your contribution to the engagement, one thing you'd do differently, and feedback for one teammate (constructive and specific).

Look for: Contribution; Improvement; Peer feedback

Tasks assigned this week

lab:lab5, quiz:w16, essay:w16

Week 17: Enterprise Security: Pre-Retrieval RBAC, data-protection law & Prompt-Injection Defence

Course 4 — Enterprise Hardening • Modules 16

Learning objectives

Enforce multi-tenant, role-based access control before retrieval.
Apply data-protection law principles (GDPR, DPDP Act): purpose limitation, minimisation, PII tokenisation.
Detect and block direct and indirect prompt injection.
Complete FDE Lab 6.

Pre-class reading

Module 16 — all sections
Playground 5 (RBAC & data-protection)

Session A — Lecture & Live Demo (90 min)

Min	Segment	What to do
25	Threat model	Who are the attackers? Insider, other tenant, malicious document, curious employee.
25	RBAC before retrieval	Why post-retrieval filtering leaks via the LLM context.
20	Data-protection law	Consent, purpose limitation, data fiduciary duties; tokenisation vs masking.
20	Prompt injection	Direct vs indirect (inside PDFs); defence in depth.

Session B — Hands-On Lab (120 min)

Min	Segment	What to do
70	FDE Lab 6	Students complete Lab 6 in the LMS.
50	Red team	Pairs attack Playground 5 with injections and role escalation; document findings.

Session C — Studio / Team Project (60 min)

Min	Segment	What to do
60	Security review board	The instructor plays CISO; each student presents one STRIDE threat and its control in 3 minutes.

Key talking points

Access control must happen before documents reach the model.
Raw PII must not leave the client's boundary; tokenise reversibly where business needs it.
Prompt instructions are not controls; deterministic filters and policy engines are.
Security sign-off is often the critical path to production.

Live demo script

In Playground 5, run as intern, then cfo; show RBAC trails and redaction. Then click 'Load Red-Team Injection Attack' and show the block.

Whiteboard derivation

Draw: User → OIDC token (tenant, role) → policy filter on vector DB query → only authorized chunks → PII redactor → LLM. Mark where a post-retrieval filter would leak.

Discussion questions & model answers

Q: Why is post-retrieval filtering dangerous?
A: Unauthorized text may already be in the prompt or logs, and the model can paraphrase it.

Q: Masking vs tokenisation?
A: Masking is irreversible; tokenisation replaces PII with tokens that an authorised vault can reverse when legally required.

Common misconceptions

'The LLM can be told to respect roles.' → Role enforcement must be deterministic in the retrieval layer.
'Data-protection law only applies to companies based in the country.' → Laws such as the GDPR and India's DPDP Act also apply to organisations abroad that offer goods or services to people in their jurisdiction.

Weekly quiz (answer key)

RBAC should be enforced…
Answer: Before retrieval — Pre-retrieval prevents leakage.
Indirect prompt injection comes from…
Answer: Content inside retrieved documents — Malicious text inside data sources.
Reversible PII replacement is called…
Answer: Tokenisation — A vault maps tokens back.

Written assignment (min 350 words)

Write a threat model (350 words) for your team's capstone candidate client: assets, actors, top 5 threats (STRIDE), controls, and residual risk.

Look for: Assets & actors; Threats; Controls & residual risk

Tasks assigned this week

lab:lab6, quiz:w17, essay:w17

Week 18: Air-Gapped Cloud, Containers & Vector DB Operations

Course 4 — Enterprise Hardening • Modules 17

Learning objectives

Design a VPC/air-gapped deployment with private endpoints.
Write a multi-stage, non-root container build.
Tune vector indexes (HNSW parameters) for recall vs latency.
Produce a deployment runbook.

Pre-class reading

Module 17 — all sections

Session A — Lecture & Live Demo (90 min)

Min	Segment	What to do
25	Network topology	Public vs private subnets, egress control, private model endpoints.
25	Containers	Multi-stage builds, distroless images, read-only FS, --network none for sandboxes.
20	Vector DB ops	HNSW M/ef parameters; backup and re-index strategy.
20	Runbooks	What an on-call engineer at the client needs at 2 a.m.

Session B — Hands-On Lab (120 min)

Min	Segment	What to do
120	Deployment design lab	Students draw a deployment diagram and write a Dockerfile for the course's own portal (non-root, read-only), then review a peer's.

Session C — Studio / Team Project (60 min)

Min	Segment	What to do
60	Ops tabletop	Instructor announces: 'The vector DB node died at 2 a.m.' Teams walk through their runbook.

Key talking points

Regulated clients often forbid public internet egress — design for it from day one.
Containers are packaging, not a security boundary by themselves; harden them.
Index parameters trade recall for latency; measure, don't guess.
A runbook is a deliverable clients value as much as code.

Live demo script

Show the DockerContainerSandbox command in sandbox_engine.py: --network none, --read-only, --memory, --pids-limit. Explain each flag.

Whiteboard derivation

Draw a VPC: private subnet with app + vector DB + self-hosted model, a NAT-less design, a bastion for admins, and a private link to the client's data center.

Discussion questions & model answers

Q: Why run the model inside the client's VPC?
A: Data residency and data-protection/central-bank requirements; no PII leaves the boundary.

Q: What goes in a runbook?
A: Architecture summary, health checks, alerts, common failures with step-by-step fixes, escalation contacts, rollback procedure.

Common misconceptions

'Containers isolate like VMs.' → They share the host kernel; use additional hardening or microVMs for hostile code.
'Higher ef always improves results at no cost.' → Higher ef increases recall but also latency and CPU.

Weekly quiz (answer key)

--network none on a sandbox container…
Answer: Blocks all network access — No exfiltration path.
Multi-stage builds help by…
Answer: Shipping only runtime artefacts — Smaller, safer images.
Air-gapped deployments forbid…
Answer: Public internet egress — No outbound internet.

Written assignment (min 350 words)

Write a deployment & incident runbook (350 words) for your team's prototype: architecture, health checks, 3 failure scenarios with fixes, rollback, and escalation.

Look for: Architecture & health; Failure scenarios; Rollback & escalation

Tasks assigned this week

quiz:w18, essay:w18

Week 19: Evaluation Engineering (RAG Triad) & Chaos Drills + Capstone Kickoff

Course 4 — Enterprise Hardening • Modules 18 • Project: Capstone — Week 1 of 6: Kickoff, role rotation & discovery

Learning objectives

Measure faithfulness, context recall and answer relevancy.
Build a CI evaluation gate that blocks bad releases.
Run chaos drills (429/503/schema drift) and document recovery.
Form capstone teams, accept new roles and start client discovery.

Pre-class reading

Module 18 — all sections
Capstone brief in the LMS (new engagement & role)

Session A — Lecture & Live Demo (90 min)

Min	Segment	What to do
25	RAG triad	Faithfulness, context recall, answer relevancy — definitions and golden datasets.
20	CI gates	Fail the build if faithfulness < threshold.
20	Chaos engineering	Playground 6B; hypothesis → inject → observe → fix.
25	Capstone kickoff	New teams and rotated roles (nobody repeats their mid-course role). Capstone calendar and rubric.

Session B — Hands-On Lab (120 min)

Min	Segment	What to do
70	FDE Lab 7	Students complete Lab 7 in the LMS.
50	Capstone discovery	Teams read the client inbox and draft open questions.

Session C — Studio / Team Project (60 min)

Min	Segment	What to do
60	Capstone discovery workshop	Instructor plays the client stakeholders; Leads facilitate.

Key talking points

If you can't measure it, you can't ship it to a regulated client.
Golden datasets must be curated with the client's domain experts.
Chaos drills prove resilience claims before production proves them for you.
Role rotation builds well-rounded FDEs.

Live demo script

Run Playground 6B with 429 + drift, then 503 with fail_count = 3. Narrate the hypothesis, observation and recovery log.

Whiteboard derivation

Draw the CI pipeline: commit → unit tests → eval on golden set (faithfulness ≥ 0.90, recall ≥ 0.85) → deploy; red arrow back to developer if the gate fails.

Discussion questions & model answers

Q: Who should write the golden dataset?
A: Domain experts at the client with the FDE; engineers alone will miss real-world edge cases.

Q: Is a chaos drill safe in production?
A: Start in staging; graduate to controlled production experiments with blast-radius limits and approval.

Common misconceptions

'High faithfulness means the answer is complete.' → Faithfulness checks grounding; completeness is measured by recall/relevancy.
'Chaos engineering means breaking things randomly.' → It's hypothesis-driven, controlled experimentation.

Weekly quiz (answer key)

Faithfulness measures…
Answer: Whether the answer is grounded in retrieved context — Grounding.
A CI eval gate should…
Answer: Block releases below thresholds — Quality gate.
In capstone teams, roles are…
Answer: Rotated — Rotation builds breadth.

Written assignment (min 300 words)

Write an evaluation plan (300 words) for your capstone: golden dataset, metrics and thresholds, chaos scenarios, and how results reach the steering committee.

Look for: Dataset & metrics; Thresholds & gates; Chaos scenarios

Tasks assigned this week

lab:lab7, quiz:w19, essay:w19, project:capstone

Week 20: Small Language Models, LoRA/QLoRA & GPU Sizing + Capstone Architecture

Course 4 — Enterprise Hardening • Modules 19 • Project: Capstone — Week 2 of 6: Architecture review & component build

Learning objectives

Decide between frontier APIs, hosted open models and on-prem SLMs.
Explain LoRA rank decomposition and QLoRA 4-bit quantisation.
Size GPU VRAM for weights + KV-cache.
Pass the capstone architecture review (ADRs).

Pre-class reading

Module 19 — all sections
Playground 6A (VRAM/TCO)

Session A — Lecture & Live Demo (90 min)

Min	Segment	What to do
25	Build vs buy	Decision matrix: data sensitivity, latency, cost, quality.
25	LoRA/QLoRA	W' = W + BA with rank r; parameter savings; 4-bit NF4.
20	VRAM sizing	params × bytes/param + KV-cache, × 1.15 overhead.
20	Capstone stand-up	Roles report; Lead lists decisions needed.

Session B — Hands-On Lab (120 min)

Min	Segment	What to do
60	FDE Lab 8	Students complete Lab 8 in the LMS.
60	Capstone sprint	Component build continues; QA writes integration tests.

Session C — Studio / Team Project (60 min)

Min	Segment	What to do
60	Capstone architecture review	Each Lead defends ADRs; instructor plays CISO + CFO and records approve/reject.

Key talking points

Fine-tuning changes behaviour/format; RAG supplies knowledge — most clients need RAG first.
Quantisation trades a little quality for large memory savings.
GPU sizing errors are expensive; always include KV-cache and overhead.
Architecture decisions must be written down (ADRs) and signed off.

Live demo script

In Playground 6A, size an 8B model at int4, int8 and fp16; then 70B int4. Read out the recommended GPU each time.

Whiteboard derivation

8B × 0.55 GB/B = 4.4 GB weights; × 1.15 overhead = 5.06 GB. LoRA: a 4096×4096 matrix has 16.8M params; rank-8 LoRA adds 2 × 4096 × 8 = 65,536 (0.39%).

Discussion questions & model answers

Q: When is fine-tuning the right answer?
A: When you need consistent format/style or domain behaviour that prompting can't achieve, and you have quality labelled data — not to add frequently-changing knowledge.

Q: Why does a CFO care about quantisation?
A: It can let a model fit on one cheaper GPU instead of several, cutting infrastructure cost dramatically.

Common misconceptions

'Fine-tuning teaches the model new facts reliably.' → It's unreliable for facts; use retrieval for knowledge.
'VRAM = parameter count in GB.' → Bytes per parameter depend on precision, plus KV-cache and overhead.

Weekly quiz (answer key)

8B model at 4-bit with 15% overhead needs about…
Answer: 5.06 GB — 8 × 0.55 × 1.15.
LoRA trains…
Answer: Small low-rank adapter matrices — W + BA.
For frequently changing policy knowledge, prefer…
Answer: RAG — Retrieval keeps knowledge fresh.

Written assignment (min 300 words)

Write a model-selection ADR (300 words) for your capstone: options considered, decision, VRAM/cost maths, and consequences.

Look for: Options; Maths; Decision & consequences

Tasks assigned this week

lab:lab8, quiz:w20, essay:w20

Week 21: Client Consulting: Scope, Change Requests & CFO TCO/ROI

Course 4 — Enterprise Hardening • Modules 20 • Project: Capstone — Week 3 of 6: Sprint 1 & client change request

Learning objectives

Manage scope and handle a mid-project change request professionally.
Build a token TCO and net-ROI model for the client CFO.
Write clear client communications (status emails, decision memos).
Complete capstone Sprint 1 role deliverables.

Pre-class reading

Module 20 — all sections

Session A — Lecture & Live Demo (90 min)

Min	Segment	What to do
25	Scope governance	Statement of work, change-request process, impact analysis.
25	TCO & ROI	Tokens, infra, people; hours saved × rate; payback period.
20	Client communication	BLUF (bottom line up front) emails; never surprise the client.
20	Change request drop	Instructor emails each team a client change request; teams must respond by Week 22.

Session B — Hands-On Lab (120 min)

Min	Segment	What to do
120	Capstone sprint	Teams build; the Lead drafts the change-request impact analysis with the SRE's TCO numbers.

Session C — Studio / Team Project (60 min)

Min	Segment	What to do
60	CFO meeting role-play	Teams present a 5-minute TCO/ROI summary; the instructor plays a sceptical CFO.

Key talking points

Saying 'yes' to everything is how FDE projects fail.
Every change request needs impact on time, cost, risk and quality.
ROI must be credible: show assumptions, ranges and sensitivity.
Write so a busy executive can act after reading the first two lines.

Live demo script

Use Playground 6A: vary cache hit rate 0 → 0.8 and show monthly token savings; then change minutes saved per query and show ROI sensitivity.

Whiteboard derivation

Monthly cost = queries × (uncached_in + cached_in + output) prices. ROI = (hours saved × rate) / (tokens + infra + support). Payback = setup cost / monthly net benefit.

Discussion questions & model answers

Q: The client asks for a new feature 2 weeks before go-live. What do you do?
A: Acknowledge, analyse impact (time/cost/risk), offer options (defer to phase 2, swap scope, extend timeline) and get a written decision.

Q: How do you make an ROI number credible?
A: Use client-provided baselines, show assumptions, give ranges, and avoid double-counting benefits.

Common misconceptions

'Change requests are a sign of a bad client.' → They're normal; unmanaged change requests are the problem.
'ROI is just token savings.' → ROI includes labour, risk reduction and revenue impact, minus all costs.

Weekly quiz (answer key)

A change request response should include…
Answer: Impact on time, cost, risk and options — Impact analysis enables a decision.
BLUF means…
Answer: Bottom Line Up Front — Lead with the conclusion.
Prefix caching mainly reduces…
Answer: Input token cost — Cached input tokens are discounted.

Written assignment (min 300 words)

Respond to your team's client change request (300 words): BLUF summary, impact analysis (time/cost/risk/quality), options, and your recommendation.

Look for: BLUF; Impact analysis; Options

Tasks assigned this week

quiz:w21, essay:w21

Week 22: Capstone Sprint 2: Integration, UAT & Observability

Capstone • Modules 22 • Project: Capstone — Week 4 of 6: Integration & UAT

Learning objectives

Integrate all role components into one working prototype.
Run client UAT with new edge cases and fix defects.
Add logging/metrics so the prototype is observable.
Submit capstone code deliverables for auto-testing and review.

Pre-class reading

Module 22 — all sections (data contracts, contract tests, client UAT, observability, SLOs) and both live examples
Optional refresher: Modules 10 (reliability), 12 (dirty data) and 14 (hybrid RAG)
Your role task brief and reviewer feedback in the LMS

Session A — Lecture & Live Demo (90 min)

Min	Segment	What to do
30	Observability	Structured logs, metrics (latency, error rate), traces; what to show the client.
30	Integration patterns	Data contracts between components; contract tests.
30	Instructor office hours	Teams bring blockers; instructor triages.

Session B — Hands-On Lab (120 min)

Min	Segment	What to do
120	Integration & UAT	QA integrates; the team runs UAT in Tab 6 Stage 4 with at least 5 new edge cases; defects logged and fixed.

Session C — Studio / Team Project (60 min)

Min	Segment	What to do
60	Code review	Cross-team code review: each team reviews another team's integrated prototype using the code rubric.

Key talking points

Integration is where plans meet reality — reserve time for it.
Observability is what lets the client trust and operate your system after you leave.
Code review by another team catches what your own team can't see.
Submit early to get auto-test and AI-review feedback before the deadline.

Live demo script

Show the LMS review queue: a submission with auto-test results, AI review comments, and the instructor's rubric scoring.

Whiteboard derivation

Draw the team's component diagram with interfaces labelled by data contract (function name, input schema, output schema).

Discussion questions & model answers

Q: What makes a good data contract between components?
A: Explicit function signature, input/output schemas, error behaviour, and a contract test.

Q: What should you log in a regulated system?
A: Request IDs, decisions, timings, redaction counts — never raw PII.

Common misconceptions

'Logging everything is safest.' → Logging raw PII creates a compliance breach; log metadata, not personal data.
'Integration can happen on the last day.' → Late integration is the top cause of failed demos.

Weekly quiz (answer key)

What should NOT be written to logs?
Answer: Raw national ID numbers — PII in logs is a breach.
Contract tests verify…
Answer: Component interfaces match agreed schemas — Interfaces.
Best time to submit for AI review?
Answer: Early, to iterate on feedback — Feedback loops.

Written assignment (min 250 words)

Sprint 2 status (250 words) from your role: integration status, UAT results, defects fixed, remaining risks.

Look for: Integration; UAT; Risks

Tasks assigned this week

quiz:w22, essay:w22

Week 23: Capstone Hardening: Security Review, Chaos Drill & Presentation Rehearsal

Capstone • Modules 23 • Project: Capstone — Week 5 of 6: Hardening & rehearsal

Learning objectives

Pass a simulated CISO security review of the capstone prototype.
Run a chaos drill and document recovery.
Rehearse the steering-committee presentation with feedback.
Submit all role documents for review.

Pre-class reading

Module 23 — all sections (threat modelling, OWASP LLM Top 10, findings & data-protection/CERT-In, chaos engineering, incident response, rehearsal, viva prep)
Optional refresher: Modules 16 (RBAC & guardrails) and 18 (evaluation)
Presentation rubric in the LMS

Session A — Lecture & Live Demo (90 min)

Min	Segment	What to do
45	Security review	Each team's Security Engineer presents controls; instructor (CISO) probes.
45	Chaos drill	Instructor injects faults; SRE leads recovery; team logs timeline.

Session B — Hands-On Lab (120 min)

Min	Segment	What to do
60	Fix sprint	Fix findings from the security review and chaos drill.
60	Presentation rehearsal	Full dry run; another team gives feedback using the presentation rubric.

Session C — Studio / Team Project (60 min)

Min	Segment	What to do
60	Viva preparation	Students practise answering individual technical questions on their role's component.

Key talking points

Security and resilience findings are normal — fixing them quickly is what clients notice.
Rehearse with a timer; executives won't wait.
Each team member must be able to explain their own component in the viva.
Finalise documents now; Week 24 is for presenting, not writing.

Live demo script

Run Playground 6B live with 503 + drift and have the class narrate the recovery like an incident commander.

Whiteboard derivation

Draw an incident timeline: detect → triage → mitigate → resolve → review, with timestamps from the drill.

Discussion questions & model answers

Q: How do you present a security finding you haven't fixed yet?
A: Transparently: severity, compensating control, fix date and owner.

Q: What makes a rehearsal useful?
A: Real timing, a critical audience, and a written list of changes afterwards.

Common misconceptions

'Hiding known issues makes the demo look better.' → Executives lose trust permanently if issues surface later.
'Only the Lead needs to present well.' → Every role presents its part and answers questions.

Weekly quiz (answer key)

An unfixed security finding should be presented with…
Answer: Severity, compensating control, owner and date — Transparency builds trust.
Incident review should be…
Answer: Blameless and action-oriented — Learning culture.
In the viva, each student explains…
Answer: Their own component in depth — Individual accountability.

Written assignment (min 300 words)

Chaos drill & security review report (300 words): faults injected, detection time, recovery steps, findings, and fixes made.

Look for: Faults & detection; Recovery; Findings & fixes

Tasks assigned this week

quiz:w23, essay:w23

Week 24: Steering Committee Final Presentations, Viva & Course Retrospective

Capstone • Modules 24 • Project: Capstone — Week 6 of 6: Final presentations & viva

Learning objectives

Present the capstone to a steering committee and secure a go/no-go decision.
Defend individual technical decisions in a viva.
Reflect on growth across the 24 weeks and build a portfolio entry.

Pre-class reading

Module 24 — all sections (steering-committee decisions, SCQA, ROI sensitivity, executive Q&A, viva defence, handover, portfolio)
Optional refresher: Module 21 (capstone tracks)
Your team's final deck and all reviewer feedback

Session A — Lecture & Live Demo (90 min)

Min	Segment	What to do
90	Final presentations (part 1)	15 min presentation + 10 min executive Q&A per team; panel scores with the presentation rubric.

Session B — Hands-On Lab (120 min)

Min	Segment	What to do
60	Final presentations (part 2)	Remaining teams.
60	Individual viva	5–7 minutes per student on their role component. Record each score (0–100) and notes in LMS → Peer Evaluation & Viva; it counts as its own gradebook component.

Session C — Studio / Team Project (60 min)

Min	Segment	What to do
60	Course retrospective & portfolio	Students submit the capstone peer evaluation in LMS → My Team & Role, run a blameless retrospective and draft their portfolio entry; the instructor shares cohort results and next steps.

Key talking points

A great final presentation tells a story: problem → solution → evidence → risks → decision.
The viva confirms individual understanding — it protects fairness in team grading.
Your capstone is a portfolio asset: describe outcomes in numbers.
FDE careers reward people who can both build and communicate.

Live demo script

Show an example generated deck from Tab 6 Stage 5 and point out the live-metrics slide and the decision slide.

Whiteboard derivation

Draw the presentation arc: Hook (client pain) → Solution → Live evidence → Security & cost → Risks → Ask.

Discussion questions & model answers

Q: What if the committee says 'no-go'?
A: Capture the reasons, propose a remediation plan with dates, and request a follow-up review — a professional no-go is still a successful engagement outcome.

Q: How do you write a portfolio entry?
A: Context, your role, what you built, measurable outcomes, technologies, and a link to code or a demo.

Common misconceptions

'The demo is the presentation.' → The demo is evidence; the presentation is about the decision.
'Team grade = individual grade.' → Individual viva and peer evaluation adjust individual grades.

Weekly quiz (answer key)

The final slide should be…
Answer: The decision request with risks — Executives need to decide.
The viva exists to…
Answer: Verify individual understanding — Fair individual assessment.
A strong portfolio entry includes…
Answer: Measurable outcomes and your role — Outcomes show impact.

Written assignment (min 400 words)

Final portfolio entry (400 words): client context, your role(s) across both engagements, what you built, measurable outcomes, what you learned, and what you'd do next.

Look for: Context & role; Outcomes; Learning

Tasks assigned this week

quiz:w24, essay:w24

AI Forward Deployed Engineering — 24-Week Professional Programme

Programme phases

Delivery modes

Grading scheme

FDE team roles

FDE Engagement Lead

Data & Integration Engineer

Security & Compliance Engineer

AI & Decision Engineer

Integration & QA Engineer

Platform & Reliability Engineer (SRE)

Review rubrics

Code

Document

Presentation

How to run a cohort in the LMS

Week 1: Orientation, the FDE Role & Python Data Structures

Learning objectives

Pre-class reading

Session A — Lecture & Live Demo (90 min)

Session B — Hands-On Lab (120 min)

Session C — Studio / Team Project (60 min)

Key talking points

Live demo script

Whiteboard derivation

Discussion questions & model answers

Common misconceptions

Weekly quiz (answer key)

Written assignment (min 250 words)

Tasks assigned this week

Week 2: Defensive Python: Errors, JSON/File I/O & Regex for KYC Data

Learning objectives

Pre-class reading

Session A — Lecture & Live Demo (90 min)

Session B — Hands-On Lab (120 min)

Session C — Studio / Team Project (60 min)

Key talking points

Live demo script

Whiteboard derivation

Discussion questions & model answers

Common misconceptions

Weekly quiz (answer key)

Written assignment (min 300 words)

Tasks assigned this week

Week 3: Object-Oriented Python, Dataclasses & Pydantic-Style Validation

Learning objectives

Pre-class reading

Session A — Lecture & Live Demo (90 min)

Session B — Hands-On Lab (120 min)

Session C — Studio / Team Project (60 min)

Key talking points

Live demo script

Whiteboard derivation

Discussion questions & model answers

Common misconceptions

Weekly quiz (answer key)

Written assignment (min 250 words)

Tasks assigned this week

Week 4: Relational Databases & SQL for Enterprise Ledgers

Learning objectives

Pre-class reading

Session A — Lecture & Live Demo (90 min)

Session B — Hands-On Lab (120 min)

Session C — Studio / Team Project (60 min)

Key talking points

Live demo script

Whiteboard derivation

Discussion questions & model answers

Common misconceptions

Weekly quiz (answer key)

Written assignment (min 300 words)

Tasks assigned this week

Week 5: How the Web Works: HTTP, REST, Idempotency Keys & JWT

Learning objectives

Pre-class reading

Session A — Lecture & Live Demo (90 min)

Session B — Hands-On Lab (120 min)

Session C — Studio / Team Project (60 min)

Key talking points

Live demo script