% !TEX encoding = UTF-8 Unicode
% ============================================================================
% AISE502 -- AI in Software Engineering II
% Lecture 7 slides, typeset with the official FHGR beamer theme
% (beamerthemeFHGR.sty, University of Applied Sciences of the Grisons).
% Slide content is unchanged; only the presentation layer is the FHGR template.
% ============================================================================
\documentclass[aspectratio=169]{beamer}

\usetheme[showsection, titlebg=pics/theme_pics/titlepage.png]{FHGR}

% ============================================
% PACKAGES
% The theme already loads tikz, graphicx, xcolor, tabularx, colortbl,
% listings, hyperref, environ and xparse -- only the extras are needed here.
% ============================================
\usepackage[british]{babel}
\usepackage{booktabs}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{tcolorbox}
\usetikzlibrary{shapes.geometric, arrows.meta, positioning, fit, backgrounds, calc}

% ============================================
% SEMANTIC COLOURS, MAPPED ONTO THE FHGR PALETTE
% The names used throughout the slides are kept, so no slide text changes;
% they now resolve to the FHGR brand colours defined by the theme.
% ============================================
\colorlet{bankblue}{blue}          % FHGR blue   (4B92A4)
\colorlet{bankgreen}{green}        % FHGR green  (817E65)
\colorlet{bankred}{red}            % FHGR red    (C60219)
\colorlet{codegray}{gray}          % FHGR gray   (595959)
\colorlet{backcolour}{linen}       % FHGR linen  (E1D3B5)
\definecolor{aiviolet}{HTML}{6B4E71} % muted plum, kept distinct for the AI lens

