# F2 — Engineering School / Computer Science
*3 ACF® teaching cases for Engineering Cycle programs, Master's Year 2, and Specialized Master's in cloud, SRE, cybersecurity, distributed systems, and DevOps.*

---

## F2-C1 — Multi-agent supervision of cloud infrastructure: who fixes what when everything is on fire

### Identity

| | |
|---|---|
| **Level** | Master's Year 2 / 3rd Year Engineering School / Specialized Master's SRE / Cloud Engineering Cycle |
| **Recommended duration** | 4h30 (1h analysis + 2h architectural design + 1h presentation + 30 min incident debrief) |
| **Format** | Teams of 4-5, presentation in the form of an architecture review before a Senior SRE panel |
| **Final deliverable** | Architecture Decision Record (ADR) in Google format + criticality matrix + Kill Switch protocol + simulated post-mortem |

### Brief

**FUNNELIQ — B2B SaaS revenue intelligence.** Pipeline analytics platform for B2B sales teams. ARR $142M (Q1 2026), Series D valuation $1.8B (Insight Partners + Tiger). 4,200 customers (SMB + mid-market + Fortune 500). 612 engineers.

**Stack**: 612 Kubernetes microservices (EKS + GKE multi-region, 14 regions), 1.4 billion events ingested/day, target p99 latency 80ms on critical APIs. 38 PB of hot data (Snowflake + BigQuery + ClickHouse). Target MTTR 12 min, actual 28 min on average (P50).

**The context.** The VP Eng (Aditi Sharma, 39, ex-Stripe) launched 8 months ago the **Sentinel** program: 12 monitoring + auto-remediation agents deployed in "co-pilot" mode (suggestion + human validation). Architecture:

- **Detector Agents** (4): real-time SLO/SLI analysis, anomaly detection via eBPF + OpenTelemetry traces
- **Diagnoser Agents** (3): root cause analysis via distributed traces, logs (Vector → ClickHouse), Prometheus metrics
- **Remediator Agents** (3): runbook playbook execution (rollback, scale, restart, route shift)
- **Coordinator Agent** (1): inter-agent arbitration in case of conflict
- **Observer Agent** (1): continuous audit of the other agents

The numbers from the past 8 months in co-pilot mode:
- Average MTTR: 28 min → 17 min (39% gain)
- False positives: 14% of alerts (manually corrected)
- Suggestions auto-applied by SRE: 71%

Aditi proposes **Sentinel-Auto**: switch 6 of the 12 agents to autonomous mode on 4 defined incident categories (pod restart, memory leak detection, certificate rotation, slow query alerting). Objective: MTTR 8 min, SRE team refocused on complex incidents.

**The tensions.**

- **SRE Lead Mathias Petersen** (37, ex-Google SRE) cites the **AWS us-east-1 December 7, 2021** incident: an auto-scaling script triggered a cascade of retries that saturated the internal subsystem service... for 9 hours. Also: **Cloudflare June 21, 2022** (config push that took down half the internet in 27 min). "An autonomous agent that makes a mistake makes that mistake at machine speed."
- **CISO Léa Hoffmann** (44) introduces the principle anchored in ANSSI guides (see *Computer Hygiene Guide* + publications on **logging and supervision**): any system that modifies a critical production state must have an accountability trail, except for documented exceptions. And **NIS2** (EU Directive 2022/2555 — French transposition in progress) requires an incident log auditable by the competent authority.
- **CTO Rajiv Patel** (52) defends autonomy: "We've already lost 2 senior SREs to burnout this year. If we don't reduce their load, we lose the team."
- The Product team is concerned: p99 latency during Sentinel operations has hit 340ms several times (vs. contractual SLA 100ms). 4 Fortune 500 customers have filed contractual escalations.
- The most recent incident (March 2026): a Remediator Agent attempted to correct a "memory leak" on a pod that was actually serving a legitimate batch workload. Restart during a critical export → partial corruption of a customer dataset. Recovery via backup in 4h. No contractual penalty, but the customer requested an audit.
- **DDAO Sara Eilenberg** (Delegated Decision Agent Officer, 41, ex-Principal SRE Stripe then Engineering Director Coinbase Custody — recruited 5 months ago in response to the March 2026 incident) — reports to the CTO but with a **direct reporting channel to the Board** on Tier 0 incidents. Position: "I refuse Sentinel-Auto on 6 agents until (1) the Coordinator Agent is immutable post-deployment, (2) there is a circuit breaker per agent (max N actions/min), (3) the blast radius SLO is explicitly bounded by service tier. On the current scope, I only authorize autonomy on Tier 2/3 and on a maximum of 2 incident categories — not 4."

