Forward Deployed Engineer: AI for the Infrastructure Estate

Embed with a client and land AI into how they run their datacenter, network and workplace — assess, frame, deliver, integrate and govern. 10 modules for infrastructure people who guide and build, not just advise.

• Audience: Infrastructure Engineers · Platform & MSP Delivery Leads · Solutions/Field Engineers · Ops Leads embedding AI with clients
• Level: Intermediate (infrastructure experience assumed; no ML background required)
• Duration: 10 weeks · 1 module/week · 5–7 h/week
• Modules: 10
• Pass mark: 70%
• Interactive version: https://ragentic.netlify.app/#/courses/fde-infrastructure

This file is generated from the course data by scripts/build-notes.mjs. Edit the course data, not this file.

The world of this course

Organisation: Cranfield Group

Your client for the next ten weeks: Cranfield Group, a mid-market distribution and light- manufacturing firm — two owned datacenters plus a colo they are half-migrated into, an SD-WAN across 42 sites and 5 plants, and roughly 6,000 endpoints. You are embedded from an infrastructure-support practice to make AI actually land in how Cranfield runs the estate — not to sell a platform. Dilan, the Head of Infrastructure, was sold an "AIOps platform" two years ago that became shelfware, and will believe outcomes, not slides. Your own delivery lead wants a repeatable land-and-expand play out of this. Everything you build is one accumulating engagement, defended to the room in Week 10.

Phase 1 — Land & Understand (weeks 1–2)

Module 1 — The Infrastructure FDE: Role, Trust & AI Foundations

Guiding question: What is a forward deployed engineer on an infrastructure estate — and how do I earn a sceptical sponsor's trust?

Outcome: Define the FDE model and separate it from consulting, pre-sales, and traditional MSP break-fix. Explain forward deployment (embed, iterate, earn trust) versus one-shot tool implementation. Draw the co-pilot vs autopilot line for infrastructure specifically, and establish a shared AI-in-operations vocabulary and the FDE duty of care.

Estate lens: You are the person the infrastructure-support firm embeds with a client to make AI actually land in how they run the estate — credible enough to assess it, hands-on enough to build the integration, disciplined enough to be trusted near production. Your deliverable is not a deck; it is a working, governed change that outlasts you. Dilan has been sold "AIOps" before and got shelfware. Trust, earned in weeks, is the whole job.

Apply-at-work mission — Engagement charter + sealed baseline: Write the Cranfield engagement charter: your mission, the trust you must earn from Dilan, and what "success by week 10" looks like. Add a stakeholder power/interest map of the cast. Then seal a baseline: in under 150 words, your current unassisted answer to "what can AI realistically do for infrastructure operations, and what can it not?" — Module 10 reopens it.

Reflection: Where did my mental model of "AI for infrastructure" turn out to be marketing rather than mechanism? Whose trust on this client will be hardest to earn, and why?

Resources

• LinkedIn Learning — Forward Deployed Engineering in the Age of AI — Vinoo Ganesh's short course on what forward deployment is and why it differs from SaaS implementation — the mindset this whole programme runs on.
  • Explain forward deployment versus one-shot tool implementation
  • Say why trust, earned on-site, is the FDE's real deliverable
  • Describe how an FDE translates real needs into technical requirements
• Andrej Karpathy — Intro to Large Language Models — The one-hour plain-language mental model of what an LLM actually is — enough AI foundation to reason about where it fits an estate, without the maths.
  • Hold a working mental model of what an LLM is and is not
  • Explain fluency-without-truth well enough to set client expectations
  • Ground later AI-in-operations decisions in how the model really works
• Microsoft Learn — Fundamentals of Generative AI — Short, free, enterprise-flavoured grounding in the vocabulary your client's governance and security people will use.
  • Speak the enterprise generative-AI vocabulary stakeholders use
  • Separate what the model does from what the platform wraps around it
  • Place generative AI against the automation the estate already runs
• Anthropic — Building Effective Agents — The workflow-vs-agent distinction and the co-pilot/autopilot line — from a frontier lab. Read for the judgement, not the code.
  • Make the workflow-vs-agent distinction on a whiteboard
  • Draw the co-pilot vs autopilot line for an infrastructure task
  • Name the guardrail any acting agent needs near production
• The forward deployed engineer role — curated search — Read two or three credible accounts of the FDE role (Palantir-style and modern AI-lab versions). Watch for how it differs from consulting and pre-sales.
  • Contrast the FDE with consulting, pre-sales and MSP break-fix
  • Recognise the failure mode of AI-theatre and shelfware
  • Form your own line on what an infrastructure FDE is accountable for

In-world ticket queue

Day one on the Cranfield account. The kickoff is done; the goodwill is thin. Dilan opened with "the last lot sold us a dashboard nobody opened" and gave you ten weeks. Your inbox already has a competing appliance quote forwarded by Tom, an eager "can AI just auto-resolve tickets?" from Priya, and a one-line note from Ken: "before anything connects to our data, I want to know what and where."

Project — Engagement charter + sealed baseline (Capstone component)

Write the Cranfield engagement charter: your mission, the specific trust you must earn from Dilan (who was burned by shelfware), and what "success by week 10" looks like as observable outcomes. Add a power/interest stakeholder map of the six-person cast — who decides, who can block, who to win first. Then seal a baseline: in under 150 words, your current unassisted answer to "what can AI realistically do for infrastructure operations, and what can it not?" Date it and set it aside — Module 10 reopens it.

Deliverable: fde/m01-charter-and-baseline.md — the charter, the stakeholder map, and the dated sealed baseline. This is the first component of your accumulating engagement pack.

Assessment rubric

Scenario drills

Drill 1. Kickoff. Dilan opens with "the last lot sold us a dashboard nobody opened" (CRN-0001) and gives you ten weeks.

Task: Write the two-sentence reply that neither dismisses the past failure nor over-promises, and names the one thing you'll do differently. Then state the single Week-10 outcome you'd put your name against.

Drill 2. Ken (CRN-0003): "Before anything connects to our data, I want to know what and where."

Task: List the three questions you must answer for Ken before any tool touches Cranfield data, and say why each matters more than the demo he hasn't asked for.

Knowledge check (12 questions)

Self-test prompts. Answers and explanations are not published here — take the quiz at https://ragentic.netlify.app/#/courses/fde-infrastructure to check yourself.

1. The clearest difference between a forward deployed engineer and a traditional consultant is that the FDE…

1. Charges the client a considerably higher day rate than the consultant does
2. Embeds to build and land the change
3. Works remotely from the head office
4. Writes the strategy slide deck

2. Forward deployment differs from a normal SaaS/tool implementation mainly because it…

1. It simply installs the software faster
2. It iterates with the client to fit real needs and earn their trust over time
3. It needs no product configuration
4. It always costs less than a rollout

3. For an infrastructure FDE, the "co-pilot vs autopilot" line is about…

1. Whether the underlying tool happens to have a chat interface bolted onto it
2. Whether AI proposes for a human or acts alone
3. Which cloud region the model happens to be hosted in
4. How quickly the model returns its answer to you

4. Dilan was "burned by shelfware" before. The main lesson for your engagement is that…

1. You should quietly avoid ever mentioning the previous failed vendor to him
2. Trust is earned through measured outcomes
3. He approves anything to avoid conflict
4. The old tool just needs reinstalling

5. An LLM sounds fluent and confident even when wrong because…

1. It is deliberately trying to mislead whoever happens to be asking it
2. Fluent plausible text is the goal, not truth
3. Only the cheaper, older models tend to do this
4. It briefly lost its connection

6. "AI theatre" on an infrastructure account most often looks like…

1. A carefully governed pilot
2. An impressive demo that solves no real, owned problem and quietly becomes shelfware
3. A boring automation that saves hours
4. A tightly scoped, measured proof

7. The FDE's "duty of care" on a client estate primarily means…

1. Making sure you always adopt the very newest model available on the market
2. Not letting AI create risk the client cannot see
3. Keeping your billed day rate as low as it can possibly go
4. Putting absolutely everything into one very long report

8. The strongest first move with a sceptical sponsor like Dilan is to…

1. Promise a dramatic, estate-wide transformation within the first few weeks
2. Agree what a measurable success looks like
3. Build the flashiest pilot you can immediately
4. Ask him to trust the process and wait

9. A stakeholder power/interest map is useful because it…

1. It quietly replaces the need to actually go and talk to any of the people
2. Shows who can block you and who to win first
3. Is mandatory for every IT project
4. Measures how technically skilled each person is

10. Which is genuinely NOT part of the infrastructure FDE role as this course frames it?

1. Assessing the client's estate
2. Training a foundation model from scratch
3. Guiding the client and building the integration work
4. Governing the AI once it runs

11. The sealed baseline you write in Module 1 exists so that…

1. The course simply needs a week-one assignment for the tutor to grade
2. You can honestly measure how your thinking changed
3. Your manager simply needs a document to file for compliance
4. You can reuse it word-for-word as your final answer

12. Treating the engagement as "a governed change that outlasts you" mainly implies…

1. You should stay embedded with them forever
2. The client's own team can keep running it long after you have left
3. The solution must use the largest model
4. You avoid writing anything down

Module 2 — Reading the Estate: Assessment & Discovery

Guiding question: Before I recommend anything, what is actually in this estate, where does it hurt, and where does usable data already live?

Outcome: Run a structured assessment across datacenter, network and workplace. Inventory the data sources that matter — telemetry, event/alert streams, tickets, logs, configs, topology, CMDB — and rate each for AI-readiness. Establish a measured baseline (MTTR, alert volume, ticket mix, capacity headroom) you can later prove improvement against.

Estate lens: Discovery for infrastructure is not a workshop of opinions; it is reading the estate's own exhaust. The CMDB is ~70% true, the monitoring is a three-tool patchwork, and the pain everyone complains about is not always where the data is. Find both. The baseline you take this week is the honest yardstick your Module-10 outcomes get measured against — take it properly or the whole engagement's "impact" is a feeling.

Apply-at-work mission — Estate map, data inventory & baseline: Build the Cranfield estate + data inventory: what telemetry, tickets, configs and CMDB data exist, the trust level of each, and where the CMDB lies. Record a measured baseline for the pains you will target. Mark every unknown with a "?" rather than a guess — the gaps are the engagement. 🎯 Completes Capstone Milestone 1.

Reflection: Which "obvious" pain point turned out to have no usable data behind it? Which data source surprised me by being richer than expected?

Resources

• Atlassian — ITSM incident & request management — A clean refresher on the ticket/incident/request lifecycle you'll read Cranfield's ServiceNow data against during discovery.
  • Recognise the incident/request/change data an estate generates
  • Know what a healthy ITSM record contains before you mine it
  • Map where AI could help each lifecycle stage — and where it can't