% Attribution labels in English (theme default is German)
\renewcommand{\source}[1]{\par\hfill {\tiny\color{FHGRDeco} Source:\,\itshape #1}}
\renewcommand{\imagesource}[1]{\par\hfill {\tiny\color{FHGRDeco} Image source:\,\itshape #1}}

% ============================================
% CUSTOM TCOLORBOXES (same semantics as the script, FHGR colours)
% ============================================
\newtcolorbox{keypoint}{
    colback=bankblue!7!white,
    colframe=bankblue,
    title=Key Concept,
    fonttitle=\bfseries\small,
    boxrule=0.8pt,
    arc=2pt,
    top=2pt, bottom=2pt, left=4pt, right=4pt
}

\newtcolorbox{examplebox}[1][]{
    colback=bankgreen!10!white,
    colframe=bankgreen,
    title={Example: #1},
    fonttitle=\bfseries\small,
    boxrule=0.8pt,
    arc=2pt,
    top=2pt, bottom=2pt, left=4pt, right=4pt
}

\newtcolorbox{definitionbox}[1][]{
    colback=linen!40!white,
    colframe=camel!85!black,
    title={Definition: #1},
    fonttitle=\bfseries\small,
    boxrule=0.8pt,
    arc=2pt,
    top=2pt, bottom=2pt, left=4pt, right=4pt
}

\newtcolorbox{thinkbox}{
    colback=lightGray!35!white,
    colframe=darkGray,
    title=Discussion,
    fonttitle=\bfseries\small,
    boxrule=0.8pt,
    arc=2pt,
    top=2pt, bottom=2pt, left=4pt, right=4pt
}

\newtcolorbox{hinweisbox}{
    colback=bankred!5!white,
    colframe=bankred,
    title=Important Note,
    fonttitle=\bfseries\small,
    boxrule=0.8pt,
    arc=2pt,
    top=2pt, bottom=2pt, left=4pt, right=4pt
}

\newtcolorbox{ailinse}[1][]{
    colback=aiviolet!7!white,
    colframe=aiviolet,
    title={AI Lens: #1},
    fonttitle=\bfseries\small,
    boxrule=0.8pt,
    arc=2pt,
    top=2pt, bottom=2pt, left=4pt, right=4pt
}

\newtcolorbox{projektbox}{
    colback=bankblue!4!white,
    colframe=bankblue!70!black,
    title=Project Link: Portfolio Intelligence Platform,
    fonttitle=\bfseries\small,
    boxrule=0.8pt,
    arc=2pt,
    top=2pt, bottom=2pt, left=4pt, right=4pt
}

% ============================================
% TITLE METADATA
% ============================================
\title[AI in Software Engineering II]{AISE502: AI in Software Engineering II}
\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}
\shortname{AISE502}
\fullname{Fachhochschule Graub\"unden, Chur -- Autumn Semester 2026}

\begin{document}

% ============================================
% TITLE SLIDE
% ============================================
\FHGRTitlePage

% ============================================
% AGENDA
% ============================================
\begin{frame}{Agenda}
\small
\begin{enumerate}\setlength\itemsep{1pt}
    \item Recap: the match, seen once at small scale -- and run by you last week
    \item Three matches, three stages: \textbf{C6} (gate), \textbf{C1} (veto), \textbf{C2} (holistic reading and its alarm)
    \item The procedure in general -- and what a weighted sum would have destroyed
    \item The matching matrix: cell semantics and the $7 \times 10$ grid
    \item Reading the matrix as a whole: columns, rows, five support points
    \item The measurement contract, introduced: fitness functions and the DORA metrics
    \item This week's exercise: \textbf{the design-review gate and Deliverable A2}
\end{enumerate}
\end{frame}

% ============================================
% RECAP
% ============================================
\section{Recap}

\begin{frame}{Recap: where we are}
\footnotesize
\begin{center}
\small demand $\;\to\;$ supply $\;\to\;$ \textbf{match} $\;\to\;$ record $\;\to\;$ \textbf{test}
\end{center}

\vspace{0.1cm}
\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}).

\vspace{0.1cm}
\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 -- today you will recognise every step.

\vspace{0.1cm}
\textbf{Today}:
\begin{itemize}\setlength\itemsep{1pt}
    \item three cases from Part IV, \textbf{one per stage}
    \item the general statement and the \textbf{seventy-cell grid}
    \item the \textbf{measurement contract}, introduced
\end{itemize}

\vspace{0.1cm}
\begin{hinweisbox}
\footnotesize \textbf{A2 is due this week} -- the architecture dossier (ADR $+$ C4 $+$ measurement contract); the design-review gate closes the design phase; production code only after the gate.
\end{hinweisbox}
\end{frame}

% ============================================
% THREE MATCHES, THREE STAGES
% ============================================
\section{Three Matches, Three Stages}

\begin{frame}{Part IV opens: three matches, three stages}
\emph{\textcolor{bankblue}{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}.

\vspace{0.1cm}
\footnotesize
\begin{itemize}\setlength\itemsep{1pt}
    \item Every Part III class ends with a \textbf{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; the other rows follow in weeks 8--9
    \item 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 (the C10 mini-match); not yet seen: \textbf{the machine at full load}
    \item 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
\end{itemize}

\vspace{-0.05cm}
\begin{center}
\resizebox{\textwidth}{!}{%
\begin{tikzpicture}[
    box/.style={rectangle, draw, rounded corners=3pt, align=center, font=\small\sffamily, minimum height=0.5cm, inner sep=3pt},
    today/.style={box, fill=bankblue!20, draw=bankblue},
    later/.style={box, fill=gray!15, draw=gray!60!black, text=gray!60!black},
    lab/.style={font=\small\sffamily\bfseries, anchor=east, minimum width=1.9cm, align=right},
    node distance=0.2cm
]
    \node[lab, text=bankblue] (l1) at (0,0) {Today:};
    \node[today, right=0.2cm of l1] (a) {\S30 three cases};
    \node[today, right=of a] (b) {\S31 the procedure};
    \node[today, right=of b] (c) {\S32 the matrix};
    \node[today, right=of c] (d) {\S34 reading the matrix};
    \node[today, right=of d] (e) {\S37 the contract (introduction)};
    \node[lab, text=gray!60!black] (l2) at (0,-0.68) {Lecture 10:};
    \node[later, right=0.2cm of l2] (f) {\S33 rationales};
    \node[later, right=of f] (g) {\S35 hybrids and evolution paths};
    \node[later, right=of g] (h) {\S36 eight-step decision procedure};
    \node[lab, text=gray!60!black] (l3) at (0,-1.36) {Lecture 11:};
    \node[later, right=0.2cm of l3] (i) {\S37 the contract in depth};
    \node[later, right=of i] (j) {\S38 organisational complement};
    \node[later, right=of j] (k) {\S39 limits};
\end{tikzpicture}%
}
\end{center}
\end{frame}

\begin{frame}{Case 1 -- C6 against all seven: the shape gate}
\emph{\textcolor{bankblue}{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?}}

\vspace{0.05cm}
\footnotesize
\begin{itemize}\setlength\itemsep{0pt}
    \item The C6 profile (given here as the operand; Part III, Lecture 9): High on \textbf{D2} (makespan reading), \textbf{D9} (reproducibility reading), \textbf{D10}; shape \textbf{scheduled batch}; deterministic seeds as a hard constraint
    \item Before comparing a single rating, hold $S(\text{C6}) = $ scheduled batch against the native-shape row $S(p)$ of the capability table (deck 6): \textbf{only PF proceeds to Stages 2--3}; the table carries the gate and its harm clause, and its verdict column is identical to the C6 row of the matching matrix
\end{itemize}

\vspace{-0.05cm}
\scriptsize
\renewcommand{\arraystretch}{0.85}%
\begin{center}
\begin{tabular}{@{}lp{2.6cm}p{7.6cm}c@{}}
\toprule
\textbf{Pattern} & \textbf{Native shape $S(p)$} & \textbf{Stage-1 outcome} & \textbf{Verdict} \\
\midrule
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$ \\
\bottomrule
\end{tabular}
\end{center}
\end{frame}

\begin{frame}{Case 1 -- one survivor, and the didactic point}
\footnotesize
\begin{itemize}\setlength\itemsep{2pt}
    \item \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
    \item Its $--$ on D3 sits on a Low weight and is \emph{inert}; the holistic reading ranks a field of one
    \item \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
    \item The didactic point generalises: \textbf{run the cheapest test first} -- six of seven candidates died before a single rating was weighed
    \item 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
    \item The verdict the class's Part III section states (Lecture 9): \textbf{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
\end{itemize}
\end{frame}

\begin{frame}{Case 2 -- C1: the gate passes both, the veto rule decides}
\emph{\textcolor{bankblue}{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?}}

\vspace{-0.05cm}
\footnotesize
\begin{itemize}\setlength\itemsep{0pt}
    \item From the deck-6 mirror pair: C1 High on \textbf{D4, D5, D6, D7, D9}; $K(\text{C1})$: ACID booking core, BCBS 239 / FINMA auditability; shape interactive with batch edges. Contested pair: \textbf{MM against MS} -- the two columns side by side
    \item \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
    \item \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 $-$}
    \item The fact is \emph{structural}: a mitigation can only show that living without the property is \emph{survivable} -- yes, but conditional: 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)
    \item 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$}
\end{itemize}
\end{frame}

\begin{frame}{Case 2 -- stage 2 for MM, and the stage-3 reading}
\footnotesize
\begin{itemize}\setlength\itemsep{3pt}
    \item \textbf{Stage 2 -- veto rule for MM.} $c_4(\text{MM}) = {++}$ (cross-module ACID transactions) -- no veto
    \item But $c_5(\text{MM}) = {-}$ on High-weight D5 $\to$ caps the cell at $\circ$ -- \emph{unless a documented mitigation exists}
    \item 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.
    \item \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
    \item \textbf{Result: $\mathrm{fit}(\text{C1},\text{MM}) = {++}$}
    \item 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
\end{itemize}
\end{frame}

\begin{frame}{Case 2 -- two kinds of mitigation, and the C1 verdict}
\footnotesize
\begin{columns}[T]
\begin{column}{0.40\textwidth}
\textcolor{bankblue}{\textbf{Operational weakness}}
\begin{itemize}\setlength\itemsep{1pt}
    \item MM's one-process blast radius (D5)
    \item \emph{repaired outright} by a standard tactic -- hot standby, pod replication
\end{itemize}
\end{column}
\begin{column}{0.56\textwidth}
\textcolor{bankblue}{\textbf{Structural weakness}}
\begin{itemize}\setlength\itemsep{1pt}
    \item atomicity surrendered at the boundary (MS, D4): no mitigation \emph{restores} ACID across service boundaries -- sagas buy coordination with compensating actions, not atomicity
    \item can only be \emph{made survivable}, under a condition most organisations do not meet (Monzo, deck 5) -- the premium paid in platform staffing with no gain for typical team sizes
\end{itemize}
\end{column}
\end{columns}

\vspace{0.05cm}
\begin{itemize}\setlength\itemsep{1pt}
    \item 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}
    \item 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
\end{itemize}

\vspace{0.05cm}
\textbf{The verdict the class's Part III section states (Lecture 8): a 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.
\end{frame}

\begin{frame}{Case 3 -- C2: when scoring cannot separate the survivors}
\emph{\textcolor{bankblue}{Two finalists carry $++$ where it matters and neither dominates: what does the procedure return when scoring cannot separate the survivors?}}

\vspace{0.05cm}
\footnotesize
\begin{itemize}\setlength\itemsep{2pt}
    \item 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
    \item \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)
    \item Neither MS (natively interactive) nor EDA (natively stream/async) is shape-foreign to the path it would carry $\to$ \textbf{the gate passes both}
    \item \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)
    \item Both reach Stage 3 intact
\end{itemize}
\end{frame}

\begin{frame}{Case 3 -- stage 3: the comparison refuses to close}
\scriptsize
\renewcommand{\arraystretch}{0.9}%
\begin{center}
\begin{tabular}{@{}p{4.2cm}cc@{}}
\toprule
\textbf{High dimension (C2)} & \textbf{MS} & \textbf{EDA} \\
\midrule
D1 Read scalability & $++$ & $++$ \\
D3 Latency \& predictability & (mitigated) & $+$ \\
D5 Availability \& isolation & $++$ & $++$ \\
D7 Evolvability & $++$ & $++$ \\
D9 Testability \& deployability & $+$ & (mitigated) \\
D11 Team scaling & $++$ & $+$ \\
\bottomrule
\end{tabular}
\end{center}

\vspace{0.1cm}
\footnotesize
\begin{itemize}\setlength\itemsep{2pt}
    \item \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)
    \item 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
    \item By Stage 3's own rule, that instability is \textbf{not noise}: it marks a genuine trade-off point in the ATAM sense, to be escalated to scenario-based analysis rather than smoothed over
\end{itemize}
\end{frame}

\begin{frame}{Case 3 -- the record refuses the either/or}
\footnotesize
\begin{itemize}\setlength\itemsep{2pt}
    \item 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
    \item 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
    \item 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
\end{itemize}

\vspace{0.1cm}
\begin{keypoint}
\footnotesize \textbf{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). \emph{Every one of the seventy cells was produced by exactly this division of labour.}
\end{keypoint}
\end{frame}

% ============================================
% THE PROCEDURE IN GENERAL
% ============================================
\section{The Procedure in General}

\begin{frame}{The formal statement -- the deck-3 box, plus one clause}
\footnotesize
\emph{\textcolor{bankblue}{What rule were the three matches following?}} Stated briefly -- 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)$, same five-step scale, \textbf{non-compensatory, three stages}.