### Mission

You are the Architecture & Reliability team (SRE Architect role). Decide in 3 sprints (6 weeks):

1. **Which agents move to autonomy, on which incident categories, with which safeguards?**
2. **What blast radius containment architecture to limit each agent's scope of action?**
3. **What continuous operational governance (review, pause, Kill Switch activation)?**

### Documents provided

- Sentinel architecture diagram (12 agents + interactions + dependencies)
- March 2026 incident post-mortem (8 pages)
- 3 runbooks used by Remediator Agents (pod restart, scale-out, route shift)
- SLO matrix per critical service (47 services)
- Extract from ANSSI guides on logging and supervision (4-page summary — *reference to public ANSSI guides*)
- Technical note: limits of eBPF observability on kernel < 5.10 (legacy EKS nodes)
- Industry comparables: *Practical Alerting* (chapter from the *Site Reliability Engineering* book, Google, Beyer et al.), Charity Majors SRE literature on observability, public post-mortem blogs (AWS, Cloudflare, Datadog)

### ACF tools to mobilize

ACF-01 + ACF-02 (per incident category × service criticality) → ACF-03 (Sentinel Constitution — 12 agents = need for a common behavior charter) → ACF-04 + ACF-12 (mandate per agent — differentiated) → ACF-07 (Deployment Dossier) → ACF-05 + ACF-09 (continuous supervision + improvement) → ACF-06 (Hierarchical Kill Switch: per agent / per category / global) → ACF-08 (Registry — NIS2 requirement) → ACF-11 (technical risk matrix) → ACF-13

### Expected deliverables

1. **Architecture Decision Record (ADR)** in Google format: context, options evaluated, decision, consequences, status
2. **Criticality matrix per incident category**: 4 categories proposed by Aditi + at least 2 categories to exclude from autonomy with justification
3. **Differentiated ACF-12 Mandates** for the 6 agents candidates for autonomy
4. **Kill Switch protocol in 3 levels**:
   - L1: Pause of a specific agent (triggerable by 1 SRE)
   - L2: Pause of a category (triggerable by SRE Lead)
   - L3: Global Sentinel pause (triggerable by CTO or on-call +30 min)
5. **Monitoring-the-monitoring plan**: who watches the agents who watch the infrastructure? Extended *Observer Agent* architecture
6. **Simulated post-mortem**: revisit the March 2026 incident and demonstrate that the new architecture would have prevented it (or not — honesty earns a bonus)
7. **DDAO Mandate for Sara Eilenberg**: scope of the right of opposition (per agent / per category / per service tier), conditions for global Sentinel freeze, direct Board access, review cadence (weekly during stabilization, monthly in steady state), articulation with SRE Lead Mathias Petersen (who validates what, who can override whom)

### Evaluation grid

- **Understanding of the context (15)**: having understood that **the 4 categories proposed by Aditi are not equivalent in blast radius**. Pod restart < memory leak detection < certificate rotation < slow query alerting (which can trigger a cascade query plan refresh)
- **Decision mapping (15)**: segment by service criticality (Tier 0 = customer-facing critical, Tier 1 = customer-facing standard, Tier 2 = internal, Tier 3 = batch). Autonomy can be asymmetric: T2/T3 OK, T0 never without human confirmation regardless of the incident
- **Relevance of the autonomy level (20)**: apply the principle of *least privilege* — each agent can only modify resources strictly necessary for its function. *Capability isolation* via Kubernetes RBAC and Service Account scoping
- **Safeguards (15)**: require for each automated action:
  1. A prior *dry run* with validation
  2. A *circuit breaker* (no more than N actions / minute per agent)
  3. An *automatic rollback* if the health metric does not improve within T seconds
  4. An *automatic escalation* if the action has been attempted 3 times without success
