herzogfloria/AISE502
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Auto-commit 2026-09-07 14:38: 9 files changed, 12968 insertions(+)

Browse Source
This commit is contained in:
herzogflorian 2026-09-07 14:38:39 +02:00
parent 95a0c4373b
commit 6dd749e958
9 changed files with 12968 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1079
Folien/Planung_7-13_json/L10.json Normal file
View File

File diff suppressed because it is too large Load Diff

894
Folien/Planung_7-13_json/L11.json Normal file
View File

@ -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: <topic> -- <detail>' 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
}

994
Folien/Planung_7-13_json/L12.json Normal file
View File

@ -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
}

937
Folien/Planung_7-13_json/L13.json Normal file
View File

@ -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
}

751
Folien/Planung_7-13_json/L7.json Normal file
View File

@ -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
}

1110
Folien/Planung_7-13_json/L8.json Normal file
View File

File diff suppressed because it is too large Load Diff

1030
Folien/Planung_7-13_json/L9.json Normal file
View File

File diff suppressed because it is too large Load Diff

458
Folien/Planung_7-13_json/coverage_table.json Normal file
View File

@ -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"
}
]

5715
Folien/Planung_Vorlesungen_7-13.md Normal file
View File

File diff suppressed because it is too large Load Diff