• Configuration management & the CMDB — curated search — Read one credible piece on why CMDBs drift out of date. Cranfield's is ~70% trustworthy — assume yours is too until proven otherwise.
  • Explain why a CMDB is rarely fully trustworthy
  • Plan to reconcile CMDB claims against live telemetry
  • Treat inventory as a data-quality problem, not a given
• Google SRE Book — Monitoring distributed systems — The four golden signals and the difference between symptoms and causes — the vocabulary for reading a monitoring patchwork like Cranfield's.
  • Use symptom-vs-cause and the golden signals when reading telemetry
  • Judge whether an alert stream is signal or noise
  • Identify which monitoring data is AI-ready and which is junk
• UK ICO — anonymisation and pseudonymisation guidance — Estate telemetry, tickets and logs are identity-dense (hostnames, users, IPs). The formal grounding for the sanitisation discipline you'll need before any of it reaches a model.
  • Distinguish anonymisation from pseudonymisation for estate data
  • Spot the identity payload in telemetry, tickets and logs
  • Justify a sanitisation rule to a DPO in their own terms

In-world ticket queue

Discovery week. The CMDB export arrived and roughly a third of it is wrong. Monitoring is three tools that disagree. Everyone "knows" what hurts most, and no two people agree. You need the estate's own data, not its opinions — and a baseline you can be measured against in Week 10.

Project — Estate map, data inventory & baseline (Capstone component)

Build Cranfield's current-state estate map across datacenter, network and workplace, and a data inventory: for each source (telemetry, event/alert streams, tickets, logs, configs, CMDB) record what it is, how trustworthy it is, and rate it for AI-readiness. Then record a measured baseline for the pains you expect to target — MTTR, alert volume, ticket mix, capacity headroom — the honest yardstick Module 10 measures against. Mark every unknown with a "?" rather than a guess.

Deliverable: fde/m02-estate-map-and-baseline.md — the estate map, the rated data inventory, and the dated baseline with question marks preserved. Second component of the engagement pack.

Assessment rubric

Scenario drills

Drill 1. The CMDB export lands and ~30% is wrong (CRN-0011): decommissioned hosts present, live services missing.

Task: Describe how you'd reconcile it against something more trustworthy in a week, and name the one class of error you'd check first before trusting any of it for a pilot.

Drill 2. Three monitoring tools disagree on whether DC-1 is healthy (CRN-0012); Marisol asks which to believe.

Task: Give the two-line rule you'd use to decide the source of truth per signal, and one question that would settle it for the specific case of DC-1 capacity.

Knowledge check (12 questions)

Self-test prompts. Answers and explanations are not published here — take the quiz at https://ragentic.netlify.app/#/courses/fde-infrastructure to check yourself.

1. Discovery on an infrastructure estate should rely most on…

1. A workshop where stakeholders get together and share their opinions about what hurts
2. The estate's own telemetry, tickets and configs
3. The vendor's recommended reference architecture diagram
4. The single most senior person's gut intuition about the estate

2. Cranfield's CMDB is about 70% trustworthy. The right response is to…

1. Treat it as authoritative
2. Reconcile every load-bearing claim in it against live telemetry and the ticket record
3. Discard it entirely as useless
4. Ask the client to rebuild it first

3. The point of taking a measured baseline in Module 2 is to…

1. Fill in a required field on the project template so the pack looks complete
2. Let Week-10 prove improvement honestly
3. Give the CFO a number to approve the budget right now today
4. Compare against benchmarks

4. The "four golden signals" of monitoring are most useful to an FDE for…

1. Choosing which single monitoring vendor the client should standardise everything onto
2. Judging whether an alert stream is signal or noise
3. Costing the observability stack
4. Deciding NOC headcount

5. Before any Cranfield telemetry or ticket data reaches a model, you must…

1. Get written sign-off from the entire board before anything at all can happen
2. Strip identity: hostnames, users, IPs
3. Convert everything into one single spreadsheet first
4. Wait until the monitoring tools are fully consolidated

6. A data source that is high-volume but low-trust (like a noisy alert feed) should be…

1. Used immediately
2. Flagged low AI-readiness until its signal is actually proven out on real data
3. Deleted from the inventory
4. Treated like a clean source

7. The most useful thing to do with a data source you cannot yet assess is to…

1. Assume it is basically fine and just move quickly on to the next source
2. Mark it as unknown rather than guessing
3. Leave it out of the inventory entirely for now
4. Rate it high so things look complete

8. Symptom-versus-cause matters in discovery because the loudest pain…

1. Is always the single most valuable thing you could possibly automate first
2. May be a symptom whose data lives elsewhere
3. Should just be ignored
4. Is caused by the tool

9. Cranfield runs SolarWinds, Datadog and Zabbix that disagree. For discovery this means…

1. You must pick just one of them and delete the other two immediately
2. Reconcile them to find the truth
3. The client is clearly incompetent at monitoring their estate
4. Monitoring data cannot be used for AI

10. The estate map is most valuable to the engagement as…

1. A one-off diagram
2. A living artifact that every later module in the engagement builds on and enriches
3. Evidence you did the work
4. A doc only you read

11. The biggest risk of skipping a proper baseline is that…

1. The overall project plan ends up being very slightly shorter than it was
2. You cannot honestly prove impact
3. The client asks for a bit more documentation later
4. The tools generate more alerts

12. When Ken asks "where does the telemetry and ticket data actually live?", the honest FDE answer is…

1. "Wherever the particular AI tool happens to need it to physically be at the time"
2. A mapped account of each source and where it lives
3. "That's the vendor's problem"
4. "We'll figure it out later"

Phase 2 — Find & Frame (weeks 3–4)

Module 3 — Use-Case Mining, Value & Risk Triage

Guiding question: Across the estate, where does AI genuinely earn its place — and what is each opportunity worth against its risk?

Outcome: Build the infrastructure-AI opportunity catalogue (AIOps and event correlation, observability and anomaly, capacity forecasting, config and change automation, ticket deflection and knowledge, security operations, DC energy). Score each on value × data-readiness × risk, set a quantified KPI hypothesis for the shortlist, and make the buy-vs-integrate-vs-build call. Kill the solution-first ideas early.

Estate lens: The fastest way to become the next shelfware is to demo a clever AI thing nobody needed. The FDE's core judgement is triage: which of the estate's real pains has both high value and enough usable data to be provable, and should you buy a tool, integrate one, or build. A quantified KPI hypothesis — "cut DC-1 alert noise 40% without hiding a real incident" — is what turns a good idea into something you can be held to.

Apply-at-work mission — Opportunity map + KPI hypotheses: Score eight candidate opportunities for Cranfield on value × data-readiness × risk. Shortlist three, and for each state a quantified KPI hypothesis measured against your Module-2 baseline, a risk tier, and a buy/integrate/build recommendation with rationale.

Reflection: Which opportunity was I tempted by because it was interesting rather than valuable? Which "boring" one scored highest, and why?

Resources

• IBM — What is AIOps? — A vendor-neutral grounding in the AIOps opportunity space — event correlation, anomaly, noise reduction — so you can name candidates for Cranfield without buying the hype.
  • Name the main AIOps opportunity categories for an estate
  • Separate a real correlation use case from a dashboard
  • Judge which AIOps claims need data you may not have
• PagerDuty — What is alert fatigue? — Why DC-1's 900-alerts-a-night problem is worth money to fix — and why "fewer alerts" is a dangerous goal if you cannot prove nothing real was hidden.
  • Quantify the operational cost of alert fatigue
  • Frame noise reduction as a value opportunity with a risk
  • Set a KPI that rewards signal, not just silence
• ProductPlan — The RICE scoring model — A clean prioritisation frame you can adapt to value × data-readiness × risk. Borrow the discipline of scoring, not the exact factors.
  • Adapt a scoring model to value, data-readiness and risk
  • Force a ranked shortlist instead of a wish list
  • Defend why one opportunity beats another with numbers
• Build vs buy vs integrate enterprise AI — curated search — Read two credible takes on the buy/integrate/build decision for enterprise AI. For an FDE on an estate, integrate is usually the default and build the exception.
  • State when to buy, integrate, or build an AI capability
  • Recognise why "build" is rarely the right first move
  • Tie the decision to data ownership and time-to-value
• NIST AI Risk Management Framework — The reference for tiering AI risk. Use it to justify why a security-ops or auto-change idea carries more risk than ticket deflection.
  • Assign a defensible risk tier to an AI opportunity
  • Explain why some estate use cases need heavier controls
  • Speak the risk vocabulary a CISO like Ken will accept

In-world ticket queue

Framing week. Now the pet ideas surface: Priya wants auto-resolve, a plant manager wants "predictive everything", and the vendor swears their appliance does it all. Tom wants to know which of these is worth money. Your job is triage — value against risk against whether the data even exists.

Project — Opportunity map + KPI hypotheses (Capstone component)

Score eight candidate AI opportunities for Cranfield across datacenter, network and workplace on value × data-readiness × risk, using the Module-2 inventory as the readiness input. Shortlist three. For each of the three, state a quantified KPI hypothesis measured against your Module-2 baseline (e.g. "cut DC-1 alert noise 40% without suppressing a real incident"), assign a risk tier, and make a buy / integrate / build recommendation with a one-line rationale. Explicitly name one solution-first idea you killed and why.

Deliverable: fde/m03-opportunity-map.md — the scored catalogue, the shortlist of three with KPI hypotheses and risk tiers, the buy/integrate/build calls, and the killed idea. Third component of the engagement pack.

Assessment rubric

Scenario drills

Drill 1. Tom forwards a competing appliance quote and asks "which two of these actually save money, and how much?" (CRN-0023).

Task: Pick the two Cranfield opportunities you would put in front of Tom, and for each give the one number you would commit to against the Module-2 baseline. Say what you would NOT promise.

Drill 2. Priya asks "can we at least start with password/VPN deflection?" (CRN-0024) while a plant wants "predictive everything".

Task: Rank these two on value × data-readiness × risk in three sentences, and say which you shortlist first and why.

Knowledge check (12 questions)

Self-test prompts. Answers and explanations are not published here — take the quiz at https://ragentic.netlify.app/#/courses/fde-infrastructure to check yourself.

1. The core triage of value × data-readiness × risk exists mainly to…

1. Make the opportunity catalogue look more thorough than it really is to the client
2. Stop you building things nobody can prove
3. Ensure the newest available model gets used somewhere
4. Give the procurement team a longer shortlist to review

2. The fastest route to becoming the next shelfware is to…

1. Ship a boring automation
2. Demo a clever AI thing that nobody actually needed and that no one will own
3. Score ideas against the baseline
4. Recommend integrating a tool

3. A quantified KPI hypothesis matters because it…