\vspace{-0.1cm}
\begin{definitionbox}[Architecture--application fit $\mathrm{fit}(a,p)$]
\footnotesize
\begin{enumerate}\setlength\itemsep{0pt}
    \item \textbf{Knock-out screening and workload-shape gate.} $K(a)$ eliminates before any scoring; $S(p) \neq S(a)$ caps 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 its native shape (Case 3: C2's fan-out delivery scenario).
    \item \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.
    \item \textbf{Holistic ordinal reading with mandatory sensitivity analysis.} Survivors ranked by support of the High set; clustered Medium conflicts \emph{can} downgrade one step; a \emph{ranking with exclusions}, never ``12\,\% better''; a flip under plausible weight variation marks a trade-off point (ATAM) $\to$ scenario-based analysis.
\end{enumerate}
\end{definitionbox}
\end{frame}

\begin{frame}{Three stages, decreasing hardness -- each with a worked face}
\footnotesize
The three stages are ordered by \textbf{decreasing hardness}, and each now has a worked face:

\vspace{0.1cm}
\renewcommand{\arraystretch}{1.0}%
\begin{center}
\begin{tabular}{@{}p{2.6cm}p{5.6cm}p{4.9cm}@{}}
\toprule
\textbf{Stage} & \textbf{What it encodes} & \textbf{Worked face} \\
\midrule
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 \\[0.2cm]
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) \\[0.2cm]
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 \\
\bottomrule
\end{tabular}
\end{center}
\end{frame}

