AISE502/Folien/Planung_7-13_json/L10.json

{
  "lecture": 10,
  "week": 10,
  "lessons": 3,
  "title": "Lecture 10: The Fit II -- Hybrids, Evolution Paths, and the Decision Procedure",
  "script_reference": "Script: Part IV, Sections 35--36 and 33",
  "agenda": [
    "Hybrids and evolution paths -- fit as a function of time",
    "The eight-step decision procedure",
    "The reference run: ADR-007 -- compare it with your A2",
    "The ten matrix rows in detail",
    "This week's exercise: the deterministic core (M4)"
  ],
  "recap": [
    "Both operands are now yours: $C(p)$ for seven patterns (Part II, weeks 4--6) and $R(a)$ for ten classes (Part III: C10 in week 6, C1--C5 in week 8, C6--C9 in week 9)",
    "Lecture 7 (Part IV, first lecture): three cases, three stages -- knock-out and shape gate, veto with documented mitigation, holistic ordinal reading; $\\mathrm{fit}(a,p)$ formally; why not a weighted sum; cell semantics; the $7 \\times 10$ grid read by column and by row; the measurement contract introduced",
    "Lectures 8--9: all ten class profiles -- challenges $\\to$ binding scenarios $\\to$ weights $\\to$ what real systems chose",
    "Your project: A2 (ADR + C4 + measurement contract) passed the design-review gate in week 7; the walking skeleton runs end-to-end (M3); M4 -- the deterministic core -- starts this week",
    "Today, three moves: (1) what the matrix cannot say -- hybrids and fit as a function of time; (2) the eight-step procedure and the reference run ADR-007, to hold against your own A2; (3) the ten rows cell by cell -- the same evidence, now matched"
  ],
  "frames": [
    {
      "no": 1,
      "deck_section": "Title",
      "title": "AISE502: AI in Software Engineering II -- Lecture 10: The Fit II -- Hybrids, Evolution Paths, and the Decision Procedure",
      "kind": "content",
      "script_ref": "title slide; Script: Part IV, Sections 35--36 and 33",
      "content": [
        "\\FHGRTitlePage with \\subtitle{Lecture 10: The Fit II -- Hybrids, Evolution Paths, and the Decision Procedure\\\\[0.4ex]{\\small Script: Part IV, Sections 35--36 and 33}} (one-line 'Lecture N: Title -- Subtitle' form of deck 6)",
        "Author Dr. Florian Herzog; \\fullname{Fachhochschule Graub\\\"unden, Chur -- Autumn Semester 2026}"
      ],
      "elements": [
        "FHGR title page as in decks 1-6"
      ],
      "minutes": 0,
      "notes": "Identical metadata block to deck 6 (line 117-120); only subtitle and script line change. Graub\\\"unden with the umlaut macro, as in decks 1-6."
    },
    {
      "no": 2,
      "deck_section": "Agenda",
      "title": "Agenda",
      "kind": "agenda",
      "script_ref": "deck skeleton; semester plan week 10",
      "content": [
        "1. Hybrids and evolution paths -- fit as a function of time",
        "2. The eight-step decision procedure",
        "3. The reference run: ADR-007 -- compare it with your A2",
        "4. The ten matrix rows in detail",
        "5. This week's exercise: the deterministic core (M4)"
      ],
      "elements": [
        "enumerate, \\small, one short line per item as in deck 6"
      ],
      "minutes": 0,
      "notes": "Order follows the semester plan row for week 10: hybrids/evolution, eight-step procedure with ADR-007, row rationales deepened."
    },
    {
      "no": 3,
      "deck_section": "Recap",
      "title": "Recap: where we are",
      "kind": "recap",
      "script_ref": "deck 6 summary and next-week frame; semester plan weeks 7--9; project sheet M2--M4",
      "content": [
        "Both operands are now yours: $C(p)$ for seven patterns (Part II, weeks 4--6) and $R(a)$ for ten classes (Part III: C10 in week 6, C1--C5 in week 8, C6--C9 in week 9)",
        "Lecture 7 (Part IV, first lecture): three cases, three stages -- knock-out and shape gate, veto with documented mitigation, holistic ordinal reading; $\\mathrm{fit}(a,p)$ formally; why not a weighted sum; cell semantics; the $7 \\times 10$ grid read by column and by row; the measurement contract introduced",
        "Lectures 8--9: ten class profiles -- challenges $\\to$ binding scenarios $\\to$ weights $\\to$ what real systems chose",
        "Your project: A2 (ADR + C4 + measurement contract) passed the design-review gate in week 7; the walking skeleton runs end-to-end (M3); M4 -- the deterministic core -- starts this week",
        "Today's three moves: (1) what the matrix cannot say -- hybrids and fit as a function of time; (2) the eight-step procedure and the reference run ADR-007, to hold against your own A2; (3) the ten rows cell by cell -- the same evidence, now matched"
      ],
      "elements": [
        "bullet list, \\footnotesize; under its own \\section{Recap} as in decks 3 and 5"
      ],
      "minutes": 3,
      "notes": "One frame only. Decks 7-9 do not yet exist as files; recap is built from deck 6's next-week frame and the semester plan -- verify wording once decks 7-9 are typeset."
    },
    {
      "no": 4,
      "deck_section": "Hybrids and Evolution Paths",
      "title": "Hybrids and evolution paths: four episodes you already know",
      "kind": "content",
      "script_ref": "§35 intro (part4_fit.tex 491-494)",
      "content": [
        "Leading question in italics (bankblue): \\emph{What happens when a fit that was right stops being right?}",
        "You know all four episodes (Lectures 1, 4, 5, 6 and the support points of Lecture 7) -- the new reading is the sentence after them:",
        "2018, Segment: more than 140 per-destination services a small team could no longer test or operate -- consolidated into one deployable",
        "2023, Amazon Prime Video: monitoring workflow moved from serverless orchestration into a single process -- infrastructure cost cut by over 90\\,\\%",
        "Shopify: the opposite of extraction -- stay a monolith, enforce module boundaries with Packwerk, shard whole-monolith pods",
        "The classical outward move -- growing the new structure around a legacy core -- has carried its own name since 2004: the Strangler Fig",
        "\\textbf{None of these corrects a \\emph{wrong} initial decision}: each is a fit that \\emph{was} right decaying as profile, organisation, or measured load drifted -- \\textbf{Assumption A5 in production}",
        "Two instruments for exactly that situation, taught as rules rather than footnotes: \\textbf{hybrids} (different patterns where one no longer serves all subsystems) and \\textbf{evolution paths} (documented, repeatable repairs between patterns)"
      ],
      "elements": [
        "italic leading question; bullet list \\footnotesize -- the four episodes one line each, the A5 punchline and the two-instruments bullet the only two-line items"
      ],
      "minutes": 3,
      "notes": "Do not re-narrate: Segment and Prime Video carry numbers in decks 1 and 5, Prime Video's cost inversion is an examplebox in deck 6, Shopify/Packwerk in deck 4, and Lecture 7 (§34) placed all of them 'on a cell boundary, measured in money'. The substance of the frame is the A5 sentence (line 494) and the two instruments."
    },
    {
      "no": 5,
      "deck_section": "Hybrids and Evolution Paths",
      "title": "Hybrids are the normal case -- and the unit of evaluation",
      "kind": "keyconcept",
      "script_ref": "§35.1 (part4_fit.tex 496-498)",
      "content": [
        "Left column -- \\textbf{eight of the ten primary recommendations of §33 are compositions}: two-column table Class | Composition: C1, C5 -- a consistent core with event-driven edges; C7 -- a pipeline feeding a serving layer; C8 -- a log with stream processors; C9 -- a monolith with a specialised push layer; C10 -- a hexagonal core with pipelines and orchestration",
        "Left column, below the table: only C4 (the pure modular monolith) and C6 (the pure pipeline) come close to a single-pattern answer -- and even they carry subordinate pipelines and glue",
        "Left column, Lecture-7 reminder: every cell rates a pattern as the \\emph{dominant structure of the core} (bold = primary recommendation); the composition is stated in the row rationale, never in the cell value",
        "Right column -- keypoint: the unit of fit evaluation is the \\textbf{subsystem with its own architecture quantum} (its own unit of deployment, scaling, and failure); applying the matrix to a whole enterprise in one stroke is a \\textbf{category error the theory explicitly forbids}",
        "Right column: the question is never ``is this company a microservices company?'' but ``what is the dominant structure of \\emph{this} subsystem's core, and which patterns serve its edges?''",
        "Right column: the composition must be \\textbf{recorded} -- a C4-model container diagram is the natural notation, since the seven patterns differ most visibly at container level",
        "Project link (one line): your A2 C4 container diagram should be that record -- check that it shows which patterns own which container"
      ],
      "elements": [
        "two columns: left = \\scriptsize two-column table Class | Composition (line 496) plus two short bullets; right = keypoint box condensing line 498 (unit of fit evaluation, category error, C4 container diagram as the record) and a one-line projektbox or plain project-link line"
      ],
      "minutes": 4,
      "notes": "Merged from the former frames 5 and 6 (§35.1 is two paragraphs). The keypoint is the deck's own condensation of line 498 (the script has no keypoint here). Bridge to §33 later: 'we will see each of these compositions computed cell by cell in the last block'. The bold/cell-value reminder is Lecture 7 material (§32 definitionbox and tab:fitmatrix caption), marked as such."
    },
    {
      "no": 6,
      "deck_section": "Hybrids and Evolution Paths",
      "title": "Fit is a function of time -- Lehman's laws and MonolithFirst",
      "kind": "content",
      "script_ref": "§35.2 (part4_fit.tex 500-507)",
      "content": [
        "Lehman's laws guarantee the drift the four episodes displayed: a system embedded in the real world must \\textbf{continually change or become progressively less useful}, and its \\textbf{complexity increases unless work is invested to reduce it}",
        "Hence a fit established at design time \\emph{decays} (Assumption A5) -- and every recommendation must carry a \\textbf{migration strategy}; three documented strategies span the space",
        "\\textbf{MonolithFirst} (recap: Lecture 7, §34 column reading -- MM primary or secondary in seven of ten classes; Lecture 4's choose-when line): stable service boundaries cannot be cut before the domain is understood, so do not start with microservices even if you expect to need them",
        "New here: the matrix encodes this as the MM column's default dominance -- Lecture 7's ``unfashionable default''; the evolution path encodes it as the \\textbf{sanctioned starting state}",
        "(Strategies two and three -- Strangler Fig and sacrificial architecture -- on the next frame)"
      ],
      "elements": [
        "bullet list \\footnotesize; the MonolithFirst bullet labelled as recap in codegray"
      ],
      "minutes": 3,
      "notes": "The MonolithFirst argument was 'already met in Section matrix-reading' (line 507), i.e. §34 lines 466-467, taught in Lecture 7 ('MM primary or secondary in seven of ten rows of the grid'); deck 4 line 544 names it in the MM choose-when line. The only new content is the 'sanctioned starting state' sentence."
    },
    {
      "no": 7,
      "deck_section": "Hybrids and Evolution Paths",
      "title": "Fit is a function of time -- Strangler Fig in both directions, and sacrificial architecture",
      "kind": "content",
      "script_ref": "§35.2 (part4_fit.tex 508-509)",
      "content": [
        "\\textbf{Strangler Fig.} Grow the new structure around the old, intercepting and capturing function by function -- the migration stays \\emph{incremental and stoppable at any point}",
        "The pattern works in \\textbf{both directions}: \\emph{outward} -- extracting services from a monolith along verified module boundaries; \\emph{inward} -- the Segment and Prime Video consolidations that opened the section",
        "A \\textbf{third direction}, Uber's DOMA (Lecture 5): beyond roughly 2{,}200 services, a \\emph{second} structuring level (about 70 domains with gateways) had to be re-introduced -- convergence back towards macro-modules",
        "\\textbf{Sacrificial architecture.} Consciously accept that the current structure will be replaced in a few years while keeping internal quality high",
        "Especially legitimate for AI-native components whose model and tool landscape turns over in months (AI Lens, three frames on -- frame 10)"
      ],
      "elements": [
        "bullet list \\footnotesize; the two strategies as bold paragraph openers"
      ],
      "minutes": 4,
      "notes": "Keep the numbers exact: 'more than 140' (Segment), 'roughly 2,200 services', 'about 70 domains'. The DOMA numbers were shown in deck 5 (line 239) -- mark as Lecture 5."
    },
    {
      "no": 8,
      "deck_section": "Hybrids and Evolution Paths",
      "title": "The documented evolution paths -- a state diagram",
      "kind": "diagram",
      "script_ref": "§35.2, Figure fig:evolution (part4_fit.tex 514-540)",
      "content": [
        "tikz state diagram only -- states are patterns, transitions are named migration strategies with their documented cases; \\textbf{the six transitions appear solely as edge labels inside the figure} (as in the script), not as text bullets:",
        "edge L $\\to$ MM: enforce domain boundaries (Packwerk, ArchUnit, Modulith)",
        "edge MM $\\to$ MS: Strangler-Fig extraction when D11 measurably binds",
        "edge MS $\\to$ MM (curved back-arrow below): consolidation (Segment 2018)",
        "edge MS $\\to$ Domain-bundled services (DOMA): re-bundle into $\\sim$70 domains (Uber DOMA 2020)",
        "edge SL $\\to$ MM: process consolidation (Prime Video 2023, $-90\\,\\%$ cost)",
        "dashed arc L $\\to$ MM above: sacrificial rebuild (planned replacement)",
        "The only text below the figure, one \\footnotesize line: \\emph{The modular monolith is both the sanctioned starting state (MonolithFirst) and the documented consolidation target}"
      ],
      "elements": [
        "tikz: evolution-path state diagram, lines 517-535, redrawn 16:9 with rounded rectangles, deck palette (core = bankblue!20, comp = bankgreen!15, extern = gray!15), \\resizebox to 0.9\\textwidth; caption sentence (line 536) as the single \\footnotesize line beneath"
      ],
      "minutes": 4,
      "notes": "Node positions from the script (L at 0,0; MM at 8,0; MS at 16,0; SL at 0,-4; DOMA at 16,-4) may need horizontal compression for the slide; all six labelled transitions (including the dashed arc and the curved back-arrow) must survive. Bullets 2-7 of the content list are figure labels only -- render nothing else on the frame."
    },
    {
      "no": 9,
      "deck_section": "Hybrids and Evolution Paths",
      "title": "Maxim 5 -- buy options on tomorrow's profile",
      "kind": "keyconcept",
      "script_ref": "§35.2 keypoint (part4_fit.tex 542-544)",
      "content": [
        "\\textbf{Maxim 5.} Choose the pattern for the requirements profile you can \\emph{verify today}; buy \\emph{options} on the profile you expect tomorrow -- via module boundaries, ports, and a strangler-ready seam, \\textbf{not via speculative distribution}",
        "Every arrow in the evolution diagram is cheaper to traverse when the boundaries it needs were bought in advance as \\textbf{modules and ports} rather than as \\textbf{processes}",
        "Reading against the diagram: L $\\to$ MM buys the boundaries; MM $\\to$ MS spends them only when D11 \\emph{measurably} binds; the inward arrows (Segment, Prime Video) are cheaper when the seams already exist as modules and ports",
        "Project link: your Spring-Modulith-verified modules and the LLM gateway port are exactly such options (ADR-007, later today)"
      ],
      "elements": [
        "keypoint box: Maxim 5 verbatim-condensed from lines 542-544"
      ],
      "minutes": 3,
      "notes": "The third bullet is a reading aid derived only from the figure labels and the keypoint's second sentence; it must not attribute the inward consolidations to speculative distribution -- the script (line 494) says none of the episodes corrects a wrong initial decision."
    },
    {
      "no": 10,
      "deck_section": "Hybrids and Evolution Paths",
      "title": "AI Lens: sacrificial architecture for AI-native components",
      "kind": "ailens",
      "script_ref": "§35.2 ailinse (part4_fit.tex 546-548)",
      "content": [
        "ailinse[Axis B]: LLM providers deprecate models on windows of \\textbf{months, not years}, and the agent-framework landscape turns over even faster",
        "For the AI layer of a C10 system, sacrificial architecture is therefore \\textbf{not an admission of failure but the rational default}",
        "Design the AI subsystem \\emph{to be replaced} -- behind a port, with an \\textbf{eval harness as the acceptance gate for its successor} -- while the \\textbf{deterministic core is designed to last}",
        "The port boundary converts a provider deprecation from an \\emph{architecture revision} (the steep part of the cost-of-change curve, §37 next week) into an \\emph{adapter task}",
        "Project link: the AI layer you build in weeks 12--13 is sacrificial by design; the deterministic core you build this week (M4) is the part designed to last"
      ],
      "elements": [
        "ailinse box condensed from lines 546-548"
      ],
      "minutes": 3,
      "notes": "Point forward to next week's cost-of-change frame (Boehm vs Menzies) without teaching it."
    },
    {
      "no": 11,
      "deck_section": "The Decision Procedure",
      "title": "From a pre-filtered shortlist to a defensible decision",
      "kind": "table",
      "script_ref": "§36 intro and step titles (part4_fit.tex 553-567)",
      "content": [
        "Leading question in italics (bankblue): \\emph{How does a pre-filtered shortlist become a defensible decision?}",
        "One framing sentence: \\textbf{the matrix pre-filters; it does not decide.} The teachable, auditable procedure compresses the SEI method family into \\textbf{eight steps}, each with a defined \\emph{artefact} and a defined \\emph{measurement}, and continues into the life cycle per Assumption A5",
        "8-row \\scriptsize table Step | Artefact / measurement: (i) Identify the ASRs | ASR list, class hypothesis; (ii) Quality attribute scenarios | six-part scenarios with response measures; (iii) Utility tree | $(H,H)$ leaves = the weights of $R(a)$; (iv) Pre-filter via the matrix | shortlist of two to three candidates or compositions; (v) Trade-off analysis (ATAM-light) | sensitivity and tradeoff points, risks, weight variation; (vi) Decide and record as ADR | MADR record with drivers and options; (vii) Measurement contract | fitness functions with thresholds; (viii) Measure in operation | DORA and QA measures continually, Lehman indicators quarterly",
        "Closing line: (i)--(iii) the demand side, (iv)--(vi) the match under governance, (vii)--(viii) the genuinely new obligations -- detailed on the next three frames"
      ],
      "elements": [
        "italic leading question; one framing sentence; 8-row two-column \\scriptsize table Step | Artefact / measurement (assembled from the step texts, lines 557-566); no enumerating bullets"
      ],
      "minutes": 3,
      "notes": "Overview frame only; each step gets its detail on frames 12-14. The 'artefact' column is the deck's assembly from the step texts, not a script table. The script names no methods in the intro (line 555 cites Bass 2021, Barbacci 2003, Kazman 2000); 'SEI method family' stays without the deck's own expansion (ATAM/QAW/CBAM) -- CBAM first appears in step (v)."
    },
    {
      "no": 12,
      "deck_section": "The Decision Procedure",
      "title": "Steps (i)--(iii): the demand side -- ASRs, scenarios, utility tree",
      "kind": "content",
      "script_ref": "§36 steps (i)-(iii) (part4_fit.tex 557-559)",
      "content": [
        "\\textbf{(i) Identify the ASRs.} Mine business goals, stakeholder interviews, and the regulatory frame -- \\emph{not} the requirements document alone, which empirically under-specifies architecturally significant requirements",
        "Classify the system as an instance (or blend) of the ten application classes -- a \\textbf{hypothesis about its ASR bundle} to inherit and then correct",
        "\\textbf{(ii) Formulate quality attribute scenarios with response measures.} Six parts each; \\textbf{no scenario without a number}",
        "An unfalsifiable requirement cannot discriminate between patterns (Assumption A4)",
        "\\textbf{(iii) Prioritise in a utility tree.} Rate each leaf on (business importance, achievement difficulty) $\\in \\{H,M,L\\}^2$",
        "The $(H,H)$ leaves \\emph{are} the weights of $R(a)$ -- this is where the matrix weights come from, so they are \\textbf{derivable, not arbitrary}"
      ],
      "elements": [
        "bullet list \\footnotesize, step labels in bold"
      ],
      "minutes": 4,
      "notes": "Students did exactly this in weeks 2-3 (A1); say so, but the formal mapping comes on frame 15."
    },
    {
      "no": 13,
      "deck_section": "The Decision Procedure",
      "title": "Steps (iv)--(v): pre-filter via the matrix, then ATAM-light",
      "kind": "content",
      "script_ref": "§36 steps (iv)-(v) (part4_fit.tex 560-561)",
      "content": [
        "\\textbf{(iv) Pre-filter candidate patterns via the matrix.} Knock-out constraints and shape gate first, then the veto rule (the three stages of Lecture 7). Output: \\textbf{two to three candidate patterns or compositions}, including the hybrid options named in the relevant class row",
        "\\textbf{(v) Trade-off analysis (ATAM-light).} Walk the $(H,H)$ scenarios against each candidate's tactic bundle",
        "Identify \\textbf{sensitivity points} (one decision, large effect on \\emph{one} attribute) and \\textbf{tradeoff points} (one decision, opposing effects on \\emph{several} attributes); classify each as \\emph{risk} or \\emph{non-risk}",
        "Where money decides, extend with \\textbf{CBAM} utility-response curves -- what is 99.99\\,\\% availability \\emph{worth}, versus 99.9\\,\\%?",
        "Lecture 3's rule, now mandatory at step (v): \\textbf{sensitivity analysis} -- vary the weights plausibly; if the recommendation flips, you have found a genuine tradeoff point that deserves \\textbf{stakeholder negotiation, not a formula}"
      ],
      "elements": [
        "bullet list \\footnotesize; optional definitionbox[Sensitivity point / tradeoff point] with the two one-line definitions"
      ],
      "minutes": 4,
      "notes": "Tie the last bullet to deck 3's 'beware pseudo-precision' frame (deck 3 line 499) -- same rule, now as step (v)."
    },
    {
      "no": 14,
      "deck_section": "The Decision Procedure",
      "title": "Steps (vi)--(viii): record, contract, measure -- and keep the paths open",
      "kind": "content",
      "script_ref": "§36 steps (vi)-(viii) (part4_fit.tex 562-566)",
      "content": [
        "\\textbf{(vi) Decide and record as an ADR} -- Lecture 3's format (context, decision, consequences including the negative ones; superseded, never edited), now as step (vi). The one new element: the MADR fields ``decision drivers / considered options'' \\textbf{carry the utility-tree weights and the matrix row into the record} -- ISO/IEC/IEEE 42010 Clause 6.10 fulfilled by construction, architectural knowledge vaporisation countered",
        "\\textbf{(vii) Define the measurement contract.} Every ADR ends with the fitness functions that would \\emph{falsify} it -- with thresholds (§37, next week)",
        "\\textbf{(viii) Measure in operation and keep evolution paths open.} The DORA metrics and the quality-attribute-specific measures run \\emph{continually}; Lehman indicators (growth, complexity trend, debt stock) run \\emph{quarterly}",
        "When measurements falsify the decision, the sanctioned responses are the \\textbf{documented evolution paths} of §35 (the arrows of frame 8); a revised decision is a \\textbf{new ADR that supersedes} -- never silently overwrites -- the old one"
      ],
      "elements": [
        "bullet list \\footnotesize; (vi) labelled 'Lecture 3's format' in codegray"
      ],
      "minutes": 3,
      "notes": "Immutability, 42010's normative conclusion, MADR and the superseding ADR were taught in deck 3 (lines 535, 548, 591); only the drivers/options-carry-the-matrix-row sentence (line 563) is new. Link (viii) back to frame 8."
    },
    {
      "no": 15,
      "deck_section": "The Decision Procedure",
      "title": "Note how much of this you have already done -- and Maxim 6",
      "kind": "keyconcept",
      "script_ref": "§36 closing paragraph and keypoint (part4_fit.tex 569-573)",
      "content": [
        "Three-row \\scriptsize table Steps | Where you did it: (i)--(iii) | the pipeline Part III ran ten times (challenges $\\to$ binding scenarios $\\to$ utility-tree weights) -- inherited work, corrected against elicited scenarios; your A1, weeks 2--3",
        "(iv)--(vi) | the three cases of Lecture 7 performed \\emph{under governance} -- same gate, veto, ordinal reading; sensitivity analysis escalated to stakeholders, outcome recorded; your match and ADR, weeks 6--7",
        "(vii)--(viii) | the genuinely new obligations -- the remainder of Part IV (next week); your A2 measurement contract = a first pass at (vii); from M4 on your CI gates generate the first data the contract measures -- (viii) proper begins once the system is operated",
        "keypoint: \\textbf{Maxim 6} (restated from Part I). An architecture decision without a response measure is an \\emph{opinion}; with a response measure and a fitness function it is a \\emph{testable hypothesis}. The eight steps exist to manufacture exactly that transformation -- from stakeholder concern to falsifiable, monitored commitment"
      ],
      "elements": [
        "three-row mapping table Steps | Where you did it (\\scriptsize) from line 569 plus the project milestones; keypoint box Maxim 6 from lines 571-573 -- nothing else on the frame"
      ],
      "minutes": 2,
      "notes": "Former bullets 1-4 deleted (they restated the table). The A1/A2/M4 mapping uses the exercise sheet's milestone table and the semester plan only; (viii) is 'measure in operation' and does not coincide with M4."
    },
    {
      "no": 16,
      "deck_section": "The Reference Run: ADR-007",
      "title": "The reference run -- step (i): ASRs and classification",
      "kind": "case",
      "script_ref": "§36.1 examplebox steps (i)-(iv), part (i) (part4_fit.tex 578-579)",
      "content": [
        "Leading question in italics (bankblue): \\emph{You ran this procedure yourselves in weeks 6--7; here is the reference run to hold your A2 against.}",
        "examplebox[Decision run for the Portfolio Intelligence Platform (class C10) -- step (i)]: the platform analyses client portfolios and generates advisory answers with LLM support",
        "Stakeholder interviews and the regulatory frame yield the ASR bundle: \\textbf{grounded answers with provenance}; \\textbf{complete per-step audit logging} (EU AI Act duties may attach); \\textbf{per-request cost control}; \\textbf{provider-migration robustness}; an \\textbf{extreme change rate} for prompts and models",
        "Classification: an instance of \\textbf{C10}, inheriting C6/C7 traits (index and eval pipelines) and C3 traits (deterministic services) -- the inheritance diagram of week 6, now as the step-(i) hypothesis",
        "Check against your A2: which of these five ASRs does your dossier name -- and which did you find that this list lacks?"
      ],
      "elements": [
        "examplebox (script lines 578-579), first paragraph"
      ],
      "minutes": 3,
      "notes": "The examplebox of the script is split over frames 16-18; keep the title of the box on each."
    },
    {
      "no": 17,
      "deck_section": "The Reference Run: ADR-007",
      "title": "The reference run -- step (ii): the binding scenario, six parts and a number",
      "kind": "case",
      "script_ref": "§36.1 examplebox steps (i)-(iv), part (ii) (part4_fit.tex 581)",
      "content": [
        "The binding scenario, six parts: a customer (\\textbf{source}) submits a request for which the LLM generates a factually wrong recommendation (\\textbf{stimulus}) in normal operation (\\textbf{environment}) of the advisory platform (\\textbf{artifact}); the deterministic validation layer blocks the answer and escalates to a human (\\textbf{response}); detection rate $\\geq 99\\,\\%$ at $< 2$\\,s added latency (\\textbf{response measure})",
        "Companion scenarios fix three more numbers:",
        "cost budget: token cost per request $\\leq$ CHF 0.40 at p95",
        "latency budget: advisory answer $< 20$\\,s end-to-end",
        "migration scenario: provider deprecation absorbed within \\textbf{one sprint}, \\textbf{zero domain-code changes}",
        "No scenario without a number -- each of these becomes a fitness function in step (vii)"
      ],
      "elements": [
        "examplebox continued (line 581); six-part scenario rendered as one sentence with bold part labels, then three-item list for companions"
      ],
      "minutes": 3,
      "notes": "S1 and S2 of deck 6 (C10 binding scenarios, deck 6 lines 546-547) carry the same numbers (99 % at < 2 s; CHF 0.40 p95, 20 s); the migration scenario adds two new response measures (one sprint, zero domain-code changes) that deck 6's S3 (eval-harness pass rate before rollout) did not fix -- point out the continuity, do not re-derive."
    },
    {
      "no": 18,
      "deck_section": "The Reference Run: ADR-007",
      "title": "The reference run -- steps (iii) and (iv): utility tree and matrix shortlist",
      "kind": "case",
      "script_ref": "§36.1 examplebox steps (i)-(iv), parts (iii)-(iv) (part4_fit.tex 583-585)",
      "content": [
        "\\textbf{(iii) Utility tree.} The $(H,H)$ leaves land on D6 (auditability), D7 (evolvability under model churn), D9 (testability, operationalised as eval pass rate), D10 (cost per request), D12 (AI integrability) -- \\textbf{reproducing the High weights of the C10 column}, as the theory predicts",
        "\\textbf{(iv) Matrix shortlist.} The C10 row yields MM $++$ and HX $++$ as core candidates, with EDA $+$ (job/audit spine) and PF $+$ (ingestion and eval pipelines) as named edge patterns",
        "L is excluded by \\textbf{veto}; MS and SL are \\textbf{capped at $\\circ$}",
        "Shortlist: \\textbf{(a)} hexagonal modular monolith with pipelines and an async job spine; \\textbf{(b)} the same core with a fuller EDA backbone",
        "Two candidates, both compositions -- the hybrid options named in the class row, exactly as step (iv) prescribes"
      ],
      "elements": [
        "examplebox continued (lines 583-585); one-row booktabs strip with headers L MM HX MS EDA PF SL for C10: $-$ {\\boldmath$++$} {\\boldmath$++$} $\\circ$ $+$ $+$ $\\circ$ (tab:fitmatrix line 150)"
      ],
      "minutes": 4,
      "notes": "The full C10 row rationale comes in the last block (frame 36); here only the shortlist reading."
    },
    {
      "no": 19,
      "deck_section": "The Reference Run: ADR-007",
      "title": "The reference run -- step (v): ATAM-light, one sensitivity point, one tradeoff point",
      "kind": "case",
      "script_ref": "§36.1 examplebox steps (v)-(viii), part (v) (part4_fit.tex 588-589)",
      "content": [
        "examplebox[Decision run ... -- steps (v)--(viii)]: walking the $(H,H)$ scenarios against both candidates identifies",
        "one dominant \\textbf{sensitivity point}: the placement of the \\textbf{LLM gateway}, on which auditability, cost telemetry, and migration cost all hinge",
        "one genuine \\textbf{tradeoff point}: LLM \\textbf{context length} (answer quality up; cost and latency down)",
        "\\textbf{Weight variation test}: flips nothing between (a) and (b) for the core; it \\emph{does} flip the job-spine choice when audit-log completeness is weighted maximally -- recorded as a \\textbf{risk to be retired by a spike}",
        "\\textbf{CBAM reasoning settles the spine}: the fuller EDA backbone buys availability the class only weights \\textbf{Medium}, at an operations cost the class weights \\textbf{High} -- candidate \\textbf{(a) wins}"
      ],
      "elements": [
        "examplebox (lines 588-589), part (v)"
      ],
      "minutes": 4,
      "notes": "Show the Medium/High argument against the C10 profile table of deck 6 (D5 = M, D10 = H): CBAM here is a weight comparison, not a curve."
    },
    {
      "no": 20,
      "deck_section": "The Reference Run: ADR-007",
      "title": "The reference run -- steps (vi)--(viii): ADR, contract, operation, declared evolution paths",
      "kind": "case",
      "script_ref": "§36.1 examplebox steps (v)-(viii), parts (vi)-(viii) and closing paragraph (part4_fit.tex 591-595, 598)",
      "content": [
        "\\textbf{(vi) ADR.} Recorded as \\textbf{ADR-007}: decision drivers = the utility-tree weights; considered options = the matrix shortlist -- \\emph{one matrix row, narrated}",
        "\\textbf{(vii) Measurement contract.} ADR-007 ends with the fitness functions of the contract table (§37), each with threshold and cadence -- the seven lines follow on the record (frame 23)",
        "\\textbf{(viii) Operation.} DORA four keys per deployable unit; the eval harness gates every prompt and model change; Lehman indicators quarterly",
        "\\textbf{Declared evolution paths}, each a new, superseding ADR: extract the ingestion pipeline to its own quantum if batch load grows; replace the LLM adapter on deprecation (sacrificial by design); escalate to an EDA spine if audit volume demands it",
        "What makes the record more than paperwork: the \\textbf{considered options carry the matrix reasoning} (auditable) and the \\textbf{final section carries the measurement contract} (falsifiable); the gateway rule it relies on is subsequently fixed in its own record, \\textbf{ADR-011} (Lecture 3)"
      ],
      "elements": [
        "examplebox (lines 591-595), parts (vi)-(viii); closing paragraph of §36.1 (line 598) as the last bullet"
      ],
      "minutes": 3,
      "notes": "Deck-authored reading to offer orally, as a question: does the job-spine risk of step (v) reappear as the 'escalate to an EDA spine' path of step (viii)? The script does not state the link. The contract table itself (tab:contract) is next week's material; name only the six fitness-function families the examplebox lists. Ordering as the script states it ('subsequently fixed in ADR-011'), without dates -- deck 3 dated ADR-011 to 'your project, week 6'."
    },
    {
      "no": 21,
      "deck_section": "The Reference Run: ADR-007",
      "title": "ADR-007 (1/3): context and decision drivers",
      "kind": "content",
      "script_ref": "§36.1 Listing lst:adr007 (part4_fit.tex 601-618)",
      "content": [
        "Narrow left column (\\scriptsize, codegray) tagging each listing section with the step that produced it: Context = (i); Decision drivers = (iii)",
        "Monospace box (\\scriptsize\\ttfamily, as ADR-011 in deck 3): \\textbf{ADR-007: Hexagonal modular monolith with LLM gateway} -- Status: accepted (2026-10-12) | supersedes: ADR-003",
        "\\textbf{Context and problem statement:} the Portfolio Intelligence Platform (class C10) must deliver grounded advisory answers with full audit logging (EU AI Act), per-request cost control, and robustness against LLM provider deprecation; change rate of prompts/models is extreme; the deterministic services (data access, portfolio computation, audit) have classical back-office profiles",
        "\\textbf{Decision drivers (utility-tree (H,H) leaves):} D6 auditability -- every agent step reconstructable; D7 evolvability under model churn; D9 testability = eval pass rate $\\geq 95\\,\\%$ in CI; D10 token cost per request $\\leq$ CHF 0.40 (p95); D12 AI integrability -- queue, port, measurement point"
      ],
      "elements": [
        "tcolorbox gray, \\scriptsize\\ttfamily, reproducing listing lines 601-618 (about 12 monospace lines after removing blank lines) in the format of deck 3's ADR-011 frame; step-tag column on the left"
      ],
      "minutes": 3,
      "notes": "Keep the listing text verbatim; remove blank lines. About the size of deck 3's ADR-011 box."
    },
    {
      "no": 22,
      "deck_section": "The Reference Run: ADR-007",
      "title": "ADR-007 (2/3): considered options and decision",
      "kind": "content",
      "script_ref": "§36.1 Listing lst:adr007 (part4_fit.tex 620-632)",
      "content": [
        "Step tags: Considered options = (iv); Decision = (v)/(vi)",
        "\\textbf{Considered options (matrix shortlist, Table fit-c10):} 1. Hexagonal modular monolith + PF pipelines + async jobs (++); 2. Same core + full EDA backbone for jobs/audit (+); 3. Microservices per capability (o); 4. Layered monolith (-, veto D7)",
        "\\textbf{Decision:} Option 1. Deterministic core as Spring-Modulith-verified modules; all LLM access via one gateway port (adapter owns prompts, schema validation, retries, cost telemetry); ingestion/eval as versioned pipelines; agent workflow orchestrated, not autonomous: \\textbf{agents propose, deterministic services decide and book}"
      ],
      "elements": [
        "tcolorbox gray, \\scriptsize\\ttfamily, reproducing listing lines 620-632 (about 11 monospace lines) with the step-tag column"
      ],
      "minutes": 2,
      "notes": "Keep the ASCII ratings (++, +, o, -) as they appear in the Markdown record. The options block is the record form of frame 18's shortlist -- say so rather than re-reading it."
    },
    {
      "no": 23,
      "deck_section": "The Reference Run: ADR-007",
      "title": "ADR-007 (3/3): consequences and measurement contract",
      "kind": "content",
      "script_ref": "§36.1 Listing lst:adr007 (part4_fit.tex 634-647)",
      "content": [
        "Step tags: Consequences = (vi); Measurement contract = (vii)/(viii)",
        "\\textbf{Consequences:} + provider deprecation = adapter task, not architecture revision; + single measurement point for cost, latency, audit; -- release coordination across modules (accepted, 2 teams); -- async job spine limited; EDA escalation path documented",
        "\\textbf{Measurement contract (falsifies this ADR):} ArchUnit/Modulith verify: 0 undeclared cross-module deps; static rule: no domain service imports the LLM gateway except via the declared port (0 violations); p95 advisory answer $< 20$\\,s (CI gate + production SLO); eval harness pass rate $\\geq 95\\,\\%$ on golden set, 0 ontology-violating outputs shipped; token cost per request $\\leq$ CHF 0.40 at p95 (continual); daily reconciliation booked vs. journaled: 0 discrepancies; DORA four keys per deployable unit, review quarterly"
      ],
      "elements": [
        "tcolorbox gray, \\scriptsize\\ttfamily, reproducing listing lines 634-647 (four consequence lines + seven contract lines + two headings, about 14 monospace lines) with the step-tag column"
      ],
      "minutes": 3,
      "notes": "Remove blank lines; if still tight, render the seven contract lines as a \\footnotesize itemize below the box exactly as deck 3's 'Confirmation' list."
    },
    {
      "no": 24,
      "deck_section": "The Reference Run: ADR-007",
      "title": "Discussion",
      "kind": "discussion",
      "script_ref": "deck-authored, derived from §36 steps (part4_fit.tex 557-566) and lst:adr007 (600-648); exercise sheet M2 (A2 = ADR + C4 + measurement contract)",
      "content": [
        "thinkbox (Discussion) -- hold your A2 against the reference run:",
        "1. Do your considered options name the matrix row and the vetoes behind each exclusion -- or only the winner?",
        "2. Which of the seven ADR-007 fitness functions does your measurement contract carry, with a threshold and a cadence? Which is missing?",
        "3. Your step (v): what was your sensitivity point, what your tradeoff point -- and did any weight variation flip a choice?",
        "4. Which evolution path did you declare -- and is the seam for it bought as a module or port, or would it require a process boundary?"
      ],
      "elements": [
        "thinkbox alone, titled 'Discussion' as in decks 1, 3 and 5"
      ],
      "minutes": 6,
      "notes": "The script provides no thinkbox for §35/§36; the four questions are derived strictly from the ADR-007 content and the step list -- flagged in open_issues. Real six-minute slot for pair discussion (funded by the merges on frames 5 and 15)."
    },
    {
      "no": 25,
      "deck_section": "The Ten Rows in Detail",
      "title": "The ten rows in detail -- how to read a row rationale",
      "kind": "content",
      "script_ref": "§33 intro (part4_fit.tex 167-171); §32 keypoint (part4_fit.tex 163-165)",
      "content": [
        "Leading question in italics (bankblue): \\emph{Every cell of the grid is a verdict -- where is the computation behind it?}",
        "For each class the row rationale records the \\textbf{stage-by-stage computation} behind every cell -- per cell: which gate or knock-out fired, which \\textbf{veto} (the High-weight dimension on which the veto rule fired), which documented \\textbf{mitigation} (tactic or hybrid composition) lifted the cap -- plus the primary and secondary recommendation and the \\textbf{central trade-off} the class forces",
        "\\textbf{Nothing in this section is new evidence: it is the same evidence, now matched} -- the production systems and numbers live in Part III's ``what real systems chose'' and are back-referenced, not re-narrated",
        "Reminder (Lecture 7): a cell answers one question only -- \\emph{how well does this pattern serve as the dominant structure of this class's core?} -- edges routinely use patterns whose cell reads $\\circ$ or $-$"
      ],
      "elements": [
        "bullet list \\footnotesize; the last bullet as a one-line keypoint condensed from lines 163-165"
      ],
      "minutes": 3,
      "notes": "Rows C6, C1, C2 were computed as the three cases in Lecture 7 -- say that the tables now complete them cell by cell. Former bullets 2-3 merged, the operands/evidence bookkeeping bullet cut."
    },
    {
      "no": 26,
      "deck_section": "The Ten Rows in Detail",
      "title": "The $7 \\times 10$ grid, for reference",
      "kind": "table",
      "script_ref": "§32 Table tab:fitmatrix (part4_fit.tex 127-152)",
      "content": [
        "Header: Application class | L | MM | HX$^{\\dagger}$ | MS | EDA | PF | SL",
        "C1 Core banking / transactions: $\\circ$ & {\\boldmath$++$} & {\\boldmath$++$} & $\\circ$ & $-$ & $\\circ$ & $-$",
        "C2 Social media / content platform: $\\circ$ & $+$ & $\\circ$ & {\\boldmath$++$} & {\\boldmath$++$} & $\\circ$ & $\\circ$",
        "C3 Back-office / workflow: $+$ & {\\boldmath$++$} & $+$ & $--$ & $-$ & $\\circ$ & $\\circ$",
        "C4 ERP / enterprise core system: $\\circ$ & {\\boldmath$++$} & $+$ & $--$ & $-$ & $\\circ$ & $--$",
        "C5 E-commerce platform: $-$ & {\\boldmath$++$} & $+$ & $+$ & $+$ & $\\circ$ & $+$",
        "C6 Simulation / batch compute: $--$ & $\\circ$ & $\\circ$ & $--$ & $\\circ$ & {\\boldmath$++$} & $\\circ$",
        "C7 Decision support / BI analytics: $+$ & $+$ & $\\circ$ & $-$ & $\\circ$ & {\\boldmath$++$} & $+$",
        "C8 Real-time / IoT streaming: $--$ & $-$ & $\\circ$ & $+$ & {\\boldmath$++$} & $+$ & $-$",
        "C9 Collaboration / messaging: $\\circ$ & $+$ & $\\circ$ & $+$ & {\\boldmath$++$} & $-$ & $--$",
        "C10 AI-native analysis / advisory: $-$ & {\\boldmath$++$} & {\\boldmath$++$} & $\\circ$ & $+$ & $+$ & $\\circ$",
        "Footnote: $^{\\dagger}$ HX is a delta pattern -- composes with a host (typically MM), cells read ``as the internal discipline of the class's core''; the HX column is never negative"
      ],
      "elements": [
        "10x7 booktabs table (\\scriptsize, no vertical rules, {\\boldmath$++$} on primary-recommendation cells) from tab:fitmatrix lines 131-152; footnote line condensed from lines 155-156"
      ],
      "minutes": 1,
      "notes": "Reference only -- taught in Lecture 7. Keep on screen briefly; students look back at it during the row frames. The row frames carry no separate strip: their Fit column already shows the row."
    },
    {
      "no": 27,
      "deck_section": "The Ten Rows in Detail",
      "title": "C1 -- core banking: the canonical hybrid, ACID core and EDA edges",
      "kind": "table",
      "script_ref": "§33.1 Table tab:fit-c1 and verdict (part4_fit.tex 173-200)",
      "content": [
        "Leading line (\\footnotesize): Case 2 of Lecture 7 computed this row's contested pair, MM against MS; the table completes the remaining cells",
        "L $\\circ$: a single ACID database satisfies the consistency veto, but technical layering fails decades-long evolvability (veto D7) and the change-isolation needs of a banking core",
        "MM {\\boldmath$++$}: cross-module ACID plus enforced domain boundaries match the consistency veto and the peripheral change rate (veto D5; mitigation: hot-standby replication) -- Fineract's production architecture",
        "HX {\\boldmath$++$}: ports isolate a long-lived booking core from volatile channels, providers, and AI scoring adapters; the core becomes hermetically testable -- the standard bank-backend discipline",
        "MS $\\circ$: sagas replace ACID in the money path (veto D4; mitigation only under the Monzo condition: organisational scale plus extreme homogeneity); premium paid in platform staff for no gain at typical team sizes",
        "EDA $-$: eventual consistency vetoed in the booking core (veto D4: High against $--$, uncapped as dominant structure); as an \\emph{edge} pattern the immutable event journal is the natural regulatory audit trail",
        "PF $\\circ$: shape gate -- end-of-day clearing, statements, and risk runs are genuine batch pipelines, but the pattern cannot carry the interactive account core",
        "SL $-$: stateful sequential ordering, strict guarantees, auditable long-lived state vs. ephemeral stateless functions (veto D4; weak on all remaining High-weight dimensions)",
        "One bold line under the table: \\textbf{Primary: hexagonal modular monolith for the booking core -- central trade-off: consistency vs. scalability, resolved by \\emph{placing} patterns: ACID core, EDA edges}"
      ],
      "elements": [
        "7-row table Pattern | Fit | Rationale (\\scriptsize, p{8.6cm} rationale column, arraystretch 0.85, every rationale cell capped at two lines, about 180 characters) condensed from tab:fit-c1 lines 180-194; one bold \\footnotesize line from line 199 -- no verdict paragraph"
      ],
      "minutes": 4,
      "notes": "Anchor row, 4 minutes. Secondary recommendation (EDA edges, PF batch runs, MS under the Monzo condition), the LMAX extreme and the reconciliation fitness functions are on the synthesis frame 38 only. Same template for frames 28-35."
    },
    {
      "no": 28,
      "deck_section": "The Ten Rows in Detail",
      "title": "C2 -- social media / content platform: the mirror image of C1",
      "kind": "table",
      "script_ref": "§33.2 Table tab:fit-c2 and verdict (part4_fit.tex 202-229)",
      "content": [
        "Leading line (\\footnotesize): Case 3 of Lecture 7 ran this row's Stage-3 finale between MS and EDA; the table records the full row",
        "L $\\circ$: Instagram proves a layered monolith scales reads via stateless replication, but single-quantum releases and technical partitioning throttle High-weighted feature velocity (veto D7, D11)",
        "MM $+$: Instagram-style scaling plus domain-cut change isolation (veto D5; mitigation: replicated instances); the honest ceiling is release coordination once team count passes roughly five",
        "HX $\\circ$: adds testability, but the binding constraints (read fan-out, team scaling) live elsewhere, and feed paths carry little long-lived domain logic",
        "MS {\\boldmath$++$}: independent scaling of feed, media, graph services plus independent team deployments match D1, D7, D11 at once (veto D3; mitigation: edge caching, precomputed timelines); $--$ on cost accepted",
        "EDA {\\boldmath$++$}: fan-out-on-write \\emph{is} an event flow -- the Twitter timeline architecture; new consumers attach without touching producers (veto D9; mitigation: schema/contract tests plus progressive delivery)",
        "PF $\\circ$: shape gate -- feed precomputation, ranking-model training, media processing are pipelines beside the serving path, never the interactive product core",
        "SL $\\circ$: viral spikes suit elastic functions (veto D3: cold starts), yet sustained baseline load makes per-execution pricing structurally expensive",
        "One bold line under the table: \\textbf{Primary: EDA + microservices hybrid at organisational scale -- central trade-off: read scalability and team scaling vs. simplicity and cost; the exact mirror of C1}"
      ],
      "elements": [
        "7-row table condensed from tab:fit-c2 lines 209-223 (cells capped at two lines); one bold line from line 228"
      ],
      "minutes": 4,
      "notes": "Anchor row, 4 minutes. Refer back to the deck-6 mirror-pair frame; the new content is the cell-by-cell veto/mitigation trail. Secondary (MM until scale is measured -- Mastodon) and the deciding measurement (deployments per developer per day) are on frame 38."
    },
    {
      "no": 29,
      "deck_section": "The Ten Rows in Detail",
      "title": "C3 -- back-office / workflow: day-one simplicity vs. multi-decade evolvability",
      "kind": "table",
      "script_ref": "§33.3 Table tab:fit-c3 and verdict (part4_fit.tex 231-258)",
      "content": [
        "L $+$: CRUD over one ACID store at office-hours load is the native habitat (High D8 rewards simplicity); the $-$ on High-weighted evolvability is the legacy-rot risk (veto D7; mitigation: scoping, hence $+$)",
        "MM {\\boldmath$++$}: the same run cost with domain boundaries that pay off over the 10--20-year evolution horizon dominating this class's cost -- the Pareto choice when process change is frequent",
        "HX $+$: worth the indirection where long-lived process logic meets volatile integrations -- LDAP, ERP, DMS, workflow engine as adapter (veto D8; mitigation: ports only at the integration seams)",
        "MS $--$: the premium buys scaling and team autonomy this class does not need, at simplicity and run costs \\textbf{vetoed twice} (veto D8, D10)",
        "EDA $-$: asynchronous choreography destroys the traceable, sequential process semantics (four-eyes principle, audit trail) the class is built around (veto D8: $--$ on High); a workflow engine, not a broker",
        "PF $\\circ$: shape gate -- nightly reporting jobs and imports are pipelines at the edge of an interactive forms-over-data core",
        "SL $\\circ$: sporadic office-hours load fits scale-to-zero economics, but the operational skill investment rarely amortises for internal IT",
        "One bold line: \\textbf{Primary: modular monolith with externalised process logic (a Camunda-class workflow engine behind a port) -- central trade-off: day-one simplicity vs. multi-decade evolvability}"
      ],
      "elements": [
        "7-row table condensed from tab:fit-c3 lines 238-252 (cells capped at two lines); one bold line from line 257"
      ],
      "minutes": 3,
      "notes": "Deck 3's Discussion (L +, MM ++, MS --) predicted exactly this row -- point it out. Secondary (L for small, stable scope) and the tiebreaker (change dispersion per process change) on frame 38."
    },
    {
      "no": 30,
      "deck_section": "The Ten Rows in Detail",
      "title": "C4 -- ERP core: the strongest anti-fit in the grid",
      "kind": "table",
      "script_ref": "§33.4 Table tab:fit-c4 and verdict (part4_fit.tex 260-287)",
      "content": [
        "L $\\circ$: one schema, one transaction scope fits the integration mandate, but technical layers offer no discipline against permanent customising pressure (veto D7; no scoping mitigation -- ERP scope is never small)",
        "MM {\\boldmath$++$}: modules over a shared ACID data model with a disciplined extension mechanism is \\emph{literally} Odoo/ERPNext; \\textbf{no veto fires} -- the $-$ on D5 is Medium-weight (maintenance windows accepted)",
        "HX $+$: ports pay off at the integration peripheries (EDI, banking, tax services) and keep customising out of the core -- the survival condition for 20--30-year life cycles",
        "MS $--$: cross-module ACID postings (order $\\to$ stock $\\to$ ledger) are the product's value and become distributed sagas (veto D4) -- \\textbf{structurally the strongest anti-fit in the grid}",
        "EDA $-$: eventual consistency between ledger and inventory contradicts the class's defining integrity guarantee (veto D4); events serve only outbound integration",
        "PF $\\circ$: shape gate -- period-end closing, MRP, payroll runs are canonical scheduled pipelines inside the batch window: a subordinate, well-fitting component",
        "SL $--$: long transactions, batch windows, stateful sessions, monolithic data model contradict short-lived stateless functions on every axis (veto D4, plus the sustained-load cost inversion)",
        "One bold line: \\textbf{Primary: modular monolith -- central trade-off: one integrated data model vs. independent module scaling and deployment, resolved by module boundaries \\emph{inside} one transactional quantum}"
      ],
      "elements": [
        "7-row table condensed from tab:fit-c4 lines 267-281 (cells capped at two lines); one bold line from line 286"
      ],
      "minutes": 3,
      "notes": "Only C4 and C6 come close to single-pattern answers (frame 5) -- C4 is the first of the two. The ERP-practice evidence sentence and the secondary (HX inside, L for very small scope) on frame 38."
    },
    {
      "no": 31,
      "deck_section": "The Ten Rows in Detail",
      "title": "C5 -- e-commerce: seasonal elasticity vs. checkout consistency",
      "kind": "table",
      "script_ref": "§33.5 Table tab:fit-c5 and verdict (part4_fit.tex 289-316)",
      "content": [
        "L $-$: a small shop is served honestly, but the single write path is what the defining 10--50$\\times$ seasonal peaks break (veto D2: $--$ on High, no mitigation within the pattern); full-regression releases fail D9",
        "MM {\\boldmath$++$}: Shopify's Packwerk-enforced modular Rails core carries roughly 280 million requests per minute while preserving checkout ACID (veto D2, D5; mitigation: pod-sharded replication, replicated pods)",
        "HX $+$: ports around payment, logistics, tax, and search providers localise very high integration churn -- and shrink the PCI audit scope",
        "MS $+$: Amazon's founding case shows the fit at organisational scale (veto D3; mitigation: caching, edge delivery); below that scale the platform premium ($--$ on Medium D10) eats margin -- $++$ only when D11 binds",
        "EDA $+$: order flows, inventory updates, saga-based checkout choreography are event-shaped at the edges of an ACID checkout (veto D9; mitigation: contract tests, progressive delivery)",
        "PF $\\circ$: shape gate -- catalogue feeds, search indexing, recommendation training are supporting pipelines, not the storefront",
        "SL $+$: flash-sale spikes are the textbook elastic-load case (veto D3; mitigation: provisioned concurrency, edge runtimes); sustained catalogue traffic and checkout latency SLOs keep it from primary status",
        "One bold line: \\textbf{Primary: modular monolith with a hybrid consistency profile inside (catalogue eventual, checkout ACID) and event-driven edges -- central trade-off: seasonal elasticity vs. checkout consistency}"
      ],
      "elements": [
        "7-row table condensed from tab:fit-c5 lines 296-310 (cells capped at two lines); one bold line from line 315"
      ],
      "minutes": 3,
      "notes": "Shopify closes the loop with frame 4 (the evolution episode) -- same case, now as a matrix cell. The 'flattest row' gloss is dropped (not in the script). Secondary (MS at organisational scale -- team size, not traffic, decides) and the contract (p95 checkout latency, zero uncompensated oversells at 10x baseline) on frame 38."
    },
    {
      "no": 32,
      "deck_section": "The Ten Rows in Detail",
      "title": "C6 -- simulation / batch compute: a row decided at Stage 1",
      "kind": "table",
      "script_ref": "§33.6 Table tab:fit-c6 and verdict (part4_fit.tex 318-345)",
      "content": [
        "Leading line (\\footnotesize): Case 1 of Lecture 7 computed this row almost entirely at Stage 1; the table records the per-cell residue",
        "L $--$: shape gate plus veto D2 -- an interactive serving pattern has no answer to makespan, checkpointing, or CPU-hour cost: a category error",
        "MM $\\circ$: numeric kernels are monolithic \\emph{code} (OpenFOAM-style), but the architecture class around them is the pipeline; the module system contributes nothing to throughput (cap via D2)",
        "HX $\\circ$: ports around solvers and data sources buy testability of orchestration code; the compute core and the binding cost dimension are untouched",
        "MS $--$: distributing a tightly coupled numeric dataflow across service boundaries multiplies communication cost (veto D10) -- the general form of the Prime Video lesson at HPC scale",
        "EDA $\\circ$: a replayable log is useful glue for job status, but continuous event semantics add machinery where a scheduler and a DAG already express the control flow (cap via D9)",
        "PF {\\boldmath$++$}: immutable inputs $\\to$ deterministic stages $\\to$ versioned outputs under Slurm/Airflow/Spark is the dominant form, reproducibility by construction",
        "SL $\\circ$: embarrassingly parallel bursts (Monte-Carlo fan-out) fit FaaS elasticity, but data-heavy inter-stage communication through storage recreates the Prime Video cost trap (split D10 resolves against it)",
        "One bold line: \\textbf{Primary: pipes-and-filters on HPC/batch infrastructure -- central trade-off: elastic scale-out vs. data affinity; in Amdahl's regime, consolidate, do not distribute}"
      ],
      "elements": [
        "7-row table condensed from tab:fit-c6 lines 325-339 (cells capped at two lines); one bold line from line 344"
      ],
      "minutes": 3,
      "notes": "Second near-single-pattern row (with C4). Prime Video appears twice in this row -- the evolution episode of frame 4 read as a matrix cell. Secondary (SL fan-out) and the measures (cost per simulation, communication share of runtime) on frame 39."
    },
    {
      "no": 33,
      "deck_section": "The Ten Rows in Detail",
      "title": "C7 -- BI analytics: a pipeline feeding a serving tier",
      "kind": "table",
      "script_ref": "§33.7 Table tab:fit-c7 and verdict (part4_fit.tex 347-374)",
      "content": [
        "L $+$: the serving tier is honestly a thin layered application delegating heavy reads to the warehouse -- Metabase ships as one JAR for exactly this reason",
        "MM $+$: the same fit with cleaner seams between semantic model, query, and visualisation concerns as the tool estate grows",
        "HX $\\circ$: adapter isolation of warehouse dialects helps tool vendors more than in-house BI teams; the dominant contracts are data schemas, not code ports",
        "MS $-$: splitting a read-only analytical product into services adds network and platform cost against no High-weight dimension (veto D10: $--$ on High)",
        "EDA $\\circ$: streaming ingestion earns its broker-operations complexity only when the freshness contract measurably tightens below the batch window",
        "PF {\\boldmath$++$}: the modern data stack \\emph{is} an ELT pipeline -- sources $\\to$ DAGs $\\to$ warehouse $\\to$ serving -- with lineage and refresh contracts as audit artefacts (D1 delegated to the output store)",
        "SL $+$: scheduled, spiky transformation jobs fit pay-per-run functions (the $++$ side of the split D10 rating), though warehouse-native scheduling often does the same more cheaply",
        "One bold line: \\textbf{Primary: pipes-and-filters (ELT) feeding a layered serving tier -- central trade-off: data freshness vs. cost and simplicity; the ADR to write is the freshness contract}"
      ],
      "elements": [
        "7-row table condensed from tab:fit-c7 lines 354-368 (cells capped at two lines); one bold line from line 373"
      ],
      "minutes": 3,
      "notes": "Bridge to C8: tightening freshness towards real time drags the class into C8 economics (line 373) -- say it orally. Secondary (EDA ingestion where freshness SLAs demand it), the third consistency semantics and the fitness functions (refresh-window adherence, p95 dashboard latency) on frame 39."
    },
    {
      "no": 34,
      "deck_section": "The Ten Rows in Detail",
      "title": "C8 -- real-time streaming: a log with stream processors",
      "kind": "table",
      "script_ref": "§33.8 Table tab:fit-c8 and verdict (part4_fit.tex 376-403)",
      "content": [
        "L $--$: shape gate plus veto D2 -- a synchronous request/response monolith cannot sustain continuous ingest at the world's production rate with backpressure",
        "MM $-$: modularity helps the codebase, but the single quantum caps sustained ingest and fault isolation (veto D2, D5) and cannot provide the durable, partitioned, replayable transport the class is defined by",
        "HX $\\circ$: ports isolate processing logic from broker APIs (easing Kafka-to-Pulsar-style migrations); the binding constraints are throughput semantics, not dependency direction",
        "MS $+$: stream processors deploy naturally as long-running services aligned with the dataflow (D3 kept out of a request/response path) -- provided boundaries follow the flow, where Segment's cut failed",
        "EDA {\\boldmath$++$}: a durable, partitioned, replayable log with decoupled producers and consumers is the class's defining structure -- Kafka's origin story",
        "PF $+$: stream processing is pipes-and-filters over a log -- the batch form's latency veto ($--$ on High-weighted D3) is lifted by its documented streaming incarnation with exactly-once checkpointing",
        "SL $-$: per-event invocation at sustained millions of events per second is dominated economically ($--$ side of the split D10) and latency-wise (cold starts, veto D3) by long-running stream processors",
        "One bold line: \\textbf{Primary: EDA (log-centric broker topology) with streaming pipes-and-filters as the processing layer -- Kafka + Flink + OLAP serving, the Uber stack -- central trade-off: delivery semantics vs. operational complexity and cost}"
      ],
      "elements": [
        "7-row table condensed from tab:fit-c8 lines 383-397 (cells capped at two lines); one bold line from line 402"
      ],
      "minutes": 3,
      "notes": "Segment reappears (MS cell) -- the evolution episode of frame 4 read as a boundary rule. The at-least-once-plus-idempotence norm and the contract (consumer lag, watermark delay, duplicate rate under chaos) on frame 39."
    },
    {
      "no": 35,
      "deck_section": "The Ten Rows in Detail",
      "title": "C9 -- collaboration / messaging: a monolithic core with a specialised push layer",
      "kind": "table",
      "script_ref": "§33.9 Table tab:fit-c9 and verdict (part4_fit.tex 405-432)",
      "content": [
        "L $\\circ$: fine for small installations, but millions of long-lived stateful connections are a resource profile the pattern never modelled (cap via D5)",
        "MM $+$: no veto beyond D5 (mitigation: replicated instances); the single-binary-by-design fit is the Mattermost case",
        "HX $\\circ$: helps swap storage and push providers (Discord's MongoDB $\\to$ Cassandra $\\to$ ScyllaDB path); the crux -- connection fan-out -- is orthogonal to dependency direction",
        "MS $+$: Discord's per-attribute specialisation (BEAM gateways, Rust data services) shows targeted services exactly where tail latency demands them (veto D3; mitigation: specialised low-latency services)",
        "EDA {\\boldmath$++$}: gate passed on the push path -- the class's binding fan-out delivery scenario; no veto on the High set; the pattern--domain coincidence Part III records for the push layer",
        "PF $-$: shape gate plus veto D3 ($--$ on High) -- interactive bidirectional message flows are the opposite of unidirectional batch transformation (history exports aside)",
        "SL $--$: structural knock-out -- long-lived WebSocket connection state is the canonical anti-case for short-lived stateless functions",
        "One bold line: \\textbf{Primary: monolithic persistence and business core with a specialised event-driven push layer (Slack: PHP/Hack core plus the Flannel edge cache) -- central trade-off: real-time fan-out at global scale vs. deployability and simplicity}"
      ],
      "elements": [
        "7-row table condensed from tab:fit-c9 lines 412-426 (cells capped at two lines); one bold line from line 431"
      ],
      "minutes": 3,
      "notes": "Last of the C1-C9 rows; keep pace -- three minutes. Secondary (MM alone for self-hosted), the connection-count tiebreaker and the Mattermost/Discord span on frame 39."
    },
    {
      "no": 36,
      "deck_section": "The Ten Rows in Detail",
      "title": "C10 -- your class: the row extended to all seven candidates",
      "kind": "table",
      "script_ref": "§33.10 Table tab:fit-c10 (part4_fit.tex 434-448)",
      "content": [
        "Leading line (\\footnotesize): the mini-match of week 3 computed L, MM, MS against the five High weights; the table extends the row to all seven candidates",
        "L $-$: technical layers give the non-deterministic component no boundary, no queue, no measurement point -- the three things it needs most (veto D7; $-$ on High-weighted D9)",
        "MM {\\boldmath$++$}: a domain-cut monolith hosts the deterministic services (data access, computation, audit) cheaply and gives the AI subsystem a hard, CI-verifiable module boundary (D5 $-$ Medium-weight, mitigated by replication)",
        "HX {\\boldmath$++$}: the LLM is an adapter on a port -- swappable on provider deprecation, mockable in tests, guarded by contract validation: the anti-corruption layer for a component that would otherwise corrupt the domain",
        "MS $\\circ$: blast-radius control is welcome, but synchronous service chains multiply seconds-scale LLM latency and failure rates; the D10 veto targets per-request AI cost (a gateway concern), so $--$ relaxes to $\\circ$",
        "EDA $+$: queues absorb LLM latency, rate limits, and outages and create batching points for cost control -- the default for non-interactive AI work (veto D9; mitigation: the eval harness as correctness instrument)",
        "PF $+$: ingestion $\\to$ chunking $\\to$ embedding $\\to$ index, and the eval harness itself, are pipelines with versioned data contracts; $+$ not $++$: the interactive advisory surface is not a pipeline (Medium D3)",
        "SL $\\circ$: event-glue around batch APIs fits (spiky advisory load hits the $++$ side of the split D10); platform timeouts against minutes-long LLM/solver runs and opaque per-call cost stacking do not"
      ],
      "elements": [
        "7-row table condensed from tab:fit-c10 lines 441-448 (\\scriptsize, every cell capped at two lines); leading line from line 434 without the operand parenthetical (the operands are deck 6's requirements profile)"
      ],
      "minutes": 4,
      "notes": "Give this row the most time: it is the row students' A2 was computed on. Verdict on the next frame."
    },
    {
      "no": 37,
      "deck_section": "The Ten Rows in Detail",
      "title": "C10 -- the verdict: a designed hybrid, and the determinism boundary",
      "kind": "keyconcept",
      "script_ref": "§33.10 verdict (part4_fit.tex 450)",
      "content": [
        "\\textbf{Primary recommendation:} a hexagonal modular monolith -- deterministic core, AI adapters at ports, an LLM gateway as the single measurement point -- plus pipes-and-filters for ingestion and evals and an orchestrated agent workflow for the AI layer",
        "\\textbf{This is a \\emph{designed hybrid}, and saying so explicitly is part of the theory}",
        "\\textbf{Secondary:} EDA for the AI job and audit spine",
        "\\textbf{Central trade-off: agent autonomy and capability vs. cost, latency, and testability} -- governed by a token-cost budget and a p95 latency budget per use case as CI-gated fitness functions (§37), and by the determinism boundary",
        "\\textbf{The determinism boundary: LLM agents propose; deterministic services decide and book} (Part V)",
        "projektbox: ADR-007's decision section is this verdict in one paragraph; this week's M4 work builds the part that \\emph{decides and books} -- the Performance, Risk, Optimization services -- and pins it with exact tests before any agent output is trusted"
      ],
      "elements": [
        "keypoint box with the primary recommendation and determinism boundary (line 450); projektbox linking to M4 (exercise sheet M4 taskbox and hint 'pin the deterministic services with tests before you trust any agent output')"
      ],
      "minutes": 3,
      "notes": "The projektbox uses the exercise sheet's M4 wording and hint box only."
    },
    {
      "no": 38,
      "deck_section": "The Ten Rows in Detail",
      "title": "Ten rows, ten trade-offs (1/2): C1--C5",
      "kind": "table",
      "script_ref": "§33.1-33.5 verdict paragraphs (part4_fit.tex 199, 228, 257, 286, 315)",
      "content": [
        "Header: Class | Primary (secondary) | Central trade-off | Deciding measurement",
        "C1: HX-MM core (EDA edges, PF batch; MS at the Monzo condition) | consistency vs. scalability | reconciliation fitness functions at the consistency boundary",
        "C2: EDA + MS hybrid (MM until scale is measured -- Mastodon) | read scalability, team scaling vs. simplicity, cost | deployments per developer per day as teams multiply",
        "C3: MM + workflow engine behind a port (L for small, stable scope) | day-one simplicity vs. multi-decade evolvability | change dispersion per process change",
        "C4: MM (HX inside for extensions; L only for very small scope) | integrated data model vs. independent module scaling and deployment | a resolution, not a metric: module boundaries inside one transactional quantum",
        "C5: MM, hybrid consistency inside + EDA edges (MS at organisational scale) | seasonal elasticity vs. checkout consistency | p95 checkout latency; zero uncompensated oversells at 10$\\times$ baseline"
      ],
      "elements": [
        "5-row, 4-column table (\\scriptsize, p{} widths approx. 0.8/4.0/3.2/3.8 cm, every cell one line) assembled from the five verdict paragraphs; secondary recommendations and deciding measurements live here only"
      ],
      "minutes": 3,
      "notes": "Synthesis table; the 'deciding measurement' column carries only what the verdict paragraph names (C4 names a resolution, not a measure -- quoted as such)."
    },
    {
      "no": 39,
      "deck_section": "The Ten Rows in Detail",
      "title": "Ten rows, ten trade-offs (2/2): C6--C10",
      "kind": "table",
      "script_ref": "§33.6-33.10 verdict paragraphs (part4_fit.tex 344, 373, 402, 431, 450)",
      "content": [
        "C6: PF on HPC/batch (SL fan-out for communication-light bursts) | elastic scale-out vs. data affinity | cost per simulation; communication share of runtime",
        "C7: PF (ELT) + layered serving tier (EDA ingestion where freshness demands) | data freshness vs. cost and simplicity | refresh-window adherence; p95 dashboard latency",
        "C8: EDA log + streaming PF (MS processors where ownership demands) | delivery semantics vs. operational complexity, cost | consumer lag, watermark delay, duplicate rate under chaos",
        "C9: monolithic core + EDA push layer (MM alone for self-hosted) | global real-time fan-out vs. deployability, simplicity | concurrent connections (push layer premature below $\\sim 10^5$)",
        "C10: HX-MM core + PF + orchestrated agents (EDA job/audit spine) | agent autonomy vs. cost, latency, testability | token-cost and p95 latency budgets per use case, CI-gated"
      ],
      "elements": [
        "5-row, 4-column table (\\scriptsize, same widths as frame 38, every cell one line) continued"
      ],
      "minutes": 3,
      "notes": "The closing keypoint moves to its own frame 40 so this table fits; C10 row abbreviated to one line per cell."
    },
    {
      "no": 40,
      "deck_section": "The Ten Rows in Detail",
      "title": "The recurring resolution: consistent core, asynchronous edges",
      "kind": "keyconcept",
      "script_ref": "§33 closing keypoint (part4_fit.tex 452-454)",
      "content": [
        "keypoint: Every cell of the ten rows is traceable to the same mechanics -- $R(a)$ against $C(p)$, a \\textbf{veto} where a High weight meets a deep deficit, and a \\textbf{documented mitigation} wherever a cap was lifted",
        "The recurring resolution across the rows is \\textbf{consistent core, asynchronous edges} -- hybrids arise by \\emph{placing} patterns in different subsystems, never by averaging their scores",
        "Loop closed: eight of ten primary recommendations are compositions (frame 5); the unit of evaluation is the subsystem with its own quantum; the composition is recorded in the C4 container diagram"
      ],
      "elements": [
        "keypoint box from lines 452-454; one closing bullet back to frame 5"
      ],
      "minutes": 3,
      "notes": "Close the loop with frame 5 (eight of ten are compositions; placing, not averaging)."
    },
    {
      "no": 41,
      "deck_section": "Closing",
      "title": "This week's exercise: the deterministic core (M4)",
      "kind": "exercise",
      "script_ref": "project_exercise.tex M4 taskbox and hint box (lines 424-429, 448-461); semester plan week 10",
      "content": [
        "projektbox: Milestone \\textbf{M4 -- Deterministic Core and Resilience} (weeks 10--11) begins; the exercise slot is coaching (1 lesson)",
        "1. Implement the \\texttt{Performance}, \\texttt{Risk}, and \\texttt{Optimization} services and test them \\textbf{fully against the reference vectors} -- exact tests, not approximate ones",
        "2. Pin the deterministic services with tests \\emph{before} you trust any agent output",
        "3. Keep the deterministic core \\textbf{free of LLM calls} -- this is the line that is graded (ADR-007's determinism boundary: agents propose, deterministic services decide and book)",
        "4. Commit after the milestone; record architectural decisions as ADRs as you go -- a revised decision is a new, superseding ADR",
        "Next week completes M4: resilience on all external calls and graceful degradation verified"
      ],
      "elements": [
        "projektbox with numbered list, as in deck 6"
      ],
      "minutes": 0,
      "notes": "Wording taken from the M4 taskbox and the hint box of the exercise sheet; the ADR-007 link is from the script listing."
    },
    {
      "no": 42,
      "deck_section": "Closing",
      "title": "Summary",
      "kind": "summary",
      "script_ref": "§35, §36, §33",
      "content": [
        "1. \\textbf{Hybrids are the normal case}: eight of ten primary recommendations are compositions; the unit of fit evaluation is the subsystem with its own quantum -- recorded as a C4 container diagram",
        "2. \\textbf{Fit is a function of time} (Lehman, A5): MonolithFirst, Strangler Fig in both directions, sacrificial architecture -- MM is start state and consolidation target",
        "3. \\textbf{Maxim 5}: choose for the profile you can verify today; buy options on tomorrow's via modules, ports, a strangler-ready seam -- not via speculative distribution",
        "4. \\textbf{Eight steps}: ASRs $\\to$ scenarios with numbers $\\to$ utility tree $\\to$ matrix shortlist $\\to$ ATAM-light $\\to$ ADR $\\to$ measurement contract $\\to$ measure and keep paths open; (vii)--(viii) are the new obligations",
        "5. \\textbf{Maxim 6}: without a response measure a decision is an opinion; with a response measure and a fitness function it is a testable hypothesis",
        "6. \\textbf{ADR-007}: one matrix row narrated -- options carry the matrix reasoning (auditable), the final section carries the contract (falsifiable)",
        "7. \\textbf{The ten rows}: every cell traceable to $R(a)$ against $C(p)$, veto and documented mitigation; the recurring resolution is \\emph{consistent core, asynchronous edges}"
      ],
      "elements": [
        "numbered list \\footnotesize, every item at most two lines"
      ],
      "minutes": 0,
      "notes": "Seven points; no extra keypoint needed."
    },
    {
      "no": 43,
      "deck_section": "Closing",
      "title": "Next week",
      "kind": "nextweek",
      "script_ref": "semester plan week 11; task brief 'Next lecture'",
      "content": [
        "Left column, Lecture 11 -- Part IV closes: the measurement contract in depth: fitness-function taxonomy in CI/CD; the four DORA metrics and the coupling finding; the four-layer cascade; the cost of change -- Boehm vs. Menzies; Conway's law and Team Topologies as the third fit dimension; limits of the theory applied to itself",
        "Right column, Reading: this week -- Part IV, Sections 35--36 and 33; ahead -- Part IV, Sections 37--39",
        "Right column, Exercise / deliverable: coaching; resilience on all external calls (timeout, retry, circuit breaker, fallback); graceful degradation; milestone: deterministic core fully tested and resilient (M4 complete)"
      ],
      "elements": [
        "two-column layout as in deck 6"
      ],
      "minutes": 0,
      "notes": "Verbatim in substance from the 'Next lecture' line of the brief and semester plan week 11."
    },
    {
      "no": 44,
      "deck_section": "Closing",
      "title": "Closing slide",
      "kind": "content",
      "script_ref": "deck skeleton",
      "content": [
        "\\FHGRClosingPage: Thank you! -- Dr. Florian Herzog -- Fachhochschule Graub\\\"unden, Chur -- AISE502 -- AI in Software Engineering II"
      ],
      "elements": [
        "FHGR closing page as in decks 1-6"
      ],
      "minutes": 0,
      "notes": "Identical to deck 6 (Graub\\\"unden with the umlaut macro)."
    }
  ],
  "exercise_frame": {
    "title": "This week's exercise: the deterministic core (M4)",
    "content": [
      "projektbox: Milestone M4 -- Deterministic Core and Resilience (weeks 10--11) begins; the exercise slot is coaching (1 lesson)",
      "Implement the Performance, Risk, and Optimization services and test them fully against the reference vectors -- exact tests",
      "Pin the deterministic services with tests before you trust any agent output",
      "Keep the deterministic core free of LLM calls -- the line that is graded (ADR-007's determinism boundary: agents propose, deterministic services decide and book)",
      "Commit after the milestone; record architectural decisions as ADRs as you go -- a revised decision is a new, superseding ADR",
      "Next week completes M4: resilience on all external calls and graceful degradation verified"
    ]
  },
  "summary": [
    "Hybrids are the normal case: eight of ten primary recommendations are compositions; the unit of fit evaluation is the subsystem with its own quantum -- recorded as a C4 container diagram",
    "Fit is a function of time (Lehman, A5): MonolithFirst, Strangler Fig in both directions, sacrificial architecture -- MM is start state and consolidation target",
    "Maxim 5: choose for the profile you can verify today; buy options on tomorrow's via modules, ports, a strangler-ready seam -- not via speculative distribution",
    "Eight steps: ASRs -> scenarios with numbers -> utility tree -> matrix shortlist -> ATAM-light -> ADR -> measurement contract -> measure and keep paths open; (vii)--(viii) are the new obligations",
    "Maxim 6: without a response measure a decision is an opinion; with a response measure and a fitness function it is a testable hypothesis",
    "ADR-007: one matrix row narrated -- options carry the matrix reasoning (auditable), the final section carries the contract (falsifiable)",
    "The ten rows: every cell traceable to R(a) against C(p), veto and documented mitigation; the recurring resolution is consistent core, asynchronous edges"
  ],
  "next_week": {
    "lecture_line": "Lecture 11 -- Part IV closes: the measurement contract in depth",
    "topics": [
      "fitness-function taxonomy in CI/CD",
      "the four DORA metrics and the coupling finding",
      "the four-layer cascade",
      "the cost of change: Boehm vs. Menzies",
      "Conway's law and Team Topologies as the third fit dimension",
      "limits of the theory applied to itself"
    ],
    "reading": [
      "this week: Part IV, Sections 35--36 and 33",
      "ahead: Part IV, Sections 37--39"
    ],
    "exercise": [
      "coaching; resilience on all external calls (timeout, retry, circuit breaker, fallback); graceful degradation",
      "milestone: deterministic core fully tested and resilient (M4 complete)"
    ]
  },
  "script_boxes_used": [
    {
      "box": "Figure fig:evolution (tikz state diagram of evolution paths)",
      "location": "§35.2, part4_fit.tex 514-540",
      "used_in_frame": "8 The documented evolution paths -- a state diagram"
    },
    {
      "box": "keypoint Maxim 5",
      "location": "§35.2, part4_fit.tex 542-544",
      "used_in_frame": "9 Maxim 5 -- buy options on tomorrow's profile"
    },
    {
      "box": "ailinse[Sacrificial architecture for AI-native components]",
      "location": "§35.2, part4_fit.tex 546-548",
      "used_in_frame": "10 AI Lens: sacrificial architecture for AI-native components"
    },
    {
      "box": "enumerate of the eight steps (i)-(viii)",
      "location": "§36, part4_fit.tex 556-567",
      "used_in_frame": "11-14 (overview table, (i)-(iii), (iv)-(v), (vi)-(viii))"
    },
    {
      "box": "keypoint Maxim 6 (restated)",
      "location": "§36, part4_fit.tex 571-573",
      "used_in_frame": "15 Note how much of this you have already done -- and Maxim 6"
    },
    {
      "box": "examplebox[Decision run for the Portfolio Intelligence Platform (class C10) -- steps (i)-(iv)]",
      "location": "§36.1, part4_fit.tex 578-586",
      "used_in_frame": "16, 17, 18 (reference run steps (i), (ii), (iii)-(iv))"
    },
    {
      "box": "examplebox[Decision run ... -- steps (v)-(viii)]",
      "location": "§36.1, part4_fit.tex 588-596",
      "used_in_frame": "19, 20 (reference run steps (v), (vi)-(viii))"
    },
    {
      "box": "Listing lst:adr007 (ADR-007 MADR record)",
      "location": "§36.1, part4_fit.tex 600-648",
      "used_in_frame": "21 ADR-007 (1/3), 22 ADR-007 (2/3), 23 ADR-007 (3/3)"
    },
    {
      "box": "Table tab:fitmatrix (the 7x10 grid)",
      "location": "§32, part4_fit.tex 127-152",
      "used_in_frame": "26 The 7x10 grid, for reference (plus the C10 row strip on frame 18)"
    },
    {
      "box": "keypoint 'Read a matrix cell as the answer to one question only'",
      "location": "§32, part4_fit.tex 163-165",
      "used_in_frame": "25 How to read a row rationale (condensed reminder bullet)"
    },
    {
      "box": "Table tab:fit-c1",
      "location": "§33.1, part4_fit.tex 175-197",
      "used_in_frame": "27 C1 -- core banking"
    },
    {
      "box": "Table tab:fit-c2",
      "location": "§33.2, part4_fit.tex 204-226",
      "used_in_frame": "28 C2 -- social media / content platform"
    },
    {
      "box": "Table tab:fit-c3",
      "location": "§33.3, part4_fit.tex 233-255",
      "used_in_frame": "29 C3 -- back-office / workflow"
    },
    {
      "box": "Table tab:fit-c4",
      "location": "§33.4, part4_fit.tex 262-284",
      "used_in_frame": "30 C4 -- ERP core"
    },
    {
      "box": "Table tab:fit-c5",
      "location": "§33.5, part4_fit.tex 291-313",
      "used_in_frame": "31 C5 -- e-commerce"
    },
    {
      "box": "Table tab:fit-c6",
      "location": "§33.6, part4_fit.tex 320-342",
      "used_in_frame": "32 C6 -- simulation / batch compute"
    },
    {
      "box": "Table tab:fit-c7",
      "location": "§33.7, part4_fit.tex 349-371",
      "used_in_frame": "33 C7 -- BI analytics"
    },
    {
      "box": "Table tab:fit-c8",
      "location": "§33.8, part4_fit.tex 378-400",
      "used_in_frame": "34 C8 -- real-time streaming"
    },
    {
      "box": "Table tab:fit-c9",
      "location": "§33.9, part4_fit.tex 407-429",
      "used_in_frame": "35 C9 -- collaboration / messaging"
    },
    {
      "box": "Table tab:fit-c10",
      "location": "§33.10, part4_fit.tex 436-448",
      "used_in_frame": "36 C10 -- the row extended to all seven candidates"
    },
    {
      "box": "keypoint 'Every cell of the ten rows is traceable to the same mechanics ... consistent core, asynchronous edges'",
      "location": "§33 closing, part4_fit.tex 452-454",
      "used_in_frame": "40 The recurring resolution: consistent core, asynchronous edges"
    },
    {
      "box": "verdict paragraphs (primary / secondary / central trade-off) for C1-C10",
      "location": "§33, part4_fit.tex 199, 228, 257, 286, 315, 344, 373, 402, 431, 450",
      "used_in_frame": "27-35 (one bold primary/trade-off line per class), 37 (C10 verdict), 38-39 (ten trade-offs tables: secondary and deciding measurement)"
    },
    {
      "box": "closing paragraph of §36.1 (two properties that make ADR-007 more than paperwork; ADR-011)",
      "location": "§36.1, part4_fit.tex 598",
      "used_in_frame": "20 The reference run -- steps (vi)-(viii) (last bullet)"
    }
  ],
  "script_boxes_dropped": [
    {
      "box": "definitionbox[Cell semantics of the matching matrix]",
      "location": "§32, part4_fit.tex 121-123",
      "reason": "Taught in Lecture 7 (deck 7, cell semantics); its one-sentence consequence is repeated as a Lecture-7 reminder on frames 5 and 25."
    },
    {
      "box": "footnote paragraph under tab:fitmatrix (HX never negative, pattern abbreviations)",
      "location": "§32, part4_fit.tex 154-157",
      "reason": "Condensed to a single footnote line on the reference grid frame 26; the full argument was taught in Lecture 7."
    },
    {
      "box": "thinkbox on the C5 row (3 vs 30 teams, 1x vs 50x traffic)",
      "location": "§34, part4_fit.tex 484-486",
      "reason": "Belongs to §34 (Lecture 7); not reused here unless deck 7 turns out not to have used it -- see open_issues."
    }
  ],
  "open_issues": [
    "The script has no thinkbox in §33, §35 or §36. The single Discussion frame (24) uses four deck-authored questions derived strictly from ADR-007 and the eight steps, asking students to compare their own A2; they introduce no new claims, but the author should confirm this is acceptable. Alternative: the script's only thinkbox in this range (§34, part4_fit.tex 484-486: the C5 row under 3 vs 30 teams and 1x vs 50x traffic) fits after the C5 row frame if deck 7 did not already use it.",
    "Decks 7, 8 and 9 do not yet exist as files; the recap (frame 3) is built from deck 6's next-week frame, the semester plan rows for weeks 7-9 and the milestone table. Verify the recap wording against the actual decks 7-9 once typeset.",
    "Density in the row frames 27-36: every rationale cell is capped at two lines (about 180 characters at \\scriptsize, rationale column about 8.6 cm, arraystretch 0.85) and the verdict prose is removed -- one bold \\footnotesize line 'Primary: ... -- central trade-off: ...' remains under the table; secondary recommendations and deciding measurements live only on frames 38-39. If any frame still overflows into the footer, split it into 'C<k> -- row' and 'C<k> -- verdict' (up to 46 frames, the upper limit).",
    "The ADR-007 listing is split over three frames (21-23, about 12/11/14 monospace lines at \\scriptsize\\ttfamily with blank lines removed) in the tcolorbox style of deck 3's ADR-011 frame, each with a narrow step-tag column. If frame 23 is still tight, render the seven contract lines as a \\footnotesize itemize below the box as in deck 3's 'Confirmation' list.",
    "Step (vii) and the ADR-007 example reference Table tab:contract (the fitness-function table of §37), which is next week's material. The deck names only the six fitness-function families listed in the examplebox and the seven contract lines of the listing; it does not reproduce tab:contract.",
    "The evolution-path figure (frame 8) has node coordinates spanning 16 cm horizontally with two rows; for 16:9 it should be redrawn with compressed spacing and a \\resizebox; all six labelled transitions (including the dashed 'sacrificial rebuild' arc L to MM and the curved 'consolidation (Segment 2018)' back-arrow) must survive. The transitions are edge labels only; the sole text under the figure is the caption's last sentence.",
    "Deck-authored condensations and links, none stated in the script: the keypoint on frame 5 (unit of fit evaluation, line 498); the Step | Artefact table on frame 11 (assembled from the step texts); the 'MonolithFirst = Lecture 7 unfashionable default' label on frame 6 (§34 line 466); the oral question on frame 20 whether the step-(v) job-spine risk reappears as the step-(viii) EDA-spine path. The deck's former expansion of 'SEI method family' into ATAM/QAW/CBAM was dropped -- the script's intro names no methods.",
    "The C10 row strip on frame 18 is transcribed from tab:fitmatrix line 150 and must be kept in sync with tab:fit-c10 (they agree in the current script). The row frames carry no strips; the tables' Fit column shows the row.",
    "The synthesis tables (frames 38-39) carry a 'deciding measurement' column; for C4 the verdict paragraph names a resolution ('module boundaries inside one transactional quantum'), not a measurement -- it is quoted as such rather than inventing a metric.",
    "Minutes recomputed from the per-frame values: recap 3; §35 frames 4-10 = 24; §36 frames 11-15 = 16; ADR-007 frames 16-24 = 31 (including the 6-minute discussion); §33 frames 25-40 = 49; total 123 content minutes, leaving about 12 minutes for title, agenda, exercise, summary, next week and questions in three lessons (135 min). Total frames 44, within the 40-46 target."
  ],
  "total_frames": 44
}