1. Fills in an otherwise empty field on the opportunity-scoring template
2. Turns an idea into a measurable target
3. Reliably impresses the finance team in the room
4. Shortens the plan

4. The plant's "predictive everything" request is best treated as…

1. A top priority the team should just start building on right away immediately
2. Hype until the data to predict on is shown to exist
3. Proof the client gets AI
4. A reason to buy the appliance

5. You would lean toward BUYING a tool when…

1. The requirement is genuinely unusual and no product exists for it at all
2. A mature product fits and integrates cheaply
3. You want to keep maximum control over all of the code yourself
4. The data is far too sensitive to ever be moved anywhere

6. You would consider BUILDING (the rare case) only when…

1. A product nearly fits and could be configured
2. The need is specific and valuable and genuinely no product or integration fits it
3. The vendor demo looked impressive
4. You have spare time in the plan

7. A high-value opportunity with no usable data behind it should be…

1. Parked until the data to support it exists
2. Shortlisted anyway because the value looks high
3. Built using synthetic data as a starting point
4. Sold to the CFO

8. Ticket deflection scored high for Cranfield mainly because it is…

1. It is simply the newest and most fashionable thing on the whole opportunity list
2. High-volume, repetitive, and rich in data from Priya's runbooks
3. It is low-risk only
4. It was the vendor's idea

9. Security-operations AI warrants a heavier risk tier because…

1. It happens to be a particularly fashionable area right now among vendors
2. False negatives are costly; data is sensitive
3. It usually needs a considerably bigger model to work
4. The vendor strongly recommends treating it that way

10. Scoring opportunities against the Module-2 baseline matters because…

1. The scoring template asks for it
2. A value claim only means something when it is tied to a real dated before-number
3. It fills the slide
4. It flatters the demo

11. The right output of the triage step is…

1. A single pet idea to take straight into build without further comparison
2. A ranked shortlist with a reason for each pick
3. Every idea kept in the catalogue for possible use later on
4. A vendor quote

12. Killing a solution-first idea early is best read as a sign of…

1. A worrying kind of indecision that clients will quickly come to distrust
2. FDE judgement that protects the client's trust and budget
3. A simple lack of ambition
4. A quiet fear of building

Module 4 — Solution Blueprint & the Readiness Gate

Guiding question: How do I turn a chosen opportunity into a blueprint I can build safely — and prove I am actually ready to start?

Outcome: Produce a solution blueprint: architecture, scope, dependencies, delivery plan, and acceptance criteria. Reason about blast radius and the advisory-before-action ladder for anything touching production. Then pass the readiness gate — explicit, checkable statements of data/access assumptions, evaluation criteria, and risk controls, without which implementation does not begin.

Estate lens: This module is the bridge from consulting conversation to engineering. A learner can understand a client's problem perfectly and still fail in delivery if they never converted it into a blueprint with data contracts, acceptance criteria, and controls. The readiness gate is a real stage-gate, not a formality: if you cannot write your data-access assumptions, eval criteria and risk controls as checkable statements, you are not ready to build — and saying so is the senior move.

Apply-at-work mission — Blueprint + checkable readiness gate: Produce the Cranfield solution blueprint (architecture, scope, dependencies, delivery plan, acceptance criteria) for your top pilot. Then write the readiness gate as checkable statements: data/access assumptions, evaluation criteria, risk controls, and the human-approval path. A colleague should be able to tick each one true or false. 🎯 Completes Capstone Milestone 2.

Reflection: Which assumption did writing it down as a checkable statement expose as wishful? What would break first if I skipped the gate and started building?

Resources

• AWS — Well-Architected Framework — The reference for reasoning about a solution across reliability, security, and operations — adapt its discipline to your Cranfield pilot blueprint.
  • Structure a blueprint across reliability, security and ops
  • Surface dependencies and failure points before building
  • Justify architecture choices a client can review
• Atlassian — Acceptance criteria — How to write acceptance criteria that make "done" checkable. The readiness gate lives or dies on statements a colleague can tick true or false.
  • Write acceptance criteria as checkable statements
  • Turn a vague goal into a testable definition of done
  • Separate what must be true from what would be nice
• Google SRE Workbook — Canarying releases — The discipline of limiting blast radius when rolling out change — directly applicable to how an AI-proposed action should reach production.
  • Reason about blast radius for an AI-driven change
  • Design a staged, reversible path to production
  • Decide what to canary before trusting an action
• Evaluating LLM applications — curated search — Read two credible pieces on building evals for an LLM feature. You must be able to state eval criteria as part of the readiness gate before any build begins.
  • Define eval criteria for an AI feature before building it
  • Choose measures that reflect real acceptance, not vibes
  • Make evals part of the go/no-go, not an afterthought
• NIST AI RMF — Playbook (Govern & Map) — Concrete control language for the risk-controls half of your readiness gate — the words Ken will expect to see in writing before anything connects.
  • Express risk controls as concrete, checkable statements
  • Map data-access assumptions to least-privilege controls
  • Give a CISO the written controls before connecting anything

In-world ticket queue

Blueprint week. Dilan has approved a shortlist in principle, but Ken will not let anything start without controls, and Marisol wants to see exactly how a change gets proposed and approved. You cannot enter build until the assumptions, evals and risk controls are written down and checkable.

Project — Blueprint + checkable readiness gate (Capstone component)

Produce the Cranfield solution blueprint for your top shortlisted pilot: architecture, scope, dependencies, delivery plan, and acceptance criteria. Reason explicitly about blast radius and place the pilot on the advisory-before-action ladder. Then write the readiness gate as checkable statements grouped into data/access assumptions, evaluation criteria, risk controls, and the human-approval path — each phrased so a colleague can tick it true or false. If any statement cannot yet be ticked true, say so: that is the gate doing its job.

Deliverable: fde/m04-blueprint-and-readiness-gate.md — the blueprint and the readiness gate as checkable statements, with any un-tickable items flagged. Fourth component of the engagement pack; completes Capstone Milestone 2.

Assessment rubric

Scenario drills

Drill 1. Ken: "show me the data-access, eval and risk controls in writing" before anything starts (CRN-0032).

Task: Draft three checkable readiness-gate statements — one data-access, one eval, one risk control — each phrased so Ken can tick it true or false. Flag any you cannot yet tick true.

Drill 2. Marisol: "walk me through how an AI-proposed change gets approved" (CRN-0033).

Task: Describe the advisory-before-action path for one Cranfield change: what the AI proposes, what it must show, who approves, and where the hard stop is.

Knowledge check (12 questions)

Self-test prompts. Answers and explanations are not published here — take the quiz at https://ragentic.netlify.app/#/courses/fde-infrastructure to check yourself.

1. This module is the bridge from consulting conversation to…

1. A noticeably longer and more detailed slide deck for the sponsor
2. Engineering you can build from
3. A formal vendor selection exercise
4. A recurring weekly status meeting

2. The readiness gate is best understood as…

1. A formality to sign
2. A real stage-gate: no build begins until every assumption is checkable
3. A document for the client
4. A vendor requirement

3. Acceptance criteria are useful mainly because they…

1. They are strictly required by the template process the team happens to follow
2. Make "done" checkable rather than opinion
3. Reliably impress the sponsor in the review meeting
4. Fill the plan

4. Reasoning about blast radius before building means asking…

1. How recent and how large the underlying model the team has chosen actually is
2. What a wrong action could touch, and how far damage spreads
3. Which vendor is cheapest
4. How fast it runs

5. The "advisory-before-action" ladder says that near production you should…

1. Automate the action first and then add human oversight later if it turns out to be needed
2. Start with AI advising, and earn each rung
3. Let the agent act and simply log what it did afterwards
4. Skip straight to full autonomy for the sake of speed

6. A data-access assumption belongs in the readiness gate as…

1. A hope
2. A checkable statement a colleague can mark true or false against reality
3. A vendor promise
4. A verbal agreement

7. Eval criteria should be defined…

1. Only after the pilot has been fully built, to see how well it happened to do
2. Before the build, as part of the go/no-go
3. Only if the client specifically asks for them
4. By the vendor

8. Writing an assumption down as a checkable statement most often…

1. It largely wastes time that would be far better spent actually building the thing
2. Exposes which "facts" were actually wishful thinking
3. It slows the client down
4. It duplicates the blueprint

9. The human-approval path in the gate specifies…

1. Who exactly should be assigned the blame if the whole thing goes badly wrong
2. Who approves an action, and when
3. The main vendor contact for the project
4. The order the demo should be given in

10. If you cannot write your risk controls as checkable statements, the right move is to…

1. Start building and refine later
2. Say you are not ready — declaring that honestly is the senior move here
3. Ask the vendor to write them
4. Skip the controls entirely

11. Naming dependencies in the blueprint matters because…

1. It usefully lengthens the overall document and makes it look more rigorous to the client
2. An unnamed dependency is what blocks the build
3. Clients simply expect to be given a fairly long list
4. It looks rigorous

12. Scope in the blueprint is best kept…

1. Kept as broad as it possibly can be, so as to properly show the client real ambition
2. Bounded to one provable pilot, the rest as later phases
3. Left undefined until the client decides
4. Whatever the vendor scopes

Phase 3 — Prepare the Ground (weeks 5)

Module 5 — Cross-Estate AI Delivery Foundation

Guiding question: What delivery primitives must be in place before I touch any estate — and which estate will I go deepest on?

Outcome: Stand up the reusable machinery every estate lab depends on. Block A (data & access): data sources and contracts, ITSM/CMDB and API access, identity/RBAC and least-privilege service accounts, ticket/event ingestion, runbook anatomy. Block B (safety & control): tool/function calling, evaluations and acceptance criteria, guardrails, observability, human-in-the-loop gates, fallback paths, and common failure modes. Then nominate your primary estate for deeper work.

Estate lens: This is the module the earlier design was missing. Infrastructure people are strong on estates and weak on agentic patterns and evaluation — so if runbook orchestration, tool calling, guardrails, evals and observability first appear only inside the estate labs, the labs collapse under the load. Learn the delivery primitives once, here, as reusable scaffolding; then the estate modules apply them rather than teach them. This is also where you choose the estate you will go deepest on.

Apply-at-work mission — Delivery foundation + primary-estate choice: Produce the Cranfield data/integration/eval/guardrail plan and stand up the shared scaffold: one permissioned tool/API connection, one grounded assistant, one guarded tool call with an eval and a human-in-the-loop gate. Start the production-readiness checklist you will update every later module. Finally, nominate your PRIMARY estate (Datacenter, Network or Workplace) — it gets your deeper lab and more of the Module-9 integration weight.

Reflection: Which delivery primitive did I underestimate — access/RBAC, evals, guardrails, observability, or fallbacks? Why did I pick the primary estate I chose?

Resources