- **Anticipation of drifts (15)**: cite at least:
  - **Cascading failures** (an agent that fixes triggers a new outage — see AWS 2021)
  - **Coordinator Agent split-brain** (two agents give contradictory orders)
  - **Retry storm** (thundering herd effect when the agent retries massively)
  - **Goodhart on MTTR** (the agent "resolves" by marking the incident resolved without actually resolving it, optimizing the target metric)
- **Bold bonus (10)**: proposing an asymmetric **human-in-the-control-loop architecture** (the human is in the critical path only for T0, but receives passive notifications for T1/T2/T3 with asynchronous pause capability) earns a bonus. Refusing autonomy on *certificate rotation* with a cryptographic argument (downstream impact, root of trust) also earns a bonus

### Analysis paths (instructor)

**The trap**: team burnout pressure pushes toward maximum autonomy. Good participants identify that **burnout comes as much from complexity as from volume** — an agent that does stupid things very quickly increases the team's cognitive complexity (each alert requires understanding what the agent attempted).

**Common mistake**: confusing "auto-remediation" with "autonomous remediation." Prescriptive auto-remediation (hard-coded runbook) has existed for 20 years (see *N + 1 redundancy* automatic, *health check restart*). Agentic autonomy (the agent decides *what* to do in the face of a new situation) is qualitatively different.

**Subtle mistake**: forgetting that the **Observer Agent** (the agent that audits the other agents) is itself an agent. *Quis custodiet ipsos custodes?* — who watches the watcher? Acceptable answer: the Observer must be (1) very simple, (2) immutable post-deployment, (3) audited by a human at fixed frequency.