\begin{frame}{Why the fit is not a weighted sum}
\footnotesize
\begin{itemize}\setlength\itemsep{2pt}
    \item 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
    \item \textbf{What the three cases add -- a demonstration of what the formula would have destroyed:} \textbf{C6} -- it would have averaged the shape gate away under good scores elsewhere $\cdot$ \textbf{C1} -- it would have let MS's missing cross-service ACID be compensated by team scaling $\cdot$ \textbf{C2} -- it would have manufactured a decimal-point winner exactly where the honest output is a flagged trade-off point
    \item 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)
\end{itemize}

\vspace{0.1cm}
\begin{keypoint}
\footnotesize The fit computation is \textbf{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. \emph{A weighted sum over ordinal profiles would be formally illegitimate and would average away exactly the failures that matter most.}
\end{keypoint}
\end{frame}

% ============================================
% THE MATCHING MATRIX
% ============================================
\section{The Matching Matrix}

\begin{frame}{Cell semantics: what one cell of the grid actually claims}
\footnotesize
\emph{\textcolor{bankblue}{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.

\vspace{0.1cm}
\begin{definitionbox}[Cell semantics of the matching matrix]
\footnotesize 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.
\end{definitionbox}

\vspace{0.1cm}
\begin{itemize}\setlength\itemsep{2pt}
    \item \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
    \item \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''
\end{itemize}
\end{frame}

\begin{frame}{The $7 \times 10$ matching matrix}
\scriptsize
\renewcommand{\arraystretch}{0.85}%
\begin{center}
\begin{tabular}{@{}p{4.2cm}ccccccc@{}}
\toprule
\textbf{Application class} & \textbf{L} & \textbf{MM} & \textbf{HX}$^{\dagger}$ & \textbf{MS} & \textbf{EDA} & \textbf{PF} & \textbf{SL} \\
\midrule
\rowcolor{bankblue!8} C1 Core banking / transactions & $\circ$ & {\boldmath$++$} & {\boldmath$++$} & $\circ$ & $-$ & $\circ$ & $-$ \\
\rowcolor{bankblue!8} 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$ & $+$ \\
\rowcolor{bankblue!8} 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$ \\
\bottomrule
\end{tabular}
\end{center}

\vspace{0.1cm}
Ratings $++$ (excellent fit) to $--$ (structural misfit); \textbf{bold} $=$ cells underlying the primary recommendation of each class; shaded rows $=$ the rows you computed today. $^{\dagger}$\,HX is a delta pattern -- it composes with a host (typically MM), its cells read ``as the internal discipline of the class's core''. L $=$ layered/3-tier, MM $=$ modular monolith, MS $=$ microservices, EDA $=$ event-driven, PF $=$ pipes-and-filters/batch pipeline, SL $=$ serverless/FaaS.
\end{frame}

\begin{frame}{Reading the grid: the rows you computed}
\footnotesize
\begin{itemize}\setlength\itemsep{2pt}
    \item The matrix is the three cases of Section 30, \textbf{done seventy times}
    \item 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
    \item Every cell is traceable to $R(a) \times C(p)$ through the per-class rationales (Section 33 -- Lecture 10)
    \item $^{\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''
\end{itemize}

\vspace{0.15cm}
\begin{keypoint}
\footnotesize 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 \textbf{hybrids are the normal case, not the exception}.
\end{keypoint}
\end{frame}

% ============================================
% READING THE MATRIX AS A WHOLE
% ============================================
\section{Reading the Matrix as a Whole}

\begin{frame}{Column patterns (1/2): the unfashionable default}
\footnotesize
\emph{\textcolor{bankblue}{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.

\vspace{0.05cm}
\begin{itemize}\setlength\itemsep{2pt}
    \item 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)
    \item 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
    \item \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
    \item 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}
\end{itemize}
\end{frame}

\begin{frame}{Column patterns (2/2): workload-shaped columns, HX never negative}
\footnotesize
\begin{columns}[T]
\begin{column}{0.58\textwidth}
\begin{itemize}\setlength\itemsep{3pt}
    \item \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)
    \item The shape gate caps them at $\circ$ -- or, by the harm clause, below -- everywhere the class core is interactive
    \item 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}
    \item \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)
\end{itemize}
\end{column}
\begin{column}{0.38\textwidth}
\scriptsize
\renewcommand{\arraystretch}{0.9}%
\begin{center}
\begin{tabular}{@{}lccccc@{}}
\toprule
\textbf{Class} & \textbf{MM} & \textbf{MS} & \textbf{HX} & \textbf{EDA} & \textbf{PF} \\
\midrule
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$ & $++$ & $+$ & $+$ \\
\bottomrule
\end{tabular}
\end{center}
\vspace{0.05cm}
\centering Five columns of the matching matrix
\end{column}
\end{columns}
\end{frame}

\begin{frame}{Row patterns and the five empirical support points}
\footnotesize
\begin{itemize}\setlength\itemsep{1pt}
    \item 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
    \item If a dominant pattern existed, its column would be uniformly positive, and this part of the module would be one page long
    \item 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}