• Anthropic — Tool use (function calling) — How a model takes a bounded, permissioned action through a defined interface — the primitive under every agentic runbook you will build in the estate labs. Read for the pattern, not the SDK.
  • Explain how tool/function calling lets a model act safely
  • Describe the interface contract a tool call needs
  • Spot where a tool call must be gated near production
• Hamel Husain — Your AI product needs evals — The practitioner's case for building evaluations before you trust an AI feature — the acceptance-criteria half of your readiness gate, made concrete.
  • Design a repeatable eval for an AI ops feature
  • Tie eval pass/fail to acceptance criteria, not vibes
  • Use evals as the go/no-go before and after building
• OWASP — Top 10 for LLM Applications — The canonical catalogue of LLM failure modes and attacks — prompt injection, data leakage, excessive agency. The backbone of the guardrails and failure-modes toolkit.
  • Name the LLM failure modes that matter on an estate
  • Map each risk to a concrete guardrail
  • Justify guardrail choices in OWASP terms to a CISO
• Microsoft — Azure RBAC best practices — Least-privilege, scoped access and service-account discipline — the controls Ken will require in writing before any AI connects to Cranfield's systems.
  • Scope a least-privilege service account for an AI task
  • Explain read-only vs write access in RBAC terms
  • Give a CISO the access controls before connecting
• OpenTelemetry — Observability primer — The grounding for making an AI workflow observable — traces, metrics, logs — so you can see what the AI did, why, and whether it still behaves.
  • Define what observability means for an AI workflow
  • Choose signals that reveal AI misbehaviour early
  • Design dashboards the ops team can actually run

In-world ticket queue

Prepare-the-ground week. Before touching any estate you need the plumbing: read-only API access to ServiceNow and monitoring, least-privilege service accounts Ken will actually sign, an eval harness, guardrails, observability, and a human-in-the-loop gate. Decide which estate you go deepest on before the labs begin.

Project — Delivery foundation + primary-estate choice (Capstone component)

Produce Cranfield's data / integration / eval / guardrail plan, then stand up the shared scaffold the estate labs will reuse: one permissioned tool or API connection (read-only, least-privilege), one grounded assistant over real Cranfield content, and one guarded tool call with an eval and a human-in-the-loop gate. Start the production-readiness checklist you will update every later module. Finally, nominate your PRIMARY estate — Datacenter, Network or Workplace — with a one-paragraph rationale; it gets your deeper lab and more of the Module-9 integration weight.

Deliverable: fde/m05-delivery-foundation.md — the data/access/eval/guardrail plan, the described scaffold (tool connection, grounded assistant, guarded call + eval + HITL gate), the started production-readiness checklist, and your primary-estate choice. Fifth component of the engagement pack.

Assessment rubric

Scenario drills

Drill 1. Ken will sign least-privilege service accounts and read-only API scopes — but wants them specified first (CRN-0041).

Task: Write the access request for one Cranfield integration: which system, read or write, scoped to what, and why that scope and no wider. Name the one thing you are deliberately NOT asking for.

Drill 2. You must stand up the shared scaffold once and reuse it across all three estates (CRN-0042).

Task: List the four reusable primitives you would build first and, for one guarded tool call, describe the eval and the human-in-the-loop gate you would wrap around it.

Knowledge check (12 questions)

Self-test prompts. Answers and explanations are not published here — take the quiz at https://ragentic.netlify.app/#/courses/fde-infrastructure to check yourself.

1. Why learn the delivery primitives here in Module 5 rather than inside each estate lab?

1. Because the client specifically asked for a dedicated foundation week up front
2. Learn them once so the labs apply, not teach
3. Because the estate labs would otherwise collapse under the combined load
4. Because the vendor tooling requires it before anything else begins

2. A least-privilege service account is…

1. A shared admin login
2. An account scoped to only the exact read and write access the task genuinely needs
3. The vendor default account
4. A personal named account

3. A data contract mainly defines…

1. A binding legal agreement the client signs with the AI model vendor before any use
2. What a source provides and in what shape
3. The commercial pricing terms for the data feed being consumed
4. The uptime SLA

4. An evaluation ("eval") in this context is…

1. A one-off subjective impression of how good the demo happened to feel on the day
2. A repeatable test of whether the AI meets its acceptance criteria
3. A vendor benchmark
4. A user survey

5. A guardrail is best described as…

1. A dashboard that displays the AI system's activity to the operations team
2. A limit on what the AI may do
3. A model that has been fine-tuned on the client's own private data
4. A written policy document filed with the compliance team

6. Observability for an AI workflow means…

1. Making it look good
2. Being able to see what the AI did, why, and whether it is still behaving as intended over time
3. A monthly report
4. A public status page

7. A human-in-the-loop gate is…

1. A mandatory training session every operator must attend before using the system at all
2. A point where a human must approve before the action proceeds
3. A recurring weekly committee that reviews all completed actions
4. A login screen

8. A fallback path matters because…

1. Because the client will always insist on having some kind of manual backup anyway
2. What the system does when the AI is unsure or fails is itself a safety decision
3. It looks thorough
4. The vendor includes one

9. Learning runbook anatomy is worth it because…

1. Because runbooks are a legacy artifact the client will eventually want to retire fully
2. An AI runbook automates a structure ops already trusts
3. Because the compliance team maintains a strict template for exactly how they must be written
4. Because every monitoring vendor ships its own competing runbook format you must learn

10. Tool/function calling lets a model…

1. Write poetry
2. Take a bounded, permissioned action in a real system through a defined interface you control
3. Run faster
4. Cost less

11. Choosing a primary estate after Module 5 means…

1. You are permanently locked out of ever touching either of the other two estates again
2. One estate gets the deeper lab and more integration weight
3. The other two estates are completely ignored for the rest of the course
4. You must pick the datacenter

12. The production-readiness checklist should be…

1. A document you fill in once at the very end of the engagement and then archive away
2. A living document you update every module from M5 onward
3. A vendor form
4. A one-page summary

Phase 4 — Build the Estate (weeks 6–8)

Module 6 — Datacenter & Cloud: AIOps, Observability & Capacity

Guiding question: How do I make the datacenter's telemetry tell me things instead of just alarming — without hiding a real incident?

Outcome: Apply the M5 primitives to compute, storage, virtualization and cloud ops: event correlation and alert-noise reduction, anomaly detection on metrics, and capacity forecasting. Integrate with the existing monitoring rather than replacing it, and validate that "fewer alerts" did not suppress something real.

Estate lens: The datacenter is the best first estate because it makes telemetry, compute, storage, patching, observability and operational reliability concrete. It is also where alert fatigue is worst, so noise reduction lands immediately — provided you can prove you did not silence a genuine incident. That validation, not the correlation itself, is the FDE move.

Apply-at-work mission — Datacenter lab: correlation, forecast & validation: Guided lab against sample Cranfield DC telemetry: correlate an alert storm down to root events, build a simple capacity forecast for DC-1's power/cooling constraint, and produce a validation note proving no real incident was suppressed. Deliver the DC runbook artifact. (Deeper build if Datacenter is your primary estate; optional stretch: apply to your own estate.)

Reflection: What did correlation catch that I would have missed — and what, if anything, did it nearly hide? How confident am I the forecast is honest?

Resources

• Google SRE Book — Practical alerting from time-series data — How to turn noisy time-series into alerts that mean something — the discipline behind reducing DC-1's alert storm without going blind to real incidents.
  • Design alerts that carry signal, not just volume
  • Reason about what a quieter alert stream might hide
  • Set thresholds you can defend to the NOC
• Elastic — What is anomaly detection? — A grounding in metric anomaly detection — where it beats a static threshold and where it produces false alarms you will have to explain.
  • Explain when anomaly detection beats a fixed threshold
  • Anticipate the false positives it will generate
  • Decide which DC metrics are worth watching this way
• Alert correlation & noise reduction (AIOps) — curated search — Read two credible pieces on collapsing many alerts into few root events. Watch for how each claims to avoid suppressing a genuine incident.
  • Describe how correlation collapses alerts to root events
  • Interrogate a vendor's "no incident hidden" claim
  • Design a check that a real incident still surfaces
• Data-center capacity planning (power & cooling) — curated search — Background for DC-1's power/cooling constraint during the colo migration — enough to build an honest, uncertainty-aware capacity forecast.
  • Identify the constraints a DC capacity forecast must model
  • Build a forecast that states its own uncertainty
  • Avoid the single-optimistic-scenario trap
• Datadog — What is observability? — Integrating with existing monitoring rather than replacing it — the vocabulary for making the DC pilot enrich Cranfield's stack, not compete with it.
  • Frame the pilot as integrating, not rip-and-replace
  • Map the DC signals worth feeding an AI layer
  • Preserve the history and trust the team already has

In-world ticket queue

Datacenter build. DC-1 threw 900 alerts overnight — a handful real, the rest noise — and it is tight on power and cooling with the colo migration only half done. Dilan remembers the last "AIOps" tool that just moved the noise around. Prove yours reduces it without hiding a real incident.

Project — Datacenter lab: correlation, forecast & validation (Capstone component)

Guided lab against sample Cranfield datacenter telemetry. Correlate the DC-1 overnight alert storm down to its few root events; build a simple, uncertainty-aware capacity forecast for DC-1's power/cooling constraint through the colo migration; and — the FDE move — write a validation note proving the noise reduction did not suppress a real incident. Integrate with the existing monitoring rather than replacing it. Deliver the datacenter runbook artifact. (Deeper build if Datacenter is your primary estate; optional stretch: apply the method to your own estate.)

Deliverable: fde/m06-datacenter-runbook.md — the correlation result, the capacity forecast with stated uncertainty, the incident-not-suppressed validation note, and the DC runbook. Updates the production-readiness checklist.

Assessment rubric

Scenario drills

Drill 1. DC-1 threw ~900 alerts overnight; a handful are real (CRN-0051), and Dilan remembers the last tool that just moved the noise around.

Task: Describe how you would collapse the storm to root events AND the one check you would run to prove a genuine incident was not buried. State what you would show Dilan.

Drill 2. DC-1 is tight on power and cooling with the colo migration half done (CRN-0052).

Task: Sketch a capacity forecast that Dilan could act on, naming its key assumption and the range of error you would attach to it.

Knowledge check (12 questions)

Self-test prompts. Answers and explanations are not published here — take the quiz at https://ragentic.netlify.app/#/courses/fde-infrastructure to check yourself.

1. Why is the datacenter a good first estate to build in?

1. Because the datacenter is by far the cheapest estate to run any kind of experiment in
2. It makes telemetry and reliability concrete
3. Because the datacenter team is usually the most enthusiastic about adopting new tools
4. Because the other two estates depend entirely on datacenter work being finished first

