From 6dd749e95809559de3d9438581864efc58b043df Mon Sep 17 00:00:00 2001 From: herzogflorian Date: Mon, 7 Sep 2026 14:38:39 +0200 Subject: [PATCH] Auto-commit 2026-09-07 14:38: 9 files changed, 12968 insertions(+) --- Folien/Planung_7-13_json/L10.json | 1079 ++++ Folien/Planung_7-13_json/L11.json | 894 +++ Folien/Planung_7-13_json/L12.json | 994 +++ Folien/Planung_7-13_json/L13.json | 937 +++ Folien/Planung_7-13_json/L7.json | 751 +++ Folien/Planung_7-13_json/L8.json | 1110 ++++ Folien/Planung_7-13_json/L9.json | 1030 ++++ Folien/Planung_7-13_json/coverage_table.json | 458 ++ Folien/Planung_Vorlesungen_7-13.md | 5715 ++++++++++++++++++ 9 files changed, 12968 insertions(+) create mode 100644 Folien/Planung_7-13_json/L10.json create mode 100644 Folien/Planung_7-13_json/L11.json create mode 100644 Folien/Planung_7-13_json/L12.json create mode 100644 Folien/Planung_7-13_json/L13.json create mode 100644 Folien/Planung_7-13_json/L7.json create mode 100644 Folien/Planung_7-13_json/L8.json create mode 100644 Folien/Planung_7-13_json/L9.json create mode 100644 Folien/Planung_7-13_json/coverage_table.json create mode 100644 Folien/Planung_Vorlesungen_7-13.md diff --git a/Folien/Planung_7-13_json/L10.json b/Folien/Planung_7-13_json/L10.json new file mode 100644 index 0000000..2587ffd --- /dev/null +++ b/Folien/Planung_7-13_json/L10.json @@ -0,0 +1,1079 @@ +{ + "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 -- row' and 'C -- 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 +} \ No newline at end of file diff --git a/Folien/Planung_7-13_json/L11.json b/Folien/Planung_7-13_json/L11.json new file mode 100644 index 0000000..3afa57a --- /dev/null +++ b/Folien/Planung_7-13_json/L11.json @@ -0,0 +1,894 @@ +{ + "lecture": 11, + "week": 11, + "lessons": 3, + "title": "Lecture 11: The Fit III -- The Measurement Contract, Conway's Law, and the Limits of the Theory", + "script_reference": "Script: Part IV, Sections 37--39", + "agenda": [ + "The measurement contract -- step (vii)", + "Fitness functions: taxonomy and three instrument families", + "DORA and the coupling finding", + "The four-layer cascade; the C10 reference contract", + "Cost of change: Boehm vs Menzies", + "AI Lens, both axes; the project's contract", + "Conway's law and Team Topologies", + "Limits of the theory; Maxim 9", + "This week's exercise: resilience complete" + ], + "recap": [ + "Part IV so far: L7 -- three cases, three stages, the procedure, the $7 \\times 10$ matrix, the contract introduced $\\mid$ L8--9 -- Part III, classes C1--C9 $\\mid$ L10 -- hybrids and evolution paths (Segment, Prime Video, Shopify), Maxim 5; the eight-step procedure with ADR-007, Maxim 6 (a response measure turns an opinion into a testable hypothesis); the ten matrix rows cell by cell -- recurring resolution: \\emph{consistent core, asynchronous edges}", + "Deck 1 (A5) and deck 2 (D9, D11) already named the four DORA metrics, the scaling finding, the \\emph{within}/\\emph{of} cost asymmetry and Conway's law -- today the instrument taxonomy, the numbers and the evidence behind them", + "The measurement contract is the \\textbf{fifth framework element}; ADR-011 (shown in lecture 3) already ended with an embryonic three-line contract -- its lines correspond to rows 2, 7 and 8 of today's reference contract, the static rule tightened from ``no provider-SDK import'' to ``gateway only via the declared port''", + "Deck 6: every cell is a \\textbf{default hypothesis}, replaced by measurement once the system exists -- today: how that measurement is organised (steps (vii)--(viii))", + "Deck 6: \\emph{Conway is a decision filter, not a footnote}, and the evidence base has honest gaps -- today \\S 38 makes the organisation the third party to the fit, \\S 39 turns the gaps into six limits the theory states about itself", + "Today closes Part IV; next week opens Part V" + ], + "frames": [ + { + "no": 1, + "deck_section": "Title", + "title": "AISE502: AI in Software Engineering II -- Lecture 11: The Fit III -- The Measurement Contract, Conway's Law, and the Limits of the Theory", + "kind": "content", + "script_ref": "title slide; subtitle line: Script: Part IV, Sections 37--39", + "content": [ + "\\FHGRTitlePage with \\subtitle{Lecture 11: The Fit III -- The Measurement Contract, Conway's Law, and the Limits of the Theory\\\\[0.4ex]{\\small Script: Part IV, Sections 37--39}}", + "author Dr. Florian Herzog; \\fullname{Fachhochschule Graub\\\"unden, Chur -- Autumn Semester 2026} unchanged from deck 6" + ], + "elements": [ + "title page macro as in deck 6 (line 117-127 of deck 6 for the subtitle/fullname form)" + ], + "minutes": 0, + "notes": "identical preamble and colour mapping to deck 6; subtitle follows the 'Lecture N: -- ' form of decks 4-6 (single colon)" + }, + { + "no": 2, + "deck_section": "Agenda", + "title": "Agenda", + "kind": "agenda", + "script_ref": "deck skeleton (decks 1-6)", + "content": [ + "1. \\textbf{The measurement contract} -- step (vii)", + "2. \\textbf{Fitness functions}: taxonomy and three instrument families", + "3. \\textbf{DORA} and the coupling finding", + "4. \\textbf{The four-layer cascade}; the C10 reference contract", + "5. \\textbf{Cost of change}: Boehm vs Menzies", + "6. \\textbf{AI Lens}, both axes; the project's contract", + "7. \\textbf{Conway's law} and Team Topologies", + "8. \\textbf{Limits of the theory}; Maxim 9", + "9. \\textbf{This week's exercise}: resilience complete" + ], + "elements": [ + "enumerate, \\small, itemsep 1pt, bold keyword per line as in deck 6" + ], + "minutes": 1 + }, + { + "no": 3, + "deck_section": "Recap", + "title": "Recap: where we are", + "kind": "recap", + "script_ref": "deck-10 summary frame (L10 plan frame 42, bullets 3, 5 and 7: Maxim 5; Maxim 6; the ten rows -- consistent core, asynchronous edges) and its Maxim-6 keyconcept frame 15 (part4_fit.tex 569-573); deck 6 (summary, 'Four reading rules', 'Reading the catalogue as a whole', 'The evidence base and its honest gaps'); deck 1 A5 frame (lines 555-558); deck 2 D9/D11 frames (lines 323-327, 355-362); deck 3 ADR-011 frame (lines 560-580); semester plan rows 7-10", + "content": [ + "Part IV so far: L7 -- three cases, three stages, the procedure, the $7 \\times 10$ matrix, the contract introduced $\\mid$ L8--9 -- Part III, classes C1--C9 $\\mid$ L10 -- hybrids and evolution paths (Segment, Prime Video, Shopify), Maxim 5; the eight-step procedure with ADR-007, Maxim 6 (a response measure turns an opinion into a testable hypothesis); the ten matrix rows cell by cell -- recurring resolution: \\emph{consistent core, asynchronous edges}", + "Deck 1 (A5) and deck 2 (D9, D11) already named the four DORA metrics, the scaling finding, the \\emph{within}/\\emph{of} cost asymmetry and Conway's law -- today the instrument taxonomy, the numbers and the evidence behind them", + "The measurement contract is the \\textbf{fifth framework element}; ADR-011 (shown in lecture 3) already ended with an embryonic three-line contract -- its lines correspond to rows 2, 7 and 8 of today's reference contract, the static rule tightened from ``no provider-SDK import'' to ``gateway only via the declared port''", + "Deck 6: every cell is a \\textbf{default hypothesis}, replaced by measurement once the system exists -- today: how that measurement is organised (steps (vii)--(viii))", + "Deck 6: \\emph{Conway is a decision filter, not a footnote}, and the evidence base has honest gaps -- today \\S 38 makes the organisation the third party to the fit, \\S 39 turns the gaps into six limits the theory states about itself", + "Today closes Part IV; next week opens Part V" + ], + "elements": [ + "bullets, \\footnotesize; bullet 1 typeset as three short sub-lines 'L7: ... | L8--9: ... | L10: ...' (as in decks 3 and 5); the L10 sub-line carries the three blocks of deck 10 separated by semicolons (hybrids/evolution + Maxim 5; procedure/ADR-007 + Maxim 6; the ten rows) and may run to two lines" + ], + "minutes": 3, + "notes": "one frame only; do not re-teach ADR-011 -- just name the three lines so the eight-row contract on frames 15-16 reads as its completion. The deck-1/deck-2 bullet is what lets frames 11, 18 and 23 carry recap tags. Bullet 1 now mirrors the deck-10 summary (all three blocks of deck 10, Maxims 5 and 6): Maxim 6 -- 'with a response measure and a fitness function it is a testable hypothesis' -- is the direct lead-in to \\S 37 and should be said aloud as the hand-over to frame 5 (step (vii))." + }, + { + "no": 4, + "deck_section": "The Measurement Contract", + "title": "How does a decision made this year stay honest in year five?", + "kind": "case", + "script_ref": "\\S 37 opening (part4_fit.tex 654-657)", + "content": [ + "\\emph{How does a decision made this year stay honest in year five?} (leading question, italic, bankblue -- above the box)", + "examplebox[Prime Video -- the trigger was a measurement]: What actually triggered the Prime Video re-architecture was \\textbf{not an architecture review but a telemetry signal}: infrastructure cost per stream, measured continuously, crossed what the team was willing to pay", + "(in the box) That measurement, not an opinion, first \\emph{forced} and then \\emph{vindicated} the redesign", + "(in the box) The cost dashboard was a \\textbf{fitness function in everything but name}: an objective, continuously evaluated check on an architectural characteristic whose breach converted a running structure from ``accepted'' into ``falsified''", + "(\\footnotesize text below the box) The empirical anchor for building such checks systematically is DORA: coupling -- this theory's leading dimension -- is a \\textbf{measurable} property; the finding itself: frame 11" + ], + "elements": [ + "examplebox[Prime Video -- the trigger was a measurement] holding bullets 2-4 (built from the running text of line 657 -- not a script box, see open_issues); leading question above, one \\footnotesize line below" + ], + "minutes": 4, + "notes": "Students met Prime Video in deck 6 (split D10 cell) and in lecture 10 (evolution path); the new angle here is only the trigger mechanism -- keep it short. The DORA quotation is deliberately withheld until frame 11." + }, + { + "no": 5, + "deck_section": "The Measurement Contract", + "title": "Step (vii): the fit becomes a measurement contract", + "kind": "content", + "script_ref": "\\S 37 opening (part4_fit.tex 659)", + "content": [ + "Step (vii) of the procedure generalises the Prime Video observation into a concept -- and it is where this course differs from a classical architecture lecture", + "The chosen fit is codified as a \\textbf{measurement contract}: the set of \\emph{executable invariants} under which the architecture is allowed to keep evolving", + "\\emph{``The architecture may change freely as long as the contract stays green''}", + "What today adds to the week-7 introduction: the instrument taxonomy (37.1), the delivery layer -- DORA (37.2), the four-layer cascade and the C10 reference contract (37.3), the economics -- cost of change (37.4)" + ], + "elements": [ + "keypoint-style highlighted quotation of the green-contract sentence (line 659)" + ], + "minutes": 3, + "notes": "bridge frame; the last bullet is the road map for the next 17 frames. Pick up Maxim 6 from recap bullet 1 verbally: the measurement contract is the set of fitness functions that makes the decision of step (vi) a testable hypothesis -- the recap already named it, this frame gives it its name" + }, + { + "no": 6, + "deck_section": "The Measurement Contract", + "title": "Architectural fitness function -- the definition", + "kind": "definition", + "script_ref": "\\S 37.1 definitionbox (part4_fit.tex 663-665)", + "content": [ + "definitionbox[Architectural fitness function] (condensed to the first two sentences): An architectural fitness function is ``any mechanism that provides an objective integrity assessment of some architectural characteristic''. Fitness functions turn quality attributes into \\textbf{executable, objective checks} and thereby move architecture governance from review meetings into the CI/CD pipeline", + "Classified along two primary dimensions -- \\textbf{scope} and \\textbf{cadence} (mini table below the box):", + "Scope | \\emph{atomic}: one characteristic in isolation, e.g. a dependency rule as a unit test | \\emph{holistic}: combined characteristics in interplay, e.g. security and data freshness under load", + "Cadence | \\emph{triggered}: event-based, on every build or deployment | \\emph{continual}: running permanently in operation, e.g. chaos experiments | \\emph{temporal}: time-scheduled, e.g. dependency-freshness time bombs" + ], + "elements": [ + "definitionbox[Architectural fitness function], first two sentences of lines 663-665, \\footnotesize", + "footnotesize 2-row mini table Scope: atomic | holistic; Cadence: triggered | continual | temporal, each cell with the script's own example (line 665); booktabs, no vertical rules" + ], + "minutes": 5, + "notes": "Replaces the former scope x cadence instrument table: the script classifies scope only for three examples, so the taxonomy is shown once here with the script's examples and not re-applied to instruments it does not classify. Say verbally that the same instrument can run at two cadences -- the latency row of the C10 contract (frame 15) is triggered + continual." + }, + { + "no": 7, + "deck_section": "The Measurement Contract", + "title": "Instrument family 1: dependency checks as CI gates", + "kind": "content", + "script_ref": "\\S 37.1 item 1 (part4_fit.tex 670)", + "content": [ + "ArchUnit (Java); analogues: NetArchTest (.NET), dependency-cruiser (JavaScript), import-linter (Python)", + "Rules formulated as \\textbf{unit tests that fail the build on violation}: ``the domain layer imports no framework''; ``no cycles between modules''; ``repositories are called only by services''", + "Spring Modulith verification does the same for module boundaries \\emph{declared} in a modular monolith", + "Classification: \\textbf{atomic, triggered}", + "For the matrix: this is what makes the MM ratings of the capability table \\textbf{enforceable rather than aspirational}", + "(recap, deck 4) without automated boundary verification, \\emph{boundary erosion} is the documented failure mode of the pattern -- ``the first fitness function most teams ever write''" + ], + "elements": [ + "three rules as a small grey tcolorbox in \\ttfamily (rendering of the quoted rules, line 670)" + ], + "minutes": 4, + "notes": "project item (1) of the projektbox is exactly this family -- say so, show it on frame 22. New here: the classification, the tool analogues per language, and the 'enforceable rather than aspirational' link to the MM column; boundary erosion and 'first fitness function' were taught in deck 4 (lines 505, 523)." + }, + { + "no": 8, + "deck_section": "The Measurement Contract", + "title": "Instrument family 2: performance and cost budgets as pipeline gates", + "kind": "content", + "script_ref": "\\S 37.1 item 2 (part4_fit.tex 671); thresholds from tab:contract (707-726)", + "content": [ + "Latency thresholds, bundle sizes, or Lighthouse scores are declared in a \\textbf{budget file} and gate the pipeline (Lighthouse CI)", + "The transfer to Axis B is direct: \\textbf{token-cost budgets} and \\textbf{p95 latency budgets} per AI use case are the same mechanism with new units", + "In the C10 reference contract the units read: advisory answer p95 $< 20$\\,s end-to-end (triggered $+$ continual); token cost $\\leq$ budget, e.g. CHF~0.40/request at p95 (continual)" + ], + "elements": [ + "two-column layout: classical budgets (left) vs Axis-B budgets (right), same mechanism arrow between them" + ], + "minutes": 3, + "notes": "'Lighthouse CI' is the bib-entry name (google2024lighthouseci) -- keep to that, add no page numbers or further tool names" + }, + { + "no": 9, + "deck_section": "The Measurement Contract", + "title": "Instrument family 3: chaos experiments as continual holistic fitness functions", + "kind": "content", + "script_ref": "\\S 37.1 item 3 (part4_fit.tex 672)", + "content": [ + "Netflix's \\textbf{Chaos Monkey} terminates production instances to test resilience assumptions \\emph{permanently}", + "Formalised as the \\emph{principles of chaos engineering}; cited by Ford et al. as the paradigm of a \\textbf{continual, holistic} fitness function", + "(recap, deck 2 D5) for the matrix: chaos experiments are the instrument that \\textbf{verifies the D5 cells}", + "\\emph{``A claimed blast radius is a hypothesis until an instance has actually been killed under load''}", + "In the C10 contract: kill one instance/broker under load -- SLO holds; blast radius $\\leq$ declared" + ], + "elements": [ + "highlighted quotation (line 672)" + ], + "minutes": 4, + "notes": "Chaos experiments as the D5 response-measure instrument were taught in deck 2 (D5 frame, lines 265 and 627) -- the new content is the classification and the quotation. Bridge to this week's project work (resilience on all external calls, graceful degradation): the resilience row is the fitness function that would verify it -- mention verbally, the exercise frame carries it." + }, + { + "no": 10, + "deck_section": "The Measurement Contract", + "title": "DORA metrics: the delivery layer", + "kind": "content", + "script_ref": "\\S 37.2 (part4_fit.tex 677); tab:contract row 'Delivery performance' (707-726); tab:cascade row 'Delivery' (695)", + "content": [ + "The four DORA metrics measure whether the \\textbf{delivery-relevant promises} of a structure are being kept", + "Tempo: \\textbf{deployment frequency}; \\textbf{lead time for changes}", + "Stability: \\textbf{change failure rate}; \\textbf{failed-deployment recovery time}", + "The central empirical finding: elite performers lead on \\emph{all four} -- tempo and stability are \\textbf{not a trade-off}", + "In the contract: DORA four keys per deployable unit (tab:cascade: per architecture quantum); example thresholds: change failure rate $< 15\\,\\%$, restore $< 1$ day; cadence continual" + ], + "elements": [ + "2 x 2 mini table Tempo | Stability with the four metrics (from line 677)" + ], + "minutes": 4 + }, + { + "no": 11, + "deck_section": "The Measurement Contract", + "title": "The coupling finding -- the strongest single result in the field", + "kind": "content", + "script_ref": "\\S 37.2 (part4_fit.tex 677)", + "content": [ + "(recap tag, one line at the top) deck 2, D9 and D11 already named these -- today the evidence behind them", + "\\emph{``Loosely coupled architectures and teams are the strongest predictor of continuous delivery''} -- supports coupling as the \\textbf{leading dimension of this entire theory}", + "(recap, deck 2 D9) 2017 analysis: the architecture characteristics \\textbf{testability and deployability} contributed more to continuous delivery than test and deployment automation itself", + "Follow-on finding 1: high performance is possible with \\emph{all kinds of systems -- including mainframes} -- provided systems and teams are loosely coupled; the label ``microservices'' is \\textbf{neither necessary nor sufficient}", + "Follow-on finding 2 (recap, deck 2 D11 / deck 5): as team count grows, deployments per developer per day \\textbf{rise} for high performers and \\textbf{fall} for low performers" + ], + "elements": [ + "the quotation set as a highlighted line; two follow-on findings as numbered items; recap tag as a \\footnotesize grey line above" + ], + "minutes": 4, + "notes": "This is the semester plan's 'Kopplungs-Befund'. Genuinely new on this frame: the verbatim quotation, the mainframe clause and the 'neither necessary nor sufficient' verdict. Connect back to deck 6 D11 row and forward to \\S 38 (frame 27) where the same finding returns as a Conway statement" + }, + { + "no": 12, + "deck_section": "The Measurement Contract", + "title": "Honesty requires the caveat: prediction, not proof", + "kind": "content", + "script_ref": "\\S 37.2 (part4_fit.tex 679)", + "content": [ + "DORA's evidence is \\textbf{survey-based} and analysed with structural equation models -- \\emph{prediction, not experimental causal proof}", + "The theory treats it as the \\textbf{best available large-$n$ evidence}", + "To be \\emph{triangulated} against case studies and the reader's own measurements", + "Not settled law -- the caveat returns in \\S 39 as limit 4" + ], + "elements": [ + "hinweisbox built from the running text of line 679 (not a script box, see open_issues)" + ], + "minutes": 2, + "notes": "Kept as its own short frame: the deck has exactly 40 frames, the lower bound of the 40-46 band for three lessons, so folding this frame into frame 11 would breach the band. If time must be saved, trim minutes instead -- frame 6 (5 -> 4) and frame 15 (5 -> 4) -- or fold this frame into 11 only together with splitting frame 25 (Team Topologies: four team types / three interaction modes) so the count stays at 40" + }, + { + "no": 13, + "deck_section": "The Measurement Contract", + "title": "The four-layer cascade: four falsification questions", + "kind": "diagram", + "script_ref": "\\S 37.3 (part4_fit.tex 683); tab:cascade header (685-703)", + "content": [ + "(one sentence above the diagram) The contract has four layers, forming a \\textbf{cascade from design time to evolution}; each layer answers a different falsification question", + "(diagram) Design time -- \\emph{is the structure intact?}", + "(diagram) Delivery -- \\emph{is the structure delivering?}", + "(diagram) Operation -- \\emph{is the structure keeping its runtime promises?}", + "(diagram) Evolution -- \\emph{is the structure ageing?}", + "(one line below the diagram) instruments and example checks per layer: next frame" + ], + "elements": [ + "tikz: four rounded rectangles in a descending cascade (left-to-right, stepping down), each with layer name and question in italics only; arrows between them; style of the topology figures in deck 6 (bankblue fill, gray arrows)" + ], + "minutes": 3, + "notes": "Diagram carries the layer names and questions; no bullet list beside it (deck 6 topology frames: figure + one paragraph). Instruments stay on frame 14." + }, + { + "no": 14, + "deck_section": "The Measurement Contract", + "title": "The cascade: instruments and example checks per layer", + "kind": "table", + "script_ref": "\\S 37.3 tab:cascade (part4_fit.tex 685-703)", + "content": [ + "Design time | dependency rules as CI gates; coupling and cohesion metrics; complexity gates | ``the domain layer imports no framework''; ``no cycles between modules''; ``no domain service calls the LLM gateway except via the declared port''", + "Delivery | the four DORA metrics | deployment frequency, lead time, change failure rate, failed-deployment recovery time -- \\emph{per architecture quantum}", + "Operation | SLOs and error budgets; latency and \\emph{cost} budgets as pipeline gates; chaos experiments as continual holistic fitness functions | p95 latency budget per scenario; token-cost budget per request; blast-radius drills", + "Evolution | Lehman indicators; change scatter; technical-debt inventory | complexity trend per module; share of features touching more than two modules; debt-register review" + ], + "elements": [ + "scriptsize 4-row table Layer | Instruments | Example checks, p{1.8cm} p{5.3cm} p{5.6cm}, booktabs, \\addlinespace between rows -- transcription of tab:cascade without citations; the parenthetical tool list of the design-time cell (ArchUnit, Spring Modulith verify, dependency-cruiser) is dropped pre-emptively -- it is on frame 7" + ], + "minutes": 4, + "notes": "Long cells: keep no text above or below the table except a one-line caption" + }, + { + "no": 15, + "deck_section": "The Measurement Contract", + "title": "The reference contract for C10 (1/2): structure, latency, consistency", + "kind": "table", + "script_ref": "\\S 37.3 tab:contract rows 1-4 (part4_fit.tex 705-726)", + "content": [ + "Intro line: tab:contract instantiates the cascade as the \\textbf{reference contract for the course-project class C10} -- the concrete table that ADR-007 points to", + "Module boundaries | ArchUnit / Spring Modulith verify: no undeclared cross-module dependency | 0 violations | triggered (every build)", + "Determinism boundary | static rule: no domain service imports the LLM gateway except via the declared port | 0 violations | triggered", + "Latency | p95 end-to-end per critical scenario | advisory answer $< 20$\\,s | triggered $+$ continual", + "Consistency | ledger/audit reconciliation job: booked vs journaled | 0 discrepancies | temporal (daily)" + ], + "elements": [ + "scriptsize 4-row table Concern | Fitness function | Threshold (example) | Cadence, p{2.4cm} p{5.0cm} p{3.0cm} p{2.4cm}, from tab:contract rows 1-4" + ], + "minutes": 5, + "notes": "Two verbal points: (a) the latency row shows the same instrument at two cadences -- triggered in the pipeline and continual in operation; (b) the determinism-boundary row is the CI-enforced form of the exercise sheet's line 'keep the deterministic core free of LLM calls -- this is the line that is graded' -- the contract row permits LLM access via the declared port, the hint forbids LLM calls inside the core; do not present them as identical" + }, + { + "no": 16, + "deck_section": "The Measurement Contract", + "title": "The reference contract for C10 (2/2): delivery, resilience, AI correctness, AI cost", + "kind": "table", + "script_ref": "\\S 37.3 tab:contract rows 5-8 and eval-harness paragraph (part4_fit.tex 705-726)", + "content": [ + "Delivery performance | DORA four keys per deployable unit | e.g. change failure rate $< 15\\,\\%$; restore $< 1$ day | continual", + "Resilience | chaos experiment: kill one instance/broker under load | SLO holds; blast radius $\\leq$ declared | temporal", + "AI correctness | eval-harness pass rate on golden set plus domain axioms | $\\geq 95\\,\\%$ pass; 0 ontology-violating outputs shipped | triggered (every prompt/model change)", + "AI cost | token cost per request, per feature | $\\leq$ budget (e.g. CHF~0.40/request at p95) | continual", + "Below the table: for AI components the contract gains \\textbf{one artefact of the first rank -- the eval harness}: a versioned suite of test cases, scoring logic, and statistical thresholds that runs in CI like a test suite and gates every prompt change, model update, and provider migration; Part V develops it in full" + ], + "elements": [ + "scriptsize 4-row table, same column widths as frame 15, from tab:contract rows 5-8; one \\footnotesize paragraph on the eval harness (line 705)" + ], + "minutes": 4, + "notes": "Link verbally: ADR-011's three embryonic lines (shown in lecture 3) correspond to rows 2, 7 and 8 of this table -- the static rule has been tightened from 'no domain module imports the provider SDK' to 'gateway only via the declared port'" + }, + { + "no": 17, + "deck_section": "The Measurement Contract", + "title": "The cost of change -- what is flat", + "kind": "content", + "script_ref": "\\S 37.4 (part4_fit.tex 728-731)", + "content": [ + "\\emph{Why does the contract matter economically?} (leading question, italic)", + "The classical answer -- \\textbf{Boehm's cost-of-change escalation}: on waterfall project data of the 1970s, fixing a problem after delivery is up to \\textbf{one hundred times} more expensive than fixing it during requirements and design", + "Honest qualification: for small, uncritical systems the factor is closer to \\textbf{2:1}", + "Modern practice has empirically \\textbf{flattened} that curve for changes \\emph{within} an architecture", + "The largest replication to date -- \\textbf{171 projects from 2006--2014} -- found \\emph{no consistent delayed-issue effect} (Menzies et al. 2017)", + "Version control, automated tests, and continuous delivery did exactly what the economic argument of Extreme Programming said they would" + ], + "elements": [ + "two columns: Boehm (1981/2001) -- 100:1, 2:1 | Menzies et al. (2017) -- 171 projects, no consistent delayed-issue effect" + ], + "minutes": 4, + "notes": "semester plan: 'Boehm vs. Menzies'; do not add numbers beyond 100x, 2:1, 171, 2006-2014. No cost-curve sketch: the script gives no curve data (see open_issues)" + }, + { + "no": 18, + "deck_section": "The Measurement Contract", + "title": "The cost of change -- what is still steep", + "kind": "content", + "script_ref": "\\S 37.4 (part4_fit.tex 733)", + "content": [ + "The nuance the module insists on: flattened is the curve for changes \\emph{within} an architecture (deck 1, Assumption A5 -- stated then, evidenced now)", + "For changes \\emph{of} the architecture -- \\textbf{splitting a monolith}, \\textbf{changing the communication paradigm}, \\textbf{moving a data-intensive flow across expensive distributed boundaries} -- the curve remains steep", + "The evidence is the case studies themselves: Segment's consolidation and Prime Video's rewrite were, at their core, \\textbf{expensive architecture revisions}", + "This asymmetry is the \\textbf{economic justification of the whole apparatus}: justify the fit \\emph{up front} (architecture revision is the change class that still costs) and keep the architecture \\emph{evolvable under a green contract} (everything else is now cheap to change)" + ], + "elements": [ + "four \\footnotesize bullets, no figure; the three steep change classes set bold" + ], + "minutes": 4, + "notes": "The within/of asymmetry with Segment and Prime Video was stated in deck 1 A5 (line 558); the new material carrying this frame is the three change classes that stay steep and the up-front/evolvable argument. The life-cycle-cost sentence moves to frame 19." + }, + { + "no": 19, + "deck_section": "The Measurement Contract", + "title": "Key concept: the contract as a standing experiment", + "kind": "keyconcept", + "script_ref": "\\S 37.4 (part4_fit.tex 733) and keypoint (735-737)", + "content": [ + "(\\footnotesize text above the keypoint) Maintenance and evolution consume roughly \\textbf{40--80\\,\\%} -- typically about \\textbf{60\\,\\%} -- of life-cycle cost, mostly for \\emph{enhancement} rather than repair (deck 1, A5 -- stated then, sourced now); the contract is how a structure \\textbf{earns the right to survive that phase}", + "(keypoint) The measurement contract converts an architecture decision into a \\textbf{standing experiment}", + "(keypoint) design-time gates verify the \\emph{structure}; DORA metrics verify the \\emph{delivery}; budgets and chaos experiments verify the \\emph{runtime promises}; Lehman indicators verify the \\emph{ageing}", + "(keypoint) The cost-of-change curve is \\textbf{flat inside a green contract} and \\textbf{steep across architecture boundaries} -- which is why \\emph{the contract, not the diagram}, is the artefact that protects the investment" + ], + "elements": [ + "one \\footnotesize paragraph (line 733, last sentence) above; keypoint box condensed from lines 735-737" + ], + "minutes": 4 + }, + { + "no": 20, + "deck_section": "The Measurement Contract", + "title": "AI Lens (Axis A): fitness functions as the operating licence for agents", + "kind": "ailens", + "script_ref": "\\S 37 ailinse, Axis A paragraph (part4_fit.tex 739-741)", + "content": [ + "An agentic coding tool iterating against a dense test suite and CI-enforced architecture rules is \\textbf{contained}", + "Every generated change must pass the \\emph{same} dependency rules, budgets, and evals as a human change -- the blast radius of ``almost right'' code is bounded by the contract", + "Without those gates, every agent change is \\textbf{unpriced risk}", + "The empirical record shows AI adoption \\emph{amplifying} existing delivery dysfunction rather than fixing it (DORA 2025 AI report)", + "The measurement contract is therefore the prerequisite for raising the change rate by an order of magnitude safely: \\textbf{fitness functions are the operating licence for agents}" + ], + "elements": [ + "ailinse[Axis A -- fitness functions as the operating licence for agents], condensed from lines 739-741" + ], + "minutes": 4 + }, + { + "no": 21, + "deck_section": "The Measurement Contract", + "title": "AI Lens (Axis B): two new fitness-function types with old mechanics", + "kind": "ailens", + "script_ref": "\\S 37 ailinse, Axis B paragraph (part4_fit.tex 741-743)", + "content": [ + "The contract absorbs AI components through \\textbf{two new fitness-function types with old mechanics}", + "\\textbf{Eval-harness pass rate}: a \\emph{triggered} gate on every prompt and model change, statistically thresholded", + "\\textbf{Token-cost budget per request}: a \\emph{continual} gate, exactly analogous to a performance budget", + "Cost per request is a runtime quality attribute with \\textbf{no counterpart in classical profiles}", + "Making it a fitness function is what turns FinOps from a \\emph{monthly surprise} into an \\textbf{architectural control loop}" + ], + "elements": [ + "ailinse[Axis B -- eval pass rate and token budget], condensed from lines 741-743" + ], + "minutes": 4, + "notes": "Connect to deck 6 C10 profile: D9 = H in its eval reading, D10 = H cost per request -- these are the two rows now measurable" + }, + { + "no": 22, + "deck_section": "The Measurement Contract", + "title": "Project link: your submission ships its contract", + "kind": "content", + "script_ref": "\\S 37 projektbox (part4_fit.tex 745-747)", + "content": [ + "Your project submission must ship its \\textbf{measurement contract}, not just its architecture -- the repository must contain, \\emph{wired into CI}:", + "(1) module-boundary verification with \\textbf{zero violations} (ArchUnit or Spring Modulith verify), including the determinism-boundary rule: no domain service reaches the LLM gateway except via its declared port", + "(2) an eval harness with a versioned golden set and a \\textbf{pass rate $\\geq 95\\,\\%$} gating every prompt or model change", + "(3) a \\textbf{token-cost budget per request} enforced as a pipeline gate and reported per feature", + "(4) a p95 latency budget for the advisory scenario (\\textbf{$< 20$\\,s} end-to-end)", + "(5) the ADR (in MADR form) whose final section \\emph{is} this contract", + "At the project review you will be asked to demonstrate \\textbf{one contract violation being caught by CI} -- \\emph{a contract that has never failed is a contract that has never been tested}" + ], + "elements": [ + "projektbox verbatim (condensed) from lines 745-747, \\footnotesize" + ], + "minutes": 3, + "notes": "This is the submission requirement for the project review; frame 37 carries this week's tasks (resilience). Keep both -- they answer different questions" + }, + { + "no": 23, + "deck_section": "Conway's Law and Team Topologies", + "title": "The third fit dimension: why do correct matrix readings still fail?", + "kind": "content", + "script_ref": "\\S 38 opening (part4_fit.tex 752-757)", + "content": [ + "\\emph{Why do correct matrix readings still fail in real organisations?} (leading question, italic)", + "(recap, deck 2 D11) Conway's law in one sentence, and its consequence: every architecture decision is a team-structure decision -- named there, sourced here", + "The matrix matches patterns to application classes; D11 (team scaling) has appeared throughout as \\emph{one dimension among twelve} -- this section makes explicit why it is more than that: the organisation is a \\textbf{third party to the fit}, and ignoring it is the most common way correct matrix readings fail in practice", + "The source is older than every pattern in the matrix -- Conway, 1968 (highlighted line): \\emph{``Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure''}", + "Named ``Conway's law'' by Brooks (1975); empirically supported by mirroring studies of organisation and product structure (MacCormack et al. 2012)" + ], + "elements": [ + "the Conway quotation once, as a highlighted line (as on frames 9 and 11) -- no definitionbox is constructed, \\S 38 has no box except the closing keypoint" + ], + "minutes": 3, + "notes": "New content on this frame: the verbatim 1968 quotation, Brooks naming it, the MacCormack mirroring evidence, and the 'third party to the fit' framing; the law and its consequence are deck 2 recap" + }, + { + "no": 24, + "deck_section": "Conway's Law and Team Topologies", + "title": "Every architecture decision is a team-structure decision", + "kind": "content", + "script_ref": "\\S 38 (part4_fit.tex 757)", + "content": [ + "The consequence for this theory is direct: every architecture decision is \\emph{simultaneously} a team-structure decision, whether acknowledged or not", + "Left column -- \\textbf{a microservices topology assigned to a single five-person team} produces a \\textbf{distributed monolith}: many quanta, one communication structure, the worst cells of \\emph{two} columns at once (recap, deck 5: the distributed monolith and its lockstep-release signature)", + "Right column -- \\textbf{a modular monolith assigned to thirty independent teams} produces a \\textbf{release-coordination bottleneck} that no amount of code quality repairs" + ], + "elements": [ + "two-column mirror pair (style of the C1/C2 frame in deck 6): 'MS to one team' | 'MM to thirty teams'; the deck-5 recap tag as a \\footnotesize line under the left column" + ], + "minutes": 4, + "notes": "Tie to deck 6 Maxim 3 (quantum count): the distributed monolith is 'the worst cells of two columns at once' (cf. Maxim 3) -- keep to the script's phrase; the failure mode is recognised from deck 5 (hinweisbox, line 305), not re-taught" + }, + { + "no": 25, + "deck_section": "Conway's Law and Team Topologies", + "title": "Team Topologies: four team types, three interaction modes", + "kind": "table", + "script_ref": "\\S 38 (part4_fit.tex 759)", + "content": [ + "Team Topologies (Skelton and Pais 2019) turns the law \\textbf{from a hazard into a design instrument}", + "Stream-aligned | delivering end-to-end on one value stream", + "Platform | reduce the load of stream teams", + "Enabling | build missing capabilities", + "Complicated-subsystem | encapsulate specialist knowledge -- \\emph{an ML inference subsystem is the canonical course-relevant example}", + "Three interaction modes: \\textbf{collaboration}, \\textbf{X-as-a-service}, \\textbf{facilitating}", + "Together: the vocabulary for matching team structure to pattern choice" + ], + "elements": [ + "footnotesize 4-row table Team type | Role (from line 759); interaction modes as one line below" + ], + "minutes": 4 + }, + { + "no": 26, + "deck_section": "Conway's Law and Team Topologies", + "title": "Two concepts that bind directly into the matrix", + "kind": "content", + "script_ref": "\\S 38 (part4_fit.tex 759)", + "content": [ + "\\textbf{1. Cognitive load as a design criterion}: team and software boundaries should be cut so that \\emph{no team's cognitive load exceeds its capacity}", + "``Team-sized software'' is an \\textbf{architectural yardstick}", + "It explains why the MS column demands stream-aligned teams with full ownership as a \\textbf{precondition, not an outcome} (recap, decks 5 and 6: 'stream-aligned $+$ platform -- a precondition')", + "\\textbf{2. The inverse Conway manoeuvre}: deliberately structure the organisation to mirror the \\emph{target} architecture", + "-- so that Conway's law works \\emph{for} the design instead of against it" + ], + "elements": [ + "two numbered blocks; optional small tikz: organisation box mirrored onto target-architecture box with a reversed arrow labelled 'inverse Conway manoeuvre'" + ], + "minutes": 3 + }, + { + "no": 27, + "deck_section": "Conway's Law and Team Topologies", + "title": "The empirical anchor -- and the contested rows D11 decides", + "kind": "content", + "script_ref": "\\S 38 (part4_fit.tex 761)", + "content": [ + "The DORA scaling finding, read again: loose coupling of \\emph{architectures and teams} -- measured \\textbf{jointly}, which is itself a Conway statement -- is the strongest predictor of continuous delivery", + "It is the mechanism that lets deployments per developer per day \\textbf{scale linearly with team count}", + "The matrix encodes the organisational variable in D11; the class rationales repeatedly show it \\emph{deciding contested rows} (table)", + "No twelve-dimensional profile fully captures an organisation (limit 5 in \\S 39) -- but the rule of thumb is teachable" + ], + "elements": [ + "footnotesize table Class | same profile | smaller organisation | larger organisation -- C1: LMAX single-threaded core | Monzo 2,800 services (different organisation sizes); C5: Shopify modular monolith | Amazon microservices (along team count, not traffic) -- from line 761; the table carries the two cases, no bullets repeat them" + ], + "minutes": 3 + }, + { + "no": 28, + "deck_section": "Conway's Law and Team Topologies", + "title": "Key concept: the fit is three-way", + "kind": "keyconcept", + "script_ref": "\\S 38 keypoint (part4_fit.tex 763-765)", + "content": [ + "The fit is three-way: \\textbf{pattern $\\leftrightarrow$ application class $\\leftrightarrow$ team structure}", + "\\textbf{Check D11 last but veto on it first}: a pattern whose team precondition is not met -- microservices without stream-aligned ownership, a monolith across too many coordinating teams -- will fail regardless of how well the other eleven dimensions match", + "If the target architecture and the organisation disagree: either apply the \\textbf{inverse Conway manoeuvre} or \\textbf{change the target}", + "\\emph{Conway's law does not negotiate}" + ], + "elements": [ + "tikz triangle: three nodes 'pattern C(p)', 'application class R(a)', 'team structure' with double arrows; keypoint box below condensed from lines 763-765" + ], + "minutes": 3, + "notes": "Explain 'check last, veto first': D11 is checked last in the twelve-row profile walk-through but is the first veto to apply in practice" + }, + { + "no": 29, + "deck_section": "Limits of the Theory", + "title": "Limit 1: ordinal scales, no arithmetic", + "kind": "content", + "script_ref": "\\S 39 opening and item 1 (part4_fit.tex 770-776)", + "content": [ + "(lead-in line, italic) \\emph{A theory whose declared standard is that unfalsifiable claims have no place in architecture decisions must state how it can itself mislead.} Six limits, stated plainly -- the first:", + "The ratings support \\textbf{rankings and exclusions, never percentages}", + "Any weighted-sum reading of the matrix imports the documented defects of additive multi-criteria methods over ordinal data (grid):", + "(grid) \\textbf{rank reversal} (Belton and Gear 1983) | \\textbf{axiomatic conflict with utility theory} (Dyer 1990) | \\textbf{scale misinterpretation} (Bana e Costa and Vansnick 2008) | \\textbf{pseudo-precision} -- priorities with three decimal places from coarse verbal comparisons", + "We keep the \\emph{explication discipline} of multi-criteria decision analysis and drop its \\emph{arithmetic pretensions}", + "\\textbf{Sensitivity analysis is mandatory, not decorative}; unstable rankings are \\emph{findings} (tradeoff points), not errors" + ], + "elements": [ + "lead-in line from lines 772-773 (replaces the former overview frame); four defects as a 2 x 2 grid of short labelled cells (replaces the former bullet list of the four names)" + ], + "minutes": 4, + "notes": "Students met 'beware pseudo-precision' in deck 3; here the literature names are new -- keep to the four names, no further explanation is in the script. The six-limit overview appears once, on the consolidation table (frame 33)." + }, + { + "no": 30, + "deck_section": "Limits of the Theory", + "title": "Limits 2 and 3: context-dependent cells, hybrids as the normal case", + "kind": "content", + "script_ref": "\\S 39 items 2-3 (part4_fit.tex 777-778)", + "content": [ + "\\textbf{Limit 2.} Every capability cell encodes a \\emph{typical} workload", + "the serverless cost cell literally inverts with load shape (Prime Video); the layered read-scalability cell inverts with cache-friendliness (Stack Overflow)", + "skilled teams can move individual cells -- LMAX and Monzo both did", + "a rating is a \\textbf{default hypothesis} to be replaced by measurement in step (viii); \\emph{the matrix predicts the default, not the exceptional}", + "\\textbf{Limit 3.} Eight of ten class recommendations involve a core pattern plus different edge patterns", + "the matrix is defined over \\textbf{subsystems}; applying it to a whole enterprise in one stroke is a \\emph{category error the theory explicitly forbids}" + ], + "elements": [ + "two labelled blocks, \\footnotesize" + ], + "minutes": 4 + }, + { + "no": 31, + "deck_section": "Limits of the Theory", + "title": "Limit 4: the evidence base is heterogeneous", + "kind": "table", + "script_ref": "\\S 39 item 4 (part4_fit.tex 779)", + "content": [ + "(table) Star ratings (Richards and Ford) | expert judgement | not measurements", + "(table) DORA | survey-based prediction | not causal proof", + "(table) Case studies | self-reported engineering blogs | selection and framing bias", + "(table, last line) Hexagonal and serverless | -- | no star ratings at all", + "(line below) Prime Video in particular is routinely misquoted as ``Amazon abandons microservices'' when it documents \\emph{one service} with a data-intensive streaming workload -- you met it in deck 6 (SL, the split cell)", + "(line below) Compensation: \\textbf{triangulation} -- ratings against cases against metrics -- and the \\textbf{measurement contract}, which converts every adopted claim into a testable one" + ], + "elements": [ + "footnotesize table Source | Nature | Weakness, three rows plus the HX/SL line; two \\footnotesize lines below -- no bullet list duplicating the table" + ], + "minutes": 3, + "notes": "Deck 6 'evidence base and its honest gaps' already listed the expert-rating and HX/SL caveats and flagged the Prime Video misquotation ('Widely reported as Amazon abandons microservices', deck 6 line 359) -- new here are only the DORA and blog-bias rows and the compensation" + }, + { + "no": 32, + "deck_section": "Limits of the Theory", + "title": "Limits 5 and 6: the hidden organisation, AI-era volatility", + "kind": "content", + "script_ref": "\\S 39 items 5-6 (part4_fit.tex 780-781)", + "content": [ + "\\textbf{Limit 5.} Conway's law makes every architecture decision a team-structure decision", + "the same requirements profile admits \\emph{opposite} optimal patterns at different organisation sizes (LMAX vs Monzo; Shopify vs Amazon)", + "D11 partially captures this; no twelve-dimensional profile fully does (\\S 38)", + "\\textbf{Limit 6.} The D12 ratings encode the \\textbf{2025/26 state} of a field whose tools deprecate in months", + "the \\emph{method} -- Assumption A6: scenarios, tactics, trade-off analysis, ADRs, fitness functions -- is the stable part; the specific cells are \\textbf{perishable}", + "they carry, in effect, their own \\textbf{temporal fitness function}: re-verify on every model generation -- \\emph{Lehman's laws apply to theories too}" + ], + "elements": [ + "two labelled blocks, \\footnotesize" + ], + "minutes": 4 + }, + { + "no": 33, + "deck_section": "Limits of the Theory", + "title": "Six limits -- and what compensates each", + "kind": "table", + "script_ref": "\\S 39 items 1-6 (part4_fit.tex 776-781), compensations as stated in each item", + "content": [ + "1 Ordinal scales | rankings and exclusions only | sensitivity analysis, mandatory; unstable rankings are findings", + "2 Context-dependence | cells are typical-workload defaults | measurement replaces the rating in step (viii)", + "3 Hybrids normal | 8 of 10 classes core $+$ edges | apply the matrix to subsystems, never to a whole enterprise", + "4 Heterogeneous evidence | expert stars, survey prediction, self-reported blogs | triangulation $+$ the measurement contract", + "5 Hidden organisation | same profile, opposite optima by org size | D11 captures it only partially -- check the team precondition separately (\\S 38)", + "6 AI-era volatility | D12 cells encode 2025/26 | method (A6) stable; cells re-verified on every model generation" + ], + "elements": [ + "scriptsize 6-row table Limit | What it means | What compensates, p{2.6cm} p{4.4cm} p{5.4cm}, booktabs" + ], + "minutes": 3, + "notes": "Consolidation frame and the only overview of the six limits; every cell is a rephrasing of the respective item -- no new claims (row 5 states what the script says, not a compensation the script does not offer)" + }, + { + "no": 34, + "deck_section": "Limits of the Theory", + "title": "Important note: the matrix is a hypothesis, not an authority", + "kind": "content", + "script_ref": "\\S 39 hinweisbox (part4_fit.tex 784-786)", + "content": [ + "A student who cites the matrix as an \\emph{authority} rather than as a \\emph{hypothesis} has misunderstood the module", + "The matrix cannot tell you what to build; it can only \\textbf{force your criteria, weights, and assumptions into the open}, \\textbf{pre-filter the candidates}, and \\textbf{hand the contested cells to scenario-based analysis}", + "Its numbers are ordinal, its ratings are context-typical defaults, its evidence is triangulated but partly survey-based and partly self-reported -- and it \\emph{decays}: every cell is a claim awaiting your measurement", + "The canonical exercise in this scepticism: reading contradictory study designs against each other -- the METR-versus-Copilot contradiction of Part V (next week)", + "The assessment of this module tests the \\textbf{discipline}, not the memorisation of the grid" + ], + "elements": [ + "hinweisbox condensed from lines 784-786" + ], + "minutes": 4, + "notes": "Explicit bridge to Lecture 12 (the two contradictory RCTs)" + }, + { + "no": 35, + "deck_section": "Limits of the Theory", + "title": "Key concept: Maxim 9", + "kind": "keyconcept", + "script_ref": "\\S 39 keypoint (part4_fit.tex 788-790)", + "content": [ + "\\textbf{Maxim 9.} The matrix is the argument's \\textbf{skeleton}, ATAM is its \\textbf{court of appeal}, the ADR is its \\textbf{record}, and the fitness function is its \\textbf{parole condition}", + "The matrix is the \\emph{lecture-hall form} of a discipline whose \\emph{engineering form} is:", + "scenarios with numbers $\\cdot$ ATAM for the contested cells $\\cdot$ ADRs for the decisions $\\cdot$ fitness functions for the lifetime" + ], + "elements": [ + "keypoint box (Maxim 9) from lines 788-790; four-column strip skeleton | court of appeal | record | parole condition" + ], + "minutes": 3, + "notes": "Closes Part IV's theory: this frame is the one-sentence takeaway of Parts I-IV" + }, + { + "no": 36, + "deck_section": "Limits of the Theory", + "title": "Discussion", + "kind": "discussion", + "script_ref": "\\S 39 thinkbox (part4_fit.tex 792-794)", + "content": [ + "(setup) Limit 4 says the evidence base is heterogeneous, and limit 2 says skilled teams can move cells", + "(setup) Suppose your team measures, over a year, that its microservices system beats every prediction of the MS column for its class", + "Has the theory been \\textbf{falsified} -- or has your measurement contract done exactly what step (viii) designed it to do?", + "What would have to be true of your \\emph{next} project for the difference to matter?" + ], + "elements": [ + "thinkbox with the setup line and the two questions from lines 792-794 (title 'Discussion' as in decks 3 and 5)" + ], + "minutes": 3, + "notes": "3 min of steered discussion: 'default hypothesis vs measured exception', then Conway (the next project may have a different team structure)" + }, + { + "no": 37, + "deck_section": "Closing", + "title": "This week's exercise: resilience complete -- M4 closes", + "kind": "exercise", + "script_ref": "project_exercise.tex 424-429 (M4 taskbox), 452-463 (hintbox); semester plan row week 11", + "content": [ + "(projektbox) Coaching session (1 lesson). \\textbf{Resilience patterns on all external calls}: timeout, retry, circuit breaker, fallback", + "(projektbox) \\textbf{Graceful degradation verified}", + "(projektbox) \\textbf{Milestone M4 of the exercise sheet closes (end of week 11)}: deterministic core \\emph{fully tested} against the reference vectors \\emph{and resilient}", + "(projektbox, hint) Keep the deterministic core free of LLM calls -- this is the line that is graded", + "(\\footnotesize line below the box) Looking ahead: the resilience row of the reference contract (kill one instance/broker under load -- SLO holds) is the fitness function that would verify what you build now -- it is not a graded deliverable" + ], + "elements": [ + "projektbox with four bullets (tasks, degradation, milestone, one hint line -- the \\small short form of decks 4-6); one \\footnotesize line below" + ], + "minutes": 4, + "notes": "Speaker note: the determinism-boundary row of the reference contract (frame 15) is the CI-enforced form of the graded line -- not the same rule (the row permits LLM access via the declared port; the hint forbids LLM calls inside the core). 'M4' follows the exercise sheet students work from; the semester plan's adjustment table still labels this milestone 'M3 Resilienz + deterministischer Kern' -- flagged for correction (open_issues). The snapshot/commit/ADR hints (exercise sheet 459-463) are mentioned verbally, not printed." + }, + { + "no": 38, + "deck_section": "Closing", + "title": "Summary", + "kind": "summary", + "script_ref": "\\S 37-39 (part4_fit.tex 654-794)", + "content": [ + "1. \\textbf{Fitness functions}: objective integrity assessments; scope atomic/holistic, cadence triggered/continual/temporal; three families -- dependency gates, budgets, chaos experiments", + "2. \\textbf{DORA}: four keys, elite performers lead on all four; loosely coupled architectures \\emph{and teams} predict continuous delivery -- prediction, not causal proof", + "3. \\textbf{Four-layer cascade} -- four falsification questions; the C10 reference contract, eight rows with thresholds and cadences", + "4. \\textbf{Cost of change}: flat \\emph{within}, steep \\emph{across} architecture boundaries -- the contract, not the diagram, protects the investment", + "5. \\textbf{AI lens}: fitness functions are the operating licence for agents (A); eval pass rate and token budget, two new types with old mechanics (B)", + "6. \\textbf{Conway}: the fit is three-way; check D11 last but veto on it first; inverse Conway manoeuvre", + "7. \\textbf{Six limits}: ordinal, context-dependent, hybrids, heterogeneous evidence, hidden organisation, AI-era volatility -- a hypothesis, not an authority", + "8. \\textbf{Maxim 9}: skeleton, court of appeal, record, parole condition -- Part IV closes" + ], + "elements": [ + "enumerate, \\footnotesize, itemsep 2pt; every item capped at ~1.5 lines (deck 6 form); if still tight merge items 7 and 8" + ], + "minutes": 3 + }, + { + "no": 39, + "deck_section": "Closing", + "title": "Next week", + "kind": "nextweek", + "script_ref": "'Next lecture' line of the assignment; semester plan row week 12; deck 6 next-week frame (lines 673-698) for the form", + "content": [ + "Left column heading -- \\textbf{Lecture 12 -- Part V: two axes, one method}", + "Axis A: Copilot vs METR -- two contradictory RCTs and their resolution; the verification bottleneck", + "Axis A compact: architecture documentation as control interface, guardrails, the tool landscape and MCP, risks and accountability (\\S 41.6--41.9)", + "Axis B (I): the news-sentiment call wired the obvious way vs the right way; the three component types; the SE4AI classics", + "Axis B (I): integration patterns -- reference architecture with the LLM gateway; eval-harness foundations", + "Right column -- \\textbf{Reading}: this week: Part IV, sections 37--39; ahead: Part V, sections 40--41, 42.1--42.5", + "\\textbf{Exercise / deliverable}: coaching; AdvisorAgent $+$ 2--3 sub-agents behind the gateway (mandatory); ontology guard active on all insights" + ], + "elements": [ + "two columns 0.55/0.42 as in deck 6; left column four bullets \\small, bullet 2 may run to two lines; 'sections' lower-case as in decks 4-6" + ], + "minutes": 1, + "notes": "Week 12, 3 lessons -- not printed on the slide (deck 6 does not print week/lesson counts). Topic bullet 2 names \\S 41.6-41.9 in full because deck 12 teaches all four subsections (its frames 15-22: control interface and AGENTS.md, guardrails, tool landscape/MCP/benchmark expiry date, risks and accountability, 14 min for 41.8-41.9 alone) and they are taught nowhere else -- do not trim this bullet to 'guardrails (compact)'. 'the SE4AI classics' (42.3) is likewise on the deck-12 agenda." + }, + { + "no": 40, + "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": [ + "closing page macro as in deck 6" + ], + "minutes": 0 + } + ], + "exercise_frame": { + "title": "This week's exercise: resilience complete -- M4 closes", + "content": [ + "Coaching session (1 lesson). Resilience patterns on all external calls: timeout, retry, circuit breaker, fallback", + "Graceful degradation verified", + "Milestone M4 of the exercise sheet closes (end of week 11): deterministic core fully tested against the reference vectors and resilient", + "Keep the deterministic core free of LLM calls -- this is the line that is graded", + "Looking ahead (line below the box): the resilience row of the reference contract (kill one instance/broker under load -- SLO holds) is the fitness function that would verify what you build now -- it is not a graded deliverable" + ] + }, + "summary": [ + "Fitness functions: objective integrity assessments; scope atomic/holistic, cadence triggered/continual/temporal; three families -- dependency gates, budgets, chaos experiments", + "DORA: four keys, elite performers lead on all four; loosely coupled architectures and teams predict continuous delivery -- prediction, not causal proof", + "Four-layer cascade -- four falsification questions; the C10 reference contract, eight rows with thresholds and cadences", + "Cost of change: flat within, steep across architecture boundaries -- the contract, not the diagram, protects the investment", + "AI lens: fitness functions are the operating licence for agents (A); eval pass rate and token budget, two new types with old mechanics (B)", + "Conway: the fit is three-way; check D11 last but veto on it first; inverse Conway manoeuvre", + "Six limits: ordinal, context-dependent, hybrids, heterogeneous evidence, hidden organisation, AI-era volatility -- a hypothesis, not an authority", + "Maxim 9: skeleton, court of appeal, record, parole condition -- Part IV closes" + ], + "next_week": { + "lecture_line": "Lecture 12 -- Part V: two axes, one method", + "topics": [ + "Axis A: Copilot vs METR -- two contradictory RCTs and their resolution; the verification bottleneck", + "Axis A compact: architecture documentation as control interface, guardrails, the tool landscape and MCP, risks and accountability (sections 41.6-41.9)", + "Axis B (I): the news-sentiment call wired the obvious way vs the right way; the three component types; the SE4AI classics", + "Axis B (I): integration patterns -- reference architecture with the LLM gateway; eval-harness foundations" + ], + "reading": [ + "this week: Part IV, sections 37--39", + "ahead: Part V, sections 40--41, 42.1--42.5" + ], + "exercise": [ + "coaching: AdvisorAgent + 2--3 sub-agents behind the gateway (mandatory)", + "ontology guard active on all insights" + ] + }, + "script_boxes_used": [ + { + "box": "definitionbox[Architectural fitness function]", + "location": "part4_fit.tex 663-665", + "used_in_frame": "6 (first two sentences in the box; scope/cadence as a mini table with the script's examples)" + }, + { + "box": "enumerate: three worked instrument families", + "location": "part4_fit.tex 669-673", + "used_in_frame": "7, 8, 9" + }, + { + "box": "table tab:cascade", + "location": "part4_fit.tex 685-703", + "used_in_frame": "14 (table), 13 (diagram from header/questions)" + }, + { + "box": "table tab:contract", + "location": "part4_fit.tex 707-726", + "used_in_frame": "15 (rows 1-4), 16 (rows 5-8); thresholds also quoted on 8, 9, 10" + }, + { + "box": "keypoint (standing experiment)", + "location": "part4_fit.tex 735-737", + "used_in_frame": "19" + }, + { + "box": "ailinse[Fitness functions as the operating licence for AI -- both axes]", + "location": "part4_fit.tex 739-743", + "used_in_frame": "20 (Axis A), 21 (Axis B)" + }, + { + "box": "projektbox (submission must ship its contract)", + "location": "part4_fit.tex 745-747", + "used_in_frame": "22" + }, + { + "box": "keypoint (the fit is three-way)", + "location": "part4_fit.tex 763-765", + "used_in_frame": "28" + }, + { + "box": "enumerate: six limits", + "location": "part4_fit.tex 775-782", + "used_in_frame": "29, 30, 31, 32, 33" + }, + { + "box": "hinweisbox (authority vs hypothesis)", + "location": "part4_fit.tex 784-786", + "used_in_frame": "34" + }, + { + "box": "keypoint Maxim 9", + "location": "part4_fit.tex 788-790", + "used_in_frame": "35" + }, + { + "box": "thinkbox (falsified or contract worked?)", + "location": "part4_fit.tex 792-794", + "used_in_frame": "36" + } + ], + "script_boxes_dropped": [], + "open_issues": [ + "Dropped after review: the constructed scope x cadence instrument table (former frame 7) -- the script classifies scope only for three examples (dependency rule atomic; security/freshness holistic; chaos holistic) and gives the cost budget the cadence 'continual' only; the taxonomy is now shown once on frame 6 with the script's own examples.", + "Inconsistency in the script to resolve before typesetting: chaos experiments are 'continual, holistic' in 37.1 (line 672) and in tab:cascade, but cadence 'temporal' in tab:contract (resilience row). Frames 9 and 16 show both as the script states them; decide whether the contract row should read 'temporal (scheduled drill)' or 'continual'.", + "Recap frame draws on the deck-10 plan (summary frame 42 and Maxim-6 frame 15), deck 1 (A5), deck 2 (D5, D9, D11) and the deck-3 ADR-011 frame in addition to deck 6 and the semester plan, so that repeats on frames 7, 9, 11, 18, 19, 23, 24, 26 and 31 can carry recap tags; the assignment permits deck-6 text only -- keep or cut those tags. Bullet 1's L10 clause must be re-checked against the typeset deck-10 summary once it exists.", + "Section 38 (Conway) has no thinkbox and no ailinse in the script, so the deck has no Discussion or AI Lens frame for Conway; if one is wanted, the script must supply it.", + "Constructed boxes, not script boxes: the Prime Video examplebox (frame 4) and the DORA-caveat hinweisbox (frame 12) are built from running text (lines 657, 679) -- verbatim rephrasings, no new facts. No definitionbox is constructed for the Conway quotation (frame 23: highlighted line only).", + "The qualitative cost-of-change sketch (former frame 19) was dropped: the script gives no curve data; frames 17-18 carry the argument in text and the two-column Boehm | Menzies layout.", + "Evolution-layer instruments (Lehman indicators, change scatter, technical-debt inventory) appear only as table entries in tab:cascade -- the assigned passages do not explain them; frames 13/14 name them without elaboration.", + "Frame 20 cites 'the empirical record shows AI adoption amplifying existing delivery dysfunction' (dora2025aireport) -- the script gives no figures; do not add any.", + "Steps (vii) and (viii) refer to the eight-step procedure of Section 36 (Lecture 10, not yet typeset as a deck); recap bullet 1 now names the procedure, ADR-007 and Maxim 6 explicitly, so frames 5/30/36 can assume the step numbering is known -- it is not re-taught here.", + "Frames 15-16 split tab:contract 4+4; if the typeset table fits comfortably, merging into one 8-row frame would free one slot -- the split is preferred so the eval-harness paragraph (line 705) has room on frame 16.", + "Timing: content frames 4-36 sum to 120 min (not 125) so that the whole deck -- agenda 1, recap 3, exercise 4, summary 3, next week 1 -- stays at 132 min inside the 135-min slot; the reviewers' trims (discussion 5->3, coupling finding 5->4, cascade table 5->4, Conway opening 4->3, empirical anchor 4->3, limit 1 with lead-in, former overview and taxonomy frames removed) are applied. Frame count is exactly 40 -- the lower bound of the 40-46 band -- so frame 12 (DORA caveat, 2 min) must stay a frame; if time runs short, trim minutes on frames 6 (5 -> 4) and 15 (5 -> 4) instead, or fold frame 12 into 11 only together with splitting frame 25 (four team types / three interaction modes) so the count stays at 40.", + "Frame 37 says 'M4 of the exercise sheet' (M4 Deterministic Core and Resilience, weeks 10-11); the semester plan's adjustment table (Semesterplan_AISE502_HS26.md line 43) still labels this milestone 'M3 Resilienz + deterministischer Kern' -- correct the semester plan.", + "Next-week topics follow the deck-12 plan, not the semester-plan week-12 row: topic bullet 2 names \\S 41.6-41.9 in full (control interface, guardrails, tool landscape and MCP, risks and accountability) because deck 12 teaches them on its frames 15-22 and they are taught nowhere else; 'the SE4AI classics' (42.3) is on the deck-12 agenda as well. The semester-plan week-12 row is the narrower document -- align it to the deck, not the slide to the row." + ], + "total_frames": 40 +} diff --git a/Folien/Planung_7-13_json/L12.json b/Folien/Planung_7-13_json/L12.json new file mode 100644 index 0000000..51f7a9a --- /dev/null +++ b/Folien/Planung_7-13_json/L12.json @@ -0,0 +1,994 @@ +{ + "lecture": 12, + "week": 12, + "lessons": 3, + "title": "Lecture 12: The AI Dimension I -- Axis A Evidence, Axis B Foundations", + "script_reference": "Script: Part V, Sections 40--41, 42.1--42.5", + "agenda": [ + "Two axes, one method -- Assumption A6 falls due", + "Axis A: two contradictory RCTs and the empirical record", + "Reconciling the divergence; the verification bottleneck (Maxim 7); Axis A compact", + "Axis B: the news-sentiment call, wired the obvious way", + "The three component types; why containment: the SE4AI classics", + "The reference architecture: LLM gateway, queue, ontology guard", + "The eval harness as an engineering artefact", + "This week's exercise: AdvisorAgent + sub-agents behind the gateway" + ], + "recap": [ + "Parts I--IV complete; Lecture 11 closed Part IV: fitness functions -- three families (dependency gates, budgets, chaos experiments); the four-layer cascade and the eight-row C10 reference contract; cost of change flat within / steep across architecture boundaries; Conway -- the fit is three-way; six limits; Maxim 9 -- Part IV closed", + "AI Lens threads so far -- deck 1: the two AI axes and Assumption A6; deck 3: an LLM component stresses D3, D10, D12; an agent drafts the ADR, a human owns the decision; ADR-011: all LLM calls through one gateway port", + "Deck 6: C10 profile -- D12 = H, evals as the operative meaning of testability, cost per request; outlook: agent orchestration reuses the catalogue's topologies, workflows before agents (15x token finding); deck 11: fitness functions are the operating licence for agents (A); eval pass rate and token budget are fitness functions with old mechanics (B)", + "Today: Part V redeems A6 systematically -- the two axes as one method; the Axis A evidence and its resolution; the Axis B foundations up to the eval harness", + "Project: M4 delivered (deterministic core fully tested and resilient); M5 begins -- AdvisorAgent + 2--3 sub-agents behind the gateway, ontology guard active; the reference architecture today is just-in-time" + ], + "frames": [ + { + "no": 1, + "deck_section": "Title", + "title": "AISE502: AI in Software Engineering II -- Lecture 12: The AI Dimension I -- Axis A Evidence, Axis B Foundations", + "kind": "content", + "script_ref": "Title slide; metadata block copied from deck 6 (AISE502_Vorlesung_6_Folien.tex 116-120)", + "content": [ + "\\title[AI in Software Engineering II]{AISE502: AI in Software Engineering II}", + "\\subtitle{Lecture 12: The AI Dimension I -- Axis A Evidence, Axis B Foundations\\\\[0.4ex]{\\small Script: Part V, Sections 40--41, 42.1--42.5}}", + "\\author{Dr.\\ Florian Herzog}; \\shortname{AISE502}; \\fullname{Fachhochschule Graub\\\"unden, Chur -- Autumn Semester 2026}" + ], + "elements": [ + "FHGR title page (theme)" + ], + "minutes": 0, + "notes": "Copy deck 6 lines 116-120 verbatim and change only the subtitle. Institution typeset as Graub\\\"unden." + }, + { + "no": 2, + "deck_section": "Agenda", + "title": "Agenda", + "kind": "agenda", + "script_ref": "Deck skeleton; semester plan week 12 row (Semesterplan_AISE502_HS26.md line 23)", + "content": [ + "1. Two axes, one method -- Assumption A6 falls due", + "2. Axis A: two contradictory RCTs and the empirical record", + "3. Reconciling the divergence; the verification bottleneck (Maxim 7); Axis A compact", + "4. Axis B: the news-sentiment call, wired the obvious way", + "5. The three component types; why containment: the SE4AI classics", + "6. The reference architecture: LLM gateway, queue, ontology guard", + "7. The eval harness as an engineering artefact", + "8. This week's exercise: AdvisorAgent + sub-agents behind the gateway" + ], + "elements": [ + "\\small enumerate, as deck 6 lines 132-144" + ], + "minutes": 1, + "notes": "Eight one-line items (items 3 and 4 of the previous version merged)." + }, + { + "no": 3, + "deck_section": "Recap", + "title": "Recap: where we are", + "kind": "recap", + "script_ref": "Deck 11 summary frame 38 (bullets 1, 3, 4, 6, 7, 8) and AI Lens frames 20-21 (L11 plan); deck 6 summary and AI Lens frames (deck 6 lines 254-263, 498-521, 555-638); deck 3 lines 350-366, 560-606; semester plan row 12 (line 23); exercise sheet M4/M5 (project_exercise.tex 424-442)", + "content": [ + "Parts I--IV complete; Lecture 11 closed Part IV: fitness functions -- three families (dependency gates, budgets, chaos experiments); the four-layer cascade and the eight-row C10 reference contract; cost of change flat within / steep across architecture boundaries; Conway -- the fit is three-way; six limits; Maxim 9 -- Part IV closed", + "AI Lens threads so far -- deck 1: the two AI axes and Assumption A6; deck 3: an LLM component stresses D3, D10, D12; an agent drafts the ADR, a human owns the decision; ADR-011: all LLM calls through one gateway port", + "Deck 6: C10 profile -- D12 = H, evals as the operative meaning of testability, cost per request; outlook: agent orchestration reuses the catalogue's topologies, workflows before agents (15x token finding); deck 11: fitness functions are the operating licence for agents (A); eval pass rate and token budget are fitness functions with old mechanics (B)", + "Today: Part V redeems A6 systematically -- the two axes as one method; the Axis A evidence and its resolution; the Axis B foundations up to the eval harness", + "Project: M4 delivered (deterministic core fully tested and resilient); M5 begins -- AdvisorAgent + 2--3 sub-agents behind the gateway, ontology guard active; the reference architecture today is just-in-time" + ], + "elements": [ + "\\footnotesize bullets, five, each at most three lines (bullets 1 and 3 run to three); no box" + ], + "minutes": 3, + "notes": "One frame only; name the AI Lens boxes, do not re-teach them. Bullet 1 condenses deck 11's summary bullets 1, 3, 4 and 8 (plus the Conway and six-limits bullets 6 and 7 as half-clauses); in speech, name the two AI rows of the C10 reference contract (AI correctness = eval-harness pass rate, triggered; AI cost = token budget per request, continual) -- they are the immediate predecessors of today's guardrails (frame 16) and eval harness (frame 36, 'thresholds in the measurement contract'). Bullet 3 ends with deck 11's two AI Lens frames, so the AI Lens thread now runs deck 1 -> 3 -> 6 -> 11 without a gap." + }, + { + "no": 4, + "deck_section": "Two Axes, One Method", + "title": "Part V opens: the promissory note falls due", + "kind": "content", + "script_ref": "§40 intro (part5_ai_dimension.tex 10-12)", + "content": [ + "Leading question (italic, bankblue): Four parts built a complete decision theory without ever making artificial intelligence its subject -- does the construction survive the technology that defines its decade?", + "Not a rhetorical flourish but a promissory note falling due: Part I issued it as Assumption A6 -- AI components extend the quality attribute space but do not change the method. The bet in two sentences: everything AI does to software engineering can be absorbed by the apparatus you now own", + "If AI-bearing systems required a genuinely different method, the bet would be lost -- this part is where the claim must survive contact with the evidence", + "Roadmap line: cases first, generalisation after -- two contradictory randomised experiments open Axis A (§41); one concrete LLM call, wired wrongly and then rightly, opens Axis B (§42); the matrix reading (§43) and the emergent pattern (§44) follow next week" + ], + "elements": [ + "Leading question in italic bankblue; three \\small bullets; no box (the keypoint moves to frame 5)" + ], + "minutes": 3, + "notes": "Opening frame in the deck 4-6 style: question, one short paragraph, roadmap line. The list of apparatus items (scenarios, tactics, profiles, ADRs, fitness functions) is spoken here and printed on frame 5's caption line." + }, + { + "no": 5, + "deck_section": "Two Axes, One Method", + "title": "The two axes of the AI dimension", + "kind": "definition", + "script_ref": "§40 definitionbox (part5_ai_dimension.tex 14-21), fig:twoaxes (25-48), keypoint (50-52)", + "content": [ + "Definition (left column): Axis A -- AI as a tool in the SDLC. Code assistants, agentic coding tools, review bots participate in building the software: they generate code, tests, documentation, draft design artefacts. The software that ships may contain no AI at all. Unit of analysis: the development process and its economics", + "Axis B -- AI as a runtime component. LLM services, trained ML models, optimisation solvers are part of the delivered system and execute in production. Unit of analysis: the running system and its quality attributes", + "The axes are independent: a classical payroll system built with heavy agent support (A without B); a hand-crafted AI-native advisory platform (B without A). In practice, and in the course project, both apply simultaneously -- which is why they must be kept conceptually apart", + "Figure (right column): Axis A (AI as tool: agents, assistants) -> Development process (specify, build, verify, operate), arrow 'shifts SDLC economics'; Axis B (AI as component: LLM, ML, solver) -> Delivered system (structure, quality attributes), arrow 'stretches quality attribute space'; process -> system 'produces'", + "Caption line beneath the figure: Axis A changes how systems are built; Axis B what the built system contains -- both absorbed by the same method: scenarios, tactics, profiles, ADRs, fitness functions", + "Key Concept (one \\footnotesize line under both columns): Two axes, one method -- Axis A changes how systems are built, Axis B what they contain; the axes are independent and must be kept apart -- and both are analysed with the apparatus of Parts I--IV, nothing new" + ], + "elements": [ + "definitionbox[The two axes of the AI dimension] (lines 14-21), \\footnotesize, left column 0.52, each item at most two lines", + "tikz fig:twoaxes (lines 25-48) redrawn in the right column 0.44: rounded rectangles, aiviolet for the two axis boxes, bankgreen process box, bankblue system box", + "keypoint 'Two axes, one method' (lines 50-52) as one \\footnotesize line spanning the frame bottom" + ], + "minutes": 4, + "notes": "Two columns [T]. Definition first, key concept after it (script order, decks 4-6 order). If the keypoint box pushes the columns down, use \\vspace{-1ex} and shorten the third definition item to one line." + }, + { + "no": 6, + "deck_section": "Axis A -- Evidence and Resolution", + "title": "Case 1 -- the Copilot RCT: +55.8\\,\\% on a greenfield task", + "kind": "case", + "script_ref": "§41 intro + §41.1 (part5_ai_dimension.tex 60-65)", + "content": [ + "Leading question (italic): AI makes developers 55.8\\,\\% faster -- or 19\\,\\% slower. Which study is wrong? Both numbers come from randomised controlled trials, both methodologically sound; few topics in software engineering carry a larger gap between headline and evidence", + "Case 1 (published 2023): 95 professional developers randomly split into two groups; same task -- implement an HTTP server in JavaScript; one group with GitHub Copilot, one without; the clock measured time to completion", + "The treatment group finished 55.8\\,\\% faster", + "Qualification 1: the confidence interval (21--89\\,\\%) is very wide -- the headline number is a point estimate, not a natural constant", + "Qualification 2: a bounded, well-defined greenfield exercise -- no legacy context, no architectural constraints, no review process", + "Qualification 3: speed was measured, not quality; completion rates did not differ significantly", + "Within those bounds the result is real -- and it is the origin of the 'AI doubles productivity' headline genre" + ], + "elements": [ + "Leading question in italic bankblue; \\small bullets; the 55.8\\,\\% and the CI in bold. No \\measured box (the macro is defined only in deck 2's preamble, line 114; deck 6's preamble does not carry it)" + ], + "minutes": 4, + "notes": "Read as an experiment, not as a headline: setting first, finding second. All percentages typeset with the thin space \\,\\% throughout the deck." + }, + { + "no": 7, + "deck_section": "Axis A -- Evidence and Resolution", + "title": "Case 2 -- the METR RCT: 19\\,\\% slower in your own mature codebase", + "kind": "case", + "script_ref": "§41.2 (part5_ai_dimension.tex 67-70); the 'So which study is wrong? Neither' paragraph (line 72) moves to frame 11", + "content": [ + "Leading question (italic): What happens when the same technology meets experts on their own terrain?", + "16 experienced open-source maintainers; 246 real issues in repositories they had maintained for years -- large, mature codebases (over a million lines) with high implicit quality standards; each issue randomly assigned to an AI-allowed condition (predominantly Cursor with frontier models of early 2025) or an AI-forbidden condition", + "With AI, the developers took 19\\,\\% longer", + "The perception data are the didactic core: forecast before the study +24\\,\\% speed-up; measured --19\\,\\%; post-hoc estimate +20\\,\\% faster -- even experts cannot validly introspect their own AI-assisted productivity", + "METR's own explanation maps boundary conditions rather than refuting Case 1: deep repository familiarity left little for AI-supplied context to add; codebases large and conventionally dense; substantial time spent checking, repairing, discarding AI proposals" + ], + "elements": [ + "Leading question in italic; the three perception numbers (+24\\,\\%, --19\\,\\%, +20\\,\\%) in bold; five \\footnotesize bullets" + ], + "minutes": 4, + "notes": "The perception gap is the single most instructive fact of the section -- dwell on it. Do not answer 'which study is wrong' here; the answer opens the moderator table (frame 11)." + }, + { + "no": 8, + "deck_section": "Axis A -- Evidence and Resolution", + "title": "The full empirical record, 2023--2025", + "kind": "table", + "script_ref": "§41.3 intro + tab:aievidence (part5_ai_dimension.tex 77-103); Ziegler caution from the 'Field experiments at scale' paragraph (line 105)", + "content": [ + "Intro (one \\footnotesize line): the two cases are the extreme corners of a larger record -- seven strands, 2023--2025, from randomised experiments to organisational telemetry and longitudinal code analysis; read every row setting first, finding second", + "Row Copilot RCT | 95 developers; greenfield HTTP server (JavaScript) | +55.8\\,\\% task speed (95\\,\\% CI 21--89\\,\\%); completion rate not significantly different", + "Row Three field experiments | 4,867 developers; Microsoft, Accenture, Fortune-100 firm | +26.1\\,\\% completed tasks (s.e. 10.3\\,\\%); less experienced developers gain most", + "Row METR RCT | 16 expert OSS maintainers; 246 real issues, own mature repositories | 19\\,\\% slower with AI -- while estimating afterwards that AI had made them 20\\,\\% faster", + "Row DORA 2024 | ~3,000 respondents; organisational delivery level | +25\\,\\% AI adoption associated with --1.5\\,\\% throughput and --7.2\\,\\% delivery stability", + "Row DORA 2025 | ~5,000 respondents | throughput association now positive; instability persists; AI acts as an amplifier of existing strengths and dysfunctions", + "Row GitClear longitudinal | 211 million changed code lines, 2020--2024 | 4x growth in code duplication; moved-code share (the refactoring signature) collapsed from ~25\\,\\% to below 10\\,\\%", + "Row Stack Overflow survey | >49,000 developers | 84\\,\\% use or plan to use AI; 46\\,\\% actively distrust its output; top frustration: 'almost right' code", + "\\scriptsize note line under the table: methodological caution from GitHub's own telemetry-plus-survey study -- the best predictor of perceived productivity is the suggestion acceptance rate, not the persistence of accepted code in the repository; much vendor-reported 'productivity' evidence measures perception, not verified output. Case 2's perception gap is the controlled-trial demonstration of the same fact" + ], + "elements": [ + "7-row scriptsize booktabs table Evidence | Setting | Finding with p{2.4cm}p{4.0cm}p{6.0cm} (12.4 cm) and \\renewcommand{\\arraystretch}{0.85}, Setting cells one line each, headline numbers in bold, from tab:aievidence lines 79-103; one \\scriptsize note line beneath" + ], + "minutes": 3, + "notes": "Former frame 9 dropped; its only non-duplicate content (the Ziegler acceptance-rate caution, line 105) is the note line under the table; the 'juniors and task novices benefit most' pattern is spoken with row 2. Compile-check the height; if it overflows, split (1/2) rows 1-3 experiments and (2/2) rows 4-7 organisation, code, survey (frame count 43, still in band)." + }, + { + "no": 9, + "deck_section": "Axis A -- Evidence and Resolution", + "title": "The system level: DORA 2024 and 2025", + "kind": "content", + "script_ref": "§41.3 paragraph 'The system level: DORA 2024 and 2025' (part5_ai_dimension.tex 107)", + "content": [ + "DORA measures neither task times nor perceptions but delivery performance at the level of the organisation -- throughput and stability -- exactly the level at which architecture acts", + "2024 (~3,000 respondents; 75.9\\,\\% use AI for at least part of their work, roughly three quarters report productivity gains) -- a 25\\,\\% increase in AI adoption is associated with: mini-table left column +7.5\\,\\% documentation quality, +3.4\\,\\% code quality, +3.1\\,\\% review speed | right column --1.5\\,\\% delivery throughput, --7.2\\,\\% delivery stability. Proposed mechanism is classical: more code per change, and larger batch sizes have been a documented risk driver for years", + "2025 (~5,000 respondents): adoption near saturation (90\\,\\%, median about two hours of daily use); more than 80\\,\\% report productivity gains; 30\\,\\% still express little or no trust in AI-generated code; the throughput association has turned positive as tools and practices matured -- the negative association with delivery stability persists", + "Central metaphor: AI is an amplifier -- it magnifies the strengths of well-run organisations and the dysfunctions of badly run ones", + "Individual acceleration and system-level performance are different quantities, and only the second one pays salaries" + ], + "elements": [ + "\\footnotesize bullets, five; the 2024 associations as a two-column \\scriptsize mini-table (gains | losses) inside bullet 2" + ], + "minutes": 3, + "notes": "Connect to Lecture 11 (four DORA metrics) in speech only; do not add content beyond §41.3." + }, + { + "no": 10, + "deck_section": "Axis A -- Evidence and Resolution", + "title": "Code structure and practitioner trust in the longitudinal record", + "kind": "content", + "script_ref": "§41.3 paragraphs 'Code structure in the longitudinal record' and 'Practitioner trust' (part5_ai_dimension.tex 109-111)", + "content": [ + "GitClear, 211 million changed lines (2020--2024): duplicated code blocks (five or more lines) at four times their pre-AI level in 2024; moved lines -- the fingerprint of refactoring and modularisation -- fell from roughly 25\\,\\% to under 10\\,\\%: 2024 was the first year in which copy-paste exceeded code movement", + "Churn -- code reworked or discarded within two weeks of commit -- rose from a pre-AI baseline of roughly 3--4\\,\\% to 5.7\\,\\% in 2024, trend continuing; two obligatory caveats: GitClear is a commercial analytics vendor, and the analysis is correlational -- AI's causal share is plausible but not isolated", + "Converges with DORA's stability data: more code, produced faster, structurally worse maintained -- reuse by abstraction displaced by reuse by duplication, the opposite of what Parnas-style modularisation (Part II) works to achieve", + "Stack Overflow 2025 (>49,000 developers): 84\\,\\% use or plan to use AI tools; 46\\,\\% actively distrust the accuracy of the output; most-cited frustration (45\\,\\%): 'almost right, but not quite' -- adoption rises while trust falls, consistent with METR and DORA: the effort has migrated from writing to verifying" + ], + "elements": [ + "\\footnotesize bullets, four; GitClear and Stack Overflow headline numbers in bold" + ], + "minutes": 4, + "notes": "The 8.3\\,\\% -> 12.3\\,\\% copy-paste share, the 3\\,\\% high-trust figure and the 66\\,\\% 'more time fixing almost-right code' figure are spoken, not printed (the 66\\,\\% returns as 'two thirds' on frame 13). The last bullet is the bridge to the bottleneck frame." + }, + { + "no": 11, + "deck_section": "Axis A -- Evidence and Resolution", + "title": "Reconciling the divergence: five moderator variables", + "kind": "table", + "script_ref": "§41.2 closing paragraph (part5_ai_dimension.tex 72) as the intro; §41.4 intro + tab:moderators (113-134)", + "content": [ + "Intro (\\footnotesize): So which study is wrong? Neither -- resolving the contradiction is the lesson: different populations (task novices versus domain experts in their own code), different codebases (greenfield versus mature), different tasks (bounded versus real issues) -- the results never actually compete; the resolution requires reading study designs, not abstracts", + "The apparent contradictions dissolve once the studies are indexed by their moderator variables: Case 1 and Case 2 sit at opposite corners of a five-dimensional design space, and every other row of the record finds its place in the same coordinates", + "Row Experience | juniors, task novices (Copilot RCT, field experiments) | domain experts in their own code (METR)", + "Row Codebase | greenfield, small, standard stack | mature, large, dense implicit conventions", + "Row Task | well-defined, bounded | under-specified, cross-cutting", + "Row Measurement | task time, perceived productivity | delivery stability, maintainability, churn (DORA 2024, GitClear)", + "Row Organisation | small batches, test automation, loose coupling | large batches, weak guardrails, tight coupling (DORA 2025)", + "Closing line: the same technology yields +55.8\\,\\% and --19\\,\\% because the two cases differ on every one of the five rows" + ], + "elements": [ + "5-row footnotesize booktabs table Moderator | Gains high | Gains low or negative, p{2.2cm}p{5.0cm}p{5.2cm} (12.4 cm), from tab:moderators lines 118-134" + ], + "minutes": 4, + "notes": "This table is the intellectual answer to the leading question of frame 6 -- announce it as such; the intro paragraph is the script's own 'Neither' answer, moved here from Case 2." + }, + { + "no": 12, + "deck_section": "Axis A -- Evidence and Resolution", + "title": "Discussion: which setting is yours?", + "kind": "discussion", + "script_ref": "§41.4 thinkbox (part5_ai_dimension.tex 136-138)", + "content": [ + "The same class of technology produced +55.8\\,\\% in one randomised experiment and --19\\,\\% in another. Walk through the five moderators: on which rows do the two studies differ?", + "Consider the systems you are likely to work on two years after graduation -- greenfield exercises, or mature codebases with implicit conventions? Which study's setting is closer to that reality?", + "What does the METR perception gap (forecast +24\\,\\%, measured --19\\,\\%, post-hoc estimate +20\\,\\%) imply about relying on your own felt productivity as evidence?", + "One-line codegray aside beneath the box (outside the thinkbox, marked 'Project transfer'): which moderator row describes your repository in week 12?" + ], + "elements": [ + "thinkbox 'Discussion' with the script's three questions, \\footnotesize; a \\scriptsize codegray aside beneath it for the project transfer" + ], + "minutes": 4, + "notes": "Four minutes of plenum discussion; keep the moderator table of frame 11 in speech. The project-transfer question is not script text -- it stays outside the box." + }, + { + "no": 13, + "deck_section": "Axis A -- Evidence and Resolution", + "title": "The verification bottleneck", + "kind": "content", + "script_ref": "§41.5 (part5_ai_dimension.tex 143-145)", + "content": [ + "The structural conclusion underneath the moderator table, in one sentence (centred, bold): code generation became cheap; specification, verification, and architecture became the binding constraints", + "When the marginal cost of producing plausible code approaches zero, the scarce resource is no longer typing but everything that surrounds it: understanding the requirement precisely enough to specify it, reviewing and testing what was generated, and accepting responsibility for shipping it", + "The strands converge: DORA -- individual acceleration coexists with delivery instability where control systems are weak; two thirds of surveyed developers spend more time on almost-right code; a substantial share of METR's slow-down is time spent checking, repairing, discarding AI proposals; industry analyses describe code review as the new bottleneck -- more and larger pull requests meeting unchanged human review capacity", + "Economically put: AI lowers the cost of producing code, not the cost of taking responsibility for code" + ], + "elements": [ + "\\small bullets; the one-sentence conclusion set as a centred bold line" + ], + "minutes": 3, + "notes": "Keep it sparse; the next frame carries the three consequences." + }, + { + "no": 14, + "deck_section": "Axis A -- Evidence and Resolution", + "title": "Three consequences bind Axis A into the fit theory -- Maxim 7", + "kind": "keyconcept", + "script_ref": "§41.5 enumerate + keypoint Maxim 7 (part5_ai_dimension.tex 147-155)", + "content": [ + "1. Architecture quality gates AI gains -- DORA 2025's core finding: teams in loosely coupled architectures with fast feedback loops convert AI adoption into throughput; tightly coupled systems with slow processes do not -- the AI-era echo of loosely coupled architectures and teams as the strongest predictor of continuous delivery performance (the coupling finding of Lecture 11)", + "In the theory's vocabulary: D7 (evolvability) and D9 (testability and deployability) gain weight in every requirements profile -- architecture--application fit acquires a second reading: fit to a mode of work in which change volume rises by an order of magnitude", + "2. Architecture documentation becomes a control interface -- ADRs, repository convention files, and machine-readable rules are no longer passive records; agents execute them on every run (§41.6)", + "3. Fitness functions become the operating licence for agents -- an agent iterating against a dense test suite and CI-enforced architecture rules is contained; without them, every agent change is unpriced risk (§41.7)", + "Key Concept -- Maxim 7: Good architecture was always the art of making change cheap and safe; AI raises the change rate by an order of magnitude -- and therefore raises, not lowers, the value of architecture" + ], + "elements": [ + "numbered list \\footnotesize", + "keypoint box 'Maxim 7' (lines 153-155) verbatim" + ], + "minutes": 4, + "notes": "Maxim 7 is examinable; set it apart visually. Each consequence 'is measurable' -- say so. The D7/D9 reading is the new content; the coupling finding is marked as Lecture 11's." + }, + { + "no": 15, + "deck_section": "Axis A -- Control Interface and Guardrails", + "title": "Architecture documentation as a control interface for agents", + "kind": "content", + "script_ref": "§41.6 text + lst:agentsmd (part5_ai_dimension.tex 160-188), condensed per semester plan ('Guardrails (kompakt)')", + "content": [ + "Agentic tools are context-driven: they produce architecture-conformant code only if the architecture is explicit, machine-readable, and in the repository -- Part I's documentation artefacts, written for human readers, upgrade into a control interface for machine collaborators. ADRs (preferably MADR) serve agents twice: as input context (why is the system structured this way? which options were rejected, and why?) and as output format -- an agent drafts, a human decides and signs, per Assumption A1 (deck 3)", + "Agent instruction files -- project-local CLAUDE.md and the vendor-neutral AGENTS.md (published 2025, adopted within months by over 60,000 open-source repositories) -- carry stack, conventions, build and test commands, module boundaries, no-go zones; loaded at every session start: documentation once 'too expensive to maintain for human readers' now amortises because it is executed on every agent run. Machine-checkable conventions (dependency directions, naming, layering) are a failing test rather than a prose exhortation -- the fitness-function discipline of Part IV", + "The corollary cuts both ways: documentation debt is now reproduced at machine speed -- a stale convention file or ADR is executed by every agent session; DORA 2025: 'AI-accessible internal knowledge' and healthy data ecosystems rank among the seven capabilities that amplify AI benefits", + "Listing (excerpt from the course project's agent instruction file): '# Portfolio Intelligence Platform -- agent instructions'", + "'## Architecture (binding; see docs/adr/)' -- Modular monolith, module boundaries enforced by CI (see fitness_functions/boundaries_test.py). Do not add cross-module imports; use the module's public API. -- All LLM access goes through gateway/ -- never call a provider SDK from domain code (ADR-011)", + "'## Verification (run before proposing changes)' -- make test (unit + module-boundary rules); make evals (eval harness; required for any change under prompts/ or gateway/)", + "'## No-go zones' -- ledger/: append-only audit journal. Propose changes as an ADR draft instead of editing code", + "One \\scriptsize caption line beneath the listing: every line is a control statement that an agent executes on each run -- and that therefore must be kept as current as code" + ], + "elements": [ + "three \\footnotesize bullets (each at most three lines) above the listing; inline continuity marker '(deck 3)' in \\scriptsize", + "lstlisting lst:agentsmd (lines 170-188) full-width in a grey tcolorbox, \\scriptsize\\ttfamily, the three blank separator lines removed (14 code lines), as the ADR-011 frame of deck 3 (lines 560-576); one \\scriptsize caption line beneath" + ], + "minutes": 4, + "notes": "Former frames 15 and 16 merged (semester plan: 'Guardrails (kompakt)'). Just-in-time: students maintain exactly this file in M5. Point to ADR-011 and the eval-harness line, which foreshadows §42.5. Compile-check with pdftoppm: three footnotesize bullets (~8 lines) plus 14 listing lines at scriptsize must clear the footline; if they do not, drop bullet 3 (the corollary) to speech first, then fall back to the two-frame version (text frame + listing frame, frame count 43)." + }, + { + "no": 16, + "deck_section": "Axis A -- Control Interface and Guardrails", + "title": "Guardrails as the precondition for safe agent use", + "kind": "content", + "script_ref": "§41.7 (part5_ai_dimension.tex 193-201), condensed", + "content": [ + "If verification is the scarce resource, then everything that automates verification multiplies the value of AI tooling -- and everything that leaves verification informal converts AI speed into instability", + "Test suites are the operating licence: against a dense, fast test suite an agent can iterate -- wrong code fails immediately and is repaired or discarded at machine speed; without that net every agent-generated change ships unpriced risk (DORA's 'strong version control and test automation' amplifier pair)", + "Architectural fitness functions fence the structure: an objective integrity assessment of an architectural characteristic is the machine-readable form of an architecture decision -- dependency rules, cycle checks, module-boundary verification as CI gates were good practice before AI; with agents in the loop they are the mechanism by which an architect constrains a collaborator who never attends design meetings", + "The delivery pipeline becomes a defence instrument: static analysis, SAST, dependency and secret scanning, contract tests, progressive delivery move from hygiene to necessity -- the only controls that scale with generation volume", + "Continuity with Part IV: nothing here is new machinery -- the measurement contract already demanded executable invariants; Axis A merely adds a new class of change producer whose volume makes the contract non-optional" + ], + "elements": [ + "\\footnotesize bullets, five" + ], + "minutes": 3, + "notes": "Compact; refer back to Lecture 11's fitness-function taxonomy in speech." + }, + { + "no": 17, + "deck_section": "Axis A -- Control Interface and Guardrails", + "title": "The tool landscape, soberly -- and the AI Lens on MCP", + "kind": "ailens", + "script_ref": "§41.8 intro, tool list, two standards + ailinse (part5_ai_dimension.tex 206-219), condensed", + "content": [ + "Record the landscape as a geologist records a riverbed -- evidence of forces, not a map that stays accurate. Generation 2021--2023 (autocomplete-style assistants) suggested lines; generation 2024/2025 onwards plans, edits multiple files, runs builds and tests, iterates on failures -- agentic loops with tool access", + "Claude Code (Anthropic): agentic CLI tool, research preview February 2025, GA May 2025; repository-level anchor CLAUDE.md", + "Cursor (Anysphere): AI-first IDE with an agent mode; the dominant tool among the METR study's experts", + "GitHub Copilot: Copilot Workspace retired May 2025; its concepts live on in the asynchronous Copilot coding agent (issues to pull requests, in CI) and the synchronous IDE agent mode", + "Devin (Cognition): 'first AI software engineer' (2024); 13.86\\,\\% SWE-bench in March 2024 triggered the agent wave; acquired Windsurf July 2025 -- rapid market consolidation", + "Two open standards matter more than any product, because they are architectural: Model Context Protocol (MCP, Anthropic, November 2024; JSON-RPC, servers expose tools, resources, prompts; adopted by OpenAI, Google DeepMind, Microsoft in 2025; December 2025 to the Agentic AI Foundation under the Linux Foundation; over 10,000 public servers) and AGENTS.md for project-level instructions; vendor SDKs extract the agent loop as a library -- the bridge to Axis B (§44, next week)", + "AI Lens [MCP is ports-and-adapters at ecosystem scale]: strip the branding and MCP is a familiar shape -- a technology-neutral port (the protocol) with swappable adapters (servers wrapping databases, ticket systems, browsers), letting any conforming client use any conforming tool -- the role JDBC/ODBC played for databases. The hexagonal pattern of Part II did not become obsolete in the agent era; it became an ecosystem standard" + ], + "elements": [ + "\\footnotesize bullets, six (product bullets one line each, names in bold); ailinse[MCP is ports-and-adapters at ecosystem scale] (lines 217-219), condensed" + ], + "minutes": 4, + "notes": "Former frames 19 and 20 merged. Announce that the examinable content is the pattern pair (sync pair-agent vs async task-agent), not product names -- the hinweisbox follows on frame 18. Ties back to deck 4's HX frames; the port/adapter vocabulary is exactly what the gateway frames reuse. If the box overflows, drop the parenthetical MCP adoption chronology to speech." + }, + { + "no": 18, + "deck_section": "Axis A -- Control Interface and Guardrails", + "title": "Benchmarks and their limits -- an expiry date on this section", + "kind": "content", + "script_ref": "§41.8 paragraph 'Benchmarks and their limits' + hinweisbox (part5_ai_dimension.tex 221-225)", + "content": [ + "SWE-bench: 2,294 real GitHub issues from twelve Python projects -- given repository and issue text, produce a patch that passes hidden tests. Trajectory: 1.96\\,\\% (best 2023 setup) -> 13.86\\,\\% (Devin, March 2024) -> around 77--81\\,\\% for frontier models by late 2025 on the human-validated 500-task SWE-bench Verified subset", + "Four qualifications keep the number honest: (1) contamination -- the repositories are in the training data; (2) scope -- Python only, issues with tests only; (3) criterion -- 'tests pass' is not 'maintainable, architecture-conformant'; (4) saturation -- on the contamination-resistant SWE-bench Pro, frontier models initially scored around 23\\,\\%. Near-80\\,\\% benchmark scores next to METR's measured slow-down: the module's canonical exercise in benchmark literacy", + "Important Note: this section encodes the state of early 2026; product names carry an expiry date measured in months (Copilot Workspace lived roughly a year). Stable -- and examinable -- are the patterns: the synchronous pair-agent versus the asynchronous task-agent as interaction modes, context files and ADRs as the control interface, fitness functions as the containment mechanism. Every concrete tool claim carries its own temporal fitness function: re-verify on every tool generation" + ], + "elements": [ + "two \\footnotesize bullets; hinweisbox (lines 223-225), condensed, \\footnotesize" + ], + "minutes": 3, + "notes": "Compressed to two SWE-bench bullets plus the hinweisbox; the box is the examinable part." + }, + { + "no": 19, + "deck_section": "Axis A -- Control Interface and Guardrails", + "title": "Risks and responsibility: security, bias, skill, accountability", + "kind": "content", + "script_ref": "§41.9 paragraphs 'Security of generated code', 'Automation bias and skill formation', 'Accountability' (part5_ai_dimension.tex 230-234), condensed per semester plan ('kompakt')", + "content": [ + "Security -- the evidence predates the agent wave and gains relevance with volume: roughly 40\\,\\% of 1,689 Copilot-generated programs (89 security-relevant scenarios) contained CWE top-25 vulnerabilities; a user study: participants with an AI assistant wrote less secure code on most tasks while believing their code to be more secure; package hallucination ('slopsquatting'): across roughly 576,000 generations, about a fifth of recommended package references did not exist -- names an attacker can register pre-emptively. Consequence: SAST, dependency and secret scanning, licence checks in CI are not optional; security review capacity must scale with generation volume", + "Automation bias: over-trust in automated systems is a decades-old human-factors finding -- Perry et al.'s participants overestimated their security, METR's experts overestimated their speed", + "Skill formation: a randomised study of engineers learning a new library -- AI assistance reduced comprehension-test scores by roughly 17\\,\\%; the usage pattern is the decisive moderator (conceptual questions preserved learning, wholesale delegation destroyed it); entry-level developer positions are measurably declining. For this module: the role being trained is the specifier, verifier, and architect -- rebuild the competence ladder deliberately, including AI-free practice of fundamentals", + "Accountability: legally and professionally, the person who merges code answers for it, regardless of what generated it; AI tools are not liability-bearing entities -- treat AI output as the contribution of an unknown third party: mandatory review, provenance labelling, an explicit policy for permitted uses (DORA 2025: a clearly communicated AI policy first among the seven amplifier capabilities)", + "AI may draft an ADR; a nameable person decides, signs, and defends it (deck 3) -- architecture is an accountability performance, not a text-production performance. IP risk open but manageable: Doe v. GitHub -- the DMCA claim dismissed in 2024, licence-related claims continue; response: provider duplication filters and indemnification, licence scanning in CI, a documented residual risk in the governance record" + ], + "elements": [ + "\\footnotesize bullets, five (bullets 1 and 3 up to three lines); the headline figures (40\\,\\%, less secure / more secure, one fifth of 576,000, --17\\,\\%, entry-level decline) in bold; 'architecture is an accountability performance' as a highlighted clause", + "\\scriptsize fallback for the bullets if the frame overflows" + ], + "minutes": 3, + "notes": "Former frames 20 and 21 (risks 1/2 and 2/2) merged (semester plan: 'kompakt'). Address the students directly on the skill-formation bullet; it is the personal reading of Maxim 7. The ADR rule is one clause with the deck-3 marker; do not re-teach it. The 8.3 -> 12.3 copy-paste and 3\\,\\% high-trust figures stay in speech as before." + }, + { + "no": 20, + "deck_section": "Axis A -- Control Interface and Guardrails", + "title": "Project link: Axis A governs how you build the platform", + "kind": "content", + "script_ref": "§41.9 projektbox (part5_ai_dimension.tex 236-238)", + "content": [ + "Axis A governs how you build the Portfolio Intelligence Platform; the project applies every mechanism of this section", + "(i) the repository carries an AGENTS.md / CLAUDE.md in the spirit of the listing -- and you are expected to keep it as current as code", + "(ii) every architecture decision is an ADR -- agents may draft, but a named team member signs", + "(iii) agent-generated changes enter the main branch only through the CI gate: module-boundary fitness functions, the test suite, and -- for anything touching prompts or the gateway -- the eval harness of §42.5", + "(iv) your project handbook contains a one-page AI policy: permitted tools, provenance labelling, review rules", + "The graded artefact is not the generated code -- it is the control system around it" + ], + "elements": [ + "projektbox (lines 236-238), \\footnotesize, four numbered items plus the closing sentence in bold" + ], + "minutes": 2, + "notes": "Closes the Axis A block; the closing sentence deserves emphasis before the break." + }, + { + "no": 21, + "deck_section": "Axis B -- Component Types", + "title": "Axis B opens: the news-sentiment call, wired the obvious way", + "kind": "case", + "script_ref": "§42 intro + §42.1 (part5_ai_dimension.tex 246-251)", + "content": [ + "Leading question (italic): One of the platform's features is a single LLM call -- news in, sentiment out. Why not call it like any other function?", + "Axis B moves AI from the workshop into the product; as always the case precedes the taxonomy: walk one concrete call end to end, watch what breaks, and name every break with a dimension you already own", + "The feature: when a user opens a portfolio, the platform fetches the latest news items for its positions and asks an LLM, per item -- is this news positive, negative, or neutral for this holding, and why? One prompt, one structured answer: the simplest runtime AI component the course project owns", + "Wired the obvious way: a provider-SDK call inside the request handler, synchronously in the page-rendering path", + "Five failures arrive on schedule -- each landing on one of the twelve dimensions" + ], + "elements": [ + "Leading question italic bankblue; optional small tikz strip: request handler -> provider SDK call -> page render (synchronous), grey boxes" + ], + "minutes": 3, + "notes": "Keep the frame light; the failures get two frames of their own." + }, + { + "no": 22, + "deck_section": "Axis B -- Component Types", + "title": "Five failures on schedule (1/2): latency, cost, non-determinism", + "kind": "case", + "script_ref": "§42.1 enumerate items 1-3 (part5_ai_dimension.tex 254-256)", + "content": [ + "Subtitle line (\\scriptsize, codegray): the deck-3 AI Lens, now concrete", + "1. Latency (D3): the call takes seconds -- one to sixty-plus, depending on model and load -- where every other call in the handler takes milliseconds: the page now blocks on the slowest and least controllable component in the stack", + "2. Cost (D10): priced per token, so the feature bills per request -- every portfolio open costs real money; a loop over twenty positions is a twenty-fold cost regression the way an n+1 query is a latency regression. No classical component in the platform has this property", + "3. Non-determinism (D12): run the same article twice and the answers differ; sometimes an answer is garbage -- a score for a company not in the portfolio, a negative headline read as positive", + "Wired synchronously, the component has none of the three things Part I said such a component needs: no queue to absorb its latency and outages, no port behind which a test can substitute a deterministic fake, no measurement point where the cost and quality of every call are observable" + ], + "elements": [ + "numbered list \\footnotesize, dimension codes in bold; subtitle marker line" + ], + "minutes": 3, + "notes": "Deck 3's AI Lens (D3, D10, D12; queue/port/measurement point) is marked on-slide as the source; the case is that box made concrete." + }, + { + "no": 23, + "deck_section": "Axis B -- Component Types", + "title": "Five failures on schedule (2/2): drift, injection, diagnosis", + "kind": "case", + "script_ref": "§42.1 items 4-5 and closing paragraph (part5_ai_dimension.tex 257-261)", + "content": [ + "4. Drift (D7): the provider ships a new model version or deprecates the old one -- GA models carry deprecation windows of the order of six months -- and the component's behaviour changes without any local action: no commit, no deployment, no reviewable diff. The feature's behaviour is now co-owned by a third party", + "5. Injection (D6): the news article is untrusted input read by a component that cannot reliably separate instructions from data -- a crafted 'article' can carry instructions to the model; the feature has quietly opened an attack surface that no classical threat model in the platform covers (the attack surface in depth: §42.6, next week)", + "Diagnosis (bold): nothing on this list is a bug in the model, and nothing on it is fixed by a better prompt -- every failure is a property of the wiring: a non-deterministic, fallible, latency-heavy, per-call-priced component was integrated as if it were deterministic, reliable, fast, and free", + "The rest of the section generalises: the component taxonomy -> why containment, not mere integration (SE4AI classics) -> the reference architecture that re-wires the call correctly -> the test instrument for a component without exact assertions (eval harness)" + ], + "elements": [ + "numbered list continued (4, 5), then a bold diagnosis line and a roadmap line" + ], + "minutes": 3, + "notes": "The diagnosis sentence is the thesis of Axis B; give it its own visual weight." + }, + { + "no": 24, + "deck_section": "Axis B -- Component Types", + "title": "The three component types -- one species, three profiles", + "kind": "definition", + "script_ref": "§42.2 intro + definitionbox 'AI runtime component' (part5_ai_dimension.tex 265-269)", + "content": [ + "The sentiment call is one instance of a species: for the first time, production systems contain building blocks that are non-deterministic, fallible, latency-heavy, priced per call, and capable of changing behaviour without any local action -- through model updates, data drift, or provider deprecation", + "Thesis, prepared by Assumption A6: such components change no principle of software engineering but shift the weights in the quality attribute space -- and thereby the pattern choice; loose coupling, asynchronous integration, explicit contracts, and observability migrate from 'nice to have' to mandatory", + "Industry speaks of compound AI systems (deck 6, C10) for exactly this reason: state-of-the-art results increasingly come from systems composed of models, retrievers, validators, and deterministic services rather than a single model call", + "Definition [AI runtime component]: a component of the delivered system whose output is produced by a learned or search-based model rather than by explicitly programmed logic. Three types with systematically different engineering profiles: (a) LLM components for analysis, extraction, and generation over unstructured input; (b) classical ML components for classification and regression; (c) optimisation components (LP/MIP and constraint solvers, metaheuristics)", + "The types differ exactly on the dimensions this theory measures -- determinism, latency, cost model, dominant risk, explainability -- and therefore demand different integration forms" + ], + "elements": [ + "definitionbox[AI runtime component] (lines 267-269), \\footnotesize" + ], + "minutes": 3, + "notes": "Three bullets above the definition box; keep the definition box the visual centre." + }, + { + "no": 25, + "deck_section": "Axis B -- Component Types", + "title": "The three AI component types and their profiles", + "kind": "table", + "script_ref": "§42.2 tab:aicomponents (part5_ai_dimension.tex 271-288)", + "content": [ + "Columns: Dimension | (a) LLM analysis / generation | (b) ML classification / regression | (c) Optimisation (LP/MIP/CP)", + "Row Determinism | non-deterministic (even at T=0 only 'mostly') | deterministic after training | reproducible at fixed seed/threads/limit; variance in practice", + "Row Latency | seconds (1--60+) | milliseconds possible | seconds to hours; anytime behaviour", + "Row Cost model | per token/call (operating expenditure) | training expensive, inference cheap | compute + solver licence", + "Row Dominant risk | hallucination, prompt injection, provider drift/deprecation | data/concept drift, training/serving skew | modelling errors, runtime explosion", + "Row Explainability | low (generated justifications are themselves model output) | medium (feature importance) | high -- provable: optimality gap, duals, IIS", + "Row Integration form | gateway + async + cache | serving endpoint + MLOps pipeline | job queue / batch worker", + "Caption sense: each column implies a different integration form -- which is why 'add AI' is never a single architectural decision" + ], + "elements": [ + "6-row scriptsize booktabs table with p{2.0cm}p{3.5cm}p{3.3cm}p{3.5cm} (12.3 cm) from tab:aicomponents lines 276-287; 'high -- provable' in bold" + ], + "minutes": 3, + "notes": "Read column-wise. Speaker guidance: (a) is the sentiment call and the AdvisorAgent's insights, (c) is your Optimization service; type (b) has no instance in the project -- the script says only that it belongs in every advisory platform (the exercise sheet's Performance/Risk/Optimization services are deterministic, project_exercise.tex 181-187)." + }, + { + "no": 26, + "deck_section": "Axis B -- Component Types", + "title": "Type (a): LLM components -- RAG, prompts, structured outputs", + "kind": "content", + "script_ref": "§42.2 paragraph 'Type (a): LLM components' (part5_ai_dimension.tex 290)", + "content": [ + "LLM components turn unstructured input -- documents, e-mails, reports -- into analyses, extractions, or generated text; three engineering building blocks define the type", + "Retrieval-augmented generation (RAG): knowledge is moved out of the model weights into a swappable, versionable, inspectable data component -- updated by re-indexing rather than retraining, with provenance through citable sources", + "RAG is an engineering problem, not a model problem: case-study evidence documents seven recurring failure points (missing content, failed ranking of the relevant documents, extraction and formatting errors, incomplete answers) -- with the sobering observation that RAG robustness evolves in operation rather than being designed in", + "Prompts are configuration artefacts: version-controlled, regression-tested, behaviour-determining like code -- exactly the configuration-debt territory Sculley et al. mapped", + "Structured outputs: since 2024 provider APIs can enforce, via constrained decoding, that outputs conform to a developer-supplied JSON schema -- syntactic correctness guaranteed; semantic correctness remains to be verified (reference architecture, eval harness)", + "Lifecycle risk is the provider: GA models carry deprecation windows of the order of six months, shorter windows observed -- a hard-coded model name is a ticking dependency: an architectural statement, not an operational one" + ], + "elements": [ + "\\footnotesize bullets, six; the three building blocks (RAG, prompts, structured outputs) in bold" + ], + "minutes": 3, + "notes": "The AdvisorAgent's insights are type (a); the ontology guard answers 'semantic correctness remains to be verified'." + }, + { + "no": 27, + "deck_section": "Axis B -- Component Types", + "title": "Types (b) and (c) -- perishable models, heavy solvers", + "kind": "content", + "script_ref": "§42.2 paragraphs 'Type (b): classical ML components' and 'Type (c): optimisation components' (part5_ai_dimension.tex 292-294)", + "content": [ + "(b) Self-trained models (scoring, churn, fraud, forecasting) bring the full nine-stage workflow -- model requirements and data collection through training, evaluation, deployment, monitoring -- with dense feedback loops; characteristic problems: training/serving skew (divergent data preparation, one of the most frequent production failure sources) and data/concept drift (sudden, gradual, incremental, recurring)", + "(b) A deployed model is a perishable good -- monitoring and retraining are operating requirements, not options; tooling: feature stores with consistent online/offline views, model registries versioning model, data, code, and configuration together, the MLOps discipline (maturity ladder: §43, next week)", + "(c) Routinely overlooked in the SE4AI literature but belongs in every advisory platform: LP/MIP solvers, constraint programming (CP-SAT dominated recent MiniZinc Challenges, a complete gold-medal sweep in 2024), stochastic metaheuristics -- the profile inverts the LLM's: deterministic but heavy. Reproducible at fixed seed, thread count, time limit (run-to-run variability in practice); runtimes seconds to hours, often anytime behaviour -> asynchronous integration: job queue, status polling, callback; never a synchronous call in a web request path", + "(c) Compensating strength: provable explainability -- optimality gap, dual values and shadow prices, and on infeasibility an irreducible infeasible subset (IIS): a minimal set of contradictory constraints as the explanation. In regulated domains the load-bearing argument for the project's division of labour: hard, auditable decisions belong to the solver and the deterministic services, not to the LLM" + ], + "elements": [ + "\\footnotesize bullets, four (each at most three lines); 'a deployed model is a perishable good' and 'deterministic but heavy' in bold" + ], + "minutes": 3, + "notes": "Split off from the former type-(b)/(c) keypoint frame; the keypoint now has its own frame (28)." + }, + { + "no": 28, + "deck_section": "Axis B -- Component Types", + "title": "Key concept: adding AI is a per-component matching problem", + "kind": "keyconcept", + "script_ref": "§42.2 keypoint (part5_ai_dimension.tex 296-298)", + "content": [ + "One-line strip above the box (\\footnotesize, dimension codes in bold): the three types differ exactly where the twelve dimensions measure -- determinism (D4) | latency (D3) | cost (D10) | auditability (D6) | testability (D9)", + "Key Concept: 'We are adding AI' is therefore never one decision -- it is a per-component matching problem, answered with the same profile logic as everything else in this module. One rule spans all three types: contain the component behind an explicit boundary; never scatter it through the domain", + "\\scriptsize codegray aside beneath the box (project transfer): the sentiment call and the AdvisorAgent's insights are type (a); the Optimization service is type (c); type (b) has no instance in the project" + ], + "elements": [ + "keypoint box (lines 296-298), verbatim-condensed, \\footnotesize; one-line dimension strip above; one-line project aside beneath" + ], + "minutes": 2, + "notes": "Author note: the script maps determinism to D4 here (line 297) while §42.1 (line 256) and the deck's frame 22 map non-determinism to D12, and tab:dimensions labels D4 'Consistency & transactional integrity' -- a script-internal tension; keep the script wording for fidelity and say in speech that the twelve-dimension table places non-determinism under D12. The project aside is a transfer, not script text; it stays outside the box." + }, + { + "no": 29, + "deck_section": "Axis B -- Containment", + "title": "Why containment: the SE4AI classics -- hidden debt and CACE", + "kind": "definition", + "script_ref": "§42.3 (part5_ai_dimension.tex 303-309)", + "content": [ + "Two foundational results explain why AI components need architectural containment rather than mere integration", + "Sculley et al. (2015) transferred the technical-debt metaphor to ML systems. Observation 1: only a small fraction of a real-world ML system is ML code -- the famous figure shows the model as a small black box amid large blocks of configuration, data collection, feature extraction, data verification, serving infrastructure, and monitoring. The system around the model is the actual engineering task -- precisely this module's perspective", + "Observation 2: ML components resist modularisation", + "Definition [CACE -- Changing Anything Changes Everything]: ML models entangle their input signals -- no feature is ever truly independent, so a change to one feature distribution, hyperparameter, or upstream data source changes the behaviour of the whole model. Architectural consequence: boundary erosion -- the strong abstraction boundaries on which modular design relies are systematically undermined by ML components", + "Alongside the paper's system anti-patterns: glue code, pipeline jungles, dead experimental code paths, configuration debt, hidden feedback loops, undeclared consumers of model outputs" + ], + "elements": [ + "definitionbox[CACE -- Changing Anything Changes Everything] (lines 307-309), \\footnotesize" + ], + "minutes": 3, + "notes": "Do not reproduce the Sculley figure (not in the script's assigned lines as a figure); describe it in words as the script does." + }, + { + "no": 30, + "deck_section": "Axis B -- Containment", + "title": "Three differences, 28 tests -- AI Lens: Parnas meets CACE", + "kind": "ailens", + "script_ref": "§42.3 Amershi paragraph + ailinse 'Parnas meets CACE' (part5_ai_dimension.tex 311-315)", + "content": [ + "Amershi et al. (Microsoft product teams) -- three fundamental differences between ML-based and classical development: (1) data discovery, versioning, labelling, and schema management are harder than and qualitatively different from code management, with no Git-equivalent of comparable maturity; (2) model customisation and reuse demand combined SE and ML competence; (3) AI components are harder to modularise than software modules -- entangled (CACE), non-monotonic error behaviour, poorly predictable interactions between models", + "Operational counterpart -- the ML Test Score: a rubric of 28 concrete tests and monitoring requirements across data, model development, infrastructure, and monitoring, distilled from Google production experience: production readiness made measurable, and a ready-made checklist for the course project", + "AI Lens [Parnas meets CACE]: Part II established Maxim 4 -- domain-oriented partitioning around anticipated change is the strongest single predictor of evolvability. CACE identifies a component class in which change anticipation fails inside the component: everything co-varies with everything. The resolution is not to abandon Parnas but to apply him one level up: if the component cannot be decomposed, the decomposition happens around it -- the module boundary goes where the entanglement stops, at the component's contract. That is the entire intellectual content of the gateway pattern, and it is sixty-year-old advice" + ], + "elements": [ + "ailinse[Parnas meets CACE] (lines 313-315), condensed, \\footnotesize" + ], + "minutes": 3, + "notes": "The AI Lens is the conceptual hinge to the reference architecture: say 'the boundary goes where the entanglement stops' before showing the figure." + }, + { + "no": 31, + "deck_section": "Axis B -- Containment", + "title": "The reference architecture -- the sentiment call, re-wired", + "kind": "diagram", + "script_ref": "§42.4 intro + fig:llmgateway (part5_ai_dimension.tex 320-385)", + "content": [ + "One \\scriptsize line above the figure: not new machinery but old machinery applied more strictly -- the correct re-wiring of the sentiment call: behind a typed port into the gateway (curing drift, containing injection); non-interactive volume onto the queue (curing latency, buying batch pricing); every call across one measurement point (cost and quality observable)", + "Figure, left: Deterministic domain core -- decides and books; no provider SDK imports -- 'typed port' arrow into the gateway", + "Figure, centre: LLM gateway (anti-corruption layer) with five internals -- prompt assembly + schema validation; model router (cheap -> expensive cascade); semantic cache; timeouts, circuit breakers, fallback chains; cost telemetry per request / feature / tenant", + "Figure, right: Provider A (models m1, m2); Provider B (fallback); Local model (last-resort degradation)", + "Figure, bottom: async job queue (batching, backpressure, retries) -> worker pool (bounded concurrency) -> gateway, fed by the core's 'non-interactive jobs'; every output -> Ontology / schema guard (entity resolution, domain axioms, citation check) -> 'validated result or rejection' back to the core; Eval harness (CI gate: prompts, models, providers) dashed to guard and gateway", + "Caption-like line beneath: this is the topology your AdvisorAgent and sub-agents are wired into this week -- ADR-011 (deck 3) made structural" + ], + "elements": [ + "tikz fig:llmgateway (lines 322-385) redrawn for 16:9: core bankblue, gateway frame aiviolet with five violet sub-boxes in a 2+3 grid, providers grey, queue/workers bankgreen, guard bankred, eval harness teal; \\resizebox to 0.95\\textwidth; one \\scriptsize line above and one beneath" + ], + "minutes": 7, + "notes": "Give the figure the whole frame; seven minutes for the walk-through (the 3 minutes freed by the kompakt merges of frames 15 and 19 are reinvested here). Walk in the order of the script's intro sentence (line 320): typed port into the gateway (curing drift, containing injection -- failures 4 and 5 of frame 23) -> the five gateway internals -> providers and fallback -> non-interactive volume onto the queue and worker pool (curing latency, buying batch pricing -- failure 1 of frame 22) -> every output through the ontology/schema guard -> the eval harness as CI gate; every call crosses one measurement point (cost and quality observable -- failures 2 and 3 of frame 22). Consider revealing the four stages with \\onslide overlays (port, queue, guard, harness) so the re-wiring of the sentiment call is visible step by step; no content beyond the figure's labels and line 320 is added. Verify with pdftoppm that the 2+3 grid fits beside the providers." + }, + { + "no": 32, + "deck_section": "Axis B -- Containment", + "title": "The elements justified (1/4): gateway, deterministic core", + "kind": "content", + "script_ref": "§42.4 itemize items 1-2 (part5_ai_dimension.tex 388-389)", + "content": [ + "Anti-corruption layer / LLM gateway: from domain-driven design -- a translation layer that prevents a foreign system's model from corrupting one's own. Applied to LLMs: no domain code speaks to a provider API", + "A facade owns the provider SDKs, prompt construction, schema validation, retry logic, model selection, and cost telemetry; the domain sees only a typed interface: \\texttt{analyse\\_report(document) -> RiskAssessment}", + "Provider deprecation becomes an adapter task instead of a crisis; the facade is mockable in every test; as an industry pattern the gateway has consolidated into its own infrastructure layer -- the AI counterpart of the API gateway. In hexagonal terms the LLM is an adapter on a port -- the strongest single reason HX gains weight in the AI era", + "Deterministic core, probabilistic edge: everything deterministically computable -- validation, aggregation, key-figure computation, authorisation, persistence, booking -- stays deterministic code; the LLM handles only what determinism cannot (language understanding, extraction from unstructured text, formulation). Keep the non-deterministic core as small as possible and push it to the edge", + "Centred, highlighted design rule (the line that is graded): LLM agents propose; deterministic services decide and book" + ], + "elements": [ + "\\footnotesize bullets, four, each at most three lines; the typed signature in \\texttt; the design rule as a highlighted centred line (bankblue, bold italic)" + ], + "minutes": 3, + "notes": "Split off from the previous version's combined gateway/core/queue frame. The HX D12 '$++$' remark (the structural fact behind the $++$ in HX's D12 row) goes to speech or a one-line codegray aside." + }, + { + "no": 33, + "deck_section": "Axis B -- Containment", + "title": "The elements justified (2/4): queue, semantic cache", + "kind": "content", + "script_ref": "§42.4 itemize items 3-4 (part5_ai_dimension.tex 390-391)", + "content": [ + "Asynchronous integration: seconds-scale latency, rate limits, and outage risk put AI calls behind a queue wherever the domain allows -- the caller enqueues a job, a worker pool calls the model at a controlled degree of parallelism, results return by event or callback", + "The queue buys backpressure instead of overload, retries without blocking users, smoothing of rate limits, and natural batching points: provider batch APIs process non-urgent volume at roughly 50\\,\\% discount within processing windows up to 24 hours (figure from deck 6 -- here placed where it lives: in the gateway)", + "Axis B's direct coupling to EDA and PF (Part II) -- exactly the mechanisms their D12 rows priced at $++$", + "Semantic caching: instead of exact-match keys, requests are compared by embedding similarity, so semantically equivalent queries hit the cache", + "The engineering point not to miss: a false-positive cache hit is a correctness risk, not a performance blemish -- the similarity threshold is a quality/cost regulator and belongs in the eval harness, not in a config file nobody reviews" + ], + "elements": [ + "\\footnotesize bullets, five, each at most three lines; 'correctness risk' in bold" + ], + "minutes": 3, + "notes": "Link the queue to Lecture 11's resilience exercise and to deck 5/6 EDA/PF in speech." + }, + { + "no": 34, + "deck_section": "Axis B -- Containment", + "title": "The elements justified (3/4): model routing -- AI Lens", + "kind": "ailens", + "script_ref": "§42.4 item 5 + ailinse 'Model routing is a classical tactic in new clothes' (part5_ai_dimension.tex 392, 397-399)", + "content": [ + "Model routing: model choice per request is one of the largest cost levers in the stack -- cascades that start with the cheapest model and escalate only on insufficient answer quality report up to 98\\,\\% cost reduction at comparable quality; learned routers trained on human preference data cut cost by more than a factor of two without quality loss, generalising to unseen model pairs (figures from deck 6 -- here placed where they live: in the gateway)", + "AI Lens [Model routing is a classical tactic in new clothes]: Part I defined tactics as the atomic units of architectural design. Routing traffic across a cheap and an expensive resource depending on demand is the ancient resource-arbitration tactic -- the FrugalGPT cascade is its token-economics incarnation. Note where it lives in the figure: in the gateway, as infrastructure, invisible to domain logic. A tactic that leaks into the domain layer stops being a tactic and starts being coupling" + ], + "elements": [ + "one \\footnotesize bullet; ailinse[Model routing is a classical tactic in new clothes] (lines 397-399), condensed, \\footnotesize" + ], + "minutes": 3, + "notes": "Deck 6's C10 frame already quoted the 98\\,\\% and factor-two figures as cost-model facts; the inline marker says so." + }, + { + "no": 35, + "deck_section": "Axis B -- Containment", + "title": "The elements justified (4/4): stability, ontology as contract", + "kind": "content", + "script_ref": "§42.4 itemize items 6-7 (part5_ai_dimension.tex 393-394)", + "content": [ + "Stability patterns transfer directly from the classical catalogue: timeouts (an LLM call without one blocks a thread for minutes); retries with exponential backoff -- only for idempotent calls and with cost awareness, since every retry burns tokens; circuit breakers per provider and model; fallback chains -- alternative model -> alternative provider -> cached or rule-based answer -> honest degradation ('analysis currently unavailable'); bulkheads separating interactive from batch quotas", + "Only the failure semantics are new: a semantically unusable answer -- schema violation, suspected hallucination -- must trigger the error path exactly like an HTTP 500", + "Ontology and schema as contract -- the most effective systematic hallucination defence is layered: (1) structured outputs enforce syntax; (2) every extracted entity (account number, ISIN, customer name, key figure) is resolved against the deterministic data store -- unresolvable references are rejected, not passed on; (3) domain axioms hold as invariants -- sums add up, weights lie in [0,1], cited passages exist in the source document; (4) grounding via RAG makes citations mandatory", + "The schema becomes a contract in the design-by-contract sense, and the gateway is the contract checker -- this is the ontology guard your project activates on all insights this week" + ], + "elements": [ + "\\footnotesize bullets, four; the four-layer defence as an inline numbered sequence" + ], + "minutes": 3, + "notes": "Link to Lecture 11's resilience exercise (timeouts, retries, breakers, fallback on all external calls) in speech: the LLM provider is one more external call with token cost attached." + }, + { + "no": 36, + "deck_section": "Axis B -- Containment", + "title": "The eval harness -- definition and course thesis", + "kind": "definition", + "script_ref": "§42.5 intro, definitionbox 'Eval harness', keypoint 'The course thesis on testing AI' (part5_ai_dimension.tex 404-408, 419-421)", + "content": [ + "Non-determinism breaks the classical test idiom: \\texttt{assert expected == actual} presupposes that equal inputs produce equal outputs. When that assumption falls, correctness must be redefined statistically -- 'correct in at least 95\\,\\% of the evaluation cases' -- and the team needs a test artefact of the first rank to carry that definition", + "Definition [Eval harness]: a versioned suite of test cases, scoring logic, and statistical thresholds for a non-deterministic component, executed in the CI/CD pipeline like a test suite. It gates every prompt change, model update, and provider migration. Its thresholds are the response measures of the AI-related quality attribute scenarios (Assumption A4), and its pass rate is a fitness function in the measurement contract of Part IV", + "Key Concept -- the course thesis on testing AI: the eval harness is to AI components what the test pyramid is to deterministic code -- the artefact that converts 'it seems to work' into a falsifiable, continuously executed claim. Without it, every model migration is a blind flight -- and given provider deprecation windows of months, migrations are not hypothetical. Statistical acceptance replaces exact assertion; the thresholds are architecture decisions and belong in the measurement contract" + ], + "elements": [ + "definitionbox[Eval harness] (lines 406-408), \\footnotesize", + "keypoint box 'The course thesis on testing AI' (lines 419-421), condensed, \\footnotesize" + ], + "minutes": 3, + "notes": "Two boxes plus one intro bullet -- fits at \\footnotesize. Recall deck 6: 'evals are the operative meaning of testability' (D9 = H for C10)." + }, + { + "no": 37, + "deck_section": "Axis B -- Containment", + "title": "Four complementary evaluation strategies make a complete harness", + "kind": "content", + "script_ref": "§42.5 enumerate (part5_ai_dimension.tex 410-417)", + "content": [ + "1. Regression against labelled references: a curated golden set of input/expectation pairs from the domain, scored with task-appropriate metrics (exact match or F1 on extracted fields, rubric scores for generated text); every prompt change, model update, and migration runs against this suite -- the direct counterpart of the regression test", + "2. LLM-as-judge: strong LLM judges agree with human preference judgements in over 80\\,\\% of cases -- the level of human--human agreement -- a scalable scoring instrument; biases to control for: position, verbosity, self-enhancement, weak reasoning grading. Conclusion: the judge is a measurement instrument that must itself be calibrated against human labels -- the judge needs its own eval", + "3. Domain axioms and property-based testing: instead of exact expected values, the harness checks properties that must hold for all valid outputs -- schema validity, referential integrity against the ontology, metamorphic relations (a paraphrased input must yield a semantically equivalent output), domain monotonicities; axioms catch failure classes that no finite golden set covers", + "4. Online evaluation: sampled human review, user feedback signals, drift monitoring of the eval metrics in production -- the LLM counterpart of model monitoring in the ML workflow" + ], + "elements": [ + "numbered list \\footnotesize; strategy names in bold; 'the judge needs its own eval' in italic" + ], + "minutes": 4, + "notes": "Speaker notes carry the bias definitions (position bias: candidate order sways the verdict; verbosity bias: longer answers preferred; self-enhancement: judges favour their own outputs) and the countermeasures (position swapping, reference-guided judging), script line 414." + }, + { + "no": 38, + "deck_section": "Axis B -- Containment", + "title": "Example: an eval harness for the portfolio platform", + "kind": "content", + "script_ref": "§42.5 examplebox + lst:evalharness (part5_ai_dimension.tex 423-453)", + "content": [ + "One \\footnotesize line above the listing: thresholds = response measures -- mean F1 >= 0.92 on the golden set | zero axiom violations | judge--human agreement kappa >= 0.70 (Cohen's chance-corrected measure) -- changing any of them is an architecture decision requiring an ADR; note what is absent: no assertion demands an exact output string", + "Listing (stripped to 16 code lines: docstrings, blank lines and the comments that duplicate the bullets dropped): GOLDEN = load_cases(\"evals/portfolio_extraction_v3.jsonl\")", + "def test_extraction_regression(gateway): scores = [f1(gateway.extract(c.report), c.expected) for c in GOLDEN]; assert mean(scores) >= 0.92 # statistical threshold", + "def test_domain_axioms(gateway, ontology): answer = gateway.advise(sample_portfolio()); for pos in answer.positions: assert ontology.resolves(pos.isin), f\"unknown: {pos.isin}\"; total = sum(p.weight for p in answer.positions); assert abs(total - 1.0) < 1e-6; for cit in answer.citations: assert cit.passage in source_text(cit.doc_id)", + "def test_judge_is_calibrated(judge, human_labels): agreement = cohens_kappa(judge.score(GOLDEN), human_labels); assert agreement >= 0.70 # the judge's own eval", + "Caption line: runs in CI on every change to prompts, models, or the gateway, alongside the deterministic test suite" + ], + "elements": [ + "examplebox header (line 424) condensed to one \\footnotesize line", + "lstlisting lst:evalharness (lines 426-452) stripped to ~16 lines in a grey tcolorbox, \\scriptsize\\ttfamily, Python; one \\scriptsize caption line beneath" + ], + "minutes": 3, + "notes": "Verify the footline with pdftoppm before finalising. The docstrings ('Statistical acceptance, not exact assertion'; 'Properties that hold for ALL valid outputs'; 'LLM-as-judge is an instrument: calibrate it') are spoken per function. Point to week 13: this harness becomes the CI gate." + }, + { + "no": 39, + "deck_section": "Closing", + "title": "This week's exercise: AdvisorAgent + sub-agents behind the gateway", + "kind": "exercise", + "script_ref": "Exercise sheet M5 taskbox (project_exercise.tex 432-442) and hintbox (451-464); semester plan week 12 row (line 23); §41.9 projektbox (part5_ai_dimension.tex 236-238)", + "content": [ + "Coaching slot (1 lesson). Milestone M5 -- Multi-Agent Orchestration, Evaluation, and Hardening (weeks 12--13)", + "Mandatory this week: the AdvisorAgent orchestrates 2--3 sub-agents through contracts -- every LLM call through the gateway port (ADR-011); no provider SDK import in domain code", + "Ontology guard active on all insights: entity resolution against the deterministic store, domain axioms, citation check -- unresolvable references are rejected, not passed on", + "LLM agents propose; deterministic services decide and book -- keep the deterministic core free of LLM calls (the line that is graded)", + "Closing line: Axis A discipline as on the project-link slide; week 13 turns the harness into a CI gate" + ], + "elements": [ + "projektbox with four items plus one closing line, \\footnotesize" + ], + "minutes": 3, + "notes": "Items 5-7 of the previous version replaced by one closing line: the Axis A discipline is frame 20, the week-13 tasks and distinction work are frame 41." + }, + { + "no": 40, + "deck_section": "Closing", + "title": "Summary", + "kind": "summary", + "script_ref": "Frames 4-38", + "content": [ + "1. A6 falls due -- two axes, one method: Axis A changes how systems are built, Axis B what they contain; independent, kept apart, analysed with the apparatus of Parts I--IV", + "2. Copilot +55.8\\,\\% vs METR --19\\,\\%: neither wrong -- five moderators reconcile the record; the perception gap (+24 / --19 / +20) is the didactic core", + "3. System level: DORA -- throughput positive, instability persists, AI is an amplifier; GitClear -- duplication 4x, refactoring signature collapsed; adoption up, trust down", + "4. Verification bottleneck, Maxim 7: generation cheap, specification/verification/architecture binding; D7 and D9 gain weight in every profile", + "5. Axis A compact: documentation as control interface, fitness functions as operating licence, who merges answers; patterns examinable, products expire; MCP = ports-and-adapters", + "6. Axis B: the sentiment call fails on D3, D10, D12, D7, D6 -- properties of the wiring; three types = a per-component matching problem; CACE -> decompose around the component", + "7. Reference architecture: typed port -> gateway (routing, cache, stability, cost telemetry) -> queue -> ontology guard; eval harness = statistical acceptance, thresholds in the measurement contract" + ], + "elements": [ + "\\footnotesize numbered list, 7 points, each at most 1.5 lines, as deck 6 lines 660-671" + ], + "minutes": 2, + "notes": "Seven points trimmed to one-and-a-half lines each." + }, + { + "no": 41, + "deck_section": "Closing", + "title": "Next week", + "kind": "nextweek", + "script_ref": "Task brief 'Next lecture' line; semester plan week 13 row (line 24); exercise sheet M5 week 13 (project_exercise.tex 436-440)", + "content": [ + "Left column: \\textcolor{bankblue}{\\textbf{Lecture 13 -- Part V closes: security and law, the matrix shift, the eighth pattern, synthesis}}", + "Left column \\small bullet: OWASP LLM Top 10 and prompt injection; the EU AI Act as hard constraint", + "Left column \\small bullet: How AI shifts the matrix: the C10 row cell by cell, D12 across the seven patterns, which cells shift, MLOps maturity", + "Left column \\small bullet: Agent orchestration as the emergent eighth pattern: topologies, the economics of autonomy, capability-profile sketch", + "Left column \\small bullet: Synthesis: one theory, five parts; exam orientation", + "Right column -- Reading: this week Part V, Sections 40--41, 42.1--42.5; ahead Part V, Sections 42.6--42.7, 43--45", + "Right column -- Exercise / deliverable: coaching; eval harness as CI gate; cost/latency observability; hardening; distinction work; \\textbf{milestone: eval harness in CI + guard + cost observability}" + ], + "elements": [ + "two columns 0.55/0.42 as deck 6 lines 673-698: bold bankblue lecture line + four \\small bullets left; Reading and Exercise/deliverable right; \\footnotesize if the topic bullets wrap beyond the column" + ], + "minutes": 1, + "notes": "Verbatim in substance from the task brief; layout as decks 1-6." + }, + { + "no": 42, + "deck_section": "Closing", + "title": "Closing slide", + "kind": "content", + "script_ref": "Deck skeleton; closing block copied from deck 6 (AISE502_Vorlesung_6_Folien.tex 703-706)", + "content": [ + "\\FHGRClosingPage[][{\\color{white}\\parbox{0.9\\paperwidth}{\\centering Thank you!\\\\[3ex] {\\normalsize\\mdseries Dr.\\ Florian Herzog\\\\[0.9ex] Fachhochschule Graub\\\"unden, Chur\\\\[2.4ex] {\\small AISE502 -- AI in Software Engineering II}}}}]" + ], + "elements": [ + "FHGR closing page" + ], + "minutes": 0, + "notes": "Copy deck 6 lines 703-706 verbatim (parbox and white text -- trap 1/2 from the deck memory)." + } + ], + "exercise_frame": { + "title": "This week's exercise: AdvisorAgent + sub-agents behind the gateway", + "content": [ + "Coaching slot (1 lesson). Milestone M5 -- Multi-Agent Orchestration, Evaluation, and Hardening (weeks 12--13)", + "Mandatory this week: the AdvisorAgent orchestrates 2--3 sub-agents through contracts -- every LLM call through the gateway port (ADR-011); no provider SDK import in domain code", + "Ontology guard active on all insights: entity resolution against the deterministic store, domain axioms, citation check -- unresolvable references are rejected, not passed on", + "LLM agents propose; deterministic services decide and book -- keep the deterministic core free of LLM calls (the line that is graded)", + "Closing line: Axis A discipline as on the project-link slide; week 13 turns the harness into a CI gate" + ] + }, + "summary": [ + "A6 falls due -- two axes, one method: Axis A changes how systems are built, Axis B what they contain; independent, kept apart, analysed with the apparatus of Parts I--IV", + "Copilot +55.8\\,\\% vs METR --19\\,\\%: neither wrong -- five moderators reconcile the record; the perception gap (+24 / --19 / +20) is the didactic core", + "System level: DORA -- throughput positive, instability persists, AI is an amplifier; GitClear -- duplication 4x, refactoring signature collapsed; adoption up, trust down", + "Verification bottleneck, Maxim 7: generation cheap, specification/verification/architecture binding; D7 and D9 gain weight in every profile", + "Axis A compact: documentation as control interface, fitness functions as operating licence, who merges answers; patterns examinable, products expire; MCP = ports-and-adapters", + "Axis B: the sentiment call fails on D3, D10, D12, D7, D6 -- properties of the wiring; three types = a per-component matching problem; CACE -> decompose around the component", + "Reference architecture: typed port -> gateway (routing, cache, stability, cost telemetry) -> queue -> ontology guard; eval harness = statistical acceptance, thresholds in the measurement contract" + ], + "next_week": { + "lecture_line": "Lecture 13 -- Part V closes: security and law, the matrix shift, the eighth pattern, synthesis", + "topics": [ + "OWASP LLM Top 10 and prompt injection; the EU AI Act as hard constraint", + "How AI shifts the matrix: the C10 row cell by cell, D12 across the seven patterns, which cells shift, MLOps maturity", + "Agent orchestration as the emergent eighth pattern: topologies, the economics of autonomy, capability-profile sketch", + "Synthesis: one theory, five parts; exam orientation" + ], + "reading": [ + "this week: Part V, Sections 40--41, 42.1--42.5", + "ahead: Part V, Sections 42.6--42.7, 43--45" + ], + "exercise": [ + "coaching; eval harness as CI gate; cost/latency observability; hardening; distinction work", + "milestone: eval harness in CI + guard + cost observability" + ] + }, + "script_boxes_used": [ + { + "box": "definitionbox 'The two axes of the AI dimension'", + "location": "§40, part5_ai_dimension.tex 14-21", + "used_in_frame": "5 The two axes of the AI dimension" + }, + { + "box": "tikz fig:twoaxes", + "location": "§40, part5_ai_dimension.tex 25-48", + "used_in_frame": "5 The two axes of the AI dimension (right column)" + }, + { + "box": "keypoint 'Two axes, one method'", + "location": "§40, part5_ai_dimension.tex 50-52", + "used_in_frame": "5 The two axes of the AI dimension (one-line keypoint at the bottom)" + }, + { + "box": "table tab:aievidence", + "location": "§41.3, part5_ai_dimension.tex 79-103", + "used_in_frame": "8 The full empirical record, 2023--2025" + }, + { + "box": "table tab:moderators", + "location": "§41.4, part5_ai_dimension.tex 118-134", + "used_in_frame": "11 Reconciling the divergence: five moderator variables" + }, + { + "box": "thinkbox (moderators, perception gap)", + "location": "§41.4, part5_ai_dimension.tex 136-138", + "used_in_frame": "12 Discussion: which setting is yours?" + }, + { + "box": "keypoint 'Maxim 7'", + "location": "§41.5, part5_ai_dimension.tex 153-155", + "used_in_frame": "14 Three consequences bind Axis A into the fit theory -- Maxim 7" + }, + { + "box": "lstlisting lst:agentsmd", + "location": "§41.6, part5_ai_dimension.tex 170-188", + "used_in_frame": "15 Architecture documentation as a control interface for agents (listing beneath the text)" + }, + { + "box": "ailinse 'MCP is ports-and-adapters at ecosystem scale'", + "location": "§41.8, part5_ai_dimension.tex 217-219", + "used_in_frame": "17 The tool landscape, soberly -- and the AI Lens on MCP" + }, + { + "box": "hinweisbox (state of early 2026, expiry date)", + "location": "§41.8, part5_ai_dimension.tex 223-225", + "used_in_frame": "18 Benchmarks and their limits -- an expiry date on this section" + }, + { + "box": "projektbox (Axis A governs how you build)", + "location": "§41.9, part5_ai_dimension.tex 236-238", + "used_in_frame": "20 Project link: Axis A governs how you build the platform (referenced by the exercise frame 39)" + }, + { + "box": "definitionbox 'AI runtime component'", + "location": "§42.2, part5_ai_dimension.tex 267-269", + "used_in_frame": "24 The three component types -- one species, three profiles" + }, + { + "box": "table tab:aicomponents", + "location": "§42.2, part5_ai_dimension.tex 271-288", + "used_in_frame": "25 The three AI component types and their profiles" + }, + { + "box": "keypoint (three types differ where the twelve dimensions measure; contain behind a boundary)", + "location": "§42.2, part5_ai_dimension.tex 296-298", + "used_in_frame": "28 Key concept: adding AI is a per-component matching problem" + }, + { + "box": "definitionbox 'CACE -- Changing Anything Changes Everything'", + "location": "§42.3, part5_ai_dimension.tex 307-309", + "used_in_frame": "29 Why containment: the SE4AI classics -- hidden debt and CACE" + }, + { + "box": "ailinse 'Parnas meets CACE'", + "location": "§42.3, part5_ai_dimension.tex 313-315", + "used_in_frame": "30 Three differences, 28 tests -- AI Lens: Parnas meets CACE" + }, + { + "box": "tikz fig:llmgateway (reference architecture)", + "location": "§42.4, part5_ai_dimension.tex 322-385", + "used_in_frame": "31 The reference architecture -- the sentiment call, re-wired" + }, + { + "box": "ailinse 'Model routing is a classical tactic in new clothes'", + "location": "§42.4, part5_ai_dimension.tex 397-399", + "used_in_frame": "34 The elements justified (3/4): model routing -- AI Lens" + }, + { + "box": "definitionbox 'Eval harness'", + "location": "§42.5, part5_ai_dimension.tex 406-408", + "used_in_frame": "36 The eval harness -- definition and course thesis" + }, + { + "box": "keypoint 'The course thesis on testing AI'", + "location": "§42.5, part5_ai_dimension.tex 419-421", + "used_in_frame": "36 The eval harness -- definition and course thesis" + }, + { + "box": "examplebox 'An eval harness for the portfolio platform' + lstlisting lst:evalharness", + "location": "§42.5, part5_ai_dimension.tex 423-453", + "used_in_frame": "38 Example: an eval harness for the portfolio platform" + } + ], + "script_boxes_dropped": [], + "open_issues": [ + "Minute budget: content frames 4-38 sum to 117 min; with agenda 1, recap 3, exercise 3, summary 2, next week 1 the total is 127 min for 135 -- the 8-min remainder is the reserve for the break. The former frame 9 was dropped, frames 19+20 and 22+23 of the previous version merged, and the freed time reinvested in the split frames 27/28 and 32/33; the cross-lecture review then merged frames 15+16 (§41.6 text + AGENTS.md listing) and 20+21 (risks 1/2 + 2/2) to honour 'Guardrails (kompakt)' -- §41.6-41.9 now take 6 frames / 16 min instead of 8 frames / 23 min -- and reinvested 3 of the 4 freed minutes in the reference-architecture walk-through (frame 31, now 7 min); the fourth minute went to the reserve.", + "Density fallbacks that would raise the frame count (all still within the 40-46 band): frame 8 (tab:aievidence, seven rows at scriptsize with 12.4 cm columns) may need a (1/2)/(2/2) split -> 43 frames; frame 15 (merged §41.6 text + 14-line AGENTS.md listing at scriptsize) may need the corollary bullet moved to speech or, failing that, a re-split into text frame + listing frame -> 43 frames; frame 17 (merged landscape + MCP ailinse, six bullets plus box) may need the MCP adoption chronology moved to speech; frame 19 (merged risks, five footnotesize bullets) may need \\scriptsize.", + "fig:llmgateway is drawn for \\textwidth portrait with five vertically stacked gateway sub-boxes; on a 16:9 frame (frame 31) it needs a redraw (gateway internals in a 2+3 grid, providers to the right, queue/guard/eval below) and a pdftoppm check; the walk-through now has 7 minutes and may use \\onslide overlays for the four re-wiring stages; no content beyond the figure's labels and the §42.4 intro sentence is added.", + "lst:evalharness is 26 lines in the script; the deck shows ~16 code lines (docstrings, blank lines and duplicating comments dropped) so that the one-line threshold header and the caption line fit; verify the footline with pdftoppm.", + "Script-internal tension flagged for the author (frame 28 note): the §42.2 keypoint (line 297) maps determinism to D4, while §42.1 (line 256) maps non-determinism to D12 and tab:dimensions labels D4 'Consistency & transactional integrity'. The deck keeps the script wording; if the script is corrected, render the strip as 'determinism (D12)'.", + "Two transfer lines are not script text and are placed outside the boxes as \\scriptsize codegray asides: the project-transfer question under the discussion thinkbox (frame 12) and the 'which project component is which type' line under the keypoint (frame 28; type (b) has no instance in the project, since the exercise sheet defines Performance/Risk/Optimization as deterministic services). Drop both if strict verbatim is required.", + "The \\measured macro exists only in deck 2's preamble (line 114); frame 6 does not use it. If the author wants the grey 'Measured / Instrument' box, copy the macro definition into this deck's preamble.", + "Failure 5 (injection, D6) in §42.1 cites OWASP; the deck names only the mechanism and defers OWASP/prompt-injection content to Lecture 13 (§42.6) as instructed -- the reference-architecture frame's 'containing injection' phrase is the script's own wording and is kept.", + "The script's §40 roadmap names §43 (matrix reading) and §44 (agent pattern); the deck cites them only as 'next week'; likewise the MLOps maturity ladder (§43) mentioned in the type (b) paragraph is pointed to, not taught.", + "There is no script thinkbox for §42.1-42.5, so the deck has a single Discussion frame (Axis A, frame 12). A second discussion on Axis B would have to be authored outside the script; not done here.", + "Deck 6's C10 frames already quoted the 50\\,\\% batch discount, the 98\\,\\% cascade figure and the factor-two router figure; frames 33-34 repeat them with an inline '(figures from deck 6 -- here placed where they live: in the gateway)' marker -- intentional repetition, not new content.", + "Frame titles are capped at ~68 characters; the exercise-frame title (66 characters, the reviewer's wording) and frame 37's title (64) are the longest -- check in the FHGR header at compile time and shorten frame 37 to 'Four evaluation strategies make a complete harness' if it wraps. The merged risks frame 19 was shortened to 63 characters ('automation bias' -> 'bias' in the title only; the bullet keeps 'Automation bias')." + ], + "total_frames": 42 +} \ No newline at end of file diff --git a/Folien/Planung_7-13_json/L13.json b/Folien/Planung_7-13_json/L13.json new file mode 100644 index 0000000..3d05784 --- /dev/null +++ b/Folien/Planung_7-13_json/L13.json @@ -0,0 +1,937 @@ +{ + "lecture": 13, + "week": 13, + "lessons": 3, + "title": "Lecture 13: Threats, the Shifted Matrix, Agent Orchestration -- and Synthesis", + "script_reference": "Script: Part V, Sections 42.6--42.7, 43--45", + "agenda": [ + "Axis B completed: a new threat class (OWASP LLM Top 10, prompt injection) and regulation as a hard constraint (EU AI Act)", + "How AI shifts the matrix: the C10 row cell by cell, the D12 column, five shifted cells, MLOps maturity -- A6 restated", + "Agent orchestration -- the emergent eighth pattern: the advisor workflow, agent vs.\\ workflow, topologies and their classical analogues", + "The economics of autonomy and the default rule; a capability-profile sketch", + "Synthesis: one theory, five parts -- Maxim 8 and the symmetry of the two axes", + "Exam orientation: the facts, the six learning objectives applied to the five parts, what to have at hand", + "This week's exercise: M5 closes -- eval harness in CI, guard, cost observability; threat model incl. prompt injection via news and basic hardening; optional distinction work (semester plan: Kür)" + ], + "recap": [ + "Part V is the framework's stress test on two axes: \\textbf{Axis A} -- AI in the process (agentic tools, verification bottleneck, guardrails); \\textbf{Axis B} -- AI in the product (non-deterministic, fallible, per-call-priced runtime components)", + "Lecture 12 (§40--41, §42.1--42.5): Axis-A evidence -- two contradictory RCTs and their resolution; the \\textbf{verification bottleneck} (Maxim 7: generation is cheap, verification and architecture are binding -- D7 and D9 gain weight); Axis A compact: documentation as control interface, fitness functions as operating licence, who merges answers; Axis B: sentiment call wired wrong and right; three component types; SE4AI classics; reference architecture (\\textbf{LLM gateway} as single measurement point); eval-harness basics", + "Already computed three times: the C10 verdict -- mini-match (Lecture 3), profile and real systems (Lecture 6), the full row with its cell rationales (Lecture 10; the $7 \\times 10$ matrix itself was read in Lecture 7)", + "Filed in advance (Lecture 6 outlook): agent orchestration is a \\emph{composition pattern} reusing the catalogue's topologies; workflows before agents ($15\\times$ token finding) -- today that claim is paid out in full", + "Today completes Axis B (threats, regulation), shows how AI \\emph{shifts} the matrix, develops the eighth pattern with its profile -- and closes the module: synthesis (Maxim 8) and exam orientation. This is the last lecture of new material; week 14: one lesson synthesis and exam hints, three lessons final presentations, architecture defence and peer reviews (A3, M6)" + ], + "frames": [ + { + "no": 1, + "deck_section": "Title", + "title": "AISE502: AI in Software Engineering II -- Lecture 13: Threats, the Shifted Matrix, Agent Orchestration -- and Synthesis", + "kind": "content", + "script_ref": "Title slide; subtitle line: Script: Part V, Sections 42.6--42.7, 43--45", + "content": [ + "\\FHGRTitlePage with subtitle as in deck 6: \\subtitle{Lecture 13: Threats, the Shifted Matrix, Agent Orchestration -- and Synthesis\\\\[0.4ex]{\\small Script: Part V, Sections 42.6--42.7, 43--45}}" + ], + "elements": [ + "FHGR title page (theme)" + ], + "minutes": 0, + "notes": "Identical metadata block to deck 6 (author, shortname, fullname). Subtitle shortened to one clause (~70 characters) so it does not wrap to three lines on the FHGR title page." + }, + { + "no": 2, + "deck_section": "Agenda", + "title": "Agenda", + "kind": "agenda", + "script_ref": "Semester plan row week 13 (Semesterplan_AISE502_HS26.md line 24)", + "content": [ + "1. Axis B completed: a new threat class -- OWASP LLM Top 10, prompt injection; regulation as a hard constraint -- the EU AI Act", + "2. How AI shifts the matrix: the C10 row cell by cell; D12 across the seven patterns; five shifted cells; MLOps maturity; A6 restated", + "3. Agent orchestration -- the emergent eighth pattern: the advisor workflow; agent vs.\\ workflow; topologies and classical analogues", + "4. The economics of autonomy and the default rule; a capability-profile sketch", + "5. Synthesis: one theory, five parts -- Maxim 8; one discipline at two binding sites", + "6. Exam orientation", + "7. This week's exercise: \\textbf{M5 closes} -- eval harness in CI, guard, cost observability; threat model incl.\\ prompt injection via news $+$ basic hardening; optional distinction work (K\\\"ur)" + ], + "elements": [ + "\\small enumerate with \\itemsep 1pt, as in deck 6" + ], + "minutes": 1 + }, + { + "no": 3, + "deck_section": "Agenda", + "title": "Recap: where we are", + "kind": "recap", + "script_ref": "Deck 12 (§40--41, §42.1--42.5 per task description; L12 plan summary; semester plan row 12); Maxim 7 and the verification bottleneck: part5_ai_dimension.tex 142-154 (line 142: 'code generation became cheap; specification, verification, and architecture became the binding constraints'; line 148: D7 and D9 gain weight in every requirements profile; lines 149-150: documentation as control interface, fitness functions as operating licence; line 234: 'the person who merges code answers for it'); deck 6 outlook frame (AISE502_Vorlesung_6_Folien.tex 498-521); deck 3/6/10 C10 computations; semester plan rows 7, 10, 14", + "content": [ + "Part V is the framework's stress test on two axes: \\textbf{Axis A} -- AI in the process; \\textbf{Axis B} -- AI in the product (components that are non-deterministic, fallible, latency-heavy, priced per call)", + "Lecture 12 (§40--41, §42.1--42.5): Axis-A evidence -- two contradictory RCTs and their resolution; the \\textbf{verification bottleneck} (Maxim 7: generation is cheap, verification and architecture are binding -- D7 and D9 gain weight); Axis A compact: documentation as control interface, fitness functions as operating licence, who merges answers; Axis B: sentiment call wired wrong and right; three component types; SE4AI classics; reference architecture (\\textbf{LLM gateway} as single measurement point); eval-harness basics", + "The C10 verdict has been computed three times: mini-match (L, MM, MS -- Lecture 3), profile and real systems (Lecture 6), the full row with its cell rationales (Lecture 10; the $7 \\times 10$ matrix itself was read in Lecture 7)", + "Lecture 6 filed the outlook: agent orchestration is a \\emph{composition pattern} reusing the catalogue's topologies -- workflows before agents ($15\\times$ tokens). Today that claim is paid out", + "Today: Axis B completed (threats, regulation) $\\to$ how AI \\emph{shifts} the matrix $\\to$ the eighth pattern with a profile sketch $\\to$ synthesis and exam orientation. \\textbf{The last lecture of new material}; week 14: one lesson synthesis and exam hints, three lessons final presentations, architecture defence and peer reviews (A3, M6)" + ], + "elements": [ + "\\footnotesize itemize; one-line running map below the bullets: 'tenth class (done) -- twelfth dimension (done) -- shifted cells (today) -- one composition pattern (today)' -- the four absorption forms of §43.4 closing paragraph (line 556); frame 9 refers back to this map" + ], + "minutes": 3, + "notes": "Emitted between Agenda and the first \\section, as in decks 2, 3, 5 -- no \\section{Recap}. Do not re-teach the gateway figure; name it only. The week-14 wording follows the semester plan row 14 ('1 L Synthese + 3 L Präsentationen'), deck 1's 'semester at a glance' row 14 and the exercise sheet. Bullet 2 now names Maxim 7 (the verification bottleneck) and the Axis-A compact block, because frame 33 ('one discipline at two binding sites') and Maxim 8 build directly on Maxim 7; it must stay within four lines at \\footnotesize -- if it overflows, drop 'two contradictory' and the parenthetical '(§40--41, §42.1--42.5)' before touching the Maxim-7 clause." + }, + { + "no": 4, + "deck_section": "Axis B Completed -- Threats and Regulation", + "title": "A new threat class -- OWASP Top 10 for LLM Applications (1/2)", + "kind": "table", + "script_ref": "§42.6 (part5_ai_dimension.tex 455-481)", + "content": [ + "\\emph{\\textcolor{bankblue}{AI components add an attack surface that classical threat models do not cover.}} (first sentence of §42.6, verbatim, line 458)", + "The OWASP Top 10 for LLM Applications 2025 codifies it; the script pairs each risk with its \\textbf{architectural} counter-measure -- deliberately, because the defence is \\emph{structural, not model-internal}", + "Table rows LLM01--LLM05: LLM01 Prompt injection (direct and indirect) -- defence in depth: privilege separation, output validation, human-in-the-loop for sensitive actions", + "LLM02 Sensitive information disclosure -- data minimisation in prompts; output filtering at the gateway", + "LLM03 Supply chain -- vetting of models, weights, and dependencies; registry discipline", + "LLM04 Data and model poisoning -- data governance and provenance for training/index data", + "LLM05 Improper output handling -- treat output as untrusted input: schema validation, encoding, ontology guard" + ], + "elements": [ + "Table (footnotesize, booktabs, p{1.2cm}p{4.2cm}p{7.2cm}): ID | Risk | Architectural counter-measure -- rows LLM01--LLM05 from tab:owasp, lines 460-481" + ], + "minutes": 4, + "notes": "Split the 10-row table into two frames (5 rows each) so the counter-measure column keeps its full wording. §42.6 has no italic leading question in the script; the opener is the section's declarative first sentence verbatim. Speaker question (not on the slide): 'where does the defence live, if not in the model?' -- the table answers it row by row. The remark that most counter-measures are elements of the Lecture-12 gateway figure belongs to the footer of frame 5 only." + }, + { + "no": 5, + "deck_section": "Axis B Completed -- Threats and Regulation", + "title": "A new threat class -- OWASP Top 10 for LLM Applications (2/2)", + "kind": "table", + "script_ref": "§42.6, tab:owasp (part5_ai_dimension.tex 460-481)", + "content": [ + "LLM06 Excessive agency -- least-privilege tool design; deterministic services own irreversible actions", + "LLM07 System prompt leakage -- no secrets or authorisation logic in prompts", + "LLM08 Vector and embedding weaknesses -- access control and tenant isolation on the retrieval index", + "LLM09 Misinformation -- grounding with mandatory citations; domain-axiom checks", + "LLM10 Unbounded consumption -- rate limits, token budgets, cost circuit breakers per tenant", + "Footer line (\\footnotesize): \\emph{most counter-measures are elements of the gateway architecture of Lecture 12} (caption of tab:owasp, line 462)" + ], + "elements": [ + "Table (footnotesize, booktabs, same column widths as 1/2): rows LLM06--LLM10 from tab:owasp, lines 460-481; one-line footer" + ], + "minutes": 3, + "notes": "Point out that three of the four defence elements of the next frame carry OWASP IDs (LLM06, LLM05, LLM10). Project link (verbal): this table is the checklist for this week's threat model." + }, + { + "no": 6, + "deck_section": "Axis B Completed -- Threats and Regulation", + "title": "Prompt injection -- why the model cannot solve it", + "kind": "keyconcept", + "script_ref": "§42.6 hinweisbox (part5_ai_dimension.tex 483-485)", + "content": [ + "\\textbf{Important Note (hinweisbox, condensed):} prompt injection is not fully solvable inside the model, because LLMs process instructions and data in the \\emph{same channel}", + "Any document, e-mail, or web page the system reads can carry instructions (``ignore your previous rules and \\dots'') -- and no reliable in-model separator exists", + "The defence is therefore \\textbf{defence in depth at the system level}: least-privilege tools (LLM06), output validation (LLM05), human approval for consequential actions, consumption limits (LLM10)", + "This is the security-flavoured restatement of the section's design rule: \\textbf{the architecture, not the model, is the trust boundary}", + "For the course project, concretely: no LLM output may reach the booking path without passing the \\textbf{ontology guard}; no agent tool may perform an \\textbf{irreversible action}" + ], + "elements": [ + "hinweisbox 'Important Note' with the condensed text (lines 483-485); the project consequence as the last line inside the box (it is part of the hinweisbox)" + ], + "minutes": 3, + "notes": "Connect to deck 6 'C10 -- the binding scenarios' footer (defence in depth is constitutive) without re-teaching it. Keep the frame to the hinweisbox plus nothing else." + }, + { + "no": 7, + "deck_section": "Axis B Completed -- Threats and Regulation", + "title": "Regulation as a hard constraint: the EU AI Act", + "kind": "table", + "script_ref": "§42.7 (part5_ai_dimension.tex 487-490)", + "content": [ + "Lead-in: regulation closes the quality-attribute loop with legal force -- \\textbf{Regulation (EU) 2024/1689}, the AI Act, entered into force on 1 August 2024; a risk-based approach with four classes:", + "Left table (Class | Examples / duties): \\textbf{Unacceptable risk} | prohibited practices, e.g.\\ social scoring", + "\\textbf{High risk} | Annex III use cases: creditworthiness assessment, employment, critical infrastructure -- duties: risk management, data governance, documentation, logging, oversight, accuracy/robustness/cybersecurity", + "\\textbf{Limited risk} | transparency duties: labelling AI interaction and generated content", + "\\textbf{Minimal risk} | --", + "Right table (Date | What applies): 2 Feb 2025 -- prohibitions; AI-literacy duties $\\cdot$ 2 Aug 2025 -- governance; GPAI duties $\\cdot$ 2 Aug 2026 -- general applicability incl.\\ Annex III high-risk $\\cdot$ 2 Aug 2027 -- high-risk AI in regulated products" + ], + "elements": [ + "Two-column layout (0.55 / 0.42): left = 4-row \\scriptsize table 'Class | Examples / duties' from line 490; right = 4-row \\scriptsize timetable 'Date | What applies', one line per row, from line 490" + ], + "minutes": 4, + "notes": "The script gives 'minimal risk' without a gloss -- print it without one; the lecturer may say 'no specific duties' as own knowledge. Spoken, not on the slide: the 2 Aug 2026 general-applicability date has passed by the time of this lecture." + }, + { + "no": 8, + "deck_section": "Axis B Completed -- Threats and Regulation", + "title": "AI Act obligations -- K(a), not weights", + "kind": "table", + "script_ref": "§42.7 (part5_ai_dimension.tex 492)", + "content": [ + "For this theory the AI Act has a precise, limited role: its obligations are \\textbf{quality attributes with legal force} that enter the requirements profile as \\textbf{hard constraints K(a), not as weights} -- Part I: constraints are knock-out filters, never averaged away", + "A finance-related advisory platform -- class C10, particularly with any \\emph{creditworthiness} bearing -- can fall into the \\textbf{high-risk} class", + "Then logging of agent steps, technical documentation, human oversight, and demonstrated robustness stop being engineering preferences and become \\textbf{conditions of legal operation}", + "Table: \\textbf{logging} | gateway telemetry $+$ audit journal $\\cdot$ \\textbf{human oversight} | human-in-the-loop interfaces at the determinism boundary $\\cdot$ \\textbf{robustness} | fallback chains $+$ eval harness", + "\\textbf{Key Concept (one line):} compliance, correctly designed, is not a parallel work stream -- it is the same architecture, documented" + ], + "elements": [ + "Three short bullets (\\footnotesize); 3-row \\footnotesize table 'Obligation | Architectural element it lands on' from line 492; one-line keypoint" + ], + "minutes": 3, + "notes": "Tie back to deck 6 C10 profile row 'Constraints K(a): EU AI Act 2024/1689 (logging, oversight; potentially high-risk); GDPR' -- this frame explains why it sits in K(a) and not in the weights. The landing points are elements of fig:llmgateway (Lecture 12) -- name the figure, do not reprint it." + }, + { + "no": 9, + "deck_section": "How AI Shifts the Matrix", + "title": "How AI shifts the matrix", + "kind": "content", + "script_ref": "§43 intro (part5_ai_dimension.tex 497-500)", + "content": [ + "\\emph{\\textcolor{bankblue}{You have computed the C10 verdict three times -- what were those computations doing to the rest of the matrix?}}", + "The verdict itself needs no fourth derivation -- the three computations of the recap (Lectures 3, 6, 10)", + "Two of the four absorption forms on the recap's map -- the \\textbf{tenth class} and the \\textbf{twelfth dimension} -- are exactly the artefacts those computations used", + "This section supplies the generalisation in three steps: (i) the \\emph{supply-side} reading of the row you own; (ii) the full \\textbf{D12 column} it exercised; (iii) the \\textbf{cells that moved} -- cell by cell, with stated and measurable reasons", + "Then: when the pipeline promise is real (MLOps maturity) -- and A6 restated as a falsifiable claim" + ], + "elements": [ + "Leading question in italics (bankblue) as in decks 4-6; a small three-step roadmap (i)-(iii)" + ], + "minutes": 2, + "notes": "Section opener; the computation list is not repeated here -- point at the recap's map (frame 3)." + }, + { + "no": 10, + "deck_section": "How AI Shifts the Matrix", + "title": "The C10 row -- which D12 mechanism each cell exercises", + "kind": "table", + "script_ref": "§43.1 (part5_ai_dimension.tex 502-507)", + "content": [ + "Opener: start from the row you own (tab:fit-c10, Lecture 10) -- the one reading the three computations used but never stated in one place: \\emph{which D12 mechanism each cell exercises}", + "Table: MM, HX | $++$ | \\textbf{boundary and port}: a CI-verifiable module boundary and an anti-corruption adapter on a port contain a fallible, entangled component", + "EDA, PF | $+$ | \\textbf{queue}: asynchronous absorption of latency, rate limits, and outages; pipeline-shaped ingestion and evals", + "L | $-$ | none of the three -- no queue, no port, no measurement point", + "MS | $\\circ$ | seconds-scale, fallible calls in synchronous chains (the missing queue)", + "SL | $\\circ$ | minutes-long LLM and solver work against platform timeout ceilings", + "\\textbf{Key Concept (recommendation, Part IV and ADR-007):} a hexagonal modular monolith plus pipelines and an orchestrated agent workflow, with EDA as the secondary job/audit spine -- governed by token and latency budgets and the determinism boundary: \\emph{agents propose; deterministic services decide and book}" + ], + "elements": [ + "5-row \\footnotesize table 'Cells | Fit | D12 mechanism exercised', p{1.6cm}cp{9.6cm}, from lines 505 (mechanisms) with the Fit ratings of tab:fit-c10 (part4_fit.tex 439-445: L $-$, MM $++$, HX $++$, MS $\\circ$, EDA $+$, PF $+$, SL $\\circ$); recommendation from line 507 alone in a keypoint below the table" + ], + "minutes": 4, + "notes": "Only opener + table + keypoint -- the bullets of the earlier draft duplicated the table rows. The ratings of the capped cells (L, MS, SL) are not restated in §43.1 ('capped'); they are taken from tab:fit-c10, taught in Lecture 10, so that the Fit column follows the rating convention of decks 4-6 instead of mixing math ratings with the word 'capped'." + }, + { + "no": 11, + "deck_section": "How AI Shifts the Matrix", + "title": "D12 across the seven patterns", + "kind": "table", + "script_ref": "§43.2, tab:d12row (part5_ai_dimension.tex 509-532)", + "content": [ + "Intro line: the D12 row of the Lecture-6 consolidated table, now with tactic-level rationales -- D12 (AI integrability) measures whether the pattern naturally provides \\textbf{the queue, the port, and the measurement point} a slow, fallible, per-call-priced component requires", + "L -- Layered $\\circ$: technical layers give the non-deterministic component no boundary, no queue, and no measurement point of its own", + "MM -- Modular monolith $+$: a dedicated AI module with a hard, CI-verifiable interface contains the component cheaply", + "HX -- Hexagonal $++$: the LLM is an adapter on a port -- swappable, mockable, contract-guarded; the ACL discipline structurally built in", + "MS -- Microservices $\\circ$: per-service isolation helps; synchronous chains through seconds-scale calls hurt -- net neutral", + "EDA -- Event-driven $++$: queues absorb exactly what LLMs are worst at -- latency, rate limits, outages; natural batching points", + "PF -- Pipes-and-filters $++$: ingestion, training, and eval pipelines are pipes-and-filters by construction", + "SL -- Serverless $\\circ$: event-glue around batch AI APIs fits; platform timeout ceilings collide with minutes-long LLM/solver runs" + ], + "elements": [ + "7-row \\scriptsize table, \\renewcommand{\\arraystretch}{0.8}, tabular{@{}p{2.6cm}cp{8.4cm}@{}} 'Pattern | D12 | Rationale', from tab:d12row lines 514-532" + ], + "minutes": 4, + "notes": "This is the D12 row of deck 6's consolidated table, now with tactic-level rationales -- say so in the intro line only, do not re-show the whole table." + }, + { + "no": 12, + "deck_section": "How AI Shifts the Matrix", + "title": "Which existing cells shift, and why (1/2)", + "kind": "content", + "script_ref": "§43.3 (part5_ai_dimension.tex 534-542)", + "content": [ + "Beyond the new row and column, AI as a runtime component moves \\emph{existing} evaluations in stated directions -- all five visible in the D12 ratings, each carrying a measurable reason", + "\\textbf{1. Asynchronous patterns gain (EDA, PF $\\uparrow$).} Queues and pipelines absorb what LLMs are worst at -- latency, rate limits, outage -- and ingestion and eval pipelines are pipes-and-filters by construction", + "\\textbf{2. Hexagonal gains most (HX $\\uparrow$).} The ACL/port discipline is exactly what the CACE problem demands; Assumption A1's cost-of-change criterion bites hardest at \\emph{model replacement}; testing against deterministic fakes is the only way to keep the deterministic 95\\,\\% of the system deterministic", + "\\textbf{3. Synchronous distributed chains lose (MS $\\downarrow$ where LLM calls sit in the request path).} Seconds-scale latency and per-hop failure probability multiply along the chain; without constitutive stability patterns this is a cascade design" + ], + "elements": [ + "Numbered list 1-3 (\\footnotesize), each movement in bold with its arrow; from lines 537-542" + ], + "minutes": 4, + "notes": "Ask the class to name the tactic behind each movement before revealing it (keypoint of frame 13 demands exactly that)." + }, + { + "no": 13, + "deck_section": "How AI Shifts the Matrix", + "title": "Which existing cells shift, and why (2/2)", + "kind": "keyconcept", + "script_ref": "§43.3 + keypoint (part5_ai_dimension.tex 543-549)", + "content": [ + "\\textbf{4. Serverless is conditional (SL $\\sim$).} Platform timeout ceilings against minutes-long LLM and solver runs cap it; event-glue around batch APIs remains a fit", + "\\textbf{5. A cost dimension becomes load-bearing everywhere.} Cost per request, feature, and tenant is a runtime quality attribute with no counterpart in classical profiles; it belongs in the gateway and in CI budgets", + "Routing across cheap and expensive models is the new incarnation of a classical resource-arbitration tactic: \\textbf{cascades} up to $\\sim$98\\,\\% cost reduction at comparable quality; \\textbf{learned routers} more than $2\\times$ cheaper without quality loss", + "\\textbf{Key Concept:} the matrix does not get \\emph{rewritten} by AI; it gets \\emph{shifted} -- in five stated directions, for five stated and measurable reasons", + "A student who can name, for any cell movement, the quality-attribute mechanism behind it (which tactic the pattern bundles or impedes for a slow, fallible, per-call-priced component) has understood both Part IV and Part V" + ], + "elements": [ + "Numbered list 4-5 (continuing, lines 543-544), then keypoint box from lines 547-549 (condensed)" + ], + "minutes": 4, + "notes": "The keypoint is exam-relevant: it states precisely what 'understood' means for Parts IV-V. It is quoted again on frame 37." + }, + { + "no": 14, + "deck_section": "How AI Shifts the Matrix", + "title": "MLOps maturity: the three-level ladder", + "kind": "table", + "script_ref": "§43.4 (part5_ai_dimension.tex 551-554)", + "content": [ + "For type-(b) components the PF cells' promise (the D12 $++$) is realised only at sufficient process maturity -- the canonical three-level ladder:", + "\\textbf{Level 0} | manual, script-driven, interactive; data science and operations separated; releases rare, no CI/CD, minimal monitoring -- \\emph{the documented reality of many teams} | model handed ``over the fence'' as an artefact", + "\\textbf{Level 1} | automated ML pipeline with continuous training; automated data and model validation, triggers, metadata store, feature store | \\emph{the pipeline, not the model, is the deployment artefact}", + "\\textbf{Level 2} | CI/CD automation of the pipeline components themselves | fast, reliable experiment-to-production cycles", + "Footer (\\scriptsize, grey): nine consolidated MLOps principles -- CI/CD automation, workflow orchestration, reproducibility, versioning of data/model/code, collaboration, continuous training and evaluation, metadata tracking, monitoring, feedback loops" + ], + "elements": [ + "3-row \\scriptsize table 'Level | Characteristics | Key trait', one-line cells, from line 554; the nine principles as one \\scriptsize grey footer line (or speaker notes if the frame is tight)" + ], + "minutes": 3, + "notes": "The third column is headed 'Key trait', not 'Deployment artefact', because the script states a deployment artefact for Levels 0 and 1 only. The PF promise is the D12 row's $++$ (§43.2); in the C10 row PF rates $+$." + }, + { + "no": 15, + "deck_section": "How AI Shifts the Matrix", + "title": "When the pipeline promise is real: the fit-theoretical reading", + "kind": "keyconcept", + "script_ref": "§43.4 (part5_ai_dimension.tex 554)", + "content": [ + "\\textbf{Fit-theoretical reading:} the MLOps level describes how much of \\textbf{D9} (testability/deployability) and \\textbf{D12} the organisation can actually \\emph{cash in}", + "A Level-0 team holding a $++$ pattern rating realises little of it", + "This is the \\textbf{Axis-B echo of DORA's Axis-A finding} (Lecture 12): \\emph{guardrail maturity, not tool adoption}, converts potential into performance" + ], + "elements": [ + "Two-line keypoint-style line for the D9/D12 cash-in sentence; the Level-0 example and the DORA echo as two short bullets (\\footnotesize); from line 554" + ], + "minutes": 2, + "notes": "Short frame, deliberately: this sentence is the exam-relevant one of §43.4 and must not be the sixth element of a crowded slide. The DORA finding was taught on Axis A in Lecture 12 -- name it, do not re-teach it." + }, + { + "no": 16, + "deck_section": "How AI Shifts the Matrix", + "title": "Assumption A6 restated as a falsifiable claim", + "kind": "keyconcept", + "script_ref": "§43.4 closing + keypoint (part5_ai_dimension.tex 556-560)", + "content": [ + "Three of the four absorption forms are now on the table, each \\emph{computed rather than asserted}: the tenth class, the twelfth dimension, the shifted cells -- the fourth, the emergent composition pattern, follows next", + "\\textbf{Key Concept -- A6 restated:} runtime AI components are non-deterministic, fallible, latency-heavy, per-call-priced, and subject to drift and vendor deprecation", + "They \\emph{stretch} existing quality dimensions by orders of magnitude and add sub-attributes: token cost per request, eval pass rate, provider deprecation risk, prompt-injection resistance", + "What does \\emph{not} change is the method: scenarios with response measures, tactics, trade-off analysis, ADRs, fitness functions", + "The theory absorbs AI -- as a tenth application class, a twelfth profile dimension, shifted cell values, and one emergent composition pattern -- instead of being reinvented for it", + "The quality gate is carried by the one new test-artefact class A6 named from the start: the \\textbf{eval harness}" + ], + "elements": [ + "keypoint box from lines 558-560 (condensed); above it the one-sentence status line from line 556" + ], + "minutes": 3, + "notes": "Bridge frame: closes §43 and opens §44 -- 'the assumption is now a falsifiable claim with evidence attached'." + }, + { + "no": 17, + "deck_section": "Agent Orchestration -- The Emergent Eighth Pattern", + "title": "Agent orchestration -- the emergent eighth pattern", + "kind": "content", + "script_ref": "§44 intro (part5_ai_dimension.tex 565-568)", + "content": [ + "\\emph{\\textcolor{bankblue}{``Should I reduce my exposure to European industrials?'' -- no single model call can answer that responsibly, so what structure can?}}", + "The final structural novelty of the AI era is the orchestration of agents", + "As everywhere in this script, \\textbf{the concrete system comes before the catalogue}: first the advisory workflow the course project actually builds, then the name of what it is an instance of", + "Rhythm of this block (the pattern rhythm of decks 4-6, adapted): case $\\to$ what an agent is and is not $\\to$ topologies and classical analogues $\\to$ choosing a topology $\\to$ economics and the default rule $\\to$ capability-profile sketch $\\to$ project link" + ], + "elements": [ + "Leading question in italics (bankblue); short roadmap line" + ], + "minutes": 2 + }, + { + "no": 18, + "deck_section": "Agent Orchestration -- The Emergent Eighth Pattern", + "title": "Case: the course project's advisor workflow", + "kind": "case", + "script_ref": "§44.1 (part5_ai_dimension.tex 570-573)", + "content": [ + "Diagram, full width: \\textbf{Orchestrator} (an LLM call with a fixed system prompt) splits the request into sub-tasks and delegates to three specialists -- \\textbf{Document analyst}, \\textbf{Portfolio quant}, \\textbf{Compliance checker}; the portfolio quant calls \\emph{deterministic analytics services}; the merged answer passes the \\textbf{guard} before reaching user or books; every call passes through the \\textbf{LLM gateway}", + "Footer line 1: orchestrator splits and delegates, then merges the results into one grounded answer", + "Footer line 2: document analyst returns extracted findings from the ingestion corpus \\emph{with citations}; portfolio quant produces exposure and concentration numbers by calling only deterministic analytics services -- \\emph{arithmetic is not a job for a language model}", + "Footer line 3: compliance checker verifies the draft -- every cited passage exists, every entity resolves against the ontology, every mandate constraint holds" + ], + "elements": [ + "tikz diagram drawn from the prose of line 573 (no figure exists in the script), full width in \\resizebox{0.75\\textwidth}{!}{...}: Orchestrator (violet agentbox) fanning out to Document analyst / Portfolio quant / Compliance checker (violet); Portfolio quant with an arrow to 'deterministic analytics services' (green gatebox); a dashed 'LLM gateway' band around all LLM calls; a green 'guard' gate between the merged answer and 'user / books'. Colours as fig:agenttopologies: violet = non-deterministic, green = deterministic. Below: a \\footnotesize footer of at most three lines" + ], + "minutes": 4, + "notes": "Deck-6 topology-frame form (diagram + three-line footer), not a two-column layout. The gateway/guard sentence ('every call flows through the LLM gateway -- routed, cached, budgeted, logged -- and nothing any agent produces reaches the user or the books without passing the guard: agents propose; deterministic services decide and book') opens frame 19. Label nothing the prose does not name." + }, + { + "no": 19, + "deck_section": "Agent Orchestration -- The Emergent Eighth Pattern", + "title": "Strip the labels: a shape you know cell by cell", + "kind": "content", + "script_ref": "§44.1 (part5_ai_dimension.tex 573-575)", + "content": [ + "Opening line: every call by every participant flows through the \\textbf{LLM gateway} -- routed, cached, budgeted, logged -- and nothing any agent produces reaches the user or the books without passing the \\textbf{guard}: \\emph{agents propose; deterministic services decide and book}", + "Now strip the labels: a coordinator decomposing work for specialised workers is the \\textbf{mediator topology of event-driven architecture} (Lecture 5); the fixed retrieve--extract--check sequence inside each specialist is a \\textbf{pipeline} (Lecture 6); peers coordinating over shared context would be the \\textbf{broker topology}", + "The section's deliberately \\emph{deflationary} claim: agent orchestration is \\textbf{not a new architectural style} but a \\textbf{composition pattern for non-deterministic runtime components} that reuses the topologies of the seven patterns you already know -- which is why it can be evaluated with the \\textbf{rating grid you already have}", + "This is the claim the Part II outlook (Lecture 6) filed in advance; this section pays it out -- the full six-row mapping follows on frame 22" + ], + "elements": [ + "Four bullets (\\footnotesize); the deflationary claim as a keypoint-styled line; no mini-table (the six-row table of frame 22 supersedes it)" + ], + "minutes": 3, + "notes": "Trimmed to the gateway/guard rule, the three analogues named in line 575, and the deflationary claim; the mapping table is not pre-empted here." + }, + { + "no": 20, + "deck_section": "Agent Orchestration -- The Emergent Eighth Pattern", + "title": "What an agent is -- and is not", + "kind": "definition", + "script_ref": "§44.2 definitionbox + guidance (part5_ai_dimension.tex 577-584)", + "content": [ + "\\textbf{Definition: Agent; workflow vs.\\ agent} -- an \\emph{agent} is an LLM running in a loop with tools and state: at each iteration the model observes the current state (conversation, tool results, working memory), selects an action (a tool call or an answer), and the loop executes it and feeds the result back -- until a termination condition holds", + "Schematically: \\textbf{agent $=$ loop $+$ tools $+$ state}", + "The load-bearing distinction: a \\textbf{workflow} orchestrates LLM calls and tools along \\emph{predefined code paths} -- deterministic structure, non-deterministic building blocks; an \\textbf{agent} lets the model \\emph{steer its own process and tool use} -- the control flow itself becomes model output", + "Autonomy is therefore not a binary but a \\textbf{dial}, and every notch on it costs latency, tokens, and testability", + "Below the box -- engineering guidance of the source that defined this vocabulary, matching the module's philosophy verbatim: \\textbf{find the simplest solution possible} $\\cdot$ \\textbf{prefer simple, composable patterns over frameworks} $\\cdot$ \\textbf{escalate to agents only when the task genuinely requires open decision paths}", + "Orchestration frameworks that model workflows as \\emph{explicit graphs} make the topology \\textbf{inspectable} -- an architectural virtue for the same reason a C4 diagram is (Lecture 3)" + ], + "elements": [ + "definitionbox[Agent; workflow vs.\\ agent] from lines 580-582 (condensed, with the schematic 'agent = loop + tools + state' as a centred line inside); below it the three guidance rules of line 584 as three bold one-liners and the explicit-graph sentence" + ], + "minutes": 5, + "notes": "Frames 19 and 20 of the earlier draft merged: definitionbox uncrowded (four lines), guidance as three bold one-liners below. Deck 6 outlook stated the workflow/agent distinction in one line; here it gets its full definition. Emphasise 'the control flow itself becomes model output' -- that is what changes testability. The ADR-per-escalation rule is NOT stated here -- it is the §44.4 keypoint and is paid out on frame 25." + }, + { + "no": 21, + "deck_section": "Agent Orchestration -- The Emergent Eighth Pattern", + "title": "Topologies and their classical analogues", + "kind": "table", + "script_ref": "§44.3, tab:agenttopology (part5_ai_dimension.tex 586-608)", + "content": [ + "The Lecture-6 outlook table, now with its third column -- structure and use: every workflow topology maps exactly onto a structure from Part II that you know cell by cell, and every property the classical pattern is known for (and every weakness) \\emph{transfers}", + "Prompt chaining (chain) | Pipes-and-filters (PF) | each call processes the previous output; programmatic gates between stages; fixed decomposition", + "Routing | Routing layer / mediator | a classification step directs inputs to specialised prompts or models; the runtime sibling of model routing", + "Parallelisation (sectioning, voting) | Broker-style fan-out | independent subtasks in parallel, or repeated runs with majority vote", + "Orchestrator--workers (tree/graph) | Mediator EDA | a lead model decomposes the task dynamically and delegates to workers; central workflow control", + "Evaluator--optimizer | Feedback control loop | generator and evaluator model iterate until a quality criterion holds", + "Autonomous multi-agent | Broker topology | peer agents coordinate over shared context; maximal flexibility, minimal central control" + ], + "elements": [ + "6-row \\footnotesize table 'Topology | Classical analogue | Structure and use', p{3.2cm}p{3.0cm}p{6.4cm}, from tab:agenttopology lines 591-608, analogue column in the script's exact wording" + ], + "minutes": 4, + "notes": "Same mapping as the Lecture-6 outlook -- the analogue column is now the script's exact wording (deck 6 said 'dispatch layer' for routing and 'broker fan-out of autonomous quanta' for multi-agent systems; the script says 'Routing layer / mediator' and 'Broker topology' -- mention the two renamed cells verbally), and the third column is new. Say: 'the classical analogue predicts both the strengths and the failure modes' (caption, line 593)." + }, + { + "no": 22, + "deck_section": "Agent Orchestration -- The Emergent Eighth Pattern", + "title": "Four topologies, drawn -- gates in code, judgement in the model", + "kind": "diagram", + "script_ref": "§44.3, fig:agenttopologies (part5_ai_dimension.tex 610-651)", + "content": [ + "Chain $\\hat{=}$ pipes-and-filters: LLM 1 $\\to$ \\textcolor{bankgreen}{gate} $\\to$ LLM 2 $\\to$ LLM 3", + "Orchestrator--workers $\\hat{=}$ mediator EDA: Orchestrator $\\to$ Worker A / Worker B / Worker C", + "Evaluator--optimizer $\\hat{=}$ control loop: Generator $\\rightleftarrows$ Evaluator (feedback)", + "Multi-agent $\\hat{=}$ broker topology: Agent 1, Agent 2, Agent 3 over a shared context / bus", + "Caption: deterministic gates (green) between non-deterministic stages (violet) are the \\textbf{workflow discipline}: \\emph{structure stays in code, judgement stays in the model}" + ], + "elements": [ + "tikz figure redrawn from lines 610-651 with the deck's styles (agentbox violet fill aiviolet!15, gatebox bankgreen!15, rounded corners 3pt, Stealth arrows); wrap in \\resizebox{0.85\\textwidth}{!}{...}; caption line (line 649) in \\footnotesize below" + ], + "minutes": 3, + "notes": "Show the advisor workflow of frame 18 as an instance of the second topology (orchestrator--workers) -- point, don't redraw." + }, + { + "no": 23, + "deck_section": "Agent Orchestration -- The Emergent Eighth Pattern", + "title": "The evaluation logic applies unchanged -- sharpened along three axes", + "kind": "content", + "script_ref": "§44.3 (part5_ai_dimension.tex 653)", + "content": [ + "Because the topologies are the old topologies, the evaluation logic of this theory applies unchanged -- sharpened along exactly three axes:", + "\\textbf{Non-determinism} -- testability is read as \\emph{eval coverage} (the eval harness of Lecture 12)", + "\\textbf{Token economics} -- cost per \\emph{request}, not per infrastructure", + "\\textbf{Fallibility} -- fault tolerance is read as guardrails, evaluator loops, and deterministic fallbacks behind ports", + "Consequence: the choice of topology can be compressed into the same style of decision aid the matrix provides -- next frame" + ], + "elements": [ + "Three axes as three short bold-headed items (\\footnotesize); no dimension numbers on the slide -- the script names the axes, not D-numbers" + ], + "minutes": 2, + "notes": "The mapping of the three axes onto D9, D10, D5 is the lecturer's own and may be spoken, not printed." + }, + { + "no": 24, + "deck_section": "Agent Orchestration -- The Emergent Eighth Pattern", + "title": "Choosing a topology from the task signature", + "kind": "table", + "script_ref": "§44.3, tab:agentchoice (part5_ai_dimension.tex 655-671)", + "content": [ + "Read top-down and \\textbf{stop at the first matching row} -- the ordering encodes ``simplest structure first''", + "Fixed decomposition; every intermediate result verifiable | Prompt chain (workflow) | cheapest and most testable; deterministic gates between stages", + "Heterogeneous input categories with specialised handling | Routing | cheap; the router itself needs its own eval", + "Broad, parallelisable subtasks; breadth-first search | Parallelisation or orchestrator--workers | token cost multiplies with worker count ($\\sim$15$\\times$ class)", + "Output must clear a measurable quality bar | Evaluator--optimizer | latency and cost grow per iteration; needs a reliable evaluator", + "Path genuinely unknown; open-ended tool use | Agent | highest cost and risk; guardrails, budgets, and oversight mandatory", + "Project pointer: your Axis-B ADR must justify your topology \\emph{against this table}" + ], + "elements": [ + "5-row \\footnotesize table 'Task signature | Topology | Cost/risk note', p{4.6cm}p{3.2cm}p{4.8cm}, from tab:agentchoice lines 655-671; one-line project pointer (projektbox, line 715)" + ], + "minutes": 4, + "notes": "Ask: which row does the advisor workflow of frame 18 match? (orchestrator--workers, row 3 -- with the 15x cost class attached)." + }, + { + "no": 25, + "deck_section": "Agent Orchestration -- The Emergent Eighth Pattern", + "title": "The economics of autonomy -- and the default rule", + "kind": "keyconcept", + "script_ref": "§44.4 + keypoint (part5_ai_dimension.tex 673-680)", + "content": [ + "The rigour case for restraint, quantified by the best-documented production account (previewed in the Lecture-6 outlook): Anthropic's multi-agent research system -- an orchestrator--workers design -- beat a single agent by \\textbf{90.2\\,\\%} at roughly \\textbf{15$\\times$ the tokens} of a chat interaction (simple agents $\\sim$4$\\times$); token use alone explains \\textbf{80\\,\\%} of the variance", + "A textbook \\textbf{CBAM decision} in the sense of Part IV: autonomy is bought with cost, latency, and error accumulation -- justified only where the task's utility-response curve clears the price: broad, parallelisable research questions do; a form-filling workflow does not", + "Regulation closes the loop from the other side: the AI Act's logging, documentation, human-oversight, and robustness duties attach to \\emph{exactly the autonomy this section prices}", + "\\textbf{Key Concept -- the default rule for agent architecture:} workflows before agents; the simplest structure first; autonomy only on demonstrated need; every escalation an ADR with a measurement contract. \\emph{An orchestration decision without a token budget and an eval threshold is an opinion -- Maxim 6 applies to agents without modification}" + ], + "elements": [ + "Three bullets (\\footnotesize, the first at two lines), then keypoint box from lines 678-680 with the Maxim-6 sentence inside it, as in the script" + ], + "minutes": 4, + "notes": "The numbers are recognised from deck 6 (the script says so, line 676) -- spend the time on the CBAM reading and the AI Act closure, which are new. This is where the 'dial' of frame 20 is paid out: every notch of autonomy is an escalation, and every escalation an ADR with a measurement contract." + }, + { + "no": 26, + "deck_section": "Agent Orchestration -- The Emergent Eighth Pattern", + "title": "Agent orchestration -- capability-profile sketch", + "kind": "table", + "script_ref": "§44.5, tab:agentprofile (part5_ai_dimension.tex 682-710)", + "content": [ + "Header note: provisional profile (state 2025/26) -- every cell carries its own temporal fitness function", + "D1 Read scalability | $\\circ$ | orchestration state small and replicable; throughput bounded by provider rate limits", + "D2 Write scalability \\& elasticity | $\\circ$ | fan-out cheap in structure, expensive in tokens; sustained volume quota-bound", + "D3 Latency \\& predictability | $--$ | seconds per step, steps multiply along the loop; open-ended loops have no tail bound", + "D4 Consistency \\& integrity | $--$ | non-deterministic by construction; integrity exists only outside, in deterministic validation", + "D5 Availability \\& fault isolation | $-$ | every step adds provider failure modes and error accumulation; evaluator loops and fallbacks mitigate", + "D6 Security \\& auditability | $\\circ$ | step and tool logging natural ($+$), legally required in high-risk uses; injection and excessive agency widen the surface ($-$)", + "D7 Evolvability | $+$ | prompts, tools, models swap behind contracts; framework and model churn claws part back", + "D8 Simplicity \\& time-to-market | $-$ | a chain workflow is genuinely simple; every notch of autonomy is not", + "D9 Testability \\& deployability | $--$ | exhaustive testing impossible; evals with statistical thresholds replace assertions", + "D10 Operating cost efficiency | $--$ | token cost per request orders of magnitude above classical calls; multi-agent $\\sim$15$\\times$ chat", + "D11 Team scaling | $\\circ$ | sub-agent and tool ownership parallelises teams moderately -- the PF filter-ownership analogy", + "D12 AI integrability | $++$ | it \\emph{is} the composition pattern for AI components -- trivially its own best host", + "Status row (in place of the 'Native shape' row of decks 4-6): default hypotheses; re-verified on every model generation" + ], + "elements": [ + "One 12-row \\scriptsize table, \\renewcommand{\\arraystretch}{0.8}, tabular{@{}p{2.9cm}cp{7.8cm}@{}} 'Dimension | Rating | Ground', each Ground condensed to $\\le$ 12 words as deck 6 does for PF/SL, from tab:agentprofile lines 687-710; a 'Status' row instead of 'Native shape'" + ], + "minutes": 5, + "notes": "The eighth profile in the exact form of the seven profiles of decks 4-6 (one 12-row scriptsize table, arraystretch 0.8) -- the rhythm students have seen seven times. The three caveats and the reading follow on frame 27." + }, + { + "no": 27, + "deck_section": "Agent Orchestration -- The Emergent Eighth Pattern", + "title": "Agent orchestration -- reading the sketch", + "kind": "keyconcept", + "script_ref": "§44.5 (part5_ai_dimension.tex 685, 712)", + "content": [ + "Why only a \\emph{sketch} -- three caveats: no Richards--Ford star ratings; no decade of production case studies; every cell is a \\textbf{default hypothesis} in the sense of the theory's own limits discussion -- to be replaced by measurement and \\textbf{re-verified on every model generation}", + "The cells read, as always, ``as the dominant structure of the subsystem it governs'' -- here the \\textbf{AI subsystem}, not the whole platform", + "\\textbf{The reading:} the profile explains at a glance why agent orchestration can never be the dominant structure of a whole platform of class C1--C9 -- it is \\textbf{vetoed by every High weight on D3, D4, D9, or D10} (stage 2 of the three-stage match, Lecture 7)", + "\\textbf{Key Concept:} it is, and remains, an \\textbf{edge pattern} -- hosted behind the ports of a deterministic core, exactly where the C10 recommendation places it" + ], + "elements": [ + "Three bullets (\\footnotesize) from line 685 and line 712; the edge-pattern sentence as a keypoint" + ], + "minutes": 3, + "notes": "Link the veto reading to the three-stage match (stage 2, veto rule): four $--$ cells against Highs -- the veto logic that capped MS for C1 in Lecture 7 (lifted to $\\circ$ only under the documented Monzo condition, part4_fit.tex line 55)." + }, + { + "no": 28, + "deck_section": "Agent Orchestration -- The Emergent Eighth Pattern", + "title": "Project link: Axis B is what you build -- and what you build it as", + "kind": "content", + "script_ref": "§44.5 projektbox (part5_ai_dimension.tex 714-716)", + "content": [ + "\\textbf{Project Link (projektbox):} Axis B is \\emph{what} you build; the advisor workflow -- an orchestrator with two to three specialised sub-agents (document analyst, portfolio quant, compliance checker), all behind the LLM gateway -- is what you build it \\emph{as}", + "The graded Axis-B deliverables are the \\textbf{containment artefacts}:", + "(i) the \\textbf{gateway} with model routing, fallback chain, and per-request \\textbf{cost observability} -- cost per request, per feature, reported on a dashboard and enforced as a CI budget", + "(ii) the \\textbf{ontology guard} -- every extracted entity resolves against the deterministic data store, every cited passage exists, portfolio axioms hold", + "(iii) the \\textbf{eval harness} (Lecture 12 listing) wired as a \\textbf{CI gate}", + "(iv) one \\textbf{ADR} that justifies your chosen orchestration topology against the task-signature table, with its \\textbf{token budget and eval threshold} as the measurement contract", + "\\emph{Sub-agents propose; your deterministic services decide and book.}" + ], + "elements": [ + "projektbox from lines 714-716, items (i)-(iv) as an enumerate inside the box" + ], + "minutes": 3, + "notes": "This is the grading rubric of Axis B in the students' own words -- it feeds the exercise frame (frame 38) and the week-14 defence." + }, + { + "no": 29, + "deck_section": "Synthesis -- One Theory, Five Parts", + "title": "What did AI change? Two temptations, one position", + "kind": "content", + "script_ref": "§45 intro (part5_ai_dimension.tex 721-724)", + "content": [ + "\\emph{\\textcolor{bankblue}{What, in the end, did AI change?}} -- the bet of the opening can now be settled", + "Architecture teaching in the AI era faces two symmetric temptations:", + "\\textbf{Denial} -- generative AI as a passing tool fashion that leaves software engineering untouched: falsified by the adoption data alone (\\textbf{90\\,\\%} of practitioners report using AI at work by 2025)", + "\\textbf{Exceptionalism} -- AI systems as a new discipline with new vocabulary, new roles, new decision logic: rejected on the assembled evidence -- nothing AI does, on either axis, required a decision no ADR can record, a correctness no response measure can capture, or a structure no tactic vocabulary describes", + "Between the temptations lies the position defended since Part I: \\textbf{absorption}" + ], + "elements": [ + "Two columns (Denial | Exceptionalism) with the refutation under each; 'absorption' centred as a keypoint line" + ], + "minutes": 3 + }, + { + "no": 30, + "deck_section": "Synthesis -- One Theory, Five Parts", + "title": "The script read backwards as a single argument (1/2): Parts I--III", + "kind": "content", + "script_ref": "§45 (part5_ai_dimension.tex 726)", + "content": [ + "\\textbf{Part I} established that architecture is the set of significant, hard-to-reverse decisions (\\textbf{A1}), that everything is a trade-off (\\textbf{A2}), that quality attributes -- not features -- drive structure (\\textbf{A3}), and that requirements decide anything only as measurable scenarios (\\textbf{A4}); it fixed the \\textbf{twelve dimensions} on which all later judgements run", + "\\textbf{Part II} turned seven patterns into \\textbf{capability profiles} by explaining every rating through the tactics a pattern bundles or impedes (the consolidated capability table)", + "\\textbf{Part III} turned ten application classes into \\textbf{requirements profiles} -- recurring bundles of architecturally significant requirements with response measures and hard constraints (the requirements table)" + ], + "elements": [ + "Three-row table or three stacked blocks (Part | What it established | Artefact): I | A1-A4 | twelve dimensions; II | tactics $\\to$ ratings | capability table; III | ASR bundles + response measures + K | requirements table -- from line 726" + ], + "minutes": 3, + "notes": "Use the deck-1 'pipeline + map of the script' vocabulary; each part's table named exactly as the script does." + }, + { + "no": 31, + "deck_section": "Synthesis -- One Theory, Five Parts", + "title": "The script read backwards as a single argument (2/2): Parts IV--V", + "kind": "content", + "script_ref": "§45 (part5_ai_dimension.tex 726)", + "content": [ + "\\textbf{Part IV} matched them: knock-out screening, veto rule, holistic ordinal reading (the $7 \\times 10$ fit matrix); it insisted that \\textbf{hybrids are the normal case}, that the decision procedure ends in an \\textbf{ADR}, and that every ADR ends in a \\textbf{measurement contract} -- because a decision is a hypothesis tested over the life cycle (\\textbf{A5})", + "\\textbf{Part V} subjected the whole construction to its hardest contemporary stress test -- and the construction held (\\textbf{A6})", + "\\textbf{Axis A} raised the value of the theory's artefacts -- documentation as agent context, fitness functions as operating licence -- rather than obsoleting them", + "\\textbf{Axis B} was absorbed as one class, one dimension, five cell shifts, and one composition pattern whose profile the theory's own grid can express" + ], + "elements": [ + "Continuation of the Part table (IV | three-stage match, hybrids, ADR, measurement contract, A5 | fit matrix; V | stress test held, A6 | Axis A / Axis B outcomes) -- from line 726" + ], + "minutes": 3 + }, + { + "no": 32, + "deck_section": "Synthesis -- One Theory, Five Parts", + "title": "Maxim 8 -- the pipeline of this script in one sentence", + "kind": "keyconcept", + "script_ref": "§45 keypoint (part5_ai_dimension.tex 728-730)", + "content": [ + "\\textbf{Key Concept -- Maxim 8.} The theory absorbs AI: a tenth application class, a twelfth dimension, shifted cells, one emergent composition pattern -- \\emph{same assumptions, same procedure, same contract}", + "The pipeline of this script is one sentence long:", + "\\emph{scenarios with numbers (Part I) meet capability profiles (Part II) and requirements profiles (Part III) in a non-compensatory match (Part IV) whose result is an ADR with a measurement contract -- and nothing about AI, on either axis, changes a single step of it (Part V)}" + ], + "elements": [ + "keypoint box from lines 728-730, the one-sentence pipeline set in italics on its own; optionally a five-box horizontal tikz strip (Part I $\\to$ II $+$ III $\\to$ IV $\\to$ ADR + contract, with Part V as a bracket underneath) redrawn from the sentence" + ], + "minutes": 2, + "notes": "This sentence returns on the exam-orientation frame 37 as the students' map -- say so." + }, + { + "no": 33, + "deck_section": "Synthesis -- One Theory, Five Parts", + "title": "The deepest result: one discipline at two binding sites", + "kind": "content", + "script_ref": "§45 (part5_ai_dimension.tex 732)", + "content": [ + "One symmetry deserves to be made explicit -- the deepest result of Part V:", + "\\textbf{Axis A} concluded: \\emph{generation} is cheap and \\emph{verification} is the bottleneck, so the SDLC must be rebuilt around machine-checkable specifications, guardrails, and human accountability", + "\\textbf{Axis B} concluded: \\emph{model output} is cheap and \\emph{validation} is the bottleneck, so the runtime must be rebuilt around contracts, ontology guards, eval harnesses, and a human-owned determinism boundary", + "These are the \\textbf{same conclusion at two different binding sites}: whether the LLM sits in the toolchain or in the product, the discipline it demands is \\textbf{containing cheap, fallible generation behind expensive, explicit verification}", + "-- which is, on reflection, what this module has called \\emph{architecture} all along" + ], + "elements": [ + "Two columns (Axis A | Axis B) with 'cheap ... / bottleneck ... / rebuilt around ...' aligned line by line; the shared conclusion as a keypoint-styled line spanning both columns" + ], + "minutes": 3, + "notes": "Axis A's line is Maxim 7 / the verification bottleneck of Lecture 12, recalled in recap bullet 2 (frame 3) -- point back to it; the two 'cheap ... / bottleneck ...' lines are the script's wording (line 732), not a paraphrase." + }, + { + "no": 34, + "deck_section": "Synthesis -- One Theory, Five Parts", + "title": "Discussion: is it one discipline?", + "kind": "discussion", + "script_ref": "§45 thinkbox (part5_ai_dimension.tex 734-736)", + "content": [ + "Close the module with the symmetry. Consider the artefact pairs across the two axes:", + "\\texttt{AGENTS.md} vs.\\ the system prompt and ontology $\\cdot$ the CI fitness function vs.\\ the runtime ontology guard $\\cdot$ the code-review obligation vs.\\ the human-oversight duty of the AI Act $\\cdot$ the test suite as the agent's operating licence vs.\\ the eval harness as the model's operating licence", + "For each pair: is this genuinely \\emph{one} engineering discipline observed at two binding sites -- or are there differences of kind, in \\textbf{reversibility}, in \\textbf{accountability}, in \\textbf{failure semantics}, that the symmetry hides?", + "And if it is one discipline: which parts of this script would survive the next order-of-magnitude improvement in model capability -- and which would you expect to rewrite?" + ], + "elements": [ + "thinkbox 'Discussion' from lines 734-736; the four artefact pairs as a 4-row two-column mini-table (Axis A artefact | Axis B artefact) inside or above the box" + ], + "minutes": 4, + "notes": "Run as a 4-minute plenary; the second question is the natural hand-over to the week-14 defence ('reflect on where AI helped and where it hurt')." + }, + { + "no": 35, + "deck_section": "Exam Orientation", + "title": "The written examination -- the facts", + "kind": "content", + "script_ref": "Deck 1, 'Assessment' frame (AISE502_Vorlesung_1_Folien.tex 179-203)", + "content": [ + "\\textbf{Written examination: 50\\,\\%} of the module grade (the project is the other 50\\,\\%)", + "\\textbf{End of semester, 60 minutes}", + "\\textbf{Open book:} script and own notes, \\emph{on paper}", + "\\textbf{Closed internet}", + "\\textbf{Focus: architecture reasoning -- profiles, matching, trade-offs}", + "Language: all materials, the script, and the exam in English" + ], + "elements": [ + "Reuse the deck-1 'Written examination (50\\,\\%)' block verbatim (right column of the Assessment frame, lines 193-200), full width" + ], + "minutes": 2, + "notes": "Only deck-1 facts; the exam date is not stated in deck 1 -- announce it verbally (open_issues)." + }, + { + "no": 36, + "deck_section": "Exam Orientation", + "title": "Six learning objectives, five parts", + "kind": "table", + "script_ref": "Deck 1 'Learning objectives' frame (AISE502_Vorlesung_1_Folien.tex 167-177) mapped onto §45 synthesis (part5_ai_dimension.tex 726-730)", + "content": [ + "1. explain why architecture selection is a \\textbf{matching problem} -- no pattern is good or bad in itself | Part I: A2 everything is a trade-off, A3 quality attributes drive structure; Part II: every rating explained through the tactics a pattern bundles or impedes", + "2. construct a \\textbf{requirements profile} R(a): scenarios with response measures, utility tree, weights | Part I: A4 requirements decide only as measurable scenarios; Part III: ten classes as ASR bundles with response measures and hard constraints K(a)", + "3. derive the \\textbf{capability profile} C(p) of seven patterns from their tactics | Part II: capability profiles, every rating explained by tactics (the consolidated capability table)", + "4. run the \\textbf{three-stage, non-compensatory match} and defend the result | Part IV: knock-out screening, veto rule, holistic ordinal reading; hybrids are the normal case", + "5. record decisions as \\textbf{ADRs} and attach a \\textbf{measurement contract} | Part IV: the procedure ends in an ADR, every ADR in a measurement contract -- A5, a decision is a hypothesis tested over the life cycle", + "6. engineer \\textbf{AI components} into a system (Axis B) and use \\textbf{AI tools} in the process (Axis A) with the same discipline | Part V: A6 held -- one class, one dimension, five cell shifts, one composition pattern; Axis A raised the value of the artefacts" + ], + "elements": [ + "6-row \\scriptsize table, \\renewcommand{\\arraystretch}{0.85}, two columns 'Learning objective (Lecture 1)' | 'Where the script settles it', p{5.4cm}p{7.2cm}, each cell $\\le$ 2 lines; sources: deck 1 lines 167-177 (objectives verbatim) and §45 line 726 (settlement wording)" + ], + "minutes": 4, + "notes": "No exam questions are invented; the right column is the §45 wording applied to each objective. The focus line is on frame 35, not repeated here." + }, + { + "no": 37, + "deck_section": "Exam Orientation", + "title": "Open book: the map and the four tables", + "kind": "content", + "script_ref": "§45 keypoint (part5_ai_dimension.tex 728-730) and line 726; Part V additions from §43-44 tables; §43.3 keypoint (547-549); deck 1 assessment facts (179-203)", + "content": [ + "Your map is Maxim 8's one sentence: scenarios with numbers $\\to$ capability profiles $+$ requirements profiles $\\to$ non-compensatory match $\\to$ ADR with measurement contract -- and AI changes no step of it", + "The four tables the argument runs on: the \\textbf{twelve dimensions} (Part I) $\\cdot$ the \\textbf{consolidated capability table} (Part II) $\\cdot$ the \\textbf{requirements table} of the ten classes (Part III) $\\cdot$ the \\textbf{$7 \\times 10$ fit matrix} (Part IV)", + "Part V's additions: the \\textbf{D12 row with rationales}, the \\textbf{agent capability-profile sketch}, the \\textbf{task-signature table}, the \\textbf{OWASP table}", + "The spine of the argument: the six load-bearing assumptions \\textbf{A1--A6} -- and the Maxims, up to Maxim 8", + "Focus (Lecture 1): \\textbf{architecture reasoning -- profiles, matching, trade-offs}; in the words of the §43 keypoint: \\emph{name, for any cell movement, the quality-attribute mechanism behind it}" + ], + "elements": [ + "Two columns: left = the one-sentence map as a small five-box strip (reuse frame 32 strip); right = the list of tables and the A1-A6 / Maxims spine; last bullet full width" + ], + "minutes": 3, + "notes": "No study advice beyond the deck-1 focus line and the §43 keypoint quotation; add nothing procedural about the exam." + }, + { + "no": 38, + "deck_section": "Closing", + "title": "This week's exercise: M5 closes -- eval harness in CI, guard, cost observability; threat model, hardening, distinction work", + "kind": "exercise", + "script_ref": "Exercise sheet M5 taskbox week 13 and hintbox (project_exercise/project_exercise.tex 432-442, 451-464; week table lines 385-386); semester plan row 13 (Semesterplan_AISE502_HS26.md line 24: 'Hardening; Kür (autonomes Planning, Self-Repair, Model-Routing)')", + "content": [ + "\\textbf{Project Link (projektbox):} week 13 of M5 -- Multi-Agent Orchestration, Evaluation, and Hardening; coaching session (1 lesson):", + "1. \\textbf{Evaluation harness as a CI gate}; report accuracy and failure modes", + "2. \\textbf{Observability} of token cost and latency per request", + "3. \\textbf{Threat model} incl.\\ prompt injection via news (today's §42.6: the OWASP table, frames 4-5; the same-channel rule, frame 6) $+$ \\textbf{basic hardening}", + "4. \\textbf{Scaling/optimisation}: caching, batching", + "\\textbf{Optional distinction} (semester plan: \\emph{K\\\"ur}): autonomous planning, self-repair, model routing, CI/CD, tracing -- every topology escalation justified against the task-signature table (frame 24) and priced per the default rule (frame 25)", + "\\textbf{Milestone M5: eval harness in CI $+$ guard $+$ cost observability.} Keep the deterministic core free of LLM calls -- this is the line that is graded" + ], + "elements": [ + "projektbox with an enumerate of the four week-13 tasks in the exercise-sheet wording (M5 taskbox, project_exercise.tex 432-442: week-13 item, threat-model item, distinction item), the distinction line as a separate bold-headed line, the milestone in bold, the hintbox line (project_exercise.tex 451-464); pointers to frames 4-6, 24 and 25 instead of restated rules" + ], + "minutes": 3, + "notes": "The threat model is the direct project application of §42.6 taught on frames 4-6 of this deck -- say so, and hand the OWASP table over as the checklist. The distinction work is the semester plan's 'Kür' (row 13) and the exercise sheet's 'Optional Distinction work' -- name both so the two documents are visibly the same list. The milestone line is unchanged ('eval harness in CI + guard + cost observability'). The week-14 announcement is the Next-week frame's job -- not repeated here." + }, + { + "no": 39, + "deck_section": "Closing", + "title": "Summary", + "kind": "summary", + "script_ref": "§42.6-42.7, §43, §44, §45 (part5_ai_dimension.tex 455-736)", + "content": [ + "1. \\textbf{OWASP LLM Top 10}: prompt injection cannot be solved in the model (same channel) -- defence in depth at the system level; \\emph{the architecture, not the model, is the trust boundary}", + "2. \\textbf{EU AI Act}: quality attributes with legal force enter R(a) as hard constraints K(a), never weights -- compliance is the same architecture, documented", + "3. \\textbf{C10 row and five shifts}: boundary/port, queue and capped cells; EDA/PF $\\uparrow$, HX $\\uparrow$ most, MS $\\downarrow$ in synchronous chains, SL conditional, cost load-bearing -- the matrix is \\emph{shifted}, not rewritten; MLOps level = how much of D9/D12 a team can cash in", + "4. \\textbf{Agent orchestration} is a composition pattern, not a style: agent $=$ loop $+$ tools $+$ state; workflows vs.\\ agents; topologies map onto PF, mediator EDA, broker, control loop", + "5. \\textbf{Economics and profile}: 90.2\\,\\% at $\\sim$15$\\times$ tokens is a CBAM decision; $--$ on D3/D4/D9/D10 makes it an edge pattern -- workflows before agents, every escalation an ADR with token budget and eval threshold", + "6. \\textbf{Maxim 8}: the theory absorbs AI -- same assumptions, same procedure, same contract; one discipline at two binding sites: containing cheap, fallible generation behind expensive, explicit verification" + ], + "elements": [ + "\\footnotesize enumerate, \\itemsep 2pt, as in deck 6; six points of at most two lines each" + ], + "minutes": 3, + "notes": "Cut from eight to six points; the parenthetical numbers (98 %, >2x, 4x, 80 %) are on the frames, not in the summary." + }, + { + "no": 40, + "deck_section": "Closing", + "title": "Next week", + "kind": "nextweek", + "script_ref": "Semester plan rows 13-14 (Semesterplan_AISE502_HS26.md lines 6, 24-25); deck 1 'semester at a glance' row 14 (line 215) and assessment frame (179-203); exercise sheet M6 taskbox (project_exercise/project_exercise.tex 444-449)", + "content": [ + "Left column -- \\textbf{Week 14}: one lesson synthesis and exam hints; three lessons final presentations, architecture defence and peer reviews (deliverable A3, milestone M6); then the written examination (open book, 60 min)", + "The week-14 synthesis lesson is a \\textbf{recap of today's synthesis and exam orientation (frames 29-37) plus Q\\&A} -- \\emph{no new material}; today's frames are the reference", + "Present the system and \\textbf{defend your architectural trade-offs}; reflect on where AI helped and where it hurt -- in building (A) and in the system (B)", + "Right column -- \\textbf{Reading}: this week: Part V, §42.6--42.7, 43--45; ahead: \\textbf{the whole script, Parts I--V} -- with the four tables and Maxim 8's one sentence as the map", + "\\textbf{Exercise / deliverable}: M5 closes this week (eval harness in CI $+$ guard $+$ cost observability; threat model $+$ hardening; optional distinction work); \\textbf{A3: final presentation with architecture defence, week 14}" + ], + "elements": [ + "Two-column layout as in deck 6 (0.55 / 0.42): left = week 14 (structure, the recap-plus-Q\\&A line, the defence) and the exam; right = Reading + Exercise/deliverable" + ], + "minutes": 1, + "notes": "Wording of week 14 follows the semester plan ('1 L Synthese + 3 L Präsentationen', lines 6 and 25), deck 1 row 14 ('Synthesis, exam preparation | Presentations + defence | A3') and the exercise sheet's week table (lines 385-386) -- not 'no lecture'. The synthesis lesson of week 14 is announced explicitly as a recap of frames 29-37 plus Q&A so that nobody expects new material there; the task brief's 'Week 14 -- no lecture' constraint must be reconciled with the semester plan by the lecturer before typesetting (open_issues)." + }, + { + "no": 41, + "deck_section": "Closing", + "title": "Closing page", + "kind": "content", + "script_ref": "Deck 6 closing page (theme)", + "content": [ + "\\FHGRClosingPage as in deck 6: 'Thank you!' -- Dr.\\ Florian Herzog, Fachhochschule Graub\\\"unden, Chur -- AISE502 -- AI in Software Engineering II" + ], + "elements": [ + "FHGR closing page (theme)" + ], + "minutes": 0, + "notes": "Last lecture of new material -- the lecturer may wish to add a one-line farewell; keep the theme page otherwise unchanged." + } + ], + "exercise_frame": { + "title": "This week's exercise: M5 closes -- eval harness in CI, guard, cost observability; threat model, hardening, distinction work", + "content": [ + "Week 13 of M5 (Multi-Agent Orchestration, Evaluation, and Hardening); coaching session (1 lesson)", + "Evaluation harness as a CI gate; report accuracy and failure modes", + "Observability of token cost and latency per request", + "Threat model incl. prompt injection via news (today's §42.6: the OWASP table, frames 4-5; the same-channel rule, frame 6) + basic hardening", + "Scaling/optimisation: caching, batching", + "Optional distinction work (semester plan: Kür): autonomous planning, self-repair, model routing, CI/CD, tracing -- topology escalations justified against the task-signature table (frame 24) and priced per the default rule (frame 25)", + "Milestone M5: eval harness in CI + guard + cost observability; keep the deterministic core free of LLM calls -- the line that is graded" + ] + }, + "summary": [ + "OWASP LLM Top 10: prompt injection cannot be solved in the model (same channel) -- defence in depth at the system level; the architecture, not the model, is the trust boundary", + "EU AI Act (Regulation 2024/1689): quality attributes with legal force enter R(a) as hard constraints K(a), never weights -- compliance is the same architecture, documented", + "C10 row and five shifts: boundary/port, queue and capped cells; EDA/PF gain, HX gains most, MS loses in synchronous chains, SL conditional, cost load-bearing everywhere -- the matrix is shifted, not rewritten; MLOps level = how much of D9/D12 a team can cash in", + "Agent orchestration is a composition pattern, not a style: agent = loop + tools + state; workflows (predefined code paths) vs. agents (model steers its own process); topologies map onto PF, mediator EDA, broker, feedback control loop", + "Economics and profile: 90.2 % better at ~15x tokens is a CBAM decision; $--$ on D3/D4/D9/D10 makes it an edge pattern behind the ports of a deterministic core -- workflows before agents, every escalation an ADR with token budget and eval threshold (Maxim 6)", + "Maxim 8: the theory absorbs AI -- tenth class, twelfth dimension, shifted cells, one composition pattern -- same assumptions, same procedure, same contract; Axis A and Axis B are one discipline at two binding sites: containing cheap, fallible generation behind expensive, explicit verification" + ], + "next_week": { + "lecture_line": "Week 14: one lesson synthesis and exam hints -- a recap of today's synthesis and exam orientation (frames 29-37) plus Q&A, no new material; three lessons final presentations, architecture defence and peer reviews (deliverable A3, milestone M6); then the written examination (open book, 60 min)", + "topics": [ + "Final presentations: present the system and defend your architectural trade-offs (M6)", + "Peer reviews", + "Reflect on where AI helped and where it hurt -- in building (Axis A) and in the system (Axis B)", + "Written examination: end of semester, 60 minutes, open book (script and own notes on paper), closed internet; focus: architecture reasoning -- profiles, matching, trade-offs" + ], + "reading": [ + "this week: Part V, Sections 42.6--42.7, 43--45", + "ahead: the whole script, Parts I--V -- with the four tables (twelve dimensions, capability table, requirements table, fit matrix) and Maxim 8's one-sentence pipeline as the map" + ], + "exercise": [ + "M5 closes this week: eval harness in CI + guard + cost observability; threat model incl. prompt injection via news + basic hardening; optional distinction work (Kür)", + "A3: final presentation with architecture defence, week 14" + ] + }, + "script_boxes_used": [ + { + "box": "Table tab:owasp -- OWASP Top 10 for LLM Applications 2025 with architectural counter-measures", + "location": "§42.6, part5_ai_dimension.tex 460-481", + "used_in_frame": "Frames 4 and 5 (split LLM01-05 / LLM06-10)" + }, + { + "box": "hinweisbox -- prompt injection not solvable inside the model; defence in depth; project consequence", + "location": "§42.6, part5_ai_dimension.tex 483-485", + "used_in_frame": "Frame 6" + }, + { + "box": "Table tab:d12row -- the D12 row of the capability table with tactic-level rationales", + "location": "§43.2, part5_ai_dimension.tex 514-532", + "used_in_frame": "Frame 11" + }, + { + "box": "keypoint -- the matrix is shifted, not rewritten (five directions, five reasons)", + "location": "§43.3, part5_ai_dimension.tex 547-549", + "used_in_frame": "Frame 13 (quoted again on frame 37)" + }, + { + "box": "keypoint -- Assumption A6 restated as a falsifiable claim", + "location": "§43.4, part5_ai_dimension.tex 558-560", + "used_in_frame": "Frame 16" + }, + { + "box": "definitionbox[Agent; workflow vs. agent]", + "location": "§44.2, part5_ai_dimension.tex 580-582", + "used_in_frame": "Frame 20" + }, + { + "box": "Table tab:agenttopology -- topologies mapped to classical patterns", + "location": "§44.3, part5_ai_dimension.tex 591-608", + "used_in_frame": "Frame 21" + }, + { + "box": "Figure fig:agenttopologies -- tikz: four topologies and their classical analogues", + "location": "§44.3, part5_ai_dimension.tex 610-651", + "used_in_frame": "Frame 22 (redrawn with deck styles)" + }, + { + "box": "Table tab:agentchoice -- choosing a topology from the task signature", + "location": "§44.3, part5_ai_dimension.tex 655-671", + "used_in_frame": "Frame 24" + }, + { + "box": "keypoint -- the default rule for agent architecture (Maxim 6 applies)", + "location": "§44.4, part5_ai_dimension.tex 678-680", + "used_in_frame": "Frame 25" + }, + { + "box": "Table tab:agentprofile -- capability-profile sketch of agent orchestration", + "location": "§44.5, part5_ai_dimension.tex 687-710", + "used_in_frame": "Frame 26 (one 12-row table); reading on frame 27" + }, + { + "box": "projektbox -- Axis B is what you build; the four graded containment artefacts", + "location": "§44.5, part5_ai_dimension.tex 714-716", + "used_in_frame": "Frame 28 (pointer on frame 24; items referenced on the exercise frame 38)" + }, + { + "box": "keypoint -- Maxim 8, the pipeline in one sentence", + "location": "§45, part5_ai_dimension.tex 728-730", + "used_in_frame": "Frame 32 (reused as the map on frame 37)" + }, + { + "box": "thinkbox -- artefact pairs across the two axes; what survives the next model generation", + "location": "§45, part5_ai_dimension.tex 734-736", + "used_in_frame": "Frame 34 (Discussion)" + } + ], + "script_boxes_dropped": [], + "open_issues": [ + "Week 14 wording: the task constraint says the Next-week frame must announce 'Week 14 -- no lecture'. Three reference documents contradict this (semester plan row 14 and phase logic, lines 6 and 25: '1 L Synthese + 3 L Präsentationen'; deck 1 'semester at a glance' row 14: 'Synthesis, exam preparation | Presentations + defence | A3'; exercise sheet week table, lines 385-386). The plan follows the reference documents on frames 3 and 40 ('one lesson synthesis and exam hints; three lessons presentations, defence, peer reviews -- A3, M6') and keeps the full synthesis and exam orientation in this deck (frames 29-37, 27 minutes); frame 40 announces the week-14 synthesis lesson as a recap of frames 29-37 plus Q&A, not new material. The lecturer must reconcile the task brief's 'no lecture' constraint with the semester plan before typesetting; if 'no lecture' is in fact intended, only the week-14 line on frames 3 and 40 and next_week.lecture_line change -- the deck's content does not.", + "§43.1 names the capped cells of the C10 row (L, MS, SL) only as 'capped'; frame 10 prints their Fit ratings from tab:fit-c10 (part4_fit.tex 439-445: L $-$, MS $\\circ$, SL $\\circ$), taught in Lecture 10 but outside the assigned passage, so that the Fit column follows the rating convention of decks 4-6.", + "The reference architecture figure fig:llmgateway (part5_ai_dimension.tex line 384, taught in Lecture 12) is named on frames 5, 8, 18-19 and 28. The plan only names it; a miniature reprint of the deck-12 figure on frame 8 is optional if space allows.", + "§44.1 (advisor workflow) has no figure in the script; the diagram on frame 18 is drawn from the prose of line 573 only (orchestrator, three specialists, gateway, guard, deterministic analytics services). Label nothing the prose does not name.", + "§42.6 has no italic leading question; frame 4 opens with the section's declarative first sentence verbatim (line 458). §43, §44 and §45 have their own leading questions (lines 499, 567, 723) and use them verbatim.", + "No thinkbox in §42.6-44 and no ailinse box anywhere in the assigned passages: the deck has exactly one Discussion frame (§45) and no AI Lens frames -- consistent with the whole lecture being Axis B.", + "Density: the eighth capability profile (frame 26) is one 12-row scriptsize table with grounds condensed to $\\le$ 12 words -- the typesetter must keep each ground to one line; frame 36 is a two-column scriptsize table with cells of at most two lines; frame 20 (definitionbox + three one-liners) must keep the definitionbox to four lines.", + "Exam orientation uses only deck-1 facts and §45 (plus the §43 keypoint quotation on frame 37); deck 1 states 'end of semester' without a date -- the exam date must be announced verbally.", + "The recap is built from the task's description of deck 12, the Lecture-12 plan's summary (L12.v1.json) and semester-plan row 12 (decks 7-12 do not exist as files in Folien/); recap bullet 2 now carries the verification bottleneck / Maxim 7 and the Axis-A compact block in the script's wording (part5_ai_dimension.tex 142-154, 234) because frame 33 and Maxim 8 build on Maxim 7. At \\footnotesize the bullet must stay within four lines -- the typesetter drops 'two contradictory' and the section-number parenthetical first, never the Maxim-7 clause. The wording 'three component types' is kept generic because only 'type-(b)' appears in the assigned passage (§43.4).", + "Frame 21 uses the script's analogue wording ('Routing layer / mediator', 'Broker topology'); deck 6's outlook table said 'dispatch layer' and 'broker fan-out of autonomous quanta' -- the two renamed cells are to be mentioned verbally, not corrected in deck 6.", + "AI Act timetable: the 2 Aug 2026 general-applicability date has passed by the time of this lecture; the script text is unchanged, but the lecturer may want to say 'now applicable' on frame 7. 'Minimal risk' is printed without a gloss because the script gives none.", + "Minutes: frames 2-37 (agenda, recap, content) sum to 116; exercise 3, summary 3, next-week 1 on top -- total 123 for the 135-minute slot, leaving about 12 minutes for the two lesson breaks and questions on the last lecture of new material.", + "Exercise sheet location: project_exercise.tex lives at AISE502/project_exercise/project_exercise.tex, not under skript/chapters; the cited line numbers (M5 taskbox 432-442, M6 444-449, hintbox 451-464, week table rows 13-14 at lines 385-386) refer to that file. Frame 38 lists all three week-13 items of the M5 taskbox (harness + observability; threat model + hardening + scaling; optional distinction) and names the semester plan's 'Kür' -- the milestone line is unchanged." + ], + "total_frames": 41 +} diff --git a/Folien/Planung_7-13_json/L7.json b/Folien/Planung_7-13_json/L7.json new file mode 100644 index 0000000..248e9c8 --- /dev/null +++ b/Folien/Planung_7-13_json/L7.json @@ -0,0 +1,751 @@ +{ + "lecture": 7, + "week": 7, + "lessons": 2, + "title": "Lecture 7: The Fit, Formally -- Three Cases, the Procedure, the Matrix", + "script_reference": "Script: Part IV, Sections 30--32, 34; Section 37 (introduction)", + "agenda": [ + "Recap: the match, seen once at small scale -- and run by you last week", + "Three matches, three stages: C6 (gate), C1 (veto), C2 (holistic reading and its alarm)", + "The procedure in general -- and what a weighted sum would have destroyed", + "The matching matrix: cell semantics and the $7 \\times 10$ grid", + "Reading the matrix as a whole: columns, rows, five support points", + "The measurement contract, introduced: fitness functions and the DORA metrics", + "This week's exercise: the design-review gate and Deliverable A2" + ], + "recap": [ + "Centre line (deck 3): demand $\\to$ supply $\\to$ match $\\to$ record $\\to$ test", + "Done (weeks 1--6): Part I -- the framework and the C10 mini-match (L $-$, MM $++$, MS $\\circ$); Part II -- seven capability profiles $C(p)$, the consolidated table, Maxims 3 and 4, ordinal reading only; Part III opened -- the C10 profile and the C1/C2 mirror pair (weights, not dimensions, define a class)", + "Last week's exercise: you ran the three stages on your own platform (knock-out $\\to$ veto $\\to$ ordinal reading) and began the ADR", + "Today: three cases from Part IV, one per stage; the general statement and the seventy-cell grid; the measurement contract, introduced", + "hinweisbox: A2 (architecture dossier: ADR $+$ C4 $+$ measurement contract) is due this week; the design-review gate closes the design phase; production code starts only after the gate" + ], + "frames": [ + { + "no": 1, + "deck_section": "Title", + "title": "AISE502: AI in Software Engineering II -- Lecture 7: The Fit, Formally -- Three Cases, the Procedure, the Matrix", + "kind": "content", + "script_ref": "title slide; subtitle line: Script: Part IV, Sections 30--32, 34; Section 37 (introduction)", + "content": [ + "\\FHGRTitlePage with \\subtitle{Lecture 7: The Fit, Formally -- Three Cases, the Procedure, the Matrix\\\\[0.4ex]{\\small Script: Part IV, Sections 30--32, 34; Section 37 (introduction)}}", + "author Dr.\\ Florian Herzog; \\fullname Fachhochschule Graub\\\"unden, Chur -- Autumn Semester 2026" + ], + "elements": [ + "FHGR title page (theme), identical to decks 1--6" + ], + "minutes": 0, + "notes": "Same preamble and box definitions as deck 6 (copy verbatim). Title format: one colon, then an en-dash, as decks 1--6." + }, + { + "no": 2, + "deck_section": "Agenda", + "title": "Agenda", + "kind": "agenda", + "script_ref": "deck skeleton (decks 1--6)", + "content": [ + "1. Recap: the match, seen once at small scale -- and run by you last week", + "2. Three matches, three stages: C6 (gate), C1 (veto), C2 (holistic reading and its alarm)", + "3. The procedure in general -- and what a weighted sum would have destroyed", + "4. The matching matrix: cell semantics and the $7 \\times 10$ grid", + "5. Reading the matrix as a whole: columns, rows, five support points", + "6. The measurement contract, introduced: fitness functions and the DORA metrics", + "7. This week's exercise: the design-review gate and Deliverable A2" + ], + "elements": [ + "enumerate, \\small, itemsep 1pt (as deck 6)" + ], + "minutes": 1, + "notes": "Seven items; each now under ~85 characters so none wraps at \\small." + }, + { + "no": 3, + "deck_section": "Recap", + "title": "Recap: where we are", + "kind": "recap", + "script_ref": "deck 3 recap frame (shape template) and its centre line; deck 6 Summary and Next-week frames; semester plan week 7", + "content": [ + "Centre line (as deck 3): demand $\\to$ supply $\\to$ \\textbf{match} $\\to$ record $\\to$ \\textbf{test}", + "\\textbf{Done (weeks 1--6)}: Part I -- the framework and the C10 mini-match (L $-$, MM $++$, MS $\\circ$); Part II -- seven capability profiles $C(p)$, the consolidated table, Maxims 3 and 4, ordinal reading only; Part III opened -- the C10 profile and the C1/C2 mirror pair (\\emph{weights, not dimensions, define a class})", + "\\textbf{Last week's exercise}: you ran the three stages on your own platform (knock-out $\\to$ veto $\\to$ ordinal reading) and began the ADR", + "\\textbf{Today}: three cases from Part IV, one per stage $\\cdot$ the general statement and the seventy-cell grid $\\cdot$ the measurement contract, introduced", + "hinweisbox: \\textbf{A2 is due this week} -- architecture dossier (ADR $+$ C4 $+$ measurement contract); the design-review gate closes the design phase; production code only after the gate" + ], + "elements": [ + "centred chain line (deck-3 style)", + "hinweisbox (A2 due), as deck 3 recap did for A1" + ], + "minutes": 3, + "notes": "Deck-3 shape: one centred line, one 'Done' sentence, one exercise line, three short 'Today' items, the hinweisbox. \\footnotesize. Do not re-run the mini-match. Emphasise 'you will recognise every step' (deck 6 exercise frame promised it)." + }, + { + "no": 4, + "deck_section": "Three Matches, Three Stages", + "title": "Part IV opens: three matches, three stages", + "kind": "content", + "script_ref": "Part IV opening + §30 intro (part4_fit.tex 1-11); operands formula from §31.1 (part4_fit.tex 80-82)", + "content": [ + "\\emph{What does the three-stage procedure actually do when it runs?} -- usually far less than students expect: \\textbf{most of the work happens before anything is scored}", + "Every Part III class ends with a verdict and a promise -- a one-sentence primary and secondary recommendation, and the assurance that Part IV computes it through the three-stage procedure. You have seen one (C10) and the C1/C2 sketch; Part IV computes those verdicts, and you meet the other rows in weeks 8--9", + "You own both operands: {\\scriptsize $R(a) = (w_1(a),\\dots,w_{12}(a);\\, S(a);\\, K(a))$, $w_i \\in \\{\\text{H},\\text{M},\\text{L}\\}$ -- from A1 and Part III; $C(p) = (c_1(p),\\dots,c_{12}(p);\\, S(p))$, $c_i \\in \\{++,+,\\circ,-,--\\}$ -- the seven columns of Part II}. You have watched $\\mathrm{fit}(a,p)$ run once at small scale (C10 mini-match); not yet seen: the machine at full load", + "Cases first, generalisation after (as Parts II and III worked) -- three matches computed end to end, each exposing one stage: \\textbf{C6} -- knock-out screening and shape gate (Stage 1) $\\cdot$ \\textbf{C1} -- veto rule with documented mitigations (Stage 2) $\\cdot$ \\textbf{C2} -- holistic ordinal reading with its built-in sensitivity alarm (Stage 3). Each lands on exactly the verdict its Part III section states", + "Roadmap strip (tikz, one line of boxes): \\textbf{today} §30 cases $\\cdot$ §31 procedure $\\cdot$ §32 matrix $\\cdot$ §34 reading $\\cdot$ §37 contract (introduced) $\\mid$ \\textcolor{gray}{Lecture 10: §33 rationales $\\cdot$ §35 hybrids and evolution paths $\\cdot$ §36 eight-step decision procedure} $\\mid$ \\textcolor{gray}{Lecture 11: §37 in depth $\\cdot$ §38 organisational complement $\\cdot$ §39 limits}" + ], + "elements": [ + "small tikz roadmap strip of Part IV sections derived from the part opening (line 4): 30, 31, 32, 34, 37-intro highlighted 'today'; 33, 35, 36 greyed 'Lecture 10'; 37-depth, 38, 39 greyed 'Lecture 11'" + ], + "minutes": 2, + "notes": "Leading question in italics, bankblue (deck 4--6 style). Five items maximum incl. the strip; body \\footnotesize. The operands formula is here (scriptsize) so frame 13 can stay at the deck-3 box length. The Part-III sections C1--C9 are weeks 8--9: do not say 'recall'." + }, + { + "no": 5, + "deck_section": "Three Matches, Three Stages", + "title": "Case 1 -- C6 against all seven: the shape gate", + "kind": "table", + "script_ref": "§30.1 (part4_fit.tex 15-16) + Table tab:case-c6 (part4_fit.tex 24-42)", + "content": [ + "\\emph{The nightly risk run must finish by 06:00, reproduce to the bit, and cost as little as possible: which of the seven patterns can even apply for the job?}", + "The C6 profile (Part III, Lecture 9 -- given here as the operand): High on \\textbf{D2} (makespan reading), \\textbf{D9} (reproducibility reading), \\textbf{D10}; dominant workload shape \\textbf{scheduled batch}; deterministic seeds as a hard constraint", + "Before comparing a single rating: hold $S(\\text{C6})$ against the native-shape row $S(p)$ of the capability table (deck 6) -- the table carries the gate and its harm clause", + "Table columns: Pattern | Native shape $S(p)$ | Stage-1 outcome | Verdict", + "L | interactive | gate caps at $\\circ$; harm clause -- no answer to makespan or checkpointing, $--$ against High D2 | $--$", + "MM | interactive | gate caps at $\\circ$: orchestration codebase around monolithic kernels | $\\circ$", + "HX | (host's) | gate caps at $\\circ$: ports touch no binding dimension | $\\circ$", + "MS | interactive | gate caps; harm clause -- communication cost multiplied against High D10 | $--$", + "EDA | stream / async | gate caps at $\\circ$: job-status glue beside scheduler and DAG | $\\circ$", + "PF | scheduled batch | \\textbf{gate passed} -- proceeds to Stages 2--3; no veto on $\\{$D2, D9, D10$\\}$ | $++$", + "SL | event-trig., short-lived | gate caps at $\\circ$: burst fan-out for communication-light sections only | $\\circ$", + "Caption line (\\scriptsize): the workload-shape gate against $S(\\text{C6}) = $ scheduled batch; only PF proceeds to Stages 2--3; the verdict column is identical to the C6 row of the matching matrix" + ], + "elements": [ + "7-row scriptsize booktabs table from tab:case-c6 (lines 24-42), columns @{}lp{2.6cm}p{6.6cm}c@{}, arraystretch 0.9; 'event-trig., short-lived' abbreviated as in the script", + "the examplebox 'Computing the C6 row: one gate, six casualties' (lines 17-22), Stage-1 half, is carried by the table rows, not repeated as bullets" + ], + "minutes": 3, + "notes": "Merged frame (former 5 and 6): three bullets above the table, nothing below except the caption line. The two harm-clause verdicts ($--$ for L and MS without any scoring) are the surprise -- say it while pointing at the rows; MS's harm clause is 'the Prime Video lesson at HPC scale' (line 20, deck 6). \\footnotesize bullets, scriptsize table." + }, + { + "no": 6, + "deck_section": "Three Matches, Three Stages", + "title": "Case 1 -- one survivor, and the didactic point", + "kind": "case", + "script_ref": "§30.1 (part4_fit.tex 19-22, 44)", + "content": [ + "\\textbf{Stages 2 and 3 -- one survivor.} Only PF reaches the veto stage, and no veto fires: against the High set $\\{$D2, D9, D10$\\}$ it rates $+$, $+$, $++$ (PF column, deck 6) -- throughput from data-parallel frameworks, reproducibility by construction, utilisation-driven cost", + "Its $--$ on D3 sits on a Low weight and is \\emph{inert}; the holistic reading ranks a field of one", + "\\textbf{Result: $\\mathrm{fit}(\\text{C6},\\text{PF}) = ++$, every other pattern at $\\circ$ or below} -- the C6 row of the matrix, computed almost entirely at Stage 1", + "The didactic point generalises: \\textbf{run the cheapest test first} -- six of seven candidates died before a single rating was weighed", + "The knock-outs of $K(a)$ belong to the same stage and work the same way: $K(\\text{C1})$ eliminates any structure that cannot guarantee an ACID booking core, an immutable audit journal, and ten-plus-year retention -- \\emph{before} scoring, however well it scales", + "The verdict the class's Part III section states (Lecture 9): pipes-and-filters on HPC/batch infrastructure as primary, serverless fan-out for bursty, communication-light parallel sections as secondary -- with the honest subsystem roles (the $\\circ$ cells) stated, not hidden" + ], + "elements": [ + "examplebox 'Computing the C6 row' (lines 17-22), second half ('Stages 2 and 3 -- one survivor')" + ], + "minutes": 3, + "notes": "\\footnotesize; 6 bullets. Link back to deck 6's PF profile column (D2 $+$, D9 $+$, D10 $++$, D3 $--$) without re-showing it." + }, + { + "no": 7, + "deck_section": "Three Matches, Three Stages", + "title": "Case 2 -- C1: the gate passes both, the veto rule decides", + "kind": "case", + "script_ref": "§30.2 (part4_fit.tex 46-52: intro, Stage 1, Stage 2 for MS)", + "content": [ + "\\emph{Two candidates pass the gate, both natively interactive -- and one of them cannot commit a transaction across its own internal boundaries: how does the procedure decide core banking?}", + "Recall from the deck-6 mirror pair: C1 High on \\textbf{D4, D5, D6, D7, D9}; $K(\\text{C1})$ includes an ACID booking core and BCBS 239 / FINMA auditability; shape interactive with batch edges. Contested pair: the modular monolith against microservices -- the MM and MS columns side by side", + "\\textbf{Stage 1.} Both natively interactive $\\to$ the gate passes both; no hard constraint in $K(\\text{C1})$ eliminates either -- \\emph{a constraint names an obligation, not a pattern}; both can in principle be operated under FINMA-grade audit obligations", + "\\textbf{Stage 2 for MS.} $c_4(\\text{MS}) = --$: no ACID transactions across service boundaries; sagas trade atomicity for choreography complexity. D4 is High in C1 $\\to$ \\textbf{the veto fires and caps the cell at $-$}", + "The fact is \\emph{structural}: no mitigation \\emph{restores} ACID across service boundaries -- sagas buy coordination with compensating actions, not atomicity -- so a mitigation can only show that living without the property is \\emph{survivable}", + "Monzo (deck 5): roughly 2{,}800 microservices in production banking -- under \\textbf{organisational scale plus extreme technological homogeneity} (one language, one monorepo, central migration automation); a condition most organisations do not meet, the premium paid in platform staffing with no gain for typical team sizes", + "Cap lifted \\textbf{only to $\\circ$}, the condition recorded in the cell rationale; MS's $--$ on D8 and D10 sit on Low weights -- no further veto fires", + "\\textbf{Result: $\\mathrm{fit}(\\text{C1},\\text{MS}) = \\circ$}" + ], + "elements": [ + "examplebox 'Computing the cells C1/MS and C1/MM step by step' (lines 50-57), Stage-1 paragraph and 'Stage 2 -- veto rule for MS' paragraph" + ], + "minutes": 3, + "notes": "Merged frame (former 8 and 9). \\footnotesize, 8 bullets -- the density limit; keep bullets 3, 7 and 8 to one line. Students met the Monzo homogeneity condition in deck 5; here it is priced. Stress on bullet 3: a constraint names an obligation, not a pattern." + }, + { + "no": 8, + "deck_section": "Three Matches, Three Stages", + "title": "Case 2 -- stage 2 for MM, and the stage-3 reading", + "kind": "case", + "script_ref": "§30.2 (part4_fit.tex 54-57)", + "content": [ + "\\textbf{Stage 2 -- veto rule for MM.} $c_4(\\text{MM}) = ++$ (cross-module ACID transactions) -- no veto", + "But $c_5(\\text{MM}) = -$ on High-weight D5 $\\to$ caps the cell at $\\circ$ -- \\emph{unless a documented mitigation exists}", + "It does: \\textbf{hot-standby replication of whole monolith instances} -- the classical banking high-availability tactic, in production at Fineract-class core-banking systems. The cap is lifted.", + "\\textbf{Stage 3 -- holistic reading.} MM now stands at $++$ on D4, $+$ on D6, $+$ on D7, $+$ on D9 -- support on every High-weight dimension of the class, with the one structural weakness mitigated", + "\\textbf{Result: $\\mathrm{fit}(\\text{C1},\\text{MM}) = ++$}", + "The ranking MM $\\succ$ MS for the C1 core is \\textbf{stable under plausible weight variation}: it would flip only if D11 (team scaling) rose to High \\emph{and} the Monzo homogeneity condition held -- exactly what the C1 cell rationale (Section 33, Lecture 10) records as the escalation condition" + ], + "elements": [ + "examplebox (lines 50-57), 'Stage 2 -- veto rule for MM' and 'Stage 3' paragraphs" + ], + "minutes": 3, + "notes": "\\footnotesize. Do not add MS's ratings on D5--D9 here: the passage states only MS's D4/D8/D10 cells; the comparison lives in the next frame as two kinds of mitigation." + }, + { + "no": 9, + "deck_section": "Three Matches, Three Stages", + "title": "Case 2 -- two kinds of mitigation, and the C1 verdict", + "kind": "case", + "script_ref": "§30.2 (part4_fit.tex 59)", + "content": [ + "Two columns. Left: \\textbf{operational weakness} -- MM's one-process blast radius (D5): \\emph{repaired outright} by a standard tactic -- hot standby, pod replication", + "Right: \\textbf{structural weakness} -- atomicity surrendered at the boundary (MS, D4): can only be \\emph{made survivable}, under a condition most organisations do not meet", + "The division of labour generalises: the veto rule does the heavy lifting, and the \\textbf{``documented mitigation'' clause is where engineering knowledge -- not arithmetic -- enters the computation}", + "The rest of the row follows the same mechanics (Section 33, Lecture 10); in particular \\textbf{HX -- a delta discipline, not a competitor -- joins MM at $++$} by isolating the long-lived booking core from volatile channels and providers", + "The verdict the class's Part III section states (Lecture 9): a \\textbf{hexagonal modular monolith for the booking core} (MM and HX at $++$), EDA at the edges and PF for the batch runs as secondary, and microservices only when organisation size forces D11 to High -- the Monzo condition -- exactly the C1 row of the matrix" + ], + "elements": [ + "two-column comparison (operational vs structural mitigation), deck-6 mirror-pair layout", + "verdict as a one-line bold statement below the columns" + ], + "minutes": 3, + "notes": "The asymmetry is the lesson of the case; give it the visual centre. \\footnotesize." + }, + { + "no": 10, + "deck_section": "Three Matches, Three Stages", + "title": "Case 3 -- C2: when scoring cannot separate the survivors", + "kind": "case", + "script_ref": "§30.3 (part4_fit.tex 61-66)", + "content": [ + "\\emph{Two finalists carry $++$ where it matters and neither dominates: what does the procedure return when scoring cannot separate the survivors?}", + "C2 (from the deck-6 mirror pair): the \\textbf{widest High set in the catalogue} -- D1, D3, D5, D7, D9, D11 -- and a constraint set that knocks out almost nothing; the discrimination work is done by the \\emph{weights}, not the constraints", + "\\textbf{Stage 1} requires one honest observation about shape: the class core has \\textbf{two constitutive paths} -- the interactive read path that serves the feed, and the asynchronous fan-out path that delivers posts (the five-second delivery scenario, given here from the C2 profile of Part III, is binding for the class)", + "Neither MS (natively interactive) nor EDA (natively stream/async) is shape-foreign to the path it would carry $\\to$ the gate passes both", + "\\textbf{Stage 2} fires one veto against each, and documented practice lifts both: MS's $-$ on High-weighted D3 (mitigation: edge caching, precomputed timelines); EDA's $-$ on High-weighted D9 (mitigation: schema/contract tests, progressive delivery)", + "Both reach Stage 3 intact" + ], + "elements": [ + "none (bullets); the 'per constitutive path' reading of the gate returns in the formal statement (frame 13) as the one clause not shown in deck 3" + ], + "minutes": 3, + "notes": "\\footnotesize. The C2 profile (tab:req-c2) is Lecture 8 material: the High set is recalled from the deck-6 mirror pair, the delivery scenario is given, not recalled. Flag that the per-path reading of the gate is the one element not in deck 3's definition." + }, + { + "no": 11, + "deck_section": "Three Matches, Three Stages", + "title": "Case 3 -- stage 3: the comparison refuses to close", + "kind": "table", + "script_ref": "§30.3 (part4_fit.tex 68)", + "content": [ + "Table across the C2 High set -- columns High dimension | MS | EDA:", + "D1 read scalability | $++$ | $++$", + "D3 latency \\& predictability | (mitigated) | $+$", + "D5 availability \\& isolation | $++$ | $++$", + "D7 evolvability | $++$ | $++$", + "D9 testability \\& deployability | $+$ | (mitigated)", + "D11 team scaling | $++$ | $+$", + "\\textbf{Neither dominates}: MS leads where \\emph{teams} multiply (D9, D11 -- independent deployments), EDA where \\emph{consumers} multiply (D3 on the asynchronous path; D7 in its attach-new-consumers reading)", + "The \\textbf{mandatory sensitivity analysis flips the ordering under entirely plausible variation}: weight D11 the way a several-hundred-team organisation must, and MS wins; frame the feed as what it technically is -- an eventually consistent, precomputed product of an event flow -- and EDA wins", + "By Stage 3's own rule, that instability is \\textbf{not noise}: it marks a genuine tradeoff point in the ATAM sense, to be escalated to scenario-based analysis rather than smoothed over" + ], + "elements": [ + "6-row scriptsize table (High dimension | MS | EDA) built from the two rating sequences in line 68 (MS: $++$, (mitigated), $++$, $++$, $+$, $++$; EDA: $++$, $+$, $++$, $++$, (mitigated), $+$), in High-set order D1, D3, D5, D7, D9, D11" + ], + "minutes": 4, + "notes": "Table on top (compact, 3 columns), three bullets below in \\footnotesize. The dimension names are the standard D-labels of the reference card; the passage gives only the numbers." + }, + { + "no": 12, + "deck_section": "Three Matches, Three Stages", + "title": "Case 3 -- the record refuses the either/or", + "kind": "keyconcept", + "script_ref": "§30.3 (part4_fit.tex 70) + keypoint (72-74)", + "content": [ + "Twitter's timeline architecture is \\textbf{both patterns at once}: fan-out-on-write \\emph{is} publish/subscribe -- an event flow whose product, the precomputed timeline, is served by independently scaled services", + "The honest reading of the instability is not ``the procedure failed to pick a winner'' but ``\\textbf{the class genuinely needs both patterns, placed}'' -- the bridge to hybrids (Section 35, Lecture 10), where hybrids turn out to be the normal case, not the exception", + "The verdict the class's Part III section states (Lecture 8): an \\textbf{EDA $+$ microservices hybrid at organisational scale} (MS and EDA at $++$), a modular monolith as secondary until that scale is \\emph{measured}, not assumed -- Mastodon runs the full fan-out mechanics in a Rails monolith -- exactly the C2 row", + "keypoint: Three cases, three stages, one division of labour -- the knock-out screening and shape gate kill most candidates before any scoring (C6: the cheapest test runs first); the veto rule disciplines the High set and prices every mitigation as documented engineering rather than optimism (C1); the holistic ordinal reading ranks the survivors while flagging its own instability as a finding, not an error (C2). Every one of the seventy cells was produced by exactly this division of labour." + ], + "elements": [ + "keypoint box, condensed from lines 72-74" + ], + "minutes": 3, + "notes": "Three bullets + keypoint: fits at \\footnotesize. Closes the section. C2 is Lecture 8 (Part III, Sections 18--23 cover C1--C5)." + }, + { + "no": 13, + "deck_section": "The Procedure in General", + "title": "The formal statement -- the deck-3 box, plus one clause", + "kind": "definition", + "script_ref": "§31.1 (part4_fit.tex 76-93); recap of deck 3 frame 'The three-stage fit procedure'", + "content": [ + "\\emph{What rule were the three matches following?} -- stated briefly, because every element has already done visible work: $\\mathrm{fit}(a,p)$ is the ordinal aggregate of the dimension-wise comparison of $R(a)$ and $C(p)$ (operands: opening frame), on the same five-step scale, computed under a deliberately \\textbf{non-compensatory, three-stage procedure}", + "definitionbox Architecture--application fit (the box you saw in deck 3, now with worked faces):", + "1. \\textbf{Knock-out screening and workload-shape gate} -- $K(a)$ eliminates before any scoring; $S(p) \\neq S(a)$ caps the cell at $\\circ$ (subsystem role; $+$ only for a \\emph{constitutive} subsystem of a shape-hybrid class; $-$/$--$ where it would harm the binding scenarios). \\textbf{Not shown in deck 3: the gate is read per constitutive path} -- a pattern is not shape-foreign to a class one of whose binding scenarios constitutes a path of the pattern's native shape (Case 3: C2's fan-out delivery scenario)", + "2. \\textbf{Veto rule on High-weight dimensions} -- $c_i(p) = --$ on a High dimension caps at $-$; $c_i(p) = -$ caps at $\\circ$ -- unless a documented mitigation exists (a tactic or hybrid composition with production evidence): the cell says so, the cap is lifted", + "3. \\textbf{Holistic ordinal reading with mandatory sensitivity analysis} -- survivors ranked by support of the High set; clustered Medium conflicts downgrade one step; a \\emph{ranking with exclusions}, never ``12\\,\\% better''; a flip under plausible weight variation marks a tradeoff point (ATAM) and is escalated to scenario-based analysis" + ], + "elements": [ + "definitionbox 'Architecture--application fit' (lines 86-93), condensed to three items of deck-3 length; the per-constitutive-path clause (line 89, last sentence) set in bold and labelled 'not shown in deck 3' -- a deck-level highlight, the script presents it as part of the definition" + ], + "minutes": 2, + "notes": "Recap frame in substance: the box is deck 3's; do not re-teach it -- point at the three worked faces (C6, C1, C2) and dwell only on the bold per-path clause. Operands formula lives on frame 4, so this frame stays at deck-3 box length (\\footnotesize). If it still overflows, split '(1/2) stage 1' / '(2/2) stages 2--3'." + }, + { + "no": 14, + "deck_section": "The Procedure in General", + "title": "Three stages, decreasing hardness -- each with a worked face", + "kind": "table", + "script_ref": "§31.1 (part4_fit.tex 103)", + "content": [ + "The three stages are ordered by \\textbf{decreasing hardness}, and each now has a worked face:", + "Table columns: Stage | What it encodes | Worked face", + "1 Knock-out and shape gate | facts no merit elsewhere can compensate -- a violated BCBS 239 obligation, an interactive pattern asked to carry a scheduled-batch core | Case 1 (C6): this stage running the show, emptying six of the row's seven cells on shape alone", + "2 Veto rule | \\textbf{Assumption A4}: the High weights come from the $(H,H)$ leaves of a utility tree (deck 2), so a structural failure on such a dimension fails precisely the scenarios that define the class -- unless engineering practice has produced a documented way around it | Case 2 (C1): both halves of the rule -- a mitigation that \\emph{repairs} (MM's hot standby) and one that merely makes \\emph{survivable under condition} (MS's Monzo condition)", + "3 Holistic ordinal reading | deliberately the softest: produces an ordering, and carries a built-in alarm for its own instability | Case 3 (C2): the alarm fired and returned a hybrid rather than a false winner" + ], + "elements": [ + "3-row footnotesize table Stage | What it encodes | Worked face (p{2.6cm} p{5.6cm} p{5.0cm}), from line 103" + ], + "minutes": 4, + "notes": "One table, one intro line -- the actually new content of §31.1. The A4 link (High = (H,H) leaves) connects to deck 2's utility-tree frame; spend the extra minute there." + }, + { + "no": 15, + "deck_section": "The Procedure in General", + "title": "Why the fit is not a weighted sum", + "kind": "keyconcept", + "script_ref": "§31.2 (part4_fit.tex 105-109)", + "content": [ + "Deck 3 (Part I): $V(p) = \\sum_i w_i \\cdot v_i(p)$ presupposes cardinal scales, preferential independence, and weights as trade-off rates -- all three violated by ordinal profiles (A2); AHP inherits rank reversal", + "\\textbf{What the three cases add -- a demonstration of what the formula would have destroyed:}", + "C6: it would have averaged the shape gate away under good scores elsewhere $\\cdot$ C1: it would have let MS's missing cross-service ACID be compensated by team scaling $\\cdot$ C2: it would have manufactured a decimal-point winner exactly where the honest output is a flagged tradeoff point", + "Kept from multi-criteria decision analysis: the \\emph{explication discipline} (criteria, weights, assumptions forced into the open); dropped: its arithmetic pretensions -- the matrix is an \\textbf{explication and communication instrument}, not a computation that determines decisions; behind every contested cell stands \\textbf{ATAM}, and, where money decides, \\textbf{CBAM} (utility-response curves, return on investment)", + "keypoint: the fit computation is non-compensatory by design -- constraints knock out before anything is scored, structural failures on High-weight dimensions veto unless a documented mitigation exists, and only then does a holistic ordinal ranking follow, with mandatory sensitivity analysis. A weighted sum over ordinal profiles would be formally illegitimate and would average away exactly the failures that matter most." + ], + "elements": [ + "keypoint box (lines 107-109), condensed", + "the three C-lines as a compact three-item list" + ], + "minutes": 3, + "notes": "One recap line only (deck 3's 'Why the obvious alternative fails' / 'pseudo-precision' frames); the three-case demonstration is the new content. \\footnotesize: four bullets + keypoint." + }, + { + "no": 16, + "deck_section": "The Matching Matrix", + "title": "Cell semantics: what one cell of the grid actually claims", + "kind": "definition", + "script_ref": "§32.1 (part4_fit.tex 118-130)", + "content": [ + "\\emph{What does one cell of a seventy-cell grid actually claim?} A matrix cell answers one precisely delimited question -- and misreading that question is the \\textbf{most common student error} with this instrument", + "definitionbox Cell semantics of the matching matrix: a cell $\\mathrm{fit}(a,p)$ states the fit of pattern $p$ \\emph{as the dominant structure of the core} of application class $a$ -- the pattern that owns the class's binding quality attribute scenarios. It does \\emph{not} state whether $p$ is useful anywhere in a system of class $a$: hybrid roles at the edges (an event journal beside an ACID core, a batch pipeline beside an interactive product) are stated in the cell rationale, not in the cell value", + "\\textbf{Consequence 1: a $-$ cell is not a prohibition.} EDA rates $-$ as the dominant structure of a banking core, yet the same rationale names the immutable event journal as the natural regulatory audit trail at that core's edges", + "\\textbf{Consequence 2: the hexagonal column needs a special reading.} HX is a delta pattern of dependency organisation, not a distribution style; it composes with a host (typically MM), and its cells read ``as the internal discipline of the class's core''" + ], + "elements": [ + "definitionbox 'Cell semantics of the matching matrix' (lines 121-123)" + ], + "minutes": 3, + "notes": "Definition box + two consequences; \\footnotesize. Ask students to keep the definition in mind before the grid appears." + }, + { + "no": 17, + "deck_section": "The Matching Matrix", + "title": "The $7 \\times 10$ matching matrix", + "kind": "table", + "script_ref": "§32.2, Table tab:fitmatrix (part4_fit.tex 132-160)", + "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 line (\\scriptsize): ratings $++$ (excellent fit) to $--$ (structural misfit); bold $=$ cells underlying the primary recommendation of each class; $^{\\dagger}$HX is a delta pattern -- composes with a host (typically MM), cells read ``as the internal discipline of the class's core''; abbreviations L $=$ layered/3-tier, MM $=$ modular monolith, MS $=$ microservices, EDA $=$ event-driven, PF $=$ pipes-and-filters/batch pipeline, SL $=$ serverless/FaaS" + ], + "elements": [ + "10-row scriptsize booktabs table from tab:fitmatrix (lines 138-152), columns @{}p{4.2cm}ccccccc@{}, arraystretch 0.85 -- upright (the script's sidewaystable becomes a normal slide table, same format as deck 6's consolidated capability table)", + "one-line scriptsize footnote condensed from the minipage (lines 156-158), without the never-negative sentence (frame 20 carries it)" + ], + "minutes": 4, + "notes": "The central slide of the deck: nothing else on it. Optionally shade rows C1, C2, C6 lightly (colortbl, bankblue!8) to mark 'the rows you computed'. Give students a silent minute with the grid before talking." + }, + { + "no": 18, + "deck_section": "The Matching Matrix", + "title": "Reading the grid: the rows you computed", + "kind": "keyconcept", + "script_ref": "§32.2 (part4_fit.tex 134, 156) + keypoint (162-164)", + "content": [ + "The matrix is the three cases of Section 30, \\textbf{done seventy times}", + "Rows C6, C1, C2: the rows you have just computed; the remaining seven were produced by exactly the same three stages -- knock-out and shape gate, then the H-dimension veto with documented mitigations, then the holistic ordinal reading", + "Every cell is traceable to $R(a) \\times C(p)$ through the per-class rationales (Section 33 -- Lecture 10)", + "$^{\\dagger}$HX: a delta pattern -- it composes with a host (typically MM), and its cells read ``as the internal discipline of the class's core''", + "keypoint: read a matrix cell as the answer to one question only -- \\emph{how well does this pattern serve as the dominant structure of this class's core?} The edges of the same system routinely use patterns whose cell reads $\\circ$ or $-$; the hybrid roles are stated in the rationales, and Section 35 (Lecture 10) shows that hybrids are the normal case, not the exception" + ], + "elements": [ + "keypoint box (lines 162-164)" + ], + "minutes": 2, + "notes": "Short frame after the grid; \\footnotesize like every other content frame. The never-negative claim is deferred to frame 20, where the excerpt table makes it checkable. Point back to the C10 row: identical to the deck-3 mini-match verdicts (L $-$, MM $++$, MS $\\circ$) -- now with HX $++$, EDA $+$, PF $+$, SL $\\circ$ added." + }, + { + "no": 19, + "deck_section": "Reading the Matrix as a Whole", + "title": "Column patterns (1/2): the unfashionable default", + "kind": "content", + "script_ref": "§34.1 (part4_fit.tex 461-469)", + "content": [ + "\\emph{What does the grid say as a whole that no single cell can?} The matrix rewards a second reading -- not cell by cell but by columns, rows, and boundaries", + "Column-wise, the \\textbf{modular monolith is primary or secondary in seven of ten classes} -- not because it is fashionable (it is conspicuously unfashionable) but because most requirements profiles weight consistency, evolvability, cost, and time-to-market higher than independent scaling, and \\textbf{MM is the only pattern rated $+$ or better on all four} of those dimensions (capability table, deck 6)", + "The matrix-level restatement of Fowler's \\textbf{MonolithFirst}: do not start with microservices even if you expect to need them -- stable service boundaries cannot be cut before the domain is understood, and refactoring \\emph{between} services is far costlier than \\emph{within} a monolith", + "\\textbf{Microservices earn their premium in exactly two situations}, both visible in the grid: where High-weight read scalability, fault isolation, and team scaling coincide (C2, and conditionally C5 and C8) -- and nowhere else", + "The premium is real and quantified: $--$ on cost and simplicity; the run-cost side materialises as platform staffing -- self-managed Kubernetes TCO \\textbf{roughly three times} managed offerings, dominated by personnel (deck 5); the two $--$ cells in the MS column (C3, C4) mark the classes that \\textbf{pay the premium and collect nothing}" + ], + "elements": [ + "none -- bullets only; the MM and MS columns appear in the excerpt table of frame 20" + ], + "minutes": 3, + "notes": "\\footnotesize, 5 bullets, no side table (the optional column excerpt has been removed; frame 20's five-column excerpt covers the visual check)." + }, + { + "no": 20, + "deck_section": "Reading the Matrix as a Whole", + "title": "Column patterns (2/2): workload-shaped columns, HX never negative", + "kind": "content", + "script_ref": "§34.1 (part4_fit.tex 471-473) + footnote minipage (157); excerpt values from tab:fitmatrix (138-147)", + "content": [ + "\\textbf{PF and EDA are workload-shaped columns.} Their $++$ cells sit precisely where the class's dominant workload shape matches the pattern's native shape -- scheduled batch for PF (C6, C7), continuous stream or fan-out for EDA (C8, C9, and the C2 fan-out)", + "The shape gate caps them at $\\circ$ -- or, by the harm clause, below -- everywhere the class core is interactive", + "The clearest demonstration that the gate of Stage 1 does real work: \\textbf{no amount of merit on other dimensions lets a batch pipeline carry an interactive core}", + "\\textbf{The HX column is never negative} -- not a free lunch but a property of orthogonality: as a delta pattern, hexagonal architecture composes with the host rather than competing with it, and its cost ($c_8 = -$) surfaces only as capped cells where the change rate is low (C6, C7)", + "Column excerpt table (Class | MM | MS | HX | EDA | PF): C1 $++$ $\\circ$ $++$ $-$ $\\circ$; C2 $+$ $++$ $\\circ$ $++$ $\\circ$; C3 $++$ $--$ $+$ $-$ $\\circ$; C4 $++$ $--$ $+$ $-$ $\\circ$; C5 $++$ $+$ $+$ $+$ $\\circ$; C6 $\\circ$ $--$ $\\circ$ $\\circ$ $++$; C7 $+$ $-$ $\\circ$ $\\circ$ $++$; C8 $-$ $+$ $\\circ$ $++$ $+$; C9 $+$ $+$ $\\circ$ $++$ $-$; C10 $++$ $\\circ$ $++$ $+$ $+$" + ], + "elements": [ + "10-row scriptsize five-column excerpt (MM, MS, HX, EDA, PF) of tab:fitmatrix (lines 138-147) on the right, bullets on the left (columns 0.58/0.38); MM/MS columns serve frame 19's claims (seven of ten; the two $--$ cells C3, C4), HX/EDA/PF serve this frame's" + ], + "minutes": 3, + "notes": "The excerpt makes the claims visually checkable: $++$ only on shape matches; no negative HX cell; the MS $--$ cells at C3/C4. Speaker note on bullet 2: the $-$ cells of EDA (C1, C3, C4) and PF (C9) are harm-clause results of the same gate (definition item 1, line 89) -- the script's sentence at line 471 says only 'caps at $\\circ$'." + }, + { + "no": 21, + "deck_section": "Reading the Matrix as a Whole", + "title": "Row patterns and the five empirical support points", + "kind": "table", + "script_ref": "§34.2 (part4_fit.tex 475-479)", + "content": [ + "Row-wise: \\textbf{no class is served above $\\circ$ by every pattern, and no pattern serves every class above $\\circ$} -- Assumption A2 made visible in a single glance at the grid", + "If a dominant pattern existed, its column would be uniformly positive, and this part of the module would be one page long", + "Cell-wise: the five case-study systems of the module each sit \\textbf{exactly on a cell boundary} -- the empirical support points at which fit and misfit have been \\emph{measured in money}", + "Table columns: System | Cell it sits on | What was measured", + "Prime Video (deck 6) | the split serverless cost cell | over 90\\,\\% infrastructure cost reduction after consolidating a data-intensive flow into one process", + "Segment | the MS evolvability cell, read against a wrongly cut boundary | services per configuration instance, not per domain seam", + "Shopify | the MM write-scalability mitigation | pod-sharded replication", + "Uber (DOMA) | the MS team-scaling cell | the point where service count itself became the problem", + "Stack Overflow | the layered read-scalability deviation | cache-friendly read dominance served by roughly nine web servers" + ], + "elements": [ + "5-row scriptsize table System | Cell | What was measured (p{2.4cm} p{4.6cm} p{6.2cm}) from line 479" + ], + "minutes": 3, + "notes": "Three bullets above the table at \\footnotesize; the table carries only what the passage states (no further figures). All five systems were case studies in decks 3--6; the deck marker is set on Prime Video, the one this deck reuses again in frame 23." + }, + { + "no": 22, + "deck_section": "Reading the Matrix as a Whole", + "title": "Discussion: the C5 row under two variations", + "kind": "discussion", + "script_ref": "§34.2 thinkbox (part4_fit.tex 485-487) + keypoint (481-483); C5 row from tab:fitmatrix (142)", + "content": [ + "The C5 row for reference: L $-$ | MM $++$ | HX $+$ | MS $+$ | EDA $+$ | PF $\\circ$ | SL $+$", + "thinkbox: Take the C5 row (e-commerce) and increase the organisation from 3 teams to 30 while holding traffic constant. Which cells change, through which dimension, and at which stage of the three-stage procedure?", + "thinkbox: Now hold the organisation at 3 teams and multiply traffic by 50.", + "thinkbox: Why does the second variation move the row so much less than the first -- and what does that say about the popular claim that ``we need microservices to scale''?", + "keypoint (closing line, after the discussion): the modular monolith dominates the matrix as default \\emph{not despite but because of} its unfashionableness: most requirements profiles weight consistency, evolvability, cost, and time-to-market above independent scaling. Microservices earn their documented premium only where read scalability, fault isolation, and team scaling are simultaneously High -- and the premium is paid in platform staffing either way" + ], + "elements": [ + "one-line C5 row excerpt from tab:fitmatrix (line 142)", + "thinkbox 'Discussion' with the three questions (lines 485-487)", + "keypoint (lines 481-483), condensed, placed below the thinkbox as the closing line" + ], + "minutes": 6, + "notes": "Budgeted at 6 minutes: run Stage 2/3 on the C5 row twice with the room. Expected direction -- inferred from §34.1 (lines 465-467) and §34.2 (line 479), NOT stated in the script: the first variation moves D11 to High and re-runs Stage 2/3 in MS's favour (the C2 condition); the second moves D1/D2 but MM's mitigations (Shopify-style replication) hold. Keep this in the speaker notes only; the keypoint is revealed last." + }, + { + "no": 23, + "deck_section": "The Measurement Contract, Introduced", + "title": "How a decision made this year stays honest in year five", + "kind": "content", + "script_ref": "§37 opening (part4_fit.tex 654-659); deck 3 framework frame (measurement contract as fifth element)", + "content": [ + "\\emph{How does a decision made this year stay honest in year five?} One case motivates the apparatus", + "What actually triggered the Prime Video re-architecture (deck 6) was \\textbf{not an architecture review but a telemetry signal}: infrastructure cost per stream, measured continuously, crossed what the team was willing to pay -- and that measurement, not an opinion, first forced and then vindicated the redesign", + "The cost dashboard was a \\textbf{fitness function in everything but name}: an objective, continuously evaluated check on an architectural characteristic whose breach converted a running structure from ``accepted'' into ``falsified''", + "Empirical anchor for building such checks systematically: DORA's finding that \\textbf{loosely coupled architectures and teams are the strongest predictor of continuous delivery} -- coupling, this theory's leading dimension, is a \\emph{measurable} property", + "The seventh step of the eight-step decision procedure (Section 36, Lecture 10) generalises the observation into a concept -- where this course differs from a classical architecture lecture: the chosen fit is codified as a \\textbf{measurement contract} -- the set of executable invariants under which the architecture is allowed to keep evolving. \\textcolor{bankblue}{\\textbf{``The architecture may change freely as long as the contract stays green''}}", + "Deck 3 named the contract as the fifth framework element -- today its definition and instruments; depth (taxonomy in CI/CD, the four-layer cascade, Boehm vs.\\ Menzies) in Lecture 11" + ], + "elements": [ + "none; the contract motto set as a highlighted one-liner (\\textcolor{bankblue})" + ], + "minutes": 3, + "notes": "Bridge to A2: this is the third artefact of the dossier. The 'Lecture 11' pointer lives here (removed from the DORA frame)." + }, + { + "no": 24, + "deck_section": "The Measurement Contract, Introduced", + "title": "Fitness functions -- the definition", + "kind": "definition", + "script_ref": "§37.1 definitionbox (part4_fit.tex 663-665)", + "content": [ + "definitionbox Architectural fitness function: ``any mechanism that provides an objective integrity assessment of some architectural characteristic''. Fitness functions turn quality attributes into executable, objective checks and move architecture governance from review meetings into the CI/CD pipeline", + "Classified along two primary dimensions -- mini-table (two rows):", + "\\textbf{Scope} | \\emph{atomic}: one characteristic in isolation (e.g.\\ a dependency rule as a unit test) | \\emph{holistic}: combined characteristics in interplay (e.g.\\ security and data freshness under load)", + "\\textbf{Cadence} | \\emph{triggered}: event-based, on every build or deployment | \\emph{continual}: running permanently in operation (e.g.\\ chaos experiments) | \\emph{temporal}: time-scheduled (e.g.\\ dependency-freshness time bombs)" + ], + "elements": [ + "definitionbox 'Architectural fitness function' (lines 663-665), quote + one sentence", + "two-row footnotesize mini-table Scope (atomic | holistic) / Cadence (triggered | continual | temporal) with the script's own examples -- not a 2x3 cross-table, because the script gives no example for four of the six cross cells" + ], + "minutes": 2, + "notes": "Split from the former frame 26 (definition + families were overfull). Introduction only: the taxonomy in CI/CD is Lecture 11." + }, + { + "no": 25, + "deck_section": "The Measurement Contract, Introduced", + "title": "Three instrument families", + "kind": "table", + "script_ref": "§37.1 enumerate (part4_fit.tex 667-673)", + "content": [ + "Three worked instrument families recur throughout the module -- table columns: Family | Instruments | Scope / cadence | What it makes testable", + "1 Dependency checks as CI gates (decks 3--4) | ArchUnit (analogues: NetArchTest, dependency-cruiser, import-linter): ``the domain layer imports no framework'', ``no cycles between modules'' as unit tests that fail the build; Spring Modulith for declared module boundaries | atomic, triggered | what makes the MM ratings of the capability table \\emph{enforceable} rather than aspirational -- without automated boundary verification, boundary erosion is the documented failure mode of the pattern", + "2 Performance and cost budgets as pipeline gates | latency thresholds, bundle sizes, Lighthouse scores declared in a budget file | (pipeline gate) | \\textbf{Axis B transfer is direct: token-cost budgets and p95 latency budgets per AI use case are the same mechanism with new units}", + "3 Chaos experiments | Netflix's Chaos Monkey terminates production instances to test resilience assumptions permanently; formalised as the principles of chaos engineering | holistic, continual | verifies the \\textbf{D5 cells}: a claimed blast radius is a hypothesis until an instance has actually been killed under load" + ], + "elements": [ + "3-row scriptsize table Family | Instruments | Scope / cadence | What it makes testable, columns p{2.2cm} p{5.0cm} p{1.8cm} p{4.4cm}, from the enumerate in lines 669-673; the family-2 scope/cadence cell reads '(pipeline gate)' without a scope label because the script classifies only families 1 and 3" + ], + "minutes": 3, + "notes": "Table alone on the frame. The Axis-B sentence (line 671) is the deck's only AI-lens material -- set in bold, no separate ailinse frame (see open_issues); map it onto item 3 of the A2 measurement contract on the exercise frame. Family 1 was deck 4's ArchUnit/Spring Modulith CI gate and deck 3's ADR-011 confirmation block: say 'the first fitness function most teams ever write' verbally, not on the slide." + }, + { + "no": 26, + "deck_section": "The Measurement Contract, Introduced", + "title": "DORA metrics: the delivery layer -- and the coupling finding", + "kind": "content", + "script_ref": "§37.2 (part4_fit.tex 675-680)", + "content": [ + "The four DORA metrics measure whether the delivery-relevant promises of a structure are being kept: \\textbf{deployment frequency} and \\textbf{lead time for changes} (tempo); \\textbf{change failure rate} and \\textbf{failed-deployment recovery time} (stability)", + "Central empirical finding: elite performers lead on \\emph{all four} -- \\textbf{tempo and stability are not a trade-off}", + "The strongest single result in the field supports coupling as the leading dimension of this entire theory: ``loosely coupled architectures and teams are the strongest predictor of continuous delivery'' -- in the 2017 analysis, testability and deployability contributed more to continuous delivery than test and deployment automation itself", + "High performance is possible with all kinds of systems -- including mainframes -- provided systems and teams are loosely coupled: the label ``microservices'' is \\emph{neither necessary nor sufficient}", + "Second follow-on finding (deck 5, depth in Lecture 11): as team count grows, deployments per developer per day \\emph{rise} for high performers and \\emph{fall} for low performers", + "hinweisbox: DORA's evidence is survey-based and analysed with structural equation models -- prediction, not experimental causal proof. The theory treats it as the best available large-$n$ evidence, to be triangulated against case studies and your own measurements -- not as settled law" + ], + "elements": [ + "hinweisbox with the honesty caveat (line 680)" + ], + "minutes": 2, + "notes": "\\footnotesize; five one-to-two-line bullets + hinweisbox. The 'neither necessary nor sufficient' line closes the loop to frame 19 (MS premium) and deck 6's Conway bullet. No separate 'Depth' line -- frame 23 carries the Lecture-11 pointer." + }, + { + "no": 27, + "deck_section": "Closing", + "title": "This week's exercise: the design-review gate and Deliverable A2", + "kind": "exercise", + "script_ref": "project_exercise.tex M2 taskbox (lines 401-414) and phase description (line 361); semester plan week 7 row", + "content": [ + "projektbox: \\textbf{The design phase closes this week.} Finalise the solution design:", + "1. \\textbf{Service cut and contracts} -- bounded contexts $\\to$ service decomposition and the contracts between the deterministic core, the edges, and the AI subsystem", + "2. \\textbf{Walking-skeleton plan} -- the thin end-to-end slice you will build first in Sprint 1", + "3. \\textbf{Measurement contract} -- in today's vocabulary: a \\emph{token budget} (family 2: cost budget as a pipeline gate), an \\emph{eval threshold} (pass rate on the golden set before rollout), and \\emph{module-boundary checks} (family 1: dependency rules as CI gates, ArchUnit / import-linter style)", + "4. \\textbf{Design-Review Gate} -- defend the ADR: which vetoes fired, which mitigations are \\emph{documented}, what the sensitivity check showed", + "\\textbf{Deliverable A2 (end of week 7): architecture dossier} -- ADR $+$ C4 diagram $+$ measurement contract. Production code starts only after the gate (exploratory spikes are allowed)", + "Below the box (\\small): From week 8 the exercise slot becomes a one-lesson (one-hour) standup/coaching session and the lecture grows to three lessons; Sprint 1 (walking skeleton) begins" + ], + "elements": [ + "projektbox with enumerate (deck-6 exercise-frame format); the outlook line sits outside the box as \\small text, as deck 6 did" + ], + "minutes": 3, + "notes": "Map each measurement-contract item to one of the instrument families from frame 25 so the lecture content lands directly in the deliverable. 'and the AI subsystem' in item 1 is consistent with the deck-6 projektbox but is not in the M2 taskbox wording ('Bounded contexts -> service decomposition and contracts')." + }, + { + "no": 28, + "deck_section": "Closing", + "title": "Summary", + "kind": "summary", + "script_ref": "deck summary (frames 4-26)", + "content": [ + "1. \\textbf{Three cases, three stages}: C6 -- the gate empties six of seven cells before scoring; C1 -- the veto rule decides, mitigations priced as documented engineering; C2 -- the reading flags its own instability and returns a hybrid", + "2. \\textbf{Two kinds of mitigation}: an operational weakness is repaired outright (hot standby); a structural one is only made survivable under a condition most organisations do not meet (Monzo)", + "3. \\textbf{The formal statement}: $\\mathrm{fit}(a,p)$ -- ordinal, non-compensatory, three stages of decreasing hardness; the gate is read per constitutive path; a weighted sum would have destroyed exactly the three decisive facts", + "4. \\textbf{Cell semantics}: a cell rates the pattern as the dominant structure of the core only; $-$ is not a prohibition; HX reads as the internal discipline of the core", + "5. \\textbf{The grid}: MM primary or secondary in seven of ten; MS premium in two situations only; PF/EDA workload-shaped; HX never negative; no row or column uniformly positive (A2)", + "6. \\textbf{Five support points}: Prime Video, Segment, Shopify, Uber, Stack Overflow each sit on a cell boundary -- fit and misfit measured in money", + "7. \\textbf{Measurement contract}: fitness functions (scope $\\times$ cadence; dependency checks, budgets, chaos) and the four DORA metrics; \\emph{the architecture may change freely as long as the contract stays green}" + ], + "elements": [ + "numbered list (7 points, each at most two lines), \\footnotesize, no keypoint" + ], + "minutes": 2, + "notes": "Keypoint dropped (its two claims are points 4 and 7). Deck-6 summary shape: seven points of 1--2 lines." + }, + { + "no": 29, + "deck_section": "Closing", + "title": "Next week", + "kind": "nextweek", + "script_ref": "semester plan week 8 row; project_exercise.tex M3 (lines 416-420); task brief 'Next lecture'", + "content": [ + "Left column -- \\textbf{Lecture 8 (week 8, 3 lessons) -- Part III: application classes C1--C5}: challenges $\\to$ profiles $\\to$ what real systems chose; the rows C1--C5 of today's matrix, derived from the demand side", + "Right column -- \\textbf{Reading}: this week: Part IV, Sections 30--32, 34; Section 37 (introduction); ahead: Part III, Sections 18--23", + "Right column -- \\textbf{Exercise / deliverable}: \\textbf{A2 $+$ design-review gate: this week}; from week 8: Sprint 1 -- walking skeleton (\\texttt{MarketDataService} $+$ minimal \\texttt{ResearchAgent} $+$ stable API); exercise slot becomes a one-lesson standup/coaching" + ], + "elements": [ + "two-column layout 0.55/0.42 as decks 3--6" + ], + "minutes": 1, + "notes": "Verbatim in substance from the task brief." + }, + { + "no": 30, + "deck_section": "Closing", + "title": "Closing slide", + "kind": "content", + "script_ref": "deck skeleton", + "content": [ + "\\FHGRClosingPage with 'Thank you!' / Dr.\\ Florian Herzog / Fachhochschule Graub\\\"unden, Chur / AISE502 -- AI in Software Engineering II (wrapped in \\parbox, white text -- theme traps 1 and 2)" + ], + "elements": [ + "FHGR closing page" + ], + "minutes": 0, + "notes": "Copy from deck 6 verbatim." + } + ], + "exercise_frame": { + "title": "This week's exercise: the design-review gate and Deliverable A2", + "content": [ + "projektbox: the design phase closes this week -- finalise the solution design", + "1. Service cut and contracts: bounded contexts $\\to$ service decomposition and contracts between the deterministic core, the edges, and the AI subsystem", + "2. Walking-skeleton plan: the thin end-to-end slice built first in Sprint 1", + "3. Measurement contract in today's vocabulary: token budget (family 2: cost budget as pipeline gate), eval threshold (pass rate on the golden set before rollout), module-boundary checks (family 1: dependency rules as CI gates, ArchUnit / import-linter style)", + "4. Design-Review Gate: defend the ADR -- which vetoes fired, which mitigations are documented, what the sensitivity check showed", + "Deliverable A2 (end of week 7): architecture dossier -- ADR $+$ C4 $+$ measurement contract; production code starts only after the gate (exploratory spikes allowed)", + "Below the box (\\small): from week 8 the exercise slot becomes a one-lesson (one-hour) standup/coaching session, the lecture grows to three lessons; Sprint 1 walking skeleton begins" + ] + }, + "summary": [ + "Three cases, three stages: C6 -- the gate empties six of seven cells before scoring; C1 -- the veto rule decides, mitigations priced as documented engineering; C2 -- the reading flags its own instability and returns a hybrid", + "Two kinds of mitigation: an operational weakness is repaired outright (hot standby); a structural one is only made survivable under a condition most organisations do not meet (Monzo)", + "The formal statement: fit(a,p) -- ordinal, non-compensatory, three stages of decreasing hardness; the gate is read per constitutive path; a weighted sum would have destroyed exactly the three decisive facts", + "Cell semantics: a cell rates the pattern as the dominant structure of the core only; a $-$ is not a prohibition; HX reads as the internal discipline of the core", + "The grid: MM primary or secondary in seven of ten; MS premium in two situations only; PF/EDA workload-shaped; HX never negative; no row or column uniformly positive (A2)", + "Five support points: Prime Video, Segment, Shopify, Uber, Stack Overflow each sit on a cell boundary -- fit and misfit measured in money", + "Measurement contract: fitness functions (scope x cadence; dependency checks, budgets, chaos) and the four DORA metrics; the architecture may change freely as long as the contract stays green" + ], + "next_week": { + "lecture_line": "Lecture 8 (week 8, 3 lessons) -- Part III: application classes C1--C5: challenges -> profiles -> what real systems chose", + "topics": [ + "application classes C1--C5: challenges -> requirements profiles -> what real systems chose", + "the rows C1--C5 of today's matrix, derived from the demand side" + ], + "reading": [ + "this week: Part IV, Sections 30--32, 34; Section 37 (introduction)", + "ahead: Part III, Sections 18--23" + ], + "exercise": [ + "A2 (architecture dossier: ADR + C4 + measurement contract) + design-review gate: due end of this week", + "week 8: Sprint 1 -- walking skeleton (MarketDataService + minimal ResearchAgent + stable API)", + "from week 8 the exercise slot is a one-lesson (one-hour) standup/coaching; the lecture grows to three lessons" + ] + }, + "script_boxes_used": [ + { + "box": "examplebox 'Computing the C6 row: one gate, six casualties'", + "location": "§30.1, part4_fit.tex 17-22", + "used_in_frame": "5 (Stage-1 half, carried by the table rows), 6 (Stages 2-3 half)" + }, + { + "box": "Table tab:case-c6 'Case 1 -- the C6 row decided at Stage 1'", + "location": "§30.1, part4_fit.tex 24-42", + "used_in_frame": "5" + }, + { + "box": "examplebox 'Computing the cells C1/MS and C1/MM step by step'", + "location": "§30.2, part4_fit.tex 50-57", + "used_in_frame": "7 (Stage 1 + Stage 2 MS), 8 (Stage 2 MM + Stage 3)" + }, + { + "box": "keypoint 'Three cases, three stages, one division of labour'", + "location": "§30.3, part4_fit.tex 72-74", + "used_in_frame": "12" + }, + { + "box": "definitionbox 'Architecture--application fit'", + "location": "§31.1, part4_fit.tex 86-93", + "used_in_frame": "13 (condensed to deck-3 length; per-path clause highlighted)" + }, + { + "box": "keypoint 'The fit computation is non-compensatory by design'", + "location": "§31.2, part4_fit.tex 107-109", + "used_in_frame": "15" + }, + { + "box": "definitionbox 'Cell semantics of the matching matrix'", + "location": "§32.1, part4_fit.tex 121-123", + "used_in_frame": "16" + }, + { + "box": "sidewaystable tab:fitmatrix 'The matching matrix' incl. dagger footnote minipage", + "location": "§32.2, part4_fit.tex 132-160", + "used_in_frame": "17 (full grid), 18 (dagger one-liner), 20 (five-column excerpt + never-negative sentence), 22 (C5 row)" + }, + { + "box": "keypoint 'Read a matrix cell as the answer to one question only'", + "location": "§32.2, part4_fit.tex 162-164", + "used_in_frame": "18" + }, + { + "box": "keypoint 'The modular monolith dominates the matrix as default'", + "location": "§34.2, part4_fit.tex 481-483", + "used_in_frame": "22 (closing line after the discussion)" + }, + { + "box": "thinkbox 'C5 row: 3 to 30 teams / traffic x50'", + "location": "§34.2, part4_fit.tex 485-487", + "used_in_frame": "22" + }, + { + "box": "definitionbox 'Architectural fitness function'", + "location": "§37.1, part4_fit.tex 663-665", + "used_in_frame": "24" + }, + { + "box": "enumerate 'Three worked instrument families' (dependency checks, budgets, chaos)", + "location": "§37.1, part4_fit.tex 669-673", + "used_in_frame": "25 (as 3-row table)" + } + ], + "script_boxes_dropped": [], + "open_issues": [ + "No ailinse box exists in the assigned passages (§30-32, §34, §37 intro), so the deck has no dedicated 'AI Lens' frame -- unlike decks 3-6. The only Axis-B material is the §37.1 sentence 'token-cost budgets and p95 latency budgets per AI use case are the same mechanism with new units' (line 671); it is set in bold in frame 25 and mapped onto item 3 of the A2 measurement contract in frame 27. An AI-lens frame would need a script addition (recorded for the script maintainer), not a deck-side invention.", + "§37 now spans four frames (23 intro, 24 definition, 25 instrument families, 26 DORA; 10 minutes) against the brief's '2-3 frames': the high-severity density finding on the former combined definition/families frame forced the split. Content was thinned to an introduction (tool analogues trimmed, no Depth line on the DORA frame, the deployments-per-developer finding reduced to a deck-5 pointer); the taxonomy in CI/CD, the four-layer cascade and Boehm vs Menzies remain Lecture 11.", + "Frame 25: the family-2 scope/cadence cell reads '(pipeline gate)' without a scope label -- the script (line 671) classifies only family 1 ('atomic, triggered', line 670) and family 3 ('continual holistic', line 672).", + "§37 opening refers to 'Step (vii)' of the eight-step decision procedure (§36, Lecture 10). Frame 23 names it as 'the seventh step of the eight-step decision procedure (Section 36, Lecture 10)' without explaining the other steps.", + "The C6 profile (frame 5) and the C2 five-second delivery scenario S2 (frame 10) are Part III material (Lectures 9 and 8); both are presented as 'given here', not 'recalled'. The C1 and C2 High sets are recalled from the deck-6 mirror pair. The 'verdict the class's Part III section states' lines (frames 6, 9, 12) refer to sections students have not read yet.", + "Case 2 (frame 8) states the escalation condition 'recorded in the cell rationale of Section 33' -- the rationale itself is Lecture 10 material; the deck only names the condition (D11 High and the Monzo homogeneity condition).", + "Frame 11's table labels the High-set dimensions by their standard names (D1 read scalability, D3 latency, ...); the passage (line 68) gives the two rating sequences by position only, in the order D1, D3, D5, D7, D9, D11.", + "Frame 8 deliberately omits MS's ratings on D5/D6/D7/D9 for C1 -- the passage states only c4(MS) = --, and -- on D8/D10 (Low); the complete MS column is available from tab:capability (deck 6) but is not in the assigned text.", + "Frame 20, bullet 2: the script's sentence (line 471) says the shape gate 'caps them at o everywhere the class core is interactive', while its own table shows EDA at - for C1, C3, C4 and PF at - for C9 (harm-clause results of the same gate). The slide rewords to 'caps them at o -- or, by the harm clause, below --'; the tension in the script itself is recorded for the script maintainer.", + "Frame 22 speaker notes carry an 'expected direction' for the thinkbox (D11 -> High re-runs Stage 2/3 in MS's favour; traffic x50 moves D1/D2 but MM's mitigations hold). It is inferred from §34.1/§34.2, not stated in the script; it must not migrate onto the slide.", + "Frame 13 labels the per-constitutive-path clause 'not shown in deck 3' -- a deck-level highlight; the script (line 89) presents it as part of the definition, not as new.", + "Frame 27 item 1 adds 'and the AI subsystem' to the M2 taskbox wording ('Bounded contexts -> service decomposition and contracts', lines 408-410); consistent with the deck-6 projektbox, not in the taskbox. 'One-lesson (one-hour)' matches both the semester plan's 3+1 and the exercise sheet's 'one-hour standup/coaching session' (line 361).", + "tab:fitmatrix is a sidewaystable in the script; on the slide it is an upright scriptsize table (p{4.2cm} class column + 7 centred columns), the same format deck 6 used for the consolidated capability table -- verify visually after the build.", + "Deck 6's 'Next week' frame announced reading 'Part IV, sections 1--3' while the title-slide line here is 'Part IV, Sections 30--32, 34; Section 37 (introduction)' -- section numbering follows the script's global numbering; the deck uses the title-slide line.", + "Minutes: content frames 4-26 sum to 70; with agenda (1), recap (3), exercise (3), summary (2), next week (1) the deck plans 80 of 90 minutes -- 10 minutes slack for the silent matrix minute and a discussion that overruns. If time is short, frame 20's excerpt table can be skipped verbally (the bullets carry the claims).", + "Residual density risks (all fallbacks recorded in the notes): frame 7 has 8 bullets (merged Stage 1 + Stage 2 for MS) -- keep bullets 3, 7, 8 to one line; frame 13 may still need a '(1/2)/(2/2)' split if the deck-3 box length is exceeded." + ], + "total_frames": 30 +} diff --git a/Folien/Planung_7-13_json/L8.json b/Folien/Planung_7-13_json/L8.json new file mode 100644 index 0000000..a227485 --- /dev/null +++ b/Folien/Planung_7-13_json/L8.json @@ -0,0 +1,1110 @@ +{ + "lecture": 8, + "week": 8, + "lessons": 3, + "title": "Lecture 8: Requirements Profiles I -- Application Classes C1--C5", + "script_reference": "Script: Part III, Sections 18--23", + "agenda": [ + "Application classes as requirements profiles -- method recall (weights, shape, constraints); the map of ten classes", + "\\textbf{C1} -- Core banking / transaction systems: the double impossibility", + "\\textbf{C2} -- Social media / content platforms: 50:1 and the fan-out", + "\\textbf{C3} -- Back-office / workflow: the modal, unglamorous case", + "\\textbf{C4} -- ERP / enterprise core: integration \\emph{is} the product", + "\\textbf{C5} -- E-commerce: quality attributes with price tags", + "Five classes side by side -- five verdicts as previews for Part IV", + "This week's exercise: \\textbf{the walking skeleton} (M3)" + ], + "recap": [ + "Lecture 6 closed Part II: the consolidated capability table, Maxims 3 and 4 (quantum count; partitioning beats distribution), ordinal reading only -- every cell a default hypothesis", + "Lecture 6 also opened Part III with \\textbf{C10}, the class of your project: Highs on D6/D7/D9/D10/D12, the binding scenarios, the verdict (hexagonal modular monolith + PF + EDA) -- and the C1/C2 mirror pair in one frame: \\emph{weights, not dimensions, define a class}", + "Lecture 7 (Part IV): three cases, three stages; the procedure in general; reading the $7 \\times 10$ matrix; the measurement contract introduced -- A2 architecture dossier and the design-review gate: implementation is free", + "Method recall from Lectures 2--3: $R(a) = (w_1 \\ldots w_{12};\\, S(a);\\, K(a))$ -- weights from the (H,\\,H) leaves of the utility tree, shape as a gate, constraints as knock-outs; every High is a veto trigger with the cap rule of the three-stage procedure", + "Today: back to the demand side, properly -- Part III in its class rhythm for C1--C5: \\emph{challenges $\\to$ binding scenarios $\\to$ profile $\\to$ what real systems chose}; every closing verdict is a preview that Part IV recomputes", + "Project: the design phase is over -- the implementation phase opens with milestone M3, the walking skeleton (weeks 8--9; numbering as in the taskboxes of the exercise sheet)" + ], + "frames": [ + { + "no": 1, + "deck_section": "Title", + "title": "AISE502: AI in Software Engineering II -- Lecture 8: Requirements Profiles I -- Application Classes C1--C5", + "kind": "content", + "script_ref": "Title slide; Script: Part III, Sections 18--23", + "content": [ + "\\FHGRTitlePage with subtitle 'Lecture 8: Requirements Profiles I -- Application Classes C1--C5' and script line 'Script: Part III, Sections 18--23'" + ], + "elements": [ + "\\FHGRTitlePage (theme)" + ], + "minutes": 0, + "notes": "Same metadata block as deck 6; only \\subtitle changes." + }, + { + "no": 2, + "deck_section": "Agenda", + "title": "Agenda", + "kind": "agenda", + "script_ref": "Deck skeleton (decks 1-6)", + "content": [ + "1. Application classes as requirements profiles -- method recall (weights, shape, constraints); the map of ten classes", + "2. C1 -- Core banking / transaction systems", + "3. C2 -- Social media / content platforms", + "4. C3 -- Back-office / workflow applications", + "5. C4 -- ERP / enterprise core systems", + "6. C5 -- E-commerce platforms", + "7. Five classes side by side -- five verdicts as previews for Part IV", + "8. This week's exercise: the walking skeleton (M3)" + ], + "elements": [ + "enumerate, \\small, itemsep 1pt (deck-6 style)" + ], + "minutes": 1, + "notes": "Point out the rhythm once: every class = intro -> challenges -> scenarios and K -> profile -> real systems -> lens/key concept. The rhythm strip itself sits on frame 4." + }, + { + "no": 3, + "deck_section": "Recap", + "title": "Recap: where we are", + "kind": "recap", + "script_ref": "Deck 6 summary and 'Next week' frame (AISE502_Vorlesung_6_Folien.tex 660-698); semester plan rows 6-8; deck 2 frames 691-780 (R(a) method); deck 3 line 389 (veto caps); project_exercise.tex 355-363 (two phases) and taskbox M3 (416-422)", + "content": [ + "Lecture 6 closed Part II: consolidated capability table, Maxims 3 and 4 (quantum count; partitioning beats distribution), ordinal reading only -- every cell a default hypothesis", + "Lecture 6 opened Part III with C10: Highs on D6/D7/D9/D10/D12, binding scenarios, verdict hexagonal MM + PF + EDA -- and the C1/C2 mirror pair in one frame: \\emph{weights, not dimensions, define a class}", + "Lecture 7 (Part IV): three cases, three stages; the procedure in general; reading the $7 \\times 10$ matrix; the measurement contract introduced -- A2 dossier and design-review gate passed: implementation is free", + "Method recall (Lectures 2--3): $R(a) = (w_1 \\ldots w_{12};\\, S(a);\\, K(a))$ -- weights from the (H,\\,H) leaves; shape gates; constraints knock out; every High is a veto trigger with the cap rule", + "Today: the demand side in its full class rhythm for C1--C5 -- \\emph{challenges $\\to$ binding scenarios $\\to$ profile $\\to$ what real systems chose}; each verdict a preview that Part IV recomputes", + "Project: design phase over -- the implementation phase opens with M3, the walking skeleton (weeks 8--9)" + ], + "elements": [ + "bullet list, \\footnotesize" + ], + "minutes": 3, + "notes": "No deck 7 file exists yet; the Lecture-7 bullet is taken from the semester plan row 7 and the deck-6 'Next week' frame -- adjust wording once deck 7 is typeset." + }, + { + "no": 4, + "deck_section": "Application Classes as Requirements Profiles", + "title": "Part III: the demand side, in the same vocabulary", + "kind": "definition", + "script_ref": "§18 opening (part3_application_classes.tex 12-27) and §18.4 rhythm sentence (line 112)", + "content": [ + "\\emph{Part II priced the supply side: seven patterns, each a capability profile $C(p)$ over the twelve dimensions. Part III characterises the demand side -- and A2 and A3 require it in the \\textbf{same} vocabulary at the \\textbf{same} resolution.}", + "'We are building a banking system' carries almost no architectural information; 'an instant payment must reach confirmed finality in under ten seconds end-to-end, with zero transaction loss, under a regulator-enforced audit obligation' carries almost all of it -- the unit that packages such statements is the \\textbf{application class}", + "[body of the definitionbox] Definition (application class): a recurring bundle of architecturally significant requirements (ASRs) -- a set of dominant quality attribute scenarios with \\emph{typical response measures}, a characteristic \\emph{workload shape} with its quantitative signature, and a \\emph{regulatory frame} acting as hard constraints", + "[body of the definitionbox, display math] $R(a) = \\bigl(w_1(a), \\ldots, w_{12}(a);\\; S(a);\\; K(a)\\bigr)$ with $w_i(a) \\in \\{\\text{H}, \\text{M}, \\text{L}\\}$, $S(a)$ the dominant workload shape, $K(a)$ the set of hard constraints", + "[one-line rhythm strip] Ten sections, one rhythm -- Part II turned around: \\textbf{leading question} $\\to$ \\textbf{the challenges it brings} $\\to$ \\textbf{the requirements profile} $\\to$ \\textbf{what real systems chose, and why}; challenges first, weights after, structures last -- every closing recommendation is a \\emph{preview} that Part IV recomputes" + ], + "elements": [ + "definitionbox[Application class] from lines 18-25 -- bullets 3-4 are its body, the formula in display math inside the box", + "one-line horizontal tikz strip of four rounded boxes (question -> challenges -> profile -> real systems) from §18.4 line 112, replacing the former 'How to read the class sections' frame" + ], + "minutes": 3, + "notes": "The frame carries only: the leading italic sentence in bankblue, the two 'banking' quotations, the definition box (\\footnotesize) and the one-line rhythm strip -- nothing else. Bridge spoken from line 27: 'two pieces of method recall before the catalogue, because every class section uses them' -> frames 5-6." + }, + { + "no": 5, + "deck_section": "Application Classes as Requirements Profiles", + "title": "Method recall: where the weights come from (Lectures 2--3)", + "kind": "content", + "script_ref": "§18.1 (part3_application_classes.tex 29-41); recall of deck 2 frame 'From leaves to weights' (692-702) and deck 3 definitionbox fit(a,p) stage 2 (389)", + "content": [ + "(Lecture 2) A4 recalled: a quality attribute is decision-relevant only as a six-part scenario; ASRs are elicited, not guessed (QAW, ATAM utility tree), each leaf rated (business importance, achievement difficulty) on \\{H, M, L\\}", + "(Lecture 2) \\textbf{The (H,\\,H) leaves of a class's characteristic utility tree \\emph{are} the High weights of $R(a)$}", + "New in Part III: a weight is a \\textbf{compressed empirical claim} -- 'systems of this class recurrently produce (H,\\,H) scenario leaves on this dimension' -- and each class section makes it \\textbf{auditable}: documented challenges (incidents, production numbers, statutory obligations) $\\to$ two to three \\emph{binding scenarios} with response measures, populating the (H,\\,H) region", + "(Lecture 3) \\textbf{H} -- veto power: $--$ on an H dimension caps the fit at $-$, $-$ caps at $\\circ$, unless a documented mitigation with production evidence; \\textbf{M} -- measured, conflicts noted not vetoed, clustered Medium conflicts downgrade one step; \\textbf{L} -- does not discriminate for this class; optimising it is waste", + "Important Note: there is no weighted sum -- profiles are ordinal, aggregation non-compensatory. \\textbf{An H weight is a veto trigger, not a coefficient.} Ten excellent Mediums cannot buy back one violated High" + ], + "elements": [ + "hinweisbox from lines 39-41 (condensed; the ledger simile is dropped here -- it returns on frames 10-11)" + ], + "minutes": 3, + "notes": "§18.1 is labelled 'method recall' by the script itself (line 27). Bullets 1, 2 and 4 are tagged as recall and kept to one line each; the genuinely new payload is bullet 3 (lines 33-35) and the box. Body \\footnotesize." + }, + { + "no": 6, + "deck_section": "Application Classes as Requirements Profiles", + "title": "Workload shape and hard constraints", + "kind": "keyconcept", + "script_ref": "§18.2 (part3_application_classes.tex 43-52); recall of deck 2 frame 'The last two components: shape and constraints' (735-752)", + "content": [ + "(recall, Lecture 2) $S(a)$ -- interactive, continuous stream, scheduled batch, explicitly hybrid; the \\emph{shape gate}: a pattern whose native shape does not match the dominant $S(a)$ cannot carry the class's core; every shape has a quantitative signature reported with production numbers -- \\emph{a workload claim without a number is as unfalsifiable as a scalability requirement without one}", + "(recall, Lecture 2) $K(a)$ -- \\textbf{knock-out filters, not weights}: a violating pattern or deployment form is excluded before any scoring and can never be averaged away", + "The regulatory inventory of this catalogue: BCBS 239, FINMA Circular 2023/1, DORA, PCI DSS v4.0, the EU AI Act -- plus organisational facts (team size and skills, mandated platforms, budget)", + "Regulation is a first-class architectural requirement that \\textbf{translates directly into structure}: immutable journals, scope zoning, data classification at module boundaries, logging obligations for AI components", + "Key Concept: an application class is an ASR bundle, not an industry label -- weights from the (H,\\,H) leaves, shape gates the core, constraints knock out before scoring. One organisation operates \\emph{several} classes at once -- a bank runs a C1 booking core, C3 back-office workflows, C6 overnight risk runs, C7 reporting and increasingly a C10 advisory layer -- so the fit matrix is read \\textbf{per subsystem, never per company logo}: your project's inheritance diagram (Lecture 6: C10 inherits C6/C7/C3) is exactly that reading" + ], + "elements": [ + "keypoint from lines 50-52 (condensed; last clause recalls the deck-6 inheritance diagram)" + ], + "minutes": 2, + "notes": "Bullets 1-2 are marked recall; new for this lecture are the regulatory inventory, 'regulation translates into structure' (lines 46-48) and the keypoint. The bank-with-five-classes sentence recalls the inheritance diagram of deck 6 (frame 'C10 -- your project as an inheritance diagram'), it does not prepare it." + }, + { + "no": 7, + "deck_section": "Application Classes as Requirements Profiles", + "title": "A map of the ten classes", + "kind": "diagram", + "script_ref": "§18.3 (part3_application_classes.tex 54-108)", + "content": [ + "C1 and C2 at opposite ends of the consistency axis within the same band -- the didactic \\textbf{mirror pair}; C10 the only class whose \\emph{shape} is constitutively hybrid", + "Today's five all sit in the interactive band -- read them along the axis: C1/C4 strict ACID, C3 ACID-leaning, C5 split by subsystem, C2 eventual" + ], + "elements": [ + "tikz fig:classmap, lines 58-108 -- redraw at \\resizebox{0.85\\textwidth} with rounded rectangles; colours inter=bankblue, stream=bankgreen, batch=gray, hybrid=bankblue!70!black (script's projteal is not defined in the deck preamble -- define or alias it); highlight today's five nodes with a thicker frame; two \\footnotesize lines beneath the figure" + ], + "minutes": 3, + "notes": "Only the two bullets go on the slide; the rest is spoken from these notes: (i) two variables discriminate more than any others -- dominant workload shape (bands) and consistency semantics the core requires (axis); (ii) the axis is ordinal, not metric: strict ACID -> hybrid split by subsystem -> causal / per-key / by contract -> eventual; (iii) interactive band: C1 ACID ledger, C4 + batch runs, C3, C5 checkout ACID / catalogue eventual, C9 connection-stateful causal per channel, C2 stale feed acceptable; (iv) stream band C8 (event time, exactly-once state); batch band C6 (reproducible, seeds) and C7 (fresh by refresh contract); hybrid band C10 (index eventual, audit path ACID); (v) C6 reproducibility and C7 freshness by refresh contract are a third family of semantics, neither ACID nor eventual -- Lecture 9. On the map C3 sits between the ACID tick and the hybrid tick without a sub-label, hence 'ACID-leaning'; the C4 keypoint (frame 33) makes the ACID claim explicit. Verify with pdftoppm that the axis labels do not collide." + }, + { + "no": 8, + "deck_section": "Application Classes as Requirements Profiles", + "title": "Discussion: classification is a hypothesis -- test it on three systems", + "kind": "discussion", + "script_ref": "§18.4 hinweisbox and thinkbox (part3_application_classes.tex 113-119)", + "content": [ + "Important Note: classifying a concrete system as an instance of a class is step (i) of the decision procedure -- a \\emph{hypothesis about the system's ASR bundle}, to be inherited and then corrected against elicited scenarios, never a verdict. Real systems blend classes; \\textbf{the blend, not the label}, is what the utility tree must capture", + "Take three software systems you have used this week -- your e-banking app, a messaging tool, a streaming service", + "Which application classes do they instantiate?", + "Which single quality attribute scenario, with which response measure, would you nominate as each system's most binding requirement?", + "Where would a failure of that scenario become visible first: in revenue, in a regulator's report, or in user churn?" + ], + "elements": [ + "hinweisbox from lines 113-115 (condensed) as the lead-in at the top of the frame", + "thinkbox from lines 117-119 with the three questions" + ], + "minutes": 3, + "notes": "3 minutes of pair talk; collect two answers, place them on the map of frame 7 (go back one frame) -- and point out where an answer is a blend rather than a label." + }, + { + "no": 9, + "deck_section": "C1 -- Core Banking", + "title": "Part III in the class rhythm: C1 -- Core banking / transaction systems", + "kind": "content", + "script_ref": "§19 opening (part3_application_classes.tex 125-128)", + "content": [ + "\\emph{A payment is booked twice, or not at all: which of the two can a bank survive?} Neither -- and that double impossibility is the class in one sentence", + "Systems of record for accounts, payments and positions: the booking core of a bank, a payment-clearing platform, an exchange's matching and settlement layer -- the machinery behind your e-banking balance, the card authorisation at the till, the salary on the 25th", + "Defining property: a lost or double-posted booking event is an \\textbf{existential} defect -- it creates or destroys money -- whereas unavailability is expensive but reversible", + "Double-entry bookkeeping demands atomic, serialisable transactions over the ledger: classical ACID territory. Auditability is a regulator-enforced obligation: every state change journaled and reconstructable -- which is why event-sourced journals and ledger data models fit naturally", + "Three challenges define the class: (1) \\textbf{the sums at stake} (D4, D6); (2) \\textbf{a speed spread of six orders of magnitude} within one class (D3, D2, D5); (3) \\textbf{time} -- lifetimes measured in decades (D7)" + ], + "elements": [ + "italic leading question in bankblue (deck 4-6 style); numbered challenge list" + ], + "minutes": 3, + "notes": "Reference the deck-6 mirror-pair frame in one spoken sentence ('you saw the headline; now the derivation'). Do not repeat its bullets." + }, + { + "no": 10, + "deck_section": "C1 -- Core Banking", + "title": "C1 -- the challenges in numbers", + "kind": "content", + "script_ref": "§19.1 (part3_application_classes.tex 130-136)", + "content": [ + "\\textbf{Sums.} Swiss Interbank Clearing settles on average roughly CHF 226 billion per day, peaks above CHF 386 billion -- a double-posted or lost booking is a balance-sheet event: D4 and D6 before any other consideration. Every payment is a write surrounded by reads (cover checks, sanctions screening, fraud scoring): \\emph{write-critical} -- but the \\emph{concurrency} of writes against shared accounts, not their raw rate, stresses D4", + "\\textbf{Speed spread.} Batch clearing hours; instant payments under 10 s; card authorisation 1--2 s; exchange trading microseconds -- latency means something different in each regime, hence D3 \\textbf{Medium with a footnote}, not High", + "SIC5 instant-payment infrastructure: dimensioned for peaks in the order of 2,000 payments/s, clustered in-memory replicated-state-machine design. VisaNet: \\emph{capacity} above 65,000 transaction messages/s while average load lies orders of magnitude below -- capacity dimensioning vs.\\ normal load, the reason D2 is \\emph{planned, not elastic}", + "Load constant with deterministic peaks (end of day, end of month, salary runs); unavailability is a loss event on national infrastructure with regulator-defined disruption tolerances -- D5", + "\\textbf{Time.} Reuters 2017: 220 billion lines of COBOL in production, 43\\,\\% of US banking systems COBOL-based -- ossification is the documented failure mode, which makes D7 a High \\emph{requirement} precisely because it is so often unmet. Change rate bimodal: booking core rarely, periphery (channels, onboarding, products) constantly. Data structured, records small, retention extreme -- ten years and more" + ], + "elements": [ + "\\footnotesize bullets, bold challenge labels; numbers in text; target 13-14 lines" + ], + "minutes": 3, + "notes": "The SWIFT/ISO 20022 evidence is spoken from here, not typeset: 'SWIFT carried over one million ISO 20022 messages per day by the end of 2024, with the MT/MX coexistence phase ending in November 2025 -- a multi-year, industry-wide coordinated interface migration, again a D7 stress' (script line 134, written before the cut-over; by the lecture date the phase has ended). The former SIC5/VisaNet bullet is split into its two claims (capacity vs. load; load pattern and D5) to keep every bullet at three lines or fewer." + }, + { + "no": 11, + "deck_section": "C1 -- Core Banking", + "title": "C1 -- the binding scenarios and the knock-outs", + "kind": "content", + "script_ref": "§19.1 scenarios and K (part3_application_classes.tex 138-146)", + "content": [ + "Three scenarios compress these challenges into the (H,\\,H) region of the C1 utility tree -- \\textbf{Assumption A4 in action}; every High in the next table traces to one of them", + "\\textbf{S1 (instant payment finality).} A customer submits an instant payment (stimulus) in normal operation to the payment core; it clears, settles and posts with confirmed finality \\textbf{in under 10 seconds end-to-end, with zero transaction loss} -- the SIC5 operating regime. D3, D4, D5", + "\\textbf{S2 (ledger integrity under concurrency).} Concurrent postings against the same account at peak load leave the double-entry invariant intact: \\textbf{zero invariant violations, verified by a daily reconciliation job with zero unexplained discrepancies}. The D4 veto scenario -- and, through the reconciliation job, D9", + "\\textbf{S3 (audit-trail reconstruction).} An auditor requests the complete causal history of one transaction chosen at random, up to ten years back; the full trail is reproduced \\textbf{within one working day, from immutable records} -- BCBS 239's aggregation and reporting principles read operationally. D6, D9", + "$K(\\text{C1})$ -- the densest constraint set in the catalogue: BCBS 239 (demonstrable risk-data aggregation and reporting: integration and lineage); FINMA Circular 2023/1 (in force 1 January 2024: ICT risk, protection of \\emph{critical data}, business continuity with disruption tolerances); DORA (EU 2022/2554, applicable 17 January 2025: ICT risk, incident reporting, resilience testing, third-party register); GDPR throughout", + "\\textbf{Knock-out reading:} any structure that cannot guarantee an ACID booking core, an immutable and complete audit journal, and ten-plus-year retention is eliminated \\emph{before} any fit scoring -- however well it scales" + ], + "elements": [ + "one-line lead sentence (line 138); three scenario bullets in deck-6 'binding scenarios' style with (D\\_i) tag in codegray; K paragraph as bold-led text" + ], + "minutes": 4, + "notes": "Same layout as deck 6 'C10 -- the binding scenarios'. Response measures in bold. The lead line closes the chain from frame 5 (challenges -> (H,H) leaves -> High weights); it is repeated as a short tag on frames 17, 23, 30 and 36. Here the ledger simile of the §18.1 box is spoken ('no feature velocity buys back a double-posted booking'). If overfull, shorten the parentheticals of the K bullet, not the scenarios." + }, + { + "no": 12, + "deck_section": "C1 -- Core Banking", + "title": "C1 -- requirements profile (column C1)", + "kind": "table", + "script_ref": "§19.2 tab:req-c1 (part3_application_classes.tex 148-178)", + "content": [ + "D1 Read scalability -- M -- reads surround every posting; volumes modest", + "D2 Write scal.\\ \\& elasticity -- M -- constant load, deterministic peaks; capacity planned, not elastic", + "D3 Latency -- M -- spread of orders of magnitude: microseconds to hours", + "D4 Consistency \\& integrity -- \\textbf{H} -- a lost or double-posted booking creates or destroys money", + "D5 Availability \\& isolation -- \\textbf{H} -- payment rails are national infrastructure; outages are loss events", + "D6 Security \\& auditability -- \\textbf{H} -- the immutable audit journal is a statutory obligation", + "D7 Evolvability -- \\textbf{H} -- decades-long lifetimes; ossification is the failure mode", + "D8 Simplicity \\& TTM -- L -- time-to-market traded for integrity without hesitation", + "D9 Testability \\& deployability -- \\textbf{H} -- reconciliation and trail reconstruction verifiable by construction", + "D10 Operating cost -- L -- run cost traded for integrity as willingly as D8", + "D11 Team scaling -- M -- binds only at neobank organisational scale -- the Monzo condition", + "D12 AI integrability -- M -- fraud scoring at the edge; the booking path stays deterministic", + "Shape $S(a)$: interactive (+ batch edges). Constraints $K(a)$: BCBS 239; FINMA 2023/1; DORA; ACID core; 10+ yr retention" + ], + "elements": [ + "12-row requirements-profile table (scriptsize, arraystretch 0.8, p{3.0cm}cp{7.7cm}, \\vspace{-0.35cm}) from tab:req-c1 lines 152-178, plus Shape and Constraints rows; Highs bold; every 'Why' cell at most ~65 characters, one line, no parentheticals, no inline footnotes" + ], + "minutes": 4, + "notes": "Five Highs: D4/D5/D6/D7/D9. Weights, Shape and Constraints cell-identical with the script; 'Why' cells are one-line condensations of lines 162-173 (row label 'D5 Availability \\& isolation' follows the deck-6 convention, script says 'fault isolation'). Spoken from the notes, not typeset: note 3 (batch clearing hours, instant payments <10 s, card authorisation 1-2 s, trading microseconds); D1's read list (cover checks, sanctions, fraud scoring) was on frame 10; D6's statute list is on frame 11. Point at the two Lows: this class pays with D8 and D10." + }, + { + "no": 13, + "deck_section": "C1 -- Core Banking", + "title": "C1 -- what real systems chose, and why", + "kind": "case", + "script_ref": "§19.3 text and keypoint (part3_application_classes.tex 180-184, 190-192); deck 4 line 534 (Fineract study)", + "content": [ + "Two documented production systems show this profile does \\emph{not} determine a single pattern", + "\\textbf{LMAX} (retail trading): six million orders/s on a \\emph{single} JVM thread -- in-memory, event-sourced, deterministic sequential core with lock-free ring buffers. Serialisable \\emph{by construction} (the strongest answer to the D4 veto); deterministic replay of the journal answers D6 and D9 at once; surrenders elastic write scaling (D2) -- weighted only Medium", + "\\textbf{Monzo} (UK digital bank): ca.\\ 2,800 Go microservices (ca.\\ 1,600 in 2020), viable only through extreme homogeneity -- one language, one monorepo, central migration automation. Binding dimension D11, where the MS column excels; the $--$ on simplicity and cost paid deliberately; the D4 risk of sagas in the money path mitigated by homogeneity and central tooling", + "\\textbf{Apache Fineract} -- the 34-module single deployable you inspected in week 4, now read from the demand side: a modular monolith behind a REST facade -- one ACID quantum serves the D4 veto; domain modules absorb the peripheral change rate (D7); the weak cell, $-$ on D5 (one process as blast radius), mitigated by hot-standby replication. A standing counter-example to 'banking at scale implies microservices'", + "Key Concept: $R(a)$ alone does not force one pattern; it defines the feasible set, and constraints decide within it. C1's veto dimensions -- D4, D5, D6, D7, D9 -- eliminate structures that cannot carry an ACID, journaled, decades-lived core; they do \\emph{not} rank the survivors. The LMAX/Monzo pair is evidence \\textbf{for} the theory, not against it" + ], + "elements": [ + "\\footnotesize bullets; system names bold", + "keypoint from lines 190-192 (condensed) as the closing box" + ], + "minutes": 3, + "notes": "The examplebox 'LMAX versus Monzo' (lines 186-188) was shown in Lecture 3 (deck 3 407-408) and in the deck-6 mirror-pair frame -- one spoken sentence only: 'same profile, opposite structures -- LMAX's binding scenario microsecond-scale deterministic ordering, Monzo's binding constraint scaling hundreds of engineers safely; A2 resolved twice, in opposite directions, within one feasible set'. Fineract: students read its code in week 4 (34 fineract-* Gradle modules, custom/ extension directory) -- ask them where the hot-standby mitigation sits. Density: four bullets plus box at \\footnotesize; the 'both banking-grade with opposite structures' sentence is spoken, not typeset." + }, + { + "no": 14, + "deck_section": "C1 -- Core Banking", + "title": "C1 -- AI lens and the verdict", + "kind": "ailens", + "script_ref": "§19.3 ailinse and closing sentence (part3_application_classes.tex 194-198)", + "content": [ + "AI Lens (Fraud scoring at the edge of the ledger, Axis B): AI enters C1 at the periphery, never in the booking path -- fraud and sanctions scoring are ML classification components (millisecond latency, deterministic after training) consulted \\emph{before} a posting is committed; increasingly LLM-based components for case triage and customer communication", + "D12 is Medium precisely because of this placement: the deterministic core must be isolatable from the probabilistic edge -- a ports-and-adapters discipline. A fraud model that could abort or mutate a posting mid-transaction would violate the D4 veto. \\textbf{The rule 'agents propose, deterministic services decide and book' originates in this class}", + "Where the winning structures' weak cells bite, practice \\emph{places} patterns rather than replacing them: the immutable event journal -- EDA's natural artefact -- serves as the regulatory audit trail at the core's edges; end-of-day clearing, statements and risk runs are genuine PF batch runs beside the interactive core", + "\\textbf{Verdict (preview):} primary -- a hexagonal modular monolith for the booking core (MM and HX at $++$); secondary -- EDA at the edges, PF for the batch runs; microservices only when organisation size forces D11 to High, the Monzo condition. Part IV computes this through the three-stage procedure" + ], + "elements": [ + "ailinse[Fraud scoring at the edge of the ledger (Axis B)] from lines 194-196 (condensed)", + "verdict as bold-led closing paragraph (deck-6 style)" + ], + "minutes": 3, + "notes": "Link to the project hint 'keep the deterministic core free of LLM calls -- this is the line that is graded'." + }, + { + "no": 15, + "deck_section": "C2 -- Social Media / Content Platforms", + "title": "C2 -- Social media / content platforms", + "kind": "content", + "script_ref": "§20 opening (part3_application_classes.tex 203-206)", + "content": [ + "\\emph{Three hundred thousand people refresh their feed every second while six thousand post: what structure serves the ratio?}", + "Consumer platforms whose product is a continuously updated content feed: social networks, media-sharing platforms, content communities -- the apps that fill the tram ride", + "Defining property: the exact inversion of C1 -- a feed that is a few seconds \\emph{stale} is acceptable; a feed that does not \\emph{load} is not", + "Consistency is explicitly negotiable -- eventual consistency is a design choice, not a defect -- while read scalability, availability and feed latency carry the binding scenarios", + "Three challenges: (1) \\textbf{the 50:1 ratio and the fan-out amplification} (D1, D2); (2) \\textbf{the pace of the product} (D7, D9, D11); (3) \\textbf{spiky, viral load} (D5, D3)" + ], + "elements": [ + "italic leading question in bankblue; numbered challenge list" + ], + "minutes": 3, + "notes": "Light frame; the numbers come on the next one." + }, + { + "no": 16, + "deck_section": "C2 -- Social Media / Content Platforms", + "title": "C2 -- the challenges: the ratio, the pace, the spikes", + "kind": "content", + "script_ref": "§20.1 (part3_application_classes.tex 208-212)", + "content": [ + "\\textbf{The ratio.} Twitter's documented 2013 figures, still the canonical calibration: roughly 300,000 timeline reads/s against roughly 6,000 tweet writes/s -- about \\textbf{50:1}. A read path that carries the product at that ratio is a demand on D1 before anything else", + "Raw write rate modest; the \\textbf{fan-out amplification} is not: one write by an account with millions of followers implies millions of logical deliveries. The naive materialisation ('\\texttt{SELECT} over all follows at read time') was tried and abandoned; the documented solution: fan-out-on-write into in-memory timeline caches (bounded to some 800 entries per home timeline), hybridised with fan-out-on-read for extreme-follower accounts", + "The textbook decision \\emph{write work versus read work as a function of the read/write ratio} -- and the reason D2 stays Medium: the amplification is absorbed by a dedicated fan-out subsystem, not by the write path proper", + "\\textbf{The pace.} Feature change rate among the highest in industry: permanent A/B experiments, daily deployments -- Instagram: roughly 100 deployments per day on a Django codebase of several million lines. A joint demand on D7, D9 and -- once the organisation grows into hundreds of feature teams -- D11", + "\\textbf{The spikes.} Spiky and viral load (breaking news, events), traffic multiplying within minutes: stresses D5 and keeps D3 binding at global peak. Data volume very large, predominantly unstructured (text, images, video); platform long-lived, individual features short-lived" + ], + "elements": [ + "\\footnotesize bullets, bold challenge labels" + ], + "minutes": 4, + "notes": "Dense; itemsep 1pt. The 800-entry cache bound and the 50:1 ratio are the numbers to write on the board. Bullet 3 is the text of note 1 of the consolidated table (6 k writes/s vs 300 k reads/s) -- say so here, so the table frame needs no inline footnote." + }, + { + "no": 17, + "deck_section": "C2 -- Social Media / Content Platforms", + "title": "C2 -- binding scenarios and a light $K$", + "kind": "content", + "script_ref": "§20.1 scenarios and K (part3_application_classes.tex 214-222)", + "content": [ + "The (H,\\,H) leaves of the C2 utility tree -- A4 in action, each with its response measure:", + "\\textbf{S1 (feed latency).} A user opens the home feed at global peak; the feed renders with \\textbf{p99 server-side latency below 200 ms} -- the regime precomputed timelines and edge caches exist to meet. D1, D3", + "\\textbf{S2 (fan-out delivery).} A user posts in normal operation; the post becomes visible to followers \\textbf{within 5 seconds for the vast majority of accounts} -- Twitter's stated target, missed by design for extreme-follower accounts and compensated by hybrid fan-out. D2's amplification reading -- and a \\emph{licence} on D4: seconds of staleness are within contract", + "\\textbf{S3 (availability under viral spikes).} An external event multiplies traffic within minutes; the platform keeps serving feeds with \\textbf{SLO attainment maintained and the blast radius of any single component failure below a declared bound}. The D5 scenario", + "$K(\\text{C2})$ is comparatively light but not empty: the EU Digital Services Act (content-moderation, transparency and systemic-risk duties); GDPR (profiling, personal data)", + "Neither forces a consistency model -- which is precisely why this class can trade consistency away: the mirror image of C1, where regulation forbids exactly that trade. $K$ knocks out little; \\textbf{the discrimination work is done by the weights, not the constraints}" + ], + "elements": [ + "short (H,H)/A4 tag line; scenario bullets in deck-6 style" + ], + "minutes": 3, + "notes": "Contrast with frame 11: densest K versus lightest K." + }, + { + "no": 18, + "deck_section": "C2 -- Social Media / Content Platforms", + "title": "C2 -- requirements profile (column C2)", + "kind": "table", + "script_ref": "§20.2 tab:req-c2 (part3_application_classes.tex 224-254)", + "content": [ + "D1 Read scalability -- \\textbf{H} -- ca.\\ 50:1 read/write ratio -- the read path carries the product", + "D2 Write scal.\\ \\& elasticity -- M -- raw writes ca.\\ 6 k/s; fan-out absorbed by a subsystem", + "D3 Latency -- \\textbf{H} -- p99 below 200 ms at global peak or the product feels broken", + "D4 Consistency \\& integrity -- L -- a feed seconds stale is invisible; eventual by design", + "D5 Availability \\& isolation -- \\textbf{H} -- an unavailable feed is the defect; spikes arrive within minutes", + "D6 Security \\& auditability -- M -- DSA and GDPR duties matter but do not shape the topology", + "D7 Evolvability -- \\textbf{H} -- permanent A/B experiments; features live weeks, platform decades", + "D8 Simplicity \\& TTM -- M -- simplicity welcome but outbid by feature velocity at scale", + "D9 Testability \\& deployability -- \\textbf{H} -- ca.\\ 100 deployments per day need cheap, safe releases", + "D10 Operating cost -- M -- fleet cost matters but never vetoes the read path", + "D11 Team scaling -- \\textbf{H} -- hundreds of feature teams must deploy independently", + "D12 AI integrability -- M -- ranking and moderation are ML components off the p99 path", + "Shape $S(a)$: interactive read-heavy. Constraints $K(a)$: DSA; GDPR" + ], + "elements": [ + "12-row requirements-profile table (scriptsize, arraystretch 0.8) from tab:req-c2 lines 228-254, plus Shape and Constraints rows; Highs bold; one-line 'Why' cells (~65 characters max)" + ], + "minutes": 3, + "notes": "Six Highs, one Low on D4 -- point at the D1/D4 inversion relative to frame 12 (the mirror seen in deck 6, now derived). Note 1 was said on frame 16; D11's 'the documented growth bottleneck' is spoken." + }, + { + "no": 19, + "deck_section": "C2 -- Social Media / Content Platforms", + "title": "C2 -- what real systems chose, and why", + "kind": "case", + "script_ref": "§20.3 (part3_application_classes.tex 256-260)", + "content": [ + "\\textbf{Instagram} -- the documented monolith-at-scale case: to this day a Django monolith at its core, several million lines of Python, thousands of endpoints, roughly 100 deployments per day, scaled horizontally across tens of thousands of identical servers over sharded PostgreSQL and Cassandra", + "It exploits exactly the cell the L and MM columns share: stateless replication of the application tier scales \\emph{reads} far -- so D1 High is servable from a monolith. \\textbf{A monolith is a potential organisational problem, not a read-scaling problem}", + "A2 bites on D11: one release train throttles hundreds of teams -- why \\textbf{Twitter/X} migrated from a Rails monolith to JVM services as organisation and load grew, and why its fan-out is an \\emph{event flow} at heart: fan-out-on-write is publish/subscribe, the EDA column's home turf ($++$ on D1, D2 and D7's attach-new-consumers reading)", + "The MS column serves the same three Highs -- independent scaling of feed, media and graph services (D1), independent team deployments (D9, D11) -- at the documented price of $--$ on D8 and D10, accepted at this scale", + "\\textbf{Mastodon} (open-source reference): Rails monolith with Sidekiq job queues, PostgreSQL (single writer, read replicas), Redis as feed cache and queue backend, Node.js streaming API, federated via ActivityPub. The entire fan-out mechanic -- one Sidekiq job per follower feed -- is inspectable in source: \\emph{Mastodon is the secondary recommendation running in public}" + ], + "elements": [ + "\\footnotesize bullets; system names bold" + ], + "minutes": 3, + "notes": "Connect to deck 1 (Stack Overflow: read scaling from one quantum) in one spoken sentence -- not on the slide. 'The scaling limits of the Rails monolith are documented rather than hidden' is spoken." + }, + { + "no": 20, + "deck_section": "C2 -- Social Media / Content Platforms", + "title": "C2 -- AI lens and the verdict", + "kind": "ailens", + "script_ref": "§20.3 keypoint, ailinse, closing sentence (part3_application_classes.tex 262-270)", + "content": [ + "AI Lens (Feed ranking and moderation as runtime AI, Axis B): in C2, AI is the product's economic engine -- feed ranking, recommendation and content moderation are ML components \\emph{in the serving path}", + "They inherit the class's own discipline: ranking models trained in offline pipelines (a C6/C7-shaped subsystem) and served from precomputed feature stores at millisecond latency, so S1's p99 budget survives; moderation classifiers sit on the asynchronous ingestion path, where seconds of latency are invisible", + "General Axis-B rule (Part V): \\textbf{the latency class of the AI component, not its accuracy, decides where in the topology it may live}", + "Key Concept (recall, Lecture 6): C1 and C2 are mirror images across the consistency/availability trade -- same twelve dimensions, inverted weights on D1 and D4; \\emph{weights, not dimensions, define a class} -- now derived from both sides", + "\\textbf{Verdict (preview):} primary -- an EDA + microservices hybrid at organisational scale (MS and EDA at $++$); secondary -- a modular monolith until that scale is \\emph{measured}, not assumed. The deciding measurement: deployments per developer per day as teams multiply. Part IV recomputes" + ], + "elements": [ + "ailinse[Feed ranking and moderation as runtime AI (Axis B)] from lines 266-268 (condensed)", + "keypoint from lines 262-264 as a one-sentence keypoint box (recall-tagged; the full box was deck 6's mirror-pair frame)" + ], + "minutes": 3, + "notes": "The closing frame keeps the established two-box form (AI Lens + Key Concept) as in frames 14 and 27; the keypoint is a single sentence tagged as recall, so it does not repeat deck 6's full box." + }, + { + "no": 21, + "deck_section": "C3 -- Back-Office / Workflow", + "title": "C3 -- Back-office / workflow applications", + "kind": "content", + "script_ref": "§21 opening (part3_application_classes.tex 275-277)", + "content": [ + "\\emph{The organisation reorganises again, and by next sprint the approval workflow must follow: which structure absorbs its fortieth process change as cheaply as its first?}", + "Internal administration systems: case management, approval workflows, HR and procurement processes, departmental record-keeping -- the vacation request, the invoice approval, the onboarding checklist", + "The \\textbf{modal, unglamorous case} of industrial software -- systematically under-represented in engineering blogs precisely because nothing about it is spectacular, which is itself the didactic point", + "Users are employees, dozens to thousands; hours of downtime usually tolerable; load low and planable", + "Three challenges: (1) \\textbf{the organisation keeps changing under the software} (D7); (2) \\textbf{the budget} (D8, D10); (3) \\textbf{correctness with witnesses} (D4, D6)" + ], + "elements": [ + "italic leading question in bankblue; numbered challenge list" + ], + "minutes": 3, + "notes": "Light intro frame in the same rhythm as C1/C2/C4/C5; the numbers follow on the next frame." + }, + { + "no": 22, + "deck_section": "C3 -- Back-Office / Workflow", + "title": "C3 -- the challenges: reorganisation, budget, witnesses", + "kind": "content", + "script_ref": "§21.1 (part3_application_classes.tex 279-286)", + "content": [ + "\\textbf{Reorganisation.} The dominant challenge is not technical: the \\emph{organisation} keeps changing under the software. Maintenance and enhancement consume roughly 40--80\\,\\% (typically about 60\\,\\%) of life-cycle cost, mostly for adapting to reorganisations and process changes rather than repair -- the single strongest demand, on D7. Lifetimes 10--20 years and routinely beyond plan: the fortieth process change is not rhetorical", + "\\textbf{Budget.} Small internal teams against internal cost centres; every franc spent on platform machinery is a franc unavailable for the next reorganisation -- a standing demand on D8 and D10, and a standing veto against premium structures", + "\\textbf{Workload.} Almost no pressure: CRUD-dominated, moderately read-heavy (80/20 rule of thumb), office-hours load, gigabytes to a few terabytes of structured data -- D1, D2, D5 do not bind; a single relational ACID database almost always suffices; integration demand, however, is high", + "\\textbf{Witnesses.} Internal control systems demand enforced dual control and a complete audit trail per case -- D4 (transactional case state) and D6" + ], + "elements": [ + "\\footnotesize bullets, bold challenge labels" + ], + "minutes": 3, + "notes": "The budget paragraph and the workload paragraph are separate bullets. Spoken from the notes: the integration list (identity/LDAP, ERP, document management, e-mail) and 'often with document attachments'." + }, + { + "no": 23, + "deck_section": "C3 -- Back-Office / Workflow", + "title": "C3 -- binding scenarios and the knock-outs", + "kind": "content", + "script_ref": "§21.1 scenarios and K (part3_application_classes.tex 288-294)", + "content": [ + "The (H,\\,H) leaves of the C3 utility tree -- A4 in action:", + "\\textbf{S1 (process change dispersion).} The organisation changes an approval process; the change is implemented and released \\textbf{touching no more than the process definition and one module, within one sprint} -- change dispersion is the operative evolvability metric. The D7 scenario", + "\\textbf{S2 (four-eyes integrity).} A clerk approves a case that requires dual control; the system enforces the second approval and journals both: \\textbf{zero bypasses and a complete, sequential audit trail per case} -- the internal-control-system obligation read as a scenario. D4, D6", + "\\textbf{S3 (interactive adequacy).} A caseworker submits a form during office hours; the system responds \\textbf{within 1--2 seconds} -- internal users tolerate more latency than customers, but not unboundedly more. D3, weighted Medium", + "$K(\\text{C3})$: GDPR for employee data; statutory retention duties (Switzerland: Art.\\ 958\\emph{f} Code of Obligations -- business records retained for ten years); internal control systems with enforced dual control; for public administration additionally administrative law and accessibility requirements", + "\\textbf{Knock-out reading:} a structure that cannot produce a sequential, tamper-evident audit trail per case, or cannot guarantee retention, is excluded -- constraints that favour simple, journaled, transactional designs" + ], + "elements": [ + "short (H,H)/A4 tag line; scenario bullets in deck-6 style" + ], + "minutes": 3, + "notes": "Point out that S1's response measure is a change-dispersion count -- the metric introduced with D7 in deck 2." + }, + { + "no": 24, + "deck_section": "C3 -- Back-Office / Workflow", + "title": "C3 -- requirements profile (column C3)", + "kind": "table", + "script_ref": "§21.2 tab:req-c3 (part3_application_classes.tex 296-326)", + "content": [ + "D1 Read scalability -- L -- dozens to thousands of internal users at office-hours load", + "D2 Write scal.\\ \\& elasticity -- L -- two requests per second at the July peak -- nothing to elasticise", + "D3 Latency -- M -- 1--2 s form turnaround suffices, but not unboundedly more", + "D4 Consistency \\& integrity -- \\textbf{H} -- case state transactional; one skipped approval is an ICS finding", + "D5 Availability \\& isolation -- L -- hours of downtime are tolerable; the work waits", + "D6 Security \\& auditability -- \\textbf{H} -- four-eyes enforcement and a tamper-evident trail per case", + "D7 Evolvability -- \\textbf{H} -- ca.\\ 60\\,\\% of life-cycle cost is evolution, driven by reorganisations", + "D8 Simplicity \\& TTM -- \\textbf{H} -- small teams, internal budgets: simplest adequate structure wins", + "D9 Testability \\& deployability -- M -- releases weekly, not hourly; regression scope modest", + "D10 Operating cost -- \\textbf{H} -- the budget belongs to the next reorganisation, not platform staff", + "D11 Team scaling -- L -- one team, often part-time", + "D12 AI integrability -- L -- document extraction decorates the intake edge; core untouched", + "Shape $S(a)$: interactive. Constraints $K(a)$: retention law, e.g.\\ OR 958\\emph{f}; internal control systems; GDPR" + ], + "elements": [ + "12-row requirements-profile table (scriptsize, arraystretch 0.8) from tab:req-c3 lines 300-326, plus Shape and Constraints rows; Highs bold; one-line 'Why' cells" + ], + "minutes": 3, + "notes": "The only class among today's five with D8 = H and D10 = H -- mark those two rows; they carry the argument of frame 26. Scenario tags (S1-S3) are spoken." + }, + { + "no": 25, + "deck_section": "C3 -- Back-Office / Workflow", + "title": "C3 -- what real systems chose, and why", + "kind": "case", + "script_ref": "§21.3 (part3_application_classes.tex 328-332)", + "content": [ + "The modal industrial answer: a three-tier or modular-monolith application over one relational database -- the capability tables explain why in two steps", + "\\textbf{Step 1, column L:} serves D8 and D10 at $++$ -- one artefact, one pipeline, near-zero platform staff -- and its ACID cell serves the D4 veto; its weakness is exactly where this class hurts most, the $-$ on D7 $\\to$ layering fits only small, stable scope", + "\\textbf{Step 2, column MM:} the same run cost with domain boundaries that absorb the reorganisation-driven change rate -- D7 rises to $+$ while D4 and D10 keep their ratings, at the price of one step on D8 (boundary governance is a permanent line item): the Pareto choice when process change is frequent", + "\\textbf{Camunda} -- the class's other big lever, \\emph{externalising the thing that changes most}: Camunda 7 embeds the process engine as a Java library with relational persistence (monolith-friendly); Camunda 8 rebuilt the engine (Zeebe) as a partitioned, replicated, horizontally scalable distributed system. Process models in BPMN 2.0: when a reorganisation arrives, \\textbf{the process definition changes, not the codebase} -- S1 met by design", + "Open-source references for the forms-over-data core: \\textbf{Flowable}; the \\textbf{Frappe} framework underlying ERPNext -- metadata-driven DocTypes generate schema, forms and REST APIs" + ], + "elements": [ + "\\footnotesize bullets; no mini table" + ], + "minutes": 3, + "notes": "Spoken, not typeset: 'Camunda's product evolution is a miniature architecture lecture; the 7-to-8 migration documents precisely what distribution buys and what it costs'. The L-vs-MM cells are already in words in steps 1 and 2 -- no mini table." + }, + { + "no": 26, + "deck_section": "C3 -- Back-Office / Workflow", + "title": "C3 -- why this class punishes distribution", + "kind": "keyconcept", + "script_ref": "§21.3 examplebox and keypoint (part3_application_classes.tex 334-340); recall of deck 3 mini-match variant (AISE502_Vorlesung_3_Folien.tex 462-467)", + "content": [ + "Recall, Lecture 3 -- the mini-match variant against $R(\\text{back-office})$: you computed this. MS hits \\textbf{two unmitigated $--$ vetoes at once} (D8 and D10); verdicts L $+$, MM $++$, MS $--$. Today: the evidence behind those weights", + "Example: a vacation-approval workflow serving 800 employees, peaking at perhaps \\textbf{two requests per second} on the first workday of July. Every quality attribute microservices buy -- independent scaling, independent deployment by many teams, fault isolation across quanta -- is priced in platform staffing and operational complexity that this workload cannot amortise; the Segment case (Part I) showed a small team crushed by exactly this premium. C3 is the clearest instance of the rule that \\textbf{D8 = H and D10 = H jointly veto premium-priced structures}: the class needs its budget for the next reorganisation, not for a service mesh", + "Key Concept: C3 is the industry's modal case, and its profile rewards the simplest structure that meets the audit constraints -- evolution dominates the cost function, so D7 = H; nobody pays for scale that office-hours load never generates, so D8 = H and D10 = H. \\emph{Unglamorous is not a defect of this class -- it is its optimum}" + ], + "elements": [ + "one \\footnotesize recall line above the boxes", + "examplebox[Why this class punishes distribution] from lines 334-336 (condensed)", + "keypoint from lines 338-340" + ], + "minutes": 3, + "notes": "Recall line plus two boxes; nothing else. The strongest continuity link of the day: the students derived the L/MM/MS verdicts for this class in week 3 without the evidence." + }, + { + "no": 27, + "deck_section": "C3 -- Back-Office / Workflow", + "title": "C3 -- AI lens and the verdict", + "kind": "ailens", + "script_ref": "§21.3 ailinse and closing sentence (part3_application_classes.tex 342-346)", + "content": [ + "AI Lens (Document extraction and workflow triage, Axis B): the AI foothold in C3 is \\emph{unstructured input} -- incoming invoices, applications and correspondence parsed by LLM-based extraction components that propose structured case data", + "The class's constraints shape the integration: extraction runs \\textbf{asynchronously before the workflow starts} (latency-tolerant); its output is \\textbf{validated against the domain schema} before any case is created (the ontology-guard tactic of Part V); the four-eyes obligation of S2 extends to AI proposals -- a human confirms, the system journals both the proposal and the confirmation", + "D12 = L because none of this touches the class's core; it decorates the intake edge", + "\\textbf{Verdict (preview):} primary -- a modular monolith with externalised process logic, a Camunda-class workflow engine behind a port (MM at $++$); secondary -- layered 3-tier for small, stable scope (L at $+$). Part IV recomputes", + "Project link: this is the discipline your deterministic services inherit (deck 6 inheritance diagram: 'the deterministic services are C3 -- ACID, boring on purpose')" + ], + "elements": [ + "ailinse[Document extraction and workflow triage (Axis B)] from lines 342-344 (condensed)" + ], + "minutes": 3, + "notes": "The ontology-guard sentence maps directly onto the project's 'ontology guard active on all insights' (M5)." + }, + { + "no": 28, + "deck_section": "C4 -- ERP / Enterprise Core", + "title": "C4 -- ERP / enterprise core systems", + "kind": "content", + "script_ref": "§22 opening (part3_application_classes.tex 351-354)", + "content": [ + "\\emph{A sales order must update stock and ledger in the same breath -- for thirty years: what does 'integrated' actually demand?}", + "Integrated enterprise systems: order management, inventory, finance, HR and production planning sharing \\textbf{one} data model", + "Defining property: the product's value \\emph{is} the integration -- an order posting updates stock and ledger in one transaction, and every module sees every other module's data consistently", + "Cross-module ACID transactions over a shared schema -- exactly what distribution makes structurally expensive", + "Three challenges: (1) \\textbf{cross-module atomicity} (D4, D6); (2) \\textbf{time, in its most extreme form in the catalogue} (D7); (3) \\textbf{rhythm rather than volume} (D3, D5; D1/D2 Low)" + ], + "elements": [ + "italic leading question in bankblue; numbered challenge list" + ], + "minutes": 3, + "notes": "Light frame." + }, + { + "no": 29, + "deck_section": "C4 -- ERP / Enterprise Core", + "title": "C4 -- the challenges: atomicity, thirty years, the batch window", + "kind": "content", + "script_ref": "§22.1 (part3_application_classes.tex 356-362)", + "content": [ + "\\textbf{Cross-module atomicity.} An order confirmation must commit order, stock reservation and ledger posting together, with zero half-completed postings, ever -- the hardest possible demand on D4, coupled directly to D6: financial-reporting law demands an unbroken, tamper-evident chain from source document to ledger entry. Eventual consistency \\emph{between ledger and inventory} is not merely inconvenient -- it contradicts the audit obligation itself", + "\\textbf{Time.} SAP R/3 appeared in 1992; SAP had to extend mainstream maintenance for the ECC generation to end-2027 (optionally 2030) because customers could not complete their migrations. ERP life cycles of 20--30 years are the normal case; replacement projects run for years", + "Under that horizon \\emph{customising pressure is permanent} -- every enterprise adapts the system to itself -- so the central requirement is a disciplined extension mechanism (modules and add-ons rather than core modification): D7, with the operative sub-requirement that \\textbf{extensions survive releases}. Change-rate signature inverse to load: core processes stable, customisations churn", + "\\textbf{Rhythm, not volume.} Mixed workload: an OLTP core with deterministic batch peaks (month-end and year-end close, MRP runs, payroll); interactive latency of 1--2 s suffices (D3 Medium); the batch window is a hard boundary; load is almost never the problem -- D1 and D2 Low; planned maintenance windows are an accepted norm, which caps D5 at Medium. Data medium to large, highly structured, very long retention" + ], + "elements": [ + "\\footnotesize bullets, bold challenge labels" + ], + "minutes": 4, + "notes": "Four long bullets -- \\footnotesize, itemsep 1pt." + }, + { + "no": 30, + "deck_section": "C4 -- ERP / Enterprise Core", + "title": "C4 -- binding scenarios and the knock-outs", + "kind": "content", + "script_ref": "§22.1 scenarios and K (part3_application_classes.tex 364-370)", + "content": [ + "The (H,\\,H) leaves of the C4 utility tree -- A4 in action:", + "\\textbf{S1 (cross-module posting).} A sales order is confirmed in normal operation; order, stock reservation and ledger posting commit atomically with \\textbf{zero half-completed postings, ever}. The D4 veto scenario", + "\\textbf{S2 (period-end close).} Month-end closing starts at the period boundary; MRP, depreciation and reporting runs complete \\textbf{within the overnight batch window, with a reconciled trial balance at 06:00}. The batch edge of the workload shape -- and D6's reconciliation reading", + "\\textbf{S3 (customising survival).} A new release of the core is installed in a system carrying years of customer-specific extensions; the extensions continue to function with \\textbf{zero core modifications required and all extension contracts verified before rollout} -- the survival condition of 20--30-year life cycles. The D7 scenario", + "$K(\\text{C4})$: financial-reporting law (Swiss CO, HGB, IFRS); audit-proof archiving duties (GoBD in Germany, GeB\\\"uV in Switzerland); GDPR for the HR module; SOX control requirements for US-listed groups", + "\\textbf{Knock-out reading:} auditability of posting chains is an obligation, not an option -- a candidate that cannot demonstrate an unbroken, tamper-evident chain from source document to ledger entry is knocked out before scoring" + ], + "elements": [ + "short (H,H)/A4 tag line; scenario bullets in deck-6 style" + ], + "minutes": 3, + "notes": "Compare S2 with the PF frame of deck 6 ('the 02:00 run missed its window')." + }, + { + "no": 31, + "deck_section": "C4 -- ERP / Enterprise Core", + "title": "C4 -- requirements profile (column C4)", + "kind": "table", + "script_ref": "§22.2 tab:req-c4 (part3_application_classes.tex 372-402)", + "content": [ + "D1 Read scalability -- L -- hundreds to thousands of internal users; load rarely binds", + "D2 Write scal.\\ \\& elasticity -- L -- batch peaks deterministic and planned into the window", + "D3 Latency -- M -- 1--2 s interactive turnaround; the batch window is the boundary", + "D4 Consistency \\& integrity -- \\textbf{H} -- cross-module ACID postings order $\\to$ stock $\\to$ ledger \\emph{are} the product", + "D5 Availability \\& isolation -- M -- planned maintenance windows are an accepted ERP norm", + "D6 Security \\& auditability -- \\textbf{H} -- unbroken, tamper-evident chain from source document to ledger", + "D7 Evolvability -- \\textbf{H} -- 20--30-year lifetimes; extensions must survive releases", + "D8 Simplicity \\& TTM -- M -- nobody expects an ERP overnight, but complexity still costs", + "D9 Testability \\& deployability -- M -- release trains; extension contracts verified before rollout", + "D10 Operating cost -- M -- material, but never the deciding dimension", + "D11 Team scaling -- M -- several module teams coordinate inside one release", + "D12 AI integrability -- L -- AI assists at the edges; the posting core is untouched", + "Shape $S(a)$: interactive (+ batch runs). Constraints $K(a)$: GoBD/GeB\\\"uV; SOX; IFRS audit chains" + ], + "elements": [ + "12-row requirements-profile table (scriptsize, arraystretch 0.8) from tab:req-c4 lines 376-402, plus Shape and Constraints rows; Highs bold; one-line 'Why' cells" + ], + "minutes": 3, + "notes": "Three Highs only (D4/D6/D7) -- the narrowest High set of the five; say so: a narrow High set with the hardest single High. D6's statute list (GoBD/GeBüV, SOX) sits in the Constraints row; scenario tags spoken." + }, + { + "no": 32, + "deck_section": "C4 -- ERP / Enterprise Core", + "title": "C4 -- what real systems chose, and why", + "kind": "case", + "script_ref": "§22.3 (part3_application_classes.tex 406-408)", + "content": [ + "\\textbf{Odoo}: a modular Python monolith over PostgreSQL -- every business domain a module over one shared ORM data model, extended by inheritance. \\textbf{ERPNext} (Frappe; Python, MariaDB): metadata-driven -- DocTypes generate schema, forms and REST APIs", + "Both: strict module boundaries, one deployment, one database, shared transactions -- \\emph{the modular monolith in its purest industrial form}", + "Read against the MM column: one ACID quantum answers the D4 veto; domain modules and a disciplined extension mechanism answer D7 -- exactly S3; the $-$ on D5 is absorbed because the class weights D5 only Medium: \\textbf{a rare case where a pattern's weak cell meets a class that does not care}", + "A2 starkest in the opposite direction: decomposing an ERP into independently deployable services turns cross-module atomicity into distributed sagas -- MS's $--$ on D4 meets the class's hardest High: \\textbf{the structurally strongest anti-fit in the whole grid}; a decade of microservices enthusiasm produced no viable ERP counter-example", + "Mitigation runs through the edges: hexagonal ports at the integration peripheries (EDI, banking, tax services) keep customising out of the core; period-end closing, MRP and payroll are canonical PF runs inside the batch window" + ], + "elements": [ + "\\footnotesize bullets; system names bold; no verdict paragraph (moved to frame 33)" + ], + "minutes": 3, + "notes": "Five bullets at \\footnotesize, each three lines or fewer. 'Community attempts at microservice ERPs have remained marginal; their near-absence after a decade ... is itself empirical evidence' is compressed to the last clause of bullet 4." + }, + { + "no": 33, + "deck_section": "C4 -- ERP / Enterprise Core", + "title": "C4 -- key concept, verdict and Discussion: what exactly ossified?", + "kind": "discussion", + "script_ref": "§22.3 keypoint, thinkbox and closing sentence (part3_application_classes.tex 410-418)", + "content": [ + "Key Concept: C4 sharpens the difference between C3 and itself -- both are ACID, interactive, evolution-dominated classes, but C4's value proposition is \\emph{integration across modules}, which binds the class to a \\textbf{single transactional quantum}. Where C3 could plausibly be several small systems, C4 by definition cannot: decomposing it converts its core feature (cross-module atomic postings) into its hardest problem (distributed sagas)", + "\\textbf{Verdict (preview):} primary -- a modular monolith (MM at $++$), the strongest pattern--class alignment in the matrix; secondary -- hexagonal discipline within it for the extension ecosystem. Part IV recomputes", + "Discussion: SAP's maintenance extension to 2027/2030 means thousands of enterprises run an ERP generation older than most of this course's students", + "Is that an architecture failure, an architecture success, or both?", + "Formulate your answer as a statement about D7 (evolvability): what precisely ossified -- the pattern, the customisations, or the organisation's ability to re-derive its own requirements profile?" + ], + "elements": [ + "keypoint from lines 410-412", + "verdict as one bold-led line between the boxes (from line 418)", + "thinkbox from lines 414-416" + ], + "minutes": 3, + "notes": "Two boxes and one verdict line; 3 minutes of discussion; steer to 'the customisations and the organisation, not the pattern'. Natural break before C5 -- about 95 minutes in (cumulative 97 min at the end of this frame)." + }, + { + "no": 34, + "deck_section": "C5 -- E-Commerce", + "title": "C5 -- E-commerce platforms", + "kind": "content", + "script_ref": "§23 opening (part3_application_classes.tex 423-426)", + "content": [ + "\\emph{A hundred milliseconds of delay costs one per cent of sales, and Black Friday brings fifty times the load: what survives both at once?}", + "Online retail platforms: catalogue, search, cart, checkout, payment, fulfilment", + "Defining property: downtime and slowness convert \\emph{directly} into revenue loss", + "Equally defining: the only class in the catalogue whose consistency profile is \\textbf{hybrid by definition} -- catalogue and recommendations may be stale, inventory is negotiable (oversell compensation), checkout and payment are strictly ACID", + "Three challenges: (1) \\textbf{a price tag on latency and availability} (D3, D5, D1); (2) \\textbf{the most extreme seasonality of all classes} (D2, D9); (3) \\textbf{the split personality of the data} (D4 Medium)" + ], + "elements": [ + "italic leading question in bankblue; numbered challenge list" + ], + "minutes": 3, + "notes": "Light frame." + }, + { + "no": 35, + "deck_section": "C5 -- E-Commerce", + "title": "C5 -- the challenges: price tags, Black Friday, two kinds of truth", + "kind": "content", + "script_ref": "§23.1 (part3_application_classes.tex 428-432); numbers first shown in deck 2 (211, 227)", + "content": [ + "\\textbf{The price tag} (Lecture 2 numbers, now read as response measures): Amazon's internal experiment attributing roughly $-1\\,\\%$ of sales to $+100$ ms of latency; Akamai's 2017 retail study measuring up to $-7\\,\\%$ conversion per 100 ms of delay. Latency and availability are \\emph{revenue variables} -- direct demands on D3 and D5, with documented conversion rates as the response measures", + "The read side is equally commercial: browse-to-buy ratios often exceed \\textbf{100:1}, so the catalogue is a read product -- D1", + "\\textbf{Seasonality.} Black Friday/Cyber Monday: load factors of \\textbf{10--50$\\times$} over normal operation; Shopify reported peaks of roughly 280 million requests per minute for BFCM 2024. Peaks of that shape must be \\emph{absorbed, not survived} -- the D2 demand, rehearsed in advance: peak readiness is load-tested at 10$\\times$ baseline before the season, which is simultaneously a demand on D9", + "\\textbf{Two kinds of truth.} The checkout must never lie, the catalogue may -- the hybrid consistency encoded as D4 Medium. Data heterogeneous (semi-structured catalogue, structured orders, media blobs); business change rate high (promotions, checkout experiments -- D7); integration surface very wide (payment service providers, logistics, tax, search, recommendations). The platform lives 10+ years; frontends are short-lived" + ], + "elements": [ + "\\footnotesize bullets, bold challenge labels" + ], + "minutes": 4, + "notes": "The headline numbers ($-1\\,\\%$/100 ms, $-7\\,\\%$/100 ms, 280 M req/min) were on deck 2 -- the tag on bullet 1 says so; what is new is their reading as response measures and dimension demands. Note 6 of the consolidated table (catalogue eventual, checkout ACID) is said here, so the table frame needs no inline footnote." + }, + { + "no": 36, + "deck_section": "C5 -- E-Commerce", + "title": "C5 -- binding scenarios and the PCI knock-out", + "kind": "content", + "script_ref": "§23.1 scenarios and K (part3_application_classes.tex 434-440)", + "content": [ + "The (H,\\,H) leaves of the C5 utility tree -- A4 in action:", + "\\textbf{S1 (peak elasticity).} Black-Friday traffic arrives at 10--50$\\times$ normal load; browsing and checkout continue with \\textbf{p95 checkout latency within budget and zero uncompensated oversells at 10$\\times$ baseline in the pre-peak load test}. D2, D5, D9", + "\\textbf{S2 (page latency).} A customer opens a product page in normal operation; it renders \\textbf{in under 1--2 s, with API calls under 100--300 ms} -- the budgets behind the revenue calibrations. D1/D3", + "\\textbf{S3 (payment-scope containment).} A security assessor audits the cardholder-data environment; the audit scope is demonstrably \\textbf{confined to the tokenised payment subsystem, with third-party scripts on checkout pages inventoried and controlled} -- PCI DSS v4.0 read as a scenario. D6", + "$K(\\text{C5})$: PCI DSS v4.0 governs cardholder data -- v3.2.1 retired 31 March 2024; future-dated requirements mandatory since 31 March 2025, including MFA for all access to the cardholder-data environment and control of third-party scripts on checkout pages. PSD2 (payment initiation, strong customer authentication); GDPR for customer data", + "Direct architectural implication: \\textbf{payment-scope minimisation} through tokenisation and outsourcing -- the audit scope is a function of the structure, so the structure is chosen to shrink it: \\emph{regulation acting on D6 as a structural force}" + ], + "elements": [ + "short (H,H)/A4 tag line; scenario bullets in deck-6 style" + ], + "minutes": 3, + "notes": "Contrast with C1: there regulation forbids a consistency trade; here it reshapes the topology (scope zoning) -- both examples of frame 6's 'regulation translates into structure'." + }, + { + "no": 37, + "deck_section": "C5 -- E-Commerce", + "title": "C5 -- requirements profile (column C5: seven Highs)", + "kind": "table", + "script_ref": "§23.2 tab:req-c5 (part3_application_classes.tex 442-472)", + "content": [ + "D1 Read scalability -- \\textbf{H} -- browse-to-buy beyond 100:1 -- the catalogue is a read product", + "D2 Write scal.\\ \\& elasticity -- \\textbf{H} -- 10--50$\\times$ seasonal peaks must be absorbed, not survived", + "D3 Latency -- \\textbf{H} -- $+100$ ms $\\approx -1\\,\\%$ sales: latency carries a price tag", + "D4 Consistency \\& integrity -- M -- hybrid by definition: catalogue eventual, checkout ACID", + "D5 Availability \\& isolation -- \\textbf{H} -- downtime converts to revenue loss at documented rates", + "D6 Security \\& auditability -- \\textbf{H} -- PCI DSS v4.0 makes payment-scope minimisation structural", + "D7 Evolvability -- \\textbf{H} -- promotions, checkout experiments, provider churn arrive weekly", + "D8 Simplicity \\& TTM -- M -- speed to market matters, but not at the checkout's expense", + "D9 Testability \\& deployability -- \\textbf{H} -- load tests at 10$\\times$ baseline gate the season", + "D10 Operating cost -- M -- fleet cost matters; the revenue stakes dominate it", + "D11 Team scaling -- M -- organisation-size dependent: Shopify versus Amazon", + "D12 AI integrability -- M -- recommendations and search ranking serve off precomputed stores", + "Shape $S(a)$: interactive, seasonal. Constraints $K(a)$: PCI DSS v4.0 scope minimisation; PSD2/SCA" + ], + "elements": [ + "12-row requirements-profile table (scriptsize, arraystretch 0.8) from tab:req-c5 lines 446-472, plus Shape and Constraints rows; Highs bold; one-line 'Why' cells" + ], + "minutes": 3, + "notes": "Seven Highs -- more than any other class (script). No Low at all: say it -- the class pays on every dimension and has the least room to not pay. Notes 6 and 17 are spoken (note 6 was said on frame 35; note 17 -- team size, not traffic -- comes on frame 38)." + }, + { + "no": 38, + "deck_section": "C5 -- E-Commerce", + "title": "C5 -- what real systems chose, and why", + "kind": "case", + "script_ref": "§23.3 (part3_application_classes.tex 476-478); recall of deck 4 examplebox 'Shopify -- the canonical modular monolith' (431-432)", + "content": [ + "\\textbf{Shopify} -- the Lecture-4 case, now from the demand side: pod sharding lifts the MM column's weak D2 cell to carry 280-million-requests-per-minute peaks, while the single transactional quantum preserves checkout ACID against the D4 boundary -- a documented mitigation of exactly the two cells where pattern and profile rub. Stated rationale: developer productivity plus transactional consistency", + "\\textbf{Amazon} -- the founding pioneer of service orientation with two-pizza team ownership: the same class, the opposite structure, driven by organisational scale. MS's $++$ on D11 becomes decisive only when team count makes D11 bind: \\textbf{team size, not traffic, is the deciding variable} -- A2 resolved by an organisational constraint, as in C1", + "Open source: \\textbf{Saleor} (Python/Django, GraphQL-first API-centric monolith), \\textbf{Medusa} (Node.js, modular commerce modules behind a REST API) -- the 'headless/composable' trend is a \\emph{layering} cut, not a microservice cut", + "Event-shaped edges -- order flows, inventory updates, search indexing, recommendation training -- served by EDA and PF beside the core; flash-sale spikes are the textbook serverless elasticity case: those three columns earn a $+$ in this row \\textbf{without ever owning the checkout}" + ], + "elements": [ + "\\footnotesize bullets; system names bold; no verdict paragraph (moved to frame 39)" + ], + "minutes": 3, + "notes": "Shopify's structure (Rails core, ca. 2.8 M lines restructured since 2017 into components with enforced boundaries, Packwerk, pod sharding) was deck 4's examplebox -- one spoken sentence. Amazon's bullet is the text of note 17 of the consolidated table. Shopify returns in Lecture 10 as an evolution-path case -- announce it in one sentence." + }, + { + "no": 39, + "deck_section": "C5 -- E-Commerce", + "title": "C5 -- hybrid consistency as a designed boundary", + "kind": "keyconcept", + "script_ref": "§23.3 examplebox, keypoint and closing sentence (part3_application_classes.tex 480-488)", + "content": [ + "Example: the C5 consistency split is not an accident to be tolerated but a boundary to be \\emph{designed and documented} -- catalogue reads may be minutes stale (cache-friendly, eventually consistent); inventory may oversell within a compensable bound; the checkout/payment path is ACID with idempotent order creation. The measurable contract: \\textbf{p95 checkout latency within budget and zero \\emph{uncompensated} oversells during peak-load tests at 10$\\times$ baseline}. Where exactly the boundary runs -- is the cart eventual or transactional? -- is a genuine ATAM tradeoff point and belongs in an ADR, not in folklore", + "Key Concept: C5 is the class where quality attributes carry price tags -- latency and availability convert to revenue at documented rates, seasonality defines elasticity (10--50$\\times$ peaks), and the consistency profile is hybrid \\emph{by definition}: the one class where 'ACID or eventual?' is answered \\textbf{'both, along a designed boundary'}. Team size, not traffic, decides between the Shopify and the Amazon structure", + "\\textbf{Verdict (preview):} primary -- a modular monolith with the hybrid consistency profile designed inside it and event-driven edges (MM at $++$); secondary -- microservices at organisational scale, MS/EDA/SL earning their $+$ at the edges. Part IV recomputes" + ], + "elements": [ + "examplebox[Hybrid consistency as a designed boundary] from lines 480-482 (condensed)", + "keypoint from lines 484-486", + "verdict as bold-led closing line (line 488), matching how frames 14/20/27 close a class" + ], + "minutes": 4, + "notes": "Link to C10 (deck 6): the project's D4 is also a designed split (index eventual, audit path ACID) -- the same discipline, one ADR." + }, + { + "no": 40, + "deck_section": "Five Classes Side by Side", + "title": "Five classes side by side -- assembled from today's five tables", + "kind": "table", + "script_ref": "Assembled from tab:req-c1..c5 (part3_application_classes.tex 152-178, 228-254, 300-326, 376-402, 446-472: the Weight and Shape rows already shown on frames 12, 18, 24, 31, 37); verdict codes from the closing sentences lines 198, 270, 346, 418, 488. Nothing from the consolidated table of Lecture 9", + "content": [ + "Compact table, rows D1--D12, columns C1 | C2 | C3 | C4 | C5 -- the Weight columns of today's five profile tables placed side by side: D1 M/H/L/L/H; D2 M/M/L/L/H; D3 M/H/M/M/H; D4 H/L/H/H/M; D5 H/H/L/M/H; D6 H/M/H/H/H; D7 H/H/H/H/H; D8 L/M/H/M/M; D9 H/H/M/M/H; D10 L/M/H/M/M; D11 M/H/L/M/M; D12 M/M/L/L/M", + "Shape row (label 'Shape $S(a)$ -- all interactive'), condensed from the five Shape rows: + batch edges | read-heavy | -- | + batch runs | seasonal", + "Verdict row (primary, pattern codes from the five closing sentences): MM+HX | EDA+MS | MM | MM | MM", + "One line under the table: all five interactive; \\textbf{D7 High in all five}; D4 runs H/L/H/H/M -- the consistency axis of the map (frame 7); D8/D10 High only in C3", + "Label line (\\scriptsize, last line of the frame): \\emph{assembled from today's five tables; the ten-column version and its footnotes: Lecture 9}" + ], + "elements": [ + "scriptsize table p{2.6cm} + 5 centred columns, Highs bold; weight cells copied from the Weight columns of frames 12/18/24/31/37 (tab:req-c1..c5, cell-identical); shape cells at most two words, condensed from the per-class Shape rows; verdict row as pattern codes only; scriptsize label line below the table" + ], + "minutes": 2, + "notes": "A summary assembled from the five profile frames, not a preview of the consolidated table: nothing on this frame is taken from §29 -- the ten-column table, its row-reading rules and its seventeen footnotes are Lecture 9's. Spoken, not typeset: 'within the feasible set the organisation decides -- the Monzo condition (C1), deployments per developer per day (C2), team size not traffic (C5)'; 'Lecture 9 sets the other five columns beside these and adds the footnotes'. Droppable if the deck runs long; summary bullets 3-7 carry the five verdicts." + }, + { + "no": 41, + "deck_section": "Closing", + "title": "This week's exercise: the walking skeleton", + "kind": "exercise", + "script_ref": "project_exercise.tex 355-363 (two phases), week-table rows 8-9 (376-377), taskbox M3 (416-422) and hintbox (451-464); milestone numbering M1-M6 from the taskboxes 391-448; semester plan row 8", + "content": [ + "Project Link box: \\textbf{implementation phase begins} -- the exercise slot becomes a one-hour standup/coaching session; implementation happens mainly in self-study time", + "\\textbf{M3 -- Walking Skeleton (weeks 8--9), the first milestone of the implementation phase:} an end-to-end thin slice running: \\texttt{MarketDataService} delivers prices; a \\emph{minimal} \\texttt{ResearchAgent} produces one validated \\texttt{Insight}; a stable API and a placeholder UI that calls it", + "Build the skeleton first thing -- a thin end-to-end slice de-risks everything that follows", + "Keep the deterministic core free of LLM calls -- this is the line that is graded (the C1 rule of today: agents propose, deterministic services decide and book)", + "Use a snapshot of market/news data so demo and grading are reproducible; commit after each milestone; record decisions as ADRs as you go", + "Checked in week 9: \\textbf{walking skeleton runs end-to-end}" + ], + "elements": [ + "projektbox with the M3 taskbox content (project_exercise.tex 416-422) and the hintbox lines 453-462" + ], + "minutes": 3, + "notes": "Same layout as deck 6 'This week's exercise'. Tie the C3 verdict to the deterministic services (ACID, boring on purpose). Milestone label M3 follows the taskboxes of project_exercise.tex (M1 requirements and ontology, weeks 1-3; M2 architecture decision and solution design, weeks 4-7; M3 walking skeleton, weeks 8-9; M4 deterministic core and resilience, weeks 10-11; M5 multi-agent orchestration, evaluation and hardening, weeks 12-13; M6 presentation, week 14) -- the same numbering decks 9-13 use. The semester plan's 'Notwendige Anpassungen' table (Semesterplan_AISE502_HS26.md lines 35-46) still labels the walking skeleton M2 and the later milestones M3/M4/M5; that table is stale, not the deck -- do not follow it." + }, + { + "no": 42, + "deck_section": "Closing", + "title": "Summary", + "kind": "summary", + "script_ref": "§18-§23 keypoints", + "content": [ + "1. An application class is an ASR bundle, not an industry label: $R(a) = (w;\\, S(a);\\, K(a))$ -- weights from the (H,\\,H) leaves; H a veto trigger, not a coefficient; $S(a)$ gates; $K(a)$ knocks out before scoring; one organisation runs several classes, so the matrix is read per subsystem", + "2. The map: shape $\\times$ consistency semantics -- today's five are all interactive; C1/C4 strict ACID, C3 ACID-leaning, C5 split, C2 eventual", + "3. \\textbf{C1}: D4/D5/D6/D7/D9 High, the densest $K$; LMAX vs.\\ Monzo -- $R(a)$ defines the feasible set, constraints decide within it; verdict MM+HX core, EDA edges, PF batch", + "4. \\textbf{C2}: 50:1 and the fan-out; D1/D3/D5/D7/D9/D11 High, D4 Low; Instagram scales reads from a monolith at 100 deployments/day; verdict EDA+MS at \\emph{measured} organisational scale, MM until then", + "5. \\textbf{C3}: the modal case -- ca.\\ 60\\,\\% of life-cycle cost is evolution; D8 = H and D10 = H jointly veto premium structures; verdict MM with a workflow engine behind a port", + "6. \\textbf{C4}: integration \\emph{is} the product -- cross-module ACID binds the class to one quantum; MM the strongest alignment, MS's $--$ on D4 the strongest anti-fit in the grid", + "7. \\textbf{C5}: quality attributes with price tags, 10--50$\\times$ peaks, consistency hybrid by definition, PCI scope minimisation as structure; Shopify vs.\\ Amazon -- team size, not traffic, decides", + "8. Every verdict is a preview: Part IV recomputes it through the three-stage procedure" + ], + "elements": [ + "enumerate, \\footnotesize, itemsep 2pt" + ], + "minutes": 2, + "notes": "Eight points -- at the upper limit; keep each to one line and a half." + }, + { + "no": 43, + "deck_section": "Closing", + "title": "Next week", + "kind": "nextweek", + "script_ref": "Semester plan row 9; task brief 'Next lecture'; §29.1 opening sentence (part3_application_classes.tex 917-920); projektboxes §24.3 (558-560) and §25.3 (632-634)", + "content": [ + "Left column -- Lecture 9, Part III: classes C6--C9 and 'Stepping back: ten profiles side by side'", + "C6 simulation/batch (reproducibility); C7 DSS/BI (freshness by refresh contract); C8 IoT streaming; C9 collaboration/messaging", + "The consolidated requirements table with its seventeen footnotes (§29)", + "Reading the catalogue as a whole: five cross-class observations (§29.1)", + "C6 and C7 inside your C10 project (projektboxes §24.3, §25.3)", + "Right column -- Reading: this week Part III, Sections 18--23; ahead Part III, Sections 24--27 and 29", + "Right column -- Exercise / deliverable: coaching; finish the walking skeleton -- \\textbf{milestone M3: runs end-to-end (week 9)}" + ], + "elements": [ + "two columns 0.55/0.42 as in deck 6; left column as a \\footnotesize bullet list (six lines)" + ], + "minutes": 1, + "notes": "Verbatim in substance from the task brief. The two added bullets announce what deck 9 teaches beyond C6-C9 and the table: §29.1's five cross-class observations (script line 920: 'Five cross-class observations fall out of the catalogue and prepare the matching in Part IV') and the two projektboxes -- the ingestion and eval pipelines are C6-shaped subsystems (reproducibility as the operative meaning of testability, line 560), the analytics and report subsystem is C7-shaped with the refresh contract 'analysis as of last completed ingestion' (line 634). Say both in one sentence each; the substance is Lecture 9's." + }, + { + "no": 44, + "deck_section": "Closing", + "title": "Closing slide", + "kind": "content", + "script_ref": "\\FHGRClosingPage (deck 6 lines 703-706)", + "content": [ + "Thank you! -- Dr.\\ Florian Herzog -- Fachhochschule Graub\\\"unden, Chur -- AISE502 -- AI in Software Engineering II" + ], + "elements": [ + "\\FHGRClosingPage with \\parbox wrapper and \\color{white} (trap 1 and 2 of the theme memo)" + ], + "minutes": 0, + "notes": "Copy verbatim from deck 6." + } + ], + "exercise_frame": { + "title": "This week's exercise: the walking skeleton", + "content": [ + "Implementation phase begins: the exercise slot becomes a one-hour standup/coaching session; implementation happens mainly in self-study time", + "M3 -- Walking Skeleton (weeks 8--9), the first milestone of the implementation phase: an end-to-end thin slice running -- \\texttt{MarketDataService} delivers prices; a minimal \\texttt{ResearchAgent} produces one validated \\texttt{Insight}; a stable API and a placeholder UI that calls it", + "Build the skeleton first thing in the implementation phase -- a thin end-to-end slice de-risks everything that follows", + "Keep the deterministic core free of LLM calls -- this is the line that is graded (today's C1 rule: agents propose, deterministic services decide and book)", + "Use a snapshot of market/news data so demo and grading are reproducible; commit after each milestone; record architectural decisions as ADRs as you go", + "Checked in week 9: walking skeleton runs end-to-end" + ] + }, + "summary": [ + "An application class is an ASR bundle, not an industry label: $R(a) = (w;\\, S(a);\\, K(a))$ -- weights from the (H,\\,H) leaves; H a veto trigger, not a coefficient; $S(a)$ gates; $K(a)$ knocks out before scoring; one organisation runs several classes, so the matrix is read per subsystem", + "The map: shape $\\times$ consistency semantics -- today's five are all interactive; C1/C4 strict ACID, C3 ACID-leaning, C5 split, C2 eventual", + "C1: D4/D5/D6/D7/D9 High, the densest $K$; LMAX vs.\\ Monzo -- $R(a)$ defines the feasible set, constraints decide within it; verdict MM+HX core, EDA edges, PF batch", + "C2: 50:1 and the fan-out; D1/D3/D5/D7/D9/D11 High, D4 Low; Instagram scales reads from a monolith at 100 deployments/day; verdict EDA+MS at measured organisational scale, MM until then", + "C3: the modal case -- ca.\\ 60\\,\\% of life-cycle cost is evolution; D8 = H and D10 = H jointly veto premium structures; verdict MM with a workflow engine behind a port", + "C4: integration is the product -- cross-module ACID binds the class to one quantum; MM the strongest alignment, MS's $--$ on D4 the strongest anti-fit in the grid", + "C5: quality attributes with price tags, 10--50$\\times$ peaks, consistency hybrid by definition, PCI scope minimisation as structure; Shopify vs.\\ Amazon -- team size, not traffic, decides", + "Every verdict is a preview: Part IV recomputes it through the three-stage procedure" + ], + "next_week": { + "lecture_line": "Lecture 9 -- Part III: classes C6--C9 and 'Stepping back: ten profiles side by side'", + "topics": [ + "C6 scientific simulation / batch compute -- reproducibility as consistency semantics", + "C7 DSS/BI -- freshness by refresh contract", + "C8 IoT streaming -- event time, exactly-once state", + "C9 collaboration/messaging -- connection-stateful, causal per channel", + "Stepping back: the consolidated requirements table with its seventeen footnotes (§29)", + "Reading the catalogue as a whole: five cross-class observations (§29.1)", + "C6 and C7 inside your C10 project (projektboxes §24.3, §25.3)" + ], + "reading": [ + "this week: Part III, Sections 18--23", + "ahead: Part III, Sections 24--27 and 29" + ], + "exercise": [ + "coaching; finish the walking skeleton", + "milestone M3: walking skeleton runs end-to-end (checked in week 9)" + ] + }, + "script_boxes_used": [ + { + "box": "definitionbox[Application class]", + "location": "§18, part3_application_classes.tex 18-25", + "used_in_frame": "4 Part III: the demand side, in the same vocabulary" + }, + { + "box": "hinweisbox (H is a veto trigger, not a coefficient)", + "location": "§18.1, lines 39-41", + "used_in_frame": "5 Method recall: where the weights come from (Lectures 2--3)" + }, + { + "box": "keypoint (class = ASR bundle; one organisation operates several classes)", + "location": "§18.2, lines 50-52", + "used_in_frame": "6 Workload shape and hard constraints" + }, + { + "box": "figure fig:classmap (tikz)", + "location": "§18.3, lines 58-108", + "used_in_frame": "7 A map of the ten classes" + }, + { + "box": "hinweisbox (classification is a hypothesis, never a verdict)", + "location": "§18.4, lines 113-115", + "used_in_frame": "8 Discussion: classification is a hypothesis -- test it on three systems (lead-in)" + }, + { + "box": "thinkbox (three systems you used this week)", + "location": "§18.4, lines 117-119", + "used_in_frame": "8 Discussion: classification is a hypothesis -- test it on three systems" + }, + { + "box": "table tab:req-c1", + "location": "§19.2, lines 152-178", + "used_in_frame": "12 C1 -- requirements profile (Weight column re-used on frame 40's assembled table)" + }, + { + "box": "keypoint (R(a) defines the feasible set, constraints decide)", + "location": "§19.3, lines 190-192", + "used_in_frame": "13 C1 -- what real systems chose, and why (closing box)" + }, + { + "box": "ailinse[Fraud scoring at the edge of the ledger (Axis B)]", + "location": "§19.3, lines 194-196", + "used_in_frame": "14 C1 -- AI lens and the verdict" + }, + { + "box": "table tab:req-c2", + "location": "§20.2, lines 228-254", + "used_in_frame": "18 C2 -- requirements profile (Weight column re-used on frame 40's assembled table)" + }, + { + "box": "keypoint (C1 and C2 are mirror images)", + "location": "§20.3, lines 262-264", + "used_in_frame": "20 C2 -- AI lens and the verdict (one-sentence keypoint box, recall-tagged; full box already in deck 6)" + }, + { + "box": "ailinse[Feed ranking and moderation as runtime AI (Axis B)]", + "location": "§20.3, lines 266-268", + "used_in_frame": "20 C2 -- AI lens and the verdict" + }, + { + "box": "table tab:req-c3", + "location": "§21.2, lines 300-326", + "used_in_frame": "24 C3 -- requirements profile (Weight column re-used on frame 40's assembled table)" + }, + { + "box": "examplebox[Why this class punishes distribution]", + "location": "§21.3, lines 334-336", + "used_in_frame": "26 C3 -- why this class punishes distribution" + }, + { + "box": "keypoint (C3 is the modal case; unglamorous is its optimum)", + "location": "§21.3, lines 338-340", + "used_in_frame": "26 C3 -- why this class punishes distribution" + }, + { + "box": "ailinse[Document extraction and workflow triage (Axis B)]", + "location": "§21.3, lines 342-344", + "used_in_frame": "27 C3 -- AI lens and the verdict" + }, + { + "box": "table tab:req-c4", + "location": "§22.2, lines 376-402", + "used_in_frame": "31 C4 -- requirements profile (Weight column re-used on frame 40's assembled table)" + }, + { + "box": "keypoint (C4 vs C3: integration binds to one quantum)", + "location": "§22.3, lines 410-412", + "used_in_frame": "33 C4 -- key concept, verdict and Discussion" + }, + { + "box": "thinkbox (SAP maintenance extension: what ossified?)", + "location": "§22.3, lines 414-416", + "used_in_frame": "33 C4 -- key concept, verdict and Discussion" + }, + { + "box": "table tab:req-c5", + "location": "§23.2, lines 446-472", + "used_in_frame": "37 C5 -- requirements profile (Weight column re-used on frame 40's assembled table)" + }, + { + "box": "examplebox[Hybrid consistency as a designed boundary]", + "location": "§23.3, lines 480-482", + "used_in_frame": "39 C5 -- hybrid consistency as a designed boundary" + }, + { + "box": "keypoint (C5: quality attributes carry price tags)", + "location": "§23.3, lines 484-486", + "used_in_frame": "39 C5 -- hybrid consistency as a designed boundary" + } + ], + "script_boxes_dropped": [ + { + "box": "examplebox[LMAX versus Monzo: one profile -- two structures]", + "location": "§19.3, lines 186-188", + "reason": "already shown as a box in deck 3 (407-408) and as the deck-6 mirror-pair bullet; reduced to one spoken sentence in the notes of frame 13 -- its lesson is carried by the keypoint 190-192 on that frame" + }, + { + "box": "keypoint (an H is a veto trigger backed by a scenario; footnotes carry class-specific semantics)", + "location": "§29, lines 860-862", + "reason": "§29 is taught in Lecture 9 together with the full ten-column table and its seventeen footnotes; frame 40 is assembled from the five per-class tables of §19-§23 and takes nothing from §29" + }, + { + "box": "tab:requirements footnotes 1, 3, 6, 17", + "location": "§29, lines 897-912", + "reason": "referenced by number in the per-class tables (tab:req-c1 D3, tab:req-c2 D2, tab:req-c5 D4/D11) but not inlined in the deck's table cells (one-line rule); their substance also appears in the §19-§23 body text and is spoken there (note 1: frame 16; note 3: frame 10/12 notes; note 6: frame 35; note 17: frame 38)" + }, + { + "box": "tab:requirements footnotes 2, 4, 5, 7-16", + "location": "§29, lines 897-912", + "reason": "belong to C6-C10 (Lecture 9; C10 covered in deck 6)" + }, + { + "box": "§18.4 'How to read the class sections' as a frame of its own", + "location": "lines 110-112", + "reason": "six lines of script; folded into the one-line rhythm strip on frame 4 -- the hinweisbox 113-115 moved to frame 8 as the discussion lead-in" + }, + { + "box": "Part III \\part opening paragraph references to Tables tab:cap-l..tab:cap-sl and tab:capability", + "location": "lines 14-16, 112", + "reason": "cross-references only; the capability columns were shown in deck 6 and are quoted per class in the 'what real systems chose' frames" + } + ], + "open_issues": [ + "No deck 7 file exists yet: the recap's Lecture-7 bullet is taken from the semester plan row 7 and deck 6's 'Next week' frame; re-align its wording once AISE502_Vorlesung_7_Folien.tex is typeset.", + "Frame 40 is a summary table assembled from the five per-class tables of frames 12/18/24/31/37 (Weight cells cell-identical with tab:req-c1..c5), with a two-word shape row condensed from the per-class Shape rows and pattern-code verdicts from the five closing sentences; it is labelled 'assembled from today's five tables; the ten-column version and its footnotes: Lecture 9' and cites no §29 material, so §29 (table, row readings, footnotes, §29.1 observations) stays single-taught in deck 9. Drop the frame if the deck runs long -- summary bullets 3-7 carry the five verdicts.", + "Milestone numbering: this deck (frames 3, 27 notes, 41, 43) uses the taskbox numbering of project_exercise.tex 391-448 -- M3 walking skeleton (weeks 8-9), M4 deterministic core + resilience (10-11), M5 multi-agent/eval/hardening (12-13), M6 presentation (14) -- as decks 9-13 do. The semester plan's 'Notwendige Anpassungen' table (Semesterplan_AISE502_HS26.md lines 35-46) still uses the older labels (M2 walking skeleton, M3 resilience + deterministic core, M4 multi-agent, M5 operate/harden), although its row 14 already says M6 and the exercise sheet has implemented the new phase logic (week table 369-387, taskboxes 401-448). Fix belongs in the semester plan, not in the deck: delete the 'Notwendige Anpassungen' section (its changes are applied) or rewrite its table with the sheet's numbering, and add the M-labels (M3, M4, M5) to the 'Meilenstein / Abgabe' column of rows 9, 11 and 13.", + "The five profile tables (frames 12, 18, 24, 31, 37) now use one-line 'Why' cells (~65 characters, no parentheticals, no inline footnotes); weights, Shape and Constraints cells are cell-identical with the script, the 'Why' texts are condensations -- verify each frame visually with pdftoppm after the first build, and check the C4 D4 cell (contains two $\\to$ arrows) for wrapping.", + "Row label 'D5 Availability \\& isolation' follows the deck-6 convention (deck 6 lines 210, 335, 568); the script writes 'D5 Availability \\& fault isolation'. Kept for consistency within the slide series; restore 'fault isolation' if the convention is not intended.", + "Footnotes 1, 3, 6, 17 of the consolidated table are no longer typeset anywhere; their content is spoken on frames 10, 16, 35 and 38 (and in the table-frame notes). If the lecturer wants them visible, the only place with room is the challenge frames, not the tables.", + "Part III has no 'build it and study it' boxes and no licence/runnability status for its open-source references (Fineract, Mastodon, Camunda/Flowable/Frappe, Odoo/ERPNext, Saleor/Medusa); the deck must not add such status -- keep the references as the script states them (Fineract's week-4 study status is quoted from deck 4, not invented).", + "The script provides only one figure for §18-23 (fig:classmap). Its node style 'projteal' is not defined in the deck preamble -- alias it (e.g. bankblue!70!black) or define it before redrawing. All other frames are text and tables.", + "Density to verify after the first build: frames 10 (C1 numbers, target 13-14 lines), 11 (C1 scenarios with lead line and the K bullet), 16 (C2 challenges), 19 (C2 real systems), 22 (C3 challenges), 25 (C3 real systems), 29 (C4 challenges), 32 (C4 real systems) and 38 (C5 real systems) -- all at \\footnotesize with three-line bullets; move parentheticals into speaker notes rather than adding frames.", + "MT/MX coexistence: the script (line 134) writes prospectively 'ending in November 2025'; the deck speaks the SWIFT evidence from the notes of frame 10 with the script's wording and a remark that the phase has since ended.", + "Script wording 'this class carries more Highs than any other' (C5) -- the count is seven of twelve (C2 has six, C1 five); frame 37 states 'seven Highs' rather than 'more than any other' to stay accurate before C6-C10 are seen.", + "Minutes: content frames 4-40 sum to 115 (intro block 14, C1 20, C2 19, C3 21, C4 19, C5 20, side-by-side 2); agenda 1 + recap 3 + exercise 3 + summary 2 + next week 1 = 10 framing minutes; total 125 for three lessons, 44 frames including title and closing. Cumulative count at the end of frame 33 (C4 discussion, the natural break) is 97 minutes.", + "Frame 43 'Next week' now carries six left-column lines (C6-C9, consolidated table, §29.1 observations, C6/C7 projektboxes) at \\footnotesize in the 0.55 column -- verify with pdftoppm that the two columns still fit without an overfull box; the frame stays at 1 minute." + ], + "total_frames": 44 +} diff --git a/Folien/Planung_7-13_json/L9.json b/Folien/Planung_7-13_json/L9.json new file mode 100644 index 0000000..60515b2 --- /dev/null +++ b/Folien/Planung_7-13_json/L9.json @@ -0,0 +1,1030 @@ +{ + "lecture": 9, + "week": 9, + "lessons": 3, + "title": "Lecture 9: Classes C6--C9 -- and Ten Profiles Side by Side", + "script_reference": "Script: Part III, Sections 24--27, 29", + "agenda": [ + "Recap: C1--C5 and the class rhythm -- where Part III stands", + "C6 -- Scientific simulation / batch compute: makespan, reproducibility, the third consistency semantics", + "C7 -- Decision support / BI analytics: OLAP scans and the refresh contract", + "Closing the loop: C6 and C7 inside your C10 project", + "C8 -- Real-time / IoT streaming: ingest at the world's rate, correctness under failure", + "C9 -- Collaboration / messaging: connection fan-out and push", + "Stepping back: ten profiles side by side -- the consolidated requirements table and its seventeen footnotes", + "Reading the catalogue as a whole: five cross-class observations", + "This week's exercise: the walking skeleton runs end-to-end (M3 closes)" + ], + "recap": [ + "Framework position: Part III supplies the demand side -- the requirements profile $R(a)$: weights $w_i(a)$ over D1--D12, workload shape $S(a)$, hard constraints $K(a)$; Part II supplied the capability profiles $C(p)$; Part IV matches the two through the three-stage non-compensatory match (Lectures 3 and 7)", + "Last week (C1--C5): an application class \\emph{is} a requirements profile -- a recurring ASR bundle with typical response measures, a characteristic workload shape and a regulatory frame; the rhythm: leading question $\\to$ challenges $\\to$ binding scenarios S1--S3 $\\to$ twelve-row profile $\\to$ what real systems chose", + "Last week (C1--C5): C1 core banking (ACID ledger) and C2 social/content ($\\sim 50{:}1$ read-heavy, deliberately eventual) as the mirror pair; C3 back-office; C4 ERP; C5 e-commerce, the only class \\emph{defined} by a hybrid consistency profile", + "Week 6 (C10): your class -- Highs on D6/D7/D9/D10/D12; inherits C6/C7/C3 and adds the cost model per request and evals as testability: \\emph{spend the design budget on the new elements}", + "The map of the ten classes: two axes -- workload shape and consistency semantics; C6 and C7 sit at semantics that are neither ACID nor eventual -- today we develop that third family", + "Today: C6--C9 in the same rhythm, then the ten profiles side by side: the consolidated table, its seventeen footnotes, five cross-class observations -- the other operand of the fit matrix" + ], + "frames": [ + { + "no": 1, + "deck_section": "Title", + "title": "AISE502: AI in Software Engineering II -- Lecture 9: Classes C6--C9 -- and Ten Profiles Side by Side", + "kind": "content", + "script_ref": "title slide; subtitle line: Script: Part III, Sections 24--27, 29", + "content": [ + "\\FHGRTitlePage with subtitle 'Lecture 9: Classes C6--C9 -- and Ten Profiles Side by Side' and small line 'Script: Part III, Sections 24--27, 29'", + "Author Dr.\\ Florian Herzog; Fachhochschule Graub\\\"unden, Chur -- Autumn Semester 2026" + ], + "elements": [ + "FHGR title page as in deck 6 (metadata block lines 118-127 of AISE502_Vorlesung_6_Folien.tex, \\FHGRTitlePage at line 127)" + ], + "minutes": 0, + "notes": "Identical metadata block to deck 6; only subtitle and script line change. One colon then an en-dash, as in 'Lecture 6: Pipelines, Serverless, the View Across -- and Your Class (C10)'." + }, + { + "no": 2, + "deck_section": "Agenda", + "title": "Agenda", + "kind": "agenda", + "script_ref": "deck skeleton (decks 1-6); semester plan week 9", + "content": [ + "1. Recap: C1--C5 and the class rhythm", + "2. \\textbf{C6} -- Scientific simulation / batch compute: the third consistency semantics", + "3. \\textbf{C7} -- Decision support / BI analytics: the refresh contract", + "4. Closing the loop: C6 and C7 inside your C10 project", + "5. \\textbf{C8} -- Real-time / IoT streaming: correctness under failure", + "6. \\textbf{C9} -- Collaboration / messaging: connection fan-out and push", + "7. Stepping back: \\textbf{ten profiles side by side} -- the consolidated table and its seventeen footnotes", + "8. Reading the catalogue as a whole: five cross-class observations", + "9. This week's exercise: \\textbf{the walking skeleton runs end-to-end}" + ], + "elements": [ + "enumerate, \\small, itemsep 1pt (deck-6 'Agenda' frame format, line 132)" + ], + "minutes": 1, + "notes": "Nine items is the maximum the agenda frame tolerates at \\small; keep each to one line." + }, + { + "no": 3, + "deck_section": "Recap", + "title": "Recap: where we are", + "kind": "recap", + "script_ref": "deck 6 summary and C10 frames; deck 8 (per brief: §18 + C1--C5); §18.3 map (part3_application_classes.tex 55-63)", + "content": [ + "\\textbf{Framework position:} Part III = the demand side -- $R(a)$: weights $w_i(a)$ over D1--D12, workload shape $S(a)$, hard constraints $K(a)$; Part II gave $C(p)$; Part IV matches them (three-stage non-compensatory match, Lectures 3 and 7)", + "\\textbf{Last week (C1--C5):} an application class \\emph{is} a requirements profile -- a recurring ASR bundle with typical response measures, a characteristic workload shape, a regulatory frame; the rhythm: leading question $\\to$ challenges $\\to$ S1--S3 $\\to$ 12-row profile $\\to$ what real systems chose", + "\\textbf{Last week (C1--C5):} C1 (ACID ledger) and C2 ($\\sim 50{:}1$ read-heavy, deliberately eventual) as the mirror pair; C3 back-office; C4 ERP; C5 e-commerce, the only class \\emph{defined} by a hybrid consistency profile", + "\\textbf{Week 6 (C10):} Highs on D6/D7/D9/D10/D12; \\emph{inherits} C6/C7/C3; spend the design budget on the two novelties (cost per request, evals as testability)", + "\\textbf{The map of the ten classes:} two axes -- workload shape and consistency semantics; C6 and C7 sit at semantics that are neither ACID nor eventual -- today we develop that third family", + "\\textbf{Today:} C6--C9 in the same rhythm; then ten profiles side by side -- the consolidated table, its seventeen footnotes, five cross-class observations" + ], + "elements": [ + "bullet list, \\footnotesize, six bullets of two to three lines -- the maximum; no classmap thumbnail" + ], + "minutes": 3, + "notes": "One frame only; do not re-teach C1--C5 or C10. No deck, frame or section numbers on the slide (decks 1-6 say 'last week' / 'week 6'). The three-stage fit procedure was introduced in deck 3 and formalised in Lecture 7, hence '(Lectures 3 and 7)'." + }, + { + "no": 4, + "deck_section": "C6 -- Scientific Simulation / Batch Compute", + "title": "Part III continues: C6 -- Scientific simulation / batch compute", + "kind": "content", + "script_ref": "§24 intro and 24.1 (part3_application_classes.tex 493-502)", + "content": [ + "\\emph{\\textcolor{bankblue}{The nightly risk run must reproduce, to the bit, on ten thousand cores by 06:00: what does that demand?}}", + "The class: compute-dominated batch systems -- cost function CPU/GPU-hours; availability in the online sense irrelevant (\\emph{an aborted job is restarted from a checkpoint, not mourned}); correctness means \\textbf{reproducibility}: regenerable from versioned inputs, versioned code and deterministic seeds", + "\\textbf{1. The interactive vocabulary does not apply} -- no read/write ratio, only read-input $\\to$ compute $\\to$ write-output over immutable datasets; the response measures are \\textbf{makespan} (hours to weeks) and \\textbf{batch-window adherence}: D2 High in its makespan reading (note 2), D3 Low (note 4); planned, queue-based load at a utilisation target near 100\\,\\%", + "\\textbf{2. The reproducibility obligation} -- bit-identical reruns from versioned inputs, code and seeds: a scientific duty and, for regulated risk models, a supervisory one $\\to$ D9 in its reproducibility reading (note 14), D4 ``as of this run'' (note 8)", + "\\textbf{3. Physics: scaling has a measurable ceiling} -- OpenFOAM domain decomposition pays down to roughly 50{,}000--200{,}000 cells per core, below which communication overhead dominates (Amdahl's law as an architecture boundary); Monte-Carlo is embarrassingly parallel -- the ideal pipeline case" + ], + "elements": [ + "leading question in bankblue italics; numbered list of the three challenges, two lines each (deck-6 'Part III opens: C10 -- AI-native advisory platforms' format, lines 528-541)" + ], + "minutes": 4, + "notes": "\\footnotesize body; class description two lines, each challenge capped at two lines (~13 lines). Speaker notes carry what was trimmed from lines 495-502: the CFD/Monte-Carlo/ML-training/data-transformation examples; 'unlawful to rely on' (returns in the K paragraph of the next frame); utilisation near 100 % as the economic opposite of C2/C5 elastic headroom; cost per simulation as a first-order D10 concern; TB--PB of result data; the split change rate (research-driven model code vs. 30+-year-old Fortran/C++ kernels) that keeps D7 at Medium -- the last two sit in the profile table's D7/D10 rows. Emphasise 'makespan' and 'reproducibility' as the two words that replace 'latency' and 'ACID'." + }, + { + "no": 5, + "deck_section": "C6 -- Scientific Simulation / Batch Compute", + "title": "C6 -- the binding scenarios", + "kind": "content", + "script_ref": "§24.1 scenarios and K(C6) (part3_application_classes.tex 504-508, 514)", + "content": [ + "\\textbf{S1 (batch-window adherence).} Overnight risk run starts after close of business; full portfolio revaluation completes \\textbf{within the batch window, results published before start of trading}. \\textcolor{codegray}{(The D2 scenario in its makespan reading.)}", + "\\textbf{S2 (bit-level reproducibility).} A model validator re-executes a historical run months later; the pipeline regenerates the results \\textbf{bit-identically from versioned inputs, code and seeds}. \\textcolor{codegray}{(The D9/D4 scenario.)}", + "\\textbf{S3 (cost efficiency).} The quarterly compute bill is reviewed; cost per simulation and cluster utilisation stay \\textbf{within budget at a utilisation target near 100\\,\\%} -- queue-based scheduling exists to meet exactly this measure. \\textcolor{codegray}{(The D10 scenario.)}", + "$K(\\text{C6})$ in financial applications: internal models are subject to \\textbf{model validation and backtesting} under the Basel framework; traceability of model runs is audit-relevant -- the BCBS~239 lineage obligation extends into the simulation stack", + "\\textbf{Knock-out reading:} any structure that cannot pin \\emph{data version + code version + seed} per run is excluded for regulated risk computation, whatever its throughput. \\textbf{Deterministic seeds are a hard constraint, not a nicety.}" + ], + "elements": [ + "three-scenario itemize with response measures in bold and the dimension in codegray; K paragraph and knock-out reading below (deck-6 'C10 -- the binding scenarios' format, lines 543-553)" + ], + "minutes": 3, + "notes": "Point out that S1 and S3 are the same numbers the PF column's D3 = $--$ and D10 = $++$ cells were built from (week 6)." + }, + { + "no": 6, + "deck_section": "C6 -- Scientific Simulation / Batch Compute", + "title": "The third consistency semantics: reproducibility and refresh contracts", + "kind": "definition", + "script_ref": "§24.1 definitionbox (part3_application_classes.tex 510-512); also §18.3 (55-57)", + "content": [ + "Beside \\textbf{ACID} (``concurrent operations preserve invariants'') and \\textbf{eventual consistency} (``replicas converge, staleness is bounded''), the batch world defines a \\emph{third family} of consistency semantics", + "\\textbf{Reproducibility (C6):} immutable inputs and idempotent, seeded stages guarantee that a rerun yields the identical result -- consistency ``\\textbf{as of this run}''", + "\\textbf{Freshness by refresh contract (C7):} consumers see a complete, internally consistent state ``\\textbf{as of the last refresh}'' (e.g.\\ yesterday 24:00), never a half-updated one", + "Both are \\emph{weaker} than ACID and \\emph{stronger} than unqualified eventual consistency -- and both are \\textbf{contracts with response measures}, testable in CI like any other scenario", + "Supply side, already seen: the PF column's D4 $= +$ (week 6: ``the subtlest cell in the table''); demand side, today: footnotes 8 (C6) and 10 (C7) of the consolidated table" + ], + "elements": [ + "definitionbox[The third consistency semantics: reproducibility and refresh contracts] from lines 510-512, verbatim in substance; one closing bullet linking to week 6 and the footnotes" + ], + "minutes": 3, + "notes": "Serves both C6 and C7 -- place here, refer back on the C7 intro and key-concept frames. The last bullet is the deck's own bridge (deck 6 PF cell, footnotes 8/10), not new content. Wording: deck 6 phrased the PF D4 = + cell as 'as of last run' (lines 209, 229, 663); the script's canonical wording (line 511) is 'as of this run' -- same semantics, say so if a student notices." + }, + { + "no": 7, + "deck_section": "C6 -- Scientific Simulation / Batch Compute", + "title": "C6 -- requirements profile (column C6)", + "kind": "table", + "script_ref": "§24.2 tab:req-c6 (part3_application_classes.tex 520-546)", + "content": [ + "D1 Read scalability | L | no interactive readers; outputs are files and tables", + "D2 Write scal.\\ \\& elasticity | \\textbf{H} | throughput as makespan and batch-window compute bursts (S1; note 2)", + "D3 Latency | L | per-request latency is meaningless; the window is the measure (note 4)", + "D4 Consistency \\& integrity | M | consistency ``as of this run'': bit-level reproducibility from versioned inputs and seeds (note 8)", + "D5 Availability \\& isolation | L | an aborted job is restarted from a checkpoint, not mourned", + "D6 Security \\& auditability | M | lineage of regulated model runs is audit-relevant; no online attack surface", + "D7 Evolvability | M | model code churns research-driven; numeric kernels live 30+ years", + "D8 Simplicity \\& TTM | M | orchestration should stay simple; the kernels never are", + "D9 Testability \\& deployability | \\textbf{H} | reproducibility is the operative meaning of testability (S2; note 14)", + "D10 Operating cost | \\textbf{H} | the cost function \\emph{is} CPU/GPU-hours at near-100\\,\\% utilisation (S3)", + "D11 Team scaling | L | small research and engineering teams", + "D12 AI integrability | M | training and simulation pipelines host ML natively, at batch cadence", + "Shape $S(a)$: scheduled batch | Constraints $K(a)$: model validation and backtesting (finance); deterministic seeds" + ], + "elements": [ + "12-row requirements-profile table (scriptsize, arraystretch 0.8, p{3.0cm} c p{7.7cm}) from tab:req-c6 lines 526-544, Highs bold; Shape and Constraints rows below midrule -- deck-6 'C10 -- requirements profile' format (lines 555-582, with \\vspace{-0.35cm})" + ], + "minutes": 4, + "notes": "Read aloud only the three Highs (D2, D9, D10) against S1--S3 and the two footnoted cells (D2, D4, D9); stress that D2 High here means makespan, not requests/s -- the first footnoted letter of the day. The D7 row carries the change-rate remark trimmed from the intro frame." + }, + { + "no": 8, + "deck_section": "C6 -- Scientific Simulation / Batch Compute", + "title": "C6 -- what real systems chose, and why", + "kind": "case", + "script_ref": "§24.3 (part3_application_classes.tex 548-552)", + "content": [ + "\\textbf{Dominant form: pipes-and-filters on HPC or batch infrastructure} -- the PF column reads like a transcript of this class's Highs: immutable inputs $+$ deterministic, idempotent stages give reproducibility (D9) \\emph{by construction}; batch scheduling drives utilisation towards the D10 target; the shape matches the gate that eliminates every interactive pattern outright", + "\\textbf{OpenFOAM}: domain decomposition via graph partitioning, MPI communication, scheduled by \\textbf{Slurm} as batch resource manager; \\textbf{OpenMC}: modern parallel Monte-Carlo transport code of the same family; \\textbf{Spark} (data-parallel) and \\textbf{Airflow} (DAG orchestration) as cloud-native incarnations (Dask/Ray Python-native)", + "\\textbf{Where the trade-off bites (A2): data affinity} -- distributing a tightly coupled numeric dataflow across expensive boundaries multiplies communication cost", + "\\textbf{Prime Video} (already met; now read from the demand side) as this class's cautionary tale in miniature: a tightly coupled processing flow distributed across orchestrator transitions and S3 round-trips per frame, until consolidation into one process cut cost by over 90\\,\\% -- \\emph{when inter-stage communication dominates, consolidate, do not distribute}", + "\\textbf{Serverless fan-out earns only a conditional role}: embarrassingly parallel, communication-light bursts (Monte-Carlo) fit FaaS elasticity; data-heavy stages recreate the Prime Video cost trap" + ], + "elements": [ + "five bullets \\footnotesize (deck-6 'C10 -- what real systems chose, and why' format, line 584); no verdict line -- the 'in one sentence' verdict closes the key-concept box on the next frame" + ], + "minutes": 3, + "notes": "Five bullets is the limit. Prime Video was taught in weeks 1--3 and 6 -- do not retell; say 'same case, now the demand side'." + }, + { + "no": 9, + "deck_section": "C6 -- Scientific Simulation / Batch Compute", + "title": "C6 -- key concept", + "kind": "keyconcept", + "script_ref": "§24.3 keypoint (part3_application_classes.tex 554-556), verdict (562); projektbox pointer only (558-560)", + "content": [ + "\\textbf{Key concept:} C6 replaces the interactive vocabulary wholesale: the response measures are \\textbf{makespan, batch-window adherence and cost per simulation}; correctness means \\textbf{bit-level reproducibility} from versioned inputs and seeds; consistency means ``as of this run''. A structure fits this class exactly to the degree that it makes these three \\emph{measurable by construction} -- which is why immutable-input pipelines dominate it. \\textbf{In one sentence:} PF on HPC/batch infrastructure (PF at $++$), serverless fan-out secondary for bursty, communication-light parallel sections -- Part IV computes the verdict through the three-stage procedure", + "\\textbf{Project link:} the ingestion pipeline and the eval pipeline of your platform are C6-shaped subsystems -- the loop closes after C7" + ], + "elements": [ + "keypoint box (lines 554-556, condensed) with the verdict (line 562) as its last sentence -- deck-6 keypoint format ('In one sentence' inside the box, line 636); one plain pointer line below" + ], + "minutes": 3, + "notes": "First half of closing week 6's inheritance loop: the C6 projektbox substance (558-560) is taught on the 'Closing the loop' frame after C7, not here -- avoid showing the same three sentences three times." + }, + { + "no": 10, + "deck_section": "C7 -- Decision Support / BI Analytics", + "title": "C7 -- Decision support / BI analytics", + "kind": "content", + "script_ref": "§25 intro and 25.1 (part3_application_classes.tex 567-576)", + "content": [ + "\\emph{\\textcolor{bankblue}{Monday, 08:00: the management dashboard must be complete as of yesterday 24:00 -- and every number must prove where it came from. What delivers that, night after night?}}", + "The class: data warehouses, BI platforms, reporting systems -- an \\textbf{integration product over C1--C5}: it owns almost no data of its own but integrates everyone else's, so data quality, lineage and governance are first-class; its consistency semantics is the \\textbf{refresh contract} (the definition just given): ``consistent as of yesterday 24:00'' is a deliberate design choice, not a deficiency", + "\\textbf{1. The shape of the reads} -- almost pure read, but \\textbf{heavy OLAP scans by few users}, not point reads by many (note 7): a D1 demand in its own reading, scan capacity \\emph{delegated} to the warehouse engine; writes bundled into the ELT/ETL window (D2 Low); dashboards render in seconds (D3 Medium)", + "\\textbf{2. The refresh contract} -- marts refreshed within the window and visible \\emph{atomically}; consumers never see a half-updated state (D4 Medium, note 10); adherence tracked as a fitness function (D9)", + "\\textbf{3. Provenance under interrogation} -- a regulator questions a reported risk figure: trace it back through every transformation to the source systems (D6); BCBS~239 hardens this into $K(a)$ where banking data are involved" + ], + "elements": [ + "leading question in bankblue italics; numbered list of three challenges, two lines each (deck-6 'Part III opens' format, lines 528-541)" + ], + "minutes": 4, + "notes": "\\footnotesize. Speaker notes carry the trimmed clauses from lines 573-575: office-hour load with Monday-morning and month-start peaks; an hour of downtime is an annoyance, not a loss event (D5 Low); the warehouse bill as the dominant run cost (D10 High); TB--PB dimensionally modelled, Kimball's star schema as the reference; change rate high at report level, moderate in the core model (D7 Medium) -- all of which sit in the profile table's rows. The phrase 'integration product over C1--C5' is the class's identity -- say it twice." + }, + { + "no": 11, + "deck_section": "C7 -- Decision Support / BI Analytics", + "title": "C7 -- the binding scenarios", + "kind": "content", + "script_ref": "§25.1 scenarios and K(C7) (part3_application_classes.tex 578-584)", + "content": [ + "\\textbf{S1 (dashboard latency).} A controller opens the standard management dashboard on Monday morning; it renders \\textbf{in under 5 seconds}, ad-hoc analytical queries in seconds to minutes. \\textcolor{codegray}{(The D1/D3 scenario in the class's OLAP reading.)}", + "\\textbf{S2 (refresh contract).} The nightly ELT run executes; all marts are refreshed \\textbf{within the refresh window, atomically visible, refresh-window adherence tracked as a fitness function}. \\textcolor{codegray}{(The D4/D9 scenario.)}", + "\\textbf{S3 (lineage on demand).} A regulator or auditor questions a reported risk figure; the platform traces it \\textbf{back through every transformation to the source systems, on demand}. \\textcolor{codegray}{(The D6 scenario, hardened into $K(a)$ for banks.)}", + "$K(\\text{C7})$: BCBS~239 for banks (risk reporting: accuracy, completeness, timeliness, demonstrable lineage); the GDPR (purpose limitation, anonymisation in analyses); sector-specific reporting duties", + "\\textbf{Knock-out reading:} a pipeline whose transformations are not versioned and traceable cannot serve regulated reporting -- \\emph{lineage is a structural property; retrofitting it is a rebuild}" + ], + "elements": [ + "three-scenario itemize with bold response measures; K paragraph below (deck-6 'C10 -- the binding scenarios' format, lines 543-553)" + ], + "minutes": 3, + "notes": "Contrast S2 with C6's S2: both are 'consistency as of' contracts -- the definition of the third semantics at work." + }, + { + "no": 12, + "deck_section": "C7 -- Decision Support / BI Analytics", + "title": "C7 -- requirements profile (column C7)", + "kind": "table", + "script_ref": "§25.2 tab:req-c7 (part3_application_classes.tex 590-616)", + "content": [ + "D1 Read scalability | \\textbf{H} | heavy OLAP scans by few users, delegated to the warehouse engine (S1; note 7)", + "D2 Write scal.\\ \\& elasticity | L | writes are bundled into the nightly ELT window", + "D3 Latency | M | dashboards in under 5\\,s; ad-hoc queries in seconds to minutes", + "D4 Consistency \\& integrity | M | freshness by refresh contract -- ``consistent as of yesterday 24:00'' (S2; note 10)", + "D5 Availability \\& isolation | L | a dashboard down for an hour is an annoyance, not a loss event", + "D6 Security \\& auditability | M | lineage and purpose limitation; BCBS~239 hardens them into $K(a)$ where banking data flow (S3)", + "D7 Evolvability | M | report-level churn is high; the core dimensional model moves slowly", + "D8 Simplicity \\& TTM | M | thin serving keeps the estate simple; the pipeline carries the complexity", + "D9 Testability \\& deployability | M | refresh-window adherence is tracked as a fitness function (S2)", + "D10 Operating cost | \\textbf{H} | warehouse compute is the bill; cost discipline is the operative FinOps concern", + "D11 Team scaling | L | a data team, not a fleet of feature teams", + "D12 AI integrability | M | text-to-SQL docks onto the governed semantic layer, not onto raw tables", + "Shape $S(a)$: batch $+$ thin serving | Constraints $K(a)$: BCBS 239 lineage (banks)" + ], + "elements": [ + "12-row requirements-profile table (scriptsize, arraystretch 0.8) from tab:req-c7 lines 596-614; Highs bold; Shape/Constraints rows (deck-6 profile format, lines 555-582)" + ], + "minutes": 4, + "notes": "Read aloud only the two Highs (D1 in the note-7 reading, D10) and the footnoted D4 cell; D5 Low, D10 High and the D7 remark trimmed from the intro frame live here. Ask: why is D6 only M when S3 is statutory? Answer from the table: it is hardened into K(a) for banks -- knock-out, not weight." + }, + { + "no": 13, + "deck_section": "C7 -- Decision Support / BI Analytics", + "title": "C7 -- what real systems chose, and why", + "kind": "case", + "script_ref": "§25.3 (part3_application_classes.tex 618-622)", + "content": [ + "\\textbf{Documented modern form: a batch/ELT pipeline in front of a thin serving layer} -- sources $\\to$ orchestrated DAGs (\\textbf{Apache Airflow}: scheduler, executor, workers, metadata database; DAGs as code) $\\to$ warehouse $\\to$ BI frontend", + "The ``modern data stack'' is architecturally \\textbf{a layered application over a batch pipeline}: the PF column serves the refresh contract and lineage by construction (note 10, D6); the L column serves the thin tier because it \\emph{delegates} the D1-High scans to the warehouse and keeps its D8/D10 virtues", + "\\textbf{Apache Superset} (Python/Flask, originating at Airbnb): deliberately a \\emph{thin} visualisation layer with no data storage of its own, connecting directly to SQL engines; \\textbf{Metabase} ships as a single JAR -- a literal monolith, mirroring how little serving infrastructure the class needs. Both delegate scaling to the database: \\emph{division of labour as an architectural principle}", + "\\textbf{Where the trade-off bites (A2): freshness} -- streaming ingestion (EDA) earns its broker-operations complexity only when the freshness contract measurably tightens below the batch window; tightening towards real time is \\textbf{not a tuning exercise but a class change into C8 economics}" + ], + "elements": [ + "four bullets \\footnotesize; no tikz strip (the PF and L topologies were drawn in weeks 4 and 6); no verdict line -- it closes the key-concept box on the next frame" + ], + "minutes": 4, + "notes": "The 'class change into C8' line prepares the C8 intro. Bullet 2 is capped at two lines." + }, + { + "no": 14, + "deck_section": "C7 -- Decision Support / BI Analytics", + "title": "C7 -- AI lens and key concept", + "kind": "ailens", + "script_ref": "§25.3 ailinse (part3_application_classes.tex 628-630), keypoint (624-626), verdict (636)", + "content": [ + "\\textbf{AI Lens [Natural-language analytics (Axis B)]:} the visible frontier is the natural-language query -- ``show me revenue by region, last four quarters'' -- compiled by an LLM into SQL against the semantic layer", + "The profile dictates the containment: the LLM \\emph{proposes} a query; the semantic layer's schema and access-control contracts \\emph{validate and execute} it -- \\textbf{text-to-SQL against governed models, not raw tables}, so that lineage (S3) and purpose limitation survive the convenience", + "Failure mode to design against: \\textbf{silent plausibility} -- a syntactically valid, semantically wrong query returns confident nonsense; the eval harness of Part V -- golden question/answer sets over a \\emph{frozen} warehouse state -- is the class-appropriate test instrument, and note 10's refresh contract is what makes such golden sets stable", + "\\textbf{Key concept:} C7 is an integration product over C1--C5 whose consistency semantics -- freshness by refresh contract -- is a \\emph{designed} third option beside ACID and eventual. \\textbf{The ADR to write is the freshness contract itself}; the fitness functions are refresh-window adherence and p95 dashboard latency; tightening the contract towards real time is a class change into C8 economics. \\textbf{In one sentence:} PF (ELT) feeding a thin layered serving tier -- the canonical hybrid of the row (PF at $++$; L, MM, SL at $+$) -- with EDA ingestion secondary where the freshness contract demands it" + ], + "elements": [ + "ailinse[Natural-language analytics (Axis B)] box (lines 628-630, condensed) above a keypoint box (lines 624-626, condensed) closing with the verdict (line 636) -- deck-6 'PF -- AI lens and key concept' format (line 254) with 'In one sentence' inside the keypoint (line 636)" + ], + "minutes": 3, + "notes": "Both boxes at \\footnotesize; the AI lens takes three short bullets at most." + }, + { + "no": 15, + "deck_section": "C7 -- Decision Support / BI Analytics", + "title": "Closing the loop: C6 and C7 inside your C10 project", + "kind": "content", + "script_ref": "§24.3 projektbox (part3_application_classes.tex 558-560); §25.3 projektbox (632-634); deck 6 'C10 -- your project as an inheritance diagram' (lines 629-640)", + "content": [ + "Week 6's inheritance diagram: C10 inherits C6, C7 and C3 -- today the two batch parents are taught", + "\\textbf{Left -- the C6 subsystems (ingestion: chunking, embedding, indexing; the eval pipeline):} versioned inputs, idempotent stages, deterministic reruns, golden datasets", + "Left: note 14 is the bridge -- for batch pipelines, \\emph{reproducibility is the operative meaning of testability}", + "Left: when your eval scores change, prove whether the \\textbf{model, the prompt, the data or the pipeline} changed -- that proof is a C6 property", + "\\textbf{Right -- the C7 subsystem:} portfolio analytics, exposure aggregation, report generation over the deterministic data store", + "Right: its refresh contract -- ``\\textbf{analysis as of last completed ingestion}''", + "Right: it bounds what the advisory layer may claim -- \\emph{an answer must never cite data fresher than the index actually is}", + "\\textbf{Key concept:} the freshness contract appears twice in your measurement contract -- as a pipeline fitness function (C7 discipline) and as a grounding rule for generated answers (C10 discipline)" + ], + "elements": [ + "one-line lead; projektbox with two columns (0.48/0.48), three one-to-two-line bullets each (C6 column from lines 558-560, C7 column from 632-634); one keypoint line below -- deck-6 mirror-pair format (line 603) with short column bullets" + ], + "minutes": 3, + "notes": "This frame owns the substance of both projektboxes (the C6 key-concept frame only pointed here; the exercise frame keeps a one-line 'applied' bullet). 'What remains genuinely new' is left to observation 5 later today, which states it. Columns must not exceed three short bullets each." + }, + { + "no": 16, + "deck_section": "C8 -- Real-Time / IoT Streaming", + "title": "C8 -- Real-time / IoT streaming", + "kind": "content", + "script_ref": "§26 intro and 26.1 (part3_application_classes.tex 641-650)", + "content": [ + "\\emph{\\textcolor{bankblue}{The sensors never stop: what ingests the world at the world's own rate, indefinitely -- and stays exactly right when a node dies mid-window?}}", + "The class: systems that process continuously arriving event data -- sensor telemetry, clickstreams, vehicle positions, market data. Defining property: data are produced by the world at the world's own rate and \\textbf{lose value quickly}; the system must sustain ingest at the production rate \\emph{indefinitely}, master backpressure, and guarantee state correctness across failures", + "\\textbf{1. The sheer, unending inflow} -- ingest around the clock with bounded consumer lag and mastered backpressure $\\to$ D2 (the \\emph{inversion} of C2's read-heavy profile); 24/7 without pause $\\to$ D5 (the world does not stop producing while a node recovers); value decay $\\to$ D3", + "\\textbf{2. The genuinely hard one: declared correctness semantics under failure} -- event time vs.\\ processing time, windowing, watermarks (the Dataflow model); exactly-once state via checkpointing -- bought with machinery and \\emph{permanent operational competence}: D4 in its stream reading (note 11), D8 Low (nobody chooses streaming for its ease)", + "\\textbf{3. Longevity of the plumbing} -- topologies change moderately but \\textbf{schema evolution is a permanent concern} (D7 Medium); the largest data volume of all classes (append-only logs), retention often TTL-bounded, infrastructure long-lived even where the data are not" + ], + "elements": [ + "leading question in bankblue italics; numbered list of three challenges (deck-6 'Part III opens' format, lines 528-541)" + ], + "minutes": 4, + "notes": "\\footnotesize; challenges 1 and 2 trimmed to two lines each. The magnitudes (LinkedIn, Uber) are deferred to the next frame; 'an anomaly alert is worth something within milliseconds to seconds, and little after' goes to the speaker notes." + }, + { + "no": 17, + "deck_section": "C8 -- Real-Time / IoT Streaming", + "title": "C8 -- the verified magnitudes", + "kind": "table", + "script_ref": "§26.1 first challenge (part3_application_classes.tex 648-649); recap of deck 5 examplebox 'Kafka at LinkedIn; the Uber real-time stack' (AISE502_Vorlesung_5_Folien.tex 423-424)", + "content": [ + "\\textit{Seen in week 5 from the supply side -- the existence proof for EDA D1/D2 $= ++$; today the same numbers as the demand-side D2 reading of C8}", + "\\textbf{LinkedIn} (Kafka's birthplace) | more than \\textbf{seven trillion} Kafka messages per day | \\textbf{new today:} roughly 100 clusters; over 4{,}000 brokers; about 100{,}000 topics; seven million partitions", + "\\textbf{Uber} | \\textbf{trillions of messages and petabytes per day} | integrated real-time stack: Kafka (transport), Flink (stream processing), Pinot (OLAP serving) -- documented in a SIGMOD paper", + "Read: D2 in the \\emph{ingest} reading -- around the clock, bounded consumer lag, mastered backpressure; D5 because it never pauses; D3 because value decays" + ], + "elements": [ + "recap marker line in italics; two-row table (footnotesize): System | Scale | Structure, from line 648; one reading line from line 649" + ], + "minutes": 1, + "notes": "Recap frame, one minute: only the cluster/broker/topic/partition breakdown is new. Pinot returns on the 'what real systems chose' frame as the OLAP sink." + }, + { + "no": 18, + "deck_section": "C8 -- Real-Time / IoT Streaming", + "title": "C8 -- the binding scenarios", + "kind": "content", + "script_ref": "§26.1 scenarios and K(C8) (part3_application_classes.tex 652-658)", + "content": [ + "\\textbf{S1 (sustained ingest).} Sensors emit at full production rate around the clock; the platform ingests and processes with \\textbf{consumer lag bounded and no data loss, indefinitely}. \\textcolor{codegray}{(The D2/D5 scenario.)}", + "\\textbf{S2 (exactly-once state).} A processing node fails mid-window under load; the system recovers with \\textbf{state restored to exactly-once semantics via checkpointing, zero duplicated or lost aggregate updates}. \\textcolor{codegray}{(The D4 scenario in its note-11 reading.)}", + "\\textbf{S3 (end-to-end latency).} An anomalous reading arrives; the alert fires \\textbf{within milliseconds to a few seconds end-to-end, per-key ordering preserved}. \\textcolor{codegray}{(The D3 scenario.)}", + "$K(\\text{C8})$ is \\textbf{technical rather than statutory}: per-key ordering and exactly-once semantics \\emph{where declared} are contractual knock-outs -- a billing stream that double-counts under failure is not ``mostly correct'', it is wrong; GDPR adds purpose limitation and retention duties where streams carry personal data (vehicle telemetry, wearables)", + "\\textbf{The pragmatic industry norm} -- at-least-once delivery plus idempotent consumers -- is legitimate exactly where the scenario says so; the decision is taken \\textbf{per stream, per scenario, never platform-wide}" + ], + "elements": [ + "three-scenario itemize; K paragraph; last bullet in plain bold (deck-6 'C10 -- the binding scenarios' format, lines 543-553)" + ], + "minutes": 4, + "notes": "The 'per stream, per scenario' rule is the class's ADR discipline -- link to the measurement contract (Lecture 7)." + }, + { + "no": 19, + "deck_section": "C8 -- Real-Time / IoT Streaming", + "title": "C8 -- requirements profile (column C8)", + "kind": "table", + "script_ref": "§26.2 tab:req-c8 (part3_application_classes.tex 664-690)", + "content": [ + "D1 Read scalability | M | consumers read the log at their own pace; serving is delegated to OLAP sinks", + "D2 Write scal.\\ \\& elasticity | \\textbf{H} | ingest at the world's production rate, indefinitely, with backpressure mastered (S1)", + "D3 Latency | \\textbf{H} | alerts fire within milliseconds to seconds, end to end (S3)", + "D4 Consistency \\& integrity | M | stream semantics: exactly-once state, event-time windows, watermarks (S2; note 11)", + "D5 Availability \\& isolation | \\textbf{H} | the world does not pause when a node fails; recovery must preserve state", + "D6 Security \\& auditability | L | low relative to the ledger classes; GDPR applies where streams carry personal data", + "D7 Evolvability | M | topologies change moderately; schema evolution is the permanent concern", + "D8 Simplicity \\& TTM | L | nobody chooses this class for its simplicity", + "D9 Testability \\& deployability | M | correctness under failure is verified by chaos experiments, not unit suites alone", + "D10 Operating cost | M | broker fleets cost, but the class's economics absorb them", + "D11 Team scaling | M | platform and stream teams coordinate around shared topics", + "D12 AI integrability | M | models score events in the stream as checkpointed operators", + "Shape $S(a)$: continuous stream | Constraints $K(a)$: per-key ordering; exactly-once where stated" + ], + "elements": [ + "12-row requirements-profile table (scriptsize, arraystretch 0.8) from tab:req-c8 lines 670-688; Highs bold (deck-6 profile format, lines 555-582)" + ], + "minutes": 4, + "notes": "Read aloud the three Highs (D2, D3, D5) -- the two that eliminate every single-quantum interactive pattern at the shape gate plus latency -- and the footnoted D4 cell. Note D8 = L and D6 = L as the two 'licences' of this column." + }, + { + "no": 20, + "deck_section": "C8 -- Real-Time / IoT Streaming", + "title": "C8 -- what real systems chose, and why", + "kind": "case", + "script_ref": "§26.3 (part3_application_classes.tex 692-696)", + "content": [ + "\\textbf{Documented form: EDA plus pipes-and-filters over a durable log} -- producers $\\to$ Kafka (durable, partitioned, replayable) $\\to$ stream processors (Flink) $\\to$ sinks (OLAP, alerting, data lake)", + "The EDA column is this class's mirror: a durable, partitioned, replayable log with decoupled producers and consumers serves \\textbf{D2 and D5 at $++$} -- the two demands that eliminate every single-quantum interactive pattern at the shape gate; the streaming incarnation of PF supplies the processing layer whose \\textbf{checkpointing answers S2}", + "\\textbf{Netflix}: the consumer-scale EDA reference -- event-driven telemetry pipelines, resilience institutionalised through \\textbf{chaos engineering}: chaos experiments are exactly how this class tests its D4/D5 claims", + "\\textbf{Counter-lessons from this class's neighbourhood, both already met} (Segment: week 5; Prime Video: week 6 and the C6 case today) -- the shared A2 pattern is read in observation 3 later today" + ], + "elements": [ + "four bullets \\footnotesize; no tikz strip (week 5 already drew the EDA topology); no verdict line -- it closes the key-concept box on the next frame" + ], + "minutes": 4, + "notes": "Speaker notes carry the open-source references from line 696 (Apache Kafka, Apache Flink, MQTT brokers Mosquitto/EMQX at the IoT edge, Apache Pinot/Druid for real-time OLAP serving) and the Segment/Prime Video details (140 per-destination microservices, the 2018 retreat to a monolith with a central queue; the serverless orchestration consolidated into one process) -- do not retell on the slide. The A2 sentence ('both cut one coherent dataflow along technical rather than domain seams') is said once, on the observation-3 frame." + }, + { + "no": 21, + "deck_section": "C8 -- Real-Time / IoT Streaming", + "title": "C8 -- AI lens and key concept", + "kind": "ailens", + "script_ref": "§26.3 ailinse (part3_application_classes.tex 702-704), keypoint (698-700), verdict (706)", + "content": [ + "\\textbf{AI Lens [Online inference and drift on streams (Axis B)]:} C8 is where ML meets its hardest operational constraint -- models score events \\emph{in the stream} (fraud, anomaly, predictive maintenance) at \\textbf{millisecond budgets}, which rules out per-event LLM calls entirely and demands pre-trained, locally served models", + "The stream is simultaneously the \\textbf{monitoring instrument}: input-distribution statistics computed in the pipeline detect data and concept drift; production-readiness rubrics such as the ML Test Score assume exactly this telemetry", + "Architecturally, the model is \\textbf{one more stateful stream operator} -- checkpointed, versioned, replayable like any other -- so that S2's exactly-once discipline extends to inference results", + "\\textbf{Key concept:} C8 must keep pace with the production rate of the world -- indefinitely. Its genuinely hard requirement is \\emph{not throughput} but \\textbf{declared correctness semantics under failure}: exactly-once state and event-time correctness are bought with checkpointing machinery and permanent operational competence, so the pragmatic norm is at-least-once plus idempotence -- decided per stream, per scenario, and recorded as such. \\textbf{In one sentence:} EDA over a durable log with streaming PF as the processing layer -- the documented Uber stack (EDA at $++$; PF and MS at $+$) -- microservice processors secondary where team ownership demands it" + ], + "elements": [ + "ailinse[Online inference and drift on streams (Axis B)] (lines 702-704, condensed) above keypoint (698-700, condensed) closing with the verdict (line 706) -- 'In one sentence' inside the keypoint as in deck 6 (line 636)" + ], + "minutes": 3, + "notes": "Contrast with C7's AI lens: C7 docks an LLM behind a semantic layer at seconds; C8 forbids LLM calls per event -- the class profile decides the AI integration, not the other way round." + }, + { + "no": 22, + "deck_section": "C9 -- Collaboration / Messaging", + "title": "C9 -- Collaboration / messaging", + "kind": "content", + "script_ref": "§27 intro and 27.1 (part3_application_classes.tex 711-720)", + "content": [ + "\\emph{\\textcolor{bankblue}{Five million people are connected at this moment, and every message must reach its channel within half a second: what holds the connections?}}", + "The class: chat, team-collaboration and messaging applications -- a resource profile classical request/response never modelled: the system holds \\textbf{millions of long-lived, stateful connections} (WebSockets) and pushes every message to all channel members immediately; latency must feel instantaneous; ordering \\textbf{causal per channel} -- global ordering unnecessary, a deliberate weakening that buys scalability (note 12)", + "\\textbf{1. The connections themselves} -- the boot storm, not the message rate, threatens the core databases: the binding load is \\textbf{connection fan-out and push} $\\to$ D1/D2 Medium (note 9); the crux is D3/D5: a message must reach its channel in 100--500\\,ms, and \\emph{a disconnected messenger is a dead messenger}", + "\\textbf{2. The history tail} -- message histories are enormous and users scroll deep into them expecting low-tens-of-milliseconds reads: a D3 demand on the read path", + "\\textbf{3. Consistency relaxed by design} -- causal order per channel suffices (D4 Medium, note 12), the deliberate weakening that makes the fan-out scalable; feature churn high while the core protocol stays stable (D7 Medium); lifetimes exceed ten years" + ], + "elements": [ + "leading question in bankblue italics; numbered list of three challenges, two lines each (deck-6 'Part III opens' format, lines 528-541)" + ], + "minutes": 4, + "notes": "The Slack and Discord numbers, the 'one write and N push-deliveries' sentence and the load-wave sentence move to the next frame; here only the mechanism." + }, + { + "no": 23, + "deck_section": "C9 -- Collaboration / Messaging", + "title": "C9 -- the connections and the history tail: two measured cases", + "kind": "case", + "script_ref": "§27.1 (part3_application_classes.tex 718-720); Discord recap of deck 4 examplebox 'Storage migrations behind a seam -- Discord' (AISE502_Vorlesung_4_Folien.tex 670-671)", + "content": [ + "\\textbf{Slack} | connection storms | more than \\textbf{five million} simultaneous WebSocket sessions at peak; a morning peak rolling across a timezone means millions of clients connecting and booting within minutes | application-level edge cache \\textbf{Flannel} at global points of presence: p99 latency for channel-membership queries from roughly \\textbf{2{,}000\\,ms to roughly 200\\,ms}, shielding the core from the boot storms", + "\\textbf{Discord} (week 4: the same migration as the D7/D9 seam story; today the D3 demand on the storage tier) | the history tail | stores \\textbf{trillions of messages}; users scroll deep expecting low-tens-of-milliseconds reads | storage migrations MongoDB $\\to$ Cassandra $\\to$ ScyllaDB behind Rust data services performing request coalescing: p99 read latency from \\textbf{40--125\\,ms to roughly 15\\,ms}", + "Reading: every message is one write and $N$ push-deliveries; load arrives as office-hour waves travelling with the timezones (Slack) or as evening peaks (Discord) -- Slack is the D5 scenario in the class's \\emph{connection} reading (note 9), Discord the D3 demand on the \\emph{storage} tier: two tails, two tiers, one class" + ], + "elements": [ + "two-row table (footnotesize, p{} widths): System | Problem | Magnitude | Measure and result -- from lines 718-720, with a recap marker in the Discord cell; one reading line (lines 718-720)" + ], + "minutes": 3, + "notes": "Discord's number becomes S3's response measure on the next frame; Slack's Flannel case is the scenario S2 was built for (S2's response measure is 'connection establishment and initial payload within budget while protecting the core databases'). The measured production number becomes the scenario's response measure, exactly as the closing keypoint of today claims." + }, + { + "no": 24, + "deck_section": "C9 -- Collaboration / Messaging", + "title": "C9 -- the binding scenarios", + "kind": "content", + "script_ref": "§27.1 scenarios and K(C9) (part3_application_classes.tex 722-728)", + "content": [ + "\\textbf{S1 (delivery latency).} A user sends a channel message in normal global operation; all online channel members receive it \\textbf{within 100--500\\,ms, in causal order per channel}. \\textcolor{codegray}{(The D3/D4 scenario.)}", + "\\textbf{S2 (connection fan-out).} Morning peak rolls across a timezone; millions of clients connect and boot with \\textbf{connection establishment and initial payload within budget while protecting the core databases} -- the exact scenario Slack built its edge cache for. \\textcolor{codegray}{(The D5 scenario in the connection reading, note 9.)}", + "\\textbf{S3 (history read tail).} A user scrolls deep into channel history; the store serves the read with \\textbf{p99 read latency in the low tens of milliseconds} -- the target of Discord's migrations. \\textcolor{codegray}{(A D3 demand on the storage tier.)}", + "$K(\\text{C9})$: the GDPR, with \\textbf{data residency} as an explicit selling argument in the self-hosted segment; in enterprise deployments, \\textbf{compliance archiving} (MiFID~II and FINRA record-keeping rules for trader communication) makes exportable, tamper-evident message archives a hard requirement", + "\\textbf{Knock-out reading:} for regulated enterprise customers, an architecture that cannot guarantee complete capture and retention of business communication is excluded -- precisely the market logic behind \\textbf{Mattermost's single-binary, self-hostable design}" + ], + "elements": [ + "three-scenario itemize; K paragraph (deck-6 'C10 -- the binding scenarios' format, lines 543-553)" + ], + "minutes": 3, + "notes": "The Mattermost line sets up the 'four structures' frame and the Discussion." + }, + { + "no": 25, + "deck_section": "C9 -- Collaboration / Messaging", + "title": "C9 -- requirements profile (column C9)", + "kind": "table", + "script_ref": "§27.2 tab:req-c9 (part3_application_classes.tex 734-760)", + "content": [ + "D1 Read scalability | M | the binding load is connection fan-out and push, not raw reads (note 9)", + "D2 Write scal.\\ \\& elasticity | M | one write becomes $N$ push deliveries -- amplification, not raw write rate (note 9)", + "D3 Latency | \\textbf{H} | delivery within 100--500\\,ms or the conversation dies (S1, S3)", + "D4 Consistency \\& integrity | M | causal order per channel suffices; global order is deliberately waived (note 12)", + "D5 Availability \\& isolation | \\textbf{H} | presence is the product: a disconnected messenger is a dead messenger (S2)", + "D6 Security \\& auditability | M | enterprise segments harden archiving duties into $K(a)$; consumer segments do not", + "D7 Evolvability | M | feature churn is high while the core protocol stays stable", + "D8 Simplicity \\& TTM | M | a small install must stay operable -- the self-hosted market demands it", + "D9 Testability \\& deployability | M | staged rollouts across a heterogeneous client fleet", + "D10 Operating cost | M | connection infrastructure costs scale with concurrency, not usage", + "D11 Team scaling | M | platform teams for gateway and storage, feature teams above", + "D12 AI integrability | L | assistants and summarisation decorate the edges; the fan-out core is untouched", + "Shape $S(a)$: interactive, connection-stateful | Constraints $K(a)$: compliance archiving (MiFID/FINRA) in enterprise segments" + ], + "elements": [ + "12-row requirements-profile table (scriptsize, arraystretch 0.8) from tab:req-c9 lines 740-758; Highs bold (deck-6 profile format, lines 555-582)" + ], + "minutes": 4, + "notes": "Read aloud only the two Highs (D3, D5), the footnoted D1/D2/D4 cells and the one L (D12): the flattest profile of the day -- which is exactly why scale and business model move its edges (next frame)." + }, + { + "no": 26, + "deck_section": "C9 -- Collaboration / Messaging", + "title": "C9 -- same domain, four structures", + "kind": "table", + "script_ref": "§27.3 (part3_application_classes.tex 764-766)", + "content": [ + "\\textbf{Mattermost} | \\emph{one} Go binary with PostgreSQL -- the monolith as a \\emph{feature} for self-hosting and compliance customers | MM column: its D8/D10 strengths are what the enterprise $K(a)$ segment buys; D5 weakness mitigated by replicated instances", + "\\textbf{Rocket.Chat} | Node.js and MongoDB | sits in the middle", + "\\textbf{Slack} | hybrid: PHP/Hack monolithic core for persistence and business logic, a specialised distributed real-time push layer in front | the push layer is publish/subscribe fan-out -- the EDA column owns this row: message delivery \\emph{is} event fan-out with causal per-channel ordering; domain semantics and pattern coincide", + "\\textbf{Discord} | polyglot specialisation per quality attribute: BEAM for connection concurrency, Rust for tail latency | targeted microservices exactly where the D3 tail demands them", + "\\textbf{The trade-off (A2) is resolved by scale and business model, not by the domain:} below roughly $10^5$ concurrent connections a specialised push layer is premature optimisation -- \\textbf{the measured concurrent-connection count is the tiebreaker}" + ], + "elements": [ + "four-row table (scriptsize, p{} widths): System | Structure | Which column, and why -- from line 764; one tiebreaker line below (line 766)" + ], + "minutes": 3, + "notes": "First of two C9 'what real systems chose' frames (restores the class rhythm: case frame + key-concept frame). Matrix/Synapse ('adds a federated counter-model', line 764) goes to the speaker notes -- mention it as the fifth structure. Keep the Slack row to two lines." + }, + { + "no": 27, + "deck_section": "C9 -- Collaboration / Messaging", + "title": "C9 -- key concept", + "kind": "keyconcept", + "script_ref": "§27.3 keypoint (part3_application_classes.tex 768-770) and verdict (776)", + "content": [ + "\\textbf{Key concept:} C9's binding load is connection fan-out and push, not raw read/write rates -- a resource profile request/response never modelled. The same business domain spans Mattermost's single, deliberately monolithic binary and Discord's polyglot specialised cluster: \\textbf{the profile's core is stable, but scale and business model move the weights at its edges} -- measured concurrent-connection count is the tiebreaker. \\textbf{In one sentence:} a hybrid -- monolithic persistence and business core with a specialised event-driven push layer, Slack's documented shape (EDA at $++$ at the fan-out crux; MM and MS at $+$) -- with a modular monolith alone as secondary for the self-hosted segment" + ], + "elements": [ + "keypoint box (lines 768-770, condensed) closing with the verdict (line 776) -- 'In one sentence' inside the keypoint as in deck 6 (line 636)" + ], + "minutes": 2, + "notes": "Short frame; leads straight into the Discussion. 'Weights at the edges' is the sentence the Discussion debrief returns to." + }, + { + "no": 28, + "deck_section": "C9 -- Collaboration / Messaging", + "title": "Discussion", + "kind": "discussion", + "script_ref": "§27.3 thinkbox (part3_application_classes.tex 772-774)", + "content": [ + "Mattermost and Discord implement substantially the same user-visible functionality. Using the twelve dimensions:", + "Which \\emph{three} dimensions differ most strongly between the requirements profile of a \\textbf{self-hosted compliance deployment (500 users, banking client)} and a \\textbf{global consumer platform (150 million users)}?", + "Would any weight flip from L to H?", + "What does that imply for the claim that ``the application class determines the profile''?" + ], + "elements": [ + "thinkbox with the three questions from lines 772-774 (deck 1/3/5 'Discussion' frame format: plain title, question inside the box)" + ], + "minutes": 3, + "notes": "Buzz groups, 2 minutes, then collect. Anchor the debrief on the C9 table (D6 archiving into K(a), D8/D10 small install, D5/D3 tail at scale, D11) and on week 6's C1/C2 lesson: weights, not dimensions, define a class -- and here scale and business model move the weights at the edges while the core (D3/D5 High) stays." + }, + { + "no": 29, + "deck_section": "Stepping Back: Ten Profiles Side by Side", + "title": "Stepping back: ten profiles side by side -- three reading rules", + "kind": "content", + "script_ref": "§29 intro (part3_application_classes.tex 853-858); D4/D7 observations read off tab:requirements (869-894, 904-908)", + "content": [ + "Ten times the same movement -- what no single section could deliver is the view \\emph{across} the ten; that is what this section adds", + "The consolidated table: $w_i(a)$, $S(a)$, $K(a)$ per class -- the \\textbf{demand-side counterpart of the capability table} (week 6), one of the two inputs to the fit matrix of Part IV", + "\\textbf{Rule 1 -- read columns to see a class:} each column repeats the per-class table of its section cell for cell; every H is backed by a binding scenario with a response measure", + "\\textbf{Rule 2 -- read rows to see what a dimension discriminates:} D7 (evolvability) is High in six classes and Low in none -- long life is the norm, not the exception -- and Medium exactly in the four classes taught today; D12 is High only in C10, the definitional case", + "\\textbf{Rule 3 -- the seventeen footnotes are part of the table's semantics, not decoration:} testability as reproducibility in C6 (note 14), as eval pass rate in C10 (note 15), read scalability as OLAP scan capacity in C7 (note 7); the D4 row of C6--C9 carries the same letter M with four footnoted meanings (notes 8, 10, 11, 12) -- \\emph{using the bare letter without its footnote produces wrong matches in Part IV}" + ], + "elements": [ + "numbered reading rules, \\footnotesize, in the deck-6 'Four reading rules -- and the table's status' format (line 469)" + ], + "minutes": 3, + "notes": "Mirror the deck-6 capability-table frames explicitly: same movement, other operand. The two C6--C9 observations under Rules 2 and 3 (D7 Medium exactly in today's four classes; D4 = M with four footnoted meanings) are read off the table, not stated in the script -- present them as such." + }, + { + "no": 30, + "deck_section": "Stepping Back: Ten Profiles Side by Side", + "title": "The consolidated requirements table (1/2): D1--D6", + "kind": "table", + "script_ref": "§29 tab:requirements rows D1--D6 (part3_application_classes.tex 864-880)", + "content": [ + "Header: Dimension | C1 core banking | C2 social/content | C3 back-office | C4 ERP | C5 e-commerce | C6 simulation/batch | C7 DSS/BI | C8 IoT streaming | C9 collab/messaging | C10 AI-native advisory", + "D1 Read scalability | M | \\textbf{H} | L | L | \\textbf{H} | L | \\textbf{H}$^{7}$ | M | M$^{9}$ | M", + "D2 Write scal.\\ \\& elasticity | M | M$^{1}$ | L | L | \\textbf{H} | \\textbf{H}$^{2}$ | L | \\textbf{H} | M$^{9}$ | L", + "D3 Latency | M$^{3}$ | \\textbf{H} | M | M | \\textbf{H} | L$^{4}$ | M | \\textbf{H} | \\textbf{H} | M$^{5}$", + "D4 Consistency \\& integrity | \\textbf{H} | L | \\textbf{H} | \\textbf{H} | M$^{6}$ | M$^{8}$ | M$^{10}$ | M$^{11}$ | M$^{12}$ | M$^{13}$", + "D5 Availability \\& isolation | \\textbf{H} | \\textbf{H} | L | M | \\textbf{H} | L | L | \\textbf{H} | \\textbf{H} | M", + "D6 Security \\& auditability | \\textbf{H} | M | \\textbf{H} | \\textbf{H} | \\textbf{H} | M | M | L | M | \\textbf{H}", + "Footer line: superscripts refer to the seventeen footnotes (see next frames) -- integral to the cell semantics" + ], + "elements": [ + "10-column table from lines 869-880: \\scriptsize, \\tabcolsep 2pt, p{2.6cm} label column + ten centred p{1.1cm} class columns, two-line \\shortstack headers, Highs bold, superscripts via \\textsuperscript -- the same column spec as (2/2) so the halves read as one table (deck-6 'The consolidated capability table' format, line 439)" + ], + "minutes": 4, + "notes": "Width check: 2.6 cm + 10 x 1.1 cm + tabcolsep fits 16:9 at scriptsize. Walk the D4 row aloud: three H, one L, six footnoted M (notes 6, 8, 10, 11, 12, 13) -- the consistency-semantics axis of the class map." + }, + { + "no": 31, + "deck_section": "Stepping Back: Ten Profiles Side by Side", + "title": "The consolidated requirements table (2/2): D7--D12 and $S(a)$", + "kind": "table", + "script_ref": "§29 tab:requirements rows D7--D12 and shape row (part3_application_classes.tex 881-889)", + "content": [ + "Header as on (1/2): C1 ... C10", + "D7 Evolvability | \\textbf{H} | \\textbf{H} | \\textbf{H} | \\textbf{H} | \\textbf{H} | M | M | M | M | \\textbf{H}", + "D8 Simplicity \\& TTM | L | M | \\textbf{H} | M | M | M | M | L | M | M", + "D9 Testability \\& deployability | \\textbf{H} | \\textbf{H} | M | M | \\textbf{H} | \\textbf{H}$^{14}$ | M | M | M | \\textbf{H}$^{15}$", + "D10 Operating cost | L | M | \\textbf{H} | M | M | \\textbf{H} | \\textbf{H} | M | M | \\textbf{H}$^{16}$", + "D11 Team scaling | M | \\textbf{H} | L | M | M$^{17}$ | L | L | M | M | L", + "D12 AI integrability | M | M | L | L | M | M | M | M | L | \\textbf{H}", + "Dominant workload shape $S(a)$ | interactive ($+$ batch edges) | interactive read-heavy | interactive | interactive ($+$ batch runs) | interactive, seasonal | scheduled batch | batch $+$ thin serving | continuous stream | interactive, connection-stateful | hybrid: interactive $+$ batch/async" + ], + "elements": [ + "10-column table continued with the identical column spec (\\scriptsize, \\tabcolsep 2pt, p{2.6cm} + ten centred p{1.1cm}, \\shortstack headers); the $S(a)$ row rendered in \\tiny so the phrases wrap within 1.1 cm -- six data rows leave the room" + ], + "minutes": 3, + "notes": "Point at the D12 row: one H, the definitional case; and at D7: six H, no L, M exactly in C6--C9." + }, + { + "no": 32, + "deck_section": "Stepping Back: Ten Profiles Side by Side", + "title": "Hard constraints $K(a)$ -- the knock-out row", + "kind": "table", + "script_ref": "§29 tab:requirements K(a) row (part3_application_classes.tex 891-892); §24.1 (514) and §26.1 (658) for the reading line", + "content": [ + "C1 core banking: BCBS 239; FINMA 2023/1; DORA (EU 2022/2554); ACID booking core; 10+ yr retention", + "C2 social/content: DSA; GDPR", + "C3 back-office: retention law (e.g.\\ OR 958\\emph{f}); internal control systems; GDPR", + "C4 ERP: GoBD/GeB\\\"uV; SOX; IFRS audit chains", + "C5 e-commerce: PCI DSS v4.0 scope minimisation; PSD2/SCA", + "C6 simulation/batch: model validation and backtesting (finance); deterministic seeds", + "C7 DSS/BI: BCBS 239 lineage (banks)", + "C8 IoT streaming: per-key ordering; exactly-once where stated", + "C9 collab/messaging: compliance archiving (MiFID/FINRA) in enterprise segments", + "C10 AI-native advisory: EU AI Act 2024/1689 (logging, oversight; potentially high-risk); GDPR", + "Reading: $K(a)$ feeds stage 1 of the match (knock-out) together with the shape gate; C8's entry is \\emph{technical rather than statutory}; C6's pairs a supervisory duty (Basel model validation and backtesting) with a technical one (deterministic seeds)" + ], + "elements": [ + "two-column layout (C1--C5 left, C6--C10 right), \\footnotesize, from the K(a) row line 892; closing reading line" + ], + "minutes": 3, + "notes": "Five per column; the reading line paraphrases line 658 ('technical rather than statutory') and line 514 (Basel model validation, BCBS 239 lineage; deterministic seeds as a hard constraint)." + }, + { + "no": 33, + "deck_section": "Stepping Back: Ten Profiles Side by Side", + "title": "The seventeen footnotes are part of the semantics (1/2): notes 1--9", + "kind": "content", + "script_ref": "§29 tab:requirements footnotes 1-9 (part3_application_classes.tex 896-905)", + "content": [ + "$^{1}$ C2, D2 = M: raw write rate is modest (Twitter: ca.\\ 6\\,k tweet writes/s vs.\\ ca.\\ 300\\,k timeline reads/s); fan-out amplification is real but absorbed by the fan-out subsystem, not the write path", + "$^{2}$ C6, D2 = H: throughput as makespan and batch-window compute bursts, not requests/s", + "$^{3}$ C1, D3 = M: class-internal spread of orders of magnitude -- batch clearing hours, instant payments $<10$\\,s end-to-end, card authorisation 1--2\\,s, trading microseconds", + "$^{4}$ C6, D3 = L: per-request latency irrelevant; makespan and batch window are the measures", + "$^{5}$ C10, D3 = M: users accept seconds-to-minutes for advisory answers; the High-grade concern is cost per request, not speed", + "$^{6}$ C5, D4 = M: the class-defining hybrid -- catalogue eventual, checkout/payment strictly ACID", + "$^{7}$ C7, D1 = H: ``read'' means heavy OLAP scans by few users; serving typically delegated to the warehouse", + "$^{8}$ C6, D4 = M: bit-level reproducibility (seeds, versioned inputs) -- a scientific and, for risk models, regulatory duty", + "$^{9}$ C9, D1/D2 = M: connection fan-out and push, not raw read/write rates, are the binding load (Slack: $>5$\\,M concurrent WebSockets); hence M with the crux carried by D3/D5" + ], + "elements": [ + "nine-item list, \\scriptsize, each note prefixed by its cell (class, dimension, letter) -- from lines 897-905" + ], + "minutes": 3, + "notes": "Nine lines at \\scriptsize fit; the cell prefix (e.g. 'C6, D2 = H') is the deck's navigation aid, derived from the table positions." + }, + { + "no": 34, + "deck_section": "Stepping Back: Ten Profiles Side by Side", + "title": "The seventeen footnotes are part of the semantics (2/2): notes 10--17 and the rule", + "kind": "keyconcept", + "script_ref": "§29 tab:requirements footnotes 10-17 (part3_application_classes.tex 906-913) and keypoint (860-862)", + "content": [ + "$^{10}$ C7, D4 = M: a third semantics beside ACID and eventual -- freshness by refresh contract (``as of yesterday 24:00'')", + "$^{11}$ C8, D4 = M: stream semantics -- exactly-once state, event-time windows, watermarks", + "$^{12}$ C9, D4 = M: causal order per channel suffices; global order unnecessary", + "$^{13}$ C10, D4 = M: hybrid -- knowledge index eventual, transaction/audit path ACID", + "$^{14}$ C6, D9 = H: reproducibility (golden datasets, versioned pipelines) is the operative meaning of testability", + "$^{15}$ C10, D9 = H: evals are the operative meaning of testability (Part V)", + "$^{16}$ C10, D10 = H: cost per \\emph{request} (tokens, GPU) -- a run-cost class no classical profile contains", + "$^{17}$ C5, D11 = M: organisation-size dependent -- the Shopify-vs-Amazon contrast", + "\\textbf{Key concept:} an H in the table is a \\textbf{veto trigger} backed by a scenario with a response measure; an L is a \\textbf{licence to not pay} for that dimension. The footnotes carry class-specific semantics that the letters alone cannot: \\emph{whoever matches profiles by letters without footnotes has not read the table}" + ], + "elements": [ + "eight-item list \\scriptsize (lines 906-913) above the keypoint box (lines 860-862)" + ], + "minutes": 3, + "notes": "The D4 row's footnoted M cells -- notes 6, 8 and 10--13 -- make the Rule-3 point again: one letter, six semantics." + }, + { + "no": 35, + "deck_section": "Stepping Back: Ten Profiles Side by Side", + "title": "Reading rows: what discriminates -- the two questions to ask first", + "kind": "table", + "script_ref": "§29.1 observation 1 (part3_application_classes.tex 918); §29 reading rule 2 (858); H positions counted from tab:requirements (869-889)", + "content": [ + "Dimension | High in | count", + "D1 | C2, C5, C7 | 3", + "D2 | C5, C6, C8 | 3", + "D3 | C2, C5, C8, C9 | 4", + "D4 | C1, C3, C4 | 3", + "D5 | C1, C2, C5, C8, C9 | 5", + "D6 | C1, C3, C4, C5, C10 | 5", + "D7 | C1, C2, C3, C4, C5, C10 | 6 (Low in none)", + "D8 | C3 | 1", + "D9 | C1, C2, C5, C6, C10 | 5", + "D10 | C3, C6, C7, C10 | 4", + "D11 | C2 | 1", + "D12 | C10 | 1", + "\\textbf{Observation 1 -- the strongest discriminators are the read/write ratio (the D1/D2 rows) and the consistency semantics (the D4 row).} C1 (write-critical, strict ACID) and C2 (roughly 50:1 read-heavy, deliberately eventual) are mirror images across both at once -- the fastest diagnostic pair in the catalogue. \\emph{When classifying an unknown system, ask these two questions first}: they eliminate more patterns via the shape gate and the D4 row than any other pair" + ], + "elements": [ + "12-row, 3-column table (scriptsize, arraystretch 0.8) derived by counting the H cells of tab:requirements, flagged on the slide as 'read off the table'; observation 1 as a three-line \\footnotesize paragraph below" + ], + "minutes": 3, + "notes": "The counts are a deck construction (see open_issues); the script states only the D7 and D12 facts (line 858, already on the reading-rules frame). Observation 1's C5/C6--C7 clause (hybrid; third semantics family) is left to the definition frame and the summary; the derived remark that D8 and D11 single out one class each (C3, C2) and D4 is High only in the three ACID classes goes to the speaker notes." + }, + { + "no": 36, + "deck_section": "Stepping Back: Ten Profiles Side by Side", + "title": "Reading the catalogue as a whole (1/2): scale does not force microservices", + "kind": "content", + "script_ref": "§29.1 observation 2 (part3_application_classes.tex 920-924)", + "content": [ + "\\textbf{Observation 2 -- scale does not force microservices.} The documented monolith-at-scale cases span four classes \\textcolor{codegray}{(all five cases: weeks 3--6; now read from the demand side)}:", + "Instagram | global consumer platform | horizontally replicated Django monolith", + "Stack Overflow | $\\sim 1.3$ billion page views/month, $> 6{,}000$ requests/s | roughly nine on-premise web servers, monolithic .NET application", + "Shopify | ca.\\ 280 million requests/min at BFCM peak | pod-sharded modular Rails monolith", + "LMAX | six million orders/s | one thread", + "Stateless replication, sharding and mechanical sympathy scale monoliths far; what microservices primarily solve is an \\emph{organisational} scaling problem -- deployments per developer as team count grows. \\textbf{In profile terms: D1/D2 rarely force distribution; D11 = H is what does}" + ], + "elements": [ + "heading bullet with visible recap marker in codegray; four-row table (\\scriptsize): System | Documented scale | Structure -- from line 924; closing two-line paragraph ending on the bold line" + ], + "minutes": 3, + "notes": "Monzo's 2,800 services ('viable only with extreme homogeneity and central migration automation', line 924) goes to the speaker notes -- week 5 taught the homogeneity condition. Do not retell the cases; they were the supply-side evidence in weeks 3--6." + }, + { + "no": 37, + "deck_section": "Stepping Back: Ten Profiles Side by Side", + "title": "Reading the catalogue as a whole (2/2): rollbacks, regulation, inheritance", + "kind": "content", + "script_ref": "§29.1 observations 3-5 (part3_application_classes.tex 926-930)", + "content": [ + "\\textbf{3. The rollback case studies share one pattern.} Segment and Prime Video both cut \\emph{one} coherent dataflow along technical rather than domain seams -- one service per integration destination, one function per processing step -- and the interaction costs (queues, orchestrator state transitions, storage round-trips, the test matrix) consumed the benefit. Granularity must follow the coupling structure of the domain. For the catalogue: \\textbf{a class's workload shape is not merely a gate for pattern selection -- it also predicts where the expensive boundaries lie \\emph{within} a pattern}", + "\\textbf{4. Regulation is a first-class architectural requirement.} $K(a)$ translates directly into structure: BCBS~239 and FINMA 2023/1 into immutable journals, lineage and resilience testing; DORA into incident-reporting and third-party risk machinery; PCI~DSS v4.0 into cardholder-data zoning and scope minimisation; the EU AI Act into logging and human-oversight duties for AI components. None can be bolted on late at reasonable cost -- \\textbf{Booch-significant decisions}, which is exactly why they live in $K(a)$ as knock-outs rather than in the weights", + "\\textbf{5. The AI-native class inherits before it innovates.} C10 inherits the disciplines of C6/C7 (batch index and eval pipelines) and C3 (deterministic transactional services), and adds exactly \\textbf{two} genuinely new elements: a cost model that is expensive per request rather than per user, and evals as the operative meaning of testability. \\emph{Design instruction for the project in one sentence: solve the inherited profiles with the inherited, well-understood structures, and concentrate the architectural attention on the two novelties}" + ], + "elements": [ + "three paragraph bullets, \\footnotesize, numbered 3--5 to continue the previous frame" + ], + "minutes": 3, + "notes": "Observation 3 is where the Segment/Prime Video A2 sentence is said once today (the C8 case frame only pointed here) and anticipates Lecture 10 (hybrids and evolution paths: Segment, Prime Video, Shopify) -- say so. Observation 5 is the 'closing the loop' frame restated by the script itself." + }, + { + "no": 38, + "deck_section": "Stepping Back: Ten Profiles Side by Side", + "title": "The other operand is ready", + "kind": "discussion", + "script_ref": "§29.1 keypoint (part3_application_classes.tex 932-934) and thinkbox (936-938)", + "content": [ + "\\textbf{Key concept:} the ten requirements profiles are \\textbf{derivable, not arbitrary}: every weight traces to binding scenarios with response measures, every constraint to a statute or a contract, every workload signature to documented production numbers. \\textbf{The other operand is ready}: Part IV matches these profiles against the capability profiles of Part II cell by cell (the fit matrix), and every cell can be traced back to $R(a) \\times C(p)$ rather than to fashion or taste", + "\\textbf{Discussion:} the catalogue contains ten classes -- why not nine, why not fourteen?", + "Propose a candidate eleventh class (for example: computer games, embedded control, blockchain ledgers) and test it against the definition of an application class (a \\emph{recurring} ASR bundle with typical response measures, a characteristic workload shape, a regulatory frame)", + "Does its profile differ from all ten columns of the consolidated table on at least \\textbf{two High weights}? If it does not differ, it is an instance, not a class" + ], + "elements": [ + "keypoint box (lines 932-934, condensed) above a thinkbox (lines 936-938) -- deck-6 'Reading the catalogue as a whole' frame format (line 484)" + ], + "minutes": 4, + "notes": "Run the Discussion as a 3-minute pair exercise with the two table frames still in reach (students need the columns to test 'two High weights'); one minute for collection. Close by pointing forward to Lecture 10's row-by-row cell rationales." + }, + { + "no": 39, + "deck_section": "Closing", + "title": "This week's exercise: the walking skeleton runs end-to-end (M3 closes)", + "kind": "exercise", + "script_ref": "project_exercise.tex 355-466 (M3 taskbox, hintbox); semester plan week 9; §24.3 and §25.3 projektboxes (one-line pointer)", + "content": [ + "\\textbf{Coaching session (1 lesson): finish the walking skeleton.}", + "\\textbf{Milestone check M3 (week 9):} the end-to-end thin slice runs -- \\texttt{MarketDataService} delivers prices $\\to$ a \\emph{minimal} \\texttt{ResearchAgent} produces \\textbf{one validated \\texttt{Insight}} $\\to$ through the \\textbf{stable API}; a placeholder UI calls it", + "Checklist from the exercise sheet: keep the deterministic core \\textbf{free of LLM calls} (the line that is graded); use a \\textbf{snapshot} of market/news data so demo and grading are reproducible even if the live APIs misbehave; commit after the milestone; record decisions as ADRs as you go", + "Today's lecture applied: your ingestion and eval pipelines are \\textbf{C6}, your analytics are \\textbf{C7} -- the skeleton should already show where an \\texttt{Insight}'s freshness stamp comes from", + "Next: weeks 10--11 (M4) -- \\texttt{Performance}, \\texttt{Risk}, \\texttt{Optimization} services with exact tests against the reference vectors; resilience on all external calls" + ], + "elements": [ + "projektbox with the milestone check and checklist (deck-6 'This week's exercise: the match' format, lines 645-658)" + ], + "minutes": 3, + "notes": "Only the first three bullets are mandatory; the one-line 'today's lecture applied' bullet is the link back to the 'Closing the loop' frame, which owns the projektbox substance." + }, + { + "no": 40, + "deck_section": "Closing", + "title": "Summary", + "kind": "summary", + "script_ref": "keypoints §24-27, §29 (part3_application_classes.tex 554, 624, 698, 768, 860, 932)", + "content": [ + "1. \\textbf{C6} replaces the interactive vocabulary wholesale -- makespan, batch-window adherence, cost per simulation; correctness = bit-level reproducibility (Highs D2/D9/D10); with C7 it defines the \\textbf{third consistency semantics}: ``as of this run'' and ``as of yesterday 24:00'' -- contracts with response measures", + "2. \\textbf{C7}: an integration product over C1--C5; Highs D1 (OLAP scans, delegated) and D10 (the warehouse bill); the ADR to write is the freshness contract; tightening it towards real time is a class change into C8", + "3. \\textbf{C8}: keep pace with the world indefinitely; the hard requirement is declared correctness semantics under failure (Highs D2/D3/D5); at-least-once $+$ idempotence decided per stream, per scenario", + "4. \\textbf{C9}: the binding load is connection fan-out and push (Highs D3/D5); same domain, four structures -- the measured concurrent-connection count is the tiebreaker", + "5. \\textbf{Five observations}: read/write ratio and consistency semantics discriminate most; scale does not force microservices (D11 = H does); rollbacks cut dataflows along technical seams; regulation lives in $K(a)$; C10 inherits before it innovates", + "6. \\textbf{The consolidated table}: an H is a veto trigger backed by a scenario, an L a licence not to pay; the seventeen footnotes are part of the semantics -- \\textbf{the other operand is ready}: $R(a) \\times C(p)$, every cell traceable, none to fashion or taste" + ], + "elements": [ + "enumerate \\footnotesize, itemsep 2pt, six points of at most two lines (deck-6 'Summary' format, line 660)" + ], + "minutes": 2, + "notes": "Six points (~13 lines): C6 and the third semantics merged; the table and 'the other operand is ready' merged." + }, + { + "no": 41, + "deck_section": "Closing", + "title": "Next week", + "kind": "nextweek", + "script_ref": "semester plan week 10; brief 'Next lecture' line", + "content": [ + "Left: \\textbf{Lecture 10 -- Part IV continued: hybrids, evolution paths, the eight-step procedure}", + "hybrids and evolution paths: Segment, Prime Video, Shopify", + "the eight-step decision procedure with the worked course-project run (ADR-007)", + "the cell rationales of the matrix, row by row", + "Right, Reading: this week -- Part III, Sections 24--27, 29; ahead -- Part IV, Sections 33, 35--36", + "Right, Exercise / deliverable: coaching; deterministic services (\\texttt{Performance}, \\texttt{Risk}, \\texttt{Optimization}) with exact tests against the reference vectors (M4 begins)" + ], + "elements": [ + "two columns 0.55/0.42 (deck-6 'Next week' format, lines 673ff)" + ], + "minutes": 1, + "notes": "Verbatim in substance from the brief's 'Next lecture' line." + }, + { + "no": 42, + "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 deck 6 (\\FHGRClosingPage at line 703)" + ], + "minutes": 0, + "notes": "Unchanged from deck 6." + } + ], + "exercise_frame": { + "title": "This week's exercise: the walking skeleton runs end-to-end (M3 closes)", + "content": [ + "Coaching session (1 lesson): finish the walking skeleton", + "Milestone check M3 (week 9): the end-to-end thin slice runs -- MarketDataService delivers prices -> a minimal ResearchAgent produces one validated Insight -> through the stable API; a placeholder UI calls it", + "Checklist from the exercise sheet: keep the deterministic core free of LLM calls (the line that is graded); use a snapshot of market/news data so demo and grading are reproducible; commit after the milestone; record decisions as ADRs as you go", + "Today's lecture applied: ingestion and eval pipelines are C6, analytics are C7 -- the skeleton should already show where an Insight's freshness stamp comes from", + "Next: weeks 10--11 (M4) -- Performance, Risk, Optimization services with exact tests against the reference vectors; resilience on all external calls" + ] + }, + "summary": [ + "C6 replaces the interactive vocabulary wholesale -- makespan, batch-window adherence, cost per simulation; correctness = bit-level reproducibility (Highs D2/D9/D10); with C7 it defines the third consistency semantics: 'as of this run' and 'as of yesterday 24:00' -- contracts with response measures", + "C7: an integration product over C1--C5; Highs D1 (OLAP scans, delegated) and D10 (the warehouse bill); the ADR to write is the freshness contract; tightening it towards real time is a class change into C8", + "C8: keep pace with the world indefinitely; the hard requirement is declared correctness semantics under failure (Highs D2/D3/D5); at-least-once + idempotence decided per stream, per scenario", + "C9: the binding load is connection fan-out and push (Highs D3/D5); same domain, four structures -- the measured concurrent-connection count is the tiebreaker", + "Five observations: read/write ratio and consistency semantics discriminate most; scale does not force microservices (D11 = H does); rollbacks cut dataflows along technical seams; regulation lives in K(a); C10 inherits before it innovates", + "The consolidated table: an H is a veto trigger backed by a scenario, an L a licence not to pay; the seventeen footnotes are part of the semantics -- the other operand is ready: R(a) x C(p), every cell traceable, none to fashion or taste" + ], + "next_week": { + "lecture_line": "Lecture 10 (week 10, 3 lessons) -- Part IV continued: hybrids and evolution paths (Segment, Prime Video, Shopify); the eight-step decision procedure with the worked course-project run (ADR-007); the cell rationales of the matrix, row by row", + "topics": [ + "hybrids and evolution paths: Segment, Prime Video, Shopify", + "the eight-step decision procedure with the worked course-project run (ADR-007)", + "the cell rationales of the matrix, row by row" + ], + "reading": [ + "this week: Part III, Sections 24--27, 29", + "ahead: Part IV, Sections 33, 35--36" + ], + "exercise": [ + "coaching; deterministic services (Performance, Risk, Optimization) with exact tests against the reference vectors (M4 begins)" + ] + }, + "script_boxes_used": [ + { + "box": "definitionbox[The third consistency semantics: reproducibility and refresh contracts]", + "location": "§24.1, part3_application_classes.tex 510-512", + "used_in_frame": "6 -- The third consistency semantics: reproducibility and refresh contracts" + }, + { + "box": "table tab:req-c6 (requirements profile of C6)", + "location": "§24.2, part3_application_classes.tex 520-546", + "used_in_frame": "7 -- C6 -- requirements profile (column C6)" + }, + { + "box": "keypoint (C6 replaces the interactive vocabulary wholesale)", + "location": "§24.3, part3_application_classes.tex 554-556", + "used_in_frame": "9 -- C6 -- key concept" + }, + { + "box": "projektbox (the course project inherits C6 wholesale: ingestion and eval pipelines)", + "location": "§24.3, part3_application_classes.tex 558-560", + "used_in_frame": "15 -- Closing the loop: C6 and C7 inside your C10 project (substance); one-line pointers on 9 and 39" + }, + { + "box": "table tab:req-c7 (requirements profile of C7)", + "location": "§25.2, part3_application_classes.tex 590-616", + "used_in_frame": "12 -- C7 -- requirements profile (column C7)" + }, + { + "box": "keypoint (C7 is an integration product; the ADR to write is the freshness contract)", + "location": "§25.3, part3_application_classes.tex 624-626", + "used_in_frame": "14 -- C7 -- AI lens and key concept" + }, + { + "box": "ailinse[Natural-language analytics (Axis B)]", + "location": "§25.3, part3_application_classes.tex 628-630", + "used_in_frame": "14 -- C7 -- AI lens and key concept" + }, + { + "box": "projektbox (the Portfolio Intelligence Platform contains a C7 subsystem; freshness contract appears twice)", + "location": "§25.3, part3_application_classes.tex 632-634", + "used_in_frame": "15 -- Closing the loop: C6 and C7 inside your C10 project (substance); one-line pointer on 39" + }, + { + "box": "table tab:req-c8 (requirements profile of C8)", + "location": "§26.2, part3_application_classes.tex 664-690", + "used_in_frame": "19 -- C8 -- requirements profile (column C8)" + }, + { + "box": "keypoint (C8 must keep pace with the production rate of the world)", + "location": "§26.3, part3_application_classes.tex 698-700", + "used_in_frame": "21 -- C8 -- AI lens and key concept" + }, + { + "box": "ailinse[Online inference and drift on streams (Axis B)]", + "location": "§26.3, part3_application_classes.tex 702-704", + "used_in_frame": "21 -- C8 -- AI lens and key concept" + }, + { + "box": "table tab:req-c9 (requirements profile of C9)", + "location": "§27.2, part3_application_classes.tex 734-760", + "used_in_frame": "25 -- C9 -- requirements profile (column C9)" + }, + { + "box": "keypoint (C9's binding load is connection fan-out and push)", + "location": "§27.3, part3_application_classes.tex 768-770", + "used_in_frame": "27 -- C9 -- key concept" + }, + { + "box": "thinkbox (Mattermost vs Discord: which three dimensions differ most)", + "location": "§27.3, part3_application_classes.tex 772-774", + "used_in_frame": "28 -- Discussion" + }, + { + "box": "keypoint (an H is a veto trigger, an L a licence; footnotes carry the semantics)", + "location": "§29, part3_application_classes.tex 860-862", + "used_in_frame": "34 -- The seventeen footnotes are part of the semantics (2/2)" + }, + { + "box": "sidewaystable tab:requirements (consolidated requirements table, 12 rows x 10 classes, S(a) row, K(a) row)", + "location": "§29, part3_application_classes.tex 864-894", + "used_in_frame": "30 -- table (1/2) D1--D6; 31 -- table (2/2) D7--D12 and S(a); 32 -- K(a) knock-out row; 35 -- row counts; 29 -- D4/D7 observations under Rules 2 and 3" + }, + { + "box": "17 table footnotes of tab:requirements", + "location": "§29, part3_application_classes.tex 896-913", + "used_in_frame": "33 -- footnotes 1--9; 34 -- footnotes 10--17" + }, + { + "box": "keypoint (the ten requirements profiles are derivable, not arbitrary; the other operand is ready)", + "location": "§29.1, part3_application_classes.tex 932-934", + "used_in_frame": "38 -- The other operand is ready" + }, + { + "box": "thinkbox (why ten classes -- propose an eleventh and test it)", + "location": "§29.1, part3_application_classes.tex 936-938", + "used_in_frame": "38 -- The other operand is ready" + } + ], + "script_boxes_dropped": [ + { + "box": "figure fig:classmap (tikz map of the ten classes by workload shape and consistency semantics)", + "location": "§18.3, part3_application_classes.tex 65-105", + "reason": "Taught in deck 8 (§18); the recap frame refers to it verbally (C6/C7 at the third semantics); no thumbnail -- the recap frame is at its six-bullet limit" + }, + { + "box": "table tab:req-c10, keypoint and projektbox of C10 (inheritance diagram; C10 stress-tests the method)", + "location": "§28, part3_application_classes.tex 806-846", + "reason": "Taught in full in deck 6; C10 appears today only as a column of the consolidated table and via the inheritance loop closed in frame 15" + } + ], + "open_issues": [ + "No deck-8 file exists in Folien/ (only AISE502_Vorlesung_1..6); the recap frame (3) is built from the task brief's description of deck 8 and the script's §18.3 -- verify wording and the C1--C5 verdicts against the actual deck 8 once it is typeset. The slide itself says 'last week (C1--C5)', never 'deck 8'.", + "Frame 35 (reading rows): the per-row H counts and positions are derived by counting the cells of tab:requirements; the script itself states only 'D7 High in six classes and Low in none' and 'D12 High only in C10' (line 858). The counts are faithful to the table but are a deck construction -- flagged on the slide as 'read off the table'.", + "Frame 29 (reading rules) now carries the two C6--C9 observations formerly on the dropped excerpt frame (D7 Medium in exactly the four classes taught today; D4 = M with four footnoted meanings, notes 8/10/11/12): both are read off the table, not stated in the script -- presented as such.", + "The script provides no thinkbox for C6, C7 or C8 and no ailinse for C6 or C9; the deck therefore has Discussion frames only for C9 (§27) and §29, and AI-lens frames only for C7 and C8. If an AI lens for C6 is wanted, deck 6's PF AI lens ('Pipelines are where AI work naturally lives') is the closest script-backed material.", + "No tikz strips: the C7 (Airflow -> warehouse -> BI) and C8 (producers -> Kafka -> Flink -> sinks) topologies stay textual on frames 13 and 20, since the PF, L and EDA topologies were drawn in decks 4-6; a builder wanting a figure must cut one bullet per frame.", + "Minute budget: content frames sum to 125 with no slack. Reviewers disagreed on frame 38 (one asked +1, one asked -1); it stays at 4 minutes (3-minute pair exercise plus 1 minute collection). Frames 26/27 (the C9 split) are budgeted 3+2; if the lecture runs long, the C8 magnitudes recap (frame 17, 1 minute) and the C9 key-concept frame can be compressed.", + "Density: the 10-column consolidated table (frames 30-31) uses one fixed spec for both halves (p{2.6cm} + ten centred p{1.1cm}, \\tabcolsep 2pt, \\shortstack headers, S(a) row in \\tiny); the builder must confirm 'connection-stateful' wraps within 1.1 cm at \\tiny. Frame 26's Matrix/Synapse row is in the speaker notes only (high-severity density fix); the coverage reviewer would have kept it as a one-line row -- restore it only if the four-row table leaves visible room.", + "The 'in one sentence' verdict lines of §24--27 (lines 562, 636, 706, 776) quote fit-matrix ratings (PF $++$, EDA $++$, etc.) that belong to Part IV (deck 7); they are in the assigned passages and are rendered uniformly as the last sentence of each class's keypoint box (frames 9, 14, 21, 27) -- recall, not teach.", + "Exercise frame: the exercise sheet's M3 box (project_exercise.tex 407-413) adds 'a placeholder UI that calls it', which the brief's milestone line omits; included from the sheet. The hintbox items used (deterministic core free of LLM calls; data snapshot; commit after milestone; ADRs) are from lines 452-464.", + "Frame 15 (closing the inheritance loop) is the deck's synthesis of the two projektboxes with deck 6's inheritance-diagram frame; no new facts, but the 'freshness stamp on an Insight' phrasing on frame 39 is a didactic gloss on the C7 projektbox ('an answer must never cite data fresher than the index actually is').", + "Recap mentions C3 as taught last week per the brief; the C3 verdict wording is not repeated to avoid inventing deck-8 content.", + "Frames 17, 20, 23 and 36 carry visible recap markers ('week 4/5/6', 'weeks 3--6') for cases taught earlier (LinkedIn/Uber, Segment/Prime Video, Discord, Instagram/Stack Overflow/Shopify/LMAX); the week numbers follow the deck files (deck 4 = Discord, deck 5 = Kafka/Uber and Segment, deck 6 = Prime Video) and should be re-checked once decks 7-8 are typeset." + ], + "total_frames": 42 +} \ No newline at end of file diff --git a/Folien/Planung_7-13_json/coverage_table.json b/Folien/Planung_7-13_json/coverage_table.json new file mode 100644 index 0000000..996502c --- /dev/null +++ b/Folien/Planung_7-13_json/coverage_table.json @@ -0,0 +1,458 @@ +[ + { + "script_section": "§18 Application Classes as Requirements Profiles (intro)", + "lecture": "8" + }, + { + "script_section": "§18.1 Where the weights come from", + "lecture": "8" + }, + { + "script_section": "§18.2 Workload shape and hard constraints", + "lecture": "8" + }, + { + "script_section": "§18.3 A map of the ten classes", + "lecture": "8" + }, + { + "script_section": "§18.4 How to read the class sections", + "lecture": "8" + }, + { + "script_section": "§19 C1 Core Banking (intro)", + "lecture": "8" + }, + { + "script_section": "§19.1 C1 challenges", + "lecture": "8" + }, + { + "script_section": "§19.2 C1 requirements profile", + "lecture": "8" + }, + { + "script_section": "§19.3 C1 what real systems chose", + "lecture": "8" + }, + { + "script_section": "§20 C2 Social Media (intro)", + "lecture": "8" + }, + { + "script_section": "§20.1 C2 challenges", + "lecture": "8" + }, + { + "script_section": "§20.2 C2 requirements profile", + "lecture": "8" + }, + { + "script_section": "§20.3 C2 what real systems chose", + "lecture": "8" + }, + { + "script_section": "§21 C3 Back-Office (intro)", + "lecture": "8" + }, + { + "script_section": "§21.1 C3 challenges", + "lecture": "8" + }, + { + "script_section": "§21.2 C3 requirements profile", + "lecture": "8" + }, + { + "script_section": "§21.3 C3 what real systems chose", + "lecture": "8" + }, + { + "script_section": "§22 C4 ERP (intro)", + "lecture": "8" + }, + { + "script_section": "§22.1 C4 challenges", + "lecture": "8" + }, + { + "script_section": "§22.2 C4 requirements profile", + "lecture": "8" + }, + { + "script_section": "§22.3 C4 what real systems chose", + "lecture": "8" + }, + { + "script_section": "§23 C5 E-Commerce (intro)", + "lecture": "8" + }, + { + "script_section": "§23.1 C5 challenges", + "lecture": "8" + }, + { + "script_section": "§23.2 C5 requirements profile", + "lecture": "8" + }, + { + "script_section": "§23.3 C5 what real systems chose", + "lecture": "8" + }, + { + "script_section": "§24 C6 Scientific Simulation (intro)", + "lecture": "9" + }, + { + "script_section": "§24.1 C6 challenges", + "lecture": "9" + }, + { + "script_section": "§24.2 C6 requirements profile", + "lecture": "9" + }, + { + "script_section": "§24.3 C6 what real systems chose (incl. projektbox)", + "lecture": "9" + }, + { + "script_section": "§25 C7 Decision Support / BI (intro)", + "lecture": "9" + }, + { + "script_section": "§25.1 C7 challenges", + "lecture": "9" + }, + { + "script_section": "§25.2 C7 requirements profile", + "lecture": "9" + }, + { + "script_section": "§25.3 C7 what real systems chose (incl. ailinse, projektbox)", + "lecture": "9" + }, + { + "script_section": "§26 C8 Real-Time / IoT Streaming (intro)", + "lecture": "9" + }, + { + "script_section": "§26.1 C8 challenges", + "lecture": "9" + }, + { + "script_section": "§26.2 C8 requirements profile", + "lecture": "9" + }, + { + "script_section": "§26.3 C8 what real systems chose (incl. ailinse)", + "lecture": "9" + }, + { + "script_section": "§27 C9 Collaboration / Messaging (intro)", + "lecture": "9" + }, + { + "script_section": "§27.1 C9 challenges", + "lecture": "9" + }, + { + "script_section": "§27.2 C9 requirements profile", + "lecture": "9" + }, + { + "script_section": "§27.3 C9 what real systems chose (incl. thinkbox)", + "lecture": "9" + }, + { + "script_section": "§28 C10 AI-Native Advisory Platforms (intro)", + "lecture": "6 (already built)" + }, + { + "script_section": "§28.1 C10 challenges", + "lecture": "6 (already built)" + }, + { + "script_section": "§28.2 C10 requirements profile", + "lecture": "6 (already built)" + }, + { + "script_section": "§28.3 C10 what real systems chose", + "lecture": "6 (already built)" + }, + { + "script_section": "§29 Stepping Back: Ten Profiles Side by Side (intro, tab:requirements, 17 footnotes)", + "lecture": "9 (columns C1-C5 previewed on deck 8 frame 40 -- see low issue)" + }, + { + "script_section": "§29.1 Reading the catalogue as a whole", + "lecture": "9" + }, + { + "script_section": "§30 Three Matches, Three Stages (intro)", + "lecture": "7" + }, + { + "script_section": "§30.1 Case 1 -- C6 against all seven", + "lecture": "7" + }, + { + "script_section": "§30.2 Case 2 -- C1: veto rule and mitigations", + "lecture": "7" + }, + { + "script_section": "§30.3 Case 3 -- C2: holistic reading and alarm", + "lecture": "7" + }, + { + "script_section": "§31 The Procedure in General (intro)", + "lecture": "7" + }, + { + "script_section": "§31.1 The formal statement", + "lecture": "7" + }, + { + "script_section": "§31.2 Why the fit is not a weighted sum", + "lecture": "7" + }, + { + "script_section": "§32 The Matching Matrix (intro)", + "lecture": "7" + }, + { + "script_section": "§32.1 Cell semantics", + "lecture": "7" + }, + { + "script_section": "§32.2 The 7 x 10 grid", + "lecture": "7 (reprinted for reference on deck 10 frame 26, 1 min)" + }, + { + "script_section": "§33 Cell Rationales: The Ten Rows in Detail (intro, closing keypoint)", + "lecture": "10" + }, + { + "script_section": "§33.1 C1 row", + "lecture": "10" + }, + { + "script_section": "§33.2 C2 row", + "lecture": "10" + }, + { + "script_section": "§33.3 C3 row", + "lecture": "10" + }, + { + "script_section": "§33.4 C4 row", + "lecture": "10" + }, + { + "script_section": "§33.5 C5 row", + "lecture": "10" + }, + { + "script_section": "§33.6 C6 row", + "lecture": "10" + }, + { + "script_section": "§33.7 C7 row", + "lecture": "10" + }, + { + "script_section": "§33.8 C8 row", + "lecture": "10" + }, + { + "script_section": "§33.9 C9 row", + "lecture": "10" + }, + { + "script_section": "§33.10 C10 row", + "lecture": "10" + }, + { + "script_section": "§34 Reading the Matrix as a Whole (intro)", + "lecture": "7" + }, + { + "script_section": "§34.1 Column patterns", + "lecture": "7" + }, + { + "script_section": "§34.2 Row patterns and empirical support points (incl. thinkbox)", + "lecture": "7" + }, + { + "script_section": "§35 Hybrids and Evolution Paths (intro)", + "lecture": "10" + }, + { + "script_section": "§35.1 Hybrids are the normal case", + "lecture": "10" + }, + { + "script_section": "§35.2 Fit is a function of time (fig:evolution, Maxim 5, ailinse)", + "lecture": "10" + }, + { + "script_section": "§36 The Decision Procedure (eight steps, Maxim 6)", + "lecture": "10" + }, + { + "script_section": "§36.1 Full worked example: course-project run, ADR-007", + "lecture": "10" + }, + { + "script_section": "§37 The Measurement Contract (opening)", + "lecture": "7 (introduction) + 11 (depth) -- intended overlap" + }, + { + "script_section": "§37.1 Fitness functions", + "lecture": "7 (introduction) + 11 (depth) -- intended overlap" + }, + { + "script_section": "§37.2 DORA metrics: the delivery layer", + "lecture": "7 (introduction) + 11 (depth) -- intended overlap; see low issue on the coupling finding" + }, + { + "script_section": "§37.3 The four-layer measurement cascade (tab:cascade, tab:contract)", + "lecture": "11" + }, + { + "script_section": "§37.4 The cost of change (incl. §37 keypoint, ailinse, projektbox)", + "lecture": "11" + }, + { + "script_section": "§38 The Third Fit Dimension: Conway's Law and Team Topologies", + "lecture": "11" + }, + { + "script_section": "§39 Limits of the Theory -- Applied to Itself (Maxim 9, thinkbox)", + "lecture": "11" + }, + { + "script_section": "§40 Two Axes, One Method", + "lecture": "12" + }, + { + "script_section": "§41 Axis A (intro)", + "lecture": "12" + }, + { + "script_section": "§41.1 Case 1 -- the Copilot RCT", + "lecture": "12" + }, + { + "script_section": "§41.2 Case 2 -- the METR RCT", + "lecture": "12" + }, + { + "script_section": "§41.3 The full empirical record", + "lecture": "12" + }, + { + "script_section": "§41.4 Reconciling the divergence: moderator variables", + "lecture": "12" + }, + { + "script_section": "§41.5 The verification bottleneck (Maxim 7)", + "lecture": "12" + }, + { + "script_section": "§41.6 Architecture documentation as context for agents", + "lecture": "12" + }, + { + "script_section": "§41.7 Guardrails as the precondition for safe agent use", + "lecture": "12" + }, + { + "script_section": "§41.8 The agentic tool landscape 2025/2026", + "lecture": "12" + }, + { + "script_section": "§41.9 Risks and responsibility (incl. projektbox)", + "lecture": "12" + }, + { + "script_section": "§42 Axis B (intro)", + "lecture": "12" + }, + { + "script_section": "§42.1 Case: the news-sentiment call, wired the obvious way", + "lecture": "12" + }, + { + "script_section": "§42.2 The three component types", + "lecture": "12" + }, + { + "script_section": "§42.3 Why containment: the SE4AI classics", + "lecture": "12" + }, + { + "script_section": "§42.4 Integration patterns: a reference architecture", + "lecture": "12" + }, + { + "script_section": "§42.5 The eval harness as an engineering artefact", + "lecture": "12" + }, + { + "script_section": "§42.6 A new threat class: OWASP LLM Top 10 and prompt injection", + "lecture": "13" + }, + { + "script_section": "§42.7 Regulation as a hard constraint: the EU AI Act", + "lecture": "13" + }, + { + "script_section": "§43 How AI Shifts the Matrix (intro)", + "lecture": "13" + }, + { + "script_section": "§43.1 The C10 row, cell by cell", + "lecture": "13" + }, + { + "script_section": "§43.2 D12 across the seven patterns", + "lecture": "13" + }, + { + "script_section": "§43.3 Which existing cells shift, and why", + "lecture": "13" + }, + { + "script_section": "§43.4 MLOps maturity (incl. A6 restated)", + "lecture": "13" + }, + { + "script_section": "§44 Agent Orchestration: The Emergent Eighth Pattern (intro)", + "lecture": "13" + }, + { + "script_section": "§44.1 Case: the course project's advisor workflow", + "lecture": "13" + }, + { + "script_section": "§44.2 What an agent is -- and is not", + "lecture": "13" + }, + { + "script_section": "§44.3 Topologies and their classical analogues", + "lecture": "13" + }, + { + "script_section": "§44.4 The economics of autonomy", + "lecture": "13" + }, + { + "script_section": "§44.5 A capability-profile sketch (incl. projektbox)", + "lecture": "13" + }, + { + "script_section": "§45 Synthesis: One Theory, Five Parts (Maxim 8, thinkbox)", + "lecture": "13" + } +] \ No newline at end of file diff --git a/Folien/Planung_Vorlesungen_7-13.md b/Folien/Planung_Vorlesungen_7-13.md new file mode 100644 index 0000000..a4feeff --- /dev/null +++ b/Folien/Planung_Vorlesungen_7-13.md @@ -0,0 +1,5715 @@ +# AISE502 -- Planning of Lecture Decks 7--13 + +Frame-by-frame plans for the remaining seven slide sets, derived strictly from the lecture script (`skript/chapters/part3_application_classes.tex`, `part4_fit.tex`, `part5_ai_dimension.tex`). Decks 1--6 are built; week 14 is the presentation and architecture-defence week and has no lecture deck. Every content frame cites the script subsection and line range it is taken from; recap, exercise and next-week frames additionally draw on the semester plan and the project exercise sheet. + +## Overview + +| Lecture | Week | Lessons | Deck title | Script reference | Frames | +|---|---|---|---|---|---| +| 7 | 7 | 2 | Lecture 7: The Fit, Formally -- Three Cases, the Procedure, the Matrix | Script: Part IV, Sections 30--32, 34; Section 37 (introduction) | 30 | +| 8 | 8 | 3 | Lecture 8: Requirements Profiles I -- Application Classes C1--C5 | Script: Part III, Sections 18--23 | 44 | +| 9 | 9 | 3 | Lecture 9: Classes C6--C9 -- and Ten Profiles Side by Side | Script: Part III, Sections 24--27, 29 | 42 | +| 10 | 10 | 3 | Lecture 10: The Fit II -- Hybrids, Evolution Paths, and the Decision Procedure | Script: Part IV, Sections 35--36 and 33 | 44 | +| 11 | 11 | 3 | Lecture 11: The Fit III -- The Measurement Contract, Conway's Law, and the Limits of the Theory | Script: Part IV, Sections 37--39 | 40 | +| 12 | 12 | 3 | Lecture 12: The AI Dimension I -- Axis A Evidence, Axis B Foundations | Script: Part V, Sections 40--41, 42.1--42.5 | 42 | +| 13 | 13 | 3 | Lecture 13: Threats, the Shifted Matrix, Agent Orchestration -- and Synthesis | Script: Part V, Sections 42.6--42.7, 43--45 | 41 | + +## Script coverage (Parts III--V) + +| Script section | Lecture | +|---|---| +| §18 Application Classes as Requirements Profiles (intro) | 8 | +| §18.1 Where the weights come from | 8 | +| §18.2 Workload shape and hard constraints | 8 | +| §18.3 A map of the ten classes | 8 | +| §18.4 How to read the class sections | 8 | +| §19 C1 Core Banking (intro) | 8 | +| §19.1 C1 challenges | 8 | +| §19.2 C1 requirements profile | 8 | +| §19.3 C1 what real systems chose | 8 | +| §20 C2 Social Media (intro) | 8 | +| §20.1 C2 challenges | 8 | +| §20.2 C2 requirements profile | 8 | +| §20.3 C2 what real systems chose | 8 | +| §21 C3 Back-Office (intro) | 8 | +| §21.1 C3 challenges | 8 | +| §21.2 C3 requirements profile | 8 | +| §21.3 C3 what real systems chose | 8 | +| §22 C4 ERP (intro) | 8 | +| §22.1 C4 challenges | 8 | +| §22.2 C4 requirements profile | 8 | +| §22.3 C4 what real systems chose | 8 | +| §23 C5 E-Commerce (intro) | 8 | +| §23.1 C5 challenges | 8 | +| §23.2 C5 requirements profile | 8 | +| §23.3 C5 what real systems chose | 8 | +| §24 C6 Scientific Simulation (intro) | 9 | +| §24.1 C6 challenges | 9 | +| §24.2 C6 requirements profile | 9 | +| §24.3 C6 what real systems chose (incl. projektbox) | 9 | +| §25 C7 Decision Support / BI (intro) | 9 | +| §25.1 C7 challenges | 9 | +| §25.2 C7 requirements profile | 9 | +| §25.3 C7 what real systems chose (incl. ailinse, projektbox) | 9 | +| §26 C8 Real-Time / IoT Streaming (intro) | 9 | +| §26.1 C8 challenges | 9 | +| §26.2 C8 requirements profile | 9 | +| §26.3 C8 what real systems chose (incl. ailinse) | 9 | +| §27 C9 Collaboration / Messaging (intro) | 9 | +| §27.1 C9 challenges | 9 | +| §27.2 C9 requirements profile | 9 | +| §27.3 C9 what real systems chose (incl. thinkbox) | 9 | +| §28 C10 AI-Native Advisory Platforms (intro) | 6 (already built) | +| §28.1 C10 challenges | 6 (already built) | +| §28.2 C10 requirements profile | 6 (already built) | +| §28.3 C10 what real systems chose | 6 (already built) | +| §29 Stepping Back: Ten Profiles Side by Side (intro, tab:requirements, 17 footnotes) | 9 (columns C1-C5 previewed on deck 8 frame 40 -- see low issue) | +| §29.1 Reading the catalogue as a whole | 9 | +| §30 Three Matches, Three Stages (intro) | 7 | +| §30.1 Case 1 -- C6 against all seven | 7 | +| §30.2 Case 2 -- C1: veto rule and mitigations | 7 | +| §30.3 Case 3 -- C2: holistic reading and alarm | 7 | +| §31 The Procedure in General (intro) | 7 | +| §31.1 The formal statement | 7 | +| §31.2 Why the fit is not a weighted sum | 7 | +| §32 The Matching Matrix (intro) | 7 | +| §32.1 Cell semantics | 7 | +| §32.2 The 7 x 10 grid | 7 (reprinted for reference on deck 10 frame 26, 1 min) | +| §33 Cell Rationales: The Ten Rows in Detail (intro, closing keypoint) | 10 | +| §33.1 C1 row | 10 | +| §33.2 C2 row | 10 | +| §33.3 C3 row | 10 | +| §33.4 C4 row | 10 | +| §33.5 C5 row | 10 | +| §33.6 C6 row | 10 | +| §33.7 C7 row | 10 | +| §33.8 C8 row | 10 | +| §33.9 C9 row | 10 | +| §33.10 C10 row | 10 | +| §34 Reading the Matrix as a Whole (intro) | 7 | +| §34.1 Column patterns | 7 | +| §34.2 Row patterns and empirical support points (incl. thinkbox) | 7 | +| §35 Hybrids and Evolution Paths (intro) | 10 | +| §35.1 Hybrids are the normal case | 10 | +| §35.2 Fit is a function of time (fig:evolution, Maxim 5, ailinse) | 10 | +| §36 The Decision Procedure (eight steps, Maxim 6) | 10 | +| §36.1 Full worked example: course-project run, ADR-007 | 10 | +| §37 The Measurement Contract (opening) | 7 (introduction) + 11 (depth) -- intended overlap | +| §37.1 Fitness functions | 7 (introduction) + 11 (depth) -- intended overlap | +| §37.2 DORA metrics: the delivery layer | 7 (introduction) + 11 (depth) -- intended overlap; see low issue on the coupling finding | +| §37.3 The four-layer measurement cascade (tab:cascade, tab:contract) | 11 | +| §37.4 The cost of change (incl. §37 keypoint, ailinse, projektbox) | 11 | +| §38 The Third Fit Dimension: Conway's Law and Team Topologies | 11 | +| §39 Limits of the Theory -- Applied to Itself (Maxim 9, thinkbox) | 11 | +| §40 Two Axes, One Method | 12 | +| §41 Axis A (intro) | 12 | +| §41.1 Case 1 -- the Copilot RCT | 12 | +| §41.2 Case 2 -- the METR RCT | 12 | +| §41.3 The full empirical record | 12 | +| §41.4 Reconciling the divergence: moderator variables | 12 | +| §41.5 The verification bottleneck (Maxim 7) | 12 | +| §41.6 Architecture documentation as context for agents | 12 | +| §41.7 Guardrails as the precondition for safe agent use | 12 | +| §41.8 The agentic tool landscape 2025/2026 | 12 | +| §41.9 Risks and responsibility (incl. projektbox) | 12 | +| §42 Axis B (intro) | 12 | +| §42.1 Case: the news-sentiment call, wired the obvious way | 12 | +| §42.2 The three component types | 12 | +| §42.3 Why containment: the SE4AI classics | 12 | +| §42.4 Integration patterns: a reference architecture | 12 | +| §42.5 The eval harness as an engineering artefact | 12 | +| §42.6 A new threat class: OWASP LLM Top 10 and prompt injection | 13 | +| §42.7 Regulation as a hard constraint: the EU AI Act | 13 | +| §43 How AI Shifts the Matrix (intro) | 13 | +| §43.1 The C10 row, cell by cell | 13 | +| §43.2 D12 across the seven patterns | 13 | +| §43.3 Which existing cells shift, and why | 13 | +| §43.4 MLOps maturity (incl. A6 restated) | 13 | +| §44 Agent Orchestration: The Emergent Eighth Pattern (intro) | 13 | +| §44.1 Case: the course project's advisor workflow | 13 | +| §44.2 What an agent is -- and is not | 13 | +| §44.3 Topologies and their classical analogues | 13 | +| §44.4 The economics of autonomy | 13 | +| §44.5 A capability-profile sketch (incl. projektbox) | 13 | +| §45 Synthesis: One Theory, Five Parts (Maxim 8, thinkbox) | 13 | + +--- + +# Lecture 7: The Fit, Formally -- Three Cases, the Procedure, the Matrix + +- **Week:** 7 -- **Lessons:** 2 -- **Frames:** 30 +- **Title-slide script line:** Script: Part IV, Sections 30--32, 34; Section 37 (introduction) + +## Agenda + +1. Recap: the match, seen once at small scale -- and run by you last week +2. Three matches, three stages: C6 (gate), C1 (veto), C2 (holistic reading and its alarm) +3. The procedure in general -- and what a weighted sum would have destroyed +4. The matching matrix: cell semantics and the $7 \times 10$ grid +5. Reading the matrix as a whole: columns, rows, five support points +6. The measurement contract, introduced: fitness functions and the DORA metrics +7. This week's exercise: the design-review gate and Deliverable A2 + +## Recap: where we are + +- Centre line (deck 3): demand $\to$ supply $\to$ match $\to$ record $\to$ test +- Done (weeks 1--6): Part I -- the framework and the C10 mini-match (L $-$, MM $++$, MS $\circ$); Part II -- seven capability profiles $C(p)$, the consolidated table, Maxims 3 and 4, ordinal reading only; Part III opened -- the C10 profile and the C1/C2 mirror pair (weights, not dimensions, define a class) +- Last week's exercise: you ran the three stages on your own platform (knock-out $\to$ veto $\to$ ordinal reading) and began the ADR +- Today: three cases from Part IV, one per stage; the general statement and the seventy-cell grid; the measurement contract, introduced +- hinweisbox: A2 (architecture dossier: ADR $+$ C4 $+$ measurement contract) is due this week; the design-review gate closes the design phase; production code starts only after the gate + +## Frame overview + +| # | Section | Frame title | Kind | Script ref | Min | +|---|---|---|---|---|---| +| 1 | Title | AISE502: AI in Software Engineering II -- Lecture 7: The Fit, Formally -- Three Cases, the Procedure, the Matrix | content | title slide; subtitle line: Script: Part IV, Sections 30--32, 34; Section 37 (introduction) | 0 | +| 2 | Agenda | Agenda | agenda | deck skeleton (decks 1--6) | 1 | +| 3 | Recap | Recap: where we are | recap | deck 3 recap frame (shape template) and its centre line; deck 6 Summary and Next-week frames; semester plan week 7 | 3 | +| 4 | Three Matches, Three Stages | Part IV opens: three matches, three stages | content | Part IV opening + §30 intro (part4_fit.tex 1-11); operands formula from §31.1 (part4_fit.tex 80-82) | 2 | +| 5 | Three Matches, Three Stages | Case 1 -- C6 against all seven: the shape gate | table | §30.1 (part4_fit.tex 15-16) + Table tab:case-c6 (part4_fit.tex 24-42) | 3 | +| 6 | Three Matches, Three Stages | Case 1 -- one survivor, and the didactic point | case | §30.1 (part4_fit.tex 19-22, 44) | 3 | +| 7 | Three Matches, Three Stages | Case 2 -- C1: the gate passes both, the veto rule decides | case | §30.2 (part4_fit.tex 46-52: intro, Stage 1, Stage 2 for MS) | 3 | +| 8 | Three Matches, Three Stages | Case 2 -- stage 2 for MM, and the stage-3 reading | case | §30.2 (part4_fit.tex 54-57) | 3 | +| 9 | Three Matches, Three Stages | Case 2 -- two kinds of mitigation, and the C1 verdict | case | §30.2 (part4_fit.tex 59) | 3 | +| 10 | Three Matches, Three Stages | Case 3 -- C2: when scoring cannot separate the survivors | case | §30.3 (part4_fit.tex 61-66) | 3 | +| 11 | Three Matches, Three Stages | Case 3 -- stage 3: the comparison refuses to close | table | §30.3 (part4_fit.tex 68) | 4 | +| 12 | Three Matches, Three Stages | Case 3 -- the record refuses the either/or | keyconcept | §30.3 (part4_fit.tex 70) + keypoint (72-74) | 3 | +| 13 | The Procedure in General | The formal statement -- the deck-3 box, plus one clause | definition | §31.1 (part4_fit.tex 76-93); recap of deck 3 frame 'The three-stage fit procedure' | 2 | +| 14 | The Procedure in General | Three stages, decreasing hardness -- each with a worked face | table | §31.1 (part4_fit.tex 103) | 4 | +| 15 | The Procedure in General | Why the fit is not a weighted sum | keyconcept | §31.2 (part4_fit.tex 105-109) | 3 | +| 16 | The Matching Matrix | Cell semantics: what one cell of the grid actually claims | definition | §32.1 (part4_fit.tex 118-130) | 3 | +| 17 | The Matching Matrix | The $7 \times 10$ matching matrix | table | §32.2, Table tab:fitmatrix (part4_fit.tex 132-160) | 4 | +| 18 | The Matching Matrix | Reading the grid: the rows you computed | keyconcept | §32.2 (part4_fit.tex 134, 156) + keypoint (162-164) | 2 | +| 19 | Reading the Matrix as a Whole | Column patterns (1/2): the unfashionable default | content | §34.1 (part4_fit.tex 461-469) | 3 | +| 20 | Reading the Matrix as a Whole | Column patterns (2/2): workload-shaped columns, HX never negative | content | §34.1 (part4_fit.tex 471-473) + footnote minipage (157); excerpt values from tab:fitmatrix (138-147) | 3 | +| 21 | Reading the Matrix as a Whole | Row patterns and the five empirical support points | table | §34.2 (part4_fit.tex 475-479) | 3 | +| 22 | Reading the Matrix as a Whole | Discussion: the C5 row under two variations | discussion | §34.2 thinkbox (part4_fit.tex 485-487) + keypoint (481-483); C5 row from tab:fitmatrix (142) | 6 | +| 23 | The Measurement Contract, Introduced | How a decision made this year stays honest in year five | content | §37 opening (part4_fit.tex 654-659); deck 3 framework frame (measurement contract as fifth element) | 3 | +| 24 | The Measurement Contract, Introduced | Fitness functions -- the definition | definition | §37.1 definitionbox (part4_fit.tex 663-665) | 2 | +| 25 | The Measurement Contract, Introduced | Three instrument families | table | §37.1 enumerate (part4_fit.tex 667-673) | 3 | +| 26 | The Measurement Contract, Introduced | DORA metrics: the delivery layer -- and the coupling finding | content | §37.2 (part4_fit.tex 675-680) | 2 | +| 27 | Closing | This week's exercise: the design-review gate and Deliverable A2 | exercise | project_exercise.tex M2 taskbox (lines 401-414) and phase description (line 361); semester plan week 7 row | 3 | +| 28 | Closing | Summary | summary | deck summary (frames 4-26) | 2 | +| 29 | Closing | Next week | nextweek | semester plan week 8 row; project_exercise.tex M3 (lines 416-420); task brief 'Next lecture' | 1 | +| 30 | Closing | Closing slide | content | deck skeleton | 0 | + +## Frames in detail + +### Section: Title + +#### Frame 1: AISE502: AI in Software Engineering II -- Lecture 7: The Fit, Formally -- Three Cases, the Procedure, the Matrix + +*Kind:* content -- *Source:* title slide; subtitle line: Script: Part IV, Sections 30--32, 34; Section 37 (introduction) -- *Minutes:* 0 + +- \FHGRTitlePage with \subtitle{Lecture 7: The Fit, Formally -- Three Cases, the Procedure, the Matrix\\[0.4ex]{\small Script: Part IV, Sections 30--32, 34; Section 37 (introduction)}} +- author Dr.\ Florian Herzog; \fullname Fachhochschule Graub\"unden, Chur -- Autumn Semester 2026 + +*Elements:* +- FHGR title page (theme), identical to decks 1--6 + +*Notes:* Same preamble and box definitions as deck 6 (copy verbatim). Title format: one colon, then an en-dash, as decks 1--6. + +### Section: Agenda + +#### Frame 2: Agenda + +*Kind:* agenda -- *Source:* deck skeleton (decks 1--6) -- *Minutes:* 1 + +- 1. Recap: the match, seen once at small scale -- and run by you last week +- 2. Three matches, three stages: C6 (gate), C1 (veto), C2 (holistic reading and its alarm) +- 3. The procedure in general -- and what a weighted sum would have destroyed +- 4. The matching matrix: cell semantics and the $7 \times 10$ grid +- 5. Reading the matrix as a whole: columns, rows, five support points +- 6. The measurement contract, introduced: fitness functions and the DORA metrics +- 7. This week's exercise: the design-review gate and Deliverable A2 + +*Elements:* +- enumerate, \small, itemsep 1pt (as deck 6) + +*Notes:* Seven items; each now under ~85 characters so none wraps at \small. + +### Section: Recap + +#### Frame 3: Recap: where we are + +*Kind:* recap -- *Source:* deck 3 recap frame (shape template) and its centre line; deck 6 Summary and Next-week frames; semester plan week 7 -- *Minutes:* 3 + +- Centre line (as deck 3): demand $\to$ supply $\to$ \textbf{match} $\to$ record $\to$ \textbf{test} +- \textbf{Done (weeks 1--6)}: Part I -- the framework and the C10 mini-match (L $-$, MM $++$, MS $\circ$); Part II -- seven capability profiles $C(p)$, the consolidated table, Maxims 3 and 4, ordinal reading only; Part III opened -- the C10 profile and the C1/C2 mirror pair (\emph{weights, not dimensions, define a class}) +- \textbf{Last week's exercise}: you ran the three stages on your own platform (knock-out $\to$ veto $\to$ ordinal reading) and began the ADR +- \textbf{Today}: three cases from Part IV, one per stage $\cdot$ the general statement and the seventy-cell grid $\cdot$ the measurement contract, introduced +- hinweisbox: \textbf{A2 is due this week} -- architecture dossier (ADR $+$ C4 $+$ measurement contract); the design-review gate closes the design phase; production code only after the gate + +*Elements:* +- centred chain line (deck-3 style) +- hinweisbox (A2 due), as deck 3 recap did for A1 + +*Notes:* Deck-3 shape: one centred line, one 'Done' sentence, one exercise line, three short 'Today' items, the hinweisbox. \footnotesize. Do not re-run the mini-match. Emphasise 'you will recognise every step' (deck 6 exercise frame promised it). + +### Section: Three Matches, Three Stages + +#### Frame 4: Part IV opens: three matches, three stages + +*Kind:* content -- *Source:* Part IV opening + §30 intro (part4_fit.tex 1-11); operands formula from §31.1 (part4_fit.tex 80-82) -- *Minutes:* 2 + +- \emph{What does the three-stage procedure actually do when it runs?} -- usually far less than students expect: \textbf{most of the work happens before anything is scored} +- Every Part III class ends with a verdict and a promise -- a one-sentence primary and secondary recommendation, and the assurance that Part IV computes it through the three-stage procedure. You have seen one (C10) and the C1/C2 sketch; Part IV computes those verdicts, and you meet the other rows in weeks 8--9 +- You own both operands: {\scriptsize $R(a) = (w_1(a),\dots,w_{12}(a);\, S(a);\, K(a))$, $w_i \in \{\text{H},\text{M},\text{L}\}$ -- from A1 and Part III; $C(p) = (c_1(p),\dots,c_{12}(p);\, S(p))$, $c_i \in \{++,+,\circ,-,--\}$ -- the seven columns of Part II}. You have watched $\mathrm{fit}(a,p)$ run once at small scale (C10 mini-match); not yet seen: the machine at full load +- Cases first, generalisation after (as Parts II and III worked) -- three matches computed end to end, each exposing one stage: \textbf{C6} -- knock-out screening and shape gate (Stage 1) $\cdot$ \textbf{C1} -- veto rule with documented mitigations (Stage 2) $\cdot$ \textbf{C2} -- holistic ordinal reading with its built-in sensitivity alarm (Stage 3). Each lands on exactly the verdict its Part III section states +- Roadmap strip (tikz, one line of boxes): \textbf{today} §30 cases $\cdot$ §31 procedure $\cdot$ §32 matrix $\cdot$ §34 reading $\cdot$ §37 contract (introduced) $\mid$ \textcolor{gray}{Lecture 10: §33 rationales $\cdot$ §35 hybrids and evolution paths $\cdot$ §36 eight-step decision procedure} $\mid$ \textcolor{gray}{Lecture 11: §37 in depth $\cdot$ §38 organisational complement $\cdot$ §39 limits} + +*Elements:* +- small tikz roadmap strip of Part IV sections derived from the part opening (line 4): 30, 31, 32, 34, 37-intro highlighted 'today'; 33, 35, 36 greyed 'Lecture 10'; 37-depth, 38, 39 greyed 'Lecture 11' + +*Notes:* Leading question in italics, bankblue (deck 4--6 style). Five items maximum incl. the strip; body \footnotesize. The operands formula is here (scriptsize) so frame 13 can stay at the deck-3 box length. The Part-III sections C1--C9 are weeks 8--9: do not say 'recall'. + +#### Frame 5: Case 1 -- C6 against all seven: the shape gate + +*Kind:* table -- *Source:* §30.1 (part4_fit.tex 15-16) + Table tab:case-c6 (part4_fit.tex 24-42) -- *Minutes:* 3 + +- \emph{The nightly risk run must finish by 06:00, reproduce to the bit, and cost as little as possible: which of the seven patterns can even apply for the job?} +- The C6 profile (Part III, Lecture 9 -- given here as the operand): High on \textbf{D2} (makespan reading), \textbf{D9} (reproducibility reading), \textbf{D10}; dominant workload shape \textbf{scheduled batch}; deterministic seeds as a hard constraint +- Before comparing a single rating: hold $S(\text{C6})$ against the native-shape row $S(p)$ of the capability table (deck 6) -- the table carries the gate and its harm clause +- Table columns: Pattern | Native shape $S(p)$ | Stage-1 outcome | Verdict +- L | interactive | gate caps at $\circ$; harm clause -- no answer to makespan or checkpointing, $--$ against High D2 | $--$ +- MM | interactive | gate caps at $\circ$: orchestration codebase around monolithic kernels | $\circ$ +- HX | (host's) | gate caps at $\circ$: ports touch no binding dimension | $\circ$ +- MS | interactive | gate caps; harm clause -- communication cost multiplied against High D10 | $--$ +- EDA | stream / async | gate caps at $\circ$: job-status glue beside scheduler and DAG | $\circ$ +- PF | scheduled batch | \textbf{gate passed} -- proceeds to Stages 2--3; no veto on $\{$D2, D9, D10$\}$ | $++$ +- SL | event-trig., short-lived | gate caps at $\circ$: burst fan-out for communication-light sections only | $\circ$ +- Caption line (\scriptsize): the workload-shape gate against $S(\text{C6}) = $ scheduled batch; only PF proceeds to Stages 2--3; the verdict column is identical to the C6 row of the matching matrix + +*Elements:* +- 7-row scriptsize booktabs table from tab:case-c6 (lines 24-42), columns @{}lp{2.6cm}p{6.6cm}c@{}, arraystretch 0.9; 'event-trig., short-lived' abbreviated as in the script +- the examplebox 'Computing the C6 row: one gate, six casualties' (lines 17-22), Stage-1 half, is carried by the table rows, not repeated as bullets + +*Notes:* Merged frame (former 5 and 6): three bullets above the table, nothing below except the caption line. The two harm-clause verdicts ($--$ for L and MS without any scoring) are the surprise -- say it while pointing at the rows; MS's harm clause is 'the Prime Video lesson at HPC scale' (line 20, deck 6). \footnotesize bullets, scriptsize table. + +#### Frame 6: Case 1 -- one survivor, and the didactic point + +*Kind:* case -- *Source:* §30.1 (part4_fit.tex 19-22, 44) -- *Minutes:* 3 + +- \textbf{Stages 2 and 3 -- one survivor.} Only PF reaches the veto stage, and no veto fires: against the High set $\{$D2, D9, D10$\}$ it rates $+$, $+$, $++$ (PF column, deck 6) -- throughput from data-parallel frameworks, reproducibility by construction, utilisation-driven cost +- Its $--$ on D3 sits on a Low weight and is \emph{inert}; the holistic reading ranks a field of one +- \textbf{Result: $\mathrm{fit}(\text{C6},\text{PF}) = ++$, every other pattern at $\circ$ or below} -- the C6 row of the matrix, computed almost entirely at Stage 1 +- The didactic point generalises: \textbf{run the cheapest test first} -- six of seven candidates died before a single rating was weighed +- The knock-outs of $K(a)$ belong to the same stage and work the same way: $K(\text{C1})$ eliminates any structure that cannot guarantee an ACID booking core, an immutable audit journal, and ten-plus-year retention -- \emph{before} scoring, however well it scales +- The verdict the class's Part III section states (Lecture 9): pipes-and-filters on HPC/batch infrastructure as primary, serverless fan-out for bursty, communication-light parallel sections as secondary -- with the honest subsystem roles (the $\circ$ cells) stated, not hidden + +*Elements:* +- examplebox 'Computing the C6 row' (lines 17-22), second half ('Stages 2 and 3 -- one survivor') + +*Notes:* \footnotesize; 6 bullets. Link back to deck 6's PF profile column (D2 $+$, D9 $+$, D10 $++$, D3 $--$) without re-showing it. + +#### Frame 7: Case 2 -- C1: the gate passes both, the veto rule decides + +*Kind:* case -- *Source:* §30.2 (part4_fit.tex 46-52: intro, Stage 1, Stage 2 for MS) -- *Minutes:* 3 + +- \emph{Two candidates pass the gate, both natively interactive -- and one of them cannot commit a transaction across its own internal boundaries: how does the procedure decide core banking?} +- Recall from the deck-6 mirror pair: C1 High on \textbf{D4, D5, D6, D7, D9}; $K(\text{C1})$ includes an ACID booking core and BCBS 239 / FINMA auditability; shape interactive with batch edges. Contested pair: the modular monolith against microservices -- the MM and MS columns side by side +- \textbf{Stage 1.} Both natively interactive $\to$ the gate passes both; no hard constraint in $K(\text{C1})$ eliminates either -- \emph{a constraint names an obligation, not a pattern}; both can in principle be operated under FINMA-grade audit obligations +- \textbf{Stage 2 for MS.} $c_4(\text{MS}) = --$: no ACID transactions across service boundaries; sagas trade atomicity for choreography complexity. D4 is High in C1 $\to$ \textbf{the veto fires and caps the cell at $-$} +- The fact is \emph{structural}: no mitigation \emph{restores} ACID across service boundaries -- sagas buy coordination with compensating actions, not atomicity -- so a mitigation can only show that living without the property is \emph{survivable} +- Monzo (deck 5): roughly 2{,}800 microservices in production banking -- under \textbf{organisational scale plus extreme technological homogeneity} (one language, one monorepo, central migration automation); a condition most organisations do not meet, the premium paid in platform staffing with no gain for typical team sizes +- Cap lifted \textbf{only to $\circ$}, the condition recorded in the cell rationale; MS's $--$ on D8 and D10 sit on Low weights -- no further veto fires +- \textbf{Result: $\mathrm{fit}(\text{C1},\text{MS}) = \circ$} + +*Elements:* +- examplebox 'Computing the cells C1/MS and C1/MM step by step' (lines 50-57), Stage-1 paragraph and 'Stage 2 -- veto rule for MS' paragraph + +*Notes:* Merged frame (former 8 and 9). \footnotesize, 8 bullets -- the density limit; keep bullets 3, 7 and 8 to one line. Students met the Monzo homogeneity condition in deck 5; here it is priced. Stress on bullet 3: a constraint names an obligation, not a pattern. + +#### Frame 8: Case 2 -- stage 2 for MM, and the stage-3 reading + +*Kind:* case -- *Source:* §30.2 (part4_fit.tex 54-57) -- *Minutes:* 3 + +- \textbf{Stage 2 -- veto rule for MM.} $c_4(\text{MM}) = ++$ (cross-module ACID transactions) -- no veto +- But $c_5(\text{MM}) = -$ on High-weight D5 $\to$ caps the cell at $\circ$ -- \emph{unless a documented mitigation exists} +- It does: \textbf{hot-standby replication of whole monolith instances} -- the classical banking high-availability tactic, in production at Fineract-class core-banking systems. The cap is lifted. +- \textbf{Stage 3 -- holistic reading.} MM now stands at $++$ on D4, $+$ on D6, $+$ on D7, $+$ on D9 -- support on every High-weight dimension of the class, with the one structural weakness mitigated +- \textbf{Result: $\mathrm{fit}(\text{C1},\text{MM}) = ++$} +- The ranking MM $\succ$ MS for the C1 core is \textbf{stable under plausible weight variation}: it would flip only if D11 (team scaling) rose to High \emph{and} the Monzo homogeneity condition held -- exactly what the C1 cell rationale (Section 33, Lecture 10) records as the escalation condition + +*Elements:* +- examplebox (lines 50-57), 'Stage 2 -- veto rule for MM' and 'Stage 3' paragraphs + +*Notes:* \footnotesize. Do not add MS's ratings on D5--D9 here: the passage states only MS's D4/D8/D10 cells; the comparison lives in the next frame as two kinds of mitigation. + +#### Frame 9: Case 2 -- two kinds of mitigation, and the C1 verdict + +*Kind:* case -- *Source:* §30.2 (part4_fit.tex 59) -- *Minutes:* 3 + +- Two columns. Left: \textbf{operational weakness} -- MM's one-process blast radius (D5): \emph{repaired outright} by a standard tactic -- hot standby, pod replication +- Right: \textbf{structural weakness} -- atomicity surrendered at the boundary (MS, D4): can only be \emph{made survivable}, under a condition most organisations do not meet +- The division of labour generalises: the veto rule does the heavy lifting, and the \textbf{``documented mitigation'' clause is where engineering knowledge -- not arithmetic -- enters the computation} +- The rest of the row follows the same mechanics (Section 33, Lecture 10); in particular \textbf{HX -- a delta discipline, not a competitor -- joins MM at $++$} by isolating the long-lived booking core from volatile channels and providers +- The verdict the class's Part III section states (Lecture 9): a \textbf{hexagonal modular monolith for the booking core} (MM and HX at $++$), EDA at the edges and PF for the batch runs as secondary, and microservices only when organisation size forces D11 to High -- the Monzo condition -- exactly the C1 row of the matrix + +*Elements:* +- two-column comparison (operational vs structural mitigation), deck-6 mirror-pair layout +- verdict as a one-line bold statement below the columns + +*Notes:* The asymmetry is the lesson of the case; give it the visual centre. \footnotesize. + +#### Frame 10: Case 3 -- C2: when scoring cannot separate the survivors + +*Kind:* case -- *Source:* §30.3 (part4_fit.tex 61-66) -- *Minutes:* 3 + +- \emph{Two finalists carry $++$ where it matters and neither dominates: what does the procedure return when scoring cannot separate the survivors?} +- C2 (from the deck-6 mirror pair): the \textbf{widest High set in the catalogue} -- D1, D3, D5, D7, D9, D11 -- and a constraint set that knocks out almost nothing; the discrimination work is done by the \emph{weights}, not the constraints +- \textbf{Stage 1} requires one honest observation about shape: the class core has \textbf{two constitutive paths} -- the interactive read path that serves the feed, and the asynchronous fan-out path that delivers posts (the five-second delivery scenario, given here from the C2 profile of Part III, is binding for the class) +- Neither MS (natively interactive) nor EDA (natively stream/async) is shape-foreign to the path it would carry $\to$ the gate passes both +- \textbf{Stage 2} fires one veto against each, and documented practice lifts both: MS's $-$ on High-weighted D3 (mitigation: edge caching, precomputed timelines); EDA's $-$ on High-weighted D9 (mitigation: schema/contract tests, progressive delivery) +- Both reach Stage 3 intact + +*Elements:* +- none (bullets); the 'per constitutive path' reading of the gate returns in the formal statement (frame 13) as the one clause not shown in deck 3 + +*Notes:* \footnotesize. The C2 profile (tab:req-c2) is Lecture 8 material: the High set is recalled from the deck-6 mirror pair, the delivery scenario is given, not recalled. Flag that the per-path reading of the gate is the one element not in deck 3's definition. + +#### Frame 11: Case 3 -- stage 3: the comparison refuses to close + +*Kind:* table -- *Source:* §30.3 (part4_fit.tex 68) -- *Minutes:* 4 + +- Table across the C2 High set -- columns High dimension | MS | EDA: +- D1 read scalability | $++$ | $++$ +- D3 latency \& predictability | (mitigated) | $+$ +- D5 availability \& isolation | $++$ | $++$ +- D7 evolvability | $++$ | $++$ +- D9 testability \& deployability | $+$ | (mitigated) +- D11 team scaling | $++$ | $+$ +- \textbf{Neither dominates}: MS leads where \emph{teams} multiply (D9, D11 -- independent deployments), EDA where \emph{consumers} multiply (D3 on the asynchronous path; D7 in its attach-new-consumers reading) +- The \textbf{mandatory sensitivity analysis flips the ordering under entirely plausible variation}: weight D11 the way a several-hundred-team organisation must, and MS wins; frame the feed as what it technically is -- an eventually consistent, precomputed product of an event flow -- and EDA wins +- By Stage 3's own rule, that instability is \textbf{not noise}: it marks a genuine tradeoff point in the ATAM sense, to be escalated to scenario-based analysis rather than smoothed over + +*Elements:* +- 6-row scriptsize table (High dimension | MS | EDA) built from the two rating sequences in line 68 (MS: $++$, (mitigated), $++$, $++$, $+$, $++$; EDA: $++$, $+$, $++$, $++$, (mitigated), $+$), in High-set order D1, D3, D5, D7, D9, D11 + +*Notes:* Table on top (compact, 3 columns), three bullets below in \footnotesize. The dimension names are the standard D-labels of the reference card; the passage gives only the numbers. + +#### Frame 12: Case 3 -- the record refuses the either/or + +*Kind:* keyconcept -- *Source:* §30.3 (part4_fit.tex 70) + keypoint (72-74) -- *Minutes:* 3 + +- Twitter's timeline architecture is \textbf{both patterns at once}: fan-out-on-write \emph{is} publish/subscribe -- an event flow whose product, the precomputed timeline, is served by independently scaled services +- The honest reading of the instability is not ``the procedure failed to pick a winner'' but ``\textbf{the class genuinely needs both patterns, placed}'' -- the bridge to hybrids (Section 35, Lecture 10), where hybrids turn out to be the normal case, not the exception +- The verdict the class's Part III section states (Lecture 8): an \textbf{EDA $+$ microservices hybrid at organisational scale} (MS and EDA at $++$), a modular monolith as secondary until that scale is \emph{measured}, not assumed -- Mastodon runs the full fan-out mechanics in a Rails monolith -- exactly the C2 row +- keypoint: Three cases, three stages, one division of labour -- the knock-out screening and shape gate kill most candidates before any scoring (C6: the cheapest test runs first); the veto rule disciplines the High set and prices every mitigation as documented engineering rather than optimism (C1); the holistic ordinal reading ranks the survivors while flagging its own instability as a finding, not an error (C2). Every one of the seventy cells was produced by exactly this division of labour. + +*Elements:* +- keypoint box, condensed from lines 72-74 + +*Notes:* Three bullets + keypoint: fits at \footnotesize. Closes the section. C2 is Lecture 8 (Part III, Sections 18--23 cover C1--C5). + +### Section: The Procedure in General + +#### Frame 13: The formal statement -- the deck-3 box, plus one clause + +*Kind:* definition -- *Source:* §31.1 (part4_fit.tex 76-93); recap of deck 3 frame 'The three-stage fit procedure' -- *Minutes:* 2 + +- \emph{What rule were the three matches following?} -- stated briefly, because every element has already done visible work: $\mathrm{fit}(a,p)$ is the ordinal aggregate of the dimension-wise comparison of $R(a)$ and $C(p)$ (operands: opening frame), on the same five-step scale, computed under a deliberately \textbf{non-compensatory, three-stage procedure} +- definitionbox Architecture--application fit (the box you saw in deck 3, now with worked faces): +- 1. \textbf{Knock-out screening and workload-shape gate} -- $K(a)$ eliminates before any scoring; $S(p) \neq S(a)$ caps the cell at $\circ$ (subsystem role; $+$ only for a \emph{constitutive} subsystem of a shape-hybrid class; $-$/$--$ where it would harm the binding scenarios). \textbf{Not shown in deck 3: the gate is read per constitutive path} -- a pattern is not shape-foreign to a class one of whose binding scenarios constitutes a path of the pattern's native shape (Case 3: C2's fan-out delivery scenario) +- 2. \textbf{Veto rule on High-weight dimensions} -- $c_i(p) = --$ on a High dimension caps at $-$; $c_i(p) = -$ caps at $\circ$ -- unless a documented mitigation exists (a tactic or hybrid composition with production evidence): the cell says so, the cap is lifted +- 3. \textbf{Holistic ordinal reading with mandatory sensitivity analysis} -- survivors ranked by support of the High set; clustered Medium conflicts downgrade one step; a \emph{ranking with exclusions}, never ``12\,\% better''; a flip under plausible weight variation marks a tradeoff point (ATAM) and is escalated to scenario-based analysis + +*Elements:* +- definitionbox 'Architecture--application fit' (lines 86-93), condensed to three items of deck-3 length; the per-constitutive-path clause (line 89, last sentence) set in bold and labelled 'not shown in deck 3' -- a deck-level highlight, the script presents it as part of the definition + +*Notes:* Recap frame in substance: the box is deck 3's; do not re-teach it -- point at the three worked faces (C6, C1, C2) and dwell only on the bold per-path clause. Operands formula lives on frame 4, so this frame stays at deck-3 box length (\footnotesize). If it still overflows, split '(1/2) stage 1' / '(2/2) stages 2--3'. + +#### Frame 14: Three stages, decreasing hardness -- each with a worked face + +*Kind:* table -- *Source:* §31.1 (part4_fit.tex 103) -- *Minutes:* 4 + +- The three stages are ordered by \textbf{decreasing hardness}, and each now has a worked face: +- Table columns: Stage | What it encodes | Worked face +- 1 Knock-out and shape gate | facts no merit elsewhere can compensate -- a violated BCBS 239 obligation, an interactive pattern asked to carry a scheduled-batch core | Case 1 (C6): this stage running the show, emptying six of the row's seven cells on shape alone +- 2 Veto rule | \textbf{Assumption A4}: the High weights come from the $(H,H)$ leaves of a utility tree (deck 2), so a structural failure on such a dimension fails precisely the scenarios that define the class -- unless engineering practice has produced a documented way around it | Case 2 (C1): both halves of the rule -- a mitigation that \emph{repairs} (MM's hot standby) and one that merely makes \emph{survivable under condition} (MS's Monzo condition) +- 3 Holistic ordinal reading | deliberately the softest: produces an ordering, and carries a built-in alarm for its own instability | Case 3 (C2): the alarm fired and returned a hybrid rather than a false winner + +*Elements:* +- 3-row footnotesize table Stage | What it encodes | Worked face (p{2.6cm} p{5.6cm} p{5.0cm}), from line 103 + +*Notes:* One table, one intro line -- the actually new content of §31.1. The A4 link (High = (H,H) leaves) connects to deck 2's utility-tree frame; spend the extra minute there. + +#### Frame 15: Why the fit is not a weighted sum + +*Kind:* keyconcept -- *Source:* §31.2 (part4_fit.tex 105-109) -- *Minutes:* 3 + +- Deck 3 (Part I): $V(p) = \sum_i w_i \cdot v_i(p)$ presupposes cardinal scales, preferential independence, and weights as trade-off rates -- all three violated by ordinal profiles (A2); AHP inherits rank reversal +- \textbf{What the three cases add -- a demonstration of what the formula would have destroyed:} +- C6: it would have averaged the shape gate away under good scores elsewhere $\cdot$ C1: it would have let MS's missing cross-service ACID be compensated by team scaling $\cdot$ C2: it would have manufactured a decimal-point winner exactly where the honest output is a flagged tradeoff point +- Kept from multi-criteria decision analysis: the \emph{explication discipline} (criteria, weights, assumptions forced into the open); dropped: its arithmetic pretensions -- the matrix is an \textbf{explication and communication instrument}, not a computation that determines decisions; behind every contested cell stands \textbf{ATAM}, and, where money decides, \textbf{CBAM} (utility-response curves, return on investment) +- keypoint: the fit computation is non-compensatory by design -- constraints knock out before anything is scored, structural failures on High-weight dimensions veto unless a documented mitigation exists, and only then does a holistic ordinal ranking follow, with mandatory sensitivity analysis. A weighted sum over ordinal profiles would be formally illegitimate and would average away exactly the failures that matter most. + +*Elements:* +- keypoint box (lines 107-109), condensed +- the three C-lines as a compact three-item list + +*Notes:* One recap line only (deck 3's 'Why the obvious alternative fails' / 'pseudo-precision' frames); the three-case demonstration is the new content. \footnotesize: four bullets + keypoint. + +### Section: The Matching Matrix + +#### Frame 16: Cell semantics: what one cell of the grid actually claims + +*Kind:* definition -- *Source:* §32.1 (part4_fit.tex 118-130) -- *Minutes:* 3 + +- \emph{What does one cell of a seventy-cell grid actually claim?} A matrix cell answers one precisely delimited question -- and misreading that question is the \textbf{most common student error} with this instrument +- definitionbox Cell semantics of the matching matrix: a cell $\mathrm{fit}(a,p)$ states the fit of pattern $p$ \emph{as the dominant structure of the core} of application class $a$ -- the pattern that owns the class's binding quality attribute scenarios. It does \emph{not} state whether $p$ is useful anywhere in a system of class $a$: hybrid roles at the edges (an event journal beside an ACID core, a batch pipeline beside an interactive product) are stated in the cell rationale, not in the cell value +- \textbf{Consequence 1: a $-$ cell is not a prohibition.} EDA rates $-$ as the dominant structure of a banking core, yet the same rationale names the immutable event journal as the natural regulatory audit trail at that core's edges +- \textbf{Consequence 2: the hexagonal column needs a special reading.} HX is a delta pattern of dependency organisation, not a distribution style; it composes with a host (typically MM), and its cells read ``as the internal discipline of the class's core'' + +*Elements:* +- definitionbox 'Cell semantics of the matching matrix' (lines 121-123) + +*Notes:* Definition box + two consequences; \footnotesize. Ask students to keep the definition in mind before the grid appears. + +#### Frame 17: The $7 \times 10$ matching matrix + +*Kind:* table -- *Source:* §32.2, Table tab:fitmatrix (part4_fit.tex 132-160) -- *Minutes:* 4 + +- 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 line (\scriptsize): ratings $++$ (excellent fit) to $--$ (structural misfit); bold $=$ cells underlying the primary recommendation of each class; $^{\dagger}$HX is a delta pattern -- composes with a host (typically MM), cells read ``as the internal discipline of the class's core''; abbreviations L $=$ layered/3-tier, MM $=$ modular monolith, MS $=$ microservices, EDA $=$ event-driven, PF $=$ pipes-and-filters/batch pipeline, SL $=$ serverless/FaaS + +*Elements:* +- 10-row scriptsize booktabs table from tab:fitmatrix (lines 138-152), columns @{}p{4.2cm}ccccccc@{}, arraystretch 0.85 -- upright (the script's sidewaystable becomes a normal slide table, same format as deck 6's consolidated capability table) +- one-line scriptsize footnote condensed from the minipage (lines 156-158), without the never-negative sentence (frame 20 carries it) + +*Notes:* The central slide of the deck: nothing else on it. Optionally shade rows C1, C2, C6 lightly (colortbl, bankblue!8) to mark 'the rows you computed'. Give students a silent minute with the grid before talking. + +#### Frame 18: Reading the grid: the rows you computed + +*Kind:* keyconcept -- *Source:* §32.2 (part4_fit.tex 134, 156) + keypoint (162-164) -- *Minutes:* 2 + +- The matrix is the three cases of Section 30, \textbf{done seventy times} +- Rows C6, C1, C2: the rows you have just computed; the remaining seven were produced by exactly the same three stages -- knock-out and shape gate, then the H-dimension veto with documented mitigations, then the holistic ordinal reading +- Every cell is traceable to $R(a) \times C(p)$ through the per-class rationales (Section 33 -- Lecture 10) +- $^{\dagger}$HX: a delta pattern -- it composes with a host (typically MM), and its cells read ``as the internal discipline of the class's core'' +- keypoint: read a matrix cell as the answer to one question only -- \emph{how well does this pattern serve as the dominant structure of this class's core?} The edges of the same system routinely use patterns whose cell reads $\circ$ or $-$; the hybrid roles are stated in the rationales, and Section 35 (Lecture 10) shows that hybrids are the normal case, not the exception + +*Elements:* +- keypoint box (lines 162-164) + +*Notes:* Short frame after the grid; \footnotesize like every other content frame. The never-negative claim is deferred to frame 20, where the excerpt table makes it checkable. Point back to the C10 row: identical to the deck-3 mini-match verdicts (L $-$, MM $++$, MS $\circ$) -- now with HX $++$, EDA $+$, PF $+$, SL $\circ$ added. + +### Section: Reading the Matrix as a Whole + +#### Frame 19: Column patterns (1/2): the unfashionable default + +*Kind:* content -- *Source:* §34.1 (part4_fit.tex 461-469) -- *Minutes:* 3 + +- \emph{What does the grid say as a whole that no single cell can?} The matrix rewards a second reading -- not cell by cell but by columns, rows, and boundaries +- Column-wise, the \textbf{modular monolith is primary or secondary in seven of ten classes} -- not because it is fashionable (it is conspicuously unfashionable) but because most requirements profiles weight consistency, evolvability, cost, and time-to-market higher than independent scaling, and \textbf{MM is the only pattern rated $+$ or better on all four} of those dimensions (capability table, deck 6) +- The matrix-level restatement of Fowler's \textbf{MonolithFirst}: do not start with microservices even if you expect to need them -- stable service boundaries cannot be cut before the domain is understood, and refactoring \emph{between} services is far costlier than \emph{within} a monolith +- \textbf{Microservices earn their premium in exactly two situations}, both visible in the grid: where High-weight read scalability, fault isolation, and team scaling coincide (C2, and conditionally C5 and C8) -- and nowhere else +- The premium is real and quantified: $--$ on cost and simplicity; the run-cost side materialises as platform staffing -- self-managed Kubernetes TCO \textbf{roughly three times} managed offerings, dominated by personnel (deck 5); the two $--$ cells in the MS column (C3, C4) mark the classes that \textbf{pay the premium and collect nothing} + +*Elements:* +- none -- bullets only; the MM and MS columns appear in the excerpt table of frame 20 + +*Notes:* \footnotesize, 5 bullets, no side table (the optional column excerpt has been removed; frame 20's five-column excerpt covers the visual check). + +#### Frame 20: Column patterns (2/2): workload-shaped columns, HX never negative + +*Kind:* content -- *Source:* §34.1 (part4_fit.tex 471-473) + footnote minipage (157); excerpt values from tab:fitmatrix (138-147) -- *Minutes:* 3 + +- \textbf{PF and EDA are workload-shaped columns.} Their $++$ cells sit precisely where the class's dominant workload shape matches the pattern's native shape -- scheduled batch for PF (C6, C7), continuous stream or fan-out for EDA (C8, C9, and the C2 fan-out) +- The shape gate caps them at $\circ$ -- or, by the harm clause, below -- everywhere the class core is interactive +- The clearest demonstration that the gate of Stage 1 does real work: \textbf{no amount of merit on other dimensions lets a batch pipeline carry an interactive core} +- \textbf{The HX column is never negative} -- not a free lunch but a property of orthogonality: as a delta pattern, hexagonal architecture composes with the host rather than competing with it, and its cost ($c_8 = -$) surfaces only as capped cells where the change rate is low (C6, C7) +- Column excerpt table (Class | MM | MS | HX | EDA | PF): C1 $++$ $\circ$ $++$ $-$ $\circ$; C2 $+$ $++$ $\circ$ $++$ $\circ$; C3 $++$ $--$ $+$ $-$ $\circ$; C4 $++$ $--$ $+$ $-$ $\circ$; C5 $++$ $+$ $+$ $+$ $\circ$; C6 $\circ$ $--$ $\circ$ $\circ$ $++$; C7 $+$ $-$ $\circ$ $\circ$ $++$; C8 $-$ $+$ $\circ$ $++$ $+$; C9 $+$ $+$ $\circ$ $++$ $-$; C10 $++$ $\circ$ $++$ $+$ $+$ + +*Elements:* +- 10-row scriptsize five-column excerpt (MM, MS, HX, EDA, PF) of tab:fitmatrix (lines 138-147) on the right, bullets on the left (columns 0.58/0.38); MM/MS columns serve frame 19's claims (seven of ten; the two $--$ cells C3, C4), HX/EDA/PF serve this frame's + +*Notes:* The excerpt makes the claims visually checkable: $++$ only on shape matches; no negative HX cell; the MS $--$ cells at C3/C4. Speaker note on bullet 2: the $-$ cells of EDA (C1, C3, C4) and PF (C9) are harm-clause results of the same gate (definition item 1, line 89) -- the script's sentence at line 471 says only 'caps at $\circ$'. + +#### Frame 21: Row patterns and the five empirical support points + +*Kind:* table -- *Source:* §34.2 (part4_fit.tex 475-479) -- *Minutes:* 3 + +- Row-wise: \textbf{no class is served above $\circ$ by every pattern, and no pattern serves every class above $\circ$} -- Assumption A2 made visible in a single glance at the grid +- If a dominant pattern existed, its column would be uniformly positive, and this part of the module would be one page long +- Cell-wise: the five case-study systems of the module each sit \textbf{exactly on a cell boundary} -- the empirical support points at which fit and misfit have been \emph{measured in money} +- Table columns: System | Cell it sits on | What was measured +- Prime Video (deck 6) | the split serverless cost cell | over 90\,\% infrastructure cost reduction after consolidating a data-intensive flow into one process +- Segment | the MS evolvability cell, read against a wrongly cut boundary | services per configuration instance, not per domain seam +- Shopify | the MM write-scalability mitigation | pod-sharded replication +- Uber (DOMA) | the MS team-scaling cell | the point where service count itself became the problem +- Stack Overflow | the layered read-scalability deviation | cache-friendly read dominance served by roughly nine web servers + +*Elements:* +- 5-row scriptsize table System | Cell | What was measured (p{2.4cm} p{4.6cm} p{6.2cm}) from line 479 + +*Notes:* Three bullets above the table at \footnotesize; the table carries only what the passage states (no further figures). All five systems were case studies in decks 3--6; the deck marker is set on Prime Video, the one this deck reuses again in frame 23. + +#### Frame 22: Discussion: the C5 row under two variations + +*Kind:* discussion -- *Source:* §34.2 thinkbox (part4_fit.tex 485-487) + keypoint (481-483); C5 row from tab:fitmatrix (142) -- *Minutes:* 6 + +- The C5 row for reference: L $-$ | MM $++$ | HX $+$ | MS $+$ | EDA $+$ | PF $\circ$ | SL $+$ +- thinkbox: Take the C5 row (e-commerce) and increase the organisation from 3 teams to 30 while holding traffic constant. Which cells change, through which dimension, and at which stage of the three-stage procedure? +- thinkbox: Now hold the organisation at 3 teams and multiply traffic by 50. +- thinkbox: Why does the second variation move the row so much less than the first -- and what does that say about the popular claim that ``we need microservices to scale''? +- keypoint (closing line, after the discussion): the modular monolith dominates the matrix as default \emph{not despite but because of} its unfashionableness: most requirements profiles weight consistency, evolvability, cost, and time-to-market above independent scaling. Microservices earn their documented premium only where read scalability, fault isolation, and team scaling are simultaneously High -- and the premium is paid in platform staffing either way + +*Elements:* +- one-line C5 row excerpt from tab:fitmatrix (line 142) +- thinkbox 'Discussion' with the three questions (lines 485-487) +- keypoint (lines 481-483), condensed, placed below the thinkbox as the closing line + +*Notes:* Budgeted at 6 minutes: run Stage 2/3 on the C5 row twice with the room. Expected direction -- inferred from §34.1 (lines 465-467) and §34.2 (line 479), NOT stated in the script: the first variation moves D11 to High and re-runs Stage 2/3 in MS's favour (the C2 condition); the second moves D1/D2 but MM's mitigations (Shopify-style replication) hold. Keep this in the speaker notes only; the keypoint is revealed last. + +### Section: The Measurement Contract, Introduced + +#### Frame 23: How a decision made this year stays honest in year five + +*Kind:* content -- *Source:* §37 opening (part4_fit.tex 654-659); deck 3 framework frame (measurement contract as fifth element) -- *Minutes:* 3 + +- \emph{How does a decision made this year stay honest in year five?} One case motivates the apparatus +- What actually triggered the Prime Video re-architecture (deck 6) was \textbf{not an architecture review but a telemetry signal}: infrastructure cost per stream, measured continuously, crossed what the team was willing to pay -- and that measurement, not an opinion, first forced and then vindicated the redesign +- The cost dashboard was a \textbf{fitness function in everything but name}: an objective, continuously evaluated check on an architectural characteristic whose breach converted a running structure from ``accepted'' into ``falsified'' +- Empirical anchor for building such checks systematically: DORA's finding that \textbf{loosely coupled architectures and teams are the strongest predictor of continuous delivery} -- coupling, this theory's leading dimension, is a \emph{measurable} property +- The seventh step of the eight-step decision procedure (Section 36, Lecture 10) generalises the observation into a concept -- where this course differs from a classical architecture lecture: the chosen fit is codified as a \textbf{measurement contract} -- the set of executable invariants under which the architecture is allowed to keep evolving. \textcolor{bankblue}{\textbf{``The architecture may change freely as long as the contract stays green''}} +- Deck 3 named the contract as the fifth framework element -- today its definition and instruments; depth (taxonomy in CI/CD, the four-layer cascade, Boehm vs.\ Menzies) in Lecture 11 + +*Elements:* +- none; the contract motto set as a highlighted one-liner (\textcolor{bankblue}) + +*Notes:* Bridge to A2: this is the third artefact of the dossier. The 'Lecture 11' pointer lives here (removed from the DORA frame). + +#### Frame 24: Fitness functions -- the definition + +*Kind:* definition -- *Source:* §37.1 definitionbox (part4_fit.tex 663-665) -- *Minutes:* 2 + +- definitionbox Architectural fitness function: ``any mechanism that provides an objective integrity assessment of some architectural characteristic''. Fitness functions turn quality attributes into executable, objective checks and move architecture governance from review meetings into the CI/CD pipeline +- Classified along two primary dimensions -- mini-table (two rows): +- \textbf{Scope} | \emph{atomic}: one characteristic in isolation (e.g.\ a dependency rule as a unit test) | \emph{holistic}: combined characteristics in interplay (e.g.\ security and data freshness under load) +- \textbf{Cadence} | \emph{triggered}: event-based, on every build or deployment | \emph{continual}: running permanently in operation (e.g.\ chaos experiments) | \emph{temporal}: time-scheduled (e.g.\ dependency-freshness time bombs) + +*Elements:* +- definitionbox 'Architectural fitness function' (lines 663-665), quote + one sentence +- two-row footnotesize mini-table Scope (atomic | holistic) / Cadence (triggered | continual | temporal) with the script's own examples -- not a 2x3 cross-table, because the script gives no example for four of the six cross cells + +*Notes:* Split from the former frame 26 (definition + families were overfull). Introduction only: the taxonomy in CI/CD is Lecture 11. + +#### Frame 25: Three instrument families + +*Kind:* table -- *Source:* §37.1 enumerate (part4_fit.tex 667-673) -- *Minutes:* 3 + +- Three worked instrument families recur throughout the module -- table columns: Family | Instruments | Scope / cadence | What it makes testable +- 1 Dependency checks as CI gates (decks 3--4) | ArchUnit (analogues: NetArchTest, dependency-cruiser, import-linter): ``the domain layer imports no framework'', ``no cycles between modules'' as unit tests that fail the build; Spring Modulith for declared module boundaries | atomic, triggered | what makes the MM ratings of the capability table \emph{enforceable} rather than aspirational -- without automated boundary verification, boundary erosion is the documented failure mode of the pattern +- 2 Performance and cost budgets as pipeline gates | latency thresholds, bundle sizes, Lighthouse scores declared in a budget file | (pipeline gate) | \textbf{Axis B transfer is direct: token-cost budgets and p95 latency budgets per AI use case are the same mechanism with new units} +- 3 Chaos experiments | Netflix's Chaos Monkey terminates production instances to test resilience assumptions permanently; formalised as the principles of chaos engineering | holistic, continual | verifies the \textbf{D5 cells}: a claimed blast radius is a hypothesis until an instance has actually been killed under load + +*Elements:* +- 3-row scriptsize table Family | Instruments | Scope / cadence | What it makes testable, columns p{2.2cm} p{5.0cm} p{1.8cm} p{4.4cm}, from the enumerate in lines 669-673; the family-2 scope/cadence cell reads '(pipeline gate)' without a scope label because the script classifies only families 1 and 3 + +*Notes:* Table alone on the frame. The Axis-B sentence (line 671) is the deck's only AI-lens material -- set in bold, no separate ailinse frame (see open_issues); map it onto item 3 of the A2 measurement contract on the exercise frame. Family 1 was deck 4's ArchUnit/Spring Modulith CI gate and deck 3's ADR-011 confirmation block: say 'the first fitness function most teams ever write' verbally, not on the slide. + +#### Frame 26: DORA metrics: the delivery layer -- and the coupling finding + +*Kind:* content -- *Source:* §37.2 (part4_fit.tex 675-680) -- *Minutes:* 2 + +- The four DORA metrics measure whether the delivery-relevant promises of a structure are being kept: \textbf{deployment frequency} and \textbf{lead time for changes} (tempo); \textbf{change failure rate} and \textbf{failed-deployment recovery time} (stability) +- Central empirical finding: elite performers lead on \emph{all four} -- \textbf{tempo and stability are not a trade-off} +- The strongest single result in the field supports coupling as the leading dimension of this entire theory: ``loosely coupled architectures and teams are the strongest predictor of continuous delivery'' -- in the 2017 analysis, testability and deployability contributed more to continuous delivery than test and deployment automation itself +- High performance is possible with all kinds of systems -- including mainframes -- provided systems and teams are loosely coupled: the label ``microservices'' is \emph{neither necessary nor sufficient} +- Second follow-on finding (deck 5, depth in Lecture 11): as team count grows, deployments per developer per day \emph{rise} for high performers and \emph{fall} for low performers +- hinweisbox: DORA's evidence is survey-based and analysed with structural equation models -- prediction, not experimental causal proof. The theory treats it as the best available large-$n$ evidence, to be triangulated against case studies and your own measurements -- not as settled law + +*Elements:* +- hinweisbox with the honesty caveat (line 680) + +*Notes:* \footnotesize; five one-to-two-line bullets + hinweisbox. The 'neither necessary nor sufficient' line closes the loop to frame 19 (MS premium) and deck 6's Conway bullet. No separate 'Depth' line -- frame 23 carries the Lecture-11 pointer. + +### Section: Closing + +#### Frame 27: This week's exercise: the design-review gate and Deliverable A2 + +*Kind:* exercise -- *Source:* project_exercise.tex M2 taskbox (lines 401-414) and phase description (line 361); semester plan week 7 row -- *Minutes:* 3 + +- projektbox: \textbf{The design phase closes this week.} Finalise the solution design: +- 1. \textbf{Service cut and contracts} -- bounded contexts $\to$ service decomposition and the contracts between the deterministic core, the edges, and the AI subsystem +- 2. \textbf{Walking-skeleton plan} -- the thin end-to-end slice you will build first in Sprint 1 +- 3. \textbf{Measurement contract} -- in today's vocabulary: a \emph{token budget} (family 2: cost budget as a pipeline gate), an \emph{eval threshold} (pass rate on the golden set before rollout), and \emph{module-boundary checks} (family 1: dependency rules as CI gates, ArchUnit / import-linter style) +- 4. \textbf{Design-Review Gate} -- defend the ADR: which vetoes fired, which mitigations are \emph{documented}, what the sensitivity check showed +- \textbf{Deliverable A2 (end of week 7): architecture dossier} -- ADR $+$ C4 diagram $+$ measurement contract. Production code starts only after the gate (exploratory spikes are allowed) +- Below the box (\small): From week 8 the exercise slot becomes a one-lesson (one-hour) standup/coaching session and the lecture grows to three lessons; Sprint 1 (walking skeleton) begins + +*Elements:* +- projektbox with enumerate (deck-6 exercise-frame format); the outlook line sits outside the box as \small text, as deck 6 did + +*Notes:* Map each measurement-contract item to one of the instrument families from frame 25 so the lecture content lands directly in the deliverable. 'and the AI subsystem' in item 1 is consistent with the deck-6 projektbox but is not in the M2 taskbox wording ('Bounded contexts -> service decomposition and contracts'). + +#### Frame 28: Summary + +*Kind:* summary -- *Source:* deck summary (frames 4-26) -- *Minutes:* 2 + +- 1. \textbf{Three cases, three stages}: C6 -- the gate empties six of seven cells before scoring; C1 -- the veto rule decides, mitigations priced as documented engineering; C2 -- the reading flags its own instability and returns a hybrid +- 2. \textbf{Two kinds of mitigation}: an operational weakness is repaired outright (hot standby); a structural one is only made survivable under a condition most organisations do not meet (Monzo) +- 3. \textbf{The formal statement}: $\mathrm{fit}(a,p)$ -- ordinal, non-compensatory, three stages of decreasing hardness; the gate is read per constitutive path; a weighted sum would have destroyed exactly the three decisive facts +- 4. \textbf{Cell semantics}: a cell rates the pattern as the dominant structure of the core only; $-$ is not a prohibition; HX reads as the internal discipline of the core +- 5. \textbf{The grid}: MM primary or secondary in seven of ten; MS premium in two situations only; PF/EDA workload-shaped; HX never negative; no row or column uniformly positive (A2) +- 6. \textbf{Five support points}: Prime Video, Segment, Shopify, Uber, Stack Overflow each sit on a cell boundary -- fit and misfit measured in money +- 7. \textbf{Measurement contract}: fitness functions (scope $\times$ cadence; dependency checks, budgets, chaos) and the four DORA metrics; \emph{the architecture may change freely as long as the contract stays green} + +*Elements:* +- numbered list (7 points, each at most two lines), \footnotesize, no keypoint + +*Notes:* Keypoint dropped (its two claims are points 4 and 7). Deck-6 summary shape: seven points of 1--2 lines. + +#### Frame 29: Next week + +*Kind:* nextweek -- *Source:* semester plan week 8 row; project_exercise.tex M3 (lines 416-420); task brief 'Next lecture' -- *Minutes:* 1 + +- Left column -- \textbf{Lecture 8 (week 8, 3 lessons) -- Part III: application classes C1--C5}: challenges $\to$ profiles $\to$ what real systems chose; the rows C1--C5 of today's matrix, derived from the demand side +- Right column -- \textbf{Reading}: this week: Part IV, Sections 30--32, 34; Section 37 (introduction); ahead: Part III, Sections 18--23 +- Right column -- \textbf{Exercise / deliverable}: \textbf{A2 $+$ design-review gate: this week}; from week 8: Sprint 1 -- walking skeleton (\texttt{MarketDataService} $+$ minimal \texttt{ResearchAgent} $+$ stable API); exercise slot becomes a one-lesson standup/coaching + +*Elements:* +- two-column layout 0.55/0.42 as decks 3--6 + +*Notes:* Verbatim in substance from the task brief. + +#### Frame 30: Closing slide + +*Kind:* content -- *Source:* deck skeleton -- *Minutes:* 0 + +- \FHGRClosingPage with 'Thank you!' / Dr.\ Florian Herzog / Fachhochschule Graub\"unden, Chur / AISE502 -- AI in Software Engineering II (wrapped in \parbox, white text -- theme traps 1 and 2) + +*Elements:* +- FHGR closing page + +*Notes:* Copy from deck 6 verbatim. + +## Exercise frame: This week's exercise: the design-review gate and Deliverable A2 + +- projektbox: the design phase closes this week -- finalise the solution design +- 1. Service cut and contracts: bounded contexts $\to$ service decomposition and contracts between the deterministic core, the edges, and the AI subsystem +- 2. Walking-skeleton plan: the thin end-to-end slice built first in Sprint 1 +- 3. Measurement contract in today's vocabulary: token budget (family 2: cost budget as pipeline gate), eval threshold (pass rate on the golden set before rollout), module-boundary checks (family 1: dependency rules as CI gates, ArchUnit / import-linter style) +- 4. Design-Review Gate: defend the ADR -- which vetoes fired, which mitigations are documented, what the sensitivity check showed +- Deliverable A2 (end of week 7): architecture dossier -- ADR $+$ C4 $+$ measurement contract; production code starts only after the gate (exploratory spikes allowed) +- Below the box (\small): from week 8 the exercise slot becomes a one-lesson (one-hour) standup/coaching session, the lecture grows to three lessons; Sprint 1 walking skeleton begins + +## Summary frame + +1. Three cases, three stages: C6 -- the gate empties six of seven cells before scoring; C1 -- the veto rule decides, mitigations priced as documented engineering; C2 -- the reading flags its own instability and returns a hybrid +2. Two kinds of mitigation: an operational weakness is repaired outright (hot standby); a structural one is only made survivable under a condition most organisations do not meet (Monzo) +3. The formal statement: fit(a,p) -- ordinal, non-compensatory, three stages of decreasing hardness; the gate is read per constitutive path; a weighted sum would have destroyed exactly the three decisive facts +4. Cell semantics: a cell rates the pattern as the dominant structure of the core only; a $-$ is not a prohibition; HX reads as the internal discipline of the core +5. The grid: MM primary or secondary in seven of ten; MS premium in two situations only; PF/EDA workload-shaped; HX never negative; no row or column uniformly positive (A2) +6. Five support points: Prime Video, Segment, Shopify, Uber, Stack Overflow each sit on a cell boundary -- fit and misfit measured in money +7. Measurement contract: fitness functions (scope x cadence; dependency checks, budgets, chaos) and the four DORA metrics; the architecture may change freely as long as the contract stays green + +## Next-week frame + +**Lecture 8 (week 8, 3 lessons) -- Part III: application classes C1--C5: challenges -> profiles -> what real systems chose** + +- application classes C1--C5: challenges -> requirements profiles -> what real systems chose +- the rows C1--C5 of today's matrix, derived from the demand side + +*Reading:* +- this week: Part IV, Sections 30--32, 34; Section 37 (introduction) +- ahead: Part III, Sections 18--23 + +*Exercise / deliverable:* +- A2 (architecture dossier: ADR + C4 + measurement contract) + design-review gate: due end of this week +- week 8: Sprint 1 -- walking skeleton (MarketDataService + minimal ResearchAgent + stable API) +- from week 8 the exercise slot is a one-lesson (one-hour) standup/coaching; the lecture grows to three lessons + +## Script boxes, tables and figures used + +| Element | Script location | Used in frame | +|---|---|---| +| examplebox 'Computing the C6 row: one gate, six casualties' | §30.1, part4_fit.tex 17-22 | 5 (Stage-1 half, carried by the table rows), 6 (Stages 2-3 half) | +| Table tab:case-c6 'Case 1 -- the C6 row decided at Stage 1' | §30.1, part4_fit.tex 24-42 | 5 | +| examplebox 'Computing the cells C1/MS and C1/MM step by step' | §30.2, part4_fit.tex 50-57 | 7 (Stage 1 + Stage 2 MS), 8 (Stage 2 MM + Stage 3) | +| keypoint 'Three cases, three stages, one division of labour' | §30.3, part4_fit.tex 72-74 | 12 | +| definitionbox 'Architecture--application fit' | §31.1, part4_fit.tex 86-93 | 13 (condensed to deck-3 length; per-path clause highlighted) | +| keypoint 'The fit computation is non-compensatory by design' | §31.2, part4_fit.tex 107-109 | 15 | +| definitionbox 'Cell semantics of the matching matrix' | §32.1, part4_fit.tex 121-123 | 16 | +| sidewaystable tab:fitmatrix 'The matching matrix' incl. dagger footnote minipage | §32.2, part4_fit.tex 132-160 | 17 (full grid), 18 (dagger one-liner), 20 (five-column excerpt + never-negative sentence), 22 (C5 row) | +| keypoint 'Read a matrix cell as the answer to one question only' | §32.2, part4_fit.tex 162-164 | 18 | +| keypoint 'The modular monolith dominates the matrix as default' | §34.2, part4_fit.tex 481-483 | 22 (closing line after the discussion) | +| thinkbox 'C5 row: 3 to 30 teams / traffic x50' | §34.2, part4_fit.tex 485-487 | 22 | +| definitionbox 'Architectural fitness function' | §37.1, part4_fit.tex 663-665 | 24 | +| enumerate 'Three worked instrument families' (dependency checks, budgets, chaos) | §37.1, part4_fit.tex 669-673 | 25 (as 3-row table) | + +## Open issues for the author + +- No ailinse box exists in the assigned passages (§30-32, §34, §37 intro), so the deck has no dedicated 'AI Lens' frame -- unlike decks 3-6. The only Axis-B material is the §37.1 sentence 'token-cost budgets and p95 latency budgets per AI use case are the same mechanism with new units' (line 671); it is set in bold in frame 25 and mapped onto item 3 of the A2 measurement contract in frame 27. An AI-lens frame would need a script addition (recorded for the script maintainer), not a deck-side invention. +- §37 now spans four frames (23 intro, 24 definition, 25 instrument families, 26 DORA; 10 minutes) against the brief's '2-3 frames': the high-severity density finding on the former combined definition/families frame forced the split. Content was thinned to an introduction (tool analogues trimmed, no Depth line on the DORA frame, the deployments-per-developer finding reduced to a deck-5 pointer); the taxonomy in CI/CD, the four-layer cascade and Boehm vs Menzies remain Lecture 11. +- Frame 25: the family-2 scope/cadence cell reads '(pipeline gate)' without a scope label -- the script (line 671) classifies only family 1 ('atomic, triggered', line 670) and family 3 ('continual holistic', line 672). +- §37 opening refers to 'Step (vii)' of the eight-step decision procedure (§36, Lecture 10). Frame 23 names it as 'the seventh step of the eight-step decision procedure (Section 36, Lecture 10)' without explaining the other steps. +- The C6 profile (frame 5) and the C2 five-second delivery scenario S2 (frame 10) are Part III material (Lectures 9 and 8); both are presented as 'given here', not 'recalled'. The C1 and C2 High sets are recalled from the deck-6 mirror pair. The 'verdict the class's Part III section states' lines (frames 6, 9, 12) refer to sections students have not read yet. +- Case 2 (frame 8) states the escalation condition 'recorded in the cell rationale of Section 33' -- the rationale itself is Lecture 10 material; the deck only names the condition (D11 High and the Monzo homogeneity condition). +- Frame 11's table labels the High-set dimensions by their standard names (D1 read scalability, D3 latency, ...); the passage (line 68) gives the two rating sequences by position only, in the order D1, D3, D5, D7, D9, D11. +- Frame 8 deliberately omits MS's ratings on D5/D6/D7/D9 for C1 -- the passage states only c4(MS) = --, and -- on D8/D10 (Low); the complete MS column is available from tab:capability (deck 6) but is not in the assigned text. +- Frame 20, bullet 2: the script's sentence (line 471) says the shape gate 'caps them at o everywhere the class core is interactive', while its own table shows EDA at - for C1, C3, C4 and PF at - for C9 (harm-clause results of the same gate). The slide rewords to 'caps them at o -- or, by the harm clause, below --'; the tension in the script itself is recorded for the script maintainer. +- Frame 22 speaker notes carry an 'expected direction' for the thinkbox (D11 -> High re-runs Stage 2/3 in MS's favour; traffic x50 moves D1/D2 but MM's mitigations hold). It is inferred from §34.1/§34.2, not stated in the script; it must not migrate onto the slide. +- Frame 13 labels the per-constitutive-path clause 'not shown in deck 3' -- a deck-level highlight; the script (line 89) presents it as part of the definition, not as new. +- Frame 27 item 1 adds 'and the AI subsystem' to the M2 taskbox wording ('Bounded contexts -> service decomposition and contracts', lines 408-410); consistent with the deck-6 projektbox, not in the taskbox. 'One-lesson (one-hour)' matches both the semester plan's 3+1 and the exercise sheet's 'one-hour standup/coaching session' (line 361). +- tab:fitmatrix is a sidewaystable in the script; on the slide it is an upright scriptsize table (p{4.2cm} class column + 7 centred columns), the same format deck 6 used for the consolidated capability table -- verify visually after the build. +- Deck 6's 'Next week' frame announced reading 'Part IV, sections 1--3' while the title-slide line here is 'Part IV, Sections 30--32, 34; Section 37 (introduction)' -- section numbering follows the script's global numbering; the deck uses the title-slide line. +- Minutes: content frames 4-26 sum to 70; with agenda (1), recap (3), exercise (3), summary (2), next week (1) the deck plans 80 of 90 minutes -- 10 minutes slack for the silent matrix minute and a discussion that overruns. If time is short, frame 20's excerpt table can be skipped verbally (the bullets carry the claims). +- Residual density risks (all fallbacks recorded in the notes): frame 7 has 8 bullets (merged Stage 1 + Stage 2 for MS) -- keep bullets 3, 7, 8 to one line; frame 13 may still need a '(1/2)/(2/2)' split if the deck-3 box length is exceeded. + +--- + +# Lecture 8: Requirements Profiles I -- Application Classes C1--C5 + +- **Week:** 8 -- **Lessons:** 3 -- **Frames:** 44 +- **Title-slide script line:** Script: Part III, Sections 18--23 + +## Agenda + +1. Application classes as requirements profiles -- method recall (weights, shape, constraints); the map of ten classes +2. \textbf{C1} -- Core banking / transaction systems: the double impossibility +3. \textbf{C2} -- Social media / content platforms: 50:1 and the fan-out +4. \textbf{C3} -- Back-office / workflow: the modal, unglamorous case +5. \textbf{C4} -- ERP / enterprise core: integration \emph{is} the product +6. \textbf{C5} -- E-commerce: quality attributes with price tags +7. Five classes side by side -- five verdicts as previews for Part IV +8. This week's exercise: \textbf{the walking skeleton} (M3) + +## Recap: where we are + +- Lecture 6 closed Part II: the consolidated capability table, Maxims 3 and 4 (quantum count; partitioning beats distribution), ordinal reading only -- every cell a default hypothesis +- Lecture 6 also opened Part III with \textbf{C10}, the class of your project: Highs on D6/D7/D9/D10/D12, the binding scenarios, the verdict (hexagonal modular monolith + PF + EDA) -- and the C1/C2 mirror pair in one frame: \emph{weights, not dimensions, define a class} +- Lecture 7 (Part IV): three cases, three stages; the procedure in general; reading the $7 \times 10$ matrix; the measurement contract introduced -- A2 architecture dossier and the design-review gate: implementation is free +- Method recall from Lectures 2--3: $R(a) = (w_1 \ldots w_{12};\, S(a);\, K(a))$ -- weights from the (H,\,H) leaves of the utility tree, shape as a gate, constraints as knock-outs; every High is a veto trigger with the cap rule of the three-stage procedure +- Today: back to the demand side, properly -- Part III in its class rhythm for C1--C5: \emph{challenges $\to$ binding scenarios $\to$ profile $\to$ what real systems chose}; every closing verdict is a preview that Part IV recomputes +- Project: the design phase is over -- the implementation phase opens with milestone M3, the walking skeleton (weeks 8--9; numbering as in the taskboxes of the exercise sheet) + +## Frame overview + +| # | Section | Frame title | Kind | Script ref | Min | +|---|---|---|---|---|---| +| 1 | Title | AISE502: AI in Software Engineering II -- Lecture 8: Requirements Profiles I -- Application Classes C1--C5 | content | Title slide; Script: Part III, Sections 18--23 | 0 | +| 2 | Agenda | Agenda | agenda | Deck skeleton (decks 1-6) | 1 | +| 3 | Recap | Recap: where we are | recap | Deck 6 summary and 'Next week' frame (AISE502_Vorlesung_6_Folien.tex 660-698); semester plan rows 6-8; deck 2 frames 691-780 (R(a) method); deck 3 line 389 (veto caps); project_exercise.tex 355-363 (two phases) and taskbox M3 (416-422) | 3 | +| 4 | Application Classes as Requirements Profiles | Part III: the demand side, in the same vocabulary | definition | §18 opening (part3_application_classes.tex 12-27) and §18.4 rhythm sentence (line 112) | 3 | +| 5 | Application Classes as Requirements Profiles | Method recall: where the weights come from (Lectures 2--3) | content | §18.1 (part3_application_classes.tex 29-41); recall of deck 2 frame 'From leaves to weights' (692-702) and deck 3 definitionbox fit(a,p) stage 2 (389) | 3 | +| 6 | Application Classes as Requirements Profiles | Workload shape and hard constraints | keyconcept | §18.2 (part3_application_classes.tex 43-52); recall of deck 2 frame 'The last two components: shape and constraints' (735-752) | 2 | +| 7 | Application Classes as Requirements Profiles | A map of the ten classes | diagram | §18.3 (part3_application_classes.tex 54-108) | 3 | +| 8 | Application Classes as Requirements Profiles | Discussion: classification is a hypothesis -- test it on three systems | discussion | §18.4 hinweisbox and thinkbox (part3_application_classes.tex 113-119) | 3 | +| 9 | C1 -- Core Banking | Part III in the class rhythm: C1 -- Core banking / transaction systems | content | §19 opening (part3_application_classes.tex 125-128) | 3 | +| 10 | C1 -- Core Banking | C1 -- the challenges in numbers | content | §19.1 (part3_application_classes.tex 130-136) | 3 | +| 11 | C1 -- Core Banking | C1 -- the binding scenarios and the knock-outs | content | §19.1 scenarios and K (part3_application_classes.tex 138-146) | 4 | +| 12 | C1 -- Core Banking | C1 -- requirements profile (column C1) | table | §19.2 tab:req-c1 (part3_application_classes.tex 148-178) | 4 | +| 13 | C1 -- Core Banking | C1 -- what real systems chose, and why | case | §19.3 text and keypoint (part3_application_classes.tex 180-184, 190-192); deck 4 line 534 (Fineract study) | 3 | +| 14 | C1 -- Core Banking | C1 -- AI lens and the verdict | ailens | §19.3 ailinse and closing sentence (part3_application_classes.tex 194-198) | 3 | +| 15 | C2 -- Social Media / Content Platforms | C2 -- Social media / content platforms | content | §20 opening (part3_application_classes.tex 203-206) | 3 | +| 16 | C2 -- Social Media / Content Platforms | C2 -- the challenges: the ratio, the pace, the spikes | content | §20.1 (part3_application_classes.tex 208-212) | 4 | +| 17 | C2 -- Social Media / Content Platforms | C2 -- binding scenarios and a light $K$ | content | §20.1 scenarios and K (part3_application_classes.tex 214-222) | 3 | +| 18 | C2 -- Social Media / Content Platforms | C2 -- requirements profile (column C2) | table | §20.2 tab:req-c2 (part3_application_classes.tex 224-254) | 3 | +| 19 | C2 -- Social Media / Content Platforms | C2 -- what real systems chose, and why | case | §20.3 (part3_application_classes.tex 256-260) | 3 | +| 20 | C2 -- Social Media / Content Platforms | C2 -- AI lens and the verdict | ailens | §20.3 keypoint, ailinse, closing sentence (part3_application_classes.tex 262-270) | 3 | +| 21 | C3 -- Back-Office / Workflow | C3 -- Back-office / workflow applications | content | §21 opening (part3_application_classes.tex 275-277) | 3 | +| 22 | C3 -- Back-Office / Workflow | C3 -- the challenges: reorganisation, budget, witnesses | content | §21.1 (part3_application_classes.tex 279-286) | 3 | +| 23 | C3 -- Back-Office / Workflow | C3 -- binding scenarios and the knock-outs | content | §21.1 scenarios and K (part3_application_classes.tex 288-294) | 3 | +| 24 | C3 -- Back-Office / Workflow | C3 -- requirements profile (column C3) | table | §21.2 tab:req-c3 (part3_application_classes.tex 296-326) | 3 | +| 25 | C3 -- Back-Office / Workflow | C3 -- what real systems chose, and why | case | §21.3 (part3_application_classes.tex 328-332) | 3 | +| 26 | C3 -- Back-Office / Workflow | C3 -- why this class punishes distribution | keyconcept | §21.3 examplebox and keypoint (part3_application_classes.tex 334-340); recall of deck 3 mini-match variant (AISE502_Vorlesung_3_Folien.tex 462-467) | 3 | +| 27 | C3 -- Back-Office / Workflow | C3 -- AI lens and the verdict | ailens | §21.3 ailinse and closing sentence (part3_application_classes.tex 342-346) | 3 | +| 28 | C4 -- ERP / Enterprise Core | C4 -- ERP / enterprise core systems | content | §22 opening (part3_application_classes.tex 351-354) | 3 | +| 29 | C4 -- ERP / Enterprise Core | C4 -- the challenges: atomicity, thirty years, the batch window | content | §22.1 (part3_application_classes.tex 356-362) | 4 | +| 30 | C4 -- ERP / Enterprise Core | C4 -- binding scenarios and the knock-outs | content | §22.1 scenarios and K (part3_application_classes.tex 364-370) | 3 | +| 31 | C4 -- ERP / Enterprise Core | C4 -- requirements profile (column C4) | table | §22.2 tab:req-c4 (part3_application_classes.tex 372-402) | 3 | +| 32 | C4 -- ERP / Enterprise Core | C4 -- what real systems chose, and why | case | §22.3 (part3_application_classes.tex 406-408) | 3 | +| 33 | C4 -- ERP / Enterprise Core | C4 -- key concept, verdict and Discussion: what exactly ossified? | discussion | §22.3 keypoint, thinkbox and closing sentence (part3_application_classes.tex 410-418) | 3 | +| 34 | C5 -- E-Commerce | C5 -- E-commerce platforms | content | §23 opening (part3_application_classes.tex 423-426) | 3 | +| 35 | C5 -- E-Commerce | C5 -- the challenges: price tags, Black Friday, two kinds of truth | content | §23.1 (part3_application_classes.tex 428-432); numbers first shown in deck 2 (211, 227) | 4 | +| 36 | C5 -- E-Commerce | C5 -- binding scenarios and the PCI knock-out | content | §23.1 scenarios and K (part3_application_classes.tex 434-440) | 3 | +| 37 | C5 -- E-Commerce | C5 -- requirements profile (column C5: seven Highs) | table | §23.2 tab:req-c5 (part3_application_classes.tex 442-472) | 3 | +| 38 | C5 -- E-Commerce | C5 -- what real systems chose, and why | case | §23.3 (part3_application_classes.tex 476-478); recall of deck 4 examplebox 'Shopify -- the canonical modular monolith' (431-432) | 3 | +| 39 | C5 -- E-Commerce | C5 -- hybrid consistency as a designed boundary | keyconcept | §23.3 examplebox, keypoint and closing sentence (part3_application_classes.tex 480-488) | 4 | +| 40 | Five Classes Side by Side | Five classes side by side -- assembled from today's five tables | table | Assembled from tab:req-c1..c5 (part3_application_classes.tex 152-178, 228-254, 300-326, 376-402, 446-472: the Weight and Shape rows already shown on frames 12, 18, 24, 31, 37); verdict codes from the closing sentences lines 198, 270, 346, 418, 488. Nothing from the consolidated table of Lecture 9 | 2 | +| 41 | Closing | This week's exercise: the walking skeleton | exercise | project_exercise.tex 355-363 (two phases), week-table rows 8-9 (376-377), taskbox M3 (416-422) and hintbox (451-464); milestone numbering M1-M6 from the taskboxes 391-448; semester plan row 8 | 3 | +| 42 | Closing | Summary | summary | §18-§23 keypoints | 2 | +| 43 | Closing | Next week | nextweek | Semester plan row 9; task brief 'Next lecture'; §29.1 opening sentence (part3_application_classes.tex 917-920); projektboxes §24.3 (558-560) and §25.3 (632-634) | 1 | +| 44 | Closing | Closing slide | content | \FHGRClosingPage (deck 6 lines 703-706) | 0 | + +## Frames in detail + +### Section: Title + +#### Frame 1: AISE502: AI in Software Engineering II -- Lecture 8: Requirements Profiles I -- Application Classes C1--C5 + +*Kind:* content -- *Source:* Title slide; Script: Part III, Sections 18--23 -- *Minutes:* 0 + +- \FHGRTitlePage with subtitle 'Lecture 8: Requirements Profiles I -- Application Classes C1--C5' and script line 'Script: Part III, Sections 18--23' + +*Elements:* +- \FHGRTitlePage (theme) + +*Notes:* Same metadata block as deck 6; only \subtitle changes. + +### Section: Agenda + +#### Frame 2: Agenda + +*Kind:* agenda -- *Source:* Deck skeleton (decks 1-6) -- *Minutes:* 1 + +- 1. Application classes as requirements profiles -- method recall (weights, shape, constraints); the map of ten classes +- 2. C1 -- Core banking / transaction systems +- 3. C2 -- Social media / content platforms +- 4. C3 -- Back-office / workflow applications +- 5. C4 -- ERP / enterprise core systems +- 6. C5 -- E-commerce platforms +- 7. Five classes side by side -- five verdicts as previews for Part IV +- 8. This week's exercise: the walking skeleton (M3) + +*Elements:* +- enumerate, \small, itemsep 1pt (deck-6 style) + +*Notes:* Point out the rhythm once: every class = intro -> challenges -> scenarios and K -> profile -> real systems -> lens/key concept. The rhythm strip itself sits on frame 4. + +### Section: Recap + +#### Frame 3: Recap: where we are + +*Kind:* recap -- *Source:* Deck 6 summary and 'Next week' frame (AISE502_Vorlesung_6_Folien.tex 660-698); semester plan rows 6-8; deck 2 frames 691-780 (R(a) method); deck 3 line 389 (veto caps); project_exercise.tex 355-363 (two phases) and taskbox M3 (416-422) -- *Minutes:* 3 + +- Lecture 6 closed Part II: consolidated capability table, Maxims 3 and 4 (quantum count; partitioning beats distribution), ordinal reading only -- every cell a default hypothesis +- Lecture 6 opened Part III with C10: Highs on D6/D7/D9/D10/D12, binding scenarios, verdict hexagonal MM + PF + EDA -- and the C1/C2 mirror pair in one frame: \emph{weights, not dimensions, define a class} +- Lecture 7 (Part IV): three cases, three stages; the procedure in general; reading the $7 \times 10$ matrix; the measurement contract introduced -- A2 dossier and design-review gate passed: implementation is free +- Method recall (Lectures 2--3): $R(a) = (w_1 \ldots w_{12};\, S(a);\, K(a))$ -- weights from the (H,\,H) leaves; shape gates; constraints knock out; every High is a veto trigger with the cap rule +- Today: the demand side in its full class rhythm for C1--C5 -- \emph{challenges $\to$ binding scenarios $\to$ profile $\to$ what real systems chose}; each verdict a preview that Part IV recomputes +- Project: design phase over -- the implementation phase opens with M3, the walking skeleton (weeks 8--9) + +*Elements:* +- bullet list, \footnotesize + +*Notes:* No deck 7 file exists yet; the Lecture-7 bullet is taken from the semester plan row 7 and the deck-6 'Next week' frame -- adjust wording once deck 7 is typeset. + +### Section: Application Classes as Requirements Profiles + +#### Frame 4: Part III: the demand side, in the same vocabulary + +*Kind:* definition -- *Source:* §18 opening (part3_application_classes.tex 12-27) and §18.4 rhythm sentence (line 112) -- *Minutes:* 3 + +- \emph{Part II priced the supply side: seven patterns, each a capability profile $C(p)$ over the twelve dimensions. Part III characterises the demand side -- and A2 and A3 require it in the \textbf{same} vocabulary at the \textbf{same} resolution.} +- 'We are building a banking system' carries almost no architectural information; 'an instant payment must reach confirmed finality in under ten seconds end-to-end, with zero transaction loss, under a regulator-enforced audit obligation' carries almost all of it -- the unit that packages such statements is the \textbf{application class} +- [body of the definitionbox] Definition (application class): a recurring bundle of architecturally significant requirements (ASRs) -- a set of dominant quality attribute scenarios with \emph{typical response measures}, a characteristic \emph{workload shape} with its quantitative signature, and a \emph{regulatory frame} acting as hard constraints +- [body of the definitionbox, display math] $R(a) = \bigl(w_1(a), \ldots, w_{12}(a);\; S(a);\; K(a)\bigr)$ with $w_i(a) \in \{\text{H}, \text{M}, \text{L}\}$, $S(a)$ the dominant workload shape, $K(a)$ the set of hard constraints +- [one-line rhythm strip] Ten sections, one rhythm -- Part II turned around: \textbf{leading question} $\to$ \textbf{the challenges it brings} $\to$ \textbf{the requirements profile} $\to$ \textbf{what real systems chose, and why}; challenges first, weights after, structures last -- every closing recommendation is a \emph{preview} that Part IV recomputes + +*Elements:* +- definitionbox[Application class] from lines 18-25 -- bullets 3-4 are its body, the formula in display math inside the box +- one-line horizontal tikz strip of four rounded boxes (question -> challenges -> profile -> real systems) from §18.4 line 112, replacing the former 'How to read the class sections' frame + +*Notes:* The frame carries only: the leading italic sentence in bankblue, the two 'banking' quotations, the definition box (\footnotesize) and the one-line rhythm strip -- nothing else. Bridge spoken from line 27: 'two pieces of method recall before the catalogue, because every class section uses them' -> frames 5-6. + +#### Frame 5: Method recall: where the weights come from (Lectures 2--3) + +*Kind:* content -- *Source:* §18.1 (part3_application_classes.tex 29-41); recall of deck 2 frame 'From leaves to weights' (692-702) and deck 3 definitionbox fit(a,p) stage 2 (389) -- *Minutes:* 3 + +- (Lecture 2) A4 recalled: a quality attribute is decision-relevant only as a six-part scenario; ASRs are elicited, not guessed (QAW, ATAM utility tree), each leaf rated (business importance, achievement difficulty) on \{H, M, L\} +- (Lecture 2) \textbf{The (H,\,H) leaves of a class's characteristic utility tree \emph{are} the High weights of $R(a)$} +- New in Part III: a weight is a \textbf{compressed empirical claim} -- 'systems of this class recurrently produce (H,\,H) scenario leaves on this dimension' -- and each class section makes it \textbf{auditable}: documented challenges (incidents, production numbers, statutory obligations) $\to$ two to three \emph{binding scenarios} with response measures, populating the (H,\,H) region +- (Lecture 3) \textbf{H} -- veto power: $--$ on an H dimension caps the fit at $-$, $-$ caps at $\circ$, unless a documented mitigation with production evidence; \textbf{M} -- measured, conflicts noted not vetoed, clustered Medium conflicts downgrade one step; \textbf{L} -- does not discriminate for this class; optimising it is waste +- Important Note: there is no weighted sum -- profiles are ordinal, aggregation non-compensatory. \textbf{An H weight is a veto trigger, not a coefficient.} Ten excellent Mediums cannot buy back one violated High + +*Elements:* +- hinweisbox from lines 39-41 (condensed; the ledger simile is dropped here -- it returns on frames 10-11) + +*Notes:* §18.1 is labelled 'method recall' by the script itself (line 27). Bullets 1, 2 and 4 are tagged as recall and kept to one line each; the genuinely new payload is bullet 3 (lines 33-35) and the box. Body \footnotesize. + +#### Frame 6: Workload shape and hard constraints + +*Kind:* keyconcept -- *Source:* §18.2 (part3_application_classes.tex 43-52); recall of deck 2 frame 'The last two components: shape and constraints' (735-752) -- *Minutes:* 2 + +- (recall, Lecture 2) $S(a)$ -- interactive, continuous stream, scheduled batch, explicitly hybrid; the \emph{shape gate}: a pattern whose native shape does not match the dominant $S(a)$ cannot carry the class's core; every shape has a quantitative signature reported with production numbers -- \emph{a workload claim without a number is as unfalsifiable as a scalability requirement without one} +- (recall, Lecture 2) $K(a)$ -- \textbf{knock-out filters, not weights}: a violating pattern or deployment form is excluded before any scoring and can never be averaged away +- The regulatory inventory of this catalogue: BCBS 239, FINMA Circular 2023/1, DORA, PCI DSS v4.0, the EU AI Act -- plus organisational facts (team size and skills, mandated platforms, budget) +- Regulation is a first-class architectural requirement that \textbf{translates directly into structure}: immutable journals, scope zoning, data classification at module boundaries, logging obligations for AI components +- Key Concept: an application class is an ASR bundle, not an industry label -- weights from the (H,\,H) leaves, shape gates the core, constraints knock out before scoring. One organisation operates \emph{several} classes at once -- a bank runs a C1 booking core, C3 back-office workflows, C6 overnight risk runs, C7 reporting and increasingly a C10 advisory layer -- so the fit matrix is read \textbf{per subsystem, never per company logo}: your project's inheritance diagram (Lecture 6: C10 inherits C6/C7/C3) is exactly that reading + +*Elements:* +- keypoint from lines 50-52 (condensed; last clause recalls the deck-6 inheritance diagram) + +*Notes:* Bullets 1-2 are marked recall; new for this lecture are the regulatory inventory, 'regulation translates into structure' (lines 46-48) and the keypoint. The bank-with-five-classes sentence recalls the inheritance diagram of deck 6 (frame 'C10 -- your project as an inheritance diagram'), it does not prepare it. + +#### Frame 7: A map of the ten classes + +*Kind:* diagram -- *Source:* §18.3 (part3_application_classes.tex 54-108) -- *Minutes:* 3 + +- C1 and C2 at opposite ends of the consistency axis within the same band -- the didactic \textbf{mirror pair}; C10 the only class whose \emph{shape} is constitutively hybrid +- Today's five all sit in the interactive band -- read them along the axis: C1/C4 strict ACID, C3 ACID-leaning, C5 split by subsystem, C2 eventual + +*Elements:* +- tikz fig:classmap, lines 58-108 -- redraw at \resizebox{0.85\textwidth} with rounded rectangles; colours inter=bankblue, stream=bankgreen, batch=gray, hybrid=bankblue!70!black (script's projteal is not defined in the deck preamble -- define or alias it); highlight today's five nodes with a thicker frame; two \footnotesize lines beneath the figure + +*Notes:* Only the two bullets go on the slide; the rest is spoken from these notes: (i) two variables discriminate more than any others -- dominant workload shape (bands) and consistency semantics the core requires (axis); (ii) the axis is ordinal, not metric: strict ACID -> hybrid split by subsystem -> causal / per-key / by contract -> eventual; (iii) interactive band: C1 ACID ledger, C4 + batch runs, C3, C5 checkout ACID / catalogue eventual, C9 connection-stateful causal per channel, C2 stale feed acceptable; (iv) stream band C8 (event time, exactly-once state); batch band C6 (reproducible, seeds) and C7 (fresh by refresh contract); hybrid band C10 (index eventual, audit path ACID); (v) C6 reproducibility and C7 freshness by refresh contract are a third family of semantics, neither ACID nor eventual -- Lecture 9. On the map C3 sits between the ACID tick and the hybrid tick without a sub-label, hence 'ACID-leaning'; the C4 keypoint (frame 33) makes the ACID claim explicit. Verify with pdftoppm that the axis labels do not collide. + +#### Frame 8: Discussion: classification is a hypothesis -- test it on three systems + +*Kind:* discussion -- *Source:* §18.4 hinweisbox and thinkbox (part3_application_classes.tex 113-119) -- *Minutes:* 3 + +- Important Note: classifying a concrete system as an instance of a class is step (i) of the decision procedure -- a \emph{hypothesis about the system's ASR bundle}, to be inherited and then corrected against elicited scenarios, never a verdict. Real systems blend classes; \textbf{the blend, not the label}, is what the utility tree must capture +- Take three software systems you have used this week -- your e-banking app, a messaging tool, a streaming service +- Which application classes do they instantiate? +- Which single quality attribute scenario, with which response measure, would you nominate as each system's most binding requirement? +- Where would a failure of that scenario become visible first: in revenue, in a regulator's report, or in user churn? + +*Elements:* +- hinweisbox from lines 113-115 (condensed) as the lead-in at the top of the frame +- thinkbox from lines 117-119 with the three questions + +*Notes:* 3 minutes of pair talk; collect two answers, place them on the map of frame 7 (go back one frame) -- and point out where an answer is a blend rather than a label. + +### Section: C1 -- Core Banking + +#### Frame 9: Part III in the class rhythm: C1 -- Core banking / transaction systems + +*Kind:* content -- *Source:* §19 opening (part3_application_classes.tex 125-128) -- *Minutes:* 3 + +- \emph{A payment is booked twice, or not at all: which of the two can a bank survive?} Neither -- and that double impossibility is the class in one sentence +- Systems of record for accounts, payments and positions: the booking core of a bank, a payment-clearing platform, an exchange's matching and settlement layer -- the machinery behind your e-banking balance, the card authorisation at the till, the salary on the 25th +- Defining property: a lost or double-posted booking event is an \textbf{existential} defect -- it creates or destroys money -- whereas unavailability is expensive but reversible +- Double-entry bookkeeping demands atomic, serialisable transactions over the ledger: classical ACID territory. Auditability is a regulator-enforced obligation: every state change journaled and reconstructable -- which is why event-sourced journals and ledger data models fit naturally +- Three challenges define the class: (1) \textbf{the sums at stake} (D4, D6); (2) \textbf{a speed spread of six orders of magnitude} within one class (D3, D2, D5); (3) \textbf{time} -- lifetimes measured in decades (D7) + +*Elements:* +- italic leading question in bankblue (deck 4-6 style); numbered challenge list + +*Notes:* Reference the deck-6 mirror-pair frame in one spoken sentence ('you saw the headline; now the derivation'). Do not repeat its bullets. + +#### Frame 10: C1 -- the challenges in numbers + +*Kind:* content -- *Source:* §19.1 (part3_application_classes.tex 130-136) -- *Minutes:* 3 + +- \textbf{Sums.} Swiss Interbank Clearing settles on average roughly CHF 226 billion per day, peaks above CHF 386 billion -- a double-posted or lost booking is a balance-sheet event: D4 and D6 before any other consideration. Every payment is a write surrounded by reads (cover checks, sanctions screening, fraud scoring): \emph{write-critical} -- but the \emph{concurrency} of writes against shared accounts, not their raw rate, stresses D4 +- \textbf{Speed spread.} Batch clearing hours; instant payments under 10 s; card authorisation 1--2 s; exchange trading microseconds -- latency means something different in each regime, hence D3 \textbf{Medium with a footnote}, not High +- SIC5 instant-payment infrastructure: dimensioned for peaks in the order of 2,000 payments/s, clustered in-memory replicated-state-machine design. VisaNet: \emph{capacity} above 65,000 transaction messages/s while average load lies orders of magnitude below -- capacity dimensioning vs.\ normal load, the reason D2 is \emph{planned, not elastic} +- Load constant with deterministic peaks (end of day, end of month, salary runs); unavailability is a loss event on national infrastructure with regulator-defined disruption tolerances -- D5 +- \textbf{Time.} Reuters 2017: 220 billion lines of COBOL in production, 43\,\% of US banking systems COBOL-based -- ossification is the documented failure mode, which makes D7 a High \emph{requirement} precisely because it is so often unmet. Change rate bimodal: booking core rarely, periphery (channels, onboarding, products) constantly. Data structured, records small, retention extreme -- ten years and more + +*Elements:* +- \footnotesize bullets, bold challenge labels; numbers in text; target 13-14 lines + +*Notes:* The SWIFT/ISO 20022 evidence is spoken from here, not typeset: 'SWIFT carried over one million ISO 20022 messages per day by the end of 2024, with the MT/MX coexistence phase ending in November 2025 -- a multi-year, industry-wide coordinated interface migration, again a D7 stress' (script line 134, written before the cut-over; by the lecture date the phase has ended). The former SIC5/VisaNet bullet is split into its two claims (capacity vs. load; load pattern and D5) to keep every bullet at three lines or fewer. + +#### Frame 11: C1 -- the binding scenarios and the knock-outs + +*Kind:* content -- *Source:* §19.1 scenarios and K (part3_application_classes.tex 138-146) -- *Minutes:* 4 + +- Three scenarios compress these challenges into the (H,\,H) region of the C1 utility tree -- \textbf{Assumption A4 in action}; every High in the next table traces to one of them +- \textbf{S1 (instant payment finality).} A customer submits an instant payment (stimulus) in normal operation to the payment core; it clears, settles and posts with confirmed finality \textbf{in under 10 seconds end-to-end, with zero transaction loss} -- the SIC5 operating regime. D3, D4, D5 +- \textbf{S2 (ledger integrity under concurrency).} Concurrent postings against the same account at peak load leave the double-entry invariant intact: \textbf{zero invariant violations, verified by a daily reconciliation job with zero unexplained discrepancies}. The D4 veto scenario -- and, through the reconciliation job, D9 +- \textbf{S3 (audit-trail reconstruction).} An auditor requests the complete causal history of one transaction chosen at random, up to ten years back; the full trail is reproduced \textbf{within one working day, from immutable records} -- BCBS 239's aggregation and reporting principles read operationally. D6, D9 +- $K(\text{C1})$ -- the densest constraint set in the catalogue: BCBS 239 (demonstrable risk-data aggregation and reporting: integration and lineage); FINMA Circular 2023/1 (in force 1 January 2024: ICT risk, protection of \emph{critical data}, business continuity with disruption tolerances); DORA (EU 2022/2554, applicable 17 January 2025: ICT risk, incident reporting, resilience testing, third-party register); GDPR throughout +- \textbf{Knock-out reading:} any structure that cannot guarantee an ACID booking core, an immutable and complete audit journal, and ten-plus-year retention is eliminated \emph{before} any fit scoring -- however well it scales + +*Elements:* +- one-line lead sentence (line 138); three scenario bullets in deck-6 'binding scenarios' style with (D\_i) tag in codegray; K paragraph as bold-led text + +*Notes:* Same layout as deck 6 'C10 -- the binding scenarios'. Response measures in bold. The lead line closes the chain from frame 5 (challenges -> (H,H) leaves -> High weights); it is repeated as a short tag on frames 17, 23, 30 and 36. Here the ledger simile of the §18.1 box is spoken ('no feature velocity buys back a double-posted booking'). If overfull, shorten the parentheticals of the K bullet, not the scenarios. + +#### Frame 12: C1 -- requirements profile (column C1) + +*Kind:* table -- *Source:* §19.2 tab:req-c1 (part3_application_classes.tex 148-178) -- *Minutes:* 4 + +- D1 Read scalability -- M -- reads surround every posting; volumes modest +- D2 Write scal.\ \& elasticity -- M -- constant load, deterministic peaks; capacity planned, not elastic +- D3 Latency -- M -- spread of orders of magnitude: microseconds to hours +- D4 Consistency \& integrity -- \textbf{H} -- a lost or double-posted booking creates or destroys money +- D5 Availability \& isolation -- \textbf{H} -- payment rails are national infrastructure; outages are loss events +- D6 Security \& auditability -- \textbf{H} -- the immutable audit journal is a statutory obligation +- D7 Evolvability -- \textbf{H} -- decades-long lifetimes; ossification is the failure mode +- D8 Simplicity \& TTM -- L -- time-to-market traded for integrity without hesitation +- D9 Testability \& deployability -- \textbf{H} -- reconciliation and trail reconstruction verifiable by construction +- D10 Operating cost -- L -- run cost traded for integrity as willingly as D8 +- D11 Team scaling -- M -- binds only at neobank organisational scale -- the Monzo condition +- D12 AI integrability -- M -- fraud scoring at the edge; the booking path stays deterministic +- Shape $S(a)$: interactive (+ batch edges). Constraints $K(a)$: BCBS 239; FINMA 2023/1; DORA; ACID core; 10+ yr retention + +*Elements:* +- 12-row requirements-profile table (scriptsize, arraystretch 0.8, p{3.0cm}cp{7.7cm}, \vspace{-0.35cm}) from tab:req-c1 lines 152-178, plus Shape and Constraints rows; Highs bold; every 'Why' cell at most ~65 characters, one line, no parentheticals, no inline footnotes + +*Notes:* Five Highs: D4/D5/D6/D7/D9. Weights, Shape and Constraints cell-identical with the script; 'Why' cells are one-line condensations of lines 162-173 (row label 'D5 Availability \& isolation' follows the deck-6 convention, script says 'fault isolation'). Spoken from the notes, not typeset: note 3 (batch clearing hours, instant payments <10 s, card authorisation 1-2 s, trading microseconds); D1's read list (cover checks, sanctions, fraud scoring) was on frame 10; D6's statute list is on frame 11. Point at the two Lows: this class pays with D8 and D10. + +#### Frame 13: C1 -- what real systems chose, and why + +*Kind:* case -- *Source:* §19.3 text and keypoint (part3_application_classes.tex 180-184, 190-192); deck 4 line 534 (Fineract study) -- *Minutes:* 3 + +- Two documented production systems show this profile does \emph{not} determine a single pattern +- \textbf{LMAX} (retail trading): six million orders/s on a \emph{single} JVM thread -- in-memory, event-sourced, deterministic sequential core with lock-free ring buffers. Serialisable \emph{by construction} (the strongest answer to the D4 veto); deterministic replay of the journal answers D6 and D9 at once; surrenders elastic write scaling (D2) -- weighted only Medium +- \textbf{Monzo} (UK digital bank): ca.\ 2,800 Go microservices (ca.\ 1,600 in 2020), viable only through extreme homogeneity -- one language, one monorepo, central migration automation. Binding dimension D11, where the MS column excels; the $--$ on simplicity and cost paid deliberately; the D4 risk of sagas in the money path mitigated by homogeneity and central tooling +- \textbf{Apache Fineract} -- the 34-module single deployable you inspected in week 4, now read from the demand side: a modular monolith behind a REST facade -- one ACID quantum serves the D4 veto; domain modules absorb the peripheral change rate (D7); the weak cell, $-$ on D5 (one process as blast radius), mitigated by hot-standby replication. A standing counter-example to 'banking at scale implies microservices' +- Key Concept: $R(a)$ alone does not force one pattern; it defines the feasible set, and constraints decide within it. C1's veto dimensions -- D4, D5, D6, D7, D9 -- eliminate structures that cannot carry an ACID, journaled, decades-lived core; they do \emph{not} rank the survivors. The LMAX/Monzo pair is evidence \textbf{for} the theory, not against it + +*Elements:* +- \footnotesize bullets; system names bold +- keypoint from lines 190-192 (condensed) as the closing box + +*Notes:* The examplebox 'LMAX versus Monzo' (lines 186-188) was shown in Lecture 3 (deck 3 407-408) and in the deck-6 mirror-pair frame -- one spoken sentence only: 'same profile, opposite structures -- LMAX's binding scenario microsecond-scale deterministic ordering, Monzo's binding constraint scaling hundreds of engineers safely; A2 resolved twice, in opposite directions, within one feasible set'. Fineract: students read its code in week 4 (34 fineract-* Gradle modules, custom/ extension directory) -- ask them where the hot-standby mitigation sits. Density: four bullets plus box at \footnotesize; the 'both banking-grade with opposite structures' sentence is spoken, not typeset. + +#### Frame 14: C1 -- AI lens and the verdict + +*Kind:* ailens -- *Source:* §19.3 ailinse and closing sentence (part3_application_classes.tex 194-198) -- *Minutes:* 3 + +- AI Lens (Fraud scoring at the edge of the ledger, Axis B): AI enters C1 at the periphery, never in the booking path -- fraud and sanctions scoring are ML classification components (millisecond latency, deterministic after training) consulted \emph{before} a posting is committed; increasingly LLM-based components for case triage and customer communication +- D12 is Medium precisely because of this placement: the deterministic core must be isolatable from the probabilistic edge -- a ports-and-adapters discipline. A fraud model that could abort or mutate a posting mid-transaction would violate the D4 veto. \textbf{The rule 'agents propose, deterministic services decide and book' originates in this class} +- Where the winning structures' weak cells bite, practice \emph{places} patterns rather than replacing them: the immutable event journal -- EDA's natural artefact -- serves as the regulatory audit trail at the core's edges; end-of-day clearing, statements and risk runs are genuine PF batch runs beside the interactive core +- \textbf{Verdict (preview):} primary -- a hexagonal modular monolith for the booking core (MM and HX at $++$); secondary -- EDA at the edges, PF for the batch runs; microservices only when organisation size forces D11 to High, the Monzo condition. Part IV computes this through the three-stage procedure + +*Elements:* +- ailinse[Fraud scoring at the edge of the ledger (Axis B)] from lines 194-196 (condensed) +- verdict as bold-led closing paragraph (deck-6 style) + +*Notes:* Link to the project hint 'keep the deterministic core free of LLM calls -- this is the line that is graded'. + +### Section: C2 -- Social Media / Content Platforms + +#### Frame 15: C2 -- Social media / content platforms + +*Kind:* content -- *Source:* §20 opening (part3_application_classes.tex 203-206) -- *Minutes:* 3 + +- \emph{Three hundred thousand people refresh their feed every second while six thousand post: what structure serves the ratio?} +- Consumer platforms whose product is a continuously updated content feed: social networks, media-sharing platforms, content communities -- the apps that fill the tram ride +- Defining property: the exact inversion of C1 -- a feed that is a few seconds \emph{stale} is acceptable; a feed that does not \emph{load} is not +- Consistency is explicitly negotiable -- eventual consistency is a design choice, not a defect -- while read scalability, availability and feed latency carry the binding scenarios +- Three challenges: (1) \textbf{the 50:1 ratio and the fan-out amplification} (D1, D2); (2) \textbf{the pace of the product} (D7, D9, D11); (3) \textbf{spiky, viral load} (D5, D3) + +*Elements:* +- italic leading question in bankblue; numbered challenge list + +*Notes:* Light frame; the numbers come on the next one. + +#### Frame 16: C2 -- the challenges: the ratio, the pace, the spikes + +*Kind:* content -- *Source:* §20.1 (part3_application_classes.tex 208-212) -- *Minutes:* 4 + +- \textbf{The ratio.} Twitter's documented 2013 figures, still the canonical calibration: roughly 300,000 timeline reads/s against roughly 6,000 tweet writes/s -- about \textbf{50:1}. A read path that carries the product at that ratio is a demand on D1 before anything else +- Raw write rate modest; the \textbf{fan-out amplification} is not: one write by an account with millions of followers implies millions of logical deliveries. The naive materialisation ('\texttt{SELECT} over all follows at read time') was tried and abandoned; the documented solution: fan-out-on-write into in-memory timeline caches (bounded to some 800 entries per home timeline), hybridised with fan-out-on-read for extreme-follower accounts +- The textbook decision \emph{write work versus read work as a function of the read/write ratio} -- and the reason D2 stays Medium: the amplification is absorbed by a dedicated fan-out subsystem, not by the write path proper +- \textbf{The pace.} Feature change rate among the highest in industry: permanent A/B experiments, daily deployments -- Instagram: roughly 100 deployments per day on a Django codebase of several million lines. A joint demand on D7, D9 and -- once the organisation grows into hundreds of feature teams -- D11 +- \textbf{The spikes.} Spiky and viral load (breaking news, events), traffic multiplying within minutes: stresses D5 and keeps D3 binding at global peak. Data volume very large, predominantly unstructured (text, images, video); platform long-lived, individual features short-lived + +*Elements:* +- \footnotesize bullets, bold challenge labels + +*Notes:* Dense; itemsep 1pt. The 800-entry cache bound and the 50:1 ratio are the numbers to write on the board. Bullet 3 is the text of note 1 of the consolidated table (6 k writes/s vs 300 k reads/s) -- say so here, so the table frame needs no inline footnote. + +#### Frame 17: C2 -- binding scenarios and a light $K$ + +*Kind:* content -- *Source:* §20.1 scenarios and K (part3_application_classes.tex 214-222) -- *Minutes:* 3 + +- The (H,\,H) leaves of the C2 utility tree -- A4 in action, each with its response measure: +- \textbf{S1 (feed latency).} A user opens the home feed at global peak; the feed renders with \textbf{p99 server-side latency below 200 ms} -- the regime precomputed timelines and edge caches exist to meet. D1, D3 +- \textbf{S2 (fan-out delivery).} A user posts in normal operation; the post becomes visible to followers \textbf{within 5 seconds for the vast majority of accounts} -- Twitter's stated target, missed by design for extreme-follower accounts and compensated by hybrid fan-out. D2's amplification reading -- and a \emph{licence} on D4: seconds of staleness are within contract +- \textbf{S3 (availability under viral spikes).} An external event multiplies traffic within minutes; the platform keeps serving feeds with \textbf{SLO attainment maintained and the blast radius of any single component failure below a declared bound}. The D5 scenario +- $K(\text{C2})$ is comparatively light but not empty: the EU Digital Services Act (content-moderation, transparency and systemic-risk duties); GDPR (profiling, personal data) +- Neither forces a consistency model -- which is precisely why this class can trade consistency away: the mirror image of C1, where regulation forbids exactly that trade. $K$ knocks out little; \textbf{the discrimination work is done by the weights, not the constraints} + +*Elements:* +- short (H,H)/A4 tag line; scenario bullets in deck-6 style + +*Notes:* Contrast with frame 11: densest K versus lightest K. + +#### Frame 18: C2 -- requirements profile (column C2) + +*Kind:* table -- *Source:* §20.2 tab:req-c2 (part3_application_classes.tex 224-254) -- *Minutes:* 3 + +- D1 Read scalability -- \textbf{H} -- ca.\ 50:1 read/write ratio -- the read path carries the product +- D2 Write scal.\ \& elasticity -- M -- raw writes ca.\ 6 k/s; fan-out absorbed by a subsystem +- D3 Latency -- \textbf{H} -- p99 below 200 ms at global peak or the product feels broken +- D4 Consistency \& integrity -- L -- a feed seconds stale is invisible; eventual by design +- D5 Availability \& isolation -- \textbf{H} -- an unavailable feed is the defect; spikes arrive within minutes +- D6 Security \& auditability -- M -- DSA and GDPR duties matter but do not shape the topology +- D7 Evolvability -- \textbf{H} -- permanent A/B experiments; features live weeks, platform decades +- D8 Simplicity \& TTM -- M -- simplicity welcome but outbid by feature velocity at scale +- D9 Testability \& deployability -- \textbf{H} -- ca.\ 100 deployments per day need cheap, safe releases +- D10 Operating cost -- M -- fleet cost matters but never vetoes the read path +- D11 Team scaling -- \textbf{H} -- hundreds of feature teams must deploy independently +- D12 AI integrability -- M -- ranking and moderation are ML components off the p99 path +- Shape $S(a)$: interactive read-heavy. Constraints $K(a)$: DSA; GDPR + +*Elements:* +- 12-row requirements-profile table (scriptsize, arraystretch 0.8) from tab:req-c2 lines 228-254, plus Shape and Constraints rows; Highs bold; one-line 'Why' cells (~65 characters max) + +*Notes:* Six Highs, one Low on D4 -- point at the D1/D4 inversion relative to frame 12 (the mirror seen in deck 6, now derived). Note 1 was said on frame 16; D11's 'the documented growth bottleneck' is spoken. + +#### Frame 19: C2 -- what real systems chose, and why + +*Kind:* case -- *Source:* §20.3 (part3_application_classes.tex 256-260) -- *Minutes:* 3 + +- \textbf{Instagram} -- the documented monolith-at-scale case: to this day a Django monolith at its core, several million lines of Python, thousands of endpoints, roughly 100 deployments per day, scaled horizontally across tens of thousands of identical servers over sharded PostgreSQL and Cassandra +- It exploits exactly the cell the L and MM columns share: stateless replication of the application tier scales \emph{reads} far -- so D1 High is servable from a monolith. \textbf{A monolith is a potential organisational problem, not a read-scaling problem} +- A2 bites on D11: one release train throttles hundreds of teams -- why \textbf{Twitter/X} migrated from a Rails monolith to JVM services as organisation and load grew, and why its fan-out is an \emph{event flow} at heart: fan-out-on-write is publish/subscribe, the EDA column's home turf ($++$ on D1, D2 and D7's attach-new-consumers reading) +- The MS column serves the same three Highs -- independent scaling of feed, media and graph services (D1), independent team deployments (D9, D11) -- at the documented price of $--$ on D8 and D10, accepted at this scale +- \textbf{Mastodon} (open-source reference): Rails monolith with Sidekiq job queues, PostgreSQL (single writer, read replicas), Redis as feed cache and queue backend, Node.js streaming API, federated via ActivityPub. The entire fan-out mechanic -- one Sidekiq job per follower feed -- is inspectable in source: \emph{Mastodon is the secondary recommendation running in public} + +*Elements:* +- \footnotesize bullets; system names bold + +*Notes:* Connect to deck 1 (Stack Overflow: read scaling from one quantum) in one spoken sentence -- not on the slide. 'The scaling limits of the Rails monolith are documented rather than hidden' is spoken. + +#### Frame 20: C2 -- AI lens and the verdict + +*Kind:* ailens -- *Source:* §20.3 keypoint, ailinse, closing sentence (part3_application_classes.tex 262-270) -- *Minutes:* 3 + +- AI Lens (Feed ranking and moderation as runtime AI, Axis B): in C2, AI is the product's economic engine -- feed ranking, recommendation and content moderation are ML components \emph{in the serving path} +- They inherit the class's own discipline: ranking models trained in offline pipelines (a C6/C7-shaped subsystem) and served from precomputed feature stores at millisecond latency, so S1's p99 budget survives; moderation classifiers sit on the asynchronous ingestion path, where seconds of latency are invisible +- General Axis-B rule (Part V): \textbf{the latency class of the AI component, not its accuracy, decides where in the topology it may live} +- Key Concept (recall, Lecture 6): C1 and C2 are mirror images across the consistency/availability trade -- same twelve dimensions, inverted weights on D1 and D4; \emph{weights, not dimensions, define a class} -- now derived from both sides +- \textbf{Verdict (preview):} primary -- an EDA + microservices hybrid at organisational scale (MS and EDA at $++$); secondary -- a modular monolith until that scale is \emph{measured}, not assumed. The deciding measurement: deployments per developer per day as teams multiply. Part IV recomputes + +*Elements:* +- ailinse[Feed ranking and moderation as runtime AI (Axis B)] from lines 266-268 (condensed) +- keypoint from lines 262-264 as a one-sentence keypoint box (recall-tagged; the full box was deck 6's mirror-pair frame) + +*Notes:* The closing frame keeps the established two-box form (AI Lens + Key Concept) as in frames 14 and 27; the keypoint is a single sentence tagged as recall, so it does not repeat deck 6's full box. + +### Section: C3 -- Back-Office / Workflow + +#### Frame 21: C3 -- Back-office / workflow applications + +*Kind:* content -- *Source:* §21 opening (part3_application_classes.tex 275-277) -- *Minutes:* 3 + +- \emph{The organisation reorganises again, and by next sprint the approval workflow must follow: which structure absorbs its fortieth process change as cheaply as its first?} +- Internal administration systems: case management, approval workflows, HR and procurement processes, departmental record-keeping -- the vacation request, the invoice approval, the onboarding checklist +- The \textbf{modal, unglamorous case} of industrial software -- systematically under-represented in engineering blogs precisely because nothing about it is spectacular, which is itself the didactic point +- Users are employees, dozens to thousands; hours of downtime usually tolerable; load low and planable +- Three challenges: (1) \textbf{the organisation keeps changing under the software} (D7); (2) \textbf{the budget} (D8, D10); (3) \textbf{correctness with witnesses} (D4, D6) + +*Elements:* +- italic leading question in bankblue; numbered challenge list + +*Notes:* Light intro frame in the same rhythm as C1/C2/C4/C5; the numbers follow on the next frame. + +#### Frame 22: C3 -- the challenges: reorganisation, budget, witnesses + +*Kind:* content -- *Source:* §21.1 (part3_application_classes.tex 279-286) -- *Minutes:* 3 + +- \textbf{Reorganisation.} The dominant challenge is not technical: the \emph{organisation} keeps changing under the software. Maintenance and enhancement consume roughly 40--80\,\% (typically about 60\,\%) of life-cycle cost, mostly for adapting to reorganisations and process changes rather than repair -- the single strongest demand, on D7. Lifetimes 10--20 years and routinely beyond plan: the fortieth process change is not rhetorical +- \textbf{Budget.} Small internal teams against internal cost centres; every franc spent on platform machinery is a franc unavailable for the next reorganisation -- a standing demand on D8 and D10, and a standing veto against premium structures +- \textbf{Workload.} Almost no pressure: CRUD-dominated, moderately read-heavy (80/20 rule of thumb), office-hours load, gigabytes to a few terabytes of structured data -- D1, D2, D5 do not bind; a single relational ACID database almost always suffices; integration demand, however, is high +- \textbf{Witnesses.} Internal control systems demand enforced dual control and a complete audit trail per case -- D4 (transactional case state) and D6 + +*Elements:* +- \footnotesize bullets, bold challenge labels + +*Notes:* The budget paragraph and the workload paragraph are separate bullets. Spoken from the notes: the integration list (identity/LDAP, ERP, document management, e-mail) and 'often with document attachments'. + +#### Frame 23: C3 -- binding scenarios and the knock-outs + +*Kind:* content -- *Source:* §21.1 scenarios and K (part3_application_classes.tex 288-294) -- *Minutes:* 3 + +- The (H,\,H) leaves of the C3 utility tree -- A4 in action: +- \textbf{S1 (process change dispersion).} The organisation changes an approval process; the change is implemented and released \textbf{touching no more than the process definition and one module, within one sprint} -- change dispersion is the operative evolvability metric. The D7 scenario +- \textbf{S2 (four-eyes integrity).} A clerk approves a case that requires dual control; the system enforces the second approval and journals both: \textbf{zero bypasses and a complete, sequential audit trail per case} -- the internal-control-system obligation read as a scenario. D4, D6 +- \textbf{S3 (interactive adequacy).} A caseworker submits a form during office hours; the system responds \textbf{within 1--2 seconds} -- internal users tolerate more latency than customers, but not unboundedly more. D3, weighted Medium +- $K(\text{C3})$: GDPR for employee data; statutory retention duties (Switzerland: Art.\ 958\emph{f} Code of Obligations -- business records retained for ten years); internal control systems with enforced dual control; for public administration additionally administrative law and accessibility requirements +- \textbf{Knock-out reading:} a structure that cannot produce a sequential, tamper-evident audit trail per case, or cannot guarantee retention, is excluded -- constraints that favour simple, journaled, transactional designs + +*Elements:* +- short (H,H)/A4 tag line; scenario bullets in deck-6 style + +*Notes:* Point out that S1's response measure is a change-dispersion count -- the metric introduced with D7 in deck 2. + +#### Frame 24: C3 -- requirements profile (column C3) + +*Kind:* table -- *Source:* §21.2 tab:req-c3 (part3_application_classes.tex 296-326) -- *Minutes:* 3 + +- D1 Read scalability -- L -- dozens to thousands of internal users at office-hours load +- D2 Write scal.\ \& elasticity -- L -- two requests per second at the July peak -- nothing to elasticise +- D3 Latency -- M -- 1--2 s form turnaround suffices, but not unboundedly more +- D4 Consistency \& integrity -- \textbf{H} -- case state transactional; one skipped approval is an ICS finding +- D5 Availability \& isolation -- L -- hours of downtime are tolerable; the work waits +- D6 Security \& auditability -- \textbf{H} -- four-eyes enforcement and a tamper-evident trail per case +- D7 Evolvability -- \textbf{H} -- ca.\ 60\,\% of life-cycle cost is evolution, driven by reorganisations +- D8 Simplicity \& TTM -- \textbf{H} -- small teams, internal budgets: simplest adequate structure wins +- D9 Testability \& deployability -- M -- releases weekly, not hourly; regression scope modest +- D10 Operating cost -- \textbf{H} -- the budget belongs to the next reorganisation, not platform staff +- D11 Team scaling -- L -- one team, often part-time +- D12 AI integrability -- L -- document extraction decorates the intake edge; core untouched +- Shape $S(a)$: interactive. Constraints $K(a)$: retention law, e.g.\ OR 958\emph{f}; internal control systems; GDPR + +*Elements:* +- 12-row requirements-profile table (scriptsize, arraystretch 0.8) from tab:req-c3 lines 300-326, plus Shape and Constraints rows; Highs bold; one-line 'Why' cells + +*Notes:* The only class among today's five with D8 = H and D10 = H -- mark those two rows; they carry the argument of frame 26. Scenario tags (S1-S3) are spoken. + +#### Frame 25: C3 -- what real systems chose, and why + +*Kind:* case -- *Source:* §21.3 (part3_application_classes.tex 328-332) -- *Minutes:* 3 + +- The modal industrial answer: a three-tier or modular-monolith application over one relational database -- the capability tables explain why in two steps +- \textbf{Step 1, column L:} serves D8 and D10 at $++$ -- one artefact, one pipeline, near-zero platform staff -- and its ACID cell serves the D4 veto; its weakness is exactly where this class hurts most, the $-$ on D7 $\to$ layering fits only small, stable scope +- \textbf{Step 2, column MM:} the same run cost with domain boundaries that absorb the reorganisation-driven change rate -- D7 rises to $+$ while D4 and D10 keep their ratings, at the price of one step on D8 (boundary governance is a permanent line item): the Pareto choice when process change is frequent +- \textbf{Camunda} -- the class's other big lever, \emph{externalising the thing that changes most}: Camunda 7 embeds the process engine as a Java library with relational persistence (monolith-friendly); Camunda 8 rebuilt the engine (Zeebe) as a partitioned, replicated, horizontally scalable distributed system. Process models in BPMN 2.0: when a reorganisation arrives, \textbf{the process definition changes, not the codebase} -- S1 met by design +- Open-source references for the forms-over-data core: \textbf{Flowable}; the \textbf{Frappe} framework underlying ERPNext -- metadata-driven DocTypes generate schema, forms and REST APIs + +*Elements:* +- \footnotesize bullets; no mini table + +*Notes:* Spoken, not typeset: 'Camunda's product evolution is a miniature architecture lecture; the 7-to-8 migration documents precisely what distribution buys and what it costs'. The L-vs-MM cells are already in words in steps 1 and 2 -- no mini table. + +#### Frame 26: C3 -- why this class punishes distribution + +*Kind:* keyconcept -- *Source:* §21.3 examplebox and keypoint (part3_application_classes.tex 334-340); recall of deck 3 mini-match variant (AISE502_Vorlesung_3_Folien.tex 462-467) -- *Minutes:* 3 + +- Recall, Lecture 3 -- the mini-match variant against $R(\text{back-office})$: you computed this. MS hits \textbf{two unmitigated $--$ vetoes at once} (D8 and D10); verdicts L $+$, MM $++$, MS $--$. Today: the evidence behind those weights +- Example: a vacation-approval workflow serving 800 employees, peaking at perhaps \textbf{two requests per second} on the first workday of July. Every quality attribute microservices buy -- independent scaling, independent deployment by many teams, fault isolation across quanta -- is priced in platform staffing and operational complexity that this workload cannot amortise; the Segment case (Part I) showed a small team crushed by exactly this premium. C3 is the clearest instance of the rule that \textbf{D8 = H and D10 = H jointly veto premium-priced structures}: the class needs its budget for the next reorganisation, not for a service mesh +- Key Concept: C3 is the industry's modal case, and its profile rewards the simplest structure that meets the audit constraints -- evolution dominates the cost function, so D7 = H; nobody pays for scale that office-hours load never generates, so D8 = H and D10 = H. \emph{Unglamorous is not a defect of this class -- it is its optimum} + +*Elements:* +- one \footnotesize recall line above the boxes +- examplebox[Why this class punishes distribution] from lines 334-336 (condensed) +- keypoint from lines 338-340 + +*Notes:* Recall line plus two boxes; nothing else. The strongest continuity link of the day: the students derived the L/MM/MS verdicts for this class in week 3 without the evidence. + +#### Frame 27: C3 -- AI lens and the verdict + +*Kind:* ailens -- *Source:* §21.3 ailinse and closing sentence (part3_application_classes.tex 342-346) -- *Minutes:* 3 + +- AI Lens (Document extraction and workflow triage, Axis B): the AI foothold in C3 is \emph{unstructured input} -- incoming invoices, applications and correspondence parsed by LLM-based extraction components that propose structured case data +- The class's constraints shape the integration: extraction runs \textbf{asynchronously before the workflow starts} (latency-tolerant); its output is \textbf{validated against the domain schema} before any case is created (the ontology-guard tactic of Part V); the four-eyes obligation of S2 extends to AI proposals -- a human confirms, the system journals both the proposal and the confirmation +- D12 = L because none of this touches the class's core; it decorates the intake edge +- \textbf{Verdict (preview):} primary -- a modular monolith with externalised process logic, a Camunda-class workflow engine behind a port (MM at $++$); secondary -- layered 3-tier for small, stable scope (L at $+$). Part IV recomputes +- Project link: this is the discipline your deterministic services inherit (deck 6 inheritance diagram: 'the deterministic services are C3 -- ACID, boring on purpose') + +*Elements:* +- ailinse[Document extraction and workflow triage (Axis B)] from lines 342-344 (condensed) + +*Notes:* The ontology-guard sentence maps directly onto the project's 'ontology guard active on all insights' (M5). + +### Section: C4 -- ERP / Enterprise Core + +#### Frame 28: C4 -- ERP / enterprise core systems + +*Kind:* content -- *Source:* §22 opening (part3_application_classes.tex 351-354) -- *Minutes:* 3 + +- \emph{A sales order must update stock and ledger in the same breath -- for thirty years: what does 'integrated' actually demand?} +- Integrated enterprise systems: order management, inventory, finance, HR and production planning sharing \textbf{one} data model +- Defining property: the product's value \emph{is} the integration -- an order posting updates stock and ledger in one transaction, and every module sees every other module's data consistently +- Cross-module ACID transactions over a shared schema -- exactly what distribution makes structurally expensive +- Three challenges: (1) \textbf{cross-module atomicity} (D4, D6); (2) \textbf{time, in its most extreme form in the catalogue} (D7); (3) \textbf{rhythm rather than volume} (D3, D5; D1/D2 Low) + +*Elements:* +- italic leading question in bankblue; numbered challenge list + +*Notes:* Light frame. + +#### Frame 29: C4 -- the challenges: atomicity, thirty years, the batch window + +*Kind:* content -- *Source:* §22.1 (part3_application_classes.tex 356-362) -- *Minutes:* 4 + +- \textbf{Cross-module atomicity.} An order confirmation must commit order, stock reservation and ledger posting together, with zero half-completed postings, ever -- the hardest possible demand on D4, coupled directly to D6: financial-reporting law demands an unbroken, tamper-evident chain from source document to ledger entry. Eventual consistency \emph{between ledger and inventory} is not merely inconvenient -- it contradicts the audit obligation itself +- \textbf{Time.} SAP R/3 appeared in 1992; SAP had to extend mainstream maintenance for the ECC generation to end-2027 (optionally 2030) because customers could not complete their migrations. ERP life cycles of 20--30 years are the normal case; replacement projects run for years +- Under that horizon \emph{customising pressure is permanent} -- every enterprise adapts the system to itself -- so the central requirement is a disciplined extension mechanism (modules and add-ons rather than core modification): D7, with the operative sub-requirement that \textbf{extensions survive releases}. Change-rate signature inverse to load: core processes stable, customisations churn +- \textbf{Rhythm, not volume.} Mixed workload: an OLTP core with deterministic batch peaks (month-end and year-end close, MRP runs, payroll); interactive latency of 1--2 s suffices (D3 Medium); the batch window is a hard boundary; load is almost never the problem -- D1 and D2 Low; planned maintenance windows are an accepted norm, which caps D5 at Medium. Data medium to large, highly structured, very long retention + +*Elements:* +- \footnotesize bullets, bold challenge labels + +*Notes:* Four long bullets -- \footnotesize, itemsep 1pt. + +#### Frame 30: C4 -- binding scenarios and the knock-outs + +*Kind:* content -- *Source:* §22.1 scenarios and K (part3_application_classes.tex 364-370) -- *Minutes:* 3 + +- The (H,\,H) leaves of the C4 utility tree -- A4 in action: +- \textbf{S1 (cross-module posting).} A sales order is confirmed in normal operation; order, stock reservation and ledger posting commit atomically with \textbf{zero half-completed postings, ever}. The D4 veto scenario +- \textbf{S2 (period-end close).} Month-end closing starts at the period boundary; MRP, depreciation and reporting runs complete \textbf{within the overnight batch window, with a reconciled trial balance at 06:00}. The batch edge of the workload shape -- and D6's reconciliation reading +- \textbf{S3 (customising survival).} A new release of the core is installed in a system carrying years of customer-specific extensions; the extensions continue to function with \textbf{zero core modifications required and all extension contracts verified before rollout} -- the survival condition of 20--30-year life cycles. The D7 scenario +- $K(\text{C4})$: financial-reporting law (Swiss CO, HGB, IFRS); audit-proof archiving duties (GoBD in Germany, GeB\"uV in Switzerland); GDPR for the HR module; SOX control requirements for US-listed groups +- \textbf{Knock-out reading:} auditability of posting chains is an obligation, not an option -- a candidate that cannot demonstrate an unbroken, tamper-evident chain from source document to ledger entry is knocked out before scoring + +*Elements:* +- short (H,H)/A4 tag line; scenario bullets in deck-6 style + +*Notes:* Compare S2 with the PF frame of deck 6 ('the 02:00 run missed its window'). + +#### Frame 31: C4 -- requirements profile (column C4) + +*Kind:* table -- *Source:* §22.2 tab:req-c4 (part3_application_classes.tex 372-402) -- *Minutes:* 3 + +- D1 Read scalability -- L -- hundreds to thousands of internal users; load rarely binds +- D2 Write scal.\ \& elasticity -- L -- batch peaks deterministic and planned into the window +- D3 Latency -- M -- 1--2 s interactive turnaround; the batch window is the boundary +- D4 Consistency \& integrity -- \textbf{H} -- cross-module ACID postings order $\to$ stock $\to$ ledger \emph{are} the product +- D5 Availability \& isolation -- M -- planned maintenance windows are an accepted ERP norm +- D6 Security \& auditability -- \textbf{H} -- unbroken, tamper-evident chain from source document to ledger +- D7 Evolvability -- \textbf{H} -- 20--30-year lifetimes; extensions must survive releases +- D8 Simplicity \& TTM -- M -- nobody expects an ERP overnight, but complexity still costs +- D9 Testability \& deployability -- M -- release trains; extension contracts verified before rollout +- D10 Operating cost -- M -- material, but never the deciding dimension +- D11 Team scaling -- M -- several module teams coordinate inside one release +- D12 AI integrability -- L -- AI assists at the edges; the posting core is untouched +- Shape $S(a)$: interactive (+ batch runs). Constraints $K(a)$: GoBD/GeB\"uV; SOX; IFRS audit chains + +*Elements:* +- 12-row requirements-profile table (scriptsize, arraystretch 0.8) from tab:req-c4 lines 376-402, plus Shape and Constraints rows; Highs bold; one-line 'Why' cells + +*Notes:* Three Highs only (D4/D6/D7) -- the narrowest High set of the five; say so: a narrow High set with the hardest single High. D6's statute list (GoBD/GeBüV, SOX) sits in the Constraints row; scenario tags spoken. + +#### Frame 32: C4 -- what real systems chose, and why + +*Kind:* case -- *Source:* §22.3 (part3_application_classes.tex 406-408) -- *Minutes:* 3 + +- \textbf{Odoo}: a modular Python monolith over PostgreSQL -- every business domain a module over one shared ORM data model, extended by inheritance. \textbf{ERPNext} (Frappe; Python, MariaDB): metadata-driven -- DocTypes generate schema, forms and REST APIs +- Both: strict module boundaries, one deployment, one database, shared transactions -- \emph{the modular monolith in its purest industrial form} +- Read against the MM column: one ACID quantum answers the D4 veto; domain modules and a disciplined extension mechanism answer D7 -- exactly S3; the $-$ on D5 is absorbed because the class weights D5 only Medium: \textbf{a rare case where a pattern's weak cell meets a class that does not care} +- A2 starkest in the opposite direction: decomposing an ERP into independently deployable services turns cross-module atomicity into distributed sagas -- MS's $--$ on D4 meets the class's hardest High: \textbf{the structurally strongest anti-fit in the whole grid}; a decade of microservices enthusiasm produced no viable ERP counter-example +- Mitigation runs through the edges: hexagonal ports at the integration peripheries (EDI, banking, tax services) keep customising out of the core; period-end closing, MRP and payroll are canonical PF runs inside the batch window + +*Elements:* +- \footnotesize bullets; system names bold; no verdict paragraph (moved to frame 33) + +*Notes:* Five bullets at \footnotesize, each three lines or fewer. 'Community attempts at microservice ERPs have remained marginal; their near-absence after a decade ... is itself empirical evidence' is compressed to the last clause of bullet 4. + +#### Frame 33: C4 -- key concept, verdict and Discussion: what exactly ossified? + +*Kind:* discussion -- *Source:* §22.3 keypoint, thinkbox and closing sentence (part3_application_classes.tex 410-418) -- *Minutes:* 3 + +- Key Concept: C4 sharpens the difference between C3 and itself -- both are ACID, interactive, evolution-dominated classes, but C4's value proposition is \emph{integration across modules}, which binds the class to a \textbf{single transactional quantum}. Where C3 could plausibly be several small systems, C4 by definition cannot: decomposing it converts its core feature (cross-module atomic postings) into its hardest problem (distributed sagas) +- \textbf{Verdict (preview):} primary -- a modular monolith (MM at $++$), the strongest pattern--class alignment in the matrix; secondary -- hexagonal discipline within it for the extension ecosystem. Part IV recomputes +- Discussion: SAP's maintenance extension to 2027/2030 means thousands of enterprises run an ERP generation older than most of this course's students +- Is that an architecture failure, an architecture success, or both? +- Formulate your answer as a statement about D7 (evolvability): what precisely ossified -- the pattern, the customisations, or the organisation's ability to re-derive its own requirements profile? + +*Elements:* +- keypoint from lines 410-412 +- verdict as one bold-led line between the boxes (from line 418) +- thinkbox from lines 414-416 + +*Notes:* Two boxes and one verdict line; 3 minutes of discussion; steer to 'the customisations and the organisation, not the pattern'. Natural break before C5 -- about 95 minutes in (cumulative 97 min at the end of this frame). + +### Section: C5 -- E-Commerce + +#### Frame 34: C5 -- E-commerce platforms + +*Kind:* content -- *Source:* §23 opening (part3_application_classes.tex 423-426) -- *Minutes:* 3 + +- \emph{A hundred milliseconds of delay costs one per cent of sales, and Black Friday brings fifty times the load: what survives both at once?} +- Online retail platforms: catalogue, search, cart, checkout, payment, fulfilment +- Defining property: downtime and slowness convert \emph{directly} into revenue loss +- Equally defining: the only class in the catalogue whose consistency profile is \textbf{hybrid by definition} -- catalogue and recommendations may be stale, inventory is negotiable (oversell compensation), checkout and payment are strictly ACID +- Three challenges: (1) \textbf{a price tag on latency and availability} (D3, D5, D1); (2) \textbf{the most extreme seasonality of all classes} (D2, D9); (3) \textbf{the split personality of the data} (D4 Medium) + +*Elements:* +- italic leading question in bankblue; numbered challenge list + +*Notes:* Light frame. + +#### Frame 35: C5 -- the challenges: price tags, Black Friday, two kinds of truth + +*Kind:* content -- *Source:* §23.1 (part3_application_classes.tex 428-432); numbers first shown in deck 2 (211, 227) -- *Minutes:* 4 + +- \textbf{The price tag} (Lecture 2 numbers, now read as response measures): Amazon's internal experiment attributing roughly $-1\,\%$ of sales to $+100$ ms of latency; Akamai's 2017 retail study measuring up to $-7\,\%$ conversion per 100 ms of delay. Latency and availability are \emph{revenue variables} -- direct demands on D3 and D5, with documented conversion rates as the response measures +- The read side is equally commercial: browse-to-buy ratios often exceed \textbf{100:1}, so the catalogue is a read product -- D1 +- \textbf{Seasonality.} Black Friday/Cyber Monday: load factors of \textbf{10--50$\times$} over normal operation; Shopify reported peaks of roughly 280 million requests per minute for BFCM 2024. Peaks of that shape must be \emph{absorbed, not survived} -- the D2 demand, rehearsed in advance: peak readiness is load-tested at 10$\times$ baseline before the season, which is simultaneously a demand on D9 +- \textbf{Two kinds of truth.} The checkout must never lie, the catalogue may -- the hybrid consistency encoded as D4 Medium. Data heterogeneous (semi-structured catalogue, structured orders, media blobs); business change rate high (promotions, checkout experiments -- D7); integration surface very wide (payment service providers, logistics, tax, search, recommendations). The platform lives 10+ years; frontends are short-lived + +*Elements:* +- \footnotesize bullets, bold challenge labels + +*Notes:* The headline numbers ($-1\,\%$/100 ms, $-7\,\%$/100 ms, 280 M req/min) were on deck 2 -- the tag on bullet 1 says so; what is new is their reading as response measures and dimension demands. Note 6 of the consolidated table (catalogue eventual, checkout ACID) is said here, so the table frame needs no inline footnote. + +#### Frame 36: C5 -- binding scenarios and the PCI knock-out + +*Kind:* content -- *Source:* §23.1 scenarios and K (part3_application_classes.tex 434-440) -- *Minutes:* 3 + +- The (H,\,H) leaves of the C5 utility tree -- A4 in action: +- \textbf{S1 (peak elasticity).} Black-Friday traffic arrives at 10--50$\times$ normal load; browsing and checkout continue with \textbf{p95 checkout latency within budget and zero uncompensated oversells at 10$\times$ baseline in the pre-peak load test}. D2, D5, D9 +- \textbf{S2 (page latency).} A customer opens a product page in normal operation; it renders \textbf{in under 1--2 s, with API calls under 100--300 ms} -- the budgets behind the revenue calibrations. D1/D3 +- \textbf{S3 (payment-scope containment).} A security assessor audits the cardholder-data environment; the audit scope is demonstrably \textbf{confined to the tokenised payment subsystem, with third-party scripts on checkout pages inventoried and controlled} -- PCI DSS v4.0 read as a scenario. D6 +- $K(\text{C5})$: PCI DSS v4.0 governs cardholder data -- v3.2.1 retired 31 March 2024; future-dated requirements mandatory since 31 March 2025, including MFA for all access to the cardholder-data environment and control of third-party scripts on checkout pages. PSD2 (payment initiation, strong customer authentication); GDPR for customer data +- Direct architectural implication: \textbf{payment-scope minimisation} through tokenisation and outsourcing -- the audit scope is a function of the structure, so the structure is chosen to shrink it: \emph{regulation acting on D6 as a structural force} + +*Elements:* +- short (H,H)/A4 tag line; scenario bullets in deck-6 style + +*Notes:* Contrast with C1: there regulation forbids a consistency trade; here it reshapes the topology (scope zoning) -- both examples of frame 6's 'regulation translates into structure'. + +#### Frame 37: C5 -- requirements profile (column C5: seven Highs) + +*Kind:* table -- *Source:* §23.2 tab:req-c5 (part3_application_classes.tex 442-472) -- *Minutes:* 3 + +- D1 Read scalability -- \textbf{H} -- browse-to-buy beyond 100:1 -- the catalogue is a read product +- D2 Write scal.\ \& elasticity -- \textbf{H} -- 10--50$\times$ seasonal peaks must be absorbed, not survived +- D3 Latency -- \textbf{H} -- $+100$ ms $\approx -1\,\%$ sales: latency carries a price tag +- D4 Consistency \& integrity -- M -- hybrid by definition: catalogue eventual, checkout ACID +- D5 Availability \& isolation -- \textbf{H} -- downtime converts to revenue loss at documented rates +- D6 Security \& auditability -- \textbf{H} -- PCI DSS v4.0 makes payment-scope minimisation structural +- D7 Evolvability -- \textbf{H} -- promotions, checkout experiments, provider churn arrive weekly +- D8 Simplicity \& TTM -- M -- speed to market matters, but not at the checkout's expense +- D9 Testability \& deployability -- \textbf{H} -- load tests at 10$\times$ baseline gate the season +- D10 Operating cost -- M -- fleet cost matters; the revenue stakes dominate it +- D11 Team scaling -- M -- organisation-size dependent: Shopify versus Amazon +- D12 AI integrability -- M -- recommendations and search ranking serve off precomputed stores +- Shape $S(a)$: interactive, seasonal. Constraints $K(a)$: PCI DSS v4.0 scope minimisation; PSD2/SCA + +*Elements:* +- 12-row requirements-profile table (scriptsize, arraystretch 0.8) from tab:req-c5 lines 446-472, plus Shape and Constraints rows; Highs bold; one-line 'Why' cells + +*Notes:* Seven Highs -- more than any other class (script). No Low at all: say it -- the class pays on every dimension and has the least room to not pay. Notes 6 and 17 are spoken (note 6 was said on frame 35; note 17 -- team size, not traffic -- comes on frame 38). + +#### Frame 38: C5 -- what real systems chose, and why + +*Kind:* case -- *Source:* §23.3 (part3_application_classes.tex 476-478); recall of deck 4 examplebox 'Shopify -- the canonical modular monolith' (431-432) -- *Minutes:* 3 + +- \textbf{Shopify} -- the Lecture-4 case, now from the demand side: pod sharding lifts the MM column's weak D2 cell to carry 280-million-requests-per-minute peaks, while the single transactional quantum preserves checkout ACID against the D4 boundary -- a documented mitigation of exactly the two cells where pattern and profile rub. Stated rationale: developer productivity plus transactional consistency +- \textbf{Amazon} -- the founding pioneer of service orientation with two-pizza team ownership: the same class, the opposite structure, driven by organisational scale. MS's $++$ on D11 becomes decisive only when team count makes D11 bind: \textbf{team size, not traffic, is the deciding variable} -- A2 resolved by an organisational constraint, as in C1 +- Open source: \textbf{Saleor} (Python/Django, GraphQL-first API-centric monolith), \textbf{Medusa} (Node.js, modular commerce modules behind a REST API) -- the 'headless/composable' trend is a \emph{layering} cut, not a microservice cut +- Event-shaped edges -- order flows, inventory updates, search indexing, recommendation training -- served by EDA and PF beside the core; flash-sale spikes are the textbook serverless elasticity case: those three columns earn a $+$ in this row \textbf{without ever owning the checkout} + +*Elements:* +- \footnotesize bullets; system names bold; no verdict paragraph (moved to frame 39) + +*Notes:* Shopify's structure (Rails core, ca. 2.8 M lines restructured since 2017 into components with enforced boundaries, Packwerk, pod sharding) was deck 4's examplebox -- one spoken sentence. Amazon's bullet is the text of note 17 of the consolidated table. Shopify returns in Lecture 10 as an evolution-path case -- announce it in one sentence. + +#### Frame 39: C5 -- hybrid consistency as a designed boundary + +*Kind:* keyconcept -- *Source:* §23.3 examplebox, keypoint and closing sentence (part3_application_classes.tex 480-488) -- *Minutes:* 4 + +- Example: the C5 consistency split is not an accident to be tolerated but a boundary to be \emph{designed and documented} -- catalogue reads may be minutes stale (cache-friendly, eventually consistent); inventory may oversell within a compensable bound; the checkout/payment path is ACID with idempotent order creation. The measurable contract: \textbf{p95 checkout latency within budget and zero \emph{uncompensated} oversells during peak-load tests at 10$\times$ baseline}. Where exactly the boundary runs -- is the cart eventual or transactional? -- is a genuine ATAM tradeoff point and belongs in an ADR, not in folklore +- Key Concept: C5 is the class where quality attributes carry price tags -- latency and availability convert to revenue at documented rates, seasonality defines elasticity (10--50$\times$ peaks), and the consistency profile is hybrid \emph{by definition}: the one class where 'ACID or eventual?' is answered \textbf{'both, along a designed boundary'}. Team size, not traffic, decides between the Shopify and the Amazon structure +- \textbf{Verdict (preview):} primary -- a modular monolith with the hybrid consistency profile designed inside it and event-driven edges (MM at $++$); secondary -- microservices at organisational scale, MS/EDA/SL earning their $+$ at the edges. Part IV recomputes + +*Elements:* +- examplebox[Hybrid consistency as a designed boundary] from lines 480-482 (condensed) +- keypoint from lines 484-486 +- verdict as bold-led closing line (line 488), matching how frames 14/20/27 close a class + +*Notes:* Link to C10 (deck 6): the project's D4 is also a designed split (index eventual, audit path ACID) -- the same discipline, one ADR. + +### Section: Five Classes Side by Side + +#### Frame 40: Five classes side by side -- assembled from today's five tables + +*Kind:* table -- *Source:* Assembled from tab:req-c1..c5 (part3_application_classes.tex 152-178, 228-254, 300-326, 376-402, 446-472: the Weight and Shape rows already shown on frames 12, 18, 24, 31, 37); verdict codes from the closing sentences lines 198, 270, 346, 418, 488. Nothing from the consolidated table of Lecture 9 -- *Minutes:* 2 + +- Compact table, rows D1--D12, columns C1 | C2 | C3 | C4 | C5 -- the Weight columns of today's five profile tables placed side by side: D1 M/H/L/L/H; D2 M/M/L/L/H; D3 M/H/M/M/H; D4 H/L/H/H/M; D5 H/H/L/M/H; D6 H/M/H/H/H; D7 H/H/H/H/H; D8 L/M/H/M/M; D9 H/H/M/M/H; D10 L/M/H/M/M; D11 M/H/L/M/M; D12 M/M/L/L/M +- Shape row (label 'Shape $S(a)$ -- all interactive'), condensed from the five Shape rows: + batch edges | read-heavy | -- | + batch runs | seasonal +- Verdict row (primary, pattern codes from the five closing sentences): MM+HX | EDA+MS | MM | MM | MM +- One line under the table: all five interactive; \textbf{D7 High in all five}; D4 runs H/L/H/H/M -- the consistency axis of the map (frame 7); D8/D10 High only in C3 +- Label line (\scriptsize, last line of the frame): \emph{assembled from today's five tables; the ten-column version and its footnotes: Lecture 9} + +*Elements:* +- scriptsize table p{2.6cm} + 5 centred columns, Highs bold; weight cells copied from the Weight columns of frames 12/18/24/31/37 (tab:req-c1..c5, cell-identical); shape cells at most two words, condensed from the per-class Shape rows; verdict row as pattern codes only; scriptsize label line below the table + +*Notes:* A summary assembled from the five profile frames, not a preview of the consolidated table: nothing on this frame is taken from §29 -- the ten-column table, its row-reading rules and its seventeen footnotes are Lecture 9's. Spoken, not typeset: 'within the feasible set the organisation decides -- the Monzo condition (C1), deployments per developer per day (C2), team size not traffic (C5)'; 'Lecture 9 sets the other five columns beside these and adds the footnotes'. Droppable if the deck runs long; summary bullets 3-7 carry the five verdicts. + +### Section: Closing + +#### Frame 41: This week's exercise: the walking skeleton + +*Kind:* exercise -- *Source:* project_exercise.tex 355-363 (two phases), week-table rows 8-9 (376-377), taskbox M3 (416-422) and hintbox (451-464); milestone numbering M1-M6 from the taskboxes 391-448; semester plan row 8 -- *Minutes:* 3 + +- Project Link box: \textbf{implementation phase begins} -- the exercise slot becomes a one-hour standup/coaching session; implementation happens mainly in self-study time +- \textbf{M3 -- Walking Skeleton (weeks 8--9), the first milestone of the implementation phase:} an end-to-end thin slice running: \texttt{MarketDataService} delivers prices; a \emph{minimal} \texttt{ResearchAgent} produces one validated \texttt{Insight}; a stable API and a placeholder UI that calls it +- Build the skeleton first thing -- a thin end-to-end slice de-risks everything that follows +- Keep the deterministic core free of LLM calls -- this is the line that is graded (the C1 rule of today: agents propose, deterministic services decide and book) +- Use a snapshot of market/news data so demo and grading are reproducible; commit after each milestone; record decisions as ADRs as you go +- Checked in week 9: \textbf{walking skeleton runs end-to-end} + +*Elements:* +- projektbox with the M3 taskbox content (project_exercise.tex 416-422) and the hintbox lines 453-462 + +*Notes:* Same layout as deck 6 'This week's exercise'. Tie the C3 verdict to the deterministic services (ACID, boring on purpose). Milestone label M3 follows the taskboxes of project_exercise.tex (M1 requirements and ontology, weeks 1-3; M2 architecture decision and solution design, weeks 4-7; M3 walking skeleton, weeks 8-9; M4 deterministic core and resilience, weeks 10-11; M5 multi-agent orchestration, evaluation and hardening, weeks 12-13; M6 presentation, week 14) -- the same numbering decks 9-13 use. The semester plan's 'Notwendige Anpassungen' table (Semesterplan_AISE502_HS26.md lines 35-46) still labels the walking skeleton M2 and the later milestones M3/M4/M5; that table is stale, not the deck -- do not follow it. + +#### Frame 42: Summary + +*Kind:* summary -- *Source:* §18-§23 keypoints -- *Minutes:* 2 + +- 1. An application class is an ASR bundle, not an industry label: $R(a) = (w;\, S(a);\, K(a))$ -- weights from the (H,\,H) leaves; H a veto trigger, not a coefficient; $S(a)$ gates; $K(a)$ knocks out before scoring; one organisation runs several classes, so the matrix is read per subsystem +- 2. The map: shape $\times$ consistency semantics -- today's five are all interactive; C1/C4 strict ACID, C3 ACID-leaning, C5 split, C2 eventual +- 3. \textbf{C1}: D4/D5/D6/D7/D9 High, the densest $K$; LMAX vs.\ Monzo -- $R(a)$ defines the feasible set, constraints decide within it; verdict MM+HX core, EDA edges, PF batch +- 4. \textbf{C2}: 50:1 and the fan-out; D1/D3/D5/D7/D9/D11 High, D4 Low; Instagram scales reads from a monolith at 100 deployments/day; verdict EDA+MS at \emph{measured} organisational scale, MM until then +- 5. \textbf{C3}: the modal case -- ca.\ 60\,\% of life-cycle cost is evolution; D8 = H and D10 = H jointly veto premium structures; verdict MM with a workflow engine behind a port +- 6. \textbf{C4}: integration \emph{is} the product -- cross-module ACID binds the class to one quantum; MM the strongest alignment, MS's $--$ on D4 the strongest anti-fit in the grid +- 7. \textbf{C5}: quality attributes with price tags, 10--50$\times$ peaks, consistency hybrid by definition, PCI scope minimisation as structure; Shopify vs.\ Amazon -- team size, not traffic, decides +- 8. Every verdict is a preview: Part IV recomputes it through the three-stage procedure + +*Elements:* +- enumerate, \footnotesize, itemsep 2pt + +*Notes:* Eight points -- at the upper limit; keep each to one line and a half. + +#### Frame 43: Next week + +*Kind:* nextweek -- *Source:* Semester plan row 9; task brief 'Next lecture'; §29.1 opening sentence (part3_application_classes.tex 917-920); projektboxes §24.3 (558-560) and §25.3 (632-634) -- *Minutes:* 1 + +- Left column -- Lecture 9, Part III: classes C6--C9 and 'Stepping back: ten profiles side by side' +- C6 simulation/batch (reproducibility); C7 DSS/BI (freshness by refresh contract); C8 IoT streaming; C9 collaboration/messaging +- The consolidated requirements table with its seventeen footnotes (§29) +- Reading the catalogue as a whole: five cross-class observations (§29.1) +- C6 and C7 inside your C10 project (projektboxes §24.3, §25.3) +- Right column -- Reading: this week Part III, Sections 18--23; ahead Part III, Sections 24--27 and 29 +- Right column -- Exercise / deliverable: coaching; finish the walking skeleton -- \textbf{milestone M3: runs end-to-end (week 9)} + +*Elements:* +- two columns 0.55/0.42 as in deck 6; left column as a \footnotesize bullet list (six lines) + +*Notes:* Verbatim in substance from the task brief. The two added bullets announce what deck 9 teaches beyond C6-C9 and the table: §29.1's five cross-class observations (script line 920: 'Five cross-class observations fall out of the catalogue and prepare the matching in Part IV') and the two projektboxes -- the ingestion and eval pipelines are C6-shaped subsystems (reproducibility as the operative meaning of testability, line 560), the analytics and report subsystem is C7-shaped with the refresh contract 'analysis as of last completed ingestion' (line 634). Say both in one sentence each; the substance is Lecture 9's. + +#### Frame 44: Closing slide + +*Kind:* content -- *Source:* \FHGRClosingPage (deck 6 lines 703-706) -- *Minutes:* 0 + +- Thank you! -- Dr.\ Florian Herzog -- Fachhochschule Graub\"unden, Chur -- AISE502 -- AI in Software Engineering II + +*Elements:* +- \FHGRClosingPage with \parbox wrapper and \color{white} (trap 1 and 2 of the theme memo) + +*Notes:* Copy verbatim from deck 6. + +## Exercise frame: This week's exercise: the walking skeleton + +- Implementation phase begins: the exercise slot becomes a one-hour standup/coaching session; implementation happens mainly in self-study time +- M3 -- Walking Skeleton (weeks 8--9), the first milestone of the implementation phase: an end-to-end thin slice running -- \texttt{MarketDataService} delivers prices; a minimal \texttt{ResearchAgent} produces one validated \texttt{Insight}; a stable API and a placeholder UI that calls it +- Build the skeleton first thing in the implementation phase -- a thin end-to-end slice de-risks everything that follows +- Keep the deterministic core free of LLM calls -- this is the line that is graded (today's C1 rule: agents propose, deterministic services decide and book) +- Use a snapshot of market/news data so demo and grading are reproducible; commit after each milestone; record architectural decisions as ADRs as you go +- Checked in week 9: walking skeleton runs end-to-end + +## Summary frame + +1. An application class is an ASR bundle, not an industry label: $R(a) = (w;\, S(a);\, K(a))$ -- weights from the (H,\,H) leaves; H a veto trigger, not a coefficient; $S(a)$ gates; $K(a)$ knocks out before scoring; one organisation runs several classes, so the matrix is read per subsystem +2. The map: shape $\times$ consistency semantics -- today's five are all interactive; C1/C4 strict ACID, C3 ACID-leaning, C5 split, C2 eventual +3. C1: D4/D5/D6/D7/D9 High, the densest $K$; LMAX vs.\ Monzo -- $R(a)$ defines the feasible set, constraints decide within it; verdict MM+HX core, EDA edges, PF batch +4. C2: 50:1 and the fan-out; D1/D3/D5/D7/D9/D11 High, D4 Low; Instagram scales reads from a monolith at 100 deployments/day; verdict EDA+MS at measured organisational scale, MM until then +5. C3: the modal case -- ca.\ 60\,\% of life-cycle cost is evolution; D8 = H and D10 = H jointly veto premium structures; verdict MM with a workflow engine behind a port +6. C4: integration is the product -- cross-module ACID binds the class to one quantum; MM the strongest alignment, MS's $--$ on D4 the strongest anti-fit in the grid +7. C5: quality attributes with price tags, 10--50$\times$ peaks, consistency hybrid by definition, PCI scope minimisation as structure; Shopify vs.\ Amazon -- team size, not traffic, decides +8. Every verdict is a preview: Part IV recomputes it through the three-stage procedure + +## Next-week frame + +**Lecture 9 -- Part III: classes C6--C9 and 'Stepping back: ten profiles side by side'** + +- C6 scientific simulation / batch compute -- reproducibility as consistency semantics +- C7 DSS/BI -- freshness by refresh contract +- C8 IoT streaming -- event time, exactly-once state +- C9 collaboration/messaging -- connection-stateful, causal per channel +- Stepping back: the consolidated requirements table with its seventeen footnotes (§29) +- Reading the catalogue as a whole: five cross-class observations (§29.1) +- C6 and C7 inside your C10 project (projektboxes §24.3, §25.3) + +*Reading:* +- this week: Part III, Sections 18--23 +- ahead: Part III, Sections 24--27 and 29 + +*Exercise / deliverable:* +- coaching; finish the walking skeleton +- milestone M3: walking skeleton runs end-to-end (checked in week 9) + +## Script boxes, tables and figures used + +| Element | Script location | Used in frame | +|---|---|---| +| definitionbox[Application class] | §18, part3_application_classes.tex 18-25 | 4 Part III: the demand side, in the same vocabulary | +| hinweisbox (H is a veto trigger, not a coefficient) | §18.1, lines 39-41 | 5 Method recall: where the weights come from (Lectures 2--3) | +| keypoint (class = ASR bundle; one organisation operates several classes) | §18.2, lines 50-52 | 6 Workload shape and hard constraints | +| figure fig:classmap (tikz) | §18.3, lines 58-108 | 7 A map of the ten classes | +| hinweisbox (classification is a hypothesis, never a verdict) | §18.4, lines 113-115 | 8 Discussion: classification is a hypothesis -- test it on three systems (lead-in) | +| thinkbox (three systems you used this week) | §18.4, lines 117-119 | 8 Discussion: classification is a hypothesis -- test it on three systems | +| table tab:req-c1 | §19.2, lines 152-178 | 12 C1 -- requirements profile (Weight column re-used on frame 40's assembled table) | +| keypoint (R(a) defines the feasible set, constraints decide) | §19.3, lines 190-192 | 13 C1 -- what real systems chose, and why (closing box) | +| ailinse[Fraud scoring at the edge of the ledger (Axis B)] | §19.3, lines 194-196 | 14 C1 -- AI lens and the verdict | +| table tab:req-c2 | §20.2, lines 228-254 | 18 C2 -- requirements profile (Weight column re-used on frame 40's assembled table) | +| keypoint (C1 and C2 are mirror images) | §20.3, lines 262-264 | 20 C2 -- AI lens and the verdict (one-sentence keypoint box, recall-tagged; full box already in deck 6) | +| ailinse[Feed ranking and moderation as runtime AI (Axis B)] | §20.3, lines 266-268 | 20 C2 -- AI lens and the verdict | +| table tab:req-c3 | §21.2, lines 300-326 | 24 C3 -- requirements profile (Weight column re-used on frame 40's assembled table) | +| examplebox[Why this class punishes distribution] | §21.3, lines 334-336 | 26 C3 -- why this class punishes distribution | +| keypoint (C3 is the modal case; unglamorous is its optimum) | §21.3, lines 338-340 | 26 C3 -- why this class punishes distribution | +| ailinse[Document extraction and workflow triage (Axis B)] | §21.3, lines 342-344 | 27 C3 -- AI lens and the verdict | +| table tab:req-c4 | §22.2, lines 376-402 | 31 C4 -- requirements profile (Weight column re-used on frame 40's assembled table) | +| keypoint (C4 vs C3: integration binds to one quantum) | §22.3, lines 410-412 | 33 C4 -- key concept, verdict and Discussion | +| thinkbox (SAP maintenance extension: what ossified?) | §22.3, lines 414-416 | 33 C4 -- key concept, verdict and Discussion | +| table tab:req-c5 | §23.2, lines 446-472 | 37 C5 -- requirements profile (Weight column re-used on frame 40's assembled table) | +| examplebox[Hybrid consistency as a designed boundary] | §23.3, lines 480-482 | 39 C5 -- hybrid consistency as a designed boundary | +| keypoint (C5: quality attributes carry price tags) | §23.3, lines 484-486 | 39 C5 -- hybrid consistency as a designed boundary | + +## Script elements deliberately not used + +| Element | Script location | Reason | +|---|---|---| +| examplebox[LMAX versus Monzo: one profile -- two structures] | §19.3, lines 186-188 | already shown as a box in deck 3 (407-408) and as the deck-6 mirror-pair bullet; reduced to one spoken sentence in the notes of frame 13 -- its lesson is carried by the keypoint 190-192 on that frame | +| keypoint (an H is a veto trigger backed by a scenario; footnotes carry class-specific semantics) | §29, lines 860-862 | §29 is taught in Lecture 9 together with the full ten-column table and its seventeen footnotes; frame 40 is assembled from the five per-class tables of §19-§23 and takes nothing from §29 | +| tab:requirements footnotes 1, 3, 6, 17 | §29, lines 897-912 | referenced by number in the per-class tables (tab:req-c1 D3, tab:req-c2 D2, tab:req-c5 D4/D11) but not inlined in the deck's table cells (one-line rule); their substance also appears in the §19-§23 body text and is spoken there (note 1: frame 16; note 3: frame 10/12 notes; note 6: frame 35; note 17: frame 38) | +| tab:requirements footnotes 2, 4, 5, 7-16 | §29, lines 897-912 | belong to C6-C10 (Lecture 9; C10 covered in deck 6) | +| §18.4 'How to read the class sections' as a frame of its own | lines 110-112 | six lines of script; folded into the one-line rhythm strip on frame 4 -- the hinweisbox 113-115 moved to frame 8 as the discussion lead-in | +| Part III \part opening paragraph references to Tables tab:cap-l..tab:cap-sl and tab:capability | lines 14-16, 112 | cross-references only; the capability columns were shown in deck 6 and are quoted per class in the 'what real systems chose' frames | + +## Open issues for the author + +- No deck 7 file exists yet: the recap's Lecture-7 bullet is taken from the semester plan row 7 and deck 6's 'Next week' frame; re-align its wording once AISE502_Vorlesung_7_Folien.tex is typeset. +- Frame 40 is a summary table assembled from the five per-class tables of frames 12/18/24/31/37 (Weight cells cell-identical with tab:req-c1..c5), with a two-word shape row condensed from the per-class Shape rows and pattern-code verdicts from the five closing sentences; it is labelled 'assembled from today's five tables; the ten-column version and its footnotes: Lecture 9' and cites no §29 material, so §29 (table, row readings, footnotes, §29.1 observations) stays single-taught in deck 9. Drop the frame if the deck runs long -- summary bullets 3-7 carry the five verdicts. +- Milestone numbering: this deck (frames 3, 27 notes, 41, 43) uses the taskbox numbering of project_exercise.tex 391-448 -- M3 walking skeleton (weeks 8-9), M4 deterministic core + resilience (10-11), M5 multi-agent/eval/hardening (12-13), M6 presentation (14) -- as decks 9-13 do. The semester plan's 'Notwendige Anpassungen' table (Semesterplan_AISE502_HS26.md lines 35-46) still uses the older labels (M2 walking skeleton, M3 resilience + deterministic core, M4 multi-agent, M5 operate/harden), although its row 14 already says M6 and the exercise sheet has implemented the new phase logic (week table 369-387, taskboxes 401-448). Fix belongs in the semester plan, not in the deck: delete the 'Notwendige Anpassungen' section (its changes are applied) or rewrite its table with the sheet's numbering, and add the M-labels (M3, M4, M5) to the 'Meilenstein / Abgabe' column of rows 9, 11 and 13. +- The five profile tables (frames 12, 18, 24, 31, 37) now use one-line 'Why' cells (~65 characters, no parentheticals, no inline footnotes); weights, Shape and Constraints cells are cell-identical with the script, the 'Why' texts are condensations -- verify each frame visually with pdftoppm after the first build, and check the C4 D4 cell (contains two $\to$ arrows) for wrapping. +- Row label 'D5 Availability \& isolation' follows the deck-6 convention (deck 6 lines 210, 335, 568); the script writes 'D5 Availability \& fault isolation'. Kept for consistency within the slide series; restore 'fault isolation' if the convention is not intended. +- Footnotes 1, 3, 6, 17 of the consolidated table are no longer typeset anywhere; their content is spoken on frames 10, 16, 35 and 38 (and in the table-frame notes). If the lecturer wants them visible, the only place with room is the challenge frames, not the tables. +- Part III has no 'build it and study it' boxes and no licence/runnability status for its open-source references (Fineract, Mastodon, Camunda/Flowable/Frappe, Odoo/ERPNext, Saleor/Medusa); the deck must not add such status -- keep the references as the script states them (Fineract's week-4 study status is quoted from deck 4, not invented). +- The script provides only one figure for §18-23 (fig:classmap). Its node style 'projteal' is not defined in the deck preamble -- alias it (e.g. bankblue!70!black) or define it before redrawing. All other frames are text and tables. +- Density to verify after the first build: frames 10 (C1 numbers, target 13-14 lines), 11 (C1 scenarios with lead line and the K bullet), 16 (C2 challenges), 19 (C2 real systems), 22 (C3 challenges), 25 (C3 real systems), 29 (C4 challenges), 32 (C4 real systems) and 38 (C5 real systems) -- all at \footnotesize with three-line bullets; move parentheticals into speaker notes rather than adding frames. +- MT/MX coexistence: the script (line 134) writes prospectively 'ending in November 2025'; the deck speaks the SWIFT evidence from the notes of frame 10 with the script's wording and a remark that the phase has since ended. +- Script wording 'this class carries more Highs than any other' (C5) -- the count is seven of twelve (C2 has six, C1 five); frame 37 states 'seven Highs' rather than 'more than any other' to stay accurate before C6-C10 are seen. +- Minutes: content frames 4-40 sum to 115 (intro block 14, C1 20, C2 19, C3 21, C4 19, C5 20, side-by-side 2); agenda 1 + recap 3 + exercise 3 + summary 2 + next week 1 = 10 framing minutes; total 125 for three lessons, 44 frames including title and closing. Cumulative count at the end of frame 33 (C4 discussion, the natural break) is 97 minutes. +- Frame 43 'Next week' now carries six left-column lines (C6-C9, consolidated table, §29.1 observations, C6/C7 projektboxes) at \footnotesize in the 0.55 column -- verify with pdftoppm that the two columns still fit without an overfull box; the frame stays at 1 minute. + +--- + +# Lecture 9: Classes C6--C9 -- and Ten Profiles Side by Side + +- **Week:** 9 -- **Lessons:** 3 -- **Frames:** 42 +- **Title-slide script line:** Script: Part III, Sections 24--27, 29 + +## Agenda + +1. Recap: C1--C5 and the class rhythm -- where Part III stands +2. C6 -- Scientific simulation / batch compute: makespan, reproducibility, the third consistency semantics +3. C7 -- Decision support / BI analytics: OLAP scans and the refresh contract +4. Closing the loop: C6 and C7 inside your C10 project +5. C8 -- Real-time / IoT streaming: ingest at the world's rate, correctness under failure +6. C9 -- Collaboration / messaging: connection fan-out and push +7. Stepping back: ten profiles side by side -- the consolidated requirements table and its seventeen footnotes +8. Reading the catalogue as a whole: five cross-class observations +9. This week's exercise: the walking skeleton runs end-to-end (M3 closes) + +## Recap: where we are + +- Framework position: Part III supplies the demand side -- the requirements profile $R(a)$: weights $w_i(a)$ over D1--D12, workload shape $S(a)$, hard constraints $K(a)$; Part II supplied the capability profiles $C(p)$; Part IV matches the two through the three-stage non-compensatory match (Lectures 3 and 7) +- Last week (C1--C5): an application class \emph{is} a requirements profile -- a recurring ASR bundle with typical response measures, a characteristic workload shape and a regulatory frame; the rhythm: leading question $\to$ challenges $\to$ binding scenarios S1--S3 $\to$ twelve-row profile $\to$ what real systems chose +- Last week (C1--C5): C1 core banking (ACID ledger) and C2 social/content ($\sim 50{:}1$ read-heavy, deliberately eventual) as the mirror pair; C3 back-office; C4 ERP; C5 e-commerce, the only class \emph{defined} by a hybrid consistency profile +- Week 6 (C10): your class -- Highs on D6/D7/D9/D10/D12; inherits C6/C7/C3 and adds the cost model per request and evals as testability: \emph{spend the design budget on the new elements} +- The map of the ten classes: two axes -- workload shape and consistency semantics; C6 and C7 sit at semantics that are neither ACID nor eventual -- today we develop that third family +- Today: C6--C9 in the same rhythm, then the ten profiles side by side: the consolidated table, its seventeen footnotes, five cross-class observations -- the other operand of the fit matrix + +## Frame overview + +| # | Section | Frame title | Kind | Script ref | Min | +|---|---|---|---|---|---| +| 1 | Title | AISE502: AI in Software Engineering II -- Lecture 9: Classes C6--C9 -- and Ten Profiles Side by Side | content | title slide; subtitle line: Script: Part III, Sections 24--27, 29 | 0 | +| 2 | Agenda | Agenda | agenda | deck skeleton (decks 1-6); semester plan week 9 | 1 | +| 3 | Recap | Recap: where we are | recap | deck 6 summary and C10 frames; deck 8 (per brief: §18 + C1--C5); §18.3 map (part3_application_classes.tex 55-63) | 3 | +| 4 | C6 -- Scientific Simulation / Batch Compute | Part III continues: C6 -- Scientific simulation / batch compute | content | §24 intro and 24.1 (part3_application_classes.tex 493-502) | 4 | +| 5 | C6 -- Scientific Simulation / Batch Compute | C6 -- the binding scenarios | content | §24.1 scenarios and K(C6) (part3_application_classes.tex 504-508, 514) | 3 | +| 6 | C6 -- Scientific Simulation / Batch Compute | The third consistency semantics: reproducibility and refresh contracts | definition | §24.1 definitionbox (part3_application_classes.tex 510-512); also §18.3 (55-57) | 3 | +| 7 | C6 -- Scientific Simulation / Batch Compute | C6 -- requirements profile (column C6) | table | §24.2 tab:req-c6 (part3_application_classes.tex 520-546) | 4 | +| 8 | C6 -- Scientific Simulation / Batch Compute | C6 -- what real systems chose, and why | case | §24.3 (part3_application_classes.tex 548-552) | 3 | +| 9 | C6 -- Scientific Simulation / Batch Compute | C6 -- key concept | keyconcept | §24.3 keypoint (part3_application_classes.tex 554-556), verdict (562); projektbox pointer only (558-560) | 3 | +| 10 | C7 -- Decision Support / BI Analytics | C7 -- Decision support / BI analytics | content | §25 intro and 25.1 (part3_application_classes.tex 567-576) | 4 | +| 11 | C7 -- Decision Support / BI Analytics | C7 -- the binding scenarios | content | §25.1 scenarios and K(C7) (part3_application_classes.tex 578-584) | 3 | +| 12 | C7 -- Decision Support / BI Analytics | C7 -- requirements profile (column C7) | table | §25.2 tab:req-c7 (part3_application_classes.tex 590-616) | 4 | +| 13 | C7 -- Decision Support / BI Analytics | C7 -- what real systems chose, and why | case | §25.3 (part3_application_classes.tex 618-622) | 4 | +| 14 | C7 -- Decision Support / BI Analytics | C7 -- AI lens and key concept | ailens | §25.3 ailinse (part3_application_classes.tex 628-630), keypoint (624-626), verdict (636) | 3 | +| 15 | C7 -- Decision Support / BI Analytics | Closing the loop: C6 and C7 inside your C10 project | content | §24.3 projektbox (part3_application_classes.tex 558-560); §25.3 projektbox (632-634); deck 6 'C10 -- your project as an inheritance diagram' (lines 629-640) | 3 | +| 16 | C8 -- Real-Time / IoT Streaming | C8 -- Real-time / IoT streaming | content | §26 intro and 26.1 (part3_application_classes.tex 641-650) | 4 | +| 17 | C8 -- Real-Time / IoT Streaming | C8 -- the verified magnitudes | table | §26.1 first challenge (part3_application_classes.tex 648-649); recap of deck 5 examplebox 'Kafka at LinkedIn; the Uber real-time stack' (AISE502_Vorlesung_5_Folien.tex 423-424) | 1 | +| 18 | C8 -- Real-Time / IoT Streaming | C8 -- the binding scenarios | content | §26.1 scenarios and K(C8) (part3_application_classes.tex 652-658) | 4 | +| 19 | C8 -- Real-Time / IoT Streaming | C8 -- requirements profile (column C8) | table | §26.2 tab:req-c8 (part3_application_classes.tex 664-690) | 4 | +| 20 | C8 -- Real-Time / IoT Streaming | C8 -- what real systems chose, and why | case | §26.3 (part3_application_classes.tex 692-696) | 4 | +| 21 | C8 -- Real-Time / IoT Streaming | C8 -- AI lens and key concept | ailens | §26.3 ailinse (part3_application_classes.tex 702-704), keypoint (698-700), verdict (706) | 3 | +| 22 | C9 -- Collaboration / Messaging | C9 -- Collaboration / messaging | content | §27 intro and 27.1 (part3_application_classes.tex 711-720) | 4 | +| 23 | C9 -- Collaboration / Messaging | C9 -- the connections and the history tail: two measured cases | case | §27.1 (part3_application_classes.tex 718-720); Discord recap of deck 4 examplebox 'Storage migrations behind a seam -- Discord' (AISE502_Vorlesung_4_Folien.tex 670-671) | 3 | +| 24 | C9 -- Collaboration / Messaging | C9 -- the binding scenarios | content | §27.1 scenarios and K(C9) (part3_application_classes.tex 722-728) | 3 | +| 25 | C9 -- Collaboration / Messaging | C9 -- requirements profile (column C9) | table | §27.2 tab:req-c9 (part3_application_classes.tex 734-760) | 4 | +| 26 | C9 -- Collaboration / Messaging | C9 -- same domain, four structures | table | §27.3 (part3_application_classes.tex 764-766) | 3 | +| 27 | C9 -- Collaboration / Messaging | C9 -- key concept | keyconcept | §27.3 keypoint (part3_application_classes.tex 768-770) and verdict (776) | 2 | +| 28 | C9 -- Collaboration / Messaging | Discussion | discussion | §27.3 thinkbox (part3_application_classes.tex 772-774) | 3 | +| 29 | Stepping Back: Ten Profiles Side by Side | Stepping back: ten profiles side by side -- three reading rules | content | §29 intro (part3_application_classes.tex 853-858); D4/D7 observations read off tab:requirements (869-894, 904-908) | 3 | +| 30 | Stepping Back: Ten Profiles Side by Side | The consolidated requirements table (1/2): D1--D6 | table | §29 tab:requirements rows D1--D6 (part3_application_classes.tex 864-880) | 4 | +| 31 | Stepping Back: Ten Profiles Side by Side | The consolidated requirements table (2/2): D7--D12 and $S(a)$ | table | §29 tab:requirements rows D7--D12 and shape row (part3_application_classes.tex 881-889) | 3 | +| 32 | Stepping Back: Ten Profiles Side by Side | Hard constraints $K(a)$ -- the knock-out row | table | §29 tab:requirements K(a) row (part3_application_classes.tex 891-892); §24.1 (514) and §26.1 (658) for the reading line | 3 | +| 33 | Stepping Back: Ten Profiles Side by Side | The seventeen footnotes are part of the semantics (1/2): notes 1--9 | content | §29 tab:requirements footnotes 1-9 (part3_application_classes.tex 896-905) | 3 | +| 34 | Stepping Back: Ten Profiles Side by Side | The seventeen footnotes are part of the semantics (2/2): notes 10--17 and the rule | keyconcept | §29 tab:requirements footnotes 10-17 (part3_application_classes.tex 906-913) and keypoint (860-862) | 3 | +| 35 | Stepping Back: Ten Profiles Side by Side | Reading rows: what discriminates -- the two questions to ask first | table | §29.1 observation 1 (part3_application_classes.tex 918); §29 reading rule 2 (858); H positions counted from tab:requirements (869-889) | 3 | +| 36 | Stepping Back: Ten Profiles Side by Side | Reading the catalogue as a whole (1/2): scale does not force microservices | content | §29.1 observation 2 (part3_application_classes.tex 920-924) | 3 | +| 37 | Stepping Back: Ten Profiles Side by Side | Reading the catalogue as a whole (2/2): rollbacks, regulation, inheritance | content | §29.1 observations 3-5 (part3_application_classes.tex 926-930) | 3 | +| 38 | Stepping Back: Ten Profiles Side by Side | The other operand is ready | discussion | §29.1 keypoint (part3_application_classes.tex 932-934) and thinkbox (936-938) | 4 | +| 39 | Closing | This week's exercise: the walking skeleton runs end-to-end (M3 closes) | exercise | project_exercise.tex 355-466 (M3 taskbox, hintbox); semester plan week 9; §24.3 and §25.3 projektboxes (one-line pointer) | 3 | +| 40 | Closing | Summary | summary | keypoints §24-27, §29 (part3_application_classes.tex 554, 624, 698, 768, 860, 932) | 2 | +| 41 | Closing | Next week | nextweek | semester plan week 10; brief 'Next lecture' line | 1 | +| 42 | Closing | Closing slide | content | deck skeleton | 0 | + +## Frames in detail + +### Section: Title + +#### Frame 1: AISE502: AI in Software Engineering II -- Lecture 9: Classes C6--C9 -- and Ten Profiles Side by Side + +*Kind:* content -- *Source:* title slide; subtitle line: Script: Part III, Sections 24--27, 29 -- *Minutes:* 0 + +- \FHGRTitlePage with subtitle 'Lecture 9: Classes C6--C9 -- and Ten Profiles Side by Side' and small line 'Script: Part III, Sections 24--27, 29' +- Author Dr.\ Florian Herzog; Fachhochschule Graub\"unden, Chur -- Autumn Semester 2026 + +*Elements:* +- FHGR title page as in deck 6 (metadata block lines 118-127 of AISE502_Vorlesung_6_Folien.tex, \FHGRTitlePage at line 127) + +*Notes:* Identical metadata block to deck 6; only subtitle and script line change. One colon then an en-dash, as in 'Lecture 6: Pipelines, Serverless, the View Across -- and Your Class (C10)'. + +### Section: Agenda + +#### Frame 2: Agenda + +*Kind:* agenda -- *Source:* deck skeleton (decks 1-6); semester plan week 9 -- *Minutes:* 1 + +- 1. Recap: C1--C5 and the class rhythm +- 2. \textbf{C6} -- Scientific simulation / batch compute: the third consistency semantics +- 3. \textbf{C7} -- Decision support / BI analytics: the refresh contract +- 4. Closing the loop: C6 and C7 inside your C10 project +- 5. \textbf{C8} -- Real-time / IoT streaming: correctness under failure +- 6. \textbf{C9} -- Collaboration / messaging: connection fan-out and push +- 7. Stepping back: \textbf{ten profiles side by side} -- the consolidated table and its seventeen footnotes +- 8. Reading the catalogue as a whole: five cross-class observations +- 9. This week's exercise: \textbf{the walking skeleton runs end-to-end} + +*Elements:* +- enumerate, \small, itemsep 1pt (deck-6 'Agenda' frame format, line 132) + +*Notes:* Nine items is the maximum the agenda frame tolerates at \small; keep each to one line. + +### Section: Recap + +#### Frame 3: Recap: where we are + +*Kind:* recap -- *Source:* deck 6 summary and C10 frames; deck 8 (per brief: §18 + C1--C5); §18.3 map (part3_application_classes.tex 55-63) -- *Minutes:* 3 + +- \textbf{Framework position:} Part III = the demand side -- $R(a)$: weights $w_i(a)$ over D1--D12, workload shape $S(a)$, hard constraints $K(a)$; Part II gave $C(p)$; Part IV matches them (three-stage non-compensatory match, Lectures 3 and 7) +- \textbf{Last week (C1--C5):} an application class \emph{is} a requirements profile -- a recurring ASR bundle with typical response measures, a characteristic workload shape, a regulatory frame; the rhythm: leading question $\to$ challenges $\to$ S1--S3 $\to$ 12-row profile $\to$ what real systems chose +- \textbf{Last week (C1--C5):} C1 (ACID ledger) and C2 ($\sim 50{:}1$ read-heavy, deliberately eventual) as the mirror pair; C3 back-office; C4 ERP; C5 e-commerce, the only class \emph{defined} by a hybrid consistency profile +- \textbf{Week 6 (C10):} Highs on D6/D7/D9/D10/D12; \emph{inherits} C6/C7/C3; spend the design budget on the two novelties (cost per request, evals as testability) +- \textbf{The map of the ten classes:} two axes -- workload shape and consistency semantics; C6 and C7 sit at semantics that are neither ACID nor eventual -- today we develop that third family +- \textbf{Today:} C6--C9 in the same rhythm; then ten profiles side by side -- the consolidated table, its seventeen footnotes, five cross-class observations + +*Elements:* +- bullet list, \footnotesize, six bullets of two to three lines -- the maximum; no classmap thumbnail + +*Notes:* One frame only; do not re-teach C1--C5 or C10. No deck, frame or section numbers on the slide (decks 1-6 say 'last week' / 'week 6'). The three-stage fit procedure was introduced in deck 3 and formalised in Lecture 7, hence '(Lectures 3 and 7)'. + +### Section: C6 -- Scientific Simulation / Batch Compute + +#### Frame 4: Part III continues: C6 -- Scientific simulation / batch compute + +*Kind:* content -- *Source:* §24 intro and 24.1 (part3_application_classes.tex 493-502) -- *Minutes:* 4 + +- \emph{\textcolor{bankblue}{The nightly risk run must reproduce, to the bit, on ten thousand cores by 06:00: what does that demand?}} +- The class: compute-dominated batch systems -- cost function CPU/GPU-hours; availability in the online sense irrelevant (\emph{an aborted job is restarted from a checkpoint, not mourned}); correctness means \textbf{reproducibility}: regenerable from versioned inputs, versioned code and deterministic seeds +- \textbf{1. The interactive vocabulary does not apply} -- no read/write ratio, only read-input $\to$ compute $\to$ write-output over immutable datasets; the response measures are \textbf{makespan} (hours to weeks) and \textbf{batch-window adherence}: D2 High in its makespan reading (note 2), D3 Low (note 4); planned, queue-based load at a utilisation target near 100\,\% +- \textbf{2. The reproducibility obligation} -- bit-identical reruns from versioned inputs, code and seeds: a scientific duty and, for regulated risk models, a supervisory one $\to$ D9 in its reproducibility reading (note 14), D4 ``as of this run'' (note 8) +- \textbf{3. Physics: scaling has a measurable ceiling} -- OpenFOAM domain decomposition pays down to roughly 50{,}000--200{,}000 cells per core, below which communication overhead dominates (Amdahl's law as an architecture boundary); Monte-Carlo is embarrassingly parallel -- the ideal pipeline case + +*Elements:* +- leading question in bankblue italics; numbered list of the three challenges, two lines each (deck-6 'Part III opens: C10 -- AI-native advisory platforms' format, lines 528-541) + +*Notes:* \footnotesize body; class description two lines, each challenge capped at two lines (~13 lines). Speaker notes carry what was trimmed from lines 495-502: the CFD/Monte-Carlo/ML-training/data-transformation examples; 'unlawful to rely on' (returns in the K paragraph of the next frame); utilisation near 100 % as the economic opposite of C2/C5 elastic headroom; cost per simulation as a first-order D10 concern; TB--PB of result data; the split change rate (research-driven model code vs. 30+-year-old Fortran/C++ kernels) that keeps D7 at Medium -- the last two sit in the profile table's D7/D10 rows. Emphasise 'makespan' and 'reproducibility' as the two words that replace 'latency' and 'ACID'. + +#### Frame 5: C6 -- the binding scenarios + +*Kind:* content -- *Source:* §24.1 scenarios and K(C6) (part3_application_classes.tex 504-508, 514) -- *Minutes:* 3 + +- \textbf{S1 (batch-window adherence).} Overnight risk run starts after close of business; full portfolio revaluation completes \textbf{within the batch window, results published before start of trading}. \textcolor{codegray}{(The D2 scenario in its makespan reading.)} +- \textbf{S2 (bit-level reproducibility).} A model validator re-executes a historical run months later; the pipeline regenerates the results \textbf{bit-identically from versioned inputs, code and seeds}. \textcolor{codegray}{(The D9/D4 scenario.)} +- \textbf{S3 (cost efficiency).} The quarterly compute bill is reviewed; cost per simulation and cluster utilisation stay \textbf{within budget at a utilisation target near 100\,\%} -- queue-based scheduling exists to meet exactly this measure. \textcolor{codegray}{(The D10 scenario.)} +- $K(\text{C6})$ in financial applications: internal models are subject to \textbf{model validation and backtesting} under the Basel framework; traceability of model runs is audit-relevant -- the BCBS~239 lineage obligation extends into the simulation stack +- \textbf{Knock-out reading:} any structure that cannot pin \emph{data version + code version + seed} per run is excluded for regulated risk computation, whatever its throughput. \textbf{Deterministic seeds are a hard constraint, not a nicety.} + +*Elements:* +- three-scenario itemize with response measures in bold and the dimension in codegray; K paragraph and knock-out reading below (deck-6 'C10 -- the binding scenarios' format, lines 543-553) + +*Notes:* Point out that S1 and S3 are the same numbers the PF column's D3 = $--$ and D10 = $++$ cells were built from (week 6). + +#### Frame 6: The third consistency semantics: reproducibility and refresh contracts + +*Kind:* definition -- *Source:* §24.1 definitionbox (part3_application_classes.tex 510-512); also §18.3 (55-57) -- *Minutes:* 3 + +- Beside \textbf{ACID} (``concurrent operations preserve invariants'') and \textbf{eventual consistency} (``replicas converge, staleness is bounded''), the batch world defines a \emph{third family} of consistency semantics +- \textbf{Reproducibility (C6):} immutable inputs and idempotent, seeded stages guarantee that a rerun yields the identical result -- consistency ``\textbf{as of this run}'' +- \textbf{Freshness by refresh contract (C7):} consumers see a complete, internally consistent state ``\textbf{as of the last refresh}'' (e.g.\ yesterday 24:00), never a half-updated one +- Both are \emph{weaker} than ACID and \emph{stronger} than unqualified eventual consistency -- and both are \textbf{contracts with response measures}, testable in CI like any other scenario +- Supply side, already seen: the PF column's D4 $= +$ (week 6: ``the subtlest cell in the table''); demand side, today: footnotes 8 (C6) and 10 (C7) of the consolidated table + +*Elements:* +- definitionbox[The third consistency semantics: reproducibility and refresh contracts] from lines 510-512, verbatim in substance; one closing bullet linking to week 6 and the footnotes + +*Notes:* Serves both C6 and C7 -- place here, refer back on the C7 intro and key-concept frames. The last bullet is the deck's own bridge (deck 6 PF cell, footnotes 8/10), not new content. Wording: deck 6 phrased the PF D4 = + cell as 'as of last run' (lines 209, 229, 663); the script's canonical wording (line 511) is 'as of this run' -- same semantics, say so if a student notices. + +#### Frame 7: C6 -- requirements profile (column C6) + +*Kind:* table -- *Source:* §24.2 tab:req-c6 (part3_application_classes.tex 520-546) -- *Minutes:* 4 + +- D1 Read scalability | L | no interactive readers; outputs are files and tables +- D2 Write scal.\ \& elasticity | \textbf{H} | throughput as makespan and batch-window compute bursts (S1; note 2) +- D3 Latency | L | per-request latency is meaningless; the window is the measure (note 4) +- D4 Consistency \& integrity | M | consistency ``as of this run'': bit-level reproducibility from versioned inputs and seeds (note 8) +- D5 Availability \& isolation | L | an aborted job is restarted from a checkpoint, not mourned +- D6 Security \& auditability | M | lineage of regulated model runs is audit-relevant; no online attack surface +- D7 Evolvability | M | model code churns research-driven; numeric kernels live 30+ years +- D8 Simplicity \& TTM | M | orchestration should stay simple; the kernels never are +- D9 Testability \& deployability | \textbf{H} | reproducibility is the operative meaning of testability (S2; note 14) +- D10 Operating cost | \textbf{H} | the cost function \emph{is} CPU/GPU-hours at near-100\,\% utilisation (S3) +- D11 Team scaling | L | small research and engineering teams +- D12 AI integrability | M | training and simulation pipelines host ML natively, at batch cadence +- Shape $S(a)$: scheduled batch | Constraints $K(a)$: model validation and backtesting (finance); deterministic seeds + +*Elements:* +- 12-row requirements-profile table (scriptsize, arraystretch 0.8, p{3.0cm} c p{7.7cm}) from tab:req-c6 lines 526-544, Highs bold; Shape and Constraints rows below midrule -- deck-6 'C10 -- requirements profile' format (lines 555-582, with \vspace{-0.35cm}) + +*Notes:* Read aloud only the three Highs (D2, D9, D10) against S1--S3 and the two footnoted cells (D2, D4, D9); stress that D2 High here means makespan, not requests/s -- the first footnoted letter of the day. The D7 row carries the change-rate remark trimmed from the intro frame. + +#### Frame 8: C6 -- what real systems chose, and why + +*Kind:* case -- *Source:* §24.3 (part3_application_classes.tex 548-552) -- *Minutes:* 3 + +- \textbf{Dominant form: pipes-and-filters on HPC or batch infrastructure} -- the PF column reads like a transcript of this class's Highs: immutable inputs $+$ deterministic, idempotent stages give reproducibility (D9) \emph{by construction}; batch scheduling drives utilisation towards the D10 target; the shape matches the gate that eliminates every interactive pattern outright +- \textbf{OpenFOAM}: domain decomposition via graph partitioning, MPI communication, scheduled by \textbf{Slurm} as batch resource manager; \textbf{OpenMC}: modern parallel Monte-Carlo transport code of the same family; \textbf{Spark} (data-parallel) and \textbf{Airflow} (DAG orchestration) as cloud-native incarnations (Dask/Ray Python-native) +- \textbf{Where the trade-off bites (A2): data affinity} -- distributing a tightly coupled numeric dataflow across expensive boundaries multiplies communication cost +- \textbf{Prime Video} (already met; now read from the demand side) as this class's cautionary tale in miniature: a tightly coupled processing flow distributed across orchestrator transitions and S3 round-trips per frame, until consolidation into one process cut cost by over 90\,\% -- \emph{when inter-stage communication dominates, consolidate, do not distribute} +- \textbf{Serverless fan-out earns only a conditional role}: embarrassingly parallel, communication-light bursts (Monte-Carlo) fit FaaS elasticity; data-heavy stages recreate the Prime Video cost trap + +*Elements:* +- five bullets \footnotesize (deck-6 'C10 -- what real systems chose, and why' format, line 584); no verdict line -- the 'in one sentence' verdict closes the key-concept box on the next frame + +*Notes:* Five bullets is the limit. Prime Video was taught in weeks 1--3 and 6 -- do not retell; say 'same case, now the demand side'. + +#### Frame 9: C6 -- key concept + +*Kind:* keyconcept -- *Source:* §24.3 keypoint (part3_application_classes.tex 554-556), verdict (562); projektbox pointer only (558-560) -- *Minutes:* 3 + +- \textbf{Key concept:} C6 replaces the interactive vocabulary wholesale: the response measures are \textbf{makespan, batch-window adherence and cost per simulation}; correctness means \textbf{bit-level reproducibility} from versioned inputs and seeds; consistency means ``as of this run''. A structure fits this class exactly to the degree that it makes these three \emph{measurable by construction} -- which is why immutable-input pipelines dominate it. \textbf{In one sentence:} PF on HPC/batch infrastructure (PF at $++$), serverless fan-out secondary for bursty, communication-light parallel sections -- Part IV computes the verdict through the three-stage procedure +- \textbf{Project link:} the ingestion pipeline and the eval pipeline of your platform are C6-shaped subsystems -- the loop closes after C7 + +*Elements:* +- keypoint box (lines 554-556, condensed) with the verdict (line 562) as its last sentence -- deck-6 keypoint format ('In one sentence' inside the box, line 636); one plain pointer line below + +*Notes:* First half of closing week 6's inheritance loop: the C6 projektbox substance (558-560) is taught on the 'Closing the loop' frame after C7, not here -- avoid showing the same three sentences three times. + +### Section: C7 -- Decision Support / BI Analytics + +#### Frame 10: C7 -- Decision support / BI analytics + +*Kind:* content -- *Source:* §25 intro and 25.1 (part3_application_classes.tex 567-576) -- *Minutes:* 4 + +- \emph{\textcolor{bankblue}{Monday, 08:00: the management dashboard must be complete as of yesterday 24:00 -- and every number must prove where it came from. What delivers that, night after night?}} +- The class: data warehouses, BI platforms, reporting systems -- an \textbf{integration product over C1--C5}: it owns almost no data of its own but integrates everyone else's, so data quality, lineage and governance are first-class; its consistency semantics is the \textbf{refresh contract} (the definition just given): ``consistent as of yesterday 24:00'' is a deliberate design choice, not a deficiency +- \textbf{1. The shape of the reads} -- almost pure read, but \textbf{heavy OLAP scans by few users}, not point reads by many (note 7): a D1 demand in its own reading, scan capacity \emph{delegated} to the warehouse engine; writes bundled into the ELT/ETL window (D2 Low); dashboards render in seconds (D3 Medium) +- \textbf{2. The refresh contract} -- marts refreshed within the window and visible \emph{atomically}; consumers never see a half-updated state (D4 Medium, note 10); adherence tracked as a fitness function (D9) +- \textbf{3. Provenance under interrogation} -- a regulator questions a reported risk figure: trace it back through every transformation to the source systems (D6); BCBS~239 hardens this into $K(a)$ where banking data are involved + +*Elements:* +- leading question in bankblue italics; numbered list of three challenges, two lines each (deck-6 'Part III opens' format, lines 528-541) + +*Notes:* \footnotesize. Speaker notes carry the trimmed clauses from lines 573-575: office-hour load with Monday-morning and month-start peaks; an hour of downtime is an annoyance, not a loss event (D5 Low); the warehouse bill as the dominant run cost (D10 High); TB--PB dimensionally modelled, Kimball's star schema as the reference; change rate high at report level, moderate in the core model (D7 Medium) -- all of which sit in the profile table's rows. The phrase 'integration product over C1--C5' is the class's identity -- say it twice. + +#### Frame 11: C7 -- the binding scenarios + +*Kind:* content -- *Source:* §25.1 scenarios and K(C7) (part3_application_classes.tex 578-584) -- *Minutes:* 3 + +- \textbf{S1 (dashboard latency).} A controller opens the standard management dashboard on Monday morning; it renders \textbf{in under 5 seconds}, ad-hoc analytical queries in seconds to minutes. \textcolor{codegray}{(The D1/D3 scenario in the class's OLAP reading.)} +- \textbf{S2 (refresh contract).} The nightly ELT run executes; all marts are refreshed \textbf{within the refresh window, atomically visible, refresh-window adherence tracked as a fitness function}. \textcolor{codegray}{(The D4/D9 scenario.)} +- \textbf{S3 (lineage on demand).} A regulator or auditor questions a reported risk figure; the platform traces it \textbf{back through every transformation to the source systems, on demand}. \textcolor{codegray}{(The D6 scenario, hardened into $K(a)$ for banks.)} +- $K(\text{C7})$: BCBS~239 for banks (risk reporting: accuracy, completeness, timeliness, demonstrable lineage); the GDPR (purpose limitation, anonymisation in analyses); sector-specific reporting duties +- \textbf{Knock-out reading:} a pipeline whose transformations are not versioned and traceable cannot serve regulated reporting -- \emph{lineage is a structural property; retrofitting it is a rebuild} + +*Elements:* +- three-scenario itemize with bold response measures; K paragraph below (deck-6 'C10 -- the binding scenarios' format, lines 543-553) + +*Notes:* Contrast S2 with C6's S2: both are 'consistency as of' contracts -- the definition of the third semantics at work. + +#### Frame 12: C7 -- requirements profile (column C7) + +*Kind:* table -- *Source:* §25.2 tab:req-c7 (part3_application_classes.tex 590-616) -- *Minutes:* 4 + +- D1 Read scalability | \textbf{H} | heavy OLAP scans by few users, delegated to the warehouse engine (S1; note 7) +- D2 Write scal.\ \& elasticity | L | writes are bundled into the nightly ELT window +- D3 Latency | M | dashboards in under 5\,s; ad-hoc queries in seconds to minutes +- D4 Consistency \& integrity | M | freshness by refresh contract -- ``consistent as of yesterday 24:00'' (S2; note 10) +- D5 Availability \& isolation | L | a dashboard down for an hour is an annoyance, not a loss event +- D6 Security \& auditability | M | lineage and purpose limitation; BCBS~239 hardens them into $K(a)$ where banking data flow (S3) +- D7 Evolvability | M | report-level churn is high; the core dimensional model moves slowly +- D8 Simplicity \& TTM | M | thin serving keeps the estate simple; the pipeline carries the complexity +- D9 Testability \& deployability | M | refresh-window adherence is tracked as a fitness function (S2) +- D10 Operating cost | \textbf{H} | warehouse compute is the bill; cost discipline is the operative FinOps concern +- D11 Team scaling | L | a data team, not a fleet of feature teams +- D12 AI integrability | M | text-to-SQL docks onto the governed semantic layer, not onto raw tables +- Shape $S(a)$: batch $+$ thin serving | Constraints $K(a)$: BCBS 239 lineage (banks) + +*Elements:* +- 12-row requirements-profile table (scriptsize, arraystretch 0.8) from tab:req-c7 lines 596-614; Highs bold; Shape/Constraints rows (deck-6 profile format, lines 555-582) + +*Notes:* Read aloud only the two Highs (D1 in the note-7 reading, D10) and the footnoted D4 cell; D5 Low, D10 High and the D7 remark trimmed from the intro frame live here. Ask: why is D6 only M when S3 is statutory? Answer from the table: it is hardened into K(a) for banks -- knock-out, not weight. + +#### Frame 13: C7 -- what real systems chose, and why + +*Kind:* case -- *Source:* §25.3 (part3_application_classes.tex 618-622) -- *Minutes:* 4 + +- \textbf{Documented modern form: a batch/ELT pipeline in front of a thin serving layer} -- sources $\to$ orchestrated DAGs (\textbf{Apache Airflow}: scheduler, executor, workers, metadata database; DAGs as code) $\to$ warehouse $\to$ BI frontend +- The ``modern data stack'' is architecturally \textbf{a layered application over a batch pipeline}: the PF column serves the refresh contract and lineage by construction (note 10, D6); the L column serves the thin tier because it \emph{delegates} the D1-High scans to the warehouse and keeps its D8/D10 virtues +- \textbf{Apache Superset} (Python/Flask, originating at Airbnb): deliberately a \emph{thin} visualisation layer with no data storage of its own, connecting directly to SQL engines; \textbf{Metabase} ships as a single JAR -- a literal monolith, mirroring how little serving infrastructure the class needs. Both delegate scaling to the database: \emph{division of labour as an architectural principle} +- \textbf{Where the trade-off bites (A2): freshness} -- streaming ingestion (EDA) earns its broker-operations complexity only when the freshness contract measurably tightens below the batch window; tightening towards real time is \textbf{not a tuning exercise but a class change into C8 economics} + +*Elements:* +- four bullets \footnotesize; no tikz strip (the PF and L topologies were drawn in weeks 4 and 6); no verdict line -- it closes the key-concept box on the next frame + +*Notes:* The 'class change into C8' line prepares the C8 intro. Bullet 2 is capped at two lines. + +#### Frame 14: C7 -- AI lens and key concept + +*Kind:* ailens -- *Source:* §25.3 ailinse (part3_application_classes.tex 628-630), keypoint (624-626), verdict (636) -- *Minutes:* 3 + +- \textbf{AI Lens [Natural-language analytics (Axis B)]:} the visible frontier is the natural-language query -- ``show me revenue by region, last four quarters'' -- compiled by an LLM into SQL against the semantic layer +- The profile dictates the containment: the LLM \emph{proposes} a query; the semantic layer's schema and access-control contracts \emph{validate and execute} it -- \textbf{text-to-SQL against governed models, not raw tables}, so that lineage (S3) and purpose limitation survive the convenience +- Failure mode to design against: \textbf{silent plausibility} -- a syntactically valid, semantically wrong query returns confident nonsense; the eval harness of Part V -- golden question/answer sets over a \emph{frozen} warehouse state -- is the class-appropriate test instrument, and note 10's refresh contract is what makes such golden sets stable +- \textbf{Key concept:} C7 is an integration product over C1--C5 whose consistency semantics -- freshness by refresh contract -- is a \emph{designed} third option beside ACID and eventual. \textbf{The ADR to write is the freshness contract itself}; the fitness functions are refresh-window adherence and p95 dashboard latency; tightening the contract towards real time is a class change into C8 economics. \textbf{In one sentence:} PF (ELT) feeding a thin layered serving tier -- the canonical hybrid of the row (PF at $++$; L, MM, SL at $+$) -- with EDA ingestion secondary where the freshness contract demands it + +*Elements:* +- ailinse[Natural-language analytics (Axis B)] box (lines 628-630, condensed) above a keypoint box (lines 624-626, condensed) closing with the verdict (line 636) -- deck-6 'PF -- AI lens and key concept' format (line 254) with 'In one sentence' inside the keypoint (line 636) + +*Notes:* Both boxes at \footnotesize; the AI lens takes three short bullets at most. + +#### Frame 15: Closing the loop: C6 and C7 inside your C10 project + +*Kind:* content -- *Source:* §24.3 projektbox (part3_application_classes.tex 558-560); §25.3 projektbox (632-634); deck 6 'C10 -- your project as an inheritance diagram' (lines 629-640) -- *Minutes:* 3 + +- Week 6's inheritance diagram: C10 inherits C6, C7 and C3 -- today the two batch parents are taught +- \textbf{Left -- the C6 subsystems (ingestion: chunking, embedding, indexing; the eval pipeline):} versioned inputs, idempotent stages, deterministic reruns, golden datasets +- Left: note 14 is the bridge -- for batch pipelines, \emph{reproducibility is the operative meaning of testability} +- Left: when your eval scores change, prove whether the \textbf{model, the prompt, the data or the pipeline} changed -- that proof is a C6 property +- \textbf{Right -- the C7 subsystem:} portfolio analytics, exposure aggregation, report generation over the deterministic data store +- Right: its refresh contract -- ``\textbf{analysis as of last completed ingestion}'' +- Right: it bounds what the advisory layer may claim -- \emph{an answer must never cite data fresher than the index actually is} +- \textbf{Key concept:} the freshness contract appears twice in your measurement contract -- as a pipeline fitness function (C7 discipline) and as a grounding rule for generated answers (C10 discipline) + +*Elements:* +- one-line lead; projektbox with two columns (0.48/0.48), three one-to-two-line bullets each (C6 column from lines 558-560, C7 column from 632-634); one keypoint line below -- deck-6 mirror-pair format (line 603) with short column bullets + +*Notes:* This frame owns the substance of both projektboxes (the C6 key-concept frame only pointed here; the exercise frame keeps a one-line 'applied' bullet). 'What remains genuinely new' is left to observation 5 later today, which states it. Columns must not exceed three short bullets each. + +### Section: C8 -- Real-Time / IoT Streaming + +#### Frame 16: C8 -- Real-time / IoT streaming + +*Kind:* content -- *Source:* §26 intro and 26.1 (part3_application_classes.tex 641-650) -- *Minutes:* 4 + +- \emph{\textcolor{bankblue}{The sensors never stop: what ingests the world at the world's own rate, indefinitely -- and stays exactly right when a node dies mid-window?}} +- The class: systems that process continuously arriving event data -- sensor telemetry, clickstreams, vehicle positions, market data. Defining property: data are produced by the world at the world's own rate and \textbf{lose value quickly}; the system must sustain ingest at the production rate \emph{indefinitely}, master backpressure, and guarantee state correctness across failures +- \textbf{1. The sheer, unending inflow} -- ingest around the clock with bounded consumer lag and mastered backpressure $\to$ D2 (the \emph{inversion} of C2's read-heavy profile); 24/7 without pause $\to$ D5 (the world does not stop producing while a node recovers); value decay $\to$ D3 +- \textbf{2. The genuinely hard one: declared correctness semantics under failure} -- event time vs.\ processing time, windowing, watermarks (the Dataflow model); exactly-once state via checkpointing -- bought with machinery and \emph{permanent operational competence}: D4 in its stream reading (note 11), D8 Low (nobody chooses streaming for its ease) +- \textbf{3. Longevity of the plumbing} -- topologies change moderately but \textbf{schema evolution is a permanent concern} (D7 Medium); the largest data volume of all classes (append-only logs), retention often TTL-bounded, infrastructure long-lived even where the data are not + +*Elements:* +- leading question in bankblue italics; numbered list of three challenges (deck-6 'Part III opens' format, lines 528-541) + +*Notes:* \footnotesize; challenges 1 and 2 trimmed to two lines each. The magnitudes (LinkedIn, Uber) are deferred to the next frame; 'an anomaly alert is worth something within milliseconds to seconds, and little after' goes to the speaker notes. + +#### Frame 17: C8 -- the verified magnitudes + +*Kind:* table -- *Source:* §26.1 first challenge (part3_application_classes.tex 648-649); recap of deck 5 examplebox 'Kafka at LinkedIn; the Uber real-time stack' (AISE502_Vorlesung_5_Folien.tex 423-424) -- *Minutes:* 1 + +- \textit{Seen in week 5 from the supply side -- the existence proof for EDA D1/D2 $= ++$; today the same numbers as the demand-side D2 reading of C8} +- \textbf{LinkedIn} (Kafka's birthplace) | more than \textbf{seven trillion} Kafka messages per day | \textbf{new today:} roughly 100 clusters; over 4{,}000 brokers; about 100{,}000 topics; seven million partitions +- \textbf{Uber} | \textbf{trillions of messages and petabytes per day} | integrated real-time stack: Kafka (transport), Flink (stream processing), Pinot (OLAP serving) -- documented in a SIGMOD paper +- Read: D2 in the \emph{ingest} reading -- around the clock, bounded consumer lag, mastered backpressure; D5 because it never pauses; D3 because value decays + +*Elements:* +- recap marker line in italics; two-row table (footnotesize): System | Scale | Structure, from line 648; one reading line from line 649 + +*Notes:* Recap frame, one minute: only the cluster/broker/topic/partition breakdown is new. Pinot returns on the 'what real systems chose' frame as the OLAP sink. + +#### Frame 18: C8 -- the binding scenarios + +*Kind:* content -- *Source:* §26.1 scenarios and K(C8) (part3_application_classes.tex 652-658) -- *Minutes:* 4 + +- \textbf{S1 (sustained ingest).} Sensors emit at full production rate around the clock; the platform ingests and processes with \textbf{consumer lag bounded and no data loss, indefinitely}. \textcolor{codegray}{(The D2/D5 scenario.)} +- \textbf{S2 (exactly-once state).} A processing node fails mid-window under load; the system recovers with \textbf{state restored to exactly-once semantics via checkpointing, zero duplicated or lost aggregate updates}. \textcolor{codegray}{(The D4 scenario in its note-11 reading.)} +- \textbf{S3 (end-to-end latency).} An anomalous reading arrives; the alert fires \textbf{within milliseconds to a few seconds end-to-end, per-key ordering preserved}. \textcolor{codegray}{(The D3 scenario.)} +- $K(\text{C8})$ is \textbf{technical rather than statutory}: per-key ordering and exactly-once semantics \emph{where declared} are contractual knock-outs -- a billing stream that double-counts under failure is not ``mostly correct'', it is wrong; GDPR adds purpose limitation and retention duties where streams carry personal data (vehicle telemetry, wearables) +- \textbf{The pragmatic industry norm} -- at-least-once delivery plus idempotent consumers -- is legitimate exactly where the scenario says so; the decision is taken \textbf{per stream, per scenario, never platform-wide} + +*Elements:* +- three-scenario itemize; K paragraph; last bullet in plain bold (deck-6 'C10 -- the binding scenarios' format, lines 543-553) + +*Notes:* The 'per stream, per scenario' rule is the class's ADR discipline -- link to the measurement contract (Lecture 7). + +#### Frame 19: C8 -- requirements profile (column C8) + +*Kind:* table -- *Source:* §26.2 tab:req-c8 (part3_application_classes.tex 664-690) -- *Minutes:* 4 + +- D1 Read scalability | M | consumers read the log at their own pace; serving is delegated to OLAP sinks +- D2 Write scal.\ \& elasticity | \textbf{H} | ingest at the world's production rate, indefinitely, with backpressure mastered (S1) +- D3 Latency | \textbf{H} | alerts fire within milliseconds to seconds, end to end (S3) +- D4 Consistency \& integrity | M | stream semantics: exactly-once state, event-time windows, watermarks (S2; note 11) +- D5 Availability \& isolation | \textbf{H} | the world does not pause when a node fails; recovery must preserve state +- D6 Security \& auditability | L | low relative to the ledger classes; GDPR applies where streams carry personal data +- D7 Evolvability | M | topologies change moderately; schema evolution is the permanent concern +- D8 Simplicity \& TTM | L | nobody chooses this class for its simplicity +- D9 Testability \& deployability | M | correctness under failure is verified by chaos experiments, not unit suites alone +- D10 Operating cost | M | broker fleets cost, but the class's economics absorb them +- D11 Team scaling | M | platform and stream teams coordinate around shared topics +- D12 AI integrability | M | models score events in the stream as checkpointed operators +- Shape $S(a)$: continuous stream | Constraints $K(a)$: per-key ordering; exactly-once where stated + +*Elements:* +- 12-row requirements-profile table (scriptsize, arraystretch 0.8) from tab:req-c8 lines 670-688; Highs bold (deck-6 profile format, lines 555-582) + +*Notes:* Read aloud the three Highs (D2, D3, D5) -- the two that eliminate every single-quantum interactive pattern at the shape gate plus latency -- and the footnoted D4 cell. Note D8 = L and D6 = L as the two 'licences' of this column. + +#### Frame 20: C8 -- what real systems chose, and why + +*Kind:* case -- *Source:* §26.3 (part3_application_classes.tex 692-696) -- *Minutes:* 4 + +- \textbf{Documented form: EDA plus pipes-and-filters over a durable log} -- producers $\to$ Kafka (durable, partitioned, replayable) $\to$ stream processors (Flink) $\to$ sinks (OLAP, alerting, data lake) +- The EDA column is this class's mirror: a durable, partitioned, replayable log with decoupled producers and consumers serves \textbf{D2 and D5 at $++$} -- the two demands that eliminate every single-quantum interactive pattern at the shape gate; the streaming incarnation of PF supplies the processing layer whose \textbf{checkpointing answers S2} +- \textbf{Netflix}: the consumer-scale EDA reference -- event-driven telemetry pipelines, resilience institutionalised through \textbf{chaos engineering}: chaos experiments are exactly how this class tests its D4/D5 claims +- \textbf{Counter-lessons from this class's neighbourhood, both already met} (Segment: week 5; Prime Video: week 6 and the C6 case today) -- the shared A2 pattern is read in observation 3 later today + +*Elements:* +- four bullets \footnotesize; no tikz strip (week 5 already drew the EDA topology); no verdict line -- it closes the key-concept box on the next frame + +*Notes:* Speaker notes carry the open-source references from line 696 (Apache Kafka, Apache Flink, MQTT brokers Mosquitto/EMQX at the IoT edge, Apache Pinot/Druid for real-time OLAP serving) and the Segment/Prime Video details (140 per-destination microservices, the 2018 retreat to a monolith with a central queue; the serverless orchestration consolidated into one process) -- do not retell on the slide. The A2 sentence ('both cut one coherent dataflow along technical rather than domain seams') is said once, on the observation-3 frame. + +#### Frame 21: C8 -- AI lens and key concept + +*Kind:* ailens -- *Source:* §26.3 ailinse (part3_application_classes.tex 702-704), keypoint (698-700), verdict (706) -- *Minutes:* 3 + +- \textbf{AI Lens [Online inference and drift on streams (Axis B)]:} C8 is where ML meets its hardest operational constraint -- models score events \emph{in the stream} (fraud, anomaly, predictive maintenance) at \textbf{millisecond budgets}, which rules out per-event LLM calls entirely and demands pre-trained, locally served models +- The stream is simultaneously the \textbf{monitoring instrument}: input-distribution statistics computed in the pipeline detect data and concept drift; production-readiness rubrics such as the ML Test Score assume exactly this telemetry +- Architecturally, the model is \textbf{one more stateful stream operator} -- checkpointed, versioned, replayable like any other -- so that S2's exactly-once discipline extends to inference results +- \textbf{Key concept:} C8 must keep pace with the production rate of the world -- indefinitely. Its genuinely hard requirement is \emph{not throughput} but \textbf{declared correctness semantics under failure}: exactly-once state and event-time correctness are bought with checkpointing machinery and permanent operational competence, so the pragmatic norm is at-least-once plus idempotence -- decided per stream, per scenario, and recorded as such. \textbf{In one sentence:} EDA over a durable log with streaming PF as the processing layer -- the documented Uber stack (EDA at $++$; PF and MS at $+$) -- microservice processors secondary where team ownership demands it + +*Elements:* +- ailinse[Online inference and drift on streams (Axis B)] (lines 702-704, condensed) above keypoint (698-700, condensed) closing with the verdict (line 706) -- 'In one sentence' inside the keypoint as in deck 6 (line 636) + +*Notes:* Contrast with C7's AI lens: C7 docks an LLM behind a semantic layer at seconds; C8 forbids LLM calls per event -- the class profile decides the AI integration, not the other way round. + +### Section: C9 -- Collaboration / Messaging + +#### Frame 22: C9 -- Collaboration / messaging + +*Kind:* content -- *Source:* §27 intro and 27.1 (part3_application_classes.tex 711-720) -- *Minutes:* 4 + +- \emph{\textcolor{bankblue}{Five million people are connected at this moment, and every message must reach its channel within half a second: what holds the connections?}} +- The class: chat, team-collaboration and messaging applications -- a resource profile classical request/response never modelled: the system holds \textbf{millions of long-lived, stateful connections} (WebSockets) and pushes every message to all channel members immediately; latency must feel instantaneous; ordering \textbf{causal per channel} -- global ordering unnecessary, a deliberate weakening that buys scalability (note 12) +- \textbf{1. The connections themselves} -- the boot storm, not the message rate, threatens the core databases: the binding load is \textbf{connection fan-out and push} $\to$ D1/D2 Medium (note 9); the crux is D3/D5: a message must reach its channel in 100--500\,ms, and \emph{a disconnected messenger is a dead messenger} +- \textbf{2. The history tail} -- message histories are enormous and users scroll deep into them expecting low-tens-of-milliseconds reads: a D3 demand on the read path +- \textbf{3. Consistency relaxed by design} -- causal order per channel suffices (D4 Medium, note 12), the deliberate weakening that makes the fan-out scalable; feature churn high while the core protocol stays stable (D7 Medium); lifetimes exceed ten years + +*Elements:* +- leading question in bankblue italics; numbered list of three challenges, two lines each (deck-6 'Part III opens' format, lines 528-541) + +*Notes:* The Slack and Discord numbers, the 'one write and N push-deliveries' sentence and the load-wave sentence move to the next frame; here only the mechanism. + +#### Frame 23: C9 -- the connections and the history tail: two measured cases + +*Kind:* case -- *Source:* §27.1 (part3_application_classes.tex 718-720); Discord recap of deck 4 examplebox 'Storage migrations behind a seam -- Discord' (AISE502_Vorlesung_4_Folien.tex 670-671) -- *Minutes:* 3 + +- \textbf{Slack} | connection storms | more than \textbf{five million} simultaneous WebSocket sessions at peak; a morning peak rolling across a timezone means millions of clients connecting and booting within minutes | application-level edge cache \textbf{Flannel} at global points of presence: p99 latency for channel-membership queries from roughly \textbf{2{,}000\,ms to roughly 200\,ms}, shielding the core from the boot storms +- \textbf{Discord} (week 4: the same migration as the D7/D9 seam story; today the D3 demand on the storage tier) | the history tail | stores \textbf{trillions of messages}; users scroll deep expecting low-tens-of-milliseconds reads | storage migrations MongoDB $\to$ Cassandra $\to$ ScyllaDB behind Rust data services performing request coalescing: p99 read latency from \textbf{40--125\,ms to roughly 15\,ms} +- Reading: every message is one write and $N$ push-deliveries; load arrives as office-hour waves travelling with the timezones (Slack) or as evening peaks (Discord) -- Slack is the D5 scenario in the class's \emph{connection} reading (note 9), Discord the D3 demand on the \emph{storage} tier: two tails, two tiers, one class + +*Elements:* +- two-row table (footnotesize, p{} widths): System | Problem | Magnitude | Measure and result -- from lines 718-720, with a recap marker in the Discord cell; one reading line (lines 718-720) + +*Notes:* Discord's number becomes S3's response measure on the next frame; Slack's Flannel case is the scenario S2 was built for (S2's response measure is 'connection establishment and initial payload within budget while protecting the core databases'). The measured production number becomes the scenario's response measure, exactly as the closing keypoint of today claims. + +#### Frame 24: C9 -- the binding scenarios + +*Kind:* content -- *Source:* §27.1 scenarios and K(C9) (part3_application_classes.tex 722-728) -- *Minutes:* 3 + +- \textbf{S1 (delivery latency).} A user sends a channel message in normal global operation; all online channel members receive it \textbf{within 100--500\,ms, in causal order per channel}. \textcolor{codegray}{(The D3/D4 scenario.)} +- \textbf{S2 (connection fan-out).} Morning peak rolls across a timezone; millions of clients connect and boot with \textbf{connection establishment and initial payload within budget while protecting the core databases} -- the exact scenario Slack built its edge cache for. \textcolor{codegray}{(The D5 scenario in the connection reading, note 9.)} +- \textbf{S3 (history read tail).} A user scrolls deep into channel history; the store serves the read with \textbf{p99 read latency in the low tens of milliseconds} -- the target of Discord's migrations. \textcolor{codegray}{(A D3 demand on the storage tier.)} +- $K(\text{C9})$: the GDPR, with \textbf{data residency} as an explicit selling argument in the self-hosted segment; in enterprise deployments, \textbf{compliance archiving} (MiFID~II and FINRA record-keeping rules for trader communication) makes exportable, tamper-evident message archives a hard requirement +- \textbf{Knock-out reading:} for regulated enterprise customers, an architecture that cannot guarantee complete capture and retention of business communication is excluded -- precisely the market logic behind \textbf{Mattermost's single-binary, self-hostable design} + +*Elements:* +- three-scenario itemize; K paragraph (deck-6 'C10 -- the binding scenarios' format, lines 543-553) + +*Notes:* The Mattermost line sets up the 'four structures' frame and the Discussion. + +#### Frame 25: C9 -- requirements profile (column C9) + +*Kind:* table -- *Source:* §27.2 tab:req-c9 (part3_application_classes.tex 734-760) -- *Minutes:* 4 + +- D1 Read scalability | M | the binding load is connection fan-out and push, not raw reads (note 9) +- D2 Write scal.\ \& elasticity | M | one write becomes $N$ push deliveries -- amplification, not raw write rate (note 9) +- D3 Latency | \textbf{H} | delivery within 100--500\,ms or the conversation dies (S1, S3) +- D4 Consistency \& integrity | M | causal order per channel suffices; global order is deliberately waived (note 12) +- D5 Availability \& isolation | \textbf{H} | presence is the product: a disconnected messenger is a dead messenger (S2) +- D6 Security \& auditability | M | enterprise segments harden archiving duties into $K(a)$; consumer segments do not +- D7 Evolvability | M | feature churn is high while the core protocol stays stable +- D8 Simplicity \& TTM | M | a small install must stay operable -- the self-hosted market demands it +- D9 Testability \& deployability | M | staged rollouts across a heterogeneous client fleet +- D10 Operating cost | M | connection infrastructure costs scale with concurrency, not usage +- D11 Team scaling | M | platform teams for gateway and storage, feature teams above +- D12 AI integrability | L | assistants and summarisation decorate the edges; the fan-out core is untouched +- Shape $S(a)$: interactive, connection-stateful | Constraints $K(a)$: compliance archiving (MiFID/FINRA) in enterprise segments + +*Elements:* +- 12-row requirements-profile table (scriptsize, arraystretch 0.8) from tab:req-c9 lines 740-758; Highs bold (deck-6 profile format, lines 555-582) + +*Notes:* Read aloud only the two Highs (D3, D5), the footnoted D1/D2/D4 cells and the one L (D12): the flattest profile of the day -- which is exactly why scale and business model move its edges (next frame). + +#### Frame 26: C9 -- same domain, four structures + +*Kind:* table -- *Source:* §27.3 (part3_application_classes.tex 764-766) -- *Minutes:* 3 + +- \textbf{Mattermost} | \emph{one} Go binary with PostgreSQL -- the monolith as a \emph{feature} for self-hosting and compliance customers | MM column: its D8/D10 strengths are what the enterprise $K(a)$ segment buys; D5 weakness mitigated by replicated instances +- \textbf{Rocket.Chat} | Node.js and MongoDB | sits in the middle +- \textbf{Slack} | hybrid: PHP/Hack monolithic core for persistence and business logic, a specialised distributed real-time push layer in front | the push layer is publish/subscribe fan-out -- the EDA column owns this row: message delivery \emph{is} event fan-out with causal per-channel ordering; domain semantics and pattern coincide +- \textbf{Discord} | polyglot specialisation per quality attribute: BEAM for connection concurrency, Rust for tail latency | targeted microservices exactly where the D3 tail demands them +- \textbf{The trade-off (A2) is resolved by scale and business model, not by the domain:} below roughly $10^5$ concurrent connections a specialised push layer is premature optimisation -- \textbf{the measured concurrent-connection count is the tiebreaker} + +*Elements:* +- four-row table (scriptsize, p{} widths): System | Structure | Which column, and why -- from line 764; one tiebreaker line below (line 766) + +*Notes:* First of two C9 'what real systems chose' frames (restores the class rhythm: case frame + key-concept frame). Matrix/Synapse ('adds a federated counter-model', line 764) goes to the speaker notes -- mention it as the fifth structure. Keep the Slack row to two lines. + +#### Frame 27: C9 -- key concept + +*Kind:* keyconcept -- *Source:* §27.3 keypoint (part3_application_classes.tex 768-770) and verdict (776) -- *Minutes:* 2 + +- \textbf{Key concept:} C9's binding load is connection fan-out and push, not raw read/write rates -- a resource profile request/response never modelled. The same business domain spans Mattermost's single, deliberately monolithic binary and Discord's polyglot specialised cluster: \textbf{the profile's core is stable, but scale and business model move the weights at its edges} -- measured concurrent-connection count is the tiebreaker. \textbf{In one sentence:} a hybrid -- monolithic persistence and business core with a specialised event-driven push layer, Slack's documented shape (EDA at $++$ at the fan-out crux; MM and MS at $+$) -- with a modular monolith alone as secondary for the self-hosted segment + +*Elements:* +- keypoint box (lines 768-770, condensed) closing with the verdict (line 776) -- 'In one sentence' inside the keypoint as in deck 6 (line 636) + +*Notes:* Short frame; leads straight into the Discussion. 'Weights at the edges' is the sentence the Discussion debrief returns to. + +#### Frame 28: Discussion + +*Kind:* discussion -- *Source:* §27.3 thinkbox (part3_application_classes.tex 772-774) -- *Minutes:* 3 + +- Mattermost and Discord implement substantially the same user-visible functionality. Using the twelve dimensions: +- Which \emph{three} dimensions differ most strongly between the requirements profile of a \textbf{self-hosted compliance deployment (500 users, banking client)} and a \textbf{global consumer platform (150 million users)}? +- Would any weight flip from L to H? +- What does that imply for the claim that ``the application class determines the profile''? + +*Elements:* +- thinkbox with the three questions from lines 772-774 (deck 1/3/5 'Discussion' frame format: plain title, question inside the box) + +*Notes:* Buzz groups, 2 minutes, then collect. Anchor the debrief on the C9 table (D6 archiving into K(a), D8/D10 small install, D5/D3 tail at scale, D11) and on week 6's C1/C2 lesson: weights, not dimensions, define a class -- and here scale and business model move the weights at the edges while the core (D3/D5 High) stays. + +### Section: Stepping Back: Ten Profiles Side by Side + +#### Frame 29: Stepping back: ten profiles side by side -- three reading rules + +*Kind:* content -- *Source:* §29 intro (part3_application_classes.tex 853-858); D4/D7 observations read off tab:requirements (869-894, 904-908) -- *Minutes:* 3 + +- Ten times the same movement -- what no single section could deliver is the view \emph{across} the ten; that is what this section adds +- The consolidated table: $w_i(a)$, $S(a)$, $K(a)$ per class -- the \textbf{demand-side counterpart of the capability table} (week 6), one of the two inputs to the fit matrix of Part IV +- \textbf{Rule 1 -- read columns to see a class:} each column repeats the per-class table of its section cell for cell; every H is backed by a binding scenario with a response measure +- \textbf{Rule 2 -- read rows to see what a dimension discriminates:} D7 (evolvability) is High in six classes and Low in none -- long life is the norm, not the exception -- and Medium exactly in the four classes taught today; D12 is High only in C10, the definitional case +- \textbf{Rule 3 -- the seventeen footnotes are part of the table's semantics, not decoration:} testability as reproducibility in C6 (note 14), as eval pass rate in C10 (note 15), read scalability as OLAP scan capacity in C7 (note 7); the D4 row of C6--C9 carries the same letter M with four footnoted meanings (notes 8, 10, 11, 12) -- \emph{using the bare letter without its footnote produces wrong matches in Part IV} + +*Elements:* +- numbered reading rules, \footnotesize, in the deck-6 'Four reading rules -- and the table's status' format (line 469) + +*Notes:* Mirror the deck-6 capability-table frames explicitly: same movement, other operand. The two C6--C9 observations under Rules 2 and 3 (D7 Medium exactly in today's four classes; D4 = M with four footnoted meanings) are read off the table, not stated in the script -- present them as such. + +#### Frame 30: The consolidated requirements table (1/2): D1--D6 + +*Kind:* table -- *Source:* §29 tab:requirements rows D1--D6 (part3_application_classes.tex 864-880) -- *Minutes:* 4 + +- Header: Dimension | C1 core banking | C2 social/content | C3 back-office | C4 ERP | C5 e-commerce | C6 simulation/batch | C7 DSS/BI | C8 IoT streaming | C9 collab/messaging | C10 AI-native advisory +- D1 Read scalability | M | \textbf{H} | L | L | \textbf{H} | L | \textbf{H}$^{7}$ | M | M$^{9}$ | M +- D2 Write scal.\ \& elasticity | M | M$^{1}$ | L | L | \textbf{H} | \textbf{H}$^{2}$ | L | \textbf{H} | M$^{9}$ | L +- D3 Latency | M$^{3}$ | \textbf{H} | M | M | \textbf{H} | L$^{4}$ | M | \textbf{H} | \textbf{H} | M$^{5}$ +- D4 Consistency \& integrity | \textbf{H} | L | \textbf{H} | \textbf{H} | M$^{6}$ | M$^{8}$ | M$^{10}$ | M$^{11}$ | M$^{12}$ | M$^{13}$ +- D5 Availability \& isolation | \textbf{H} | \textbf{H} | L | M | \textbf{H} | L | L | \textbf{H} | \textbf{H} | M +- D6 Security \& auditability | \textbf{H} | M | \textbf{H} | \textbf{H} | \textbf{H} | M | M | L | M | \textbf{H} +- Footer line: superscripts refer to the seventeen footnotes (see next frames) -- integral to the cell semantics + +*Elements:* +- 10-column table from lines 869-880: \scriptsize, \tabcolsep 2pt, p{2.6cm} label column + ten centred p{1.1cm} class columns, two-line \shortstack headers, Highs bold, superscripts via \textsuperscript -- the same column spec as (2/2) so the halves read as one table (deck-6 'The consolidated capability table' format, line 439) + +*Notes:* Width check: 2.6 cm + 10 x 1.1 cm + tabcolsep fits 16:9 at scriptsize. Walk the D4 row aloud: three H, one L, six footnoted M (notes 6, 8, 10, 11, 12, 13) -- the consistency-semantics axis of the class map. + +#### Frame 31: The consolidated requirements table (2/2): D7--D12 and $S(a)$ + +*Kind:* table -- *Source:* §29 tab:requirements rows D7--D12 and shape row (part3_application_classes.tex 881-889) -- *Minutes:* 3 + +- Header as on (1/2): C1 ... C10 +- D7 Evolvability | \textbf{H} | \textbf{H} | \textbf{H} | \textbf{H} | \textbf{H} | M | M | M | M | \textbf{H} +- D8 Simplicity \& TTM | L | M | \textbf{H} | M | M | M | M | L | M | M +- D9 Testability \& deployability | \textbf{H} | \textbf{H} | M | M | \textbf{H} | \textbf{H}$^{14}$ | M | M | M | \textbf{H}$^{15}$ +- D10 Operating cost | L | M | \textbf{H} | M | M | \textbf{H} | \textbf{H} | M | M | \textbf{H}$^{16}$ +- D11 Team scaling | M | \textbf{H} | L | M | M$^{17}$ | L | L | M | M | L +- D12 AI integrability | M | M | L | L | M | M | M | M | L | \textbf{H} +- Dominant workload shape $S(a)$ | interactive ($+$ batch edges) | interactive read-heavy | interactive | interactive ($+$ batch runs) | interactive, seasonal | scheduled batch | batch $+$ thin serving | continuous stream | interactive, connection-stateful | hybrid: interactive $+$ batch/async + +*Elements:* +- 10-column table continued with the identical column spec (\scriptsize, \tabcolsep 2pt, p{2.6cm} + ten centred p{1.1cm}, \shortstack headers); the $S(a)$ row rendered in \tiny so the phrases wrap within 1.1 cm -- six data rows leave the room + +*Notes:* Point at the D12 row: one H, the definitional case; and at D7: six H, no L, M exactly in C6--C9. + +#### Frame 32: Hard constraints $K(a)$ -- the knock-out row + +*Kind:* table -- *Source:* §29 tab:requirements K(a) row (part3_application_classes.tex 891-892); §24.1 (514) and §26.1 (658) for the reading line -- *Minutes:* 3 + +- C1 core banking: BCBS 239; FINMA 2023/1; DORA (EU 2022/2554); ACID booking core; 10+ yr retention +- C2 social/content: DSA; GDPR +- C3 back-office: retention law (e.g.\ OR 958\emph{f}); internal control systems; GDPR +- C4 ERP: GoBD/GeB\"uV; SOX; IFRS audit chains +- C5 e-commerce: PCI DSS v4.0 scope minimisation; PSD2/SCA +- C6 simulation/batch: model validation and backtesting (finance); deterministic seeds +- C7 DSS/BI: BCBS 239 lineage (banks) +- C8 IoT streaming: per-key ordering; exactly-once where stated +- C9 collab/messaging: compliance archiving (MiFID/FINRA) in enterprise segments +- C10 AI-native advisory: EU AI Act 2024/1689 (logging, oversight; potentially high-risk); GDPR +- Reading: $K(a)$ feeds stage 1 of the match (knock-out) together with the shape gate; C8's entry is \emph{technical rather than statutory}; C6's pairs a supervisory duty (Basel model validation and backtesting) with a technical one (deterministic seeds) + +*Elements:* +- two-column layout (C1--C5 left, C6--C10 right), \footnotesize, from the K(a) row line 892; closing reading line + +*Notes:* Five per column; the reading line paraphrases line 658 ('technical rather than statutory') and line 514 (Basel model validation, BCBS 239 lineage; deterministic seeds as a hard constraint). + +#### Frame 33: The seventeen footnotes are part of the semantics (1/2): notes 1--9 + +*Kind:* content -- *Source:* §29 tab:requirements footnotes 1-9 (part3_application_classes.tex 896-905) -- *Minutes:* 3 + +- $^{1}$ C2, D2 = M: raw write rate is modest (Twitter: ca.\ 6\,k tweet writes/s vs.\ ca.\ 300\,k timeline reads/s); fan-out amplification is real but absorbed by the fan-out subsystem, not the write path +- $^{2}$ C6, D2 = H: throughput as makespan and batch-window compute bursts, not requests/s +- $^{3}$ C1, D3 = M: class-internal spread of orders of magnitude -- batch clearing hours, instant payments $<10$\,s end-to-end, card authorisation 1--2\,s, trading microseconds +- $^{4}$ C6, D3 = L: per-request latency irrelevant; makespan and batch window are the measures +- $^{5}$ C10, D3 = M: users accept seconds-to-minutes for advisory answers; the High-grade concern is cost per request, not speed +- $^{6}$ C5, D4 = M: the class-defining hybrid -- catalogue eventual, checkout/payment strictly ACID +- $^{7}$ C7, D1 = H: ``read'' means heavy OLAP scans by few users; serving typically delegated to the warehouse +- $^{8}$ C6, D4 = M: bit-level reproducibility (seeds, versioned inputs) -- a scientific and, for risk models, regulatory duty +- $^{9}$ C9, D1/D2 = M: connection fan-out and push, not raw read/write rates, are the binding load (Slack: $>5$\,M concurrent WebSockets); hence M with the crux carried by D3/D5 + +*Elements:* +- nine-item list, \scriptsize, each note prefixed by its cell (class, dimension, letter) -- from lines 897-905 + +*Notes:* Nine lines at \scriptsize fit; the cell prefix (e.g. 'C6, D2 = H') is the deck's navigation aid, derived from the table positions. + +#### Frame 34: The seventeen footnotes are part of the semantics (2/2): notes 10--17 and the rule + +*Kind:* keyconcept -- *Source:* §29 tab:requirements footnotes 10-17 (part3_application_classes.tex 906-913) and keypoint (860-862) -- *Minutes:* 3 + +- $^{10}$ C7, D4 = M: a third semantics beside ACID and eventual -- freshness by refresh contract (``as of yesterday 24:00'') +- $^{11}$ C8, D4 = M: stream semantics -- exactly-once state, event-time windows, watermarks +- $^{12}$ C9, D4 = M: causal order per channel suffices; global order unnecessary +- $^{13}$ C10, D4 = M: hybrid -- knowledge index eventual, transaction/audit path ACID +- $^{14}$ C6, D9 = H: reproducibility (golden datasets, versioned pipelines) is the operative meaning of testability +- $^{15}$ C10, D9 = H: evals are the operative meaning of testability (Part V) +- $^{16}$ C10, D10 = H: cost per \emph{request} (tokens, GPU) -- a run-cost class no classical profile contains +- $^{17}$ C5, D11 = M: organisation-size dependent -- the Shopify-vs-Amazon contrast +- \textbf{Key concept:} an H in the table is a \textbf{veto trigger} backed by a scenario with a response measure; an L is a \textbf{licence to not pay} for that dimension. The footnotes carry class-specific semantics that the letters alone cannot: \emph{whoever matches profiles by letters without footnotes has not read the table} + +*Elements:* +- eight-item list \scriptsize (lines 906-913) above the keypoint box (lines 860-862) + +*Notes:* The D4 row's footnoted M cells -- notes 6, 8 and 10--13 -- make the Rule-3 point again: one letter, six semantics. + +#### Frame 35: Reading rows: what discriminates -- the two questions to ask first + +*Kind:* table -- *Source:* §29.1 observation 1 (part3_application_classes.tex 918); §29 reading rule 2 (858); H positions counted from tab:requirements (869-889) -- *Minutes:* 3 + +- Dimension | High in | count +- D1 | C2, C5, C7 | 3 +- D2 | C5, C6, C8 | 3 +- D3 | C2, C5, C8, C9 | 4 +- D4 | C1, C3, C4 | 3 +- D5 | C1, C2, C5, C8, C9 | 5 +- D6 | C1, C3, C4, C5, C10 | 5 +- D7 | C1, C2, C3, C4, C5, C10 | 6 (Low in none) +- D8 | C3 | 1 +- D9 | C1, C2, C5, C6, C10 | 5 +- D10 | C3, C6, C7, C10 | 4 +- D11 | C2 | 1 +- D12 | C10 | 1 +- \textbf{Observation 1 -- the strongest discriminators are the read/write ratio (the D1/D2 rows) and the consistency semantics (the D4 row).} C1 (write-critical, strict ACID) and C2 (roughly 50:1 read-heavy, deliberately eventual) are mirror images across both at once -- the fastest diagnostic pair in the catalogue. \emph{When classifying an unknown system, ask these two questions first}: they eliminate more patterns via the shape gate and the D4 row than any other pair + +*Elements:* +- 12-row, 3-column table (scriptsize, arraystretch 0.8) derived by counting the H cells of tab:requirements, flagged on the slide as 'read off the table'; observation 1 as a three-line \footnotesize paragraph below + +*Notes:* The counts are a deck construction (see open_issues); the script states only the D7 and D12 facts (line 858, already on the reading-rules frame). Observation 1's C5/C6--C7 clause (hybrid; third semantics family) is left to the definition frame and the summary; the derived remark that D8 and D11 single out one class each (C3, C2) and D4 is High only in the three ACID classes goes to the speaker notes. + +#### Frame 36: Reading the catalogue as a whole (1/2): scale does not force microservices + +*Kind:* content -- *Source:* §29.1 observation 2 (part3_application_classes.tex 920-924) -- *Minutes:* 3 + +- \textbf{Observation 2 -- scale does not force microservices.} The documented monolith-at-scale cases span four classes \textcolor{codegray}{(all five cases: weeks 3--6; now read from the demand side)}: +- Instagram | global consumer platform | horizontally replicated Django monolith +- Stack Overflow | $\sim 1.3$ billion page views/month, $> 6{,}000$ requests/s | roughly nine on-premise web servers, monolithic .NET application +- Shopify | ca.\ 280 million requests/min at BFCM peak | pod-sharded modular Rails monolith +- LMAX | six million orders/s | one thread +- Stateless replication, sharding and mechanical sympathy scale monoliths far; what microservices primarily solve is an \emph{organisational} scaling problem -- deployments per developer as team count grows. \textbf{In profile terms: D1/D2 rarely force distribution; D11 = H is what does} + +*Elements:* +- heading bullet with visible recap marker in codegray; four-row table (\scriptsize): System | Documented scale | Structure -- from line 924; closing two-line paragraph ending on the bold line + +*Notes:* Monzo's 2,800 services ('viable only with extreme homogeneity and central migration automation', line 924) goes to the speaker notes -- week 5 taught the homogeneity condition. Do not retell the cases; they were the supply-side evidence in weeks 3--6. + +#### Frame 37: Reading the catalogue as a whole (2/2): rollbacks, regulation, inheritance + +*Kind:* content -- *Source:* §29.1 observations 3-5 (part3_application_classes.tex 926-930) -- *Minutes:* 3 + +- \textbf{3. The rollback case studies share one pattern.} Segment and Prime Video both cut \emph{one} coherent dataflow along technical rather than domain seams -- one service per integration destination, one function per processing step -- and the interaction costs (queues, orchestrator state transitions, storage round-trips, the test matrix) consumed the benefit. Granularity must follow the coupling structure of the domain. For the catalogue: \textbf{a class's workload shape is not merely a gate for pattern selection -- it also predicts where the expensive boundaries lie \emph{within} a pattern} +- \textbf{4. Regulation is a first-class architectural requirement.} $K(a)$ translates directly into structure: BCBS~239 and FINMA 2023/1 into immutable journals, lineage and resilience testing; DORA into incident-reporting and third-party risk machinery; PCI~DSS v4.0 into cardholder-data zoning and scope minimisation; the EU AI Act into logging and human-oversight duties for AI components. None can be bolted on late at reasonable cost -- \textbf{Booch-significant decisions}, which is exactly why they live in $K(a)$ as knock-outs rather than in the weights +- \textbf{5. The AI-native class inherits before it innovates.} C10 inherits the disciplines of C6/C7 (batch index and eval pipelines) and C3 (deterministic transactional services), and adds exactly \textbf{two} genuinely new elements: a cost model that is expensive per request rather than per user, and evals as the operative meaning of testability. \emph{Design instruction for the project in one sentence: solve the inherited profiles with the inherited, well-understood structures, and concentrate the architectural attention on the two novelties} + +*Elements:* +- three paragraph bullets, \footnotesize, numbered 3--5 to continue the previous frame + +*Notes:* Observation 3 is where the Segment/Prime Video A2 sentence is said once today (the C8 case frame only pointed here) and anticipates Lecture 10 (hybrids and evolution paths: Segment, Prime Video, Shopify) -- say so. Observation 5 is the 'closing the loop' frame restated by the script itself. + +#### Frame 38: The other operand is ready + +*Kind:* discussion -- *Source:* §29.1 keypoint (part3_application_classes.tex 932-934) and thinkbox (936-938) -- *Minutes:* 4 + +- \textbf{Key concept:} the ten requirements profiles are \textbf{derivable, not arbitrary}: every weight traces to binding scenarios with response measures, every constraint to a statute or a contract, every workload signature to documented production numbers. \textbf{The other operand is ready}: Part IV matches these profiles against the capability profiles of Part II cell by cell (the fit matrix), and every cell can be traced back to $R(a) \times C(p)$ rather than to fashion or taste +- \textbf{Discussion:} the catalogue contains ten classes -- why not nine, why not fourteen? +- Propose a candidate eleventh class (for example: computer games, embedded control, blockchain ledgers) and test it against the definition of an application class (a \emph{recurring} ASR bundle with typical response measures, a characteristic workload shape, a regulatory frame) +- Does its profile differ from all ten columns of the consolidated table on at least \textbf{two High weights}? If it does not differ, it is an instance, not a class + +*Elements:* +- keypoint box (lines 932-934, condensed) above a thinkbox (lines 936-938) -- deck-6 'Reading the catalogue as a whole' frame format (line 484) + +*Notes:* Run the Discussion as a 3-minute pair exercise with the two table frames still in reach (students need the columns to test 'two High weights'); one minute for collection. Close by pointing forward to Lecture 10's row-by-row cell rationales. + +### Section: Closing + +#### Frame 39: This week's exercise: the walking skeleton runs end-to-end (M3 closes) + +*Kind:* exercise -- *Source:* project_exercise.tex 355-466 (M3 taskbox, hintbox); semester plan week 9; §24.3 and §25.3 projektboxes (one-line pointer) -- *Minutes:* 3 + +- \textbf{Coaching session (1 lesson): finish the walking skeleton.} +- \textbf{Milestone check M3 (week 9):} the end-to-end thin slice runs -- \texttt{MarketDataService} delivers prices $\to$ a \emph{minimal} \texttt{ResearchAgent} produces \textbf{one validated \texttt{Insight}} $\to$ through the \textbf{stable API}; a placeholder UI calls it +- Checklist from the exercise sheet: keep the deterministic core \textbf{free of LLM calls} (the line that is graded); use a \textbf{snapshot} of market/news data so demo and grading are reproducible even if the live APIs misbehave; commit after the milestone; record decisions as ADRs as you go +- Today's lecture applied: your ingestion and eval pipelines are \textbf{C6}, your analytics are \textbf{C7} -- the skeleton should already show where an \texttt{Insight}'s freshness stamp comes from +- Next: weeks 10--11 (M4) -- \texttt{Performance}, \texttt{Risk}, \texttt{Optimization} services with exact tests against the reference vectors; resilience on all external calls + +*Elements:* +- projektbox with the milestone check and checklist (deck-6 'This week's exercise: the match' format, lines 645-658) + +*Notes:* Only the first three bullets are mandatory; the one-line 'today's lecture applied' bullet is the link back to the 'Closing the loop' frame, which owns the projektbox substance. + +#### Frame 40: Summary + +*Kind:* summary -- *Source:* keypoints §24-27, §29 (part3_application_classes.tex 554, 624, 698, 768, 860, 932) -- *Minutes:* 2 + +- 1. \textbf{C6} replaces the interactive vocabulary wholesale -- makespan, batch-window adherence, cost per simulation; correctness = bit-level reproducibility (Highs D2/D9/D10); with C7 it defines the \textbf{third consistency semantics}: ``as of this run'' and ``as of yesterday 24:00'' -- contracts with response measures +- 2. \textbf{C7}: an integration product over C1--C5; Highs D1 (OLAP scans, delegated) and D10 (the warehouse bill); the ADR to write is the freshness contract; tightening it towards real time is a class change into C8 +- 3. \textbf{C8}: keep pace with the world indefinitely; the hard requirement is declared correctness semantics under failure (Highs D2/D3/D5); at-least-once $+$ idempotence decided per stream, per scenario +- 4. \textbf{C9}: the binding load is connection fan-out and push (Highs D3/D5); same domain, four structures -- the measured concurrent-connection count is the tiebreaker +- 5. \textbf{Five observations}: read/write ratio and consistency semantics discriminate most; scale does not force microservices (D11 = H does); rollbacks cut dataflows along technical seams; regulation lives in $K(a)$; C10 inherits before it innovates +- 6. \textbf{The consolidated table}: an H is a veto trigger backed by a scenario, an L a licence not to pay; the seventeen footnotes are part of the semantics -- \textbf{the other operand is ready}: $R(a) \times C(p)$, every cell traceable, none to fashion or taste + +*Elements:* +- enumerate \footnotesize, itemsep 2pt, six points of at most two lines (deck-6 'Summary' format, line 660) + +*Notes:* Six points (~13 lines): C6 and the third semantics merged; the table and 'the other operand is ready' merged. + +#### Frame 41: Next week + +*Kind:* nextweek -- *Source:* semester plan week 10; brief 'Next lecture' line -- *Minutes:* 1 + +- Left: \textbf{Lecture 10 -- Part IV continued: hybrids, evolution paths, the eight-step procedure} +- hybrids and evolution paths: Segment, Prime Video, Shopify +- the eight-step decision procedure with the worked course-project run (ADR-007) +- the cell rationales of the matrix, row by row +- Right, Reading: this week -- Part III, Sections 24--27, 29; ahead -- Part IV, Sections 33, 35--36 +- Right, Exercise / deliverable: coaching; deterministic services (\texttt{Performance}, \texttt{Risk}, \texttt{Optimization}) with exact tests against the reference vectors (M4 begins) + +*Elements:* +- two columns 0.55/0.42 (deck-6 'Next week' format, lines 673ff) + +*Notes:* Verbatim in substance from the brief's 'Next lecture' line. + +#### Frame 42: Closing slide + +*Kind:* content -- *Source:* deck skeleton -- *Minutes:* 0 + +- \FHGRClosingPage -- Thank you! / Dr.\ Florian Herzog / Fachhochschule Graub\"unden, Chur / AISE502 -- AI in Software Engineering II + +*Elements:* +- FHGR closing page as in deck 6 (\FHGRClosingPage at line 703) + +*Notes:* Unchanged from deck 6. + +## Exercise frame: This week's exercise: the walking skeleton runs end-to-end (M3 closes) + +- Coaching session (1 lesson): finish the walking skeleton +- Milestone check M3 (week 9): the end-to-end thin slice runs -- MarketDataService delivers prices -> a minimal ResearchAgent produces one validated Insight -> through the stable API; a placeholder UI calls it +- Checklist from the exercise sheet: keep the deterministic core free of LLM calls (the line that is graded); use a snapshot of market/news data so demo and grading are reproducible; commit after the milestone; record decisions as ADRs as you go +- Today's lecture applied: ingestion and eval pipelines are C6, analytics are C7 -- the skeleton should already show where an Insight's freshness stamp comes from +- Next: weeks 10--11 (M4) -- Performance, Risk, Optimization services with exact tests against the reference vectors; resilience on all external calls + +## Summary frame + +1. C6 replaces the interactive vocabulary wholesale -- makespan, batch-window adherence, cost per simulation; correctness = bit-level reproducibility (Highs D2/D9/D10); with C7 it defines the third consistency semantics: 'as of this run' and 'as of yesterday 24:00' -- contracts with response measures +2. C7: an integration product over C1--C5; Highs D1 (OLAP scans, delegated) and D10 (the warehouse bill); the ADR to write is the freshness contract; tightening it towards real time is a class change into C8 +3. C8: keep pace with the world indefinitely; the hard requirement is declared correctness semantics under failure (Highs D2/D3/D5); at-least-once + idempotence decided per stream, per scenario +4. C9: the binding load is connection fan-out and push (Highs D3/D5); same domain, four structures -- the measured concurrent-connection count is the tiebreaker +5. Five observations: read/write ratio and consistency semantics discriminate most; scale does not force microservices (D11 = H does); rollbacks cut dataflows along technical seams; regulation lives in K(a); C10 inherits before it innovates +6. The consolidated table: an H is a veto trigger backed by a scenario, an L a licence not to pay; the seventeen footnotes are part of the semantics -- the other operand is ready: R(a) x C(p), every cell traceable, none to fashion or taste + +## Next-week frame + +**Lecture 10 (week 10, 3 lessons) -- Part IV continued: hybrids and evolution paths (Segment, Prime Video, Shopify); the eight-step decision procedure with the worked course-project run (ADR-007); the cell rationales of the matrix, row by row** + +- hybrids and evolution paths: Segment, Prime Video, Shopify +- the eight-step decision procedure with the worked course-project run (ADR-007) +- the cell rationales of the matrix, row by row + +*Reading:* +- this week: Part III, Sections 24--27, 29 +- ahead: Part IV, Sections 33, 35--36 + +*Exercise / deliverable:* +- coaching; deterministic services (Performance, Risk, Optimization) with exact tests against the reference vectors (M4 begins) + +## Script boxes, tables and figures used + +| Element | Script location | Used in frame | +|---|---|---| +| definitionbox[The third consistency semantics: reproducibility and refresh contracts] | §24.1, part3_application_classes.tex 510-512 | 6 -- The third consistency semantics: reproducibility and refresh contracts | +| table tab:req-c6 (requirements profile of C6) | §24.2, part3_application_classes.tex 520-546 | 7 -- C6 -- requirements profile (column C6) | +| keypoint (C6 replaces the interactive vocabulary wholesale) | §24.3, part3_application_classes.tex 554-556 | 9 -- C6 -- key concept | +| projektbox (the course project inherits C6 wholesale: ingestion and eval pipelines) | §24.3, part3_application_classes.tex 558-560 | 15 -- Closing the loop: C6 and C7 inside your C10 project (substance); one-line pointers on 9 and 39 | +| table tab:req-c7 (requirements profile of C7) | §25.2, part3_application_classes.tex 590-616 | 12 -- C7 -- requirements profile (column C7) | +| keypoint (C7 is an integration product; the ADR to write is the freshness contract) | §25.3, part3_application_classes.tex 624-626 | 14 -- C7 -- AI lens and key concept | +| ailinse[Natural-language analytics (Axis B)] | §25.3, part3_application_classes.tex 628-630 | 14 -- C7 -- AI lens and key concept | +| projektbox (the Portfolio Intelligence Platform contains a C7 subsystem; freshness contract appears twice) | §25.3, part3_application_classes.tex 632-634 | 15 -- Closing the loop: C6 and C7 inside your C10 project (substance); one-line pointer on 39 | +| table tab:req-c8 (requirements profile of C8) | §26.2, part3_application_classes.tex 664-690 | 19 -- C8 -- requirements profile (column C8) | +| keypoint (C8 must keep pace with the production rate of the world) | §26.3, part3_application_classes.tex 698-700 | 21 -- C8 -- AI lens and key concept | +| ailinse[Online inference and drift on streams (Axis B)] | §26.3, part3_application_classes.tex 702-704 | 21 -- C8 -- AI lens and key concept | +| table tab:req-c9 (requirements profile of C9) | §27.2, part3_application_classes.tex 734-760 | 25 -- C9 -- requirements profile (column C9) | +| keypoint (C9's binding load is connection fan-out and push) | §27.3, part3_application_classes.tex 768-770 | 27 -- C9 -- key concept | +| thinkbox (Mattermost vs Discord: which three dimensions differ most) | §27.3, part3_application_classes.tex 772-774 | 28 -- Discussion | +| keypoint (an H is a veto trigger, an L a licence; footnotes carry the semantics) | §29, part3_application_classes.tex 860-862 | 34 -- The seventeen footnotes are part of the semantics (2/2) | +| sidewaystable tab:requirements (consolidated requirements table, 12 rows x 10 classes, S(a) row, K(a) row) | §29, part3_application_classes.tex 864-894 | 30 -- table (1/2) D1--D6; 31 -- table (2/2) D7--D12 and S(a); 32 -- K(a) knock-out row; 35 -- row counts; 29 -- D4/D7 observations under Rules 2 and 3 | +| 17 table footnotes of tab:requirements | §29, part3_application_classes.tex 896-913 | 33 -- footnotes 1--9; 34 -- footnotes 10--17 | +| keypoint (the ten requirements profiles are derivable, not arbitrary; the other operand is ready) | §29.1, part3_application_classes.tex 932-934 | 38 -- The other operand is ready | +| thinkbox (why ten classes -- propose an eleventh and test it) | §29.1, part3_application_classes.tex 936-938 | 38 -- The other operand is ready | + +## Script elements deliberately not used + +| Element | Script location | Reason | +|---|---|---| +| figure fig:classmap (tikz map of the ten classes by workload shape and consistency semantics) | §18.3, part3_application_classes.tex 65-105 | Taught in deck 8 (§18); the recap frame refers to it verbally (C6/C7 at the third semantics); no thumbnail -- the recap frame is at its six-bullet limit | +| table tab:req-c10, keypoint and projektbox of C10 (inheritance diagram; C10 stress-tests the method) | §28, part3_application_classes.tex 806-846 | Taught in full in deck 6; C10 appears today only as a column of the consolidated table and via the inheritance loop closed in frame 15 | + +## Open issues for the author + +- No deck-8 file exists in Folien/ (only AISE502_Vorlesung_1..6); the recap frame (3) is built from the task brief's description of deck 8 and the script's §18.3 -- verify wording and the C1--C5 verdicts against the actual deck 8 once it is typeset. The slide itself says 'last week (C1--C5)', never 'deck 8'. +- Frame 35 (reading rows): the per-row H counts and positions are derived by counting the cells of tab:requirements; the script itself states only 'D7 High in six classes and Low in none' and 'D12 High only in C10' (line 858). The counts are faithful to the table but are a deck construction -- flagged on the slide as 'read off the table'. +- Frame 29 (reading rules) now carries the two C6--C9 observations formerly on the dropped excerpt frame (D7 Medium in exactly the four classes taught today; D4 = M with four footnoted meanings, notes 8/10/11/12): both are read off the table, not stated in the script -- presented as such. +- The script provides no thinkbox for C6, C7 or C8 and no ailinse for C6 or C9; the deck therefore has Discussion frames only for C9 (§27) and §29, and AI-lens frames only for C7 and C8. If an AI lens for C6 is wanted, deck 6's PF AI lens ('Pipelines are where AI work naturally lives') is the closest script-backed material. +- No tikz strips: the C7 (Airflow -> warehouse -> BI) and C8 (producers -> Kafka -> Flink -> sinks) topologies stay textual on frames 13 and 20, since the PF, L and EDA topologies were drawn in decks 4-6; a builder wanting a figure must cut one bullet per frame. +- Minute budget: content frames sum to 125 with no slack. Reviewers disagreed on frame 38 (one asked +1, one asked -1); it stays at 4 minutes (3-minute pair exercise plus 1 minute collection). Frames 26/27 (the C9 split) are budgeted 3+2; if the lecture runs long, the C8 magnitudes recap (frame 17, 1 minute) and the C9 key-concept frame can be compressed. +- Density: the 10-column consolidated table (frames 30-31) uses one fixed spec for both halves (p{2.6cm} + ten centred p{1.1cm}, \tabcolsep 2pt, \shortstack headers, S(a) row in \tiny); the builder must confirm 'connection-stateful' wraps within 1.1 cm at \tiny. Frame 26's Matrix/Synapse row is in the speaker notes only (high-severity density fix); the coverage reviewer would have kept it as a one-line row -- restore it only if the four-row table leaves visible room. +- The 'in one sentence' verdict lines of §24--27 (lines 562, 636, 706, 776) quote fit-matrix ratings (PF $++$, EDA $++$, etc.) that belong to Part IV (deck 7); they are in the assigned passages and are rendered uniformly as the last sentence of each class's keypoint box (frames 9, 14, 21, 27) -- recall, not teach. +- Exercise frame: the exercise sheet's M3 box (project_exercise.tex 407-413) adds 'a placeholder UI that calls it', which the brief's milestone line omits; included from the sheet. The hintbox items used (deterministic core free of LLM calls; data snapshot; commit after milestone; ADRs) are from lines 452-464. +- Frame 15 (closing the inheritance loop) is the deck's synthesis of the two projektboxes with deck 6's inheritance-diagram frame; no new facts, but the 'freshness stamp on an Insight' phrasing on frame 39 is a didactic gloss on the C7 projektbox ('an answer must never cite data fresher than the index actually is'). +- Recap mentions C3 as taught last week per the brief; the C3 verdict wording is not repeated to avoid inventing deck-8 content. +- Frames 17, 20, 23 and 36 carry visible recap markers ('week 4/5/6', 'weeks 3--6') for cases taught earlier (LinkedIn/Uber, Segment/Prime Video, Discord, Instagram/Stack Overflow/Shopify/LMAX); the week numbers follow the deck files (deck 4 = Discord, deck 5 = Kafka/Uber and Segment, deck 6 = Prime Video) and should be re-checked once decks 7-8 are typeset. + +--- + +# Lecture 10: The Fit II -- Hybrids, Evolution Paths, and the Decision Procedure + +- **Week:** 10 -- **Lessons:** 3 -- **Frames:** 44 +- **Title-slide script line:** Script: Part IV, Sections 35--36 and 33 + +## Agenda + +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) + +## Recap: where we are + +- 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 + +## Frame overview + +| # | Section | Frame title | Kind | Script ref | Min | +|---|---|---|---|---|---| +| 1 | Title | AISE502: AI in Software Engineering II -- Lecture 10: The Fit II -- Hybrids, Evolution Paths, and the Decision Procedure | content | title slide; Script: Part IV, Sections 35--36 and 33 | 0 | +| 2 | Agenda | Agenda | agenda | deck skeleton; semester plan week 10 | 0 | +| 3 | Recap | Recap: where we are | recap | deck 6 summary and next-week frame; semester plan weeks 7--9; project sheet M2--M4 | 3 | +| 4 | Hybrids and Evolution Paths | Hybrids and evolution paths: four episodes you already know | content | §35 intro (part4_fit.tex 491-494) | 3 | +| 5 | Hybrids and Evolution Paths | Hybrids are the normal case -- and the unit of evaluation | keyconcept | §35.1 (part4_fit.tex 496-498) | 4 | +| 6 | Hybrids and Evolution Paths | Fit is a function of time -- Lehman's laws and MonolithFirst | content | §35.2 (part4_fit.tex 500-507) | 3 | +| 7 | Hybrids and Evolution Paths | Fit is a function of time -- Strangler Fig in both directions, and sacrificial architecture | content | §35.2 (part4_fit.tex 508-509) | 4 | +| 8 | Hybrids and Evolution Paths | The documented evolution paths -- a state diagram | diagram | §35.2, Figure fig:evolution (part4_fit.tex 514-540) | 4 | +| 9 | Hybrids and Evolution Paths | Maxim 5 -- buy options on tomorrow's profile | keyconcept | §35.2 keypoint (part4_fit.tex 542-544) | 3 | +| 10 | Hybrids and Evolution Paths | AI Lens: sacrificial architecture for AI-native components | ailens | §35.2 ailinse (part4_fit.tex 546-548) | 3 | +| 11 | The Decision Procedure | From a pre-filtered shortlist to a defensible decision | table | §36 intro and step titles (part4_fit.tex 553-567) | 3 | +| 12 | The Decision Procedure | Steps (i)--(iii): the demand side -- ASRs, scenarios, utility tree | content | §36 steps (i)-(iii) (part4_fit.tex 557-559) | 4 | +| 13 | The Decision Procedure | Steps (iv)--(v): pre-filter via the matrix, then ATAM-light | content | §36 steps (iv)-(v) (part4_fit.tex 560-561) | 4 | +| 14 | The Decision Procedure | Steps (vi)--(viii): record, contract, measure -- and keep the paths open | content | §36 steps (vi)-(viii) (part4_fit.tex 562-566) | 3 | +| 15 | The Decision Procedure | Note how much of this you have already done -- and Maxim 6 | keyconcept | §36 closing paragraph and keypoint (part4_fit.tex 569-573) | 2 | +| 16 | The Reference Run: ADR-007 | The reference run -- step (i): ASRs and classification | case | §36.1 examplebox steps (i)-(iv), part (i) (part4_fit.tex 578-579) | 3 | +| 17 | The Reference Run: ADR-007 | The reference run -- step (ii): the binding scenario, six parts and a number | case | §36.1 examplebox steps (i)-(iv), part (ii) (part4_fit.tex 581) | 3 | +| 18 | The Reference Run: ADR-007 | The reference run -- steps (iii) and (iv): utility tree and matrix shortlist | case | §36.1 examplebox steps (i)-(iv), parts (iii)-(iv) (part4_fit.tex 583-585) | 4 | +| 19 | The Reference Run: ADR-007 | The reference run -- step (v): ATAM-light, one sensitivity point, one tradeoff point | case | §36.1 examplebox steps (v)-(viii), part (v) (part4_fit.tex 588-589) | 4 | +| 20 | The Reference Run: ADR-007 | The reference run -- steps (vi)--(viii): ADR, contract, operation, declared evolution paths | case | §36.1 examplebox steps (v)-(viii), parts (vi)-(viii) and closing paragraph (part4_fit.tex 591-595, 598) | 3 | +| 21 | The Reference Run: ADR-007 | ADR-007 (1/3): context and decision drivers | content | §36.1 Listing lst:adr007 (part4_fit.tex 601-618) | 3 | +| 22 | The Reference Run: ADR-007 | ADR-007 (2/3): considered options and decision | content | §36.1 Listing lst:adr007 (part4_fit.tex 620-632) | 2 | +| 23 | The Reference Run: ADR-007 | ADR-007 (3/3): consequences and measurement contract | content | §36.1 Listing lst:adr007 (part4_fit.tex 634-647) | 3 | +| 24 | The Reference Run: ADR-007 | Discussion | discussion | deck-authored, derived from §36 steps (part4_fit.tex 557-566) and lst:adr007 (600-648); exercise sheet M2 (A2 = ADR + C4 + measurement contract) | 6 | +| 25 | The Ten Rows in Detail | The ten rows in detail -- how to read a row rationale | content | §33 intro (part4_fit.tex 167-171); §32 keypoint (part4_fit.tex 163-165) | 3 | +| 26 | The Ten Rows in Detail | The $7 \times 10$ grid, for reference | table | §32 Table tab:fitmatrix (part4_fit.tex 127-152) | 1 | +| 27 | The Ten Rows in Detail | C1 -- core banking: the canonical hybrid, ACID core and EDA edges | table | §33.1 Table tab:fit-c1 and verdict (part4_fit.tex 173-200) | 4 | +| 28 | The Ten Rows in Detail | C2 -- social media / content platform: the mirror image of C1 | table | §33.2 Table tab:fit-c2 and verdict (part4_fit.tex 202-229) | 4 | +| 29 | The Ten Rows in Detail | C3 -- back-office / workflow: day-one simplicity vs. multi-decade evolvability | table | §33.3 Table tab:fit-c3 and verdict (part4_fit.tex 231-258) | 3 | +| 30 | The Ten Rows in Detail | C4 -- ERP core: the strongest anti-fit in the grid | table | §33.4 Table tab:fit-c4 and verdict (part4_fit.tex 260-287) | 3 | +| 31 | The Ten Rows in Detail | C5 -- e-commerce: seasonal elasticity vs. checkout consistency | table | §33.5 Table tab:fit-c5 and verdict (part4_fit.tex 289-316) | 3 | +| 32 | The Ten Rows in Detail | C6 -- simulation / batch compute: a row decided at Stage 1 | table | §33.6 Table tab:fit-c6 and verdict (part4_fit.tex 318-345) | 3 | +| 33 | The Ten Rows in Detail | C7 -- BI analytics: a pipeline feeding a serving tier | table | §33.7 Table tab:fit-c7 and verdict (part4_fit.tex 347-374) | 3 | +| 34 | The Ten Rows in Detail | C8 -- real-time streaming: a log with stream processors | table | §33.8 Table tab:fit-c8 and verdict (part4_fit.tex 376-403) | 3 | +| 35 | The Ten Rows in Detail | C9 -- collaboration / messaging: a monolithic core with a specialised push layer | table | §33.9 Table tab:fit-c9 and verdict (part4_fit.tex 405-432) | 3 | +| 36 | The Ten Rows in Detail | C10 -- your class: the row extended to all seven candidates | table | §33.10 Table tab:fit-c10 (part4_fit.tex 434-448) | 4 | +| 37 | The Ten Rows in Detail | C10 -- the verdict: a designed hybrid, and the determinism boundary | keyconcept | §33.10 verdict (part4_fit.tex 450) | 3 | +| 38 | The Ten Rows in Detail | Ten rows, ten trade-offs (1/2): C1--C5 | table | §33.1-33.5 verdict paragraphs (part4_fit.tex 199, 228, 257, 286, 315) | 3 | +| 39 | The Ten Rows in Detail | Ten rows, ten trade-offs (2/2): C6--C10 | table | §33.6-33.10 verdict paragraphs (part4_fit.tex 344, 373, 402, 431, 450) | 3 | +| 40 | The Ten Rows in Detail | The recurring resolution: consistent core, asynchronous edges | keyconcept | §33 closing keypoint (part4_fit.tex 452-454) | 3 | +| 41 | Closing | This week's exercise: the deterministic core (M4) | exercise | project_exercise.tex M4 taskbox and hint box (lines 424-429, 448-461); semester plan week 10 | 0 | +| 42 | Closing | Summary | summary | §35, §36, §33 | 0 | +| 43 | Closing | Next week | nextweek | semester plan week 11; task brief 'Next lecture' | 0 | +| 44 | Closing | Closing slide | content | deck skeleton | 0 | + +## Frames in detail + +### Section: Title + +#### Frame 1: AISE502: AI in Software Engineering II -- Lecture 10: The Fit II -- Hybrids, Evolution Paths, and the Decision Procedure + +*Kind:* content -- *Source:* title slide; Script: Part IV, Sections 35--36 and 33 -- *Minutes:* 0 + +- \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 + +*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. + +### Section: Agenda + +#### Frame 2: Agenda + +*Kind:* agenda -- *Source:* deck skeleton; semester plan week 10 -- *Minutes:* 0 + +- 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 + +*Notes:* Order follows the semester plan row for week 10: hybrids/evolution, eight-step procedure with ADR-007, row rationales deepened. + +### Section: Recap + +#### Frame 3: Recap: where we are + +*Kind:* recap -- *Source:* deck 6 summary and next-week frame; semester plan weeks 7--9; project sheet M2--M4 -- *Minutes:* 3 + +- 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 + +*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. + +### Section: Hybrids and Evolution Paths + +#### Frame 4: Hybrids and evolution paths: four episodes you already know + +*Kind:* content -- *Source:* §35 intro (part4_fit.tex 491-494) -- *Minutes:* 3 + +- 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 + +*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. + +#### Frame 5: Hybrids are the normal case -- and the unit of evaluation + +*Kind:* keyconcept -- *Source:* §35.1 (part4_fit.tex 496-498) -- *Minutes:* 4 + +- 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 + +*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. + +#### Frame 6: Fit is a function of time -- Lehman's laws and MonolithFirst + +*Kind:* content -- *Source:* §35.2 (part4_fit.tex 500-507) -- *Minutes:* 3 + +- 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 + +*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. + +#### Frame 7: Fit is a function of time -- Strangler Fig in both directions, and sacrificial architecture + +*Kind:* content -- *Source:* §35.2 (part4_fit.tex 508-509) -- *Minutes:* 4 + +- \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 + +*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. + +#### Frame 8: The documented evolution paths -- a state diagram + +*Kind:* diagram -- *Source:* §35.2, Figure fig:evolution (part4_fit.tex 514-540) -- *Minutes:* 4 + +- 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 + +*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. + +#### Frame 9: Maxim 5 -- buy options on tomorrow's profile + +*Kind:* keyconcept -- *Source:* §35.2 keypoint (part4_fit.tex 542-544) -- *Minutes:* 3 + +- \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 + +*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. + +#### Frame 10: AI Lens: sacrificial architecture for AI-native components + +*Kind:* ailens -- *Source:* §35.2 ailinse (part4_fit.tex 546-548) -- *Minutes:* 3 + +- 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 + +*Notes:* Point forward to next week's cost-of-change frame (Boehm vs Menzies) without teaching it. + +### Section: The Decision Procedure + +#### Frame 11: From a pre-filtered shortlist to a defensible decision + +*Kind:* table -- *Source:* §36 intro and step titles (part4_fit.tex 553-567) -- *Minutes:* 3 + +- 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 + +*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). + +#### Frame 12: Steps (i)--(iii): the demand side -- ASRs, scenarios, utility tree + +*Kind:* content -- *Source:* §36 steps (i)-(iii) (part4_fit.tex 557-559) -- *Minutes:* 4 + +- \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 + +*Notes:* Students did exactly this in weeks 2-3 (A1); say so, but the formal mapping comes on frame 15. + +#### Frame 13: Steps (iv)--(v): pre-filter via the matrix, then ATAM-light + +*Kind:* content -- *Source:* §36 steps (iv)-(v) (part4_fit.tex 560-561) -- *Minutes:* 4 + +- \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 + +*Notes:* Tie the last bullet to deck 3's 'beware pseudo-precision' frame (deck 3 line 499) -- same rule, now as step (v). + +#### Frame 14: Steps (vi)--(viii): record, contract, measure -- and keep the paths open + +*Kind:* content -- *Source:* §36 steps (vi)-(viii) (part4_fit.tex 562-566) -- *Minutes:* 3 + +- \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 + +*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. + +#### Frame 15: Note how much of this you have already done -- and Maxim 6 + +*Kind:* keyconcept -- *Source:* §36 closing paragraph and keypoint (part4_fit.tex 569-573) -- *Minutes:* 2 + +- 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 + +*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. + +### Section: The Reference Run: ADR-007 + +#### Frame 16: The reference run -- step (i): ASRs and classification + +*Kind:* case -- *Source:* §36.1 examplebox steps (i)-(iv), part (i) (part4_fit.tex 578-579) -- *Minutes:* 3 + +- 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 + +*Notes:* The examplebox of the script is split over frames 16-18; keep the title of the box on each. + +#### Frame 17: The reference run -- step (ii): the binding scenario, six parts and a number + +*Kind:* case -- *Source:* §36.1 examplebox steps (i)-(iv), part (ii) (part4_fit.tex 581) -- *Minutes:* 3 + +- 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 + +*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. + +#### Frame 18: The reference run -- steps (iii) and (iv): utility tree and matrix shortlist + +*Kind:* case -- *Source:* §36.1 examplebox steps (i)-(iv), parts (iii)-(iv) (part4_fit.tex 583-585) -- *Minutes:* 4 + +- \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) + +*Notes:* The full C10 row rationale comes in the last block (frame 36); here only the shortlist reading. + +#### Frame 19: The reference run -- step (v): ATAM-light, one sensitivity point, one tradeoff point + +*Kind:* case -- *Source:* §36.1 examplebox steps (v)-(viii), part (v) (part4_fit.tex 588-589) -- *Minutes:* 4 + +- 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) + +*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. + +#### Frame 20: The reference run -- steps (vi)--(viii): ADR, contract, operation, declared evolution paths + +*Kind:* case -- *Source:* §36.1 examplebox steps (v)-(viii), parts (vi)-(viii) and closing paragraph (part4_fit.tex 591-595, 598) -- *Minutes:* 3 + +- \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 + +*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'. + +#### Frame 21: ADR-007 (1/3): context and decision drivers + +*Kind:* content -- *Source:* §36.1 Listing lst:adr007 (part4_fit.tex 601-618) -- *Minutes:* 3 + +- 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 + +*Notes:* Keep the listing text verbatim; remove blank lines. About the size of deck 3's ADR-011 box. + +#### Frame 22: ADR-007 (2/3): considered options and decision + +*Kind:* content -- *Source:* §36.1 Listing lst:adr007 (part4_fit.tex 620-632) -- *Minutes:* 2 + +- 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 + +*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. + +#### Frame 23: ADR-007 (3/3): consequences and measurement contract + +*Kind:* content -- *Source:* §36.1 Listing lst:adr007 (part4_fit.tex 634-647) -- *Minutes:* 3 + +- 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 + +*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. + +#### Frame 24: Discussion + +*Kind:* discussion -- *Source:* deck-authored, derived from §36 steps (part4_fit.tex 557-566) and lst:adr007 (600-648); exercise sheet M2 (A2 = ADR + C4 + measurement contract) -- *Minutes:* 6 + +- 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 + +*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). + +### Section: The Ten Rows in Detail + +#### Frame 25: The ten rows in detail -- how to read a row rationale + +*Kind:* content -- *Source:* §33 intro (part4_fit.tex 167-171); §32 keypoint (part4_fit.tex 163-165) -- *Minutes:* 3 + +- 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 + +*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. + +#### Frame 26: The $7 \times 10$ grid, for reference + +*Kind:* table -- *Source:* §32 Table tab:fitmatrix (part4_fit.tex 127-152) -- *Minutes:* 1 + +- 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 + +*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. + +#### Frame 27: C1 -- core banking: the canonical hybrid, ACID core and EDA edges + +*Kind:* table -- *Source:* §33.1 Table tab:fit-c1 and verdict (part4_fit.tex 173-200) -- *Minutes:* 4 + +- 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 + +*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. + +#### Frame 28: C2 -- social media / content platform: the mirror image of C1 + +*Kind:* table -- *Source:* §33.2 Table tab:fit-c2 and verdict (part4_fit.tex 202-229) -- *Minutes:* 4 + +- 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 + +*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. + +#### Frame 29: C3 -- back-office / workflow: day-one simplicity vs. multi-decade evolvability + +*Kind:* table -- *Source:* §33.3 Table tab:fit-c3 and verdict (part4_fit.tex 231-258) -- *Minutes:* 3 + +- 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 + +*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. + +#### Frame 30: C4 -- ERP core: the strongest anti-fit in the grid + +*Kind:* table -- *Source:* §33.4 Table tab:fit-c4 and verdict (part4_fit.tex 260-287) -- *Minutes:* 3 + +- 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 + +*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. + +#### Frame 31: C5 -- e-commerce: seasonal elasticity vs. checkout consistency + +*Kind:* table -- *Source:* §33.5 Table tab:fit-c5 and verdict (part4_fit.tex 289-316) -- *Minutes:* 3 + +- 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 + +*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. + +#### Frame 32: C6 -- simulation / batch compute: a row decided at Stage 1 + +*Kind:* table -- *Source:* §33.6 Table tab:fit-c6 and verdict (part4_fit.tex 318-345) -- *Minutes:* 3 + +- 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 + +*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. + +#### Frame 33: C7 -- BI analytics: a pipeline feeding a serving tier + +*Kind:* table -- *Source:* §33.7 Table tab:fit-c7 and verdict (part4_fit.tex 347-374) -- *Minutes:* 3 + +- 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 + +*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. + +#### Frame 34: C8 -- real-time streaming: a log with stream processors + +*Kind:* table -- *Source:* §33.8 Table tab:fit-c8 and verdict (part4_fit.tex 376-403) -- *Minutes:* 3 + +- 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 + +*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. + +#### Frame 35: C9 -- collaboration / messaging: a monolithic core with a specialised push layer + +*Kind:* table -- *Source:* §33.9 Table tab:fit-c9 and verdict (part4_fit.tex 405-432) -- *Minutes:* 3 + +- 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 + +*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. + +#### Frame 36: C10 -- your class: the row extended to all seven candidates + +*Kind:* table -- *Source:* §33.10 Table tab:fit-c10 (part4_fit.tex 434-448) -- *Minutes:* 4 + +- 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) + +*Notes:* Give this row the most time: it is the row students' A2 was computed on. Verdict on the next frame. + +#### Frame 37: C10 -- the verdict: a designed hybrid, and the determinism boundary + +*Kind:* keyconcept -- *Source:* §33.10 verdict (part4_fit.tex 450) -- *Minutes:* 3 + +- \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') + +*Notes:* The projektbox uses the exercise sheet's M4 wording and hint box only. + +#### Frame 38: Ten rows, ten trade-offs (1/2): C1--C5 + +*Kind:* table -- *Source:* §33.1-33.5 verdict paragraphs (part4_fit.tex 199, 228, 257, 286, 315) -- *Minutes:* 3 + +- 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 + +*Notes:* Synthesis table; the 'deciding measurement' column carries only what the verdict paragraph names (C4 names a resolution, not a measure -- quoted as such). + +#### Frame 39: Ten rows, ten trade-offs (2/2): C6--C10 + +*Kind:* table -- *Source:* §33.6-33.10 verdict paragraphs (part4_fit.tex 344, 373, 402, 431, 450) -- *Minutes:* 3 + +- 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 + +*Notes:* The closing keypoint moves to its own frame 40 so this table fits; C10 row abbreviated to one line per cell. + +#### Frame 40: The recurring resolution: consistent core, asynchronous edges + +*Kind:* keyconcept -- *Source:* §33 closing keypoint (part4_fit.tex 452-454) -- *Minutes:* 3 + +- 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 + +*Notes:* Close the loop with frame 5 (eight of ten are compositions; placing, not averaging). + +### Section: Closing + +#### Frame 41: This week's exercise: the deterministic core (M4) + +*Kind:* exercise -- *Source:* project_exercise.tex M4 taskbox and hint box (lines 424-429, 448-461); semester plan week 10 -- *Minutes:* 0 + +- 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 + +*Notes:* Wording taken from the M4 taskbox and the hint box of the exercise sheet; the ADR-007 link is from the script listing. + +#### Frame 42: Summary + +*Kind:* summary -- *Source:* §35, §36, §33 -- *Minutes:* 0 + +- 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 + +*Notes:* Seven points; no extra keypoint needed. + +#### Frame 43: Next week + +*Kind:* nextweek -- *Source:* semester plan week 11; task brief 'Next lecture' -- *Minutes:* 0 + +- 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 + +*Notes:* Verbatim in substance from the 'Next lecture' line of the brief and semester plan week 11. + +#### Frame 44: Closing slide + +*Kind:* content -- *Source:* deck skeleton -- *Minutes:* 0 + +- \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 + +*Notes:* Identical to deck 6 (Graub\"unden with the umlaut macro). + +## Exercise frame: This week's exercise: the deterministic core (M4) + +- 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 frame + +1. 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. Fit is a function of time (Lehman, A5): MonolithFirst, Strangler Fig in both directions, sacrificial architecture -- MM is start state and consolidation target +3. 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. 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 +5. 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. ADR-007: one matrix row narrated -- options carry the matrix reasoning (auditable), the final section carries the contract (falsifiable) +7. 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 frame + +**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 + +*Reading:* +- this week: Part IV, Sections 35--36 and 33 +- ahead: Part IV, Sections 37--39 + +*Exercise / deliverable:* +- coaching; resilience on all external calls (timeout, retry, circuit breaker, fallback); graceful degradation +- milestone: deterministic core fully tested and resilient (M4 complete) + +## Script boxes, tables and figures used + +| Element | Script location | Used in frame | +|---|---|---| +| Figure fig:evolution (tikz state diagram of evolution paths) | §35.2, part4_fit.tex 514-540 | 8 The documented evolution paths -- a state diagram | +| keypoint Maxim 5 | §35.2, part4_fit.tex 542-544 | 9 Maxim 5 -- buy options on tomorrow's profile | +| ailinse[Sacrificial architecture for AI-native components] | §35.2, part4_fit.tex 546-548 | 10 AI Lens: sacrificial architecture for AI-native components | +| enumerate of the eight steps (i)-(viii) | §36, part4_fit.tex 556-567 | 11-14 (overview table, (i)-(iii), (iv)-(v), (vi)-(viii)) | +| keypoint Maxim 6 (restated) | §36, part4_fit.tex 571-573 | 15 Note how much of this you have already done -- and Maxim 6 | +| examplebox[Decision run for the Portfolio Intelligence Platform (class C10) -- steps (i)-(iv)] | §36.1, part4_fit.tex 578-586 | 16, 17, 18 (reference run steps (i), (ii), (iii)-(iv)) | +| examplebox[Decision run ... -- steps (v)-(viii)] | §36.1, part4_fit.tex 588-596 | 19, 20 (reference run steps (v), (vi)-(viii)) | +| Listing lst:adr007 (ADR-007 MADR record) | §36.1, part4_fit.tex 600-648 | 21 ADR-007 (1/3), 22 ADR-007 (2/3), 23 ADR-007 (3/3) | +| Table tab:fitmatrix (the 7x10 grid) | §32, part4_fit.tex 127-152 | 26 The 7x10 grid, for reference (plus the C10 row strip on frame 18) | +| keypoint 'Read a matrix cell as the answer to one question only' | §32, part4_fit.tex 163-165 | 25 How to read a row rationale (condensed reminder bullet) | +| Table tab:fit-c1 | §33.1, part4_fit.tex 175-197 | 27 C1 -- core banking | +| Table tab:fit-c2 | §33.2, part4_fit.tex 204-226 | 28 C2 -- social media / content platform | +| Table tab:fit-c3 | §33.3, part4_fit.tex 233-255 | 29 C3 -- back-office / workflow | +| Table tab:fit-c4 | §33.4, part4_fit.tex 262-284 | 30 C4 -- ERP core | +| Table tab:fit-c5 | §33.5, part4_fit.tex 291-313 | 31 C5 -- e-commerce | +| Table tab:fit-c6 | §33.6, part4_fit.tex 320-342 | 32 C6 -- simulation / batch compute | +| Table tab:fit-c7 | §33.7, part4_fit.tex 349-371 | 33 C7 -- BI analytics | +| Table tab:fit-c8 | §33.8, part4_fit.tex 378-400 | 34 C8 -- real-time streaming | +| Table tab:fit-c9 | §33.9, part4_fit.tex 407-429 | 35 C9 -- collaboration / messaging | +| Table tab:fit-c10 | §33.10, part4_fit.tex 436-448 | 36 C10 -- the row extended to all seven candidates | +| keypoint 'Every cell of the ten rows is traceable to the same mechanics ... consistent core, asynchronous edges' | §33 closing, part4_fit.tex 452-454 | 40 The recurring resolution: consistent core, asynchronous edges | +| verdict paragraphs (primary / secondary / central trade-off) for C1-C10 | §33, part4_fit.tex 199, 228, 257, 286, 315, 344, 373, 402, 431, 450 | 27-35 (one bold primary/trade-off line per class), 37 (C10 verdict), 38-39 (ten trade-offs tables: secondary and deciding measurement) | +| closing paragraph of §36.1 (two properties that make ADR-007 more than paperwork; ADR-011) | §36.1, part4_fit.tex 598 | 20 The reference run -- steps (vi)-(viii) (last bullet) | + +## Script elements deliberately not used + +| Element | Script location | Reason | +|---|---|---| +| definitionbox[Cell semantics of the matching matrix] | §32, part4_fit.tex 121-123 | Taught in Lecture 7 (deck 7, cell semantics); its one-sentence consequence is repeated as a Lecture-7 reminder on frames 5 and 25. | +| footnote paragraph under tab:fitmatrix (HX never negative, pattern abbreviations) | §32, part4_fit.tex 154-157 | Condensed to a single footnote line on the reference grid frame 26; the full argument was taught in Lecture 7. | +| thinkbox on the C5 row (3 vs 30 teams, 1x vs 50x traffic) | §34, part4_fit.tex 484-486 | Belongs to §34 (Lecture 7); not reused here unless deck 7 turns out not to have used it -- see open_issues. | + +## Open issues for the author + +- 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 -- row' and 'C -- 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. + +--- + +# Lecture 11: The Fit III -- The Measurement Contract, Conway's Law, and the Limits of the Theory + +- **Week:** 11 -- **Lessons:** 3 -- **Frames:** 40 +- **Title-slide script line:** Script: Part IV, Sections 37--39 + +## Agenda + +1. The measurement contract -- step (vii) +2. Fitness functions: taxonomy and three instrument families +3. DORA and the coupling finding +4. The four-layer cascade; the C10 reference contract +5. Cost of change: Boehm vs Menzies +6. AI Lens, both axes; the project's contract +7. Conway's law and Team Topologies +8. Limits of the theory; Maxim 9 +9. This week's exercise: resilience complete + +## Recap: where we are + +- Part IV so far: L7 -- three cases, three stages, the procedure, the $7 \times 10$ matrix, the contract introduced $\mid$ L8--9 -- Part III, classes C1--C9 $\mid$ L10 -- hybrids and evolution paths (Segment, Prime Video, Shopify), Maxim 5; the eight-step procedure with ADR-007, Maxim 6 (a response measure turns an opinion into a testable hypothesis); the ten matrix rows cell by cell -- recurring resolution: \emph{consistent core, asynchronous edges} +- Deck 1 (A5) and deck 2 (D9, D11) already named the four DORA metrics, the scaling finding, the \emph{within}/\emph{of} cost asymmetry and Conway's law -- today the instrument taxonomy, the numbers and the evidence behind them +- The measurement contract is the \textbf{fifth framework element}; ADR-011 (shown in lecture 3) already ended with an embryonic three-line contract -- its lines correspond to rows 2, 7 and 8 of today's reference contract, the static rule tightened from ``no provider-SDK import'' to ``gateway only via the declared port'' +- Deck 6: every cell is a \textbf{default hypothesis}, replaced by measurement once the system exists -- today: how that measurement is organised (steps (vii)--(viii)) +- Deck 6: \emph{Conway is a decision filter, not a footnote}, and the evidence base has honest gaps -- today \S 38 makes the organisation the third party to the fit, \S 39 turns the gaps into six limits the theory states about itself +- Today closes Part IV; next week opens Part V + +## Frame overview + +| # | Section | Frame title | Kind | Script ref | Min | +|---|---|---|---|---|---| +| 1 | Title | AISE502: AI in Software Engineering II -- Lecture 11: The Fit III -- The Measurement Contract, Conway's Law, and the Limits of the Theory | content | title slide; subtitle line: Script: Part IV, Sections 37--39 | 0 | +| 2 | Agenda | Agenda | agenda | deck skeleton (decks 1-6) | 1 | +| 3 | Recap | Recap: where we are | recap | deck-10 summary frame (L10 plan frame 42, bullets 3, 5 and 7: Maxim 5; Maxim 6; the ten rows -- consistent core, asynchronous edges) and its Maxim-6 keyconcept frame 15 (part4_fit.tex 569-573); deck 6 (summary, 'Four reading rules', 'Reading the catalogue as a whole', 'The evidence base and its honest gaps'); deck 1 A5 frame (lines 555-558); deck 2 D9/D11 frames (lines 323-327, 355-362); deck 3 ADR-011 frame (lines 560-580); semester plan rows 7-10 | 3 | +| 4 | The Measurement Contract | How does a decision made this year stay honest in year five? | case | \S 37 opening (part4_fit.tex 654-657) | 4 | +| 5 | The Measurement Contract | Step (vii): the fit becomes a measurement contract | content | \S 37 opening (part4_fit.tex 659) | 3 | +| 6 | The Measurement Contract | Architectural fitness function -- the definition | definition | \S 37.1 definitionbox (part4_fit.tex 663-665) | 5 | +| 7 | The Measurement Contract | Instrument family 1: dependency checks as CI gates | content | \S 37.1 item 1 (part4_fit.tex 670) | 4 | +| 8 | The Measurement Contract | Instrument family 2: performance and cost budgets as pipeline gates | content | \S 37.1 item 2 (part4_fit.tex 671); thresholds from tab:contract (707-726) | 3 | +| 9 | The Measurement Contract | Instrument family 3: chaos experiments as continual holistic fitness functions | content | \S 37.1 item 3 (part4_fit.tex 672) | 4 | +| 10 | The Measurement Contract | DORA metrics: the delivery layer | content | \S 37.2 (part4_fit.tex 677); tab:contract row 'Delivery performance' (707-726); tab:cascade row 'Delivery' (695) | 4 | +| 11 | The Measurement Contract | The coupling finding -- the strongest single result in the field | content | \S 37.2 (part4_fit.tex 677) | 4 | +| 12 | The Measurement Contract | Honesty requires the caveat: prediction, not proof | content | \S 37.2 (part4_fit.tex 679) | 2 | +| 13 | The Measurement Contract | The four-layer cascade: four falsification questions | diagram | \S 37.3 (part4_fit.tex 683); tab:cascade header (685-703) | 3 | +| 14 | The Measurement Contract | The cascade: instruments and example checks per layer | table | \S 37.3 tab:cascade (part4_fit.tex 685-703) | 4 | +| 15 | The Measurement Contract | The reference contract for C10 (1/2): structure, latency, consistency | table | \S 37.3 tab:contract rows 1-4 (part4_fit.tex 705-726) | 5 | +| 16 | The Measurement Contract | The reference contract for C10 (2/2): delivery, resilience, AI correctness, AI cost | table | \S 37.3 tab:contract rows 5-8 and eval-harness paragraph (part4_fit.tex 705-726) | 4 | +| 17 | The Measurement Contract | The cost of change -- what is flat | content | \S 37.4 (part4_fit.tex 728-731) | 4 | +| 18 | The Measurement Contract | The cost of change -- what is still steep | content | \S 37.4 (part4_fit.tex 733) | 4 | +| 19 | The Measurement Contract | Key concept: the contract as a standing experiment | keyconcept | \S 37.4 (part4_fit.tex 733) and keypoint (735-737) | 4 | +| 20 | The Measurement Contract | AI Lens (Axis A): fitness functions as the operating licence for agents | ailens | \S 37 ailinse, Axis A paragraph (part4_fit.tex 739-741) | 4 | +| 21 | The Measurement Contract | AI Lens (Axis B): two new fitness-function types with old mechanics | ailens | \S 37 ailinse, Axis B paragraph (part4_fit.tex 741-743) | 4 | +| 22 | The Measurement Contract | Project link: your submission ships its contract | content | \S 37 projektbox (part4_fit.tex 745-747) | 3 | +| 23 | Conway's Law and Team Topologies | The third fit dimension: why do correct matrix readings still fail? | content | \S 38 opening (part4_fit.tex 752-757) | 3 | +| 24 | Conway's Law and Team Topologies | Every architecture decision is a team-structure decision | content | \S 38 (part4_fit.tex 757) | 4 | +| 25 | Conway's Law and Team Topologies | Team Topologies: four team types, three interaction modes | table | \S 38 (part4_fit.tex 759) | 4 | +| 26 | Conway's Law and Team Topologies | Two concepts that bind directly into the matrix | content | \S 38 (part4_fit.tex 759) | 3 | +| 27 | Conway's Law and Team Topologies | The empirical anchor -- and the contested rows D11 decides | content | \S 38 (part4_fit.tex 761) | 3 | +| 28 | Conway's Law and Team Topologies | Key concept: the fit is three-way | keyconcept | \S 38 keypoint (part4_fit.tex 763-765) | 3 | +| 29 | Limits of the Theory | Limit 1: ordinal scales, no arithmetic | content | \S 39 opening and item 1 (part4_fit.tex 770-776) | 4 | +| 30 | Limits of the Theory | Limits 2 and 3: context-dependent cells, hybrids as the normal case | content | \S 39 items 2-3 (part4_fit.tex 777-778) | 4 | +| 31 | Limits of the Theory | Limit 4: the evidence base is heterogeneous | table | \S 39 item 4 (part4_fit.tex 779) | 3 | +| 32 | Limits of the Theory | Limits 5 and 6: the hidden organisation, AI-era volatility | content | \S 39 items 5-6 (part4_fit.tex 780-781) | 4 | +| 33 | Limits of the Theory | Six limits -- and what compensates each | table | \S 39 items 1-6 (part4_fit.tex 776-781), compensations as stated in each item | 3 | +| 34 | Limits of the Theory | Important note: the matrix is a hypothesis, not an authority | content | \S 39 hinweisbox (part4_fit.tex 784-786) | 4 | +| 35 | Limits of the Theory | Key concept: Maxim 9 | keyconcept | \S 39 keypoint (part4_fit.tex 788-790) | 3 | +| 36 | Limits of the Theory | Discussion | discussion | \S 39 thinkbox (part4_fit.tex 792-794) | 3 | +| 37 | Closing | This week's exercise: resilience complete -- M4 closes | exercise | project_exercise.tex 424-429 (M4 taskbox), 452-463 (hintbox); semester plan row week 11 | 4 | +| 38 | Closing | Summary | summary | \S 37-39 (part4_fit.tex 654-794) | 3 | +| 39 | Closing | Next week | nextweek | 'Next lecture' line of the assignment; semester plan row week 12; deck 6 next-week frame (lines 673-698) for the form | 1 | +| 40 | Closing | Closing slide | content | deck skeleton | 0 | + +## Frames in detail + +### Section: Title + +#### Frame 1: AISE502: AI in Software Engineering II -- Lecture 11: The Fit III -- The Measurement Contract, Conway's Law, and the Limits of the Theory + +*Kind:* content -- *Source:* title slide; subtitle line: Script: Part IV, Sections 37--39 -- *Minutes:* 0 + +- \FHGRTitlePage with \subtitle{Lecture 11: The Fit III -- The Measurement Contract, Conway's Law, and the Limits of the Theory\\[0.4ex]{\small Script: Part IV, Sections 37--39}} +- author Dr. Florian Herzog; \fullname{Fachhochschule Graub\"unden, Chur -- Autumn Semester 2026} unchanged from deck 6 + +*Elements:* +- title page macro as in deck 6 (line 117-127 of deck 6 for the subtitle/fullname form) + +*Notes:* identical preamble and colour mapping to deck 6; subtitle follows the 'Lecture N: -- ' form of decks 4-6 (single colon) + +### Section: Agenda + +#### Frame 2: Agenda + +*Kind:* agenda -- *Source:* deck skeleton (decks 1-6) -- *Minutes:* 1 + +- 1. \textbf{The measurement contract} -- step (vii) +- 2. \textbf{Fitness functions}: taxonomy and three instrument families +- 3. \textbf{DORA} and the coupling finding +- 4. \textbf{The four-layer cascade}; the C10 reference contract +- 5. \textbf{Cost of change}: Boehm vs Menzies +- 6. \textbf{AI Lens}, both axes; the project's contract +- 7. \textbf{Conway's law} and Team Topologies +- 8. \textbf{Limits of the theory}; Maxim 9 +- 9. \textbf{This week's exercise}: resilience complete + +*Elements:* +- enumerate, \small, itemsep 1pt, bold keyword per line as in deck 6 + +### Section: Recap + +#### Frame 3: Recap: where we are + +*Kind:* recap -- *Source:* deck-10 summary frame (L10 plan frame 42, bullets 3, 5 and 7: Maxim 5; Maxim 6; the ten rows -- consistent core, asynchronous edges) and its Maxim-6 keyconcept frame 15 (part4_fit.tex 569-573); deck 6 (summary, 'Four reading rules', 'Reading the catalogue as a whole', 'The evidence base and its honest gaps'); deck 1 A5 frame (lines 555-558); deck 2 D9/D11 frames (lines 323-327, 355-362); deck 3 ADR-011 frame (lines 560-580); semester plan rows 7-10 -- *Minutes:* 3 + +- Part IV so far: L7 -- three cases, three stages, the procedure, the $7 \times 10$ matrix, the contract introduced $\mid$ L8--9 -- Part III, classes C1--C9 $\mid$ L10 -- hybrids and evolution paths (Segment, Prime Video, Shopify), Maxim 5; the eight-step procedure with ADR-007, Maxim 6 (a response measure turns an opinion into a testable hypothesis); the ten matrix rows cell by cell -- recurring resolution: \emph{consistent core, asynchronous edges} +- Deck 1 (A5) and deck 2 (D9, D11) already named the four DORA metrics, the scaling finding, the \emph{within}/\emph{of} cost asymmetry and Conway's law -- today the instrument taxonomy, the numbers and the evidence behind them +- The measurement contract is the \textbf{fifth framework element}; ADR-011 (shown in lecture 3) already ended with an embryonic three-line contract -- its lines correspond to rows 2, 7 and 8 of today's reference contract, the static rule tightened from ``no provider-SDK import'' to ``gateway only via the declared port'' +- Deck 6: every cell is a \textbf{default hypothesis}, replaced by measurement once the system exists -- today: how that measurement is organised (steps (vii)--(viii)) +- Deck 6: \emph{Conway is a decision filter, not a footnote}, and the evidence base has honest gaps -- today \S 38 makes the organisation the third party to the fit, \S 39 turns the gaps into six limits the theory states about itself +- Today closes Part IV; next week opens Part V + +*Elements:* +- bullets, \footnotesize; bullet 1 typeset as three short sub-lines 'L7: ... | L8--9: ... | L10: ...' (as in decks 3 and 5); the L10 sub-line carries the three blocks of deck 10 separated by semicolons (hybrids/evolution + Maxim 5; procedure/ADR-007 + Maxim 6; the ten rows) and may run to two lines + +*Notes:* one frame only; do not re-teach ADR-011 -- just name the three lines so the eight-row contract on frames 15-16 reads as its completion. The deck-1/deck-2 bullet is what lets frames 11, 18 and 23 carry recap tags. Bullet 1 now mirrors the deck-10 summary (all three blocks of deck 10, Maxims 5 and 6): Maxim 6 -- 'with a response measure and a fitness function it is a testable hypothesis' -- is the direct lead-in to \S 37 and should be said aloud as the hand-over to frame 5 (step (vii)). + +### Section: The Measurement Contract + +#### Frame 4: How does a decision made this year stay honest in year five? + +*Kind:* case -- *Source:* \S 37 opening (part4_fit.tex 654-657) -- *Minutes:* 4 + +- \emph{How does a decision made this year stay honest in year five?} (leading question, italic, bankblue -- above the box) +- examplebox[Prime Video -- the trigger was a measurement]: What actually triggered the Prime Video re-architecture was \textbf{not an architecture review but a telemetry signal}: infrastructure cost per stream, measured continuously, crossed what the team was willing to pay +- (in the box) That measurement, not an opinion, first \emph{forced} and then \emph{vindicated} the redesign +- (in the box) The cost dashboard was a \textbf{fitness function in everything but name}: an objective, continuously evaluated check on an architectural characteristic whose breach converted a running structure from ``accepted'' into ``falsified'' +- (\footnotesize text below the box) The empirical anchor for building such checks systematically is DORA: coupling -- this theory's leading dimension -- is a \textbf{measurable} property; the finding itself: frame 11 + +*Elements:* +- examplebox[Prime Video -- the trigger was a measurement] holding bullets 2-4 (built from the running text of line 657 -- not a script box, see open_issues); leading question above, one \footnotesize line below + +*Notes:* Students met Prime Video in deck 6 (split D10 cell) and in lecture 10 (evolution path); the new angle here is only the trigger mechanism -- keep it short. The DORA quotation is deliberately withheld until frame 11. + +#### Frame 5: Step (vii): the fit becomes a measurement contract + +*Kind:* content -- *Source:* \S 37 opening (part4_fit.tex 659) -- *Minutes:* 3 + +- Step (vii) of the procedure generalises the Prime Video observation into a concept -- and it is where this course differs from a classical architecture lecture +- The chosen fit is codified as a \textbf{measurement contract}: the set of \emph{executable invariants} under which the architecture is allowed to keep evolving +- \emph{``The architecture may change freely as long as the contract stays green''} +- What today adds to the week-7 introduction: the instrument taxonomy (37.1), the delivery layer -- DORA (37.2), the four-layer cascade and the C10 reference contract (37.3), the economics -- cost of change (37.4) + +*Elements:* +- keypoint-style highlighted quotation of the green-contract sentence (line 659) + +*Notes:* bridge frame; the last bullet is the road map for the next 17 frames. Pick up Maxim 6 from recap bullet 1 verbally: the measurement contract is the set of fitness functions that makes the decision of step (vi) a testable hypothesis -- the recap already named it, this frame gives it its name + +#### Frame 6: Architectural fitness function -- the definition + +*Kind:* definition -- *Source:* \S 37.1 definitionbox (part4_fit.tex 663-665) -- *Minutes:* 5 + +- definitionbox[Architectural fitness function] (condensed to the first two sentences): An architectural fitness function is ``any mechanism that provides an objective integrity assessment of some architectural characteristic''. Fitness functions turn quality attributes into \textbf{executable, objective checks} and thereby move architecture governance from review meetings into the CI/CD pipeline +- Classified along two primary dimensions -- \textbf{scope} and \textbf{cadence} (mini table below the box): +- Scope | \emph{atomic}: one characteristic in isolation, e.g. a dependency rule as a unit test | \emph{holistic}: combined characteristics in interplay, e.g. security and data freshness under load +- Cadence | \emph{triggered}: event-based, on every build or deployment | \emph{continual}: running permanently in operation, e.g. chaos experiments | \emph{temporal}: time-scheduled, e.g. dependency-freshness time bombs + +*Elements:* +- definitionbox[Architectural fitness function], first two sentences of lines 663-665, \footnotesize +- footnotesize 2-row mini table Scope: atomic | holistic; Cadence: triggered | continual | temporal, each cell with the script's own example (line 665); booktabs, no vertical rules + +*Notes:* Replaces the former scope x cadence instrument table: the script classifies scope only for three examples, so the taxonomy is shown once here with the script's examples and not re-applied to instruments it does not classify. Say verbally that the same instrument can run at two cadences -- the latency row of the C10 contract (frame 15) is triggered + continual. + +#### Frame 7: Instrument family 1: dependency checks as CI gates + +*Kind:* content -- *Source:* \S 37.1 item 1 (part4_fit.tex 670) -- *Minutes:* 4 + +- ArchUnit (Java); analogues: NetArchTest (.NET), dependency-cruiser (JavaScript), import-linter (Python) +- Rules formulated as \textbf{unit tests that fail the build on violation}: ``the domain layer imports no framework''; ``no cycles between modules''; ``repositories are called only by services'' +- Spring Modulith verification does the same for module boundaries \emph{declared} in a modular monolith +- Classification: \textbf{atomic, triggered} +- For the matrix: this is what makes the MM ratings of the capability table \textbf{enforceable rather than aspirational} +- (recap, deck 4) without automated boundary verification, \emph{boundary erosion} is the documented failure mode of the pattern -- ``the first fitness function most teams ever write'' + +*Elements:* +- three rules as a small grey tcolorbox in \ttfamily (rendering of the quoted rules, line 670) + +*Notes:* project item (1) of the projektbox is exactly this family -- say so, show it on frame 22. New here: the classification, the tool analogues per language, and the 'enforceable rather than aspirational' link to the MM column; boundary erosion and 'first fitness function' were taught in deck 4 (lines 505, 523). + +#### Frame 8: Instrument family 2: performance and cost budgets as pipeline gates + +*Kind:* content -- *Source:* \S 37.1 item 2 (part4_fit.tex 671); thresholds from tab:contract (707-726) -- *Minutes:* 3 + +- Latency thresholds, bundle sizes, or Lighthouse scores are declared in a \textbf{budget file} and gate the pipeline (Lighthouse CI) +- The transfer to Axis B is direct: \textbf{token-cost budgets} and \textbf{p95 latency budgets} per AI use case are the same mechanism with new units +- In the C10 reference contract the units read: advisory answer p95 $< 20$\,s end-to-end (triggered $+$ continual); token cost $\leq$ budget, e.g. CHF~0.40/request at p95 (continual) + +*Elements:* +- two-column layout: classical budgets (left) vs Axis-B budgets (right), same mechanism arrow between them + +*Notes:* 'Lighthouse CI' is the bib-entry name (google2024lighthouseci) -- keep to that, add no page numbers or further tool names + +#### Frame 9: Instrument family 3: chaos experiments as continual holistic fitness functions + +*Kind:* content -- *Source:* \S 37.1 item 3 (part4_fit.tex 672) -- *Minutes:* 4 + +- Netflix's \textbf{Chaos Monkey} terminates production instances to test resilience assumptions \emph{permanently} +- Formalised as the \emph{principles of chaos engineering}; cited by Ford et al. as the paradigm of a \textbf{continual, holistic} fitness function +- (recap, deck 2 D5) for the matrix: chaos experiments are the instrument that \textbf{verifies the D5 cells} +- \emph{``A claimed blast radius is a hypothesis until an instance has actually been killed under load''} +- In the C10 contract: kill one instance/broker under load -- SLO holds; blast radius $\leq$ declared + +*Elements:* +- highlighted quotation (line 672) + +*Notes:* Chaos experiments as the D5 response-measure instrument were taught in deck 2 (D5 frame, lines 265 and 627) -- the new content is the classification and the quotation. Bridge to this week's project work (resilience on all external calls, graceful degradation): the resilience row is the fitness function that would verify it -- mention verbally, the exercise frame carries it. + +#### Frame 10: DORA metrics: the delivery layer + +*Kind:* content -- *Source:* \S 37.2 (part4_fit.tex 677); tab:contract row 'Delivery performance' (707-726); tab:cascade row 'Delivery' (695) -- *Minutes:* 4 + +- The four DORA metrics measure whether the \textbf{delivery-relevant promises} of a structure are being kept +- Tempo: \textbf{deployment frequency}; \textbf{lead time for changes} +- Stability: \textbf{change failure rate}; \textbf{failed-deployment recovery time} +- The central empirical finding: elite performers lead on \emph{all four} -- tempo and stability are \textbf{not a trade-off} +- In the contract: DORA four keys per deployable unit (tab:cascade: per architecture quantum); example thresholds: change failure rate $< 15\,\%$, restore $< 1$ day; cadence continual + +*Elements:* +- 2 x 2 mini table Tempo | Stability with the four metrics (from line 677) + +#### Frame 11: The coupling finding -- the strongest single result in the field + +*Kind:* content -- *Source:* \S 37.2 (part4_fit.tex 677) -- *Minutes:* 4 + +- (recap tag, one line at the top) deck 2, D9 and D11 already named these -- today the evidence behind them +- \emph{``Loosely coupled architectures and teams are the strongest predictor of continuous delivery''} -- supports coupling as the \textbf{leading dimension of this entire theory} +- (recap, deck 2 D9) 2017 analysis: the architecture characteristics \textbf{testability and deployability} contributed more to continuous delivery than test and deployment automation itself +- Follow-on finding 1: high performance is possible with \emph{all kinds of systems -- including mainframes} -- provided systems and teams are loosely coupled; the label ``microservices'' is \textbf{neither necessary nor sufficient} +- Follow-on finding 2 (recap, deck 2 D11 / deck 5): as team count grows, deployments per developer per day \textbf{rise} for high performers and \textbf{fall} for low performers + +*Elements:* +- the quotation set as a highlighted line; two follow-on findings as numbered items; recap tag as a \footnotesize grey line above + +*Notes:* This is the semester plan's 'Kopplungs-Befund'. Genuinely new on this frame: the verbatim quotation, the mainframe clause and the 'neither necessary nor sufficient' verdict. Connect back to deck 6 D11 row and forward to \S 38 (frame 27) where the same finding returns as a Conway statement + +#### Frame 12: Honesty requires the caveat: prediction, not proof + +*Kind:* content -- *Source:* \S 37.2 (part4_fit.tex 679) -- *Minutes:* 2 + +- DORA's evidence is \textbf{survey-based} and analysed with structural equation models -- \emph{prediction, not experimental causal proof} +- The theory treats it as the \textbf{best available large-$n$ evidence} +- To be \emph{triangulated} against case studies and the reader's own measurements +- Not settled law -- the caveat returns in \S 39 as limit 4 + +*Elements:* +- hinweisbox built from the running text of line 679 (not a script box, see open_issues) + +*Notes:* Kept as its own short frame: the deck has exactly 40 frames, the lower bound of the 40-46 band for three lessons, so folding this frame into frame 11 would breach the band. If time must be saved, trim minutes instead -- frame 6 (5 -> 4) and frame 15 (5 -> 4) -- or fold this frame into 11 only together with splitting frame 25 (Team Topologies: four team types / three interaction modes) so the count stays at 40 + +#### Frame 13: The four-layer cascade: four falsification questions + +*Kind:* diagram -- *Source:* \S 37.3 (part4_fit.tex 683); tab:cascade header (685-703) -- *Minutes:* 3 + +- (one sentence above the diagram) The contract has four layers, forming a \textbf{cascade from design time to evolution}; each layer answers a different falsification question +- (diagram) Design time -- \emph{is the structure intact?} +- (diagram) Delivery -- \emph{is the structure delivering?} +- (diagram) Operation -- \emph{is the structure keeping its runtime promises?} +- (diagram) Evolution -- \emph{is the structure ageing?} +- (one line below the diagram) instruments and example checks per layer: next frame + +*Elements:* +- tikz: four rounded rectangles in a descending cascade (left-to-right, stepping down), each with layer name and question in italics only; arrows between them; style of the topology figures in deck 6 (bankblue fill, gray arrows) + +*Notes:* Diagram carries the layer names and questions; no bullet list beside it (deck 6 topology frames: figure + one paragraph). Instruments stay on frame 14. + +#### Frame 14: The cascade: instruments and example checks per layer + +*Kind:* table -- *Source:* \S 37.3 tab:cascade (part4_fit.tex 685-703) -- *Minutes:* 4 + +- Design time | dependency rules as CI gates; coupling and cohesion metrics; complexity gates | ``the domain layer imports no framework''; ``no cycles between modules''; ``no domain service calls the LLM gateway except via the declared port'' +- Delivery | the four DORA metrics | deployment frequency, lead time, change failure rate, failed-deployment recovery time -- \emph{per architecture quantum} +- Operation | SLOs and error budgets; latency and \emph{cost} budgets as pipeline gates; chaos experiments as continual holistic fitness functions | p95 latency budget per scenario; token-cost budget per request; blast-radius drills +- Evolution | Lehman indicators; change scatter; technical-debt inventory | complexity trend per module; share of features touching more than two modules; debt-register review + +*Elements:* +- scriptsize 4-row table Layer | Instruments | Example checks, p{1.8cm} p{5.3cm} p{5.6cm}, booktabs, \addlinespace between rows -- transcription of tab:cascade without citations; the parenthetical tool list of the design-time cell (ArchUnit, Spring Modulith verify, dependency-cruiser) is dropped pre-emptively -- it is on frame 7 + +*Notes:* Long cells: keep no text above or below the table except a one-line caption + +#### Frame 15: The reference contract for C10 (1/2): structure, latency, consistency + +*Kind:* table -- *Source:* \S 37.3 tab:contract rows 1-4 (part4_fit.tex 705-726) -- *Minutes:* 5 + +- Intro line: tab:contract instantiates the cascade as the \textbf{reference contract for the course-project class C10} -- the concrete table that ADR-007 points to +- Module boundaries | ArchUnit / Spring Modulith verify: no undeclared cross-module dependency | 0 violations | triggered (every build) +- Determinism boundary | static rule: no domain service imports the LLM gateway except via the declared port | 0 violations | triggered +- Latency | p95 end-to-end per critical scenario | advisory answer $< 20$\,s | triggered $+$ continual +- Consistency | ledger/audit reconciliation job: booked vs journaled | 0 discrepancies | temporal (daily) + +*Elements:* +- scriptsize 4-row table Concern | Fitness function | Threshold (example) | Cadence, p{2.4cm} p{5.0cm} p{3.0cm} p{2.4cm}, from tab:contract rows 1-4 + +*Notes:* Two verbal points: (a) the latency row shows the same instrument at two cadences -- triggered in the pipeline and continual in operation; (b) the determinism-boundary row is the CI-enforced form of the exercise sheet's line 'keep the deterministic core free of LLM calls -- this is the line that is graded' -- the contract row permits LLM access via the declared port, the hint forbids LLM calls inside the core; do not present them as identical + +#### Frame 16: The reference contract for C10 (2/2): delivery, resilience, AI correctness, AI cost + +*Kind:* table -- *Source:* \S 37.3 tab:contract rows 5-8 and eval-harness paragraph (part4_fit.tex 705-726) -- *Minutes:* 4 + +- Delivery performance | DORA four keys per deployable unit | e.g. change failure rate $< 15\,\%$; restore $< 1$ day | continual +- Resilience | chaos experiment: kill one instance/broker under load | SLO holds; blast radius $\leq$ declared | temporal +- AI correctness | eval-harness pass rate on golden set plus domain axioms | $\geq 95\,\%$ pass; 0 ontology-violating outputs shipped | triggered (every prompt/model change) +- AI cost | token cost per request, per feature | $\leq$ budget (e.g. CHF~0.40/request at p95) | continual +- Below the table: for AI components the contract gains \textbf{one artefact of the first rank -- the eval harness}: a versioned suite of test cases, scoring logic, and statistical thresholds that runs in CI like a test suite and gates every prompt change, model update, and provider migration; Part V develops it in full + +*Elements:* +- scriptsize 4-row table, same column widths as frame 15, from tab:contract rows 5-8; one \footnotesize paragraph on the eval harness (line 705) + +*Notes:* Link verbally: ADR-011's three embryonic lines (shown in lecture 3) correspond to rows 2, 7 and 8 of this table -- the static rule has been tightened from 'no domain module imports the provider SDK' to 'gateway only via the declared port' + +#### Frame 17: The cost of change -- what is flat + +*Kind:* content -- *Source:* \S 37.4 (part4_fit.tex 728-731) -- *Minutes:* 4 + +- \emph{Why does the contract matter economically?} (leading question, italic) +- The classical answer -- \textbf{Boehm's cost-of-change escalation}: on waterfall project data of the 1970s, fixing a problem after delivery is up to \textbf{one hundred times} more expensive than fixing it during requirements and design +- Honest qualification: for small, uncritical systems the factor is closer to \textbf{2:1} +- Modern practice has empirically \textbf{flattened} that curve for changes \emph{within} an architecture +- The largest replication to date -- \textbf{171 projects from 2006--2014} -- found \emph{no consistent delayed-issue effect} (Menzies et al. 2017) +- Version control, automated tests, and continuous delivery did exactly what the economic argument of Extreme Programming said they would + +*Elements:* +- two columns: Boehm (1981/2001) -- 100:1, 2:1 | Menzies et al. (2017) -- 171 projects, no consistent delayed-issue effect + +*Notes:* semester plan: 'Boehm vs. Menzies'; do not add numbers beyond 100x, 2:1, 171, 2006-2014. No cost-curve sketch: the script gives no curve data (see open_issues) + +#### Frame 18: The cost of change -- what is still steep + +*Kind:* content -- *Source:* \S 37.4 (part4_fit.tex 733) -- *Minutes:* 4 + +- The nuance the module insists on: flattened is the curve for changes \emph{within} an architecture (deck 1, Assumption A5 -- stated then, evidenced now) +- For changes \emph{of} the architecture -- \textbf{splitting a monolith}, \textbf{changing the communication paradigm}, \textbf{moving a data-intensive flow across expensive distributed boundaries} -- the curve remains steep +- The evidence is the case studies themselves: Segment's consolidation and Prime Video's rewrite were, at their core, \textbf{expensive architecture revisions} +- This asymmetry is the \textbf{economic justification of the whole apparatus}: justify the fit \emph{up front} (architecture revision is the change class that still costs) and keep the architecture \emph{evolvable under a green contract} (everything else is now cheap to change) + +*Elements:* +- four \footnotesize bullets, no figure; the three steep change classes set bold + +*Notes:* The within/of asymmetry with Segment and Prime Video was stated in deck 1 A5 (line 558); the new material carrying this frame is the three change classes that stay steep and the up-front/evolvable argument. The life-cycle-cost sentence moves to frame 19. + +#### Frame 19: Key concept: the contract as a standing experiment + +*Kind:* keyconcept -- *Source:* \S 37.4 (part4_fit.tex 733) and keypoint (735-737) -- *Minutes:* 4 + +- (\footnotesize text above the keypoint) Maintenance and evolution consume roughly \textbf{40--80\,\%} -- typically about \textbf{60\,\%} -- of life-cycle cost, mostly for \emph{enhancement} rather than repair (deck 1, A5 -- stated then, sourced now); the contract is how a structure \textbf{earns the right to survive that phase} +- (keypoint) The measurement contract converts an architecture decision into a \textbf{standing experiment} +- (keypoint) design-time gates verify the \emph{structure}; DORA metrics verify the \emph{delivery}; budgets and chaos experiments verify the \emph{runtime promises}; Lehman indicators verify the \emph{ageing} +- (keypoint) The cost-of-change curve is \textbf{flat inside a green contract} and \textbf{steep across architecture boundaries} -- which is why \emph{the contract, not the diagram}, is the artefact that protects the investment + +*Elements:* +- one \footnotesize paragraph (line 733, last sentence) above; keypoint box condensed from lines 735-737 + +#### Frame 20: AI Lens (Axis A): fitness functions as the operating licence for agents + +*Kind:* ailens -- *Source:* \S 37 ailinse, Axis A paragraph (part4_fit.tex 739-741) -- *Minutes:* 4 + +- An agentic coding tool iterating against a dense test suite and CI-enforced architecture rules is \textbf{contained} +- Every generated change must pass the \emph{same} dependency rules, budgets, and evals as a human change -- the blast radius of ``almost right'' code is bounded by the contract +- Without those gates, every agent change is \textbf{unpriced risk} +- The empirical record shows AI adoption \emph{amplifying} existing delivery dysfunction rather than fixing it (DORA 2025 AI report) +- The measurement contract is therefore the prerequisite for raising the change rate by an order of magnitude safely: \textbf{fitness functions are the operating licence for agents} + +*Elements:* +- ailinse[Axis A -- fitness functions as the operating licence for agents], condensed from lines 739-741 + +#### Frame 21: AI Lens (Axis B): two new fitness-function types with old mechanics + +*Kind:* ailens -- *Source:* \S 37 ailinse, Axis B paragraph (part4_fit.tex 741-743) -- *Minutes:* 4 + +- The contract absorbs AI components through \textbf{two new fitness-function types with old mechanics} +- \textbf{Eval-harness pass rate}: a \emph{triggered} gate on every prompt and model change, statistically thresholded +- \textbf{Token-cost budget per request}: a \emph{continual} gate, exactly analogous to a performance budget +- Cost per request is a runtime quality attribute with \textbf{no counterpart in classical profiles} +- Making it a fitness function is what turns FinOps from a \emph{monthly surprise} into an \textbf{architectural control loop} + +*Elements:* +- ailinse[Axis B -- eval pass rate and token budget], condensed from lines 741-743 + +*Notes:* Connect to deck 6 C10 profile: D9 = H in its eval reading, D10 = H cost per request -- these are the two rows now measurable + +#### Frame 22: Project link: your submission ships its contract + +*Kind:* content -- *Source:* \S 37 projektbox (part4_fit.tex 745-747) -- *Minutes:* 3 + +- Your project submission must ship its \textbf{measurement contract}, not just its architecture -- the repository must contain, \emph{wired into CI}: +- (1) module-boundary verification with \textbf{zero violations} (ArchUnit or Spring Modulith verify), including the determinism-boundary rule: no domain service reaches the LLM gateway except via its declared port +- (2) an eval harness with a versioned golden set and a \textbf{pass rate $\geq 95\,\%$} gating every prompt or model change +- (3) a \textbf{token-cost budget per request} enforced as a pipeline gate and reported per feature +- (4) a p95 latency budget for the advisory scenario (\textbf{$< 20$\,s} end-to-end) +- (5) the ADR (in MADR form) whose final section \emph{is} this contract +- At the project review you will be asked to demonstrate \textbf{one contract violation being caught by CI} -- \emph{a contract that has never failed is a contract that has never been tested} + +*Elements:* +- projektbox verbatim (condensed) from lines 745-747, \footnotesize + +*Notes:* This is the submission requirement for the project review; frame 37 carries this week's tasks (resilience). Keep both -- they answer different questions + +### Section: Conway's Law and Team Topologies + +#### Frame 23: The third fit dimension: why do correct matrix readings still fail? + +*Kind:* content -- *Source:* \S 38 opening (part4_fit.tex 752-757) -- *Minutes:* 3 + +- \emph{Why do correct matrix readings still fail in real organisations?} (leading question, italic) +- (recap, deck 2 D11) Conway's law in one sentence, and its consequence: every architecture decision is a team-structure decision -- named there, sourced here +- The matrix matches patterns to application classes; D11 (team scaling) has appeared throughout as \emph{one dimension among twelve} -- this section makes explicit why it is more than that: the organisation is a \textbf{third party to the fit}, and ignoring it is the most common way correct matrix readings fail in practice +- The source is older than every pattern in the matrix -- Conway, 1968 (highlighted line): \emph{``Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure''} +- Named ``Conway's law'' by Brooks (1975); empirically supported by mirroring studies of organisation and product structure (MacCormack et al. 2012) + +*Elements:* +- the Conway quotation once, as a highlighted line (as on frames 9 and 11) -- no definitionbox is constructed, \S 38 has no box except the closing keypoint + +*Notes:* New content on this frame: the verbatim 1968 quotation, Brooks naming it, the MacCormack mirroring evidence, and the 'third party to the fit' framing; the law and its consequence are deck 2 recap + +#### Frame 24: Every architecture decision is a team-structure decision + +*Kind:* content -- *Source:* \S 38 (part4_fit.tex 757) -- *Minutes:* 4 + +- The consequence for this theory is direct: every architecture decision is \emph{simultaneously} a team-structure decision, whether acknowledged or not +- Left column -- \textbf{a microservices topology assigned to a single five-person team} produces a \textbf{distributed monolith}: many quanta, one communication structure, the worst cells of \emph{two} columns at once (recap, deck 5: the distributed monolith and its lockstep-release signature) +- Right column -- \textbf{a modular monolith assigned to thirty independent teams} produces a \textbf{release-coordination bottleneck} that no amount of code quality repairs + +*Elements:* +- two-column mirror pair (style of the C1/C2 frame in deck 6): 'MS to one team' | 'MM to thirty teams'; the deck-5 recap tag as a \footnotesize line under the left column + +*Notes:* Tie to deck 6 Maxim 3 (quantum count): the distributed monolith is 'the worst cells of two columns at once' (cf. Maxim 3) -- keep to the script's phrase; the failure mode is recognised from deck 5 (hinweisbox, line 305), not re-taught + +#### Frame 25: Team Topologies: four team types, three interaction modes + +*Kind:* table -- *Source:* \S 38 (part4_fit.tex 759) -- *Minutes:* 4 + +- Team Topologies (Skelton and Pais 2019) turns the law \textbf{from a hazard into a design instrument} +- Stream-aligned | delivering end-to-end on one value stream +- Platform | reduce the load of stream teams +- Enabling | build missing capabilities +- Complicated-subsystem | encapsulate specialist knowledge -- \emph{an ML inference subsystem is the canonical course-relevant example} +- Three interaction modes: \textbf{collaboration}, \textbf{X-as-a-service}, \textbf{facilitating} +- Together: the vocabulary for matching team structure to pattern choice + +*Elements:* +- footnotesize 4-row table Team type | Role (from line 759); interaction modes as one line below + +#### Frame 26: Two concepts that bind directly into the matrix + +*Kind:* content -- *Source:* \S 38 (part4_fit.tex 759) -- *Minutes:* 3 + +- \textbf{1. Cognitive load as a design criterion}: team and software boundaries should be cut so that \emph{no team's cognitive load exceeds its capacity} +- ``Team-sized software'' is an \textbf{architectural yardstick} +- It explains why the MS column demands stream-aligned teams with full ownership as a \textbf{precondition, not an outcome} (recap, decks 5 and 6: 'stream-aligned $+$ platform -- a precondition') +- \textbf{2. The inverse Conway manoeuvre}: deliberately structure the organisation to mirror the \emph{target} architecture +- -- so that Conway's law works \emph{for} the design instead of against it + +*Elements:* +- two numbered blocks; optional small tikz: organisation box mirrored onto target-architecture box with a reversed arrow labelled 'inverse Conway manoeuvre' + +#### Frame 27: The empirical anchor -- and the contested rows D11 decides + +*Kind:* content -- *Source:* \S 38 (part4_fit.tex 761) -- *Minutes:* 3 + +- The DORA scaling finding, read again: loose coupling of \emph{architectures and teams} -- measured \textbf{jointly}, which is itself a Conway statement -- is the strongest predictor of continuous delivery +- It is the mechanism that lets deployments per developer per day \textbf{scale linearly with team count} +- The matrix encodes the organisational variable in D11; the class rationales repeatedly show it \emph{deciding contested rows} (table) +- No twelve-dimensional profile fully captures an organisation (limit 5 in \S 39) -- but the rule of thumb is teachable + +*Elements:* +- footnotesize table Class | same profile | smaller organisation | larger organisation -- C1: LMAX single-threaded core | Monzo 2,800 services (different organisation sizes); C5: Shopify modular monolith | Amazon microservices (along team count, not traffic) -- from line 761; the table carries the two cases, no bullets repeat them + +#### Frame 28: Key concept: the fit is three-way + +*Kind:* keyconcept -- *Source:* \S 38 keypoint (part4_fit.tex 763-765) -- *Minutes:* 3 + +- The fit is three-way: \textbf{pattern $\leftrightarrow$ application class $\leftrightarrow$ team structure} +- \textbf{Check D11 last but veto on it first}: a pattern whose team precondition is not met -- microservices without stream-aligned ownership, a monolith across too many coordinating teams -- will fail regardless of how well the other eleven dimensions match +- If the target architecture and the organisation disagree: either apply the \textbf{inverse Conway manoeuvre} or \textbf{change the target} +- \emph{Conway's law does not negotiate} + +*Elements:* +- tikz triangle: three nodes 'pattern C(p)', 'application class R(a)', 'team structure' with double arrows; keypoint box below condensed from lines 763-765 + +*Notes:* Explain 'check last, veto first': D11 is checked last in the twelve-row profile walk-through but is the first veto to apply in practice + +### Section: Limits of the Theory + +#### Frame 29: Limit 1: ordinal scales, no arithmetic + +*Kind:* content -- *Source:* \S 39 opening and item 1 (part4_fit.tex 770-776) -- *Minutes:* 4 + +- (lead-in line, italic) \emph{A theory whose declared standard is that unfalsifiable claims have no place in architecture decisions must state how it can itself mislead.} Six limits, stated plainly -- the first: +- The ratings support \textbf{rankings and exclusions, never percentages} +- Any weighted-sum reading of the matrix imports the documented defects of additive multi-criteria methods over ordinal data (grid): +- (grid) \textbf{rank reversal} (Belton and Gear 1983) | \textbf{axiomatic conflict with utility theory} (Dyer 1990) | \textbf{scale misinterpretation} (Bana e Costa and Vansnick 2008) | \textbf{pseudo-precision} -- priorities with three decimal places from coarse verbal comparisons +- We keep the \emph{explication discipline} of multi-criteria decision analysis and drop its \emph{arithmetic pretensions} +- \textbf{Sensitivity analysis is mandatory, not decorative}; unstable rankings are \emph{findings} (tradeoff points), not errors + +*Elements:* +- lead-in line from lines 772-773 (replaces the former overview frame); four defects as a 2 x 2 grid of short labelled cells (replaces the former bullet list of the four names) + +*Notes:* Students met 'beware pseudo-precision' in deck 3; here the literature names are new -- keep to the four names, no further explanation is in the script. The six-limit overview appears once, on the consolidation table (frame 33). + +#### Frame 30: Limits 2 and 3: context-dependent cells, hybrids as the normal case + +*Kind:* content -- *Source:* \S 39 items 2-3 (part4_fit.tex 777-778) -- *Minutes:* 4 + +- \textbf{Limit 2.} Every capability cell encodes a \emph{typical} workload +- the serverless cost cell literally inverts with load shape (Prime Video); the layered read-scalability cell inverts with cache-friendliness (Stack Overflow) +- skilled teams can move individual cells -- LMAX and Monzo both did +- a rating is a \textbf{default hypothesis} to be replaced by measurement in step (viii); \emph{the matrix predicts the default, not the exceptional} +- \textbf{Limit 3.} Eight of ten class recommendations involve a core pattern plus different edge patterns +- the matrix is defined over \textbf{subsystems}; applying it to a whole enterprise in one stroke is a \emph{category error the theory explicitly forbids} + +*Elements:* +- two labelled blocks, \footnotesize + +#### Frame 31: Limit 4: the evidence base is heterogeneous + +*Kind:* table -- *Source:* \S 39 item 4 (part4_fit.tex 779) -- *Minutes:* 3 + +- (table) Star ratings (Richards and Ford) | expert judgement | not measurements +- (table) DORA | survey-based prediction | not causal proof +- (table) Case studies | self-reported engineering blogs | selection and framing bias +- (table, last line) Hexagonal and serverless | -- | no star ratings at all +- (line below) Prime Video in particular is routinely misquoted as ``Amazon abandons microservices'' when it documents \emph{one service} with a data-intensive streaming workload -- you met it in deck 6 (SL, the split cell) +- (line below) Compensation: \textbf{triangulation} -- ratings against cases against metrics -- and the \textbf{measurement contract}, which converts every adopted claim into a testable one + +*Elements:* +- footnotesize table Source | Nature | Weakness, three rows plus the HX/SL line; two \footnotesize lines below -- no bullet list duplicating the table + +*Notes:* Deck 6 'evidence base and its honest gaps' already listed the expert-rating and HX/SL caveats and flagged the Prime Video misquotation ('Widely reported as Amazon abandons microservices', deck 6 line 359) -- new here are only the DORA and blog-bias rows and the compensation + +#### Frame 32: Limits 5 and 6: the hidden organisation, AI-era volatility + +*Kind:* content -- *Source:* \S 39 items 5-6 (part4_fit.tex 780-781) -- *Minutes:* 4 + +- \textbf{Limit 5.} Conway's law makes every architecture decision a team-structure decision +- the same requirements profile admits \emph{opposite} optimal patterns at different organisation sizes (LMAX vs Monzo; Shopify vs Amazon) +- D11 partially captures this; no twelve-dimensional profile fully does (\S 38) +- \textbf{Limit 6.} The D12 ratings encode the \textbf{2025/26 state} of a field whose tools deprecate in months +- the \emph{method} -- Assumption A6: scenarios, tactics, trade-off analysis, ADRs, fitness functions -- is the stable part; the specific cells are \textbf{perishable} +- they carry, in effect, their own \textbf{temporal fitness function}: re-verify on every model generation -- \emph{Lehman's laws apply to theories too} + +*Elements:* +- two labelled blocks, \footnotesize + +#### Frame 33: Six limits -- and what compensates each + +*Kind:* table -- *Source:* \S 39 items 1-6 (part4_fit.tex 776-781), compensations as stated in each item -- *Minutes:* 3 + +- 1 Ordinal scales | rankings and exclusions only | sensitivity analysis, mandatory; unstable rankings are findings +- 2 Context-dependence | cells are typical-workload defaults | measurement replaces the rating in step (viii) +- 3 Hybrids normal | 8 of 10 classes core $+$ edges | apply the matrix to subsystems, never to a whole enterprise +- 4 Heterogeneous evidence | expert stars, survey prediction, self-reported blogs | triangulation $+$ the measurement contract +- 5 Hidden organisation | same profile, opposite optima by org size | D11 captures it only partially -- check the team precondition separately (\S 38) +- 6 AI-era volatility | D12 cells encode 2025/26 | method (A6) stable; cells re-verified on every model generation + +*Elements:* +- scriptsize 6-row table Limit | What it means | What compensates, p{2.6cm} p{4.4cm} p{5.4cm}, booktabs + +*Notes:* Consolidation frame and the only overview of the six limits; every cell is a rephrasing of the respective item -- no new claims (row 5 states what the script says, not a compensation the script does not offer) + +#### Frame 34: Important note: the matrix is a hypothesis, not an authority + +*Kind:* content -- *Source:* \S 39 hinweisbox (part4_fit.tex 784-786) -- *Minutes:* 4 + +- A student who cites the matrix as an \emph{authority} rather than as a \emph{hypothesis} has misunderstood the module +- The matrix cannot tell you what to build; it can only \textbf{force your criteria, weights, and assumptions into the open}, \textbf{pre-filter the candidates}, and \textbf{hand the contested cells to scenario-based analysis} +- Its numbers are ordinal, its ratings are context-typical defaults, its evidence is triangulated but partly survey-based and partly self-reported -- and it \emph{decays}: every cell is a claim awaiting your measurement +- The canonical exercise in this scepticism: reading contradictory study designs against each other -- the METR-versus-Copilot contradiction of Part V (next week) +- The assessment of this module tests the \textbf{discipline}, not the memorisation of the grid + +*Elements:* +- hinweisbox condensed from lines 784-786 + +*Notes:* Explicit bridge to Lecture 12 (the two contradictory RCTs) + +#### Frame 35: Key concept: Maxim 9 + +*Kind:* keyconcept -- *Source:* \S 39 keypoint (part4_fit.tex 788-790) -- *Minutes:* 3 + +- \textbf{Maxim 9.} The matrix is the argument's \textbf{skeleton}, ATAM is its \textbf{court of appeal}, the ADR is its \textbf{record}, and the fitness function is its \textbf{parole condition} +- The matrix is the \emph{lecture-hall form} of a discipline whose \emph{engineering form} is: +- scenarios with numbers $\cdot$ ATAM for the contested cells $\cdot$ ADRs for the decisions $\cdot$ fitness functions for the lifetime + +*Elements:* +- keypoint box (Maxim 9) from lines 788-790; four-column strip skeleton | court of appeal | record | parole condition + +*Notes:* Closes Part IV's theory: this frame is the one-sentence takeaway of Parts I-IV + +#### Frame 36: Discussion + +*Kind:* discussion -- *Source:* \S 39 thinkbox (part4_fit.tex 792-794) -- *Minutes:* 3 + +- (setup) Limit 4 says the evidence base is heterogeneous, and limit 2 says skilled teams can move cells +- (setup) Suppose your team measures, over a year, that its microservices system beats every prediction of the MS column for its class +- Has the theory been \textbf{falsified} -- or has your measurement contract done exactly what step (viii) designed it to do? +- What would have to be true of your \emph{next} project for the difference to matter? + +*Elements:* +- thinkbox with the setup line and the two questions from lines 792-794 (title 'Discussion' as in decks 3 and 5) + +*Notes:* 3 min of steered discussion: 'default hypothesis vs measured exception', then Conway (the next project may have a different team structure) + +### Section: Closing + +#### Frame 37: This week's exercise: resilience complete -- M4 closes + +*Kind:* exercise -- *Source:* project_exercise.tex 424-429 (M4 taskbox), 452-463 (hintbox); semester plan row week 11 -- *Minutes:* 4 + +- (projektbox) Coaching session (1 lesson). \textbf{Resilience patterns on all external calls}: timeout, retry, circuit breaker, fallback +- (projektbox) \textbf{Graceful degradation verified} +- (projektbox) \textbf{Milestone M4 of the exercise sheet closes (end of week 11)}: deterministic core \emph{fully tested} against the reference vectors \emph{and resilient} +- (projektbox, hint) Keep the deterministic core free of LLM calls -- this is the line that is graded +- (\footnotesize line below the box) Looking ahead: the resilience row of the reference contract (kill one instance/broker under load -- SLO holds) is the fitness function that would verify what you build now -- it is not a graded deliverable + +*Elements:* +- projektbox with four bullets (tasks, degradation, milestone, one hint line -- the \small short form of decks 4-6); one \footnotesize line below + +*Notes:* Speaker note: the determinism-boundary row of the reference contract (frame 15) is the CI-enforced form of the graded line -- not the same rule (the row permits LLM access via the declared port; the hint forbids LLM calls inside the core). 'M4' follows the exercise sheet students work from; the semester plan's adjustment table still labels this milestone 'M3 Resilienz + deterministischer Kern' -- flagged for correction (open_issues). The snapshot/commit/ADR hints (exercise sheet 459-463) are mentioned verbally, not printed. + +#### Frame 38: Summary + +*Kind:* summary -- *Source:* \S 37-39 (part4_fit.tex 654-794) -- *Minutes:* 3 + +- 1. \textbf{Fitness functions}: objective integrity assessments; scope atomic/holistic, cadence triggered/continual/temporal; three families -- dependency gates, budgets, chaos experiments +- 2. \textbf{DORA}: four keys, elite performers lead on all four; loosely coupled architectures \emph{and teams} predict continuous delivery -- prediction, not causal proof +- 3. \textbf{Four-layer cascade} -- four falsification questions; the C10 reference contract, eight rows with thresholds and cadences +- 4. \textbf{Cost of change}: flat \emph{within}, steep \emph{across} architecture boundaries -- the contract, not the diagram, protects the investment +- 5. \textbf{AI lens}: fitness functions are the operating licence for agents (A); eval pass rate and token budget, two new types with old mechanics (B) +- 6. \textbf{Conway}: the fit is three-way; check D11 last but veto on it first; inverse Conway manoeuvre +- 7. \textbf{Six limits}: ordinal, context-dependent, hybrids, heterogeneous evidence, hidden organisation, AI-era volatility -- a hypothesis, not an authority +- 8. \textbf{Maxim 9}: skeleton, court of appeal, record, parole condition -- Part IV closes + +*Elements:* +- enumerate, \footnotesize, itemsep 2pt; every item capped at ~1.5 lines (deck 6 form); if still tight merge items 7 and 8 + +#### Frame 39: Next week + +*Kind:* nextweek -- *Source:* 'Next lecture' line of the assignment; semester plan row week 12; deck 6 next-week frame (lines 673-698) for the form -- *Minutes:* 1 + +- Left column heading -- \textbf{Lecture 12 -- Part V: two axes, one method} +- Axis A: Copilot vs METR -- two contradictory RCTs and their resolution; the verification bottleneck +- Axis A compact: architecture documentation as control interface, guardrails, the tool landscape and MCP, risks and accountability (\S 41.6--41.9) +- Axis B (I): the news-sentiment call wired the obvious way vs the right way; the three component types; the SE4AI classics +- Axis B (I): integration patterns -- reference architecture with the LLM gateway; eval-harness foundations +- Right column -- \textbf{Reading}: this week: Part IV, sections 37--39; ahead: Part V, sections 40--41, 42.1--42.5 +- \textbf{Exercise / deliverable}: coaching; AdvisorAgent $+$ 2--3 sub-agents behind the gateway (mandatory); ontology guard active on all insights + +*Elements:* +- two columns 0.55/0.42 as in deck 6; left column four bullets \small, bullet 2 may run to two lines; 'sections' lower-case as in decks 4-6 + +*Notes:* Week 12, 3 lessons -- not printed on the slide (deck 6 does not print week/lesson counts). Topic bullet 2 names \S 41.6-41.9 in full because deck 12 teaches all four subsections (its frames 15-22: control interface and AGENTS.md, guardrails, tool landscape/MCP/benchmark expiry date, risks and accountability, 14 min for 41.8-41.9 alone) and they are taught nowhere else -- do not trim this bullet to 'guardrails (compact)'. 'the SE4AI classics' (42.3) is likewise on the deck-12 agenda. + +#### Frame 40: Closing slide + +*Kind:* content -- *Source:* deck skeleton -- *Minutes:* 0 + +- \FHGRClosingPage: Thank you! -- Dr. Florian Herzog, Fachhochschule Graub\"unden, Chur -- AISE502 -- AI in Software Engineering II + +*Elements:* +- closing page macro as in deck 6 + +## Exercise frame: This week's exercise: resilience complete -- M4 closes + +- Coaching session (1 lesson). Resilience patterns on all external calls: timeout, retry, circuit breaker, fallback +- Graceful degradation verified +- Milestone M4 of the exercise sheet closes (end of week 11): deterministic core fully tested against the reference vectors and resilient +- Keep the deterministic core free of LLM calls -- this is the line that is graded +- Looking ahead (line below the box): the resilience row of the reference contract (kill one instance/broker under load -- SLO holds) is the fitness function that would verify what you build now -- it is not a graded deliverable + +## Summary frame + +1. Fitness functions: objective integrity assessments; scope atomic/holistic, cadence triggered/continual/temporal; three families -- dependency gates, budgets, chaos experiments +2. DORA: four keys, elite performers lead on all four; loosely coupled architectures and teams predict continuous delivery -- prediction, not causal proof +3. Four-layer cascade -- four falsification questions; the C10 reference contract, eight rows with thresholds and cadences +4. Cost of change: flat within, steep across architecture boundaries -- the contract, not the diagram, protects the investment +5. AI lens: fitness functions are the operating licence for agents (A); eval pass rate and token budget, two new types with old mechanics (B) +6. Conway: the fit is three-way; check D11 last but veto on it first; inverse Conway manoeuvre +7. Six limits: ordinal, context-dependent, hybrids, heterogeneous evidence, hidden organisation, AI-era volatility -- a hypothesis, not an authority +8. Maxim 9: skeleton, court of appeal, record, parole condition -- Part IV closes + +## Next-week frame + +**Lecture 12 -- Part V: two axes, one method** + +- Axis A: Copilot vs METR -- two contradictory RCTs and their resolution; the verification bottleneck +- Axis A compact: architecture documentation as control interface, guardrails, the tool landscape and MCP, risks and accountability (sections 41.6-41.9) +- Axis B (I): the news-sentiment call wired the obvious way vs the right way; the three component types; the SE4AI classics +- Axis B (I): integration patterns -- reference architecture with the LLM gateway; eval-harness foundations + +*Reading:* +- this week: Part IV, sections 37--39 +- ahead: Part V, sections 40--41, 42.1--42.5 + +*Exercise / deliverable:* +- coaching: AdvisorAgent + 2--3 sub-agents behind the gateway (mandatory) +- ontology guard active on all insights + +## Script boxes, tables and figures used + +| Element | Script location | Used in frame | +|---|---|---| +| definitionbox[Architectural fitness function] | part4_fit.tex 663-665 | 6 (first two sentences in the box; scope/cadence as a mini table with the script's examples) | +| enumerate: three worked instrument families | part4_fit.tex 669-673 | 7, 8, 9 | +| table tab:cascade | part4_fit.tex 685-703 | 14 (table), 13 (diagram from header/questions) | +| table tab:contract | part4_fit.tex 707-726 | 15 (rows 1-4), 16 (rows 5-8); thresholds also quoted on 8, 9, 10 | +| keypoint (standing experiment) | part4_fit.tex 735-737 | 19 | +| ailinse[Fitness functions as the operating licence for AI -- both axes] | part4_fit.tex 739-743 | 20 (Axis A), 21 (Axis B) | +| projektbox (submission must ship its contract) | part4_fit.tex 745-747 | 22 | +| keypoint (the fit is three-way) | part4_fit.tex 763-765 | 28 | +| enumerate: six limits | part4_fit.tex 775-782 | 29, 30, 31, 32, 33 | +| hinweisbox (authority vs hypothesis) | part4_fit.tex 784-786 | 34 | +| keypoint Maxim 9 | part4_fit.tex 788-790 | 35 | +| thinkbox (falsified or contract worked?) | part4_fit.tex 792-794 | 36 | + +## Open issues for the author + +- Dropped after review: the constructed scope x cadence instrument table (former frame 7) -- the script classifies scope only for three examples (dependency rule atomic; security/freshness holistic; chaos holistic) and gives the cost budget the cadence 'continual' only; the taxonomy is now shown once on frame 6 with the script's own examples. +- Inconsistency in the script to resolve before typesetting: chaos experiments are 'continual, holistic' in 37.1 (line 672) and in tab:cascade, but cadence 'temporal' in tab:contract (resilience row). Frames 9 and 16 show both as the script states them; decide whether the contract row should read 'temporal (scheduled drill)' or 'continual'. +- Recap frame draws on the deck-10 plan (summary frame 42 and Maxim-6 frame 15), deck 1 (A5), deck 2 (D5, D9, D11) and the deck-3 ADR-011 frame in addition to deck 6 and the semester plan, so that repeats on frames 7, 9, 11, 18, 19, 23, 24, 26 and 31 can carry recap tags; the assignment permits deck-6 text only -- keep or cut those tags. Bullet 1's L10 clause must be re-checked against the typeset deck-10 summary once it exists. +- Section 38 (Conway) has no thinkbox and no ailinse in the script, so the deck has no Discussion or AI Lens frame for Conway; if one is wanted, the script must supply it. +- Constructed boxes, not script boxes: the Prime Video examplebox (frame 4) and the DORA-caveat hinweisbox (frame 12) are built from running text (lines 657, 679) -- verbatim rephrasings, no new facts. No definitionbox is constructed for the Conway quotation (frame 23: highlighted line only). +- The qualitative cost-of-change sketch (former frame 19) was dropped: the script gives no curve data; frames 17-18 carry the argument in text and the two-column Boehm | Menzies layout. +- Evolution-layer instruments (Lehman indicators, change scatter, technical-debt inventory) appear only as table entries in tab:cascade -- the assigned passages do not explain them; frames 13/14 name them without elaboration. +- Frame 20 cites 'the empirical record shows AI adoption amplifying existing delivery dysfunction' (dora2025aireport) -- the script gives no figures; do not add any. +- Steps (vii) and (viii) refer to the eight-step procedure of Section 36 (Lecture 10, not yet typeset as a deck); recap bullet 1 now names the procedure, ADR-007 and Maxim 6 explicitly, so frames 5/30/36 can assume the step numbering is known -- it is not re-taught here. +- Frames 15-16 split tab:contract 4+4; if the typeset table fits comfortably, merging into one 8-row frame would free one slot -- the split is preferred so the eval-harness paragraph (line 705) has room on frame 16. +- Timing: content frames 4-36 sum to 120 min (not 125) so that the whole deck -- agenda 1, recap 3, exercise 4, summary 3, next week 1 -- stays at 132 min inside the 135-min slot; the reviewers' trims (discussion 5->3, coupling finding 5->4, cascade table 5->4, Conway opening 4->3, empirical anchor 4->3, limit 1 with lead-in, former overview and taxonomy frames removed) are applied. Frame count is exactly 40 -- the lower bound of the 40-46 band -- so frame 12 (DORA caveat, 2 min) must stay a frame; if time runs short, trim minutes on frames 6 (5 -> 4) and 15 (5 -> 4) instead, or fold frame 12 into 11 only together with splitting frame 25 (four team types / three interaction modes) so the count stays at 40. +- Frame 37 says 'M4 of the exercise sheet' (M4 Deterministic Core and Resilience, weeks 10-11); the semester plan's adjustment table (Semesterplan_AISE502_HS26.md line 43) still labels this milestone 'M3 Resilienz + deterministischer Kern' -- correct the semester plan. +- Next-week topics follow the deck-12 plan, not the semester-plan week-12 row: topic bullet 2 names \S 41.6-41.9 in full (control interface, guardrails, tool landscape and MCP, risks and accountability) because deck 12 teaches them on its frames 15-22 and they are taught nowhere else; 'the SE4AI classics' (42.3) is on the deck-12 agenda as well. The semester-plan week-12 row is the narrower document -- align it to the deck, not the slide to the row. + +--- + +# Lecture 12: The AI Dimension I -- Axis A Evidence, Axis B Foundations + +- **Week:** 12 -- **Lessons:** 3 -- **Frames:** 42 +- **Title-slide script line:** Script: Part V, Sections 40--41, 42.1--42.5 + +## Agenda + +1. Two axes, one method -- Assumption A6 falls due +2. Axis A: two contradictory RCTs and the empirical record +3. Reconciling the divergence; the verification bottleneck (Maxim 7); Axis A compact +4. Axis B: the news-sentiment call, wired the obvious way +5. The three component types; why containment: the SE4AI classics +6. The reference architecture: LLM gateway, queue, ontology guard +7. The eval harness as an engineering artefact +8. This week's exercise: AdvisorAgent + sub-agents behind the gateway + +## Recap: where we are + +- Parts I--IV complete; Lecture 11 closed Part IV: fitness functions -- three families (dependency gates, budgets, chaos experiments); the four-layer cascade and the eight-row C10 reference contract; cost of change flat within / steep across architecture boundaries; Conway -- the fit is three-way; six limits; Maxim 9 -- Part IV closed +- AI Lens threads so far -- deck 1: the two AI axes and Assumption A6; deck 3: an LLM component stresses D3, D10, D12; an agent drafts the ADR, a human owns the decision; ADR-011: all LLM calls through one gateway port +- Deck 6: C10 profile -- D12 = H, evals as the operative meaning of testability, cost per request; outlook: agent orchestration reuses the catalogue's topologies, workflows before agents (15x token finding); deck 11: fitness functions are the operating licence for agents (A); eval pass rate and token budget are fitness functions with old mechanics (B) +- Today: Part V redeems A6 systematically -- the two axes as one method; the Axis A evidence and its resolution; the Axis B foundations up to the eval harness +- Project: M4 delivered (deterministic core fully tested and resilient); M5 begins -- AdvisorAgent + 2--3 sub-agents behind the gateway, ontology guard active; the reference architecture today is just-in-time + +## Frame overview + +| # | Section | Frame title | Kind | Script ref | Min | +|---|---|---|---|---|---| +| 1 | Title | AISE502: AI in Software Engineering II -- Lecture 12: The AI Dimension I -- Axis A Evidence, Axis B Foundations | content | Title slide; metadata block copied from deck 6 (AISE502_Vorlesung_6_Folien.tex 116-120) | 0 | +| 2 | Agenda | Agenda | agenda | Deck skeleton; semester plan week 12 row (Semesterplan_AISE502_HS26.md line 23) | 1 | +| 3 | Recap | Recap: where we are | recap | Deck 11 summary frame 38 (bullets 1, 3, 4, 6, 7, 8) and AI Lens frames 20-21 (L11 plan); deck 6 summary and AI Lens frames (deck 6 lines 254-263, 498-521, 555-638); deck 3 lines 350-366, 560-606; semester plan row 12 (line 23); exercise sheet M4/M5 (project_exercise.tex 424-442) | 3 | +| 4 | Two Axes, One Method | Part V opens: the promissory note falls due | content | §40 intro (part5_ai_dimension.tex 10-12) | 3 | +| 5 | Two Axes, One Method | The two axes of the AI dimension | definition | §40 definitionbox (part5_ai_dimension.tex 14-21), fig:twoaxes (25-48), keypoint (50-52) | 4 | +| 6 | Axis A -- Evidence and Resolution | Case 1 -- the Copilot RCT: +55.8\,\% on a greenfield task | case | §41 intro + §41.1 (part5_ai_dimension.tex 60-65) | 4 | +| 7 | Axis A -- Evidence and Resolution | Case 2 -- the METR RCT: 19\,\% slower in your own mature codebase | case | §41.2 (part5_ai_dimension.tex 67-70); the 'So which study is wrong? Neither' paragraph (line 72) moves to frame 11 | 4 | +| 8 | Axis A -- Evidence and Resolution | The full empirical record, 2023--2025 | table | §41.3 intro + tab:aievidence (part5_ai_dimension.tex 77-103); Ziegler caution from the 'Field experiments at scale' paragraph (line 105) | 3 | +| 9 | Axis A -- Evidence and Resolution | The system level: DORA 2024 and 2025 | content | §41.3 paragraph 'The system level: DORA 2024 and 2025' (part5_ai_dimension.tex 107) | 3 | +| 10 | Axis A -- Evidence and Resolution | Code structure and practitioner trust in the longitudinal record | content | §41.3 paragraphs 'Code structure in the longitudinal record' and 'Practitioner trust' (part5_ai_dimension.tex 109-111) | 4 | +| 11 | Axis A -- Evidence and Resolution | Reconciling the divergence: five moderator variables | table | §41.2 closing paragraph (part5_ai_dimension.tex 72) as the intro; §41.4 intro + tab:moderators (113-134) | 4 | +| 12 | Axis A -- Evidence and Resolution | Discussion: which setting is yours? | discussion | §41.4 thinkbox (part5_ai_dimension.tex 136-138) | 4 | +| 13 | Axis A -- Evidence and Resolution | The verification bottleneck | content | §41.5 (part5_ai_dimension.tex 143-145) | 3 | +| 14 | Axis A -- Evidence and Resolution | Three consequences bind Axis A into the fit theory -- Maxim 7 | keyconcept | §41.5 enumerate + keypoint Maxim 7 (part5_ai_dimension.tex 147-155) | 4 | +| 15 | Axis A -- Control Interface and Guardrails | Architecture documentation as a control interface for agents | content | §41.6 text + lst:agentsmd (part5_ai_dimension.tex 160-188), condensed per semester plan ('Guardrails (kompakt)') | 4 | +| 16 | Axis A -- Control Interface and Guardrails | Guardrails as the precondition for safe agent use | content | §41.7 (part5_ai_dimension.tex 193-201), condensed | 3 | +| 17 | Axis A -- Control Interface and Guardrails | The tool landscape, soberly -- and the AI Lens on MCP | ailens | §41.8 intro, tool list, two standards + ailinse (part5_ai_dimension.tex 206-219), condensed | 4 | +| 18 | Axis A -- Control Interface and Guardrails | Benchmarks and their limits -- an expiry date on this section | content | §41.8 paragraph 'Benchmarks and their limits' + hinweisbox (part5_ai_dimension.tex 221-225) | 3 | +| 19 | Axis A -- Control Interface and Guardrails | Risks and responsibility: security, bias, skill, accountability | content | §41.9 paragraphs 'Security of generated code', 'Automation bias and skill formation', 'Accountability' (part5_ai_dimension.tex 230-234), condensed per semester plan ('kompakt') | 3 | +| 20 | Axis A -- Control Interface and Guardrails | Project link: Axis A governs how you build the platform | content | §41.9 projektbox (part5_ai_dimension.tex 236-238) | 2 | +| 21 | Axis B -- Component Types | Axis B opens: the news-sentiment call, wired the obvious way | case | §42 intro + §42.1 (part5_ai_dimension.tex 246-251) | 3 | +| 22 | Axis B -- Component Types | Five failures on schedule (1/2): latency, cost, non-determinism | case | §42.1 enumerate items 1-3 (part5_ai_dimension.tex 254-256) | 3 | +| 23 | Axis B -- Component Types | Five failures on schedule (2/2): drift, injection, diagnosis | case | §42.1 items 4-5 and closing paragraph (part5_ai_dimension.tex 257-261) | 3 | +| 24 | Axis B -- Component Types | The three component types -- one species, three profiles | definition | §42.2 intro + definitionbox 'AI runtime component' (part5_ai_dimension.tex 265-269) | 3 | +| 25 | Axis B -- Component Types | The three AI component types and their profiles | table | §42.2 tab:aicomponents (part5_ai_dimension.tex 271-288) | 3 | +| 26 | Axis B -- Component Types | Type (a): LLM components -- RAG, prompts, structured outputs | content | §42.2 paragraph 'Type (a): LLM components' (part5_ai_dimension.tex 290) | 3 | +| 27 | Axis B -- Component Types | Types (b) and (c) -- perishable models, heavy solvers | content | §42.2 paragraphs 'Type (b): classical ML components' and 'Type (c): optimisation components' (part5_ai_dimension.tex 292-294) | 3 | +| 28 | Axis B -- Component Types | Key concept: adding AI is a per-component matching problem | keyconcept | §42.2 keypoint (part5_ai_dimension.tex 296-298) | 2 | +| 29 | Axis B -- Containment | Why containment: the SE4AI classics -- hidden debt and CACE | definition | §42.3 (part5_ai_dimension.tex 303-309) | 3 | +| 30 | Axis B -- Containment | Three differences, 28 tests -- AI Lens: Parnas meets CACE | ailens | §42.3 Amershi paragraph + ailinse 'Parnas meets CACE' (part5_ai_dimension.tex 311-315) | 3 | +| 31 | Axis B -- Containment | The reference architecture -- the sentiment call, re-wired | diagram | §42.4 intro + fig:llmgateway (part5_ai_dimension.tex 320-385) | 7 | +| 32 | Axis B -- Containment | The elements justified (1/4): gateway, deterministic core | content | §42.4 itemize items 1-2 (part5_ai_dimension.tex 388-389) | 3 | +| 33 | Axis B -- Containment | The elements justified (2/4): queue, semantic cache | content | §42.4 itemize items 3-4 (part5_ai_dimension.tex 390-391) | 3 | +| 34 | Axis B -- Containment | The elements justified (3/4): model routing -- AI Lens | ailens | §42.4 item 5 + ailinse 'Model routing is a classical tactic in new clothes' (part5_ai_dimension.tex 392, 397-399) | 3 | +| 35 | Axis B -- Containment | The elements justified (4/4): stability, ontology as contract | content | §42.4 itemize items 6-7 (part5_ai_dimension.tex 393-394) | 3 | +| 36 | Axis B -- Containment | The eval harness -- definition and course thesis | definition | §42.5 intro, definitionbox 'Eval harness', keypoint 'The course thesis on testing AI' (part5_ai_dimension.tex 404-408, 419-421) | 3 | +| 37 | Axis B -- Containment | Four complementary evaluation strategies make a complete harness | content | §42.5 enumerate (part5_ai_dimension.tex 410-417) | 4 | +| 38 | Axis B -- Containment | Example: an eval harness for the portfolio platform | content | §42.5 examplebox + lst:evalharness (part5_ai_dimension.tex 423-453) | 3 | +| 39 | Closing | This week's exercise: AdvisorAgent + sub-agents behind the gateway | exercise | Exercise sheet M5 taskbox (project_exercise.tex 432-442) and hintbox (451-464); semester plan week 12 row (line 23); §41.9 projektbox (part5_ai_dimension.tex 236-238) | 3 | +| 40 | Closing | Summary | summary | Frames 4-38 | 2 | +| 41 | Closing | Next week | nextweek | Task brief 'Next lecture' line; semester plan week 13 row (line 24); exercise sheet M5 week 13 (project_exercise.tex 436-440) | 1 | +| 42 | Closing | Closing slide | content | Deck skeleton; closing block copied from deck 6 (AISE502_Vorlesung_6_Folien.tex 703-706) | 0 | + +## Frames in detail + +### Section: Title + +#### Frame 1: AISE502: AI in Software Engineering II -- Lecture 12: The AI Dimension I -- Axis A Evidence, Axis B Foundations + +*Kind:* content -- *Source:* Title slide; metadata block copied from deck 6 (AISE502_Vorlesung_6_Folien.tex 116-120) -- *Minutes:* 0 + +- \title[AI in Software Engineering II]{AISE502: AI in Software Engineering II} +- \subtitle{Lecture 12: The AI Dimension I -- Axis A Evidence, Axis B Foundations\\[0.4ex]{\small Script: Part V, Sections 40--41, 42.1--42.5}} +- \author{Dr.\ Florian Herzog}; \shortname{AISE502}; \fullname{Fachhochschule Graub\"unden, Chur -- Autumn Semester 2026} + +*Elements:* +- FHGR title page (theme) + +*Notes:* Copy deck 6 lines 116-120 verbatim and change only the subtitle. Institution typeset as Graub\"unden. + +### Section: Agenda + +#### Frame 2: Agenda + +*Kind:* agenda -- *Source:* Deck skeleton; semester plan week 12 row (Semesterplan_AISE502_HS26.md line 23) -- *Minutes:* 1 + +- 1. Two axes, one method -- Assumption A6 falls due +- 2. Axis A: two contradictory RCTs and the empirical record +- 3. Reconciling the divergence; the verification bottleneck (Maxim 7); Axis A compact +- 4. Axis B: the news-sentiment call, wired the obvious way +- 5. The three component types; why containment: the SE4AI classics +- 6. The reference architecture: LLM gateway, queue, ontology guard +- 7. The eval harness as an engineering artefact +- 8. This week's exercise: AdvisorAgent + sub-agents behind the gateway + +*Elements:* +- \small enumerate, as deck 6 lines 132-144 + +*Notes:* Eight one-line items (items 3 and 4 of the previous version merged). + +### Section: Recap + +#### Frame 3: Recap: where we are + +*Kind:* recap -- *Source:* Deck 11 summary frame 38 (bullets 1, 3, 4, 6, 7, 8) and AI Lens frames 20-21 (L11 plan); deck 6 summary and AI Lens frames (deck 6 lines 254-263, 498-521, 555-638); deck 3 lines 350-366, 560-606; semester plan row 12 (line 23); exercise sheet M4/M5 (project_exercise.tex 424-442) -- *Minutes:* 3 + +- Parts I--IV complete; Lecture 11 closed Part IV: fitness functions -- three families (dependency gates, budgets, chaos experiments); the four-layer cascade and the eight-row C10 reference contract; cost of change flat within / steep across architecture boundaries; Conway -- the fit is three-way; six limits; Maxim 9 -- Part IV closed +- AI Lens threads so far -- deck 1: the two AI axes and Assumption A6; deck 3: an LLM component stresses D3, D10, D12; an agent drafts the ADR, a human owns the decision; ADR-011: all LLM calls through one gateway port +- Deck 6: C10 profile -- D12 = H, evals as the operative meaning of testability, cost per request; outlook: agent orchestration reuses the catalogue's topologies, workflows before agents (15x token finding); deck 11: fitness functions are the operating licence for agents (A); eval pass rate and token budget are fitness functions with old mechanics (B) +- Today: Part V redeems A6 systematically -- the two axes as one method; the Axis A evidence and its resolution; the Axis B foundations up to the eval harness +- Project: M4 delivered (deterministic core fully tested and resilient); M5 begins -- AdvisorAgent + 2--3 sub-agents behind the gateway, ontology guard active; the reference architecture today is just-in-time + +*Elements:* +- \footnotesize bullets, five, each at most three lines (bullets 1 and 3 run to three); no box + +*Notes:* One frame only; name the AI Lens boxes, do not re-teach them. Bullet 1 condenses deck 11's summary bullets 1, 3, 4 and 8 (plus the Conway and six-limits bullets 6 and 7 as half-clauses); in speech, name the two AI rows of the C10 reference contract (AI correctness = eval-harness pass rate, triggered; AI cost = token budget per request, continual) -- they are the immediate predecessors of today's guardrails (frame 16) and eval harness (frame 36, 'thresholds in the measurement contract'). Bullet 3 ends with deck 11's two AI Lens frames, so the AI Lens thread now runs deck 1 -> 3 -> 6 -> 11 without a gap. + +### Section: Two Axes, One Method + +#### Frame 4: Part V opens: the promissory note falls due + +*Kind:* content -- *Source:* §40 intro (part5_ai_dimension.tex 10-12) -- *Minutes:* 3 + +- Leading question (italic, bankblue): Four parts built a complete decision theory without ever making artificial intelligence its subject -- does the construction survive the technology that defines its decade? +- Not a rhetorical flourish but a promissory note falling due: Part I issued it as Assumption A6 -- AI components extend the quality attribute space but do not change the method. The bet in two sentences: everything AI does to software engineering can be absorbed by the apparatus you now own +- If AI-bearing systems required a genuinely different method, the bet would be lost -- this part is where the claim must survive contact with the evidence +- Roadmap line: cases first, generalisation after -- two contradictory randomised experiments open Axis A (§41); one concrete LLM call, wired wrongly and then rightly, opens Axis B (§42); the matrix reading (§43) and the emergent pattern (§44) follow next week + +*Elements:* +- Leading question in italic bankblue; three \small bullets; no box (the keypoint moves to frame 5) + +*Notes:* Opening frame in the deck 4-6 style: question, one short paragraph, roadmap line. The list of apparatus items (scenarios, tactics, profiles, ADRs, fitness functions) is spoken here and printed on frame 5's caption line. + +#### Frame 5: The two axes of the AI dimension + +*Kind:* definition -- *Source:* §40 definitionbox (part5_ai_dimension.tex 14-21), fig:twoaxes (25-48), keypoint (50-52) -- *Minutes:* 4 + +- Definition (left column): Axis A -- AI as a tool in the SDLC. Code assistants, agentic coding tools, review bots participate in building the software: they generate code, tests, documentation, draft design artefacts. The software that ships may contain no AI at all. Unit of analysis: the development process and its economics +- Axis B -- AI as a runtime component. LLM services, trained ML models, optimisation solvers are part of the delivered system and execute in production. Unit of analysis: the running system and its quality attributes +- The axes are independent: a classical payroll system built with heavy agent support (A without B); a hand-crafted AI-native advisory platform (B without A). In practice, and in the course project, both apply simultaneously -- which is why they must be kept conceptually apart +- Figure (right column): Axis A (AI as tool: agents, assistants) -> Development process (specify, build, verify, operate), arrow 'shifts SDLC economics'; Axis B (AI as component: LLM, ML, solver) -> Delivered system (structure, quality attributes), arrow 'stretches quality attribute space'; process -> system 'produces' +- Caption line beneath the figure: Axis A changes how systems are built; Axis B what the built system contains -- both absorbed by the same method: scenarios, tactics, profiles, ADRs, fitness functions +- Key Concept (one \footnotesize line under both columns): Two axes, one method -- Axis A changes how systems are built, Axis B what they contain; the axes are independent and must be kept apart -- and both are analysed with the apparatus of Parts I--IV, nothing new + +*Elements:* +- definitionbox[The two axes of the AI dimension] (lines 14-21), \footnotesize, left column 0.52, each item at most two lines +- tikz fig:twoaxes (lines 25-48) redrawn in the right column 0.44: rounded rectangles, aiviolet for the two axis boxes, bankgreen process box, bankblue system box +- keypoint 'Two axes, one method' (lines 50-52) as one \footnotesize line spanning the frame bottom + +*Notes:* Two columns [T]. Definition first, key concept after it (script order, decks 4-6 order). If the keypoint box pushes the columns down, use \vspace{-1ex} and shorten the third definition item to one line. + +### Section: Axis A -- Evidence and Resolution + +#### Frame 6: Case 1 -- the Copilot RCT: +55.8\,\% on a greenfield task + +*Kind:* case -- *Source:* §41 intro + §41.1 (part5_ai_dimension.tex 60-65) -- *Minutes:* 4 + +- Leading question (italic): AI makes developers 55.8\,\% faster -- or 19\,\% slower. Which study is wrong? Both numbers come from randomised controlled trials, both methodologically sound; few topics in software engineering carry a larger gap between headline and evidence +- Case 1 (published 2023): 95 professional developers randomly split into two groups; same task -- implement an HTTP server in JavaScript; one group with GitHub Copilot, one without; the clock measured time to completion +- The treatment group finished 55.8\,\% faster +- Qualification 1: the confidence interval (21--89\,\%) is very wide -- the headline number is a point estimate, not a natural constant +- Qualification 2: a bounded, well-defined greenfield exercise -- no legacy context, no architectural constraints, no review process +- Qualification 3: speed was measured, not quality; completion rates did not differ significantly +- Within those bounds the result is real -- and it is the origin of the 'AI doubles productivity' headline genre + +*Elements:* +- Leading question in italic bankblue; \small bullets; the 55.8\,\% and the CI in bold. No \measured box (the macro is defined only in deck 2's preamble, line 114; deck 6's preamble does not carry it) + +*Notes:* Read as an experiment, not as a headline: setting first, finding second. All percentages typeset with the thin space \,\% throughout the deck. + +#### Frame 7: Case 2 -- the METR RCT: 19\,\% slower in your own mature codebase + +*Kind:* case -- *Source:* §41.2 (part5_ai_dimension.tex 67-70); the 'So which study is wrong? Neither' paragraph (line 72) moves to frame 11 -- *Minutes:* 4 + +- Leading question (italic): What happens when the same technology meets experts on their own terrain? +- 16 experienced open-source maintainers; 246 real issues in repositories they had maintained for years -- large, mature codebases (over a million lines) with high implicit quality standards; each issue randomly assigned to an AI-allowed condition (predominantly Cursor with frontier models of early 2025) or an AI-forbidden condition +- With AI, the developers took 19\,\% longer +- The perception data are the didactic core: forecast before the study +24\,\% speed-up; measured --19\,\%; post-hoc estimate +20\,\% faster -- even experts cannot validly introspect their own AI-assisted productivity +- METR's own explanation maps boundary conditions rather than refuting Case 1: deep repository familiarity left little for AI-supplied context to add; codebases large and conventionally dense; substantial time spent checking, repairing, discarding AI proposals + +*Elements:* +- Leading question in italic; the three perception numbers (+24\,\%, --19\,\%, +20\,\%) in bold; five \footnotesize bullets + +*Notes:* The perception gap is the single most instructive fact of the section -- dwell on it. Do not answer 'which study is wrong' here; the answer opens the moderator table (frame 11). + +#### Frame 8: The full empirical record, 2023--2025 + +*Kind:* table -- *Source:* §41.3 intro + tab:aievidence (part5_ai_dimension.tex 77-103); Ziegler caution from the 'Field experiments at scale' paragraph (line 105) -- *Minutes:* 3 + +- Intro (one \footnotesize line): the two cases are the extreme corners of a larger record -- seven strands, 2023--2025, from randomised experiments to organisational telemetry and longitudinal code analysis; read every row setting first, finding second +- Row Copilot RCT | 95 developers; greenfield HTTP server (JavaScript) | +55.8\,\% task speed (95\,\% CI 21--89\,\%); completion rate not significantly different +- Row Three field experiments | 4,867 developers; Microsoft, Accenture, Fortune-100 firm | +26.1\,\% completed tasks (s.e. 10.3\,\%); less experienced developers gain most +- Row METR RCT | 16 expert OSS maintainers; 246 real issues, own mature repositories | 19\,\% slower with AI -- while estimating afterwards that AI had made them 20\,\% faster +- Row DORA 2024 | ~3,000 respondents; organisational delivery level | +25\,\% AI adoption associated with --1.5\,\% throughput and --7.2\,\% delivery stability +- Row DORA 2025 | ~5,000 respondents | throughput association now positive; instability persists; AI acts as an amplifier of existing strengths and dysfunctions +- Row GitClear longitudinal | 211 million changed code lines, 2020--2024 | 4x growth in code duplication; moved-code share (the refactoring signature) collapsed from ~25\,\% to below 10\,\% +- Row Stack Overflow survey | >49,000 developers | 84\,\% use or plan to use AI; 46\,\% actively distrust its output; top frustration: 'almost right' code +- \scriptsize note line under the table: methodological caution from GitHub's own telemetry-plus-survey study -- the best predictor of perceived productivity is the suggestion acceptance rate, not the persistence of accepted code in the repository; much vendor-reported 'productivity' evidence measures perception, not verified output. Case 2's perception gap is the controlled-trial demonstration of the same fact + +*Elements:* +- 7-row scriptsize booktabs table Evidence | Setting | Finding with p{2.4cm}p{4.0cm}p{6.0cm} (12.4 cm) and \renewcommand{\arraystretch}{0.85}, Setting cells one line each, headline numbers in bold, from tab:aievidence lines 79-103; one \scriptsize note line beneath + +*Notes:* Former frame 9 dropped; its only non-duplicate content (the Ziegler acceptance-rate caution, line 105) is the note line under the table; the 'juniors and task novices benefit most' pattern is spoken with row 2. Compile-check the height; if it overflows, split (1/2) rows 1-3 experiments and (2/2) rows 4-7 organisation, code, survey (frame count 43, still in band). + +#### Frame 9: The system level: DORA 2024 and 2025 + +*Kind:* content -- *Source:* §41.3 paragraph 'The system level: DORA 2024 and 2025' (part5_ai_dimension.tex 107) -- *Minutes:* 3 + +- DORA measures neither task times nor perceptions but delivery performance at the level of the organisation -- throughput and stability -- exactly the level at which architecture acts +- 2024 (~3,000 respondents; 75.9\,\% use AI for at least part of their work, roughly three quarters report productivity gains) -- a 25\,\% increase in AI adoption is associated with: mini-table left column +7.5\,\% documentation quality, +3.4\,\% code quality, +3.1\,\% review speed | right column --1.5\,\% delivery throughput, --7.2\,\% delivery stability. Proposed mechanism is classical: more code per change, and larger batch sizes have been a documented risk driver for years +- 2025 (~5,000 respondents): adoption near saturation (90\,\%, median about two hours of daily use); more than 80\,\% report productivity gains; 30\,\% still express little or no trust in AI-generated code; the throughput association has turned positive as tools and practices matured -- the negative association with delivery stability persists +- Central metaphor: AI is an amplifier -- it magnifies the strengths of well-run organisations and the dysfunctions of badly run ones +- Individual acceleration and system-level performance are different quantities, and only the second one pays salaries + +*Elements:* +- \footnotesize bullets, five; the 2024 associations as a two-column \scriptsize mini-table (gains | losses) inside bullet 2 + +*Notes:* Connect to Lecture 11 (four DORA metrics) in speech only; do not add content beyond §41.3. + +#### Frame 10: Code structure and practitioner trust in the longitudinal record + +*Kind:* content -- *Source:* §41.3 paragraphs 'Code structure in the longitudinal record' and 'Practitioner trust' (part5_ai_dimension.tex 109-111) -- *Minutes:* 4 + +- GitClear, 211 million changed lines (2020--2024): duplicated code blocks (five or more lines) at four times their pre-AI level in 2024; moved lines -- the fingerprint of refactoring and modularisation -- fell from roughly 25\,\% to under 10\,\%: 2024 was the first year in which copy-paste exceeded code movement +- Churn -- code reworked or discarded within two weeks of commit -- rose from a pre-AI baseline of roughly 3--4\,\% to 5.7\,\% in 2024, trend continuing; two obligatory caveats: GitClear is a commercial analytics vendor, and the analysis is correlational -- AI's causal share is plausible but not isolated +- Converges with DORA's stability data: more code, produced faster, structurally worse maintained -- reuse by abstraction displaced by reuse by duplication, the opposite of what Parnas-style modularisation (Part II) works to achieve +- Stack Overflow 2025 (>49,000 developers): 84\,\% use or plan to use AI tools; 46\,\% actively distrust the accuracy of the output; most-cited frustration (45\,\%): 'almost right, but not quite' -- adoption rises while trust falls, consistent with METR and DORA: the effort has migrated from writing to verifying + +*Elements:* +- \footnotesize bullets, four; GitClear and Stack Overflow headline numbers in bold + +*Notes:* The 8.3\,\% -> 12.3\,\% copy-paste share, the 3\,\% high-trust figure and the 66\,\% 'more time fixing almost-right code' figure are spoken, not printed (the 66\,\% returns as 'two thirds' on frame 13). The last bullet is the bridge to the bottleneck frame. + +#### Frame 11: Reconciling the divergence: five moderator variables + +*Kind:* table -- *Source:* §41.2 closing paragraph (part5_ai_dimension.tex 72) as the intro; §41.4 intro + tab:moderators (113-134) -- *Minutes:* 4 + +- Intro (\footnotesize): So which study is wrong? Neither -- resolving the contradiction is the lesson: different populations (task novices versus domain experts in their own code), different codebases (greenfield versus mature), different tasks (bounded versus real issues) -- the results never actually compete; the resolution requires reading study designs, not abstracts +- The apparent contradictions dissolve once the studies are indexed by their moderator variables: Case 1 and Case 2 sit at opposite corners of a five-dimensional design space, and every other row of the record finds its place in the same coordinates +- Row Experience | juniors, task novices (Copilot RCT, field experiments) | domain experts in their own code (METR) +- Row Codebase | greenfield, small, standard stack | mature, large, dense implicit conventions +- Row Task | well-defined, bounded | under-specified, cross-cutting +- Row Measurement | task time, perceived productivity | delivery stability, maintainability, churn (DORA 2024, GitClear) +- Row Organisation | small batches, test automation, loose coupling | large batches, weak guardrails, tight coupling (DORA 2025) +- Closing line: the same technology yields +55.8\,\% and --19\,\% because the two cases differ on every one of the five rows + +*Elements:* +- 5-row footnotesize booktabs table Moderator | Gains high | Gains low or negative, p{2.2cm}p{5.0cm}p{5.2cm} (12.4 cm), from tab:moderators lines 118-134 + +*Notes:* This table is the intellectual answer to the leading question of frame 6 -- announce it as such; the intro paragraph is the script's own 'Neither' answer, moved here from Case 2. + +#### Frame 12: Discussion: which setting is yours? + +*Kind:* discussion -- *Source:* §41.4 thinkbox (part5_ai_dimension.tex 136-138) -- *Minutes:* 4 + +- The same class of technology produced +55.8\,\% in one randomised experiment and --19\,\% in another. Walk through the five moderators: on which rows do the two studies differ? +- Consider the systems you are likely to work on two years after graduation -- greenfield exercises, or mature codebases with implicit conventions? Which study's setting is closer to that reality? +- What does the METR perception gap (forecast +24\,\%, measured --19\,\%, post-hoc estimate +20\,\%) imply about relying on your own felt productivity as evidence? +- One-line codegray aside beneath the box (outside the thinkbox, marked 'Project transfer'): which moderator row describes your repository in week 12? + +*Elements:* +- thinkbox 'Discussion' with the script's three questions, \footnotesize; a \scriptsize codegray aside beneath it for the project transfer + +*Notes:* Four minutes of plenum discussion; keep the moderator table of frame 11 in speech. The project-transfer question is not script text -- it stays outside the box. + +#### Frame 13: The verification bottleneck + +*Kind:* content -- *Source:* §41.5 (part5_ai_dimension.tex 143-145) -- *Minutes:* 3 + +- The structural conclusion underneath the moderator table, in one sentence (centred, bold): code generation became cheap; specification, verification, and architecture became the binding constraints +- When the marginal cost of producing plausible code approaches zero, the scarce resource is no longer typing but everything that surrounds it: understanding the requirement precisely enough to specify it, reviewing and testing what was generated, and accepting responsibility for shipping it +- The strands converge: DORA -- individual acceleration coexists with delivery instability where control systems are weak; two thirds of surveyed developers spend more time on almost-right code; a substantial share of METR's slow-down is time spent checking, repairing, discarding AI proposals; industry analyses describe code review as the new bottleneck -- more and larger pull requests meeting unchanged human review capacity +- Economically put: AI lowers the cost of producing code, not the cost of taking responsibility for code + +*Elements:* +- \small bullets; the one-sentence conclusion set as a centred bold line + +*Notes:* Keep it sparse; the next frame carries the three consequences. + +#### Frame 14: Three consequences bind Axis A into the fit theory -- Maxim 7 + +*Kind:* keyconcept -- *Source:* §41.5 enumerate + keypoint Maxim 7 (part5_ai_dimension.tex 147-155) -- *Minutes:* 4 + +- 1. Architecture quality gates AI gains -- DORA 2025's core finding: teams in loosely coupled architectures with fast feedback loops convert AI adoption into throughput; tightly coupled systems with slow processes do not -- the AI-era echo of loosely coupled architectures and teams as the strongest predictor of continuous delivery performance (the coupling finding of Lecture 11) +- In the theory's vocabulary: D7 (evolvability) and D9 (testability and deployability) gain weight in every requirements profile -- architecture--application fit acquires a second reading: fit to a mode of work in which change volume rises by an order of magnitude +- 2. Architecture documentation becomes a control interface -- ADRs, repository convention files, and machine-readable rules are no longer passive records; agents execute them on every run (§41.6) +- 3. Fitness functions become the operating licence for agents -- an agent iterating against a dense test suite and CI-enforced architecture rules is contained; without them, every agent change is unpriced risk (§41.7) +- Key Concept -- Maxim 7: Good architecture was always the art of making change cheap and safe; AI raises the change rate by an order of magnitude -- and therefore raises, not lowers, the value of architecture + +*Elements:* +- numbered list \footnotesize +- keypoint box 'Maxim 7' (lines 153-155) verbatim + +*Notes:* Maxim 7 is examinable; set it apart visually. Each consequence 'is measurable' -- say so. The D7/D9 reading is the new content; the coupling finding is marked as Lecture 11's. + +### Section: Axis A -- Control Interface and Guardrails + +#### Frame 15: Architecture documentation as a control interface for agents + +*Kind:* content -- *Source:* §41.6 text + lst:agentsmd (part5_ai_dimension.tex 160-188), condensed per semester plan ('Guardrails (kompakt)') -- *Minutes:* 4 + +- Agentic tools are context-driven: they produce architecture-conformant code only if the architecture is explicit, machine-readable, and in the repository -- Part I's documentation artefacts, written for human readers, upgrade into a control interface for machine collaborators. ADRs (preferably MADR) serve agents twice: as input context (why is the system structured this way? which options were rejected, and why?) and as output format -- an agent drafts, a human decides and signs, per Assumption A1 (deck 3) +- Agent instruction files -- project-local CLAUDE.md and the vendor-neutral AGENTS.md (published 2025, adopted within months by over 60,000 open-source repositories) -- carry stack, conventions, build and test commands, module boundaries, no-go zones; loaded at every session start: documentation once 'too expensive to maintain for human readers' now amortises because it is executed on every agent run. Machine-checkable conventions (dependency directions, naming, layering) are a failing test rather than a prose exhortation -- the fitness-function discipline of Part IV +- The corollary cuts both ways: documentation debt is now reproduced at machine speed -- a stale convention file or ADR is executed by every agent session; DORA 2025: 'AI-accessible internal knowledge' and healthy data ecosystems rank among the seven capabilities that amplify AI benefits +- Listing (excerpt from the course project's agent instruction file): '# Portfolio Intelligence Platform -- agent instructions' +- '## Architecture (binding; see docs/adr/)' -- Modular monolith, module boundaries enforced by CI (see fitness_functions/boundaries_test.py). Do not add cross-module imports; use the module's public API. -- All LLM access goes through gateway/ -- never call a provider SDK from domain code (ADR-011) +- '## Verification (run before proposing changes)' -- make test (unit + module-boundary rules); make evals (eval harness; required for any change under prompts/ or gateway/) +- '## No-go zones' -- ledger/: append-only audit journal. Propose changes as an ADR draft instead of editing code +- One \scriptsize caption line beneath the listing: every line is a control statement that an agent executes on each run -- and that therefore must be kept as current as code + +*Elements:* +- three \footnotesize bullets (each at most three lines) above the listing; inline continuity marker '(deck 3)' in \scriptsize +- lstlisting lst:agentsmd (lines 170-188) full-width in a grey tcolorbox, \scriptsize\ttfamily, the three blank separator lines removed (14 code lines), as the ADR-011 frame of deck 3 (lines 560-576); one \scriptsize caption line beneath + +*Notes:* Former frames 15 and 16 merged (semester plan: 'Guardrails (kompakt)'). Just-in-time: students maintain exactly this file in M5. Point to ADR-011 and the eval-harness line, which foreshadows §42.5. Compile-check with pdftoppm: three footnotesize bullets (~8 lines) plus 14 listing lines at scriptsize must clear the footline; if they do not, drop bullet 3 (the corollary) to speech first, then fall back to the two-frame version (text frame + listing frame, frame count 43). + +#### Frame 16: Guardrails as the precondition for safe agent use + +*Kind:* content -- *Source:* §41.7 (part5_ai_dimension.tex 193-201), condensed -- *Minutes:* 3 + +- If verification is the scarce resource, then everything that automates verification multiplies the value of AI tooling -- and everything that leaves verification informal converts AI speed into instability +- Test suites are the operating licence: against a dense, fast test suite an agent can iterate -- wrong code fails immediately and is repaired or discarded at machine speed; without that net every agent-generated change ships unpriced risk (DORA's 'strong version control and test automation' amplifier pair) +- Architectural fitness functions fence the structure: an objective integrity assessment of an architectural characteristic is the machine-readable form of an architecture decision -- dependency rules, cycle checks, module-boundary verification as CI gates were good practice before AI; with agents in the loop they are the mechanism by which an architect constrains a collaborator who never attends design meetings +- The delivery pipeline becomes a defence instrument: static analysis, SAST, dependency and secret scanning, contract tests, progressive delivery move from hygiene to necessity -- the only controls that scale with generation volume +- Continuity with Part IV: nothing here is new machinery -- the measurement contract already demanded executable invariants; Axis A merely adds a new class of change producer whose volume makes the contract non-optional + +*Elements:* +- \footnotesize bullets, five + +*Notes:* Compact; refer back to Lecture 11's fitness-function taxonomy in speech. + +#### Frame 17: The tool landscape, soberly -- and the AI Lens on MCP + +*Kind:* ailens -- *Source:* §41.8 intro, tool list, two standards + ailinse (part5_ai_dimension.tex 206-219), condensed -- *Minutes:* 4 + +- Record the landscape as a geologist records a riverbed -- evidence of forces, not a map that stays accurate. Generation 2021--2023 (autocomplete-style assistants) suggested lines; generation 2024/2025 onwards plans, edits multiple files, runs builds and tests, iterates on failures -- agentic loops with tool access +- Claude Code (Anthropic): agentic CLI tool, research preview February 2025, GA May 2025; repository-level anchor CLAUDE.md +- Cursor (Anysphere): AI-first IDE with an agent mode; the dominant tool among the METR study's experts +- GitHub Copilot: Copilot Workspace retired May 2025; its concepts live on in the asynchronous Copilot coding agent (issues to pull requests, in CI) and the synchronous IDE agent mode +- Devin (Cognition): 'first AI software engineer' (2024); 13.86\,\% SWE-bench in March 2024 triggered the agent wave; acquired Windsurf July 2025 -- rapid market consolidation +- Two open standards matter more than any product, because they are architectural: Model Context Protocol (MCP, Anthropic, November 2024; JSON-RPC, servers expose tools, resources, prompts; adopted by OpenAI, Google DeepMind, Microsoft in 2025; December 2025 to the Agentic AI Foundation under the Linux Foundation; over 10,000 public servers) and AGENTS.md for project-level instructions; vendor SDKs extract the agent loop as a library -- the bridge to Axis B (§44, next week) +- AI Lens [MCP is ports-and-adapters at ecosystem scale]: strip the branding and MCP is a familiar shape -- a technology-neutral port (the protocol) with swappable adapters (servers wrapping databases, ticket systems, browsers), letting any conforming client use any conforming tool -- the role JDBC/ODBC played for databases. The hexagonal pattern of Part II did not become obsolete in the agent era; it became an ecosystem standard + +*Elements:* +- \footnotesize bullets, six (product bullets one line each, names in bold); ailinse[MCP is ports-and-adapters at ecosystem scale] (lines 217-219), condensed + +*Notes:* Former frames 19 and 20 merged. Announce that the examinable content is the pattern pair (sync pair-agent vs async task-agent), not product names -- the hinweisbox follows on frame 18. Ties back to deck 4's HX frames; the port/adapter vocabulary is exactly what the gateway frames reuse. If the box overflows, drop the parenthetical MCP adoption chronology to speech. + +#### Frame 18: Benchmarks and their limits -- an expiry date on this section + +*Kind:* content -- *Source:* §41.8 paragraph 'Benchmarks and their limits' + hinweisbox (part5_ai_dimension.tex 221-225) -- *Minutes:* 3 + +- SWE-bench: 2,294 real GitHub issues from twelve Python projects -- given repository and issue text, produce a patch that passes hidden tests. Trajectory: 1.96\,\% (best 2023 setup) -> 13.86\,\% (Devin, March 2024) -> around 77--81\,\% for frontier models by late 2025 on the human-validated 500-task SWE-bench Verified subset +- Four qualifications keep the number honest: (1) contamination -- the repositories are in the training data; (2) scope -- Python only, issues with tests only; (3) criterion -- 'tests pass' is not 'maintainable, architecture-conformant'; (4) saturation -- on the contamination-resistant SWE-bench Pro, frontier models initially scored around 23\,\%. Near-80\,\% benchmark scores next to METR's measured slow-down: the module's canonical exercise in benchmark literacy +- Important Note: this section encodes the state of early 2026; product names carry an expiry date measured in months (Copilot Workspace lived roughly a year). Stable -- and examinable -- are the patterns: the synchronous pair-agent versus the asynchronous task-agent as interaction modes, context files and ADRs as the control interface, fitness functions as the containment mechanism. Every concrete tool claim carries its own temporal fitness function: re-verify on every tool generation + +*Elements:* +- two \footnotesize bullets; hinweisbox (lines 223-225), condensed, \footnotesize + +*Notes:* Compressed to two SWE-bench bullets plus the hinweisbox; the box is the examinable part. + +#### Frame 19: Risks and responsibility: security, bias, skill, accountability + +*Kind:* content -- *Source:* §41.9 paragraphs 'Security of generated code', 'Automation bias and skill formation', 'Accountability' (part5_ai_dimension.tex 230-234), condensed per semester plan ('kompakt') -- *Minutes:* 3 + +- Security -- the evidence predates the agent wave and gains relevance with volume: roughly 40\,\% of 1,689 Copilot-generated programs (89 security-relevant scenarios) contained CWE top-25 vulnerabilities; a user study: participants with an AI assistant wrote less secure code on most tasks while believing their code to be more secure; package hallucination ('slopsquatting'): across roughly 576,000 generations, about a fifth of recommended package references did not exist -- names an attacker can register pre-emptively. Consequence: SAST, dependency and secret scanning, licence checks in CI are not optional; security review capacity must scale with generation volume +- Automation bias: over-trust in automated systems is a decades-old human-factors finding -- Perry et al.'s participants overestimated their security, METR's experts overestimated their speed +- Skill formation: a randomised study of engineers learning a new library -- AI assistance reduced comprehension-test scores by roughly 17\,\%; the usage pattern is the decisive moderator (conceptual questions preserved learning, wholesale delegation destroyed it); entry-level developer positions are measurably declining. For this module: the role being trained is the specifier, verifier, and architect -- rebuild the competence ladder deliberately, including AI-free practice of fundamentals +- Accountability: legally and professionally, the person who merges code answers for it, regardless of what generated it; AI tools are not liability-bearing entities -- treat AI output as the contribution of an unknown third party: mandatory review, provenance labelling, an explicit policy for permitted uses (DORA 2025: a clearly communicated AI policy first among the seven amplifier capabilities) +- AI may draft an ADR; a nameable person decides, signs, and defends it (deck 3) -- architecture is an accountability performance, not a text-production performance. IP risk open but manageable: Doe v. GitHub -- the DMCA claim dismissed in 2024, licence-related claims continue; response: provider duplication filters and indemnification, licence scanning in CI, a documented residual risk in the governance record + +*Elements:* +- \footnotesize bullets, five (bullets 1 and 3 up to three lines); the headline figures (40\,\%, less secure / more secure, one fifth of 576,000, --17\,\%, entry-level decline) in bold; 'architecture is an accountability performance' as a highlighted clause +- \scriptsize fallback for the bullets if the frame overflows + +*Notes:* Former frames 20 and 21 (risks 1/2 and 2/2) merged (semester plan: 'kompakt'). Address the students directly on the skill-formation bullet; it is the personal reading of Maxim 7. The ADR rule is one clause with the deck-3 marker; do not re-teach it. The 8.3 -> 12.3 copy-paste and 3\,\% high-trust figures stay in speech as before. + +#### Frame 20: Project link: Axis A governs how you build the platform + +*Kind:* content -- *Source:* §41.9 projektbox (part5_ai_dimension.tex 236-238) -- *Minutes:* 2 + +- Axis A governs how you build the Portfolio Intelligence Platform; the project applies every mechanism of this section +- (i) the repository carries an AGENTS.md / CLAUDE.md in the spirit of the listing -- and you are expected to keep it as current as code +- (ii) every architecture decision is an ADR -- agents may draft, but a named team member signs +- (iii) agent-generated changes enter the main branch only through the CI gate: module-boundary fitness functions, the test suite, and -- for anything touching prompts or the gateway -- the eval harness of §42.5 +- (iv) your project handbook contains a one-page AI policy: permitted tools, provenance labelling, review rules +- The graded artefact is not the generated code -- it is the control system around it + +*Elements:* +- projektbox (lines 236-238), \footnotesize, four numbered items plus the closing sentence in bold + +*Notes:* Closes the Axis A block; the closing sentence deserves emphasis before the break. + +### Section: Axis B -- Component Types + +#### Frame 21: Axis B opens: the news-sentiment call, wired the obvious way + +*Kind:* case -- *Source:* §42 intro + §42.1 (part5_ai_dimension.tex 246-251) -- *Minutes:* 3 + +- Leading question (italic): One of the platform's features is a single LLM call -- news in, sentiment out. Why not call it like any other function? +- Axis B moves AI from the workshop into the product; as always the case precedes the taxonomy: walk one concrete call end to end, watch what breaks, and name every break with a dimension you already own +- The feature: when a user opens a portfolio, the platform fetches the latest news items for its positions and asks an LLM, per item -- is this news positive, negative, or neutral for this holding, and why? One prompt, one structured answer: the simplest runtime AI component the course project owns +- Wired the obvious way: a provider-SDK call inside the request handler, synchronously in the page-rendering path +- Five failures arrive on schedule -- each landing on one of the twelve dimensions + +*Elements:* +- Leading question italic bankblue; optional small tikz strip: request handler -> provider SDK call -> page render (synchronous), grey boxes + +*Notes:* Keep the frame light; the failures get two frames of their own. + +#### Frame 22: Five failures on schedule (1/2): latency, cost, non-determinism + +*Kind:* case -- *Source:* §42.1 enumerate items 1-3 (part5_ai_dimension.tex 254-256) -- *Minutes:* 3 + +- Subtitle line (\scriptsize, codegray): the deck-3 AI Lens, now concrete +- 1. Latency (D3): the call takes seconds -- one to sixty-plus, depending on model and load -- where every other call in the handler takes milliseconds: the page now blocks on the slowest and least controllable component in the stack +- 2. Cost (D10): priced per token, so the feature bills per request -- every portfolio open costs real money; a loop over twenty positions is a twenty-fold cost regression the way an n+1 query is a latency regression. No classical component in the platform has this property +- 3. Non-determinism (D12): run the same article twice and the answers differ; sometimes an answer is garbage -- a score for a company not in the portfolio, a negative headline read as positive +- Wired synchronously, the component has none of the three things Part I said such a component needs: no queue to absorb its latency and outages, no port behind which a test can substitute a deterministic fake, no measurement point where the cost and quality of every call are observable + +*Elements:* +- numbered list \footnotesize, dimension codes in bold; subtitle marker line + +*Notes:* Deck 3's AI Lens (D3, D10, D12; queue/port/measurement point) is marked on-slide as the source; the case is that box made concrete. + +#### Frame 23: Five failures on schedule (2/2): drift, injection, diagnosis + +*Kind:* case -- *Source:* §42.1 items 4-5 and closing paragraph (part5_ai_dimension.tex 257-261) -- *Minutes:* 3 + +- 4. Drift (D7): the provider ships a new model version or deprecates the old one -- GA models carry deprecation windows of the order of six months -- and the component's behaviour changes without any local action: no commit, no deployment, no reviewable diff. The feature's behaviour is now co-owned by a third party +- 5. Injection (D6): the news article is untrusted input read by a component that cannot reliably separate instructions from data -- a crafted 'article' can carry instructions to the model; the feature has quietly opened an attack surface that no classical threat model in the platform covers (the attack surface in depth: §42.6, next week) +- Diagnosis (bold): nothing on this list is a bug in the model, and nothing on it is fixed by a better prompt -- every failure is a property of the wiring: a non-deterministic, fallible, latency-heavy, per-call-priced component was integrated as if it were deterministic, reliable, fast, and free +- The rest of the section generalises: the component taxonomy -> why containment, not mere integration (SE4AI classics) -> the reference architecture that re-wires the call correctly -> the test instrument for a component without exact assertions (eval harness) + +*Elements:* +- numbered list continued (4, 5), then a bold diagnosis line and a roadmap line + +*Notes:* The diagnosis sentence is the thesis of Axis B; give it its own visual weight. + +#### Frame 24: The three component types -- one species, three profiles + +*Kind:* definition -- *Source:* §42.2 intro + definitionbox 'AI runtime component' (part5_ai_dimension.tex 265-269) -- *Minutes:* 3 + +- The sentiment call is one instance of a species: for the first time, production systems contain building blocks that are non-deterministic, fallible, latency-heavy, priced per call, and capable of changing behaviour without any local action -- through model updates, data drift, or provider deprecation +- Thesis, prepared by Assumption A6: such components change no principle of software engineering but shift the weights in the quality attribute space -- and thereby the pattern choice; loose coupling, asynchronous integration, explicit contracts, and observability migrate from 'nice to have' to mandatory +- Industry speaks of compound AI systems (deck 6, C10) for exactly this reason: state-of-the-art results increasingly come from systems composed of models, retrievers, validators, and deterministic services rather than a single model call +- Definition [AI runtime component]: a component of the delivered system whose output is produced by a learned or search-based model rather than by explicitly programmed logic. Three types with systematically different engineering profiles: (a) LLM components for analysis, extraction, and generation over unstructured input; (b) classical ML components for classification and regression; (c) optimisation components (LP/MIP and constraint solvers, metaheuristics) +- The types differ exactly on the dimensions this theory measures -- determinism, latency, cost model, dominant risk, explainability -- and therefore demand different integration forms + +*Elements:* +- definitionbox[AI runtime component] (lines 267-269), \footnotesize + +*Notes:* Three bullets above the definition box; keep the definition box the visual centre. + +#### Frame 25: The three AI component types and their profiles + +*Kind:* table -- *Source:* §42.2 tab:aicomponents (part5_ai_dimension.tex 271-288) -- *Minutes:* 3 + +- Columns: Dimension | (a) LLM analysis / generation | (b) ML classification / regression | (c) Optimisation (LP/MIP/CP) +- Row Determinism | non-deterministic (even at T=0 only 'mostly') | deterministic after training | reproducible at fixed seed/threads/limit; variance in practice +- Row Latency | seconds (1--60+) | milliseconds possible | seconds to hours; anytime behaviour +- Row Cost model | per token/call (operating expenditure) | training expensive, inference cheap | compute + solver licence +- Row Dominant risk | hallucination, prompt injection, provider drift/deprecation | data/concept drift, training/serving skew | modelling errors, runtime explosion +- Row Explainability | low (generated justifications are themselves model output) | medium (feature importance) | high -- provable: optimality gap, duals, IIS +- Row Integration form | gateway + async + cache | serving endpoint + MLOps pipeline | job queue / batch worker +- Caption sense: each column implies a different integration form -- which is why 'add AI' is never a single architectural decision + +*Elements:* +- 6-row scriptsize booktabs table with p{2.0cm}p{3.5cm}p{3.3cm}p{3.5cm} (12.3 cm) from tab:aicomponents lines 276-287; 'high -- provable' in bold + +*Notes:* Read column-wise. Speaker guidance: (a) is the sentiment call and the AdvisorAgent's insights, (c) is your Optimization service; type (b) has no instance in the project -- the script says only that it belongs in every advisory platform (the exercise sheet's Performance/Risk/Optimization services are deterministic, project_exercise.tex 181-187). + +#### Frame 26: Type (a): LLM components -- RAG, prompts, structured outputs + +*Kind:* content -- *Source:* §42.2 paragraph 'Type (a): LLM components' (part5_ai_dimension.tex 290) -- *Minutes:* 3 + +- LLM components turn unstructured input -- documents, e-mails, reports -- into analyses, extractions, or generated text; three engineering building blocks define the type +- Retrieval-augmented generation (RAG): knowledge is moved out of the model weights into a swappable, versionable, inspectable data component -- updated by re-indexing rather than retraining, with provenance through citable sources +- RAG is an engineering problem, not a model problem: case-study evidence documents seven recurring failure points (missing content, failed ranking of the relevant documents, extraction and formatting errors, incomplete answers) -- with the sobering observation that RAG robustness evolves in operation rather than being designed in +- Prompts are configuration artefacts: version-controlled, regression-tested, behaviour-determining like code -- exactly the configuration-debt territory Sculley et al. mapped +- Structured outputs: since 2024 provider APIs can enforce, via constrained decoding, that outputs conform to a developer-supplied JSON schema -- syntactic correctness guaranteed; semantic correctness remains to be verified (reference architecture, eval harness) +- Lifecycle risk is the provider: GA models carry deprecation windows of the order of six months, shorter windows observed -- a hard-coded model name is a ticking dependency: an architectural statement, not an operational one + +*Elements:* +- \footnotesize bullets, six; the three building blocks (RAG, prompts, structured outputs) in bold + +*Notes:* The AdvisorAgent's insights are type (a); the ontology guard answers 'semantic correctness remains to be verified'. + +#### Frame 27: Types (b) and (c) -- perishable models, heavy solvers + +*Kind:* content -- *Source:* §42.2 paragraphs 'Type (b): classical ML components' and 'Type (c): optimisation components' (part5_ai_dimension.tex 292-294) -- *Minutes:* 3 + +- (b) Self-trained models (scoring, churn, fraud, forecasting) bring the full nine-stage workflow -- model requirements and data collection through training, evaluation, deployment, monitoring -- with dense feedback loops; characteristic problems: training/serving skew (divergent data preparation, one of the most frequent production failure sources) and data/concept drift (sudden, gradual, incremental, recurring) +- (b) A deployed model is a perishable good -- monitoring and retraining are operating requirements, not options; tooling: feature stores with consistent online/offline views, model registries versioning model, data, code, and configuration together, the MLOps discipline (maturity ladder: §43, next week) +- (c) Routinely overlooked in the SE4AI literature but belongs in every advisory platform: LP/MIP solvers, constraint programming (CP-SAT dominated recent MiniZinc Challenges, a complete gold-medal sweep in 2024), stochastic metaheuristics -- the profile inverts the LLM's: deterministic but heavy. Reproducible at fixed seed, thread count, time limit (run-to-run variability in practice); runtimes seconds to hours, often anytime behaviour -> asynchronous integration: job queue, status polling, callback; never a synchronous call in a web request path +- (c) Compensating strength: provable explainability -- optimality gap, dual values and shadow prices, and on infeasibility an irreducible infeasible subset (IIS): a minimal set of contradictory constraints as the explanation. In regulated domains the load-bearing argument for the project's division of labour: hard, auditable decisions belong to the solver and the deterministic services, not to the LLM + +*Elements:* +- \footnotesize bullets, four (each at most three lines); 'a deployed model is a perishable good' and 'deterministic but heavy' in bold + +*Notes:* Split off from the former type-(b)/(c) keypoint frame; the keypoint now has its own frame (28). + +#### Frame 28: Key concept: adding AI is a per-component matching problem + +*Kind:* keyconcept -- *Source:* §42.2 keypoint (part5_ai_dimension.tex 296-298) -- *Minutes:* 2 + +- One-line strip above the box (\footnotesize, dimension codes in bold): the three types differ exactly where the twelve dimensions measure -- determinism (D4) | latency (D3) | cost (D10) | auditability (D6) | testability (D9) +- Key Concept: 'We are adding AI' is therefore never one decision -- it is a per-component matching problem, answered with the same profile logic as everything else in this module. One rule spans all three types: contain the component behind an explicit boundary; never scatter it through the domain +- \scriptsize codegray aside beneath the box (project transfer): the sentiment call and the AdvisorAgent's insights are type (a); the Optimization service is type (c); type (b) has no instance in the project + +*Elements:* +- keypoint box (lines 296-298), verbatim-condensed, \footnotesize; one-line dimension strip above; one-line project aside beneath + +*Notes:* Author note: the script maps determinism to D4 here (line 297) while §42.1 (line 256) and the deck's frame 22 map non-determinism to D12, and tab:dimensions labels D4 'Consistency & transactional integrity' -- a script-internal tension; keep the script wording for fidelity and say in speech that the twelve-dimension table places non-determinism under D12. The project aside is a transfer, not script text; it stays outside the box. + +### Section: Axis B -- Containment + +#### Frame 29: Why containment: the SE4AI classics -- hidden debt and CACE + +*Kind:* definition -- *Source:* §42.3 (part5_ai_dimension.tex 303-309) -- *Minutes:* 3 + +- Two foundational results explain why AI components need architectural containment rather than mere integration +- Sculley et al. (2015) transferred the technical-debt metaphor to ML systems. Observation 1: only a small fraction of a real-world ML system is ML code -- the famous figure shows the model as a small black box amid large blocks of configuration, data collection, feature extraction, data verification, serving infrastructure, and monitoring. The system around the model is the actual engineering task -- precisely this module's perspective +- Observation 2: ML components resist modularisation +- Definition [CACE -- Changing Anything Changes Everything]: ML models entangle their input signals -- no feature is ever truly independent, so a change to one feature distribution, hyperparameter, or upstream data source changes the behaviour of the whole model. Architectural consequence: boundary erosion -- the strong abstraction boundaries on which modular design relies are systematically undermined by ML components +- Alongside the paper's system anti-patterns: glue code, pipeline jungles, dead experimental code paths, configuration debt, hidden feedback loops, undeclared consumers of model outputs + +*Elements:* +- definitionbox[CACE -- Changing Anything Changes Everything] (lines 307-309), \footnotesize + +*Notes:* Do not reproduce the Sculley figure (not in the script's assigned lines as a figure); describe it in words as the script does. + +#### Frame 30: Three differences, 28 tests -- AI Lens: Parnas meets CACE + +*Kind:* ailens -- *Source:* §42.3 Amershi paragraph + ailinse 'Parnas meets CACE' (part5_ai_dimension.tex 311-315) -- *Minutes:* 3 + +- Amershi et al. (Microsoft product teams) -- three fundamental differences between ML-based and classical development: (1) data discovery, versioning, labelling, and schema management are harder than and qualitatively different from code management, with no Git-equivalent of comparable maturity; (2) model customisation and reuse demand combined SE and ML competence; (3) AI components are harder to modularise than software modules -- entangled (CACE), non-monotonic error behaviour, poorly predictable interactions between models +- Operational counterpart -- the ML Test Score: a rubric of 28 concrete tests and monitoring requirements across data, model development, infrastructure, and monitoring, distilled from Google production experience: production readiness made measurable, and a ready-made checklist for the course project +- AI Lens [Parnas meets CACE]: Part II established Maxim 4 -- domain-oriented partitioning around anticipated change is the strongest single predictor of evolvability. CACE identifies a component class in which change anticipation fails inside the component: everything co-varies with everything. The resolution is not to abandon Parnas but to apply him one level up: if the component cannot be decomposed, the decomposition happens around it -- the module boundary goes where the entanglement stops, at the component's contract. That is the entire intellectual content of the gateway pattern, and it is sixty-year-old advice + +*Elements:* +- ailinse[Parnas meets CACE] (lines 313-315), condensed, \footnotesize + +*Notes:* The AI Lens is the conceptual hinge to the reference architecture: say 'the boundary goes where the entanglement stops' before showing the figure. + +#### Frame 31: The reference architecture -- the sentiment call, re-wired + +*Kind:* diagram -- *Source:* §42.4 intro + fig:llmgateway (part5_ai_dimension.tex 320-385) -- *Minutes:* 7 + +- One \scriptsize line above the figure: not new machinery but old machinery applied more strictly -- the correct re-wiring of the sentiment call: behind a typed port into the gateway (curing drift, containing injection); non-interactive volume onto the queue (curing latency, buying batch pricing); every call across one measurement point (cost and quality observable) +- Figure, left: Deterministic domain core -- decides and books; no provider SDK imports -- 'typed port' arrow into the gateway +- Figure, centre: LLM gateway (anti-corruption layer) with five internals -- prompt assembly + schema validation; model router (cheap -> expensive cascade); semantic cache; timeouts, circuit breakers, fallback chains; cost telemetry per request / feature / tenant +- Figure, right: Provider A (models m1, m2); Provider B (fallback); Local model (last-resort degradation) +- Figure, bottom: async job queue (batching, backpressure, retries) -> worker pool (bounded concurrency) -> gateway, fed by the core's 'non-interactive jobs'; every output -> Ontology / schema guard (entity resolution, domain axioms, citation check) -> 'validated result or rejection' back to the core; Eval harness (CI gate: prompts, models, providers) dashed to guard and gateway +- Caption-like line beneath: this is the topology your AdvisorAgent and sub-agents are wired into this week -- ADR-011 (deck 3) made structural + +*Elements:* +- tikz fig:llmgateway (lines 322-385) redrawn for 16:9: core bankblue, gateway frame aiviolet with five violet sub-boxes in a 2+3 grid, providers grey, queue/workers bankgreen, guard bankred, eval harness teal; \resizebox to 0.95\textwidth; one \scriptsize line above and one beneath + +*Notes:* Give the figure the whole frame; seven minutes for the walk-through (the 3 minutes freed by the kompakt merges of frames 15 and 19 are reinvested here). Walk in the order of the script's intro sentence (line 320): typed port into the gateway (curing drift, containing injection -- failures 4 and 5 of frame 23) -> the five gateway internals -> providers and fallback -> non-interactive volume onto the queue and worker pool (curing latency, buying batch pricing -- failure 1 of frame 22) -> every output through the ontology/schema guard -> the eval harness as CI gate; every call crosses one measurement point (cost and quality observable -- failures 2 and 3 of frame 22). Consider revealing the four stages with \onslide overlays (port, queue, guard, harness) so the re-wiring of the sentiment call is visible step by step; no content beyond the figure's labels and line 320 is added. Verify with pdftoppm that the 2+3 grid fits beside the providers. + +#### Frame 32: The elements justified (1/4): gateway, deterministic core + +*Kind:* content -- *Source:* §42.4 itemize items 1-2 (part5_ai_dimension.tex 388-389) -- *Minutes:* 3 + +- Anti-corruption layer / LLM gateway: from domain-driven design -- a translation layer that prevents a foreign system's model from corrupting one's own. Applied to LLMs: no domain code speaks to a provider API +- A facade owns the provider SDKs, prompt construction, schema validation, retry logic, model selection, and cost telemetry; the domain sees only a typed interface: \texttt{analyse\_report(document) -> RiskAssessment} +- Provider deprecation becomes an adapter task instead of a crisis; the facade is mockable in every test; as an industry pattern the gateway has consolidated into its own infrastructure layer -- the AI counterpart of the API gateway. In hexagonal terms the LLM is an adapter on a port -- the strongest single reason HX gains weight in the AI era +- Deterministic core, probabilistic edge: everything deterministically computable -- validation, aggregation, key-figure computation, authorisation, persistence, booking -- stays deterministic code; the LLM handles only what determinism cannot (language understanding, extraction from unstructured text, formulation). Keep the non-deterministic core as small as possible and push it to the edge +- Centred, highlighted design rule (the line that is graded): LLM agents propose; deterministic services decide and book + +*Elements:* +- \footnotesize bullets, four, each at most three lines; the typed signature in \texttt; the design rule as a highlighted centred line (bankblue, bold italic) + +*Notes:* Split off from the previous version's combined gateway/core/queue frame. The HX D12 '$++$' remark (the structural fact behind the $++$ in HX's D12 row) goes to speech or a one-line codegray aside. + +#### Frame 33: The elements justified (2/4): queue, semantic cache + +*Kind:* content -- *Source:* §42.4 itemize items 3-4 (part5_ai_dimension.tex 390-391) -- *Minutes:* 3 + +- Asynchronous integration: seconds-scale latency, rate limits, and outage risk put AI calls behind a queue wherever the domain allows -- the caller enqueues a job, a worker pool calls the model at a controlled degree of parallelism, results return by event or callback +- The queue buys backpressure instead of overload, retries without blocking users, smoothing of rate limits, and natural batching points: provider batch APIs process non-urgent volume at roughly 50\,\% discount within processing windows up to 24 hours (figure from deck 6 -- here placed where it lives: in the gateway) +- Axis B's direct coupling to EDA and PF (Part II) -- exactly the mechanisms their D12 rows priced at $++$ +- Semantic caching: instead of exact-match keys, requests are compared by embedding similarity, so semantically equivalent queries hit the cache +- The engineering point not to miss: a false-positive cache hit is a correctness risk, not a performance blemish -- the similarity threshold is a quality/cost regulator and belongs in the eval harness, not in a config file nobody reviews + +*Elements:* +- \footnotesize bullets, five, each at most three lines; 'correctness risk' in bold + +*Notes:* Link the queue to Lecture 11's resilience exercise and to deck 5/6 EDA/PF in speech. + +#### Frame 34: The elements justified (3/4): model routing -- AI Lens + +*Kind:* ailens -- *Source:* §42.4 item 5 + ailinse 'Model routing is a classical tactic in new clothes' (part5_ai_dimension.tex 392, 397-399) -- *Minutes:* 3 + +- Model routing: model choice per request is one of the largest cost levers in the stack -- cascades that start with the cheapest model and escalate only on insufficient answer quality report up to 98\,\% cost reduction at comparable quality; learned routers trained on human preference data cut cost by more than a factor of two without quality loss, generalising to unseen model pairs (figures from deck 6 -- here placed where they live: in the gateway) +- AI Lens [Model routing is a classical tactic in new clothes]: Part I defined tactics as the atomic units of architectural design. Routing traffic across a cheap and an expensive resource depending on demand is the ancient resource-arbitration tactic -- the FrugalGPT cascade is its token-economics incarnation. Note where it lives in the figure: in the gateway, as infrastructure, invisible to domain logic. A tactic that leaks into the domain layer stops being a tactic and starts being coupling + +*Elements:* +- one \footnotesize bullet; ailinse[Model routing is a classical tactic in new clothes] (lines 397-399), condensed, \footnotesize + +*Notes:* Deck 6's C10 frame already quoted the 98\,\% and factor-two figures as cost-model facts; the inline marker says so. + +#### Frame 35: The elements justified (4/4): stability, ontology as contract + +*Kind:* content -- *Source:* §42.4 itemize items 6-7 (part5_ai_dimension.tex 393-394) -- *Minutes:* 3 + +- Stability patterns transfer directly from the classical catalogue: timeouts (an LLM call without one blocks a thread for minutes); retries with exponential backoff -- only for idempotent calls and with cost awareness, since every retry burns tokens; circuit breakers per provider and model; fallback chains -- alternative model -> alternative provider -> cached or rule-based answer -> honest degradation ('analysis currently unavailable'); bulkheads separating interactive from batch quotas +- Only the failure semantics are new: a semantically unusable answer -- schema violation, suspected hallucination -- must trigger the error path exactly like an HTTP 500 +- Ontology and schema as contract -- the most effective systematic hallucination defence is layered: (1) structured outputs enforce syntax; (2) every extracted entity (account number, ISIN, customer name, key figure) is resolved against the deterministic data store -- unresolvable references are rejected, not passed on; (3) domain axioms hold as invariants -- sums add up, weights lie in [0,1], cited passages exist in the source document; (4) grounding via RAG makes citations mandatory +- The schema becomes a contract in the design-by-contract sense, and the gateway is the contract checker -- this is the ontology guard your project activates on all insights this week + +*Elements:* +- \footnotesize bullets, four; the four-layer defence as an inline numbered sequence + +*Notes:* Link to Lecture 11's resilience exercise (timeouts, retries, breakers, fallback on all external calls) in speech: the LLM provider is one more external call with token cost attached. + +#### Frame 36: The eval harness -- definition and course thesis + +*Kind:* definition -- *Source:* §42.5 intro, definitionbox 'Eval harness', keypoint 'The course thesis on testing AI' (part5_ai_dimension.tex 404-408, 419-421) -- *Minutes:* 3 + +- Non-determinism breaks the classical test idiom: \texttt{assert expected == actual} presupposes that equal inputs produce equal outputs. When that assumption falls, correctness must be redefined statistically -- 'correct in at least 95\,\% of the evaluation cases' -- and the team needs a test artefact of the first rank to carry that definition +- Definition [Eval harness]: a versioned suite of test cases, scoring logic, and statistical thresholds for a non-deterministic component, executed in the CI/CD pipeline like a test suite. It gates every prompt change, model update, and provider migration. Its thresholds are the response measures of the AI-related quality attribute scenarios (Assumption A4), and its pass rate is a fitness function in the measurement contract of Part IV +- Key Concept -- the course thesis on testing AI: the eval harness is to AI components what the test pyramid is to deterministic code -- the artefact that converts 'it seems to work' into a falsifiable, continuously executed claim. Without it, every model migration is a blind flight -- and given provider deprecation windows of months, migrations are not hypothetical. Statistical acceptance replaces exact assertion; the thresholds are architecture decisions and belong in the measurement contract + +*Elements:* +- definitionbox[Eval harness] (lines 406-408), \footnotesize +- keypoint box 'The course thesis on testing AI' (lines 419-421), condensed, \footnotesize + +*Notes:* Two boxes plus one intro bullet -- fits at \footnotesize. Recall deck 6: 'evals are the operative meaning of testability' (D9 = H for C10). + +#### Frame 37: Four complementary evaluation strategies make a complete harness + +*Kind:* content -- *Source:* §42.5 enumerate (part5_ai_dimension.tex 410-417) -- *Minutes:* 4 + +- 1. Regression against labelled references: a curated golden set of input/expectation pairs from the domain, scored with task-appropriate metrics (exact match or F1 on extracted fields, rubric scores for generated text); every prompt change, model update, and migration runs against this suite -- the direct counterpart of the regression test +- 2. LLM-as-judge: strong LLM judges agree with human preference judgements in over 80\,\% of cases -- the level of human--human agreement -- a scalable scoring instrument; biases to control for: position, verbosity, self-enhancement, weak reasoning grading. Conclusion: the judge is a measurement instrument that must itself be calibrated against human labels -- the judge needs its own eval +- 3. Domain axioms and property-based testing: instead of exact expected values, the harness checks properties that must hold for all valid outputs -- schema validity, referential integrity against the ontology, metamorphic relations (a paraphrased input must yield a semantically equivalent output), domain monotonicities; axioms catch failure classes that no finite golden set covers +- 4. Online evaluation: sampled human review, user feedback signals, drift monitoring of the eval metrics in production -- the LLM counterpart of model monitoring in the ML workflow + +*Elements:* +- numbered list \footnotesize; strategy names in bold; 'the judge needs its own eval' in italic + +*Notes:* Speaker notes carry the bias definitions (position bias: candidate order sways the verdict; verbosity bias: longer answers preferred; self-enhancement: judges favour their own outputs) and the countermeasures (position swapping, reference-guided judging), script line 414. + +#### Frame 38: Example: an eval harness for the portfolio platform + +*Kind:* content -- *Source:* §42.5 examplebox + lst:evalharness (part5_ai_dimension.tex 423-453) -- *Minutes:* 3 + +- One \footnotesize line above the listing: thresholds = response measures -- mean F1 >= 0.92 on the golden set | zero axiom violations | judge--human agreement kappa >= 0.70 (Cohen's chance-corrected measure) -- changing any of them is an architecture decision requiring an ADR; note what is absent: no assertion demands an exact output string +- Listing (stripped to 16 code lines: docstrings, blank lines and the comments that duplicate the bullets dropped): GOLDEN = load_cases("evals/portfolio_extraction_v3.jsonl") +- def test_extraction_regression(gateway): scores = [f1(gateway.extract(c.report), c.expected) for c in GOLDEN]; assert mean(scores) >= 0.92 # statistical threshold +- def test_domain_axioms(gateway, ontology): answer = gateway.advise(sample_portfolio()); for pos in answer.positions: assert ontology.resolves(pos.isin), f"unknown: {pos.isin}"; total = sum(p.weight for p in answer.positions); assert abs(total - 1.0) < 1e-6; for cit in answer.citations: assert cit.passage in source_text(cit.doc_id) +- def test_judge_is_calibrated(judge, human_labels): agreement = cohens_kappa(judge.score(GOLDEN), human_labels); assert agreement >= 0.70 # the judge's own eval +- Caption line: runs in CI on every change to prompts, models, or the gateway, alongside the deterministic test suite + +*Elements:* +- examplebox header (line 424) condensed to one \footnotesize line +- lstlisting lst:evalharness (lines 426-452) stripped to ~16 lines in a grey tcolorbox, \scriptsize\ttfamily, Python; one \scriptsize caption line beneath + +*Notes:* Verify the footline with pdftoppm before finalising. The docstrings ('Statistical acceptance, not exact assertion'; 'Properties that hold for ALL valid outputs'; 'LLM-as-judge is an instrument: calibrate it') are spoken per function. Point to week 13: this harness becomes the CI gate. + +### Section: Closing + +#### Frame 39: This week's exercise: AdvisorAgent + sub-agents behind the gateway + +*Kind:* exercise -- *Source:* Exercise sheet M5 taskbox (project_exercise.tex 432-442) and hintbox (451-464); semester plan week 12 row (line 23); §41.9 projektbox (part5_ai_dimension.tex 236-238) -- *Minutes:* 3 + +- Coaching slot (1 lesson). Milestone M5 -- Multi-Agent Orchestration, Evaluation, and Hardening (weeks 12--13) +- Mandatory this week: the AdvisorAgent orchestrates 2--3 sub-agents through contracts -- every LLM call through the gateway port (ADR-011); no provider SDK import in domain code +- Ontology guard active on all insights: entity resolution against the deterministic store, domain axioms, citation check -- unresolvable references are rejected, not passed on +- LLM agents propose; deterministic services decide and book -- keep the deterministic core free of LLM calls (the line that is graded) +- Closing line: Axis A discipline as on the project-link slide; week 13 turns the harness into a CI gate + +*Elements:* +- projektbox with four items plus one closing line, \footnotesize + +*Notes:* Items 5-7 of the previous version replaced by one closing line: the Axis A discipline is frame 20, the week-13 tasks and distinction work are frame 41. + +#### Frame 40: Summary + +*Kind:* summary -- *Source:* Frames 4-38 -- *Minutes:* 2 + +- 1. A6 falls due -- two axes, one method: Axis A changes how systems are built, Axis B what they contain; independent, kept apart, analysed with the apparatus of Parts I--IV +- 2. Copilot +55.8\,\% vs METR --19\,\%: neither wrong -- five moderators reconcile the record; the perception gap (+24 / --19 / +20) is the didactic core +- 3. System level: DORA -- throughput positive, instability persists, AI is an amplifier; GitClear -- duplication 4x, refactoring signature collapsed; adoption up, trust down +- 4. Verification bottleneck, Maxim 7: generation cheap, specification/verification/architecture binding; D7 and D9 gain weight in every profile +- 5. Axis A compact: documentation as control interface, fitness functions as operating licence, who merges answers; patterns examinable, products expire; MCP = ports-and-adapters +- 6. Axis B: the sentiment call fails on D3, D10, D12, D7, D6 -- properties of the wiring; three types = a per-component matching problem; CACE -> decompose around the component +- 7. Reference architecture: typed port -> gateway (routing, cache, stability, cost telemetry) -> queue -> ontology guard; eval harness = statistical acceptance, thresholds in the measurement contract + +*Elements:* +- \footnotesize numbered list, 7 points, each at most 1.5 lines, as deck 6 lines 660-671 + +*Notes:* Seven points trimmed to one-and-a-half lines each. + +#### Frame 41: Next week + +*Kind:* nextweek -- *Source:* Task brief 'Next lecture' line; semester plan week 13 row (line 24); exercise sheet M5 week 13 (project_exercise.tex 436-440) -- *Minutes:* 1 + +- Left column: \textcolor{bankblue}{\textbf{Lecture 13 -- Part V closes: security and law, the matrix shift, the eighth pattern, synthesis}} +- Left column \small bullet: OWASP LLM Top 10 and prompt injection; the EU AI Act as hard constraint +- Left column \small bullet: How AI shifts the matrix: the C10 row cell by cell, D12 across the seven patterns, which cells shift, MLOps maturity +- Left column \small bullet: Agent orchestration as the emergent eighth pattern: topologies, the economics of autonomy, capability-profile sketch +- Left column \small bullet: Synthesis: one theory, five parts; exam orientation +- Right column -- Reading: this week Part V, Sections 40--41, 42.1--42.5; ahead Part V, Sections 42.6--42.7, 43--45 +- Right column -- Exercise / deliverable: coaching; eval harness as CI gate; cost/latency observability; hardening; distinction work; \textbf{milestone: eval harness in CI + guard + cost observability} + +*Elements:* +- two columns 0.55/0.42 as deck 6 lines 673-698: bold bankblue lecture line + four \small bullets left; Reading and Exercise/deliverable right; \footnotesize if the topic bullets wrap beyond the column + +*Notes:* Verbatim in substance from the task brief; layout as decks 1-6. + +#### Frame 42: Closing slide + +*Kind:* content -- *Source:* Deck skeleton; closing block copied from deck 6 (AISE502_Vorlesung_6_Folien.tex 703-706) -- *Minutes:* 0 + +- \FHGRClosingPage[][{\color{white}\parbox{0.9\paperwidth}{\centering Thank you!\\[3ex] {\normalsize\mdseries Dr.\ Florian Herzog\\[0.9ex] Fachhochschule Graub\"unden, Chur\\[2.4ex] {\small AISE502 -- AI in Software Engineering II}}}}] + +*Elements:* +- FHGR closing page + +*Notes:* Copy deck 6 lines 703-706 verbatim (parbox and white text -- trap 1/2 from the deck memory). + +## Exercise frame: This week's exercise: AdvisorAgent + sub-agents behind the gateway + +- Coaching slot (1 lesson). Milestone M5 -- Multi-Agent Orchestration, Evaluation, and Hardening (weeks 12--13) +- Mandatory this week: the AdvisorAgent orchestrates 2--3 sub-agents through contracts -- every LLM call through the gateway port (ADR-011); no provider SDK import in domain code +- Ontology guard active on all insights: entity resolution against the deterministic store, domain axioms, citation check -- unresolvable references are rejected, not passed on +- LLM agents propose; deterministic services decide and book -- keep the deterministic core free of LLM calls (the line that is graded) +- Closing line: Axis A discipline as on the project-link slide; week 13 turns the harness into a CI gate + +## Summary frame + +1. A6 falls due -- two axes, one method: Axis A changes how systems are built, Axis B what they contain; independent, kept apart, analysed with the apparatus of Parts I--IV +2. Copilot +55.8\,\% vs METR --19\,\%: neither wrong -- five moderators reconcile the record; the perception gap (+24 / --19 / +20) is the didactic core +3. System level: DORA -- throughput positive, instability persists, AI is an amplifier; GitClear -- duplication 4x, refactoring signature collapsed; adoption up, trust down +4. Verification bottleneck, Maxim 7: generation cheap, specification/verification/architecture binding; D7 and D9 gain weight in every profile +5. Axis A compact: documentation as control interface, fitness functions as operating licence, who merges answers; patterns examinable, products expire; MCP = ports-and-adapters +6. Axis B: the sentiment call fails on D3, D10, D12, D7, D6 -- properties of the wiring; three types = a per-component matching problem; CACE -> decompose around the component +7. Reference architecture: typed port -> gateway (routing, cache, stability, cost telemetry) -> queue -> ontology guard; eval harness = statistical acceptance, thresholds in the measurement contract + +## Next-week frame + +**Lecture 13 -- Part V closes: security and law, the matrix shift, the eighth pattern, synthesis** + +- OWASP LLM Top 10 and prompt injection; the EU AI Act as hard constraint +- How AI shifts the matrix: the C10 row cell by cell, D12 across the seven patterns, which cells shift, MLOps maturity +- Agent orchestration as the emergent eighth pattern: topologies, the economics of autonomy, capability-profile sketch +- Synthesis: one theory, five parts; exam orientation + +*Reading:* +- this week: Part V, Sections 40--41, 42.1--42.5 +- ahead: Part V, Sections 42.6--42.7, 43--45 + +*Exercise / deliverable:* +- coaching; eval harness as CI gate; cost/latency observability; hardening; distinction work +- milestone: eval harness in CI + guard + cost observability + +## Script boxes, tables and figures used + +| Element | Script location | Used in frame | +|---|---|---| +| definitionbox 'The two axes of the AI dimension' | §40, part5_ai_dimension.tex 14-21 | 5 The two axes of the AI dimension | +| tikz fig:twoaxes | §40, part5_ai_dimension.tex 25-48 | 5 The two axes of the AI dimension (right column) | +| keypoint 'Two axes, one method' | §40, part5_ai_dimension.tex 50-52 | 5 The two axes of the AI dimension (one-line keypoint at the bottom) | +| table tab:aievidence | §41.3, part5_ai_dimension.tex 79-103 | 8 The full empirical record, 2023--2025 | +| table tab:moderators | §41.4, part5_ai_dimension.tex 118-134 | 11 Reconciling the divergence: five moderator variables | +| thinkbox (moderators, perception gap) | §41.4, part5_ai_dimension.tex 136-138 | 12 Discussion: which setting is yours? | +| keypoint 'Maxim 7' | §41.5, part5_ai_dimension.tex 153-155 | 14 Three consequences bind Axis A into the fit theory -- Maxim 7 | +| lstlisting lst:agentsmd | §41.6, part5_ai_dimension.tex 170-188 | 15 Architecture documentation as a control interface for agents (listing beneath the text) | +| ailinse 'MCP is ports-and-adapters at ecosystem scale' | §41.8, part5_ai_dimension.tex 217-219 | 17 The tool landscape, soberly -- and the AI Lens on MCP | +| hinweisbox (state of early 2026, expiry date) | §41.8, part5_ai_dimension.tex 223-225 | 18 Benchmarks and their limits -- an expiry date on this section | +| projektbox (Axis A governs how you build) | §41.9, part5_ai_dimension.tex 236-238 | 20 Project link: Axis A governs how you build the platform (referenced by the exercise frame 39) | +| definitionbox 'AI runtime component' | §42.2, part5_ai_dimension.tex 267-269 | 24 The three component types -- one species, three profiles | +| table tab:aicomponents | §42.2, part5_ai_dimension.tex 271-288 | 25 The three AI component types and their profiles | +| keypoint (three types differ where the twelve dimensions measure; contain behind a boundary) | §42.2, part5_ai_dimension.tex 296-298 | 28 Key concept: adding AI is a per-component matching problem | +| definitionbox 'CACE -- Changing Anything Changes Everything' | §42.3, part5_ai_dimension.tex 307-309 | 29 Why containment: the SE4AI classics -- hidden debt and CACE | +| ailinse 'Parnas meets CACE' | §42.3, part5_ai_dimension.tex 313-315 | 30 Three differences, 28 tests -- AI Lens: Parnas meets CACE | +| tikz fig:llmgateway (reference architecture) | §42.4, part5_ai_dimension.tex 322-385 | 31 The reference architecture -- the sentiment call, re-wired | +| ailinse 'Model routing is a classical tactic in new clothes' | §42.4, part5_ai_dimension.tex 397-399 | 34 The elements justified (3/4): model routing -- AI Lens | +| definitionbox 'Eval harness' | §42.5, part5_ai_dimension.tex 406-408 | 36 The eval harness -- definition and course thesis | +| keypoint 'The course thesis on testing AI' | §42.5, part5_ai_dimension.tex 419-421 | 36 The eval harness -- definition and course thesis | +| examplebox 'An eval harness for the portfolio platform' + lstlisting lst:evalharness | §42.5, part5_ai_dimension.tex 423-453 | 38 Example: an eval harness for the portfolio platform | + +## Open issues for the author + +- Minute budget: content frames 4-38 sum to 117 min; with agenda 1, recap 3, exercise 3, summary 2, next week 1 the total is 127 min for 135 -- the 8-min remainder is the reserve for the break. The former frame 9 was dropped, frames 19+20 and 22+23 of the previous version merged, and the freed time reinvested in the split frames 27/28 and 32/33; the cross-lecture review then merged frames 15+16 (§41.6 text + AGENTS.md listing) and 20+21 (risks 1/2 + 2/2) to honour 'Guardrails (kompakt)' -- §41.6-41.9 now take 6 frames / 16 min instead of 8 frames / 23 min -- and reinvested 3 of the 4 freed minutes in the reference-architecture walk-through (frame 31, now 7 min); the fourth minute went to the reserve. +- Density fallbacks that would raise the frame count (all still within the 40-46 band): frame 8 (tab:aievidence, seven rows at scriptsize with 12.4 cm columns) may need a (1/2)/(2/2) split -> 43 frames; frame 15 (merged §41.6 text + 14-line AGENTS.md listing at scriptsize) may need the corollary bullet moved to speech or, failing that, a re-split into text frame + listing frame -> 43 frames; frame 17 (merged landscape + MCP ailinse, six bullets plus box) may need the MCP adoption chronology moved to speech; frame 19 (merged risks, five footnotesize bullets) may need \scriptsize. +- fig:llmgateway is drawn for \textwidth portrait with five vertically stacked gateway sub-boxes; on a 16:9 frame (frame 31) it needs a redraw (gateway internals in a 2+3 grid, providers to the right, queue/guard/eval below) and a pdftoppm check; the walk-through now has 7 minutes and may use \onslide overlays for the four re-wiring stages; no content beyond the figure's labels and the §42.4 intro sentence is added. +- lst:evalharness is 26 lines in the script; the deck shows ~16 code lines (docstrings, blank lines and duplicating comments dropped) so that the one-line threshold header and the caption line fit; verify the footline with pdftoppm. +- Script-internal tension flagged for the author (frame 28 note): the §42.2 keypoint (line 297) maps determinism to D4, while §42.1 (line 256) maps non-determinism to D12 and tab:dimensions labels D4 'Consistency & transactional integrity'. The deck keeps the script wording; if the script is corrected, render the strip as 'determinism (D12)'. +- Two transfer lines are not script text and are placed outside the boxes as \scriptsize codegray asides: the project-transfer question under the discussion thinkbox (frame 12) and the 'which project component is which type' line under the keypoint (frame 28; type (b) has no instance in the project, since the exercise sheet defines Performance/Risk/Optimization as deterministic services). Drop both if strict verbatim is required. +- The \measured macro exists only in deck 2's preamble (line 114); frame 6 does not use it. If the author wants the grey 'Measured / Instrument' box, copy the macro definition into this deck's preamble. +- Failure 5 (injection, D6) in §42.1 cites OWASP; the deck names only the mechanism and defers OWASP/prompt-injection content to Lecture 13 (§42.6) as instructed -- the reference-architecture frame's 'containing injection' phrase is the script's own wording and is kept. +- The script's §40 roadmap names §43 (matrix reading) and §44 (agent pattern); the deck cites them only as 'next week'; likewise the MLOps maturity ladder (§43) mentioned in the type (b) paragraph is pointed to, not taught. +- There is no script thinkbox for §42.1-42.5, so the deck has a single Discussion frame (Axis A, frame 12). A second discussion on Axis B would have to be authored outside the script; not done here. +- Deck 6's C10 frames already quoted the 50\,\% batch discount, the 98\,\% cascade figure and the factor-two router figure; frames 33-34 repeat them with an inline '(figures from deck 6 -- here placed where they live: in the gateway)' marker -- intentional repetition, not new content. +- Frame titles are capped at ~68 characters; the exercise-frame title (66 characters, the reviewer's wording) and frame 37's title (64) are the longest -- check in the FHGR header at compile time and shorten frame 37 to 'Four evaluation strategies make a complete harness' if it wraps. The merged risks frame 19 was shortened to 63 characters ('automation bias' -> 'bias' in the title only; the bullet keeps 'Automation bias'). + +--- + +# Lecture 13: Threats, the Shifted Matrix, Agent Orchestration -- and Synthesis + +- **Week:** 13 -- **Lessons:** 3 -- **Frames:** 41 +- **Title-slide script line:** Script: Part V, Sections 42.6--42.7, 43--45 + +## Agenda + +1. Axis B completed: a new threat class (OWASP LLM Top 10, prompt injection) and regulation as a hard constraint (EU AI Act) +2. How AI shifts the matrix: the C10 row cell by cell, the D12 column, five shifted cells, MLOps maturity -- A6 restated +3. Agent orchestration -- the emergent eighth pattern: the advisor workflow, agent vs.\ workflow, topologies and their classical analogues +4. The economics of autonomy and the default rule; a capability-profile sketch +5. Synthesis: one theory, five parts -- Maxim 8 and the symmetry of the two axes +6. Exam orientation: the facts, the six learning objectives applied to the five parts, what to have at hand +7. This week's exercise: M5 closes -- eval harness in CI, guard, cost observability; threat model incl. prompt injection via news and basic hardening; optional distinction work (semester plan: Kür) + +## Recap: where we are + +- Part V is the framework's stress test on two axes: \textbf{Axis A} -- AI in the process (agentic tools, verification bottleneck, guardrails); \textbf{Axis B} -- AI in the product (non-deterministic, fallible, per-call-priced runtime components) +- Lecture 12 (§40--41, §42.1--42.5): Axis-A evidence -- two contradictory RCTs and their resolution; the \textbf{verification bottleneck} (Maxim 7: generation is cheap, verification and architecture are binding -- D7 and D9 gain weight); Axis A compact: documentation as control interface, fitness functions as operating licence, who merges answers; Axis B: sentiment call wired wrong and right; three component types; SE4AI classics; reference architecture (\textbf{LLM gateway} as single measurement point); eval-harness basics +- Already computed three times: the C10 verdict -- mini-match (Lecture 3), profile and real systems (Lecture 6), the full row with its cell rationales (Lecture 10; the $7 \times 10$ matrix itself was read in Lecture 7) +- Filed in advance (Lecture 6 outlook): agent orchestration is a \emph{composition pattern} reusing the catalogue's topologies; workflows before agents ($15\times$ token finding) -- today that claim is paid out in full +- Today completes Axis B (threats, regulation), shows how AI \emph{shifts} the matrix, develops the eighth pattern with its profile -- and closes the module: synthesis (Maxim 8) and exam orientation. This is the last lecture of new material; week 14: one lesson synthesis and exam hints, three lessons final presentations, architecture defence and peer reviews (A3, M6) + +## Frame overview + +| # | Section | Frame title | Kind | Script ref | Min | +|---|---|---|---|---|---| +| 1 | Title | AISE502: AI in Software Engineering II -- Lecture 13: Threats, the Shifted Matrix, Agent Orchestration -- and Synthesis | content | Title slide; subtitle line: Script: Part V, Sections 42.6--42.7, 43--45 | 0 | +| 2 | Agenda | Agenda | agenda | Semester plan row week 13 (Semesterplan_AISE502_HS26.md line 24) | 1 | +| 3 | Agenda | Recap: where we are | recap | Deck 12 (§40--41, §42.1--42.5 per task description; L12 plan summary; semester plan row 12); Maxim 7 and the verification bottleneck: part5_ai_dimension.tex 142-154 (line 142: 'code generation became cheap; specification, verification, and architecture became the binding constraints'; line 148: D7 and D9 gain weight in every requirements profile; lines 149-150: documentation as control interface, fitness functions as operating licence; line 234: 'the person who merges code answers for it'); deck 6 outlook frame (AISE502_Vorlesung_6_Folien.tex 498-521); deck 3/6/10 C10 computations; semester plan rows 7, 10, 14 | 3 | +| 4 | Axis B Completed -- Threats and Regulation | A new threat class -- OWASP Top 10 for LLM Applications (1/2) | table | §42.6 (part5_ai_dimension.tex 455-481) | 4 | +| 5 | Axis B Completed -- Threats and Regulation | A new threat class -- OWASP Top 10 for LLM Applications (2/2) | table | §42.6, tab:owasp (part5_ai_dimension.tex 460-481) | 3 | +| 6 | Axis B Completed -- Threats and Regulation | Prompt injection -- why the model cannot solve it | keyconcept | §42.6 hinweisbox (part5_ai_dimension.tex 483-485) | 3 | +| 7 | Axis B Completed -- Threats and Regulation | Regulation as a hard constraint: the EU AI Act | table | §42.7 (part5_ai_dimension.tex 487-490) | 4 | +| 8 | Axis B Completed -- Threats and Regulation | AI Act obligations -- K(a), not weights | table | §42.7 (part5_ai_dimension.tex 492) | 3 | +| 9 | How AI Shifts the Matrix | How AI shifts the matrix | content | §43 intro (part5_ai_dimension.tex 497-500) | 2 | +| 10 | How AI Shifts the Matrix | The C10 row -- which D12 mechanism each cell exercises | table | §43.1 (part5_ai_dimension.tex 502-507) | 4 | +| 11 | How AI Shifts the Matrix | D12 across the seven patterns | table | §43.2, tab:d12row (part5_ai_dimension.tex 509-532) | 4 | +| 12 | How AI Shifts the Matrix | Which existing cells shift, and why (1/2) | content | §43.3 (part5_ai_dimension.tex 534-542) | 4 | +| 13 | How AI Shifts the Matrix | Which existing cells shift, and why (2/2) | keyconcept | §43.3 + keypoint (part5_ai_dimension.tex 543-549) | 4 | +| 14 | How AI Shifts the Matrix | MLOps maturity: the three-level ladder | table | §43.4 (part5_ai_dimension.tex 551-554) | 3 | +| 15 | How AI Shifts the Matrix | When the pipeline promise is real: the fit-theoretical reading | keyconcept | §43.4 (part5_ai_dimension.tex 554) | 2 | +| 16 | How AI Shifts the Matrix | Assumption A6 restated as a falsifiable claim | keyconcept | §43.4 closing + keypoint (part5_ai_dimension.tex 556-560) | 3 | +| 17 | Agent Orchestration -- The Emergent Eighth Pattern | Agent orchestration -- the emergent eighth pattern | content | §44 intro (part5_ai_dimension.tex 565-568) | 2 | +| 18 | Agent Orchestration -- The Emergent Eighth Pattern | Case: the course project's advisor workflow | case | §44.1 (part5_ai_dimension.tex 570-573) | 4 | +| 19 | Agent Orchestration -- The Emergent Eighth Pattern | Strip the labels: a shape you know cell by cell | content | §44.1 (part5_ai_dimension.tex 573-575) | 3 | +| 20 | Agent Orchestration -- The Emergent Eighth Pattern | What an agent is -- and is not | definition | §44.2 definitionbox + guidance (part5_ai_dimension.tex 577-584) | 5 | +| 21 | Agent Orchestration -- The Emergent Eighth Pattern | Topologies and their classical analogues | table | §44.3, tab:agenttopology (part5_ai_dimension.tex 586-608) | 4 | +| 22 | Agent Orchestration -- The Emergent Eighth Pattern | Four topologies, drawn -- gates in code, judgement in the model | diagram | §44.3, fig:agenttopologies (part5_ai_dimension.tex 610-651) | 3 | +| 23 | Agent Orchestration -- The Emergent Eighth Pattern | The evaluation logic applies unchanged -- sharpened along three axes | content | §44.3 (part5_ai_dimension.tex 653) | 2 | +| 24 | Agent Orchestration -- The Emergent Eighth Pattern | Choosing a topology from the task signature | table | §44.3, tab:agentchoice (part5_ai_dimension.tex 655-671) | 4 | +| 25 | Agent Orchestration -- The Emergent Eighth Pattern | The economics of autonomy -- and the default rule | keyconcept | §44.4 + keypoint (part5_ai_dimension.tex 673-680) | 4 | +| 26 | Agent Orchestration -- The Emergent Eighth Pattern | Agent orchestration -- capability-profile sketch | table | §44.5, tab:agentprofile (part5_ai_dimension.tex 682-710) | 5 | +| 27 | Agent Orchestration -- The Emergent Eighth Pattern | Agent orchestration -- reading the sketch | keyconcept | §44.5 (part5_ai_dimension.tex 685, 712) | 3 | +| 28 | Agent Orchestration -- The Emergent Eighth Pattern | Project link: Axis B is what you build -- and what you build it as | content | §44.5 projektbox (part5_ai_dimension.tex 714-716) | 3 | +| 29 | Synthesis -- One Theory, Five Parts | What did AI change? Two temptations, one position | content | §45 intro (part5_ai_dimension.tex 721-724) | 3 | +| 30 | Synthesis -- One Theory, Five Parts | The script read backwards as a single argument (1/2): Parts I--III | content | §45 (part5_ai_dimension.tex 726) | 3 | +| 31 | Synthesis -- One Theory, Five Parts | The script read backwards as a single argument (2/2): Parts IV--V | content | §45 (part5_ai_dimension.tex 726) | 3 | +| 32 | Synthesis -- One Theory, Five Parts | Maxim 8 -- the pipeline of this script in one sentence | keyconcept | §45 keypoint (part5_ai_dimension.tex 728-730) | 2 | +| 33 | Synthesis -- One Theory, Five Parts | The deepest result: one discipline at two binding sites | content | §45 (part5_ai_dimension.tex 732) | 3 | +| 34 | Synthesis -- One Theory, Five Parts | Discussion: is it one discipline? | discussion | §45 thinkbox (part5_ai_dimension.tex 734-736) | 4 | +| 35 | Exam Orientation | The written examination -- the facts | content | Deck 1, 'Assessment' frame (AISE502_Vorlesung_1_Folien.tex 179-203) | 2 | +| 36 | Exam Orientation | Six learning objectives, five parts | table | Deck 1 'Learning objectives' frame (AISE502_Vorlesung_1_Folien.tex 167-177) mapped onto §45 synthesis (part5_ai_dimension.tex 726-730) | 4 | +| 37 | Exam Orientation | Open book: the map and the four tables | content | §45 keypoint (part5_ai_dimension.tex 728-730) and line 726; Part V additions from §43-44 tables; §43.3 keypoint (547-549); deck 1 assessment facts (179-203) | 3 | +| 38 | Closing | This week's exercise: M5 closes -- eval harness in CI, guard, cost observability; threat model, hardening, distinction work | exercise | Exercise sheet M5 taskbox week 13 and hintbox (project_exercise/project_exercise.tex 432-442, 451-464; week table lines 385-386); semester plan row 13 (Semesterplan_AISE502_HS26.md line 24: 'Hardening; Kür (autonomes Planning, Self-Repair, Model-Routing)') | 3 | +| 39 | Closing | Summary | summary | §42.6-42.7, §43, §44, §45 (part5_ai_dimension.tex 455-736) | 3 | +| 40 | Closing | Next week | nextweek | Semester plan rows 13-14 (Semesterplan_AISE502_HS26.md lines 6, 24-25); deck 1 'semester at a glance' row 14 (line 215) and assessment frame (179-203); exercise sheet M6 taskbox (project_exercise/project_exercise.tex 444-449) | 1 | +| 41 | Closing | Closing page | content | Deck 6 closing page (theme) | 0 | + +## Frames in detail + +### Section: Title + +#### Frame 1: AISE502: AI in Software Engineering II -- Lecture 13: Threats, the Shifted Matrix, Agent Orchestration -- and Synthesis + +*Kind:* content -- *Source:* Title slide; subtitle line: Script: Part V, Sections 42.6--42.7, 43--45 -- *Minutes:* 0 + +- \FHGRTitlePage with subtitle as in deck 6: \subtitle{Lecture 13: Threats, the Shifted Matrix, Agent Orchestration -- and Synthesis\\[0.4ex]{\small Script: Part V, Sections 42.6--42.7, 43--45}} + +*Elements:* +- FHGR title page (theme) + +*Notes:* Identical metadata block to deck 6 (author, shortname, fullname). Subtitle shortened to one clause (~70 characters) so it does not wrap to three lines on the FHGR title page. + +### Section: Agenda + +#### Frame 2: Agenda + +*Kind:* agenda -- *Source:* Semester plan row week 13 (Semesterplan_AISE502_HS26.md line 24) -- *Minutes:* 1 + +- 1. Axis B completed: a new threat class -- OWASP LLM Top 10, prompt injection; regulation as a hard constraint -- the EU AI Act +- 2. How AI shifts the matrix: the C10 row cell by cell; D12 across the seven patterns; five shifted cells; MLOps maturity; A6 restated +- 3. Agent orchestration -- the emergent eighth pattern: the advisor workflow; agent vs.\ workflow; topologies and classical analogues +- 4. The economics of autonomy and the default rule; a capability-profile sketch +- 5. Synthesis: one theory, five parts -- Maxim 8; one discipline at two binding sites +- 6. Exam orientation +- 7. This week's exercise: \textbf{M5 closes} -- eval harness in CI, guard, cost observability; threat model incl.\ prompt injection via news $+$ basic hardening; optional distinction work (K\"ur) + +*Elements:* +- \small enumerate with \itemsep 1pt, as in deck 6 + +#### Frame 3: Recap: where we are + +*Kind:* recap -- *Source:* Deck 12 (§40--41, §42.1--42.5 per task description; L12 plan summary; semester plan row 12); Maxim 7 and the verification bottleneck: part5_ai_dimension.tex 142-154 (line 142: 'code generation became cheap; specification, verification, and architecture became the binding constraints'; line 148: D7 and D9 gain weight in every requirements profile; lines 149-150: documentation as control interface, fitness functions as operating licence; line 234: 'the person who merges code answers for it'); deck 6 outlook frame (AISE502_Vorlesung_6_Folien.tex 498-521); deck 3/6/10 C10 computations; semester plan rows 7, 10, 14 -- *Minutes:* 3 + +- Part V is the framework's stress test on two axes: \textbf{Axis A} -- AI in the process; \textbf{Axis B} -- AI in the product (components that are non-deterministic, fallible, latency-heavy, priced per call) +- Lecture 12 (§40--41, §42.1--42.5): Axis-A evidence -- two contradictory RCTs and their resolution; the \textbf{verification bottleneck} (Maxim 7: generation is cheap, verification and architecture are binding -- D7 and D9 gain weight); Axis A compact: documentation as control interface, fitness functions as operating licence, who merges answers; Axis B: sentiment call wired wrong and right; three component types; SE4AI classics; reference architecture (\textbf{LLM gateway} as single measurement point); eval-harness basics +- The C10 verdict has been computed three times: mini-match (L, MM, MS -- Lecture 3), profile and real systems (Lecture 6), the full row with its cell rationales (Lecture 10; the $7 \times 10$ matrix itself was read in Lecture 7) +- Lecture 6 filed the outlook: agent orchestration is a \emph{composition pattern} reusing the catalogue's topologies -- workflows before agents ($15\times$ tokens). Today that claim is paid out +- Today: Axis B completed (threats, regulation) $\to$ how AI \emph{shifts} the matrix $\to$ the eighth pattern with a profile sketch $\to$ synthesis and exam orientation. \textbf{The last lecture of new material}; week 14: one lesson synthesis and exam hints, three lessons final presentations, architecture defence and peer reviews (A3, M6) + +*Elements:* +- \footnotesize itemize; one-line running map below the bullets: 'tenth class (done) -- twelfth dimension (done) -- shifted cells (today) -- one composition pattern (today)' -- the four absorption forms of §43.4 closing paragraph (line 556); frame 9 refers back to this map + +*Notes:* Emitted between Agenda and the first \section, as in decks 2, 3, 5 -- no \section{Recap}. Do not re-teach the gateway figure; name it only. The week-14 wording follows the semester plan row 14 ('1 L Synthese + 3 L Präsentationen'), deck 1's 'semester at a glance' row 14 and the exercise sheet. Bullet 2 now names Maxim 7 (the verification bottleneck) and the Axis-A compact block, because frame 33 ('one discipline at two binding sites') and Maxim 8 build directly on Maxim 7; it must stay within four lines at \footnotesize -- if it overflows, drop 'two contradictory' and the parenthetical '(§40--41, §42.1--42.5)' before touching the Maxim-7 clause. + +### Section: Axis B Completed -- Threats and Regulation + +#### Frame 4: A new threat class -- OWASP Top 10 for LLM Applications (1/2) + +*Kind:* table -- *Source:* §42.6 (part5_ai_dimension.tex 455-481) -- *Minutes:* 4 + +- \emph{\textcolor{bankblue}{AI components add an attack surface that classical threat models do not cover.}} (first sentence of §42.6, verbatim, line 458) +- The OWASP Top 10 for LLM Applications 2025 codifies it; the script pairs each risk with its \textbf{architectural} counter-measure -- deliberately, because the defence is \emph{structural, not model-internal} +- Table rows LLM01--LLM05: LLM01 Prompt injection (direct and indirect) -- defence in depth: privilege separation, output validation, human-in-the-loop for sensitive actions +- LLM02 Sensitive information disclosure -- data minimisation in prompts; output filtering at the gateway +- LLM03 Supply chain -- vetting of models, weights, and dependencies; registry discipline +- LLM04 Data and model poisoning -- data governance and provenance for training/index data +- LLM05 Improper output handling -- treat output as untrusted input: schema validation, encoding, ontology guard + +*Elements:* +- Table (footnotesize, booktabs, p{1.2cm}p{4.2cm}p{7.2cm}): ID | Risk | Architectural counter-measure -- rows LLM01--LLM05 from tab:owasp, lines 460-481 + +*Notes:* Split the 10-row table into two frames (5 rows each) so the counter-measure column keeps its full wording. §42.6 has no italic leading question in the script; the opener is the section's declarative first sentence verbatim. Speaker question (not on the slide): 'where does the defence live, if not in the model?' -- the table answers it row by row. The remark that most counter-measures are elements of the Lecture-12 gateway figure belongs to the footer of frame 5 only. + +#### Frame 5: A new threat class -- OWASP Top 10 for LLM Applications (2/2) + +*Kind:* table -- *Source:* §42.6, tab:owasp (part5_ai_dimension.tex 460-481) -- *Minutes:* 3 + +- LLM06 Excessive agency -- least-privilege tool design; deterministic services own irreversible actions +- LLM07 System prompt leakage -- no secrets or authorisation logic in prompts +- LLM08 Vector and embedding weaknesses -- access control and tenant isolation on the retrieval index +- LLM09 Misinformation -- grounding with mandatory citations; domain-axiom checks +- LLM10 Unbounded consumption -- rate limits, token budgets, cost circuit breakers per tenant +- Footer line (\footnotesize): \emph{most counter-measures are elements of the gateway architecture of Lecture 12} (caption of tab:owasp, line 462) + +*Elements:* +- Table (footnotesize, booktabs, same column widths as 1/2): rows LLM06--LLM10 from tab:owasp, lines 460-481; one-line footer + +*Notes:* Point out that three of the four defence elements of the next frame carry OWASP IDs (LLM06, LLM05, LLM10). Project link (verbal): this table is the checklist for this week's threat model. + +#### Frame 6: Prompt injection -- why the model cannot solve it + +*Kind:* keyconcept -- *Source:* §42.6 hinweisbox (part5_ai_dimension.tex 483-485) -- *Minutes:* 3 + +- \textbf{Important Note (hinweisbox, condensed):} prompt injection is not fully solvable inside the model, because LLMs process instructions and data in the \emph{same channel} +- Any document, e-mail, or web page the system reads can carry instructions (``ignore your previous rules and \dots'') -- and no reliable in-model separator exists +- The defence is therefore \textbf{defence in depth at the system level}: least-privilege tools (LLM06), output validation (LLM05), human approval for consequential actions, consumption limits (LLM10) +- This is the security-flavoured restatement of the section's design rule: \textbf{the architecture, not the model, is the trust boundary} +- For the course project, concretely: no LLM output may reach the booking path without passing the \textbf{ontology guard}; no agent tool may perform an \textbf{irreversible action} + +*Elements:* +- hinweisbox 'Important Note' with the condensed text (lines 483-485); the project consequence as the last line inside the box (it is part of the hinweisbox) + +*Notes:* Connect to deck 6 'C10 -- the binding scenarios' footer (defence in depth is constitutive) without re-teaching it. Keep the frame to the hinweisbox plus nothing else. + +#### Frame 7: Regulation as a hard constraint: the EU AI Act + +*Kind:* table -- *Source:* §42.7 (part5_ai_dimension.tex 487-490) -- *Minutes:* 4 + +- Lead-in: regulation closes the quality-attribute loop with legal force -- \textbf{Regulation (EU) 2024/1689}, the AI Act, entered into force on 1 August 2024; a risk-based approach with four classes: +- Left table (Class | Examples / duties): \textbf{Unacceptable risk} | prohibited practices, e.g.\ social scoring +- \textbf{High risk} | Annex III use cases: creditworthiness assessment, employment, critical infrastructure -- duties: risk management, data governance, documentation, logging, oversight, accuracy/robustness/cybersecurity +- \textbf{Limited risk} | transparency duties: labelling AI interaction and generated content +- \textbf{Minimal risk} | -- +- Right table (Date | What applies): 2 Feb 2025 -- prohibitions; AI-literacy duties $\cdot$ 2 Aug 2025 -- governance; GPAI duties $\cdot$ 2 Aug 2026 -- general applicability incl.\ Annex III high-risk $\cdot$ 2 Aug 2027 -- high-risk AI in regulated products + +*Elements:* +- Two-column layout (0.55 / 0.42): left = 4-row \scriptsize table 'Class | Examples / duties' from line 490; right = 4-row \scriptsize timetable 'Date | What applies', one line per row, from line 490 + +*Notes:* The script gives 'minimal risk' without a gloss -- print it without one; the lecturer may say 'no specific duties' as own knowledge. Spoken, not on the slide: the 2 Aug 2026 general-applicability date has passed by the time of this lecture. + +#### Frame 8: AI Act obligations -- K(a), not weights + +*Kind:* table -- *Source:* §42.7 (part5_ai_dimension.tex 492) -- *Minutes:* 3 + +- For this theory the AI Act has a precise, limited role: its obligations are \textbf{quality attributes with legal force} that enter the requirements profile as \textbf{hard constraints K(a), not as weights} -- Part I: constraints are knock-out filters, never averaged away +- A finance-related advisory platform -- class C10, particularly with any \emph{creditworthiness} bearing -- can fall into the \textbf{high-risk} class +- Then logging of agent steps, technical documentation, human oversight, and demonstrated robustness stop being engineering preferences and become \textbf{conditions of legal operation} +- Table: \textbf{logging} | gateway telemetry $+$ audit journal $\cdot$ \textbf{human oversight} | human-in-the-loop interfaces at the determinism boundary $\cdot$ \textbf{robustness} | fallback chains $+$ eval harness +- \textbf{Key Concept (one line):} compliance, correctly designed, is not a parallel work stream -- it is the same architecture, documented + +*Elements:* +- Three short bullets (\footnotesize); 3-row \footnotesize table 'Obligation | Architectural element it lands on' from line 492; one-line keypoint + +*Notes:* Tie back to deck 6 C10 profile row 'Constraints K(a): EU AI Act 2024/1689 (logging, oversight; potentially high-risk); GDPR' -- this frame explains why it sits in K(a) and not in the weights. The landing points are elements of fig:llmgateway (Lecture 12) -- name the figure, do not reprint it. + +### Section: How AI Shifts the Matrix + +#### Frame 9: How AI shifts the matrix + +*Kind:* content -- *Source:* §43 intro (part5_ai_dimension.tex 497-500) -- *Minutes:* 2 + +- \emph{\textcolor{bankblue}{You have computed the C10 verdict three times -- what were those computations doing to the rest of the matrix?}} +- The verdict itself needs no fourth derivation -- the three computations of the recap (Lectures 3, 6, 10) +- Two of the four absorption forms on the recap's map -- the \textbf{tenth class} and the \textbf{twelfth dimension} -- are exactly the artefacts those computations used +- This section supplies the generalisation in three steps: (i) the \emph{supply-side} reading of the row you own; (ii) the full \textbf{D12 column} it exercised; (iii) the \textbf{cells that moved} -- cell by cell, with stated and measurable reasons +- Then: when the pipeline promise is real (MLOps maturity) -- and A6 restated as a falsifiable claim + +*Elements:* +- Leading question in italics (bankblue) as in decks 4-6; a small three-step roadmap (i)-(iii) + +*Notes:* Section opener; the computation list is not repeated here -- point at the recap's map (frame 3). + +#### Frame 10: The C10 row -- which D12 mechanism each cell exercises + +*Kind:* table -- *Source:* §43.1 (part5_ai_dimension.tex 502-507) -- *Minutes:* 4 + +- Opener: start from the row you own (tab:fit-c10, Lecture 10) -- the one reading the three computations used but never stated in one place: \emph{which D12 mechanism each cell exercises} +- Table: MM, HX | $++$ | \textbf{boundary and port}: a CI-verifiable module boundary and an anti-corruption adapter on a port contain a fallible, entangled component +- EDA, PF | $+$ | \textbf{queue}: asynchronous absorption of latency, rate limits, and outages; pipeline-shaped ingestion and evals +- L | $-$ | none of the three -- no queue, no port, no measurement point +- MS | $\circ$ | seconds-scale, fallible calls in synchronous chains (the missing queue) +- SL | $\circ$ | minutes-long LLM and solver work against platform timeout ceilings +- \textbf{Key Concept (recommendation, Part IV and ADR-007):} a hexagonal modular monolith plus pipelines and an orchestrated agent workflow, with EDA as the secondary job/audit spine -- governed by token and latency budgets and the determinism boundary: \emph{agents propose; deterministic services decide and book} + +*Elements:* +- 5-row \footnotesize table 'Cells | Fit | D12 mechanism exercised', p{1.6cm}cp{9.6cm}, from lines 505 (mechanisms) with the Fit ratings of tab:fit-c10 (part4_fit.tex 439-445: L $-$, MM $++$, HX $++$, MS $\circ$, EDA $+$, PF $+$, SL $\circ$); recommendation from line 507 alone in a keypoint below the table + +*Notes:* Only opener + table + keypoint -- the bullets of the earlier draft duplicated the table rows. The ratings of the capped cells (L, MS, SL) are not restated in §43.1 ('capped'); they are taken from tab:fit-c10, taught in Lecture 10, so that the Fit column follows the rating convention of decks 4-6 instead of mixing math ratings with the word 'capped'. + +#### Frame 11: D12 across the seven patterns + +*Kind:* table -- *Source:* §43.2, tab:d12row (part5_ai_dimension.tex 509-532) -- *Minutes:* 4 + +- Intro line: the D12 row of the Lecture-6 consolidated table, now with tactic-level rationales -- D12 (AI integrability) measures whether the pattern naturally provides \textbf{the queue, the port, and the measurement point} a slow, fallible, per-call-priced component requires +- L -- Layered $\circ$: technical layers give the non-deterministic component no boundary, no queue, and no measurement point of its own +- MM -- Modular monolith $+$: a dedicated AI module with a hard, CI-verifiable interface contains the component cheaply +- HX -- Hexagonal $++$: the LLM is an adapter on a port -- swappable, mockable, contract-guarded; the ACL discipline structurally built in +- MS -- Microservices $\circ$: per-service isolation helps; synchronous chains through seconds-scale calls hurt -- net neutral +- EDA -- Event-driven $++$: queues absorb exactly what LLMs are worst at -- latency, rate limits, outages; natural batching points +- PF -- Pipes-and-filters $++$: ingestion, training, and eval pipelines are pipes-and-filters by construction +- SL -- Serverless $\circ$: event-glue around batch AI APIs fits; platform timeout ceilings collide with minutes-long LLM/solver runs + +*Elements:* +- 7-row \scriptsize table, \renewcommand{\arraystretch}{0.8}, tabular{@{}p{2.6cm}cp{8.4cm}@{}} 'Pattern | D12 | Rationale', from tab:d12row lines 514-532 + +*Notes:* This is the D12 row of deck 6's consolidated table, now with tactic-level rationales -- say so in the intro line only, do not re-show the whole table. + +#### Frame 12: Which existing cells shift, and why (1/2) + +*Kind:* content -- *Source:* §43.3 (part5_ai_dimension.tex 534-542) -- *Minutes:* 4 + +- Beyond the new row and column, AI as a runtime component moves \emph{existing} evaluations in stated directions -- all five visible in the D12 ratings, each carrying a measurable reason +- \textbf{1. Asynchronous patterns gain (EDA, PF $\uparrow$).} Queues and pipelines absorb what LLMs are worst at -- latency, rate limits, outage -- and ingestion and eval pipelines are pipes-and-filters by construction +- \textbf{2. Hexagonal gains most (HX $\uparrow$).} The ACL/port discipline is exactly what the CACE problem demands; Assumption A1's cost-of-change criterion bites hardest at \emph{model replacement}; testing against deterministic fakes is the only way to keep the deterministic 95\,\% of the system deterministic +- \textbf{3. Synchronous distributed chains lose (MS $\downarrow$ where LLM calls sit in the request path).} Seconds-scale latency and per-hop failure probability multiply along the chain; without constitutive stability patterns this is a cascade design + +*Elements:* +- Numbered list 1-3 (\footnotesize), each movement in bold with its arrow; from lines 537-542 + +*Notes:* Ask the class to name the tactic behind each movement before revealing it (keypoint of frame 13 demands exactly that). + +#### Frame 13: Which existing cells shift, and why (2/2) + +*Kind:* keyconcept -- *Source:* §43.3 + keypoint (part5_ai_dimension.tex 543-549) -- *Minutes:* 4 + +- \textbf{4. Serverless is conditional (SL $\sim$).} Platform timeout ceilings against minutes-long LLM and solver runs cap it; event-glue around batch APIs remains a fit +- \textbf{5. A cost dimension becomes load-bearing everywhere.} Cost per request, feature, and tenant is a runtime quality attribute with no counterpart in classical profiles; it belongs in the gateway and in CI budgets +- Routing across cheap and expensive models is the new incarnation of a classical resource-arbitration tactic: \textbf{cascades} up to $\sim$98\,\% cost reduction at comparable quality; \textbf{learned routers} more than $2\times$ cheaper without quality loss +- \textbf{Key Concept:} the matrix does not get \emph{rewritten} by AI; it gets \emph{shifted} -- in five stated directions, for five stated and measurable reasons +- A student who can name, for any cell movement, the quality-attribute mechanism behind it (which tactic the pattern bundles or impedes for a slow, fallible, per-call-priced component) has understood both Part IV and Part V + +*Elements:* +- Numbered list 4-5 (continuing, lines 543-544), then keypoint box from lines 547-549 (condensed) + +*Notes:* The keypoint is exam-relevant: it states precisely what 'understood' means for Parts IV-V. It is quoted again on frame 37. + +#### Frame 14: MLOps maturity: the three-level ladder + +*Kind:* table -- *Source:* §43.4 (part5_ai_dimension.tex 551-554) -- *Minutes:* 3 + +- For type-(b) components the PF cells' promise (the D12 $++$) is realised only at sufficient process maturity -- the canonical three-level ladder: +- \textbf{Level 0} | manual, script-driven, interactive; data science and operations separated; releases rare, no CI/CD, minimal monitoring -- \emph{the documented reality of many teams} | model handed ``over the fence'' as an artefact +- \textbf{Level 1} | automated ML pipeline with continuous training; automated data and model validation, triggers, metadata store, feature store | \emph{the pipeline, not the model, is the deployment artefact} +- \textbf{Level 2} | CI/CD automation of the pipeline components themselves | fast, reliable experiment-to-production cycles +- Footer (\scriptsize, grey): nine consolidated MLOps principles -- CI/CD automation, workflow orchestration, reproducibility, versioning of data/model/code, collaboration, continuous training and evaluation, metadata tracking, monitoring, feedback loops + +*Elements:* +- 3-row \scriptsize table 'Level | Characteristics | Key trait', one-line cells, from line 554; the nine principles as one \scriptsize grey footer line (or speaker notes if the frame is tight) + +*Notes:* The third column is headed 'Key trait', not 'Deployment artefact', because the script states a deployment artefact for Levels 0 and 1 only. The PF promise is the D12 row's $++$ (§43.2); in the C10 row PF rates $+$. + +#### Frame 15: When the pipeline promise is real: the fit-theoretical reading + +*Kind:* keyconcept -- *Source:* §43.4 (part5_ai_dimension.tex 554) -- *Minutes:* 2 + +- \textbf{Fit-theoretical reading:} the MLOps level describes how much of \textbf{D9} (testability/deployability) and \textbf{D12} the organisation can actually \emph{cash in} +- A Level-0 team holding a $++$ pattern rating realises little of it +- This is the \textbf{Axis-B echo of DORA's Axis-A finding} (Lecture 12): \emph{guardrail maturity, not tool adoption}, converts potential into performance + +*Elements:* +- Two-line keypoint-style line for the D9/D12 cash-in sentence; the Level-0 example and the DORA echo as two short bullets (\footnotesize); from line 554 + +*Notes:* Short frame, deliberately: this sentence is the exam-relevant one of §43.4 and must not be the sixth element of a crowded slide. The DORA finding was taught on Axis A in Lecture 12 -- name it, do not re-teach it. + +#### Frame 16: Assumption A6 restated as a falsifiable claim + +*Kind:* keyconcept -- *Source:* §43.4 closing + keypoint (part5_ai_dimension.tex 556-560) -- *Minutes:* 3 + +- Three of the four absorption forms are now on the table, each \emph{computed rather than asserted}: the tenth class, the twelfth dimension, the shifted cells -- the fourth, the emergent composition pattern, follows next +- \textbf{Key Concept -- A6 restated:} runtime AI components are non-deterministic, fallible, latency-heavy, per-call-priced, and subject to drift and vendor deprecation +- They \emph{stretch} existing quality dimensions by orders of magnitude and add sub-attributes: token cost per request, eval pass rate, provider deprecation risk, prompt-injection resistance +- What does \emph{not} change is the method: scenarios with response measures, tactics, trade-off analysis, ADRs, fitness functions +- The theory absorbs AI -- as a tenth application class, a twelfth profile dimension, shifted cell values, and one emergent composition pattern -- instead of being reinvented for it +- The quality gate is carried by the one new test-artefact class A6 named from the start: the \textbf{eval harness} + +*Elements:* +- keypoint box from lines 558-560 (condensed); above it the one-sentence status line from line 556 + +*Notes:* Bridge frame: closes §43 and opens §44 -- 'the assumption is now a falsifiable claim with evidence attached'. + +### Section: Agent Orchestration -- The Emergent Eighth Pattern + +#### Frame 17: Agent orchestration -- the emergent eighth pattern + +*Kind:* content -- *Source:* §44 intro (part5_ai_dimension.tex 565-568) -- *Minutes:* 2 + +- \emph{\textcolor{bankblue}{``Should I reduce my exposure to European industrials?'' -- no single model call can answer that responsibly, so what structure can?}} +- The final structural novelty of the AI era is the orchestration of agents +- As everywhere in this script, \textbf{the concrete system comes before the catalogue}: first the advisory workflow the course project actually builds, then the name of what it is an instance of +- Rhythm of this block (the pattern rhythm of decks 4-6, adapted): case $\to$ what an agent is and is not $\to$ topologies and classical analogues $\to$ choosing a topology $\to$ economics and the default rule $\to$ capability-profile sketch $\to$ project link + +*Elements:* +- Leading question in italics (bankblue); short roadmap line + +#### Frame 18: Case: the course project's advisor workflow + +*Kind:* case -- *Source:* §44.1 (part5_ai_dimension.tex 570-573) -- *Minutes:* 4 + +- Diagram, full width: \textbf{Orchestrator} (an LLM call with a fixed system prompt) splits the request into sub-tasks and delegates to three specialists -- \textbf{Document analyst}, \textbf{Portfolio quant}, \textbf{Compliance checker}; the portfolio quant calls \emph{deterministic analytics services}; the merged answer passes the \textbf{guard} before reaching user or books; every call passes through the \textbf{LLM gateway} +- Footer line 1: orchestrator splits and delegates, then merges the results into one grounded answer +- Footer line 2: document analyst returns extracted findings from the ingestion corpus \emph{with citations}; portfolio quant produces exposure and concentration numbers by calling only deterministic analytics services -- \emph{arithmetic is not a job for a language model} +- Footer line 3: compliance checker verifies the draft -- every cited passage exists, every entity resolves against the ontology, every mandate constraint holds + +*Elements:* +- tikz diagram drawn from the prose of line 573 (no figure exists in the script), full width in \resizebox{0.75\textwidth}{!}{...}: Orchestrator (violet agentbox) fanning out to Document analyst / Portfolio quant / Compliance checker (violet); Portfolio quant with an arrow to 'deterministic analytics services' (green gatebox); a dashed 'LLM gateway' band around all LLM calls; a green 'guard' gate between the merged answer and 'user / books'. Colours as fig:agenttopologies: violet = non-deterministic, green = deterministic. Below: a \footnotesize footer of at most three lines + +*Notes:* Deck-6 topology-frame form (diagram + three-line footer), not a two-column layout. The gateway/guard sentence ('every call flows through the LLM gateway -- routed, cached, budgeted, logged -- and nothing any agent produces reaches the user or the books without passing the guard: agents propose; deterministic services decide and book') opens frame 19. Label nothing the prose does not name. + +#### Frame 19: Strip the labels: a shape you know cell by cell + +*Kind:* content -- *Source:* §44.1 (part5_ai_dimension.tex 573-575) -- *Minutes:* 3 + +- Opening line: every call by every participant flows through the \textbf{LLM gateway} -- routed, cached, budgeted, logged -- and nothing any agent produces reaches the user or the books without passing the \textbf{guard}: \emph{agents propose; deterministic services decide and book} +- Now strip the labels: a coordinator decomposing work for specialised workers is the \textbf{mediator topology of event-driven architecture} (Lecture 5); the fixed retrieve--extract--check sequence inside each specialist is a \textbf{pipeline} (Lecture 6); peers coordinating over shared context would be the \textbf{broker topology} +- The section's deliberately \emph{deflationary} claim: agent orchestration is \textbf{not a new architectural style} but a \textbf{composition pattern for non-deterministic runtime components} that reuses the topologies of the seven patterns you already know -- which is why it can be evaluated with the \textbf{rating grid you already have} +- This is the claim the Part II outlook (Lecture 6) filed in advance; this section pays it out -- the full six-row mapping follows on frame 22 + +*Elements:* +- Four bullets (\footnotesize); the deflationary claim as a keypoint-styled line; no mini-table (the six-row table of frame 22 supersedes it) + +*Notes:* Trimmed to the gateway/guard rule, the three analogues named in line 575, and the deflationary claim; the mapping table is not pre-empted here. + +#### Frame 20: What an agent is -- and is not + +*Kind:* definition -- *Source:* §44.2 definitionbox + guidance (part5_ai_dimension.tex 577-584) -- *Minutes:* 5 + +- \textbf{Definition: Agent; workflow vs.\ agent} -- an \emph{agent} is an LLM running in a loop with tools and state: at each iteration the model observes the current state (conversation, tool results, working memory), selects an action (a tool call or an answer), and the loop executes it and feeds the result back -- until a termination condition holds +- Schematically: \textbf{agent $=$ loop $+$ tools $+$ state} +- The load-bearing distinction: a \textbf{workflow} orchestrates LLM calls and tools along \emph{predefined code paths} -- deterministic structure, non-deterministic building blocks; an \textbf{agent} lets the model \emph{steer its own process and tool use} -- the control flow itself becomes model output +- Autonomy is therefore not a binary but a \textbf{dial}, and every notch on it costs latency, tokens, and testability +- Below the box -- engineering guidance of the source that defined this vocabulary, matching the module's philosophy verbatim: \textbf{find the simplest solution possible} $\cdot$ \textbf{prefer simple, composable patterns over frameworks} $\cdot$ \textbf{escalate to agents only when the task genuinely requires open decision paths} +- Orchestration frameworks that model workflows as \emph{explicit graphs} make the topology \textbf{inspectable} -- an architectural virtue for the same reason a C4 diagram is (Lecture 3) + +*Elements:* +- definitionbox[Agent; workflow vs.\ agent] from lines 580-582 (condensed, with the schematic 'agent = loop + tools + state' as a centred line inside); below it the three guidance rules of line 584 as three bold one-liners and the explicit-graph sentence + +*Notes:* Frames 19 and 20 of the earlier draft merged: definitionbox uncrowded (four lines), guidance as three bold one-liners below. Deck 6 outlook stated the workflow/agent distinction in one line; here it gets its full definition. Emphasise 'the control flow itself becomes model output' -- that is what changes testability. The ADR-per-escalation rule is NOT stated here -- it is the §44.4 keypoint and is paid out on frame 25. + +#### Frame 21: Topologies and their classical analogues + +*Kind:* table -- *Source:* §44.3, tab:agenttopology (part5_ai_dimension.tex 586-608) -- *Minutes:* 4 + +- The Lecture-6 outlook table, now with its third column -- structure and use: every workflow topology maps exactly onto a structure from Part II that you know cell by cell, and every property the classical pattern is known for (and every weakness) \emph{transfers} +- Prompt chaining (chain) | Pipes-and-filters (PF) | each call processes the previous output; programmatic gates between stages; fixed decomposition +- Routing | Routing layer / mediator | a classification step directs inputs to specialised prompts or models; the runtime sibling of model routing +- Parallelisation (sectioning, voting) | Broker-style fan-out | independent subtasks in parallel, or repeated runs with majority vote +- Orchestrator--workers (tree/graph) | Mediator EDA | a lead model decomposes the task dynamically and delegates to workers; central workflow control +- Evaluator--optimizer | Feedback control loop | generator and evaluator model iterate until a quality criterion holds +- Autonomous multi-agent | Broker topology | peer agents coordinate over shared context; maximal flexibility, minimal central control + +*Elements:* +- 6-row \footnotesize table 'Topology | Classical analogue | Structure and use', p{3.2cm}p{3.0cm}p{6.4cm}, from tab:agenttopology lines 591-608, analogue column in the script's exact wording + +*Notes:* Same mapping as the Lecture-6 outlook -- the analogue column is now the script's exact wording (deck 6 said 'dispatch layer' for routing and 'broker fan-out of autonomous quanta' for multi-agent systems; the script says 'Routing layer / mediator' and 'Broker topology' -- mention the two renamed cells verbally), and the third column is new. Say: 'the classical analogue predicts both the strengths and the failure modes' (caption, line 593). + +#### Frame 22: Four topologies, drawn -- gates in code, judgement in the model + +*Kind:* diagram -- *Source:* §44.3, fig:agenttopologies (part5_ai_dimension.tex 610-651) -- *Minutes:* 3 + +- Chain $\hat{=}$ pipes-and-filters: LLM 1 $\to$ \textcolor{bankgreen}{gate} $\to$ LLM 2 $\to$ LLM 3 +- Orchestrator--workers $\hat{=}$ mediator EDA: Orchestrator $\to$ Worker A / Worker B / Worker C +- Evaluator--optimizer $\hat{=}$ control loop: Generator $\rightleftarrows$ Evaluator (feedback) +- Multi-agent $\hat{=}$ broker topology: Agent 1, Agent 2, Agent 3 over a shared context / bus +- Caption: deterministic gates (green) between non-deterministic stages (violet) are the \textbf{workflow discipline}: \emph{structure stays in code, judgement stays in the model} + +*Elements:* +- tikz figure redrawn from lines 610-651 with the deck's styles (agentbox violet fill aiviolet!15, gatebox bankgreen!15, rounded corners 3pt, Stealth arrows); wrap in \resizebox{0.85\textwidth}{!}{...}; caption line (line 649) in \footnotesize below + +*Notes:* Show the advisor workflow of frame 18 as an instance of the second topology (orchestrator--workers) -- point, don't redraw. + +#### Frame 23: The evaluation logic applies unchanged -- sharpened along three axes + +*Kind:* content -- *Source:* §44.3 (part5_ai_dimension.tex 653) -- *Minutes:* 2 + +- Because the topologies are the old topologies, the evaluation logic of this theory applies unchanged -- sharpened along exactly three axes: +- \textbf{Non-determinism} -- testability is read as \emph{eval coverage} (the eval harness of Lecture 12) +- \textbf{Token economics} -- cost per \emph{request}, not per infrastructure +- \textbf{Fallibility} -- fault tolerance is read as guardrails, evaluator loops, and deterministic fallbacks behind ports +- Consequence: the choice of topology can be compressed into the same style of decision aid the matrix provides -- next frame + +*Elements:* +- Three axes as three short bold-headed items (\footnotesize); no dimension numbers on the slide -- the script names the axes, not D-numbers + +*Notes:* The mapping of the three axes onto D9, D10, D5 is the lecturer's own and may be spoken, not printed. + +#### Frame 24: Choosing a topology from the task signature + +*Kind:* table -- *Source:* §44.3, tab:agentchoice (part5_ai_dimension.tex 655-671) -- *Minutes:* 4 + +- Read top-down and \textbf{stop at the first matching row} -- the ordering encodes ``simplest structure first'' +- Fixed decomposition; every intermediate result verifiable | Prompt chain (workflow) | cheapest and most testable; deterministic gates between stages +- Heterogeneous input categories with specialised handling | Routing | cheap; the router itself needs its own eval +- Broad, parallelisable subtasks; breadth-first search | Parallelisation or orchestrator--workers | token cost multiplies with worker count ($\sim$15$\times$ class) +- Output must clear a measurable quality bar | Evaluator--optimizer | latency and cost grow per iteration; needs a reliable evaluator +- Path genuinely unknown; open-ended tool use | Agent | highest cost and risk; guardrails, budgets, and oversight mandatory +- Project pointer: your Axis-B ADR must justify your topology \emph{against this table} + +*Elements:* +- 5-row \footnotesize table 'Task signature | Topology | Cost/risk note', p{4.6cm}p{3.2cm}p{4.8cm}, from tab:agentchoice lines 655-671; one-line project pointer (projektbox, line 715) + +*Notes:* Ask: which row does the advisor workflow of frame 18 match? (orchestrator--workers, row 3 -- with the 15x cost class attached). + +#### Frame 25: The economics of autonomy -- and the default rule + +*Kind:* keyconcept -- *Source:* §44.4 + keypoint (part5_ai_dimension.tex 673-680) -- *Minutes:* 4 + +- The rigour case for restraint, quantified by the best-documented production account (previewed in the Lecture-6 outlook): Anthropic's multi-agent research system -- an orchestrator--workers design -- beat a single agent by \textbf{90.2\,\%} at roughly \textbf{15$\times$ the tokens} of a chat interaction (simple agents $\sim$4$\times$); token use alone explains \textbf{80\,\%} of the variance +- A textbook \textbf{CBAM decision} in the sense of Part IV: autonomy is bought with cost, latency, and error accumulation -- justified only where the task's utility-response curve clears the price: broad, parallelisable research questions do; a form-filling workflow does not +- Regulation closes the loop from the other side: the AI Act's logging, documentation, human-oversight, and robustness duties attach to \emph{exactly the autonomy this section prices} +- \textbf{Key Concept -- the default rule for agent architecture:} workflows before agents; the simplest structure first; autonomy only on demonstrated need; every escalation an ADR with a measurement contract. \emph{An orchestration decision without a token budget and an eval threshold is an opinion -- Maxim 6 applies to agents without modification} + +*Elements:* +- Three bullets (\footnotesize, the first at two lines), then keypoint box from lines 678-680 with the Maxim-6 sentence inside it, as in the script + +*Notes:* The numbers are recognised from deck 6 (the script says so, line 676) -- spend the time on the CBAM reading and the AI Act closure, which are new. This is where the 'dial' of frame 20 is paid out: every notch of autonomy is an escalation, and every escalation an ADR with a measurement contract. + +#### Frame 26: Agent orchestration -- capability-profile sketch + +*Kind:* table -- *Source:* §44.5, tab:agentprofile (part5_ai_dimension.tex 682-710) -- *Minutes:* 5 + +- Header note: provisional profile (state 2025/26) -- every cell carries its own temporal fitness function +- D1 Read scalability | $\circ$ | orchestration state small and replicable; throughput bounded by provider rate limits +- D2 Write scalability \& elasticity | $\circ$ | fan-out cheap in structure, expensive in tokens; sustained volume quota-bound +- D3 Latency \& predictability | $--$ | seconds per step, steps multiply along the loop; open-ended loops have no tail bound +- D4 Consistency \& integrity | $--$ | non-deterministic by construction; integrity exists only outside, in deterministic validation +- D5 Availability \& fault isolation | $-$ | every step adds provider failure modes and error accumulation; evaluator loops and fallbacks mitigate +- D6 Security \& auditability | $\circ$ | step and tool logging natural ($+$), legally required in high-risk uses; injection and excessive agency widen the surface ($-$) +- D7 Evolvability | $+$ | prompts, tools, models swap behind contracts; framework and model churn claws part back +- D8 Simplicity \& time-to-market | $-$ | a chain workflow is genuinely simple; every notch of autonomy is not +- D9 Testability \& deployability | $--$ | exhaustive testing impossible; evals with statistical thresholds replace assertions +- D10 Operating cost efficiency | $--$ | token cost per request orders of magnitude above classical calls; multi-agent $\sim$15$\times$ chat +- D11 Team scaling | $\circ$ | sub-agent and tool ownership parallelises teams moderately -- the PF filter-ownership analogy +- D12 AI integrability | $++$ | it \emph{is} the composition pattern for AI components -- trivially its own best host +- Status row (in place of the 'Native shape' row of decks 4-6): default hypotheses; re-verified on every model generation + +*Elements:* +- One 12-row \scriptsize table, \renewcommand{\arraystretch}{0.8}, tabular{@{}p{2.9cm}cp{7.8cm}@{}} 'Dimension | Rating | Ground', each Ground condensed to $\le$ 12 words as deck 6 does for PF/SL, from tab:agentprofile lines 687-710; a 'Status' row instead of 'Native shape' + +*Notes:* The eighth profile in the exact form of the seven profiles of decks 4-6 (one 12-row scriptsize table, arraystretch 0.8) -- the rhythm students have seen seven times. The three caveats and the reading follow on frame 27. + +#### Frame 27: Agent orchestration -- reading the sketch + +*Kind:* keyconcept -- *Source:* §44.5 (part5_ai_dimension.tex 685, 712) -- *Minutes:* 3 + +- Why only a \emph{sketch} -- three caveats: no Richards--Ford star ratings; no decade of production case studies; every cell is a \textbf{default hypothesis} in the sense of the theory's own limits discussion -- to be replaced by measurement and \textbf{re-verified on every model generation} +- The cells read, as always, ``as the dominant structure of the subsystem it governs'' -- here the \textbf{AI subsystem}, not the whole platform +- \textbf{The reading:} the profile explains at a glance why agent orchestration can never be the dominant structure of a whole platform of class C1--C9 -- it is \textbf{vetoed by every High weight on D3, D4, D9, or D10} (stage 2 of the three-stage match, Lecture 7) +- \textbf{Key Concept:} it is, and remains, an \textbf{edge pattern} -- hosted behind the ports of a deterministic core, exactly where the C10 recommendation places it + +*Elements:* +- Three bullets (\footnotesize) from line 685 and line 712; the edge-pattern sentence as a keypoint + +*Notes:* Link the veto reading to the three-stage match (stage 2, veto rule): four $--$ cells against Highs -- the veto logic that capped MS for C1 in Lecture 7 (lifted to $\circ$ only under the documented Monzo condition, part4_fit.tex line 55). + +#### Frame 28: Project link: Axis B is what you build -- and what you build it as + +*Kind:* content -- *Source:* §44.5 projektbox (part5_ai_dimension.tex 714-716) -- *Minutes:* 3 + +- \textbf{Project Link (projektbox):} Axis B is \emph{what} you build; the advisor workflow -- an orchestrator with two to three specialised sub-agents (document analyst, portfolio quant, compliance checker), all behind the LLM gateway -- is what you build it \emph{as} +- The graded Axis-B deliverables are the \textbf{containment artefacts}: +- (i) the \textbf{gateway} with model routing, fallback chain, and per-request \textbf{cost observability} -- cost per request, per feature, reported on a dashboard and enforced as a CI budget +- (ii) the \textbf{ontology guard} -- every extracted entity resolves against the deterministic data store, every cited passage exists, portfolio axioms hold +- (iii) the \textbf{eval harness} (Lecture 12 listing) wired as a \textbf{CI gate} +- (iv) one \textbf{ADR} that justifies your chosen orchestration topology against the task-signature table, with its \textbf{token budget and eval threshold} as the measurement contract +- \emph{Sub-agents propose; your deterministic services decide and book.} + +*Elements:* +- projektbox from lines 714-716, items (i)-(iv) as an enumerate inside the box + +*Notes:* This is the grading rubric of Axis B in the students' own words -- it feeds the exercise frame (frame 38) and the week-14 defence. + +### Section: Synthesis -- One Theory, Five Parts + +#### Frame 29: What did AI change? Two temptations, one position + +*Kind:* content -- *Source:* §45 intro (part5_ai_dimension.tex 721-724) -- *Minutes:* 3 + +- \emph{\textcolor{bankblue}{What, in the end, did AI change?}} -- the bet of the opening can now be settled +- Architecture teaching in the AI era faces two symmetric temptations: +- \textbf{Denial} -- generative AI as a passing tool fashion that leaves software engineering untouched: falsified by the adoption data alone (\textbf{90\,\%} of practitioners report using AI at work by 2025) +- \textbf{Exceptionalism} -- AI systems as a new discipline with new vocabulary, new roles, new decision logic: rejected on the assembled evidence -- nothing AI does, on either axis, required a decision no ADR can record, a correctness no response measure can capture, or a structure no tactic vocabulary describes +- Between the temptations lies the position defended since Part I: \textbf{absorption} + +*Elements:* +- Two columns (Denial | Exceptionalism) with the refutation under each; 'absorption' centred as a keypoint line + +#### Frame 30: The script read backwards as a single argument (1/2): Parts I--III + +*Kind:* content -- *Source:* §45 (part5_ai_dimension.tex 726) -- *Minutes:* 3 + +- \textbf{Part I} established that architecture is the set of significant, hard-to-reverse decisions (\textbf{A1}), that everything is a trade-off (\textbf{A2}), that quality attributes -- not features -- drive structure (\textbf{A3}), and that requirements decide anything only as measurable scenarios (\textbf{A4}); it fixed the \textbf{twelve dimensions} on which all later judgements run +- \textbf{Part II} turned seven patterns into \textbf{capability profiles} by explaining every rating through the tactics a pattern bundles or impedes (the consolidated capability table) +- \textbf{Part III} turned ten application classes into \textbf{requirements profiles} -- recurring bundles of architecturally significant requirements with response measures and hard constraints (the requirements table) + +*Elements:* +- Three-row table or three stacked blocks (Part | What it established | Artefact): I | A1-A4 | twelve dimensions; II | tactics $\to$ ratings | capability table; III | ASR bundles + response measures + K | requirements table -- from line 726 + +*Notes:* Use the deck-1 'pipeline + map of the script' vocabulary; each part's table named exactly as the script does. + +#### Frame 31: The script read backwards as a single argument (2/2): Parts IV--V + +*Kind:* content -- *Source:* §45 (part5_ai_dimension.tex 726) -- *Minutes:* 3 + +- \textbf{Part IV} matched them: knock-out screening, veto rule, holistic ordinal reading (the $7 \times 10$ fit matrix); it insisted that \textbf{hybrids are the normal case}, that the decision procedure ends in an \textbf{ADR}, and that every ADR ends in a \textbf{measurement contract} -- because a decision is a hypothesis tested over the life cycle (\textbf{A5}) +- \textbf{Part V} subjected the whole construction to its hardest contemporary stress test -- and the construction held (\textbf{A6}) +- \textbf{Axis A} raised the value of the theory's artefacts -- documentation as agent context, fitness functions as operating licence -- rather than obsoleting them +- \textbf{Axis B} was absorbed as one class, one dimension, five cell shifts, and one composition pattern whose profile the theory's own grid can express + +*Elements:* +- Continuation of the Part table (IV | three-stage match, hybrids, ADR, measurement contract, A5 | fit matrix; V | stress test held, A6 | Axis A / Axis B outcomes) -- from line 726 + +#### Frame 32: Maxim 8 -- the pipeline of this script in one sentence + +*Kind:* keyconcept -- *Source:* §45 keypoint (part5_ai_dimension.tex 728-730) -- *Minutes:* 2 + +- \textbf{Key Concept -- Maxim 8.} The theory absorbs AI: a tenth application class, a twelfth dimension, shifted cells, one emergent composition pattern -- \emph{same assumptions, same procedure, same contract} +- The pipeline of this script is one sentence long: +- \emph{scenarios with numbers (Part I) meet capability profiles (Part II) and requirements profiles (Part III) in a non-compensatory match (Part IV) whose result is an ADR with a measurement contract -- and nothing about AI, on either axis, changes a single step of it (Part V)} + +*Elements:* +- keypoint box from lines 728-730, the one-sentence pipeline set in italics on its own; optionally a five-box horizontal tikz strip (Part I $\to$ II $+$ III $\to$ IV $\to$ ADR + contract, with Part V as a bracket underneath) redrawn from the sentence + +*Notes:* This sentence returns on the exam-orientation frame 37 as the students' map -- say so. + +#### Frame 33: The deepest result: one discipline at two binding sites + +*Kind:* content -- *Source:* §45 (part5_ai_dimension.tex 732) -- *Minutes:* 3 + +- One symmetry deserves to be made explicit -- the deepest result of Part V: +- \textbf{Axis A} concluded: \emph{generation} is cheap and \emph{verification} is the bottleneck, so the SDLC must be rebuilt around machine-checkable specifications, guardrails, and human accountability +- \textbf{Axis B} concluded: \emph{model output} is cheap and \emph{validation} is the bottleneck, so the runtime must be rebuilt around contracts, ontology guards, eval harnesses, and a human-owned determinism boundary +- These are the \textbf{same conclusion at two different binding sites}: whether the LLM sits in the toolchain or in the product, the discipline it demands is \textbf{containing cheap, fallible generation behind expensive, explicit verification} +- -- which is, on reflection, what this module has called \emph{architecture} all along + +*Elements:* +- Two columns (Axis A | Axis B) with 'cheap ... / bottleneck ... / rebuilt around ...' aligned line by line; the shared conclusion as a keypoint-styled line spanning both columns + +*Notes:* Axis A's line is Maxim 7 / the verification bottleneck of Lecture 12, recalled in recap bullet 2 (frame 3) -- point back to it; the two 'cheap ... / bottleneck ...' lines are the script's wording (line 732), not a paraphrase. + +#### Frame 34: Discussion: is it one discipline? + +*Kind:* discussion -- *Source:* §45 thinkbox (part5_ai_dimension.tex 734-736) -- *Minutes:* 4 + +- Close the module with the symmetry. Consider the artefact pairs across the two axes: +- \texttt{AGENTS.md} vs.\ the system prompt and ontology $\cdot$ the CI fitness function vs.\ the runtime ontology guard $\cdot$ the code-review obligation vs.\ the human-oversight duty of the AI Act $\cdot$ the test suite as the agent's operating licence vs.\ the eval harness as the model's operating licence +- For each pair: is this genuinely \emph{one} engineering discipline observed at two binding sites -- or are there differences of kind, in \textbf{reversibility}, in \textbf{accountability}, in \textbf{failure semantics}, that the symmetry hides? +- And if it is one discipline: which parts of this script would survive the next order-of-magnitude improvement in model capability -- and which would you expect to rewrite? + +*Elements:* +- thinkbox 'Discussion' from lines 734-736; the four artefact pairs as a 4-row two-column mini-table (Axis A artefact | Axis B artefact) inside or above the box + +*Notes:* Run as a 4-minute plenary; the second question is the natural hand-over to the week-14 defence ('reflect on where AI helped and where it hurt'). + +### Section: Exam Orientation + +#### Frame 35: The written examination -- the facts + +*Kind:* content -- *Source:* Deck 1, 'Assessment' frame (AISE502_Vorlesung_1_Folien.tex 179-203) -- *Minutes:* 2 + +- \textbf{Written examination: 50\,\%} of the module grade (the project is the other 50\,\%) +- \textbf{End of semester, 60 minutes} +- \textbf{Open book:} script and own notes, \emph{on paper} +- \textbf{Closed internet} +- \textbf{Focus: architecture reasoning -- profiles, matching, trade-offs} +- Language: all materials, the script, and the exam in English + +*Elements:* +- Reuse the deck-1 'Written examination (50\,\%)' block verbatim (right column of the Assessment frame, lines 193-200), full width + +*Notes:* Only deck-1 facts; the exam date is not stated in deck 1 -- announce it verbally (open_issues). + +#### Frame 36: Six learning objectives, five parts + +*Kind:* table -- *Source:* Deck 1 'Learning objectives' frame (AISE502_Vorlesung_1_Folien.tex 167-177) mapped onto §45 synthesis (part5_ai_dimension.tex 726-730) -- *Minutes:* 4 + +- 1. explain why architecture selection is a \textbf{matching problem} -- no pattern is good or bad in itself | Part I: A2 everything is a trade-off, A3 quality attributes drive structure; Part II: every rating explained through the tactics a pattern bundles or impedes +- 2. construct a \textbf{requirements profile} R(a): scenarios with response measures, utility tree, weights | Part I: A4 requirements decide only as measurable scenarios; Part III: ten classes as ASR bundles with response measures and hard constraints K(a) +- 3. derive the \textbf{capability profile} C(p) of seven patterns from their tactics | Part II: capability profiles, every rating explained by tactics (the consolidated capability table) +- 4. run the \textbf{three-stage, non-compensatory match} and defend the result | Part IV: knock-out screening, veto rule, holistic ordinal reading; hybrids are the normal case +- 5. record decisions as \textbf{ADRs} and attach a \textbf{measurement contract} | Part IV: the procedure ends in an ADR, every ADR in a measurement contract -- A5, a decision is a hypothesis tested over the life cycle +- 6. engineer \textbf{AI components} into a system (Axis B) and use \textbf{AI tools} in the process (Axis A) with the same discipline | Part V: A6 held -- one class, one dimension, five cell shifts, one composition pattern; Axis A raised the value of the artefacts + +*Elements:* +- 6-row \scriptsize table, \renewcommand{\arraystretch}{0.85}, two columns 'Learning objective (Lecture 1)' | 'Where the script settles it', p{5.4cm}p{7.2cm}, each cell $\le$ 2 lines; sources: deck 1 lines 167-177 (objectives verbatim) and §45 line 726 (settlement wording) + +*Notes:* No exam questions are invented; the right column is the §45 wording applied to each objective. The focus line is on frame 35, not repeated here. + +#### Frame 37: Open book: the map and the four tables + +*Kind:* content -- *Source:* §45 keypoint (part5_ai_dimension.tex 728-730) and line 726; Part V additions from §43-44 tables; §43.3 keypoint (547-549); deck 1 assessment facts (179-203) -- *Minutes:* 3 + +- Your map is Maxim 8's one sentence: scenarios with numbers $\to$ capability profiles $+$ requirements profiles $\to$ non-compensatory match $\to$ ADR with measurement contract -- and AI changes no step of it +- The four tables the argument runs on: the \textbf{twelve dimensions} (Part I) $\cdot$ the \textbf{consolidated capability table} (Part II) $\cdot$ the \textbf{requirements table} of the ten classes (Part III) $\cdot$ the \textbf{$7 \times 10$ fit matrix} (Part IV) +- Part V's additions: the \textbf{D12 row with rationales}, the \textbf{agent capability-profile sketch}, the \textbf{task-signature table}, the \textbf{OWASP table} +- The spine of the argument: the six load-bearing assumptions \textbf{A1--A6} -- and the Maxims, up to Maxim 8 +- Focus (Lecture 1): \textbf{architecture reasoning -- profiles, matching, trade-offs}; in the words of the §43 keypoint: \emph{name, for any cell movement, the quality-attribute mechanism behind it} + +*Elements:* +- Two columns: left = the one-sentence map as a small five-box strip (reuse frame 32 strip); right = the list of tables and the A1-A6 / Maxims spine; last bullet full width + +*Notes:* No study advice beyond the deck-1 focus line and the §43 keypoint quotation; add nothing procedural about the exam. + +### Section: Closing + +#### Frame 38: This week's exercise: M5 closes -- eval harness in CI, guard, cost observability; threat model, hardening, distinction work + +*Kind:* exercise -- *Source:* Exercise sheet M5 taskbox week 13 and hintbox (project_exercise/project_exercise.tex 432-442, 451-464; week table lines 385-386); semester plan row 13 (Semesterplan_AISE502_HS26.md line 24: 'Hardening; Kür (autonomes Planning, Self-Repair, Model-Routing)') -- *Minutes:* 3 + +- \textbf{Project Link (projektbox):} week 13 of M5 -- Multi-Agent Orchestration, Evaluation, and Hardening; coaching session (1 lesson): +- 1. \textbf{Evaluation harness as a CI gate}; report accuracy and failure modes +- 2. \textbf{Observability} of token cost and latency per request +- 3. \textbf{Threat model} incl.\ prompt injection via news (today's §42.6: the OWASP table, frames 4-5; the same-channel rule, frame 6) $+$ \textbf{basic hardening} +- 4. \textbf{Scaling/optimisation}: caching, batching +- \textbf{Optional distinction} (semester plan: \emph{K\"ur}): autonomous planning, self-repair, model routing, CI/CD, tracing -- every topology escalation justified against the task-signature table (frame 24) and priced per the default rule (frame 25) +- \textbf{Milestone M5: eval harness in CI $+$ guard $+$ cost observability.} Keep the deterministic core free of LLM calls -- this is the line that is graded + +*Elements:* +- projektbox with an enumerate of the four week-13 tasks in the exercise-sheet wording (M5 taskbox, project_exercise.tex 432-442: week-13 item, threat-model item, distinction item), the distinction line as a separate bold-headed line, the milestone in bold, the hintbox line (project_exercise.tex 451-464); pointers to frames 4-6, 24 and 25 instead of restated rules + +*Notes:* The threat model is the direct project application of §42.6 taught on frames 4-6 of this deck -- say so, and hand the OWASP table over as the checklist. The distinction work is the semester plan's 'Kür' (row 13) and the exercise sheet's 'Optional Distinction work' -- name both so the two documents are visibly the same list. The milestone line is unchanged ('eval harness in CI + guard + cost observability'). The week-14 announcement is the Next-week frame's job -- not repeated here. + +#### Frame 39: Summary + +*Kind:* summary -- *Source:* §42.6-42.7, §43, §44, §45 (part5_ai_dimension.tex 455-736) -- *Minutes:* 3 + +- 1. \textbf{OWASP LLM Top 10}: prompt injection cannot be solved in the model (same channel) -- defence in depth at the system level; \emph{the architecture, not the model, is the trust boundary} +- 2. \textbf{EU AI Act}: quality attributes with legal force enter R(a) as hard constraints K(a), never weights -- compliance is the same architecture, documented +- 3. \textbf{C10 row and five shifts}: boundary/port, queue and capped cells; EDA/PF $\uparrow$, HX $\uparrow$ most, MS $\downarrow$ in synchronous chains, SL conditional, cost load-bearing -- the matrix is \emph{shifted}, not rewritten; MLOps level = how much of D9/D12 a team can cash in +- 4. \textbf{Agent orchestration} is a composition pattern, not a style: agent $=$ loop $+$ tools $+$ state; workflows vs.\ agents; topologies map onto PF, mediator EDA, broker, control loop +- 5. \textbf{Economics and profile}: 90.2\,\% at $\sim$15$\times$ tokens is a CBAM decision; $--$ on D3/D4/D9/D10 makes it an edge pattern -- workflows before agents, every escalation an ADR with token budget and eval threshold +- 6. \textbf{Maxim 8}: the theory absorbs AI -- same assumptions, same procedure, same contract; one discipline at two binding sites: containing cheap, fallible generation behind expensive, explicit verification + +*Elements:* +- \footnotesize enumerate, \itemsep 2pt, as in deck 6; six points of at most two lines each + +*Notes:* Cut from eight to six points; the parenthetical numbers (98 %, >2x, 4x, 80 %) are on the frames, not in the summary. + +#### Frame 40: Next week + +*Kind:* nextweek -- *Source:* Semester plan rows 13-14 (Semesterplan_AISE502_HS26.md lines 6, 24-25); deck 1 'semester at a glance' row 14 (line 215) and assessment frame (179-203); exercise sheet M6 taskbox (project_exercise/project_exercise.tex 444-449) -- *Minutes:* 1 + +- Left column -- \textbf{Week 14}: one lesson synthesis and exam hints; three lessons final presentations, architecture defence and peer reviews (deliverable A3, milestone M6); then the written examination (open book, 60 min) +- The week-14 synthesis lesson is a \textbf{recap of today's synthesis and exam orientation (frames 29-37) plus Q\&A} -- \emph{no new material}; today's frames are the reference +- Present the system and \textbf{defend your architectural trade-offs}; reflect on where AI helped and where it hurt -- in building (A) and in the system (B) +- Right column -- \textbf{Reading}: this week: Part V, §42.6--42.7, 43--45; ahead: \textbf{the whole script, Parts I--V} -- with the four tables and Maxim 8's one sentence as the map +- \textbf{Exercise / deliverable}: M5 closes this week (eval harness in CI $+$ guard $+$ cost observability; threat model $+$ hardening; optional distinction work); \textbf{A3: final presentation with architecture defence, week 14} + +*Elements:* +- Two-column layout as in deck 6 (0.55 / 0.42): left = week 14 (structure, the recap-plus-Q\&A line, the defence) and the exam; right = Reading + Exercise/deliverable + +*Notes:* Wording of week 14 follows the semester plan ('1 L Synthese + 3 L Präsentationen', lines 6 and 25), deck 1 row 14 ('Synthesis, exam preparation | Presentations + defence | A3') and the exercise sheet's week table (lines 385-386) -- not 'no lecture'. The synthesis lesson of week 14 is announced explicitly as a recap of frames 29-37 plus Q&A so that nobody expects new material there; the task brief's 'Week 14 -- no lecture' constraint must be reconciled with the semester plan by the lecturer before typesetting (open_issues). + +#### Frame 41: Closing page + +*Kind:* content -- *Source:* Deck 6 closing page (theme) -- *Minutes:* 0 + +- \FHGRClosingPage as in deck 6: 'Thank you!' -- Dr.\ Florian Herzog, Fachhochschule Graub\"unden, Chur -- AISE502 -- AI in Software Engineering II + +*Elements:* +- FHGR closing page (theme) + +*Notes:* Last lecture of new material -- the lecturer may wish to add a one-line farewell; keep the theme page otherwise unchanged. + +## Exercise frame: This week's exercise: M5 closes -- eval harness in CI, guard, cost observability; threat model, hardening, distinction work + +- Week 13 of M5 (Multi-Agent Orchestration, Evaluation, and Hardening); coaching session (1 lesson) +- Evaluation harness as a CI gate; report accuracy and failure modes +- Observability of token cost and latency per request +- Threat model incl. prompt injection via news (today's §42.6: the OWASP table, frames 4-5; the same-channel rule, frame 6) + basic hardening +- Scaling/optimisation: caching, batching +- Optional distinction work (semester plan: Kür): autonomous planning, self-repair, model routing, CI/CD, tracing -- topology escalations justified against the task-signature table (frame 24) and priced per the default rule (frame 25) +- Milestone M5: eval harness in CI + guard + cost observability; keep the deterministic core free of LLM calls -- the line that is graded + +## Summary frame + +1. OWASP LLM Top 10: prompt injection cannot be solved in the model (same channel) -- defence in depth at the system level; the architecture, not the model, is the trust boundary +2. EU AI Act (Regulation 2024/1689): quality attributes with legal force enter R(a) as hard constraints K(a), never weights -- compliance is the same architecture, documented +3. C10 row and five shifts: boundary/port, queue and capped cells; EDA/PF gain, HX gains most, MS loses in synchronous chains, SL conditional, cost load-bearing everywhere -- the matrix is shifted, not rewritten; MLOps level = how much of D9/D12 a team can cash in +4. Agent orchestration is a composition pattern, not a style: agent = loop + tools + state; workflows (predefined code paths) vs. agents (model steers its own process); topologies map onto PF, mediator EDA, broker, feedback control loop +5. Economics and profile: 90.2 % better at ~15x tokens is a CBAM decision; $--$ on D3/D4/D9/D10 makes it an edge pattern behind the ports of a deterministic core -- workflows before agents, every escalation an ADR with token budget and eval threshold (Maxim 6) +6. Maxim 8: the theory absorbs AI -- tenth class, twelfth dimension, shifted cells, one composition pattern -- same assumptions, same procedure, same contract; Axis A and Axis B are one discipline at two binding sites: containing cheap, fallible generation behind expensive, explicit verification + +## Next-week frame + +**Week 14: one lesson synthesis and exam hints -- a recap of today's synthesis and exam orientation (frames 29-37) plus Q&A, no new material; three lessons final presentations, architecture defence and peer reviews (deliverable A3, milestone M6); then the written examination (open book, 60 min)** + +- Final presentations: present the system and defend your architectural trade-offs (M6) +- Peer reviews +- Reflect on where AI helped and where it hurt -- in building (Axis A) and in the system (Axis B) +- Written examination: end of semester, 60 minutes, open book (script and own notes on paper), closed internet; focus: architecture reasoning -- profiles, matching, trade-offs + +*Reading:* +- this week: Part V, Sections 42.6--42.7, 43--45 +- ahead: the whole script, Parts I--V -- with the four tables (twelve dimensions, capability table, requirements table, fit matrix) and Maxim 8's one-sentence pipeline as the map + +*Exercise / deliverable:* +- M5 closes this week: eval harness in CI + guard + cost observability; threat model incl. prompt injection via news + basic hardening; optional distinction work (Kür) +- A3: final presentation with architecture defence, week 14 + +## Script boxes, tables and figures used + +| Element | Script location | Used in frame | +|---|---|---| +| Table tab:owasp -- OWASP Top 10 for LLM Applications 2025 with architectural counter-measures | §42.6, part5_ai_dimension.tex 460-481 | Frames 4 and 5 (split LLM01-05 / LLM06-10) | +| hinweisbox -- prompt injection not solvable inside the model; defence in depth; project consequence | §42.6, part5_ai_dimension.tex 483-485 | Frame 6 | +| Table tab:d12row -- the D12 row of the capability table with tactic-level rationales | §43.2, part5_ai_dimension.tex 514-532 | Frame 11 | +| keypoint -- the matrix is shifted, not rewritten (five directions, five reasons) | §43.3, part5_ai_dimension.tex 547-549 | Frame 13 (quoted again on frame 37) | +| keypoint -- Assumption A6 restated as a falsifiable claim | §43.4, part5_ai_dimension.tex 558-560 | Frame 16 | +| definitionbox[Agent; workflow vs. agent] | §44.2, part5_ai_dimension.tex 580-582 | Frame 20 | +| Table tab:agenttopology -- topologies mapped to classical patterns | §44.3, part5_ai_dimension.tex 591-608 | Frame 21 | +| Figure fig:agenttopologies -- tikz: four topologies and their classical analogues | §44.3, part5_ai_dimension.tex 610-651 | Frame 22 (redrawn with deck styles) | +| Table tab:agentchoice -- choosing a topology from the task signature | §44.3, part5_ai_dimension.tex 655-671 | Frame 24 | +| keypoint -- the default rule for agent architecture (Maxim 6 applies) | §44.4, part5_ai_dimension.tex 678-680 | Frame 25 | +| Table tab:agentprofile -- capability-profile sketch of agent orchestration | §44.5, part5_ai_dimension.tex 687-710 | Frame 26 (one 12-row table); reading on frame 27 | +| projektbox -- Axis B is what you build; the four graded containment artefacts | §44.5, part5_ai_dimension.tex 714-716 | Frame 28 (pointer on frame 24; items referenced on the exercise frame 38) | +| keypoint -- Maxim 8, the pipeline in one sentence | §45, part5_ai_dimension.tex 728-730 | Frame 32 (reused as the map on frame 37) | +| thinkbox -- artefact pairs across the two axes; what survives the next model generation | §45, part5_ai_dimension.tex 734-736 | Frame 34 (Discussion) | + +## Open issues for the author + +- Week 14 wording: the task constraint says the Next-week frame must announce 'Week 14 -- no lecture'. Three reference documents contradict this (semester plan row 14 and phase logic, lines 6 and 25: '1 L Synthese + 3 L Präsentationen'; deck 1 'semester at a glance' row 14: 'Synthesis, exam preparation | Presentations + defence | A3'; exercise sheet week table, lines 385-386). The plan follows the reference documents on frames 3 and 40 ('one lesson synthesis and exam hints; three lessons presentations, defence, peer reviews -- A3, M6') and keeps the full synthesis and exam orientation in this deck (frames 29-37, 27 minutes); frame 40 announces the week-14 synthesis lesson as a recap of frames 29-37 plus Q&A, not new material. The lecturer must reconcile the task brief's 'no lecture' constraint with the semester plan before typesetting; if 'no lecture' is in fact intended, only the week-14 line on frames 3 and 40 and next_week.lecture_line change -- the deck's content does not. +- §43.1 names the capped cells of the C10 row (L, MS, SL) only as 'capped'; frame 10 prints their Fit ratings from tab:fit-c10 (part4_fit.tex 439-445: L $-$, MS $\circ$, SL $\circ$), taught in Lecture 10 but outside the assigned passage, so that the Fit column follows the rating convention of decks 4-6. +- The reference architecture figure fig:llmgateway (part5_ai_dimension.tex line 384, taught in Lecture 12) is named on frames 5, 8, 18-19 and 28. The plan only names it; a miniature reprint of the deck-12 figure on frame 8 is optional if space allows. +- §44.1 (advisor workflow) has no figure in the script; the diagram on frame 18 is drawn from the prose of line 573 only (orchestrator, three specialists, gateway, guard, deterministic analytics services). Label nothing the prose does not name. +- §42.6 has no italic leading question; frame 4 opens with the section's declarative first sentence verbatim (line 458). §43, §44 and §45 have their own leading questions (lines 499, 567, 723) and use them verbatim. +- No thinkbox in §42.6-44 and no ailinse box anywhere in the assigned passages: the deck has exactly one Discussion frame (§45) and no AI Lens frames -- consistent with the whole lecture being Axis B. +- Density: the eighth capability profile (frame 26) is one 12-row scriptsize table with grounds condensed to $\le$ 12 words -- the typesetter must keep each ground to one line; frame 36 is a two-column scriptsize table with cells of at most two lines; frame 20 (definitionbox + three one-liners) must keep the definitionbox to four lines. +- Exam orientation uses only deck-1 facts and §45 (plus the §43 keypoint quotation on frame 37); deck 1 states 'end of semester' without a date -- the exam date must be announced verbally. +- The recap is built from the task's description of deck 12, the Lecture-12 plan's summary (L12.v1.json) and semester-plan row 12 (decks 7-12 do not exist as files in Folien/); recap bullet 2 now carries the verification bottleneck / Maxim 7 and the Axis-A compact block in the script's wording (part5_ai_dimension.tex 142-154, 234) because frame 33 and Maxim 8 build on Maxim 7. At \footnotesize the bullet must stay within four lines -- the typesetter drops 'two contradictory' and the section-number parenthetical first, never the Maxim-7 clause. The wording 'three component types' is kept generic because only 'type-(b)' appears in the assigned passage (§43.4). +- Frame 21 uses the script's analogue wording ('Routing layer / mediator', 'Broker topology'); deck 6's outlook table said 'dispatch layer' and 'broker fan-out of autonomous quanta' -- the two renamed cells are to be mentioned verbally, not corrected in deck 6. +- AI Act timetable: the 2 Aug 2026 general-applicability date has passed by the time of this lecture; the script text is unchanged, but the lecturer may want to say 'now applicable' on frame 7. 'Minimal risk' is printed without a gloss because the script gives none. +- Minutes: frames 2-37 (agenda, recap, content) sum to 116; exercise 3, summary 3, next-week 1 on top -- total 123 for the 135-minute slot, leaving about 12 minutes for the two lesson breaks and questions on the last lecture of new material. +- Exercise sheet location: project_exercise.tex lives at AISE502/project_exercise/project_exercise.tex, not under skript/chapters; the cited line numbers (M5 taskbox 432-442, M6 444-449, hintbox 451-464, week table rows 13-14 at lines 385-386) refer to that file. Frame 38 lists all three week-13 items of the M5 taskbox (harness + observability; threat model + hardening + scaling; optional distinction) and names the semester plan's 'Kür' -- the milestone line is unchanged.