\end{itemize}

\vspace{0.1cm}
\scriptsize
\renewcommand{\arraystretch}{1.0}%
\begin{center}
\begin{tabular}{@{}p{2.4cm}p{4.6cm}p{6.1cm}@{}}
\toprule
\textbf{System} & \textbf{Cell it sits on} & \textbf{What was measured} \\
\midrule
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 \\
\bottomrule
\end{tabular}
\end{center}
\end{frame}

\begin{frame}{Discussion: the C5 row under two variations}
\footnotesize
\textbf{The C5 row (e-commerce) for reference:} L $-$ $\cdot$ MM {\boldmath$++$} $\cdot$ HX $+$ $\cdot$ MS $+$ $\cdot$ EDA $+$ $\cdot$ PF $\circ$ $\cdot$ SL $+$

\vspace{0.1cm}
\begin{thinkbox}
\footnotesize
\begin{enumerate}\setlength\itemsep{1pt}
    \item Take the C5 row (e-commerce) and \textbf{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?
    \item Now hold the organisation at 3 teams and \textbf{multiply traffic by 50}.
    \item 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''?
\end{enumerate}
\end{thinkbox}

\vspace{0.1cm}
\begin{keypoint}
\footnotesize 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.
\end{keypoint}
\end{frame}

% ============================================
% THE MEASUREMENT CONTRACT, INTRODUCED
% ============================================
\section{The Measurement Contract, Introduced}

\begin{frame}{How a decision made this year stays honest in year five}
\emph{\textcolor{bankblue}{How does a decision made this year stay honest in year five?}} \small One case motivates the apparatus.

\vspace{0.05cm}
\footnotesize
\begin{itemize}\setlength\itemsep{0pt}
    \item 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
    \item 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''
    \item 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
    \item 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.''}}