2. The real FDE move in alert-noise reduction is…

1. Fewer alerts
2. Proving that reducing the noise did not quietly suppress a single genuine incident
3. A nicer dashboard
4. Faster paging

3. Event correlation aims to…

1. Permanently delete every alert that the on-call engineer finds even slightly annoying
2. Collapse many alerts into their few root events
3. Route each alert to a different team automatically based on some keyword match
4. Silence P3s

4. Anomaly detection on metrics is most valuable when…

1. When the operations team has completely run out of any other ideas left to try at all
2. It catches deviations a static threshold would miss
3. When the vendor demo looked good
4. When alerts are already quiet

5. A capacity forecast for DC-1 must above all be…

1. Presented to the CFO in a polished slide format with confident projections attached
2. Honest about its own uncertainty
3. Built exclusively from the single most optimistic growth scenario available to you
4. Signed off by the vendor before it can ever be shown to anyone at all at Cranfield

6. You integrate with existing monitoring rather than replacing it because…

1. It is cheaper
2. Rip-and-replace destroys the trust and history the team already has, and it rarely lands
3. The vendor says so
4. It is faster

7. The four golden signals mainly help you…

1. Decide precisely how many separate monitoring vendors the client really ought to buy
2. Judge whether an alert stream carries real signal
3. Set the exact budget for the whole observability stack for the coming year
4. Pick a colour scheme

8. The incident-not-suppressed validation note matters because…

1. Because Dilan will otherwise simply refuse to even look at the pilot's results at all
2. "Fewer alerts" is worthless if it hid a real one
3. It fills the runbook
4. It pleases the NOC

9. Correlating the alert storm down to root events means…

1. Manually reading through all nine hundred overnight alerts one single alert at a time
2. Finding the few causes behind the many
3. Escalating the entire storm straight to the most senior engineer on call that night
4. Turning the affected monitoring system off completely until the morning shift arrives

10. A capacity forecast is honest when…

1. It looks confident
2. It states its assumptions and how wrong it could plausibly be, not just a single tidy number
3. It is short
4. It agrees with Dilan

11. A real incident hidden by noise reduction is…

1. A perfectly acceptable and entirely normal trade-off to make in exchange for less noise
2. The exact failure the validation guards against
3. A problem only for the vendor to worry about later
4. Impossible

12. The datacenter runbook artifact should show…

1. A single impressive screenshot of the correlation tool working nicely during the live demo
2. the correlation, the forecast, and the validation together
3. Just the alert count
4. The vendor logo

Module 7 — Network Infrastructure: Assurance, Anomaly & Change Safety

Guiding question: Can AI find the "random" branch slowdown before the NOC does — and never make an unsafe change?

Outcome: Apply AI to network telemetry for assurance and anomaly across sites, add config-drift detection and pre-change validation, and enable natural-language query over network state — with hard guardrails keeping every change human-approved.

Estate lens: Network changes are the highest-blast-radius action in the estate, and Marisol's change control is usually right to say no. The FDE earns her trust by respecting the CAB, not bypassing it: AI proposes and explains a change; a human disposes. Get that boundary wrong once and you lose the room for the rest of the engagement.

Apply-at-work mission — Network lab: root-cause & human-gated change: Guided lab against sample Cranfield network telemetry and configs: trace the branch-slowdown to a cause using telemetry + natural-language query, detect a config drift, and propose (never auto-apply) a fix with a validation checklist and an explicit human-approval gate. Deliver the network runbook artifact. (Deeper if Network is your primary estate.)

Reflection: Where was I tempted to let the agent act rather than propose? What would have to be true before any network change could be safely automated here?

Resources

• Atlassian — Change management (ITSM) — The change-advisory-board discipline Marisol guards. Respecting it — not bypassing it — is how AI-proposed changes earn a path to production.
  • Explain the role of a CAB in safe change
  • Position AI as proposing within change control, not around it
  • Describe how a change earns approval
• Network assurance & intent-based networking — curated search — Read two credible pieces on AI-assisted network assurance and anomaly across sites — the pattern behind chasing Cranfield's "random" branch slowdown.
  • Describe AI-assisted assurance across many sites
  • Judge which network signals are worth correlating
  • Separate genuine assurance from vendor hype
• Red Hat — What is configuration management? — The grounding for config-drift detection — spotting where live config has diverged from intended before a change freeze exposes it.
  • Define configuration drift and why it accumulates
  • Design drift detection against an intended baseline
  • Treat drift as an early warning before a freeze
• Google SRE Workbook — Canarying releases — Blast-radius thinking for change: staged, reversible rollout. Directly applicable to why a network change must never be auto-applied estate-wide.
  • Reason about blast radius for a network change
  • Design a staged, reversible change path
  • Explain why estate-wide auto-apply is unsafe
• Natural-language query over network state — curated search — How an engineer can ask the estate questions in plain English — an assistive layer that must never cross into applying changes on its own.
  • Describe NL query as an assistive, read-only layer
  • Keep query strictly separate from action
  • Spot where a plain-English answer could mislead

In-world ticket queue

Network build. The "random" branch slowdown is back — three sites, no root cause after weeks — and a shipping-peak change freeze starts Friday. Marisol will consider an AI assist, but nothing it suggests touches the network without her sign-off.

Project — Network lab: root-cause & human-gated change (Capstone component)

Guided lab against sample Cranfield network telemetry and configs. Trace the "random" branch slowdown to a cause using telemetry plus natural-language query; detect a config drift ahead of the shipping-peak freeze; and propose — never auto-apply — a fix with a validation checklist and an explicit human-approval gate. Every AI-proposed change stays human-approved. Deliver the network runbook artifact. (Deeper build if Network is your primary estate.)

Deliverable: fde/m07-network-runbook.md — the root-cause trace, the drift finding, and the proposed fix with its validation checklist and human-approval gate. Updates the production-readiness checklist.

Assessment rubric

Scenario drills

Drill 1. The "random" branch slowdown is back across three sites with no root cause after weeks, and a change freeze starts Friday (CRN-0061).

Task: Outline how you would use telemetry + natural-language query to trace it, and state clearly where the AI stops and a human takes over.

Drill 2. Config drift is detected pre-freeze (CRN-0062) and must be validated before any change.

Task: Write the human-approval gate for the proposed fix: what the AI must show, who approves, and the hard stop if validation fails.

Knowledge check (12 questions)

Self-test prompts. Answers and explanations are not published here — take the quiz at https://ragentic.netlify.app/#/courses/fde-infrastructure to check yourself.

1. Network changes are best understood as…

1. Roughly the same risk level as any other routine change made anywhere in the estate
2. The highest-blast-radius action in the estate
3. Best made quickly and quietly, late at night, without troubling the change board at all
4. Something an AI can be trusted to apply on its own once it has seen enough examples

2. You earn Marisol's trust by…

1. Moving fast
2. Respecting the change board and letting AI propose while a human always disposes
3. Buying her tool
4. Avoiding her

3. Config-drift detection is…

1. A way to automatically roll every device back to its factory-default configuration nightly
2. Spotting where live config has diverged from intended
3. A replacement for the entire existing change-management process the team already runs
4. A vendor upsell

4. Pre-change validation means…

1. Waiting until well after the change has been applied to see whether anything at all broke
2. Checking a proposed change is safe before it is applied
3. Skipping the test
4. Asking the vendor

5. Natural-language query over network state lets an engineer…

1. Completely replace their own years of hard-won networking knowledge with a chatbot
2. Ask the estate questions in plain English
3. Automatically apply any fix the model happens to suggest without any further review at all
4. Bypass the change advisory board entirely whenever they happen to be in a genuine hurry

6. AI must never auto-apply a network change because…

1. It is slow
2. A wrong change can take down many sites at once, so a human must approve first every time
3. Marisol dislikes it
4. It costs money

7. AI helps root-cause the "random" branch slowdown mainly because…

1. Because the artificial intelligence simply always knows the correct answer to every question
2. It can correlate telemetry a human would not connect
3. Because it can be safely left running completely unattended overnight to fix it by itself
4. It is cheap

8. A change freeze before the shipping peak means…

1. That this is exactly the perfect moment to push through as many big changes as possible
2. Extra caution: validate, do not risk the peak
3. That all AI work must stop
4. Nothing much

9. The human-approval gate on a network change is…

1. An optional extra step that can be safely skipped whenever the team is under time pressure
2. The hard stop the whole design turns on
3. A slow bureaucratic formality that mostly exists only to protect people from blame later
4. A weekly meeting the network operations team holds to review changes already completed

10. When AI proposes a network fix, it must also…

1. Apply it fast
2. Show its evidence and reasoning so a human can judge whether the proposed change is safe
3. Log nothing
4. Skip the CAB

11. Config drift detected just before a freeze is best treated as…

1. Something to quietly ignore until well after the busy shipping peak has fully passed by
2. An early warning to validate before the freeze
3. A reason to immediately cancel the entire shipping peak and impose the freeze at once
4. A vendor problem

12. The network runbook artifact should include…

1. A confident promise that the AI will soon fully automate all network changes end to end
2. the root-cause trace, the drift finding, and the approval gate
3. Only the final config
4. The vendor SLA

Module 8 — Workplace & Endpoint: Experience, Deflection & Self-Heal

Guiding question: How do I cut the service desk's load and lift end-user experience without leaking data or breaking devices?

Outcome: Apply AI to identity, endpoint and collaboration workflows: digital-employee-experience and endpoint analytics, ticket deflection with retrieval grounded in the client's runbooks, and a bounded self-heal automation — with anonymisation and PII discipline throughout, and honest measurement of what was actually deflected.

Estate lens: Workplace comes last because endpoint and collaboration scenarios depend on identity, access, connectivity and device posture — the things the datacenter and network modules made concrete. It is also the most data-sensitive estate: tickets are full of names and machines, so the sanitisation discipline is not optional. "Deflected" only counts if it was not merely deflected-then-reopened.

Apply-at-work mission — Workplace lab: deflection & self-heal: Guided lab against sample Cranfield runbooks and tickets: build a retrieval-grounded assistant over the runbook set, design one bounded self-heal flow with explicit stop conditions, add the sanitisation step, and define an honest deflection measurement. Deliver the workplace runbook artifact. (Deeper if Workplace is your primary estate.) 🎯 Completes Capstone Milestone 3.

Reflection: What did I have to strip before anything reached a model, and did I nearly miss a quasi-identifier? Is my deflection metric honest, or flattering?

Resources

• AWS — What is Retrieval-Augmented Generation (RAG)? — How to ground an assistant in the client's own runbooks and knowledge base so it answers from Cranfield's reality, not the model's guesswork.
  • Explain how retrieval grounds an assistant in real content
  • Describe why grounding reduces confident wrong answers
  • Design retrieval over Priya's runbook set