**Precise technical reference**:
- **Site Reliability Engineering** (Beyer et al., O'Reilly 2016) — *Practical Alerting* chapter
- **Charity Majors** on observability: *Observability Engineering* (O'Reilly 2022)
- **ANSSI guides** on logging and supervision (public publications)
- **NIS2** (EU Directive 2022/2555) — incident log requirement
- **Capability Elicitation** (METR methodology — Model Evaluation and Threat Research): evaluate what an agent can do beyond what it should do
- **Capability Stacking**: risk that the combination of individually legitimate agents produces an unintended collective capability

**Going further**: introduce the concept of the **incident pyramid**: for 1 catastrophic incident, we observe ~30 major incidents and ~300 near-misses. Large-scale autonomy modifies the pyramid by increasing the number of near-misses (which the human no longer sees) and by reducing the time between near-miss and catastrophe.

**The DDAO's reading of the case**: Sara Eilenberg brings the "blast radius per tier" dimension that no other function would bring spontaneously. The SRE Lead thinks in MTTR, the CTO in team burnout, the CISO in compliance — Sara thinks in *cost to customers in case of cascade*. Her reading is typically: "MTTR is not the right optimizer. The right optimizer is the combination MTTR × blast radius × tier criticality — and on this metric, autonomy on cert rotation is strictly inadvisable." A participant who delivers this metric-driven yet systemic reasoning is in excellence territory.

### Variants & extensions

- **V1 — chaos engineering**: inject a dependency failure (DNS resolver) during the session and observe the behavior of the 12 agents
- **V2 — multi-agent incident**: two Remediator Agents simultaneously attempt to correct the same symptom with two opposing actions (one wants to scale-out, the other wants to migrate the load). How does the Coordinator arbitrate? What does the Registry say?
- **V3 — supply chain attack**: a Detector Agent receives a compromised model update (SolarWinds-style) that leads it to flag a real incident as normal. What defense-in-depth architecture?

---

## F2-C2 — Autonomous SOC Agent: isolating a workstation while the user is in a client meeting

### Identity

| | |
|---|---|
| **Level** | Master's Year 2 Cybersecurity / Specialized Master's Digital Security / Engineering Cycle Security option |
| **Recommended duration** | 4h (1h30 brief + 2h design + 30 min presentation) |
| **Format** | Teams of 3-4, role-play CISO / SOC Lead / IT Service / Business Direction |
| **Final deliverable** | Autonomous IR playbook + decision matrix + SLA contractual clauses |

### Brief

**MERIDIAN BANQUE.** Mid-cap private bank, 1,200 employees, €18B in assets under management, 14 locations (FR + Lux + Switzerland + Singapore). Subject to: DORA (eff. 01/17/2025), NIS2, ACPR, FINMA (Switzerland), MAS (Singapore), CNIL/GDPR, French Military Programming Act (LPM) art. 22.

**The context.** The internal SOC is composed of 14 analysts (L1/L2/L3) + 4 Threat Intel + 2 IR. Volume: 8,200 alerts/day, of which 380 escalated, of which 22 qualified incidents/month. MTTD (mean time to detect): 14 min. MTTC (mean time to contain): 47 min. DORA regulatory MTTC target: *< 30 min* on critical incidents.

The CISO (Karim Yacoubi, 47, CISSP, ex-ANSSI) deployed in 2025 **Cyber-Sentinel**, an autonomous SOC agent based on Microsoft Security Copilot + custom layer. In "augmented" mode for 9 months:

- Automatic L1 triage (78% reduction in L1 volume)
- Assisted L2 investigation (41% gain in average investigation time)
- Response suggestion for L3 (acceptance rate 64%)

Karim proposes **Cyber-Sentinel-Auto**: switch to autonomous mode on 4 response categories:

1. **Endpoint isolation** (network disconnection of a workstation on compromise detection)
2. **Account suspension** (Active Directory deactivation on credential compromise)
3. **URL sinkholing** (redirection of DNS calls to a sinkhole on C2 detection)
4. **Email quarantine** (isolation of an incoming email suspected of phishing)

Proposed conditions: automatic triggering if confidence score > 0.92 AND no manual action within 90 seconds AND no "VIP flag" on the user.

**The tensions.**

- **Business management** (Private Banking GM Hélène Meier) recounts the November 2025 incident: an agent isolated the workstation of Pierre L., senior private banker, **during a video conference with a UHNWI client in Geneva** (potential €80M mandate). False positive: a legitimate marketing PDF but signed with an expired certificate. Reintegration in 18 minutes. Client lost (signed with UBS).
- **DPO Sandra Rocco** recalls that **AD account suspension** of an employee without managerial validation falls under labor law (conservatory measure). In case of a false positive, the risk is a formal notice or a labor tribunal case.
- **CIO François Bellanger** warns: the 4 proposed categories have asymmetric blast radii. Endpoint isolation = local, reversible. Global URL sinkholing = can break a critical business function (SWIFT payment for example).
- **The Audit Committee** recalls: an ACPR audit is announced for Q2 2026, with particular focus on "*auditability of automated decisions within the cybersecurity perimeter*." DORA art. 8 requires a documented governance framework for any critical ICT tool.
- **SOC Lead Wei Tang** defends autonomy: "On an ongoing ransomware incident, 30 seconds of difference = 800 encrypted workstations vs. 3 contained workstations."
- **DDAO Étienne Reverdy** (Delegated Decision Agent Officer, 52, ex-CISO Société Générale then 6 years at **ANSSI** on cyber doctrine) — recruited in September 2025 specifically to prepare the Q2 2026 ACPR audit, attached to the Risk Committee (and not to the CISO, to preserve independence). Position: "I'm not opposing Cyber-Sentinel-Auto as a whole — I'm opposing *this configuration*. Endpoint isolation and email quarantine on standard user: OK. Account suspension: NO without 2-of-3 human validation during business hours and NO without a reversibility mechanism < 60s. Global URL sinkholing: NO without explicit SOC Lead confirmation — the blast radius is too wide. And the concept of a static 'VIP flag' is insufficient: real-time contextual detection is needed (calendar, client label, active video call)."

### Mission

You are mandated by Meridian's Risk Committee. Deliver in 4 weeks:

1. **What autonomous response architecture to deploy (activated categories, triggering conditions, safeguards)?**
2. **Which contractual clauses to modify (internal SOC SLA, employee contracts, VIP client contracts)?**
3. **What framework for responding to the Q2 ACPR audit?**

### Documents provided

- Extracts from ANSSI guides on **incident response** and supervision (public reference publications)
- DORA framework (art. 5-13) — ICT governance extract
- CNIL position on **automated decisions** (art. 22 GDPR) applied to conservatory measures (see public positions + EDPB guidelines)
- Pierre L. incident post-mortem (November 2025, 6 pages)
- MITRE ATT&CK + ATLAS matrix (top 20 techniques observed at Meridian 2024-2025)
- Cyber-Sentinel metrics: false positive rate per category, per user segment, per time slot

### ACF tools to mobilize

ACF-01 + ACF-02 (per response category × user profile) → ACF-03 (Cyber-Sentinel Constitution — non-negotiable rules such as "never isolate a board-level workstation without 2nd human factor") → ACF-04 + ACF-12 → ACF-06 (Tiered Kill Switch) → ACF-08 (Registry — DORA requirement) → ACF-11 (risk matrix) → ACF-05 (continuous supervision with decision quality KPIs, not just volume)

### Expected deliverables

1. **4 × 4 matrix**: 4 response categories × 4 user criticality levels (Standard / Manager / Internal-VIP / Engaged-External-VIP) → autonomy / co-decision / suggestion decision per cell
2. **Cyber-Sentinel Constitution (ACF-03)**: 6-10 non-negotiable rules (e.g., "Never any action on a board-level account," "Never any deactivation during 7am-10pm window without L3 confirmation," etc.)
3. **Differentiated ACF-12 Mandate** per category
4. **Kill Switch protocol**: triggerable by CISO / SOC Lead / Board on-call on explicit signal (press alert, legal request, ACPR audit underway)
5. **Revised contractual clauses**:
   - Internal SOC SLA (response time commitment, false positive rate)
   - Employment contract addendum (information about IR automation, recourse)
   - Specific clause for UHNWI client contracts (priority service commitment)
6. **Anticipated response note for the ACPR audit**: demonstration of DORA art. 5-8 compliance
7. **DDAO Mandate for Étienne Reverdy**: scope of the right of opposition (per category × user profile), 2-of-3 human activation conditions, attachment to the Risk Committee, direct ACPR access in case of serious incident, articulation with CISO Karim Yacoubi (who validates what in routine vs. during active incident)

### Evaluation grid

- **Understanding of the context (15)**: simultaneously holding cybersecurity (speed essential) + business (client impact) + law (false positive = procedure) + audit (auditability). A participant who sacrifices one dimension caps at 10/15
- **Decision mapping (15)**: the 4×4 matrix must be built with rigor. Detecting that an Engaged-External-VIP (in a live client meeting) NEVER has acceptable auto-isolation, even on a very high confidence signal, is expected
- **Relevance of the autonomy level (20)**: autonomy justified on categories with local and reversible blast radius (endpoint isolation, email quarantine), co-decision on categories with identity impact (account suspension), suggestion on category with global blast radius (URL sinkholing). Inverting this logic = penalty
- **Safeguards (15)**: require for each autonomous action (1) a *reversibility signal < 60s*, (2) an *immediate user notification via alternative channel* (e.g., SMS), (3) an *escalation timer* (if the user or a third party does not validate within X min, L3 escalation)
- **Anticipation of drifts (15)**: cite at least:
  - **Adversarial AI**: an attacker who generates traffic resembling an incident to trigger targeted auto-isolation (indirect denial of service)
  - **Silent false negative**: the agent wrongly classifies as "non-incident" and closes the ticket without a human
  - **Authority capture**: by being right 92% of the time, human analysts validate without looking, creating a cognitive bottleneck
  - **Model drift**: the baseline changes (new business tool deployed), false positives explode in 48h
- **Bold bonus (10)**: explicitly refusing autonomy on the "Account suspension" category with a *labor law* argument + recommending instead a protocol of "session token isolation without account suspension" (technically intermediate) earns a bonus

### Analysis paths (instructor)

**The trap**: the "MTTC < 30 min via auto" promise seems irresistible for a CISO under DORA pressure. Good participants understand that **DORA does not demand autonomy, it demands traceability**. A 35-min MTTC with perfect auditability is better than a 12-min MTTC with an opaque decision.

**Common mistake**: forgetting that "confidence score > 0.92" is not a neutral threshold. **0.92 ≠ 8% error** — it's 8% error *among classifications made by the model*, on its training distribution. In production, a baseline change (new collab tool deployed, new network policy) can multiply errors by 10 without changing the displayed confidence. This is the classic *calibration drift* trap.

**Subtle mistake**: confusing "VIP flag" with "contextual criticality." A non-VIP private banker who is in the process of onboarding an €80M client is *contextually* as critical as a VIP. The right design is not based on a static flag but on a real-time contextual signal (calendar busy + active video call + client label).

**Technical reference**:
- **DORA** (EU Regulation 2022/2554) — art. 5 (ICT governance), art. 8 (incident management)
- **NIS2** (EU Directive 2022/2555)
- **MITRE ATT&CK** + **MITRE ATLAS** (adversarial AI taxonomy)
- **NIST AI RMF 1.0** (AI risk framework)
- **ANSSI guides** on incident response (public resources)
- **Capability Elicitation** (METR methodology): what the agent can do beyond what it should do

**The DDAO's reading of the case**: Étienne Reverdy brings what neither the SOC Lead (who thinks speed) nor the CISO (who thinks compliance) brings — the **reading by potential victim profile**. He insists that the 4×4 matrix (categories × user profile) be built **asymmetrically**: enhanced protections on Engaged-External-VIP are not limited to a static flag, they include a real-time contextual signal (calendar, client label, active video call). His major contribution: requiring an **immediate user notification mechanism via alternative channel** (SMS) for any auto-isolation — which transforms the worst-case scenario "Pierre L. in video call" into a simple "Pierre L. receives an SMS, asks the client for 30 seconds, calls the SOC." A participant who delivers this perspective change earns the bold bonus.

### Variants & extensions

- **V1 — ongoing ransomware incident**: an autonomous agent has isolated 47 workstations in 90 seconds. Bingo — real LockBit-3 attack contained. But 3 of the 47 workstations were outside the attack perimeter (false positives). 1 client negotiation interrupted. How does the Registry tell the story? How do we defend this at audit?
- **V2 — judicial requisition**: a judge asks "how was this automated decision made" (art. 22 GDPR + right to explanation). Does the ACF-08 Registry answer?
- **V3 — adversarial**: a red team simulates an attacker who exploits auto-isolation to neutralize a senior L3 during a real incident. Detection? Response?

---

## F2-C3 — CI/CD Agent with prod rollback: who pushes, who rolls back, who decides when we stop

### Identity

| | |
|---|---|
| **Level** | Master's Year 2 / Specialized Master's DevOps & SRE / Engineering Cycle spec. distributed systems |
| **Recommended duration** | 4h (1h analysis + 2h design + 1h chaos game) |
| **Format** | Teams of 3-4, live incident simulation (15 min chaos game) |
| **Final deliverable** | Autonomous deploy spec + canary protocol + tiered Kill Switch + simulated post-mortem |

### Brief

**SUNBLADE — DTC e-commerce men's fashion.** €84M ARR (2025), 11 EU + UK + US markets, 18 engineers. Monorepo stack (Turborepo), 47 microservices, GitOps via ArgoCD on multi-region EKS. Releases 12-18/day on average, but *0/day on Friday after 2pm* and *0 on weekends* (strict team policy).

**The context.** The team deployed **DeployBot**, a CI/CD agent based on Harness AI + custom layer:

- Generates release notes
- Scores PRs on 12 criteria (size, cyclomatic complexity, test coverage, dependencies, scope, etc.)
- On "low risk" scored PRs, launches build → tests → canary deployment 5% traffic → metrics analysis → progression 25% → 50% → 100% in 90 min
- On "high risk" scored PRs, stops at canary 5% and notifies a human

Tom Zhao (CTO, 33, ex-Shopify) proposes **DeployBot-Auto**: switch to total autonomy including **automatic rollback decision** on SLO breach signal. Today, rollback is manual (median 6 min, p99 18 min, median blast radius 14K affected orders).

**The tensions.**

- **SRE Lead Jonas Bohr** recalls the **Cloudflare June 21, 2022** incident (config push, 27 min global outage) and **Knight Capital August 1, 2012** (deployment bug, $440M lost in 45 min). Argument: "auto-rollback is a powerful decision, but auto-deploy + auto-rollback in the same agent creates an autonomous loop where the human is totally out."
- **Tech Lead Ana Paulino** defends: "Our p99 rollback is 18 min. During 18 min, we lose 200 orders/min. Doing this at machine speed is 90 seconds."
- **Head of Product Lucas Ferrari** is concerned: "If DeployBot automatically rolls back a highly anticipated feature (launch of the new line tomorrow), it can break a €600K marketing operation."
- **DevSecOps Eric Bernal** warns: an agent that can push AND rollback autonomously is a *capability* that must be audited independently. If compromised, it becomes the perfect weapon (push backdoor → "rollback" = but actually push something else).
- **The recent incident (April 2026)**: DeployBot deployed a feature that subtly degraded checkout latency (p99 +120ms, p50 unchanged). SLO breach detected at canary 50%. Automatic rollback suggested, validated by Jonas in 4 min. No customer loss. *But* the commit author (a senior engineer, 4 years on the team) was flagged as "high risk pattern" for his next PRs — implicit algorithmic discrimination.

### Mission

You are the Platform Engineering team. Decide in 2 sprints:

1. **What autonomy architecture for DeployBot — separation autonomous push / autonomous rollback / both?**
2. **What time windows, what services, what conditions for total autonomy?**
3. **What governance for the implicit "engineer risk scores" — to avoid drift?**

### Documents provided

- DeployBot architecture (12 modules + capabilities + permissions)
- 12-month metrics: number of deployments, post-deploy incident rate, MTTR rollback, blast radius per incident
- April 2026 post-mortem (4 pages) with appendix on PR author scoring
- Upcoming SOC2 Type II note (September 2026 audit, focus on change management)
- Industry comparables: **Spinnaker** (Netflix, open source continuous delivery platform), **Argo Rollouts** patterns (CNCF, *progressive delivery*), public post-mortems of deployment incidents (Cloudflare, GitHub, Slack)

### ACF tools to mobilize

ACF-01 + ACF-02 (per service type × release type × time window) → ACF-03 (DeployBot Constitution — non-negotiable rules) → ACF-04 + ACF-12 (mandate splitting push vs. rollback) → ACF-07 (progressive autonomy deployment) → ACF-05 + ACF-09 (continuous monitoring + improvement cycles) → ACF-06 (Tiered Kill Switch — pause a service / pause a window / global pause) → ACF-08 (registry — SOC2 requirement) → ACF-11 (technical risks)

### Expected deliverables

1. **Autonomy decision matrix**: Service type (T0/T1/T2/T3) × Release type (patch / minor / major / DB migration / config) × Time window (business hours / night / weekend) → autonomy level cell by cell
2. **Separate architecture**: should DeployBot **be a single agent or two** (independent Pusher Agent + Rollback Agent, communicating via an audited interface)? Argue
3. **DeployBot Constitution (ACF-03)**: non-negotiable rules such as "Never auto-deploy + auto-rollback within the same 60 minutes on the same service," "Never DB migration deployment in autonomy," "Never modification of a PR author's score without Lead validation"
4. **Kill Switch protocol in 3 levels** + **physical stop mechanism** (who can literally turn off DeployBot, how, with what SLA)
5. **Anti-algorithmic discrimination policy** on PR author scoring (transparency, recourse, annual audit)
6. **SOC2 audit response plan**: demonstration that changes in production are auditable and accountable

### Evaluation grid

- **Understanding of the context (15)**: having understood that autonomous push and autonomous rollback are **two different decisions** with **two different blast radii**. A participant who treats them as a single block caps at 9/15
- **Decision mapping (15)**: 3-dimensional matrix (service × release type × time window) built and defensible. No "all autonomous at night" without thinking about on-call
- **Relevance of the autonomy level (20)**: legitimate rollback autonomy on critical T0/T1 services (the cost of inaction is greater than the cost of an unnecessary rollback). Legitimate push autonomy on T2/T3 patches during business hours. **Refusing total autonomy (push + rollback) on DB migration or global config change** is expected
- **Safeguards (15)**: systematically require (1) a *canary minimum 15 min observation*, (2) a *blast radius cap* per release (e.g., no more than N% of traffic in the first 30 min), (3) a *cooldown* after rollback (no automatic redeployment of the same commit before human validation), (4) an *automatic change freeze* in case of successive rollbacks (3 rollbacks in 1h = global freeze)
- **Anticipation of drifts (15)**: cite at least:
  - **Infinite push-rollback loop** (DeployBot rolls back, but the next code also fails, etc.)
  - **Algorithmic discrimination of authors** (an engineer whose PRs are systematically scored "high risk" becomes marginalized without documented reason)
  - **Supply chain compromise** (DeployBot becomes a privileged attack vector)
  - **Loss of human capacity** (the team progressively loses the ability to deploy manually = internal vendor lock-in)
- **Bold bonus (10)**: recommending **two physically distinct agents** (Pusher and Rollback) with **audited interface + cryptographic attestation** between them. Refusing PR author scoring as a feature and replacing it with context scoring (PR size, complexity, scope) earns a bonus

### Analysis paths (instructor)

**The trap**: productivity pressure (12-18 releases/day) pushes toward saying "total autonomy." Good participants identify that **push autonomy and rollback autonomy are not symmetric**:
- Auto-rollback: conservative decision, *fail-safe direction*. The cost of an unnecessary rollback is low (a few minutes of the previous version). So autonomy is more easily justifiable.
- Auto-push: risky decision, *fail-forward direction*. The cost of a failed push is unbounded (see Knight Capital). Autonomy requires many more safeguards.

**Common mistake**: forgetting the **human dimension of PR author scoring**. An agent that learns "who produces risky PRs" de facto produces an undocumented, non-auditable performance scoring that can be used to justify HR decisions (refusal of raise, sidelining). This is a major drift that is often invisible. The best participants either (a) refuse author scoring, or (b) make it transparent + auditable + contestable.

**Subtle mistake**: confusing "automatic rollback" with "automatic *progressive deployment* with automatic stop." The latter is more prudent: the agent **does not advance** beyond canary 5% in case of doubt, but **does not decide** alone to revert code already in production. It's a smart intermediate option.

**Technical reference**:
- **Knight Capital incident 2012** — canonical blast radius reference ($440M lost in ~45 min)
- **Cloudflare incident June 21, 2022** — catastrophic config push
- **Spinnaker** (Netflix, open source continuous delivery platform)
- **Argo Rollouts** CNCF patterns (*progressive delivery*)
- **The Site Reliability Workbook** (O'Reilly 2018) — *Canarying releases* chapter
- **SOC2 Type II** — Trust Services Criteria, *Change Management*
- **NIST 800-53** — *CM-3 Configuration Change Control*

### Variants & extensions

- **V1 — Black Friday**: should DeployBot be active on BF (10× traffic, 0 errors tolerated)? Or in total freeze? Or in mode authorized only on rollback?
- **V2 — multi-layer incident**: DeployBot pushed a feature at 2pm. At 4pm, minor SLO breach signal. Automatic rollback. At 4:05pm, another feature pushed. At 4:08pm, another signal. Loop. When does the human come into play? Where did the Kill Switch fail?
- **V3 — chaos game (15 min) in presentation**: the panel simulates a live incident (chaos engineering script). The team must show how their architecture would have handled it

---

*End of file F2 — Engineering School / Computer Science. 3 cases, level of demand: Engineering Cycle, Master's Year 2, Specialized Master's.*