\end{itemize}
\end{frame}

\begin{frame}{Fitness functions -- the definition}
\footnotesize 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.

\vspace{0.1cm}
\begin{definitionbox}[Architectural fitness function]
\footnotesize ``Any mechanism that provides an objective integrity assessment of some architectural characteristic.'' Fitness functions turn quality attributes into \textbf{executable, objective checks} and move architecture governance from review meetings into the CI/CD pipeline.
\end{definitionbox}

\vspace{0.15cm}
\footnotesize Classified along two primary dimensions:

\vspace{0.05cm}
\renewcommand{\arraystretch}{1.1}%
\begin{center}
\begin{tabular}{@{}p{1.6cm}p{11.6cm}@{}}
\toprule
\textbf{Scope} & \emph{atomic} -- one characteristic in isolation (e.g.\ a dependency rule as a unit test) \newline \emph{holistic} -- combined characteristics in interplay (e.g.\ security and data freshness under load) \\
\midrule
\textbf{Cadence} & \emph{triggered} -- event-based, on every build or deployment \newline \emph{continual} -- running permanently in operation (e.g.\ chaos experiments) \newline \emph{temporal} -- time-scheduled (e.g.\ dependency-freshness time bombs) \\
\bottomrule
\end{tabular}
\end{center}
\end{frame}