• Quasi-identifiers & re-identification — curated search — Why stripping obvious names is not enough — combinations of ordinary fields can re-identify a person. The discipline for sanitising identity-dense ticket data.
  • Define a quasi-identifier and its re-identification risk
  • Spot quasi-identifiers hiding in ticket and endpoint data
  • Design a sanitisation step that catches combinations
• Digital employee experience (DEX) — curated search — The workplace-estate opportunity space: endpoint analytics and experience signals that let you lift end-user experience, not just close tickets.
  • Name the DEX and endpoint signals worth using
  • Connect experience data to a real service-desk pain
  • Separate experience improvement from ticket theatre
• HDI / KCS — knowledge-centered service — curated search — The knowledge discipline behind honest ticket deflection — and why "deflected" must mean resolved, not merely deflected-then-reopened.
  • Explain knowledge-centered service for deflection
  • Define an honest deflection metric
  • Track reopened tickets, not just first-touch closes
• Autonomous endpoint self-heal — curated search — How bounded self-heal automations work on endpoints — and why explicit stop conditions and blast-radius limits are the whole safety story.
  • Design a bounded self-heal flow with stop conditions
  • Reason about self-heal blast radius on endpoints
  • Decide when a flow must halt and hand off to a human

In-world ticket queue

Workplace build. Priya's queue is drowning — 18 password resets, 12 VPN, Outlook, onboarding — and she is ready to pilot deflection today. Ken's only condition: no user data leaks into a model. Measure what is actually deflected, not what merely bounced back later.

Project — Workplace lab: deflection & self-heal (Capstone component)

Guided lab against sample Cranfield runbooks and tickets. Build a retrieval-grounded assistant over Priya's runbook set; design one bounded self-heal flow with explicit stop conditions; add the sanitisation step that strips the identity payload (including quasi-identifiers) before anything reaches a model; and define an honest deflection measurement that counts resolution, not deflected-then-reopened. Deliver the workplace runbook artifact. (Deeper build if Workplace is your primary estate.) Completes Capstone Milestone 3.

Deliverable: fde/m08-workplace-runbook.md — the grounded assistant design, the bounded self-heal flow with stop conditions, the sanitisation step, and the honest deflection metric. Updates the production-readiness checklist; completes MS3.

Assessment rubric

Scenario drills

Drill 1. Priya's queue is drowning and she is ready to pilot deflection today; Ken's only condition is that no user data leaks into a model (CRN-0071, CRN-0073).

Task: Describe the sanitisation step you would put before the model and name one quasi-identifier you would strip that is not an obvious name.

Drill 2. You are designing one bounded self-heal flow with explicit stop conditions (CRN-0072).

Task: Define the flow's single job, its two hardest stop conditions, and how you would measure deflection honestly rather than flatteringly.

Knowledge check (12 questions)

Self-test prompts. Answers and explanations are not published here — take the quiz at https://ragentic.netlify.app/#/courses/fde-infrastructure to check yourself.

1. The workplace is best understood as the estate that is most…

1. Workplace is by a wide margin the very easiest estate to gather clean data from safely
2. data-sensitive
3. Workplace is the estate where any mistakes carry the smallest possible consequences of all
4. Workplace is the estate that depends least on any of the other estate work being done first

2. Sanitisation before data reaches a model is…

1. Optional here
2. Non-negotiable, because tickets are full of names, machines and other identity payload
3. A vendor feature
4. Ken's job only

3. A retrieval-grounded assistant answers from…

1. Whatever the underlying base model happens to already know from its training data alone
2. the client's own runbooks and knowledge base
3. A large public dataset scraped from across the whole of the open internet somewhere
4. Pure guesswork

4. A ticket only counts as "deflected" if it…

1. If the ticket simply bounced off the assistant and then quietly came straight back later on
2. was actually resolved, not merely deflected-then-reopened
3. was logged
4. was urgent

5. A bounded self-heal flow needs above all…

1. A completely free hand to take whatever remediation action it judges best in the moment
2. explicit stop conditions
3. The single largest and most capable model that the budget could possibly stretch to cover
4. Full unattended write access across every managed endpoint in the entire workplace estate

6. A quasi-identifier is dangerous because…

1. It is loud
2. On its own it seems harmless, but combined with other fields it can re-identify a person
3. It is rare
4. It is old

7. The workplace estate is built last because…

1. Because it is comfortably the least important of the three estates to Cranfield overall
2. It depends on identity, access and device posture
3. Because the service desk team specifically asked to be scheduled into the very last slot
4. It is hardest

8. Grounding an assistant in real runbooks mainly…

1. It completely and permanently removes any and all possibility of the model ever being wrong
2. reduces confident, made-up answers
3. Makes it faster
4. Costs less

9. An honest deflection metric must also track…

1. Only the raw count of tickets that the assistant managed to close on its very first try
2. reopened tickets too
3. The total number of separate conversations the assistant had with users over the week
4. How positive the wording of every single user feedback comment happened to sound overall

10. The sanitisation step should strip…

1. Only full names
2. the whole identity payload — hostnames, usernames, IPs and the quasi-identifiers around them
3. The timestamps
4. The ticket ID

11. A self-heal flow that hits its stop condition should…

1. Keep quietly retrying the very same failed action over and over until it eventually works
2. halt and hand off to a human
3. Silently give up and close the ticket as resolved without telling anyone at all about it
4. Escalate to the vendor

12. The workplace runbook artifact should show…

1. A single glowing quote from one happy end user about how much they liked the new assistant
2. the grounded assistant, the self-heal flow, and the sanitisation step
3. Just the ticket count
4. The tool logo

Phase 5 — Integrate & Land (weeks 9–10)

Module 9 — Integrated Agentic Runbooks & Production Readiness

Guiding question: How do I combine the estate pilots into one production-grade workflow that is monitored, reversible, and safe to run?

Outcome: Integrate the pilots into cross-estate agentic runbooks (reason → propose → human approves → act → verify), connected to ITSM/monitoring/config via APIs and webhooks with least-privilege accounts. Prove production readiness: eval evidence, observability dashboards, rollback, change records, and a handover pack — the M5 foundations, now demonstrated at integration.

Estate lens: This is synthesis, not first exposure — the runbook, tool-calling, eval, guardrail and observability foundations were taught in Module 5 precisely so this module can integrate rather than introduce. The bar here is production-readiness: an agent that touches production must propose-and-verify behind a human gate, log every action, and roll back cleanly. If it cannot, it is a demo, not a delivery.

Apply-at-work mission — Integrated runbook pack + production-readiness review: Wire one pilot to ServiceNow (ticket in → AI triage → drafted action → human approve → verify) and build one cross-estate agentic runbook with an explicit stop-and-approve. Run the production-readiness checklist against it — test evidence, rollback, observability, HITL, change record, handover — and deliver the integrated runbook pack with observability evidence and the HITL gate design. 🎯 Completes Capstone Milestone 4.

Reflection: Which production-readiness item was my runbook missing when I first checked? Where is the single point where a wrong AI step could still cause harm?

Resources

• Martin Fowler — Engineering practices for LLM applications — What it takes to run an LLM feature as a real system — testing, evals, observability, guardrails — the production bar this module holds the integrated runbook to.
  • Name the engineering practices a production AI feature needs
  • Judge an integrated runbook against a production bar
  • Spot where a pilot is still only a demo
• ServiceNow REST API integration & webhooks — curated search — How to wire a workflow to ServiceNow with scoped, least-privilege access — the plumbing for "ticket in → AI triage → human approve → verify".
  • Describe a least-privilege ServiceNow integration
  • Design the ticket → triage → approve → verify loop
  • Keep write access scoped to exactly the workflow
• Safe rollback & deployment strategies — curated search — The discipline of reversible change — so that when an AI-driven action goes wrong, you can undo it cleanly. A production-readiness must-have.
  • Design a clean rollback for an AI-driven action
  • Reason about which actions are reversible and which are not
  • Make reversibility a precondition for autonomy
• Human-in-the-loop AI in production — curated search — Patterns for keeping a human approval point in a live workflow without grinding it to a halt — the balance the integrated runbook has to strike.
  • Place a human approval point without killing throughput
  • Decide which actions need a gate and which do not
  • Design the approver's view so the decision is real
• Production readiness review — curated search — The SRE practice of a production-readiness review — the model for running your living checklist against the runbook before it goes live.
  • Run a production-readiness review against a runbook
  • Turn the living checklist into a go/no-go
  • Find the readiness item the runbook is missing

In-world ticket queue

Integration week. The three pilots work in isolation; now they must become one production-grade workflow wired to ServiceNow, monitored, and reversible. Ken will not approve anything that acts on production without a human gate, an audit trail, and a clean rollback. This is where "demo" becomes "delivery".

Project — Integrated runbook pack + production-readiness review (Capstone component)

Wire one pilot to ServiceNow (ticket in → AI triage → drafted action → human approve → verify) with least-privilege access, and build one cross-estate agentic runbook with an explicit stop-and-approve step. Run the production-readiness checklist against it — eval evidence, rollback, observability, HITL gate, change record, handover — and deliver the integrated runbook pack with observability evidence and the HITL gate design. This is synthesis of the Module-5 foundations at integration, not first exposure. Completes Capstone Milestone 4.

Deliverable: fde/m09-integrated-runbook.md — the wired ServiceNow loop, the cross-estate runbook with its stop-and-approve, the completed production-readiness review, and the observability + HITL evidence. Completes MS4.

Assessment rubric

Scenario drills

Drill 1. You must wire a pilot to ServiceNow: ticket in → AI triage → human approve → verify (CRN-0081), and Ken wants rollback, audit trail and the human gate shown (CRN-0083).

Task: Describe the least-privilege access you would request and where exactly the human gate sits. Name the one action in the loop that must never happen without approval.

Drill 2. You are running the production-readiness checklist against the runbook (CRN-0082).

Task: List the readiness items you would check and identify the one your runbook is most likely to be missing on the first pass.

Knowledge check (12 questions)

Self-test prompts. Answers and explanations are not published here — take the quiz at https://ragentic.netlify.app/#/courses/fde-infrastructure to check yourself.

1. Module 9 is best understood as…

1. An entirely fresh introduction to tool calling, evals, guardrails and observability from scratch
2. synthesis, not first exposure
3. The first time the learner has ever had to think about production readiness at all here
4. A lighter, optional module that mostly just reviews what the earlier modules already covered

2. An agentic runbook near production follows the pattern…

1. Act, then log
2. Reason, propose, a human approves, then act, and finally verify the result afterwards
3. Just act
4. Ask, then wait

3. "Production readiness" here means…

1. That the demo ran successfully end to end at least once in front of the assembled steering group
2. eval evidence, observability, rollback, and a human gate
3. That the vendor has formally certified the whole thing as being ready for production use somewhere
4. That it is fast

4. The integration to ServiceNow should use…

1. A single shared administrator account with full write access to absolutely everything at once
2. least-privilege API access scoped to the workflow
3. The vendor default
4. A personal login

5. The real difference between a demo and a delivery is that…

1. A delivery generally has a noticeably larger and more detailed accompanying slide deck than a demo
2. a demo cannot be safely run in production
3. A delivery is the one that the client happens to have paid a slightly larger sum of money for
4. A delivery is simply a demo that has been given a second time to a different audience later

6. A clean rollback matters because…

1. It looks tidy
2. When an AI-driven action goes wrong, being able to reverse it cleanly is what limits the harm
3. The vendor requires it
4. It is quick

7. Observability dashboards for the AI workflow itself let the ops team…

1. Finally replace every one of the older monitoring dashboards the team currently still relies on
2. see what the AI is doing and catch drift
3. Prove to the finance team that the whole project was genuinely worth all the money spent on it
4. Look busy

8. A change record for an AI action exists so that…

1. So that there is always someone specific who can be held personally to blame when it goes wrong
2. every AI-driven change is auditable after the fact
3. It fills the log
4. The CAB is happy

9. The handover pack matters because…

1. Because the delivery lead insists on having one final document produced before the engagement ends
2. the client's team must run it after you leave
3. Because it is a standard contractual deliverable that every engagement of this kind must include
4. Because it gives the FDE something tangible to point at when justifying the final invoice later

10. The single most dangerous point in an integrated runbook is…

1. The slowest step
2. any point where a wrong AI step could still act on production without a human catching it first
3. The first step
4. The log step

11. At integration, the Module-5 foundations are…

1. Being taught to the learner for the very first time, now that the estate labs have all finished
2. demonstrated in production, not introduced
3. Quietly abandoned in favour of whatever the integration vendor happens to recommend doing instead
4. Optional now

12. A cross-estate agentic runbook needs an explicit stop-and-approve because…

1. Because the change advisory board will otherwise be quite annoyed about being left out of it all
2. no agent should act across estates unattended
3. It is neater
4. The demo needs it

Module 10 — Governance, Adoption, Scale & Capstone Defense

Guiding question: How do I make this outlast me — governed, adopted by the client's team, measured, and defended to a sceptical room?

Outcome: Consolidate the governance thread into a signable AI-in-operations pack (data residency, change control for AI actions, guardrails, audit, the autonomy ladder). Drive adoption and handover to the client's ops team, measure outcomes and ROI against the Module-2 baseline, tell the demo narrative, plan the land-and-expand, and defend the whole engagement to the Cranfield cast.

Estate lens: An engagement that dies when the FDE leaves was theatre. Landing means the client's own team runs it, the CISO and change board have signed the governance, the CFO has a defensible number, and there is a plan to expand from pilot to estate. The capstone is not a presentation — it is the defence of accumulated work in front of people paid to be sceptical.

Apply-at-work mission — Capstone: defend the Cranfield engagement: Assemble the accumulated engagement pack — charter, estate map + baseline, use-case canvas, blueprint + readiness gate, delivery foundation, the estate runbooks, the integrated runbook pack, and the governance/adoption pack — and defend it to the cast with measured before/after. Choose a track: (A) delivery-lead package (the full engagement, presentation-ready) or (B) a deep single-estate implementation with a working integration.

Reflection: Reopen the Module-1 sealed baseline: what did I get wrong on day one? What would I need to be true before I let any of this run unattended?

Resources

• ISO/IEC 42001 & enterprise AI governance — curated search — The shape of a formal AI management system — the reference for turning your threaded governance work into a signable AI-in-operations pack.
  • Describe what a formal AI governance pack contains
  • Map your threaded controls to a signable structure
  • Speak the governance language a CISO expects
• NIST AI Risk Management Framework — The autonomy-and-controls backbone for the governance pack: risk tiers, controls, and the change control that governs AI actions in production.
  • Frame the autonomy ladder in risk terms
  • Attach controls to each rung of autonomy
  • Govern AI-driven change like any other change
• Prosci — ADKAR change-management model — Adoption is a people problem, not a technical one. ADKAR is a clean frame for handover and getting the client's own team to actually run it.
  • Plan adoption as a change-management problem
  • Design a handover the client's team will sustain
  • Anticipate where adoption usually stalls
• Measuring ROI of IT-operations automation — curated search — How to build a defensible ROI number against a real baseline — what Tom will fund, as opposed to a slideware projection.
  • Build an ROI number against the Module-2 baseline
  • Separate a defensible figure from a flattering one
  • Present ROI a sceptical CFO will actually accept
• Land-and-expand strategy — curated search — How one proven pilot becomes a path across the estate — the 90-day plan Renata wants to turn this engagement into a repeatable play.
  • Turn a proven pilot into a staged expansion plan
  • Sequence the estate rollout by value and readiness
  • Frame expansion around evidence, not enthusiasm

In-world ticket queue

Final week. Steering review Friday: Dilan wants to know it will outlast you, Tom wants the number against the Week-2 baseline, Ken wants a signable governance pack, and Renata wants a handover the client's own team can run. Defend the whole engagement — and make the case to expand from pilot to estate.

Project — Capstone: defend the Cranfield engagement (Capstone component)

Assemble the accumulated engagement pack — charter, estate map + baseline, opportunity map, blueprint + readiness gate, delivery foundation, the three estate runbooks, the integrated runbook pack, and the governance/adoption pack — and defend it to the Cranfield cast with a measured before/after against the Module-2 baseline. Consolidate governance into a signable AI-in-operations pack (data residency, change control for AI actions, guardrails, audit, the autonomy ladder), plan the handover and the 90-day land-and-expand, and reopen the Module-1 sealed baseline. Choose a track: (A) delivery-lead package — the full engagement, presentation-ready; or (B) a deep single-estate implementation with a working integration.

Deliverable: fde/m10-capstone.md — the assembled engagement pack, the signable governance pack, the measured ROI against the Module-2 baseline, the adoption + land-and-expand plan, and the reopened sealed baseline. The defended whole.

Assessment rubric

Scenario drills

Drill 1. Steering review Friday: Dilan wants proof it will outlast you, Tom wants the number against the baseline, Ken wants a signable pack (CRN-0091, CRN-0092, CRN-0093).

Task: For each of the three, state the one artifact you would put in front of them and the single sentence you would open with.

Drill 2. Renata wants a handover pack and 90-day land-and-expand plan the client's own team can run (CRN-0094).

Task: Outline the first three expansion steps after the pilot and the one condition that must be true before each, so expansion is evidence-led not hope-led.

Knowledge check (12 questions)

Self-test prompts. Answers and explanations are not published here — take the quiz at https://ragentic.netlify.app/#/courses/fde-infrastructure to check yourself.

1. An engagement that dies the moment the FDE leaves was…

1. A perfectly acceptable and entirely normal outcome for this kind of short embedded engagement
2. theatre
3. Actually a genuine success, because the FDE clearly made themselves completely indispensable to it
4. Mostly the client's own fault for not hiring enough of their own permanent staff to run it later

2. "Landing" the engagement means…

1. A nice final demo
2. The client's own team runs it, governance is signed, and there is a plan to expand it further
3. A thick report
4. A closing dinner

3. The governance pack must be…

1. A lengthy academic document that carefully surveys the entire field of AI ethics in general terms
2. signable by the CISO and the change board
3. Written entirely by the external vendor and then simply handed over to the client to sign off on
4. Kept confidential

4. ROI must be measured…

1. However the chief financial officer happens to prefer to see it presented on the day in question
2. against the dated Module-2 baseline
3. By the vendor
4. Optimistically

5. The autonomy ladder is best understood as something…

1. A one-off decision the client makes right at the very start about exactly how autonomous AI may be
2. earned rung by rung with evidence
3. A marketing term the vendor uses to describe how advanced their particular product apparently is
4. A fixed regulatory requirement that applies identically to every AI system regardless of its risk

6. Adoption by the client's team requires…

1. A launch email
2. Handover, training and enough trust that the client's own people will actually keep running it
3. A big demo
4. A logo

7. The capstone is best understood as…

1. A polished one-way presentation delivered to a friendly and broadly supportive internal audience
2. a defence of accumulated work to sceptics
3. A written exam that tests whether the learner has memorised the key terms from the whole course
4. A formality

8. Change control for AI actions means…

1. That every single AI action must first be reviewed in person by the full change board in advance
2. AI-driven changes follow the same governed path
3. It moves faster
4. The vendor decides

9. Reopening the Module-1 sealed baseline shows…

1. Whether the tutor happened to mark the very first week-one assignment fairly and consistently or not
2. how the learner's thinking actually changed
3. Whether the original unassisted answer was already polished enough to reuse without any real edits
4. That the course has now finally reached its proper administrative end and can be formally closed

10. A defensible ROI number is one that…

1. Sounds impressive
2. ties a measured after-figure back to the dated before-figure, so the CFO can actually trust it
3. Is very large
4. Is rounded up

11. The land-and-expand plan is valuable because…

1. Because the FDE's own delivery lead is keen to turn this one engagement into repeatable practice revenue
2. it turns one proven pilot into a path across the estate
3. Because the client will always automatically want to buy considerably more the moment the pilot works
4. It fills a slide

12. Data residency belongs in the governance pack because…

1. Because Ken personally happens to feel rather strongly about it for his own particular reasons
2. it is one of the CISO's hard, non-negotiable lines
3. It sounds rigorous
4. The vendor asked

Toolkits

Pre-work diagnostic → remediation map

Unlocks in module 1.

A quick self-assessment across the six competencies, mapped to targeted "do these before Module 5" actions — not just a score.

# Pre-work diagnostic → remediation map

Rate yourself 1–5 on each axis, then follow the remediation for anything under 3.
The point is targeted preparation before the delivery foundation (Module 5), not a grade.

| Competency | 1–5 | If under 3, do this before M5 |
|---|---|---|
| Infrastructure depth (DC / network / workplace) | | Sketch your own estate's topology and systems of record from memory, then check it |
| AI fluency in operations | | Watch the Karpathy intro (M1) and write one paragraph on what an LLM cannot do |
| Discovery & scoping | | Practise turning one real pain into a value × data-readiness × risk line |
| Hands-on delivery | | Read the Anthropic tool-use overview (M5) and the evals piece; note what you don't follow |
| Governance, risk & security | | Read the OWASP LLM Top 10; list the three risks most relevant to your estate |
| Client trust & communication | | Write the two-sentence reply to a sceptical sponsor (M1 drill) |

## How to use it
- Retake it after Module 5 and again at Module 10 — the delta is evidence for your journal.
- Bring the lowest axis into your primary-estate choice: sometimes the right estate is the
 one that stretches your weakest competency, sometimes the one that plays to your strongest.