\begin{frame}{Three instrument families}
\footnotesize Three worked instrument families recur throughout the module:

\vspace{0.1cm}
\scriptsize
\renewcommand{\arraystretch}{1.0}%
\begin{center}
\begin{tabular}{@{}>{\raggedright\arraybackslash}p{2.0cm}p{4.8cm}>{\raggedright\arraybackslash}p{1.6cm}p{4.2cm}@{}}
\toprule
\textbf{Family} & \textbf{Instruments} & \textbf{Scope /}\newline\textbf{cadence} & \textbf{What it makes testable} \\
\midrule
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 \\[0.15cm]
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} \\[0.15cm]
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 \\
\bottomrule
\end{tabular}
\end{center}
\end{frame}

\begin{frame}{DORA metrics: the delivery layer -- and the coupling finding}
\footnotesize
\begin{itemize}\setlength\itemsep{0pt}
    \item 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)
    \item Central empirical finding: elite performers lead on \emph{all four} -- \textbf{tempo and stability are not a trade-off}
    \item 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
    \item 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}
    \item 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
\end{itemize}

\vspace{0.05cm}
\begin{hinweisbox}
\footnotesize DORA's evidence is survey-based and analysed with structural equation models -- \textbf{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.
\end{hinweisbox}
\end{frame}

% ============================================
% CLOSING
% ============================================
\section{Closing}

\begin{frame}{This week's exercise: the design-review gate and Deliverable A2}
\begin{projektbox}
\footnotesize \textbf{The design phase closes this week.} Finalise the solution design:
\begin{enumerate}\setlength\itemsep{1pt}
    \item \textbf{Service cut and contracts} -- bounded contexts $\to$ service decomposition and the contracts between the deterministic core, the edges, and the AI subsystem
    \item \textbf{Walking-skeleton plan} -- the thin end-to-end slice you will build first in Sprint 1
    \item \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)
    \item \textbf{Design-review gate} -- defend the ADR: which vetoes fired, which mitigations are \emph{documented}, what the sensitivity check showed
\end{enumerate}
\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).
\end{projektbox}

\vspace{0.1cm}
\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 (M3, walking skeleton) begins.
\end{frame}

\begin{frame}{Summary}
\footnotesize
\begin{enumerate}\setlength\itemsep{2pt}
    \item \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
    \item \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)
    \item \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
    \item \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
    \item \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)
    \item \textbf{Five support points}: Prime Video, Segment, Shopify, Uber, Stack Overflow each sit on a cell boundary -- fit and misfit measured in money
    \item \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}
\end{enumerate}
\end{frame}

\begin{frame}{Next week}
\begin{columns}[T]
\begin{column}{0.55\textwidth}
\textcolor{bankblue}{\textbf{Lecture 8 (week 8, 3 lessons) -- Part III: application classes C1--C5}}
\begin{itemize}\small
    \item challenges $\to$ requirements profiles $\to$ what real systems chose
    \item the rows C1--C5 of today's matrix, derived from the demand side
\end{itemize}
\end{column}
\begin{column}{0.42\textwidth}
\textcolor{bankblue}{\textbf{Reading}}
\begin{itemize}\small
    \item this week: Part IV, Sections 30--32, 34; Section 37 (introduction)
    \item ahead: Part III, Sections 18--23
\end{itemize}

\vspace{0.2cm}
\textcolor{bankblue}{\textbf{Exercise / deliverable}}
\begin{itemize}\small
    \item \textbf{A2 $+$ design-review gate: this week}
    \item from week 8: Sprint 1 / M3 -- walking skeleton (\texttt{MarketDataService} $+$ minimal \texttt{ResearchAgent} $+$ stable API); the exercise slot becomes a one-lesson standup/coaching
\end{itemize}
\end{column}
\end{columns}
\end{frame}


% ============================================
% END
% ============================================
\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}}}}]

\end{document}