Opportunity-scoring sheet

Unlocks in module 3.

The value × data-readiness × risk grid, with a quantified KPI hypothesis and a buy / integrate / build call per shortlisted item.

# Opportunity-scoring sheet

Score each candidate 1–5 on all three axes. Shortlist the highest combined, then commit a
number. Readiness comes from the Module-2 data inventory, not optimism.

| Opportunity | Value (1–5) | Data-readiness (1–5) | Risk (1–5, lower=safer) | Shortlist? |
|---|---|---|---|---|
| DC alert-noise reduction | | | | |
| Capacity forecasting | | | | |
| Network anomaly / assurance | | | | |
| Config-drift detection | | | | |
| Ticket deflection | | | | |
| Bounded self-heal | | | | |
| Security operations assist | | | | |
| DC energy optimisation | | | | |

## For each shortlisted item
- **KPI hypothesis (quantified, vs the M2 baseline):** e.g. "cut DC-1 alert noise 40% without
 suppressing a real incident."
- **Risk tier:** low / medium / high — and the one control that earns the tier.
- **Buy / integrate / build:** with a one-line rationale. Integrate is the default; build is
 the exception, reserved for specific, valuable needs nothing else fits.

## The killed idea
Name one tempting solution-first idea you rejected, and whether value or data killed it.
Recording the rejection is the evidence of triage.

Solution-blueprint template

Unlocks in module 4.

Architecture, scope, dependencies, delivery plan and acceptance criteria — the bridge from a chosen opportunity to a buildable plan.

# Solution-blueprint template

## 1. Problem & outcome
- The bounded problem this pilot solves (one sentence).
- The acceptance criteria: what "done and good" looks like, as checkable statements.

## 2. Architecture
- Data sources in → processing → action out. Where the AI sits and what it may touch.
- The advisory-before-action rung this pilot occupies (advise / propose / act-with-approval).

## 3. Scope
- In scope (this pilot). Out of scope (named later phases).

## 4. Dependencies
- Access grants, data feeds, sign-offs, environments. The unnamed dependency is the one
 that stalls the build in week six — write them all down.

## 5. Delivery plan
- Milestones, sequence, who does what, and the human-approval path for any action.

## 6. Blast radius
- What a wrong action could touch, and how far it could spread. The control follows the reach.

Delivery-foundation checklist (living)

Unlocks in module 5.

The reusable data / access / eval / guardrail scaffold every estate lab depends on. Stood up once in M5, referenced everywhere after.

# Delivery-foundation checklist (living — start in M5)

## Block A — data & access
- [ ] Data sources identified with a contract (what, shape, who may use it)
- [ ] ITSM / CMDB / monitoring API access scoped and requested
- [ ] Least-privilege service accounts specified (read-only where possible)
- [ ] Identity / RBAC model written down and signed by the CISO
- [ ] Ticket / event ingestion path defined
- [ ] Runbook anatomy understood for the target workflow

## Block B — safety & control
- [ ] Tool / function calling interface defined and bounded
- [ ] Evals written as acceptance criteria (before build)
- [ ] Guardrails specified (what the AI may and may not do)
- [ ] Observability designed (traces, metrics, logs for the AI itself)
- [ ] Human-in-the-loop gate placed before any production action
- [ ] Fallback path defined (what happens when the AI is unsure or fails)
- [ ] Failure modes reviewed against the failure-modes library

## Primary-estate choice
- [ ] Primary estate nominated (Datacenter / Network / Workplace) with a rationale

Production-readiness checklist (living)

Unlocks in module 9.

The go/no-go for letting a runbook near production. Begun in M5, updated every module, run in full at integration (M9).

# Production-readiness checklist (living — run in full at M9)

A runbook that cannot tick these is a demo, not a delivery.

## Evidence
- [ ] Eval evidence: the AI meets its acceptance criteria, shown not claimed
- [ ] Observability: dashboards + alerts for the AI workflow itself
- [ ] Change record: every AI-driven action is auditable after the fact

## Safety
- [ ] Human-in-the-loop gate before any production action
- [ ] Clean rollback for every action the AI can take
- [ ] Least-privilege access, scoped to the workflow
- [ ] The single point where a wrong step could still cause harm is identified and gated

## Handover
- [ ] The client's own team can operate it (runbook + training)
- [ ] Handover pack complete
- [ ] Escalation and stop conditions documented

Failure-modes & anti-patterns library

Unlocks in module 5.

The catalogue of ways AI-in-operations goes wrong — from AI theatre to suppressed incidents to prompt injection — each with its guardrail.

# Failure-modes & anti-patterns library

Referenced in M5 (foundation), M9 (integration), and the governance pack.

## Delivery anti-patterns
- **AI theatre** — a slick demo of an unowned, unneeded capability. *Guard:* every pilot has a
 named owner and a measured problem behind it.
- **Solution-first** — building the clever thing, then hunting for a problem. *Guard:* triage on
 value × data-readiness × risk before any build.
- **Baseline-free impact** — "it feels faster." *Guard:* a dated Module-2 baseline behind every KPI.
- **The hero engagement** — only the FDE can run it. *Guard:* handover pack + the client's team operates it.

## Operational failure modes
- **Suppressed incident** — noise reduction hides a real event. *Guard:* the not-suppressed validation note.
- **Confident wrong answer** — fluent hallucination. *Guard:* retrieval grounding + evals + a human gate.
- **Unattended production action** — AI acts without approval. *Guard:* HITL gate + advisory-before-action ladder.
- **High-blast-radius change** — one network change takes down many sites. *Guard:* propose-not-apply + CAB.

## Data & security failure modes
- **Identity leak** — names / hosts / IPs reach a model. *Guard:* the sanitisation step (incl. quasi-identifiers).
- **Prompt injection / excessive agency** (OWASP LLM Top 10). *Guard:* input handling + bounded tools + least privilege.
- **Data residency breach** — telemetry leaves its permitted region. *Guard:* mapped data locations + governance pack.

Governance-pack skeleton

Unlocks in module 10.

The signable AI-in-operations pack the CISO and change board approve — data residency, AI change control, guardrails, audit, the autonomy ladder.

# AI-in-operations governance pack (skeleton)

Threaded from Module 1, consolidated here into something the CISO and CAB can sign.

## 1. Scope & data residency
- Which systems and data the AI touches, and where every byte lives.

## 2. Change control for AI actions
- How an AI-proposed change is proposed, approved and recorded — the same governed path as any change.

## 3. Guardrails & autonomy ladder
- What the AI may and may not do at each rung; how a rung is earned with evidence.

## 4. Access & least privilege
- Service accounts, scopes, and who holds them.

## 5. Audit & observability
- What is logged, retained, and how an action is reconstructed after the fact.

## 6. Human-in-the-loop
- Where the gates are, who approves, and the stop conditions.

## 7. Sign-off
- CISO / DPO, change board, sponsor — names and date.

Per-persona feedback templates

Unlocks in module 1.

Structured checkpoint prompts for each of the Cranfield cast, so client feedback is specific and comparable across modules.

# Per-persona feedback templates

Use at each client checkpoint. Match the evidence to what the persona actually fears.

## Dilan Petrou (sponsor, burned by shelfware)
- "Show me this will outlast the engagement." → handover plan + adoption.
- Opening line: the one measurable Week-10 outcome you put your name against.

## Marisol Vega (NOC / change control)
- "Walk me through how an AI-proposed change gets approved." → the human-approval gate.
- She must see: propose-not-apply, evidence shown, an explicit stop.

## Ken Adeyemi (CISO / DPO)
- "Show me the data-access, eval and risk controls in writing." → checkable readiness-gate statements.
- He must see: data residency, least privilege, no unattended production action.

## Priya Raman (service desk, early adopter)
- "Does this genuinely help my team without leaking user data?" → sanitisation + honest deflection metric.

## Tom Böttcher (CFO / procurement)
- "What does this actually save, against where we started?" → measured before/after vs the M2 baseline.

## Renata Cole (your delivery lead)
- "Is this a repeatable land-and-expand play?" → the artifacts + the 90-day expansion plan.

Capstone

Track A — Delivery lead · Full engagement package

The complete, presentation-ready Cranfield engagement: charter, estate map + baseline, opportunity map, blueprint + readiness gate, delivery foundation, three estate runbooks, integrated runbook pack, and the governance/adoption pack — defended with measured before/after.

Track A — Delivery lead · AI-in-operations governance standard

The standing control the client keeps: a signable governance pack — data residency, change control for AI actions, guardrails, audit, and the autonomy ladder — written so the CISO and change board actually approve it.

Track A — Delivery lead · Land-and-expand playbook

Renata's repeatable play: how one proven Cranfield pilot becomes a path across the estate, sequenced by value and readiness, with the 90-day plan and the artifacts that make it repeatable on the next account.

Track B — Deep build · Datacenter runbook, integrated

Go deep on one estate: the DC alert-correlation + capacity + not-suppressed validation runbook, wired to ServiceNow with a human gate, observability and rollback — a working integration, production-ready.

Track B — Deep build · Network assurance runbook, integrated

The network root-cause + config-drift + human-gated-change runbook as a working, reversible integration — every AI-proposed change human-approved, with the evidence Marisol would need to trust it.

Track B — Deep build · Workplace deflection runbook, integrated

The retrieval-grounded deflection + bounded self-heal runbook with the sanitisation step and an honest deflection metric, integrated end to end — proving no user data reaches the model.

Your own · Your own estate

The strongest capstone is a real engagement you actually face. If your organisation or a client has a live AI-in-operations decision, run the method on that one — the pushback will be free and genuine.

Milestones

• Module 2 — Estate assessment & baseline
• Module 4 — Blueprint + delivery-readiness gate
• Module 8 — Three estate runbooks
• Module 9 — Integrated runbook pack
• Module 10 — Engagement defended

Portfolio checklist

• Engagement charter + the dated Module-1 sealed baseline
• Estate map + rated data inventory + measured baseline (question marks preserved then closed)
• Opportunity map with quantified KPI hypotheses and buy/integrate/build calls
• Solution blueprint + the readiness gate as checkable statements
• Delivery-foundation plan + the shared scaffold, and your primary-estate choice
• Datacenter runbook: correlation, capacity forecast, incident-not-suppressed validation
• Network runbook: root-cause trace, drift finding, human-gated change
• Workplace runbook: grounded assistant, bounded self-heal, sanitisation, honest deflection metric
• Integrated runbook pack with observability evidence and the HITL gate design
• Signable AI-in-operations governance pack
• Measured ROI against the Module-2 baseline + the 90-day land-and-expand plan
• Capstone (Track A package or Track B deep build), presented and defended