AISE502/skript/chapters/part3_application_classes.tex

% ============================================================
% AISE502 -- Part III: Requirements Profiles:
% The Ten Application Classes
% ============================================================

\part{Requirements Profiles: The Ten Application Classes}
\label{part:applications}

% ============================================
% SECTION: APPLICATION CLASSES AS REQUIREMENTS PROFILES
% ============================================
\section{Application Classes as Requirements Profiles}
\label{sec:appclass-intro}

Part~\ref{part:patterns} characterised the supply side of the matching problem: seven architectural patterns, each described by a capability profile $C(p)$ over the twelve dimensions of Table~\ref{tab:dimensions}. This part characterises the demand side -- and if architecture selection is a matching problem, the operational consequence of Assumptions A2 and A3 in Part~\ref{part:foundations}, then the demand side must be described in the \emph{same} vocabulary and at the \emph{same} resolution as the supply side. A statement such as ``we are building a banking system'' carries almost no architectural information; a statement such as ``an instant payment must reach confirmed finality in under ten seconds end-to-end, with zero transaction loss, under a regulator-enforced audit obligation'' carries almost all of it. The unit that packages such statements is the \emph{application class}.

\begin{definitionbox}[Application class]
An \emph{application class} is a recurring bundle of architecturally significant requirements (ASRs): a set of dominant quality attribute scenarios with \emph{typical response measures}, a characteristic \emph{workload shape} with its quantitative signature, and a \emph{regulatory frame} that acts as a set of hard constraints \citep{bass2021software, chen2013characterizing}. Formally, a class $a$ is described by its requirements profile
\[
R(a) = \bigl(w_1(a), \ldots, w_{12}(a);\; S(a);\; K(a)\bigr),
\]
where $w_i(a) \in \{\text{H}, \text{M}, \text{L}\}$ weights profile dimension $D_i$, $S(a)$ is the dominant workload shape, and $K(a)$ is the set of hard constraints (see the formal model in Part~\ref{part:foundations}).
\end{definitionbox}

Two pieces of method recall are needed before the catalogue begins, because every class section uses them: where the weights come from, and what the shape and constraint elements do.

\subsection{Where the weights come from: utility trees, not opinions}
\label{subsec:weights-origin}

The weights $w_i(a)$ are not editorial judgements. Assumption A4 states that a quality attribute becomes decision-relevant only as a six-part scenario -- source, stimulus, environment, artifact, response, response measure -- and that architecturally significant requirements are empirically vague and implicit and must be elicited systematically \citep{bass2021software, chen2013characterizing}. The elicitation instruments are the Quality Attribute Workshop \citep{barbacci2003quality} and the \emph{utility tree} of the ATAM method, in which each scenario leaf is rated on the pair (business importance, achievement difficulty), each on \{H, M, L\} \citep{kazman2000atam}. The (H,\,H) leaves of a class's characteristic utility tree \emph{are} the High weights of $R(a)$. A weight in this part is therefore a compressed empirical claim: ``systems of this class recurrently produce (H,\,H) scenario leaves on this dimension.'' Each class section makes that claim auditable: it leads with the class's documented challenges -- incidents, production numbers, statutory obligations -- and states two to three \emph{binding scenarios} with response measures, of the kind that populate the (H,\,H) region of the class's utility tree.

The semantics of the three weight levels follow the formal model of Part~\ref{part:foundations} and are deliberately asymmetric:

\begin{itemize}
    \item \textbf{H (High)} -- the dimension carries binding scenarios; it exercises \emph{veto power}. If a pattern's capability rating on an H-weighted dimension is $--$, the fit of that pattern is capped at $-$; if the rating is $-$, the cap is $\circ$ -- unless a documented mitigation with production evidence exists, in which case the matrix cell in Part~\ref{part:fit} says so explicitly.
    \item \textbf{M (Medium)} -- the dimension matters and is measured, but conflicts on it are noted rather than vetoed; clustered Medium conflicts can downgrade a fit rating by one step.
    \item \textbf{L (Low)} -- the dimension does not discriminate for this class; effort spent optimising it is, for this class, waste.
\end{itemize}

\begin{hinweisbox}
H does not mean ``more important than M in a weighted sum''. There is no weighted sum: the profiles are ordinal, and the aggregation in Part~\ref{part:foundations} is deliberately non-compensatory \citep{keeney1993decisions}. An H weight is a \emph{veto trigger}, not a coefficient. Ten excellent Medium ratings cannot buy back one violated High-weighted dimension -- exactly as no amount of feature velocity buys back a double-posted booking in a ledger.
\end{hinweisbox}

\subsection{Workload shape and hard constraints}
\label{subsec:shape-constraints}

$S(a)$, the dominant workload shape, is the second load-bearing element of a profile. Four shapes recur: \emph{interactive} request/response, \emph{continuous stream}, \emph{scheduled batch}, and explicitly \emph{hybrid} combinations. The shape gate of the decision procedure (Part~\ref{part:foundations}) operates on it: a pattern whose native shape does not match the dominant $S(a)$ cannot be the dominant structure of the class's core, however attractive its other ratings. Each shape carries a quantitative signature -- read/write ratio, load pattern, latency budget, data volume, change rate -- and the class sections report these signatures with documented production numbers, because a workload claim without a number is as unfalsifiable as a scalability requirement without one.

$K(a)$, the set of hard constraints, is where regulation enters the theory. Constraints are \emph{knock-out filters}, not weights: a pattern or deployment form that violates a constraint is excluded before any scoring and can never be averaged away \citep{keeney1993decisions}. For the classes in this catalogue the constraints are predominantly regulatory -- BCBS~239 risk-data aggregation \citep{bcbs2013rdarr}, FINMA Circular 2023/1 \citep{finma2023oprisk}, DORA \citep{eu2022dora}, PCI~DSS v4.0 \citep{pcissc2022pcidss}, the EU AI Act \citep{eu2024aiact} -- plus organisational facts (team size and skills, mandated platforms, budget). Regulation, in this theory, is not a compliance afterthought: it is a first-class architectural requirement that translates directly into structure -- immutable journals, scope zoning, data classification at module boundaries, logging obligations for AI components.

\begin{keypoint}
An application class is not an industry label; it is an ASR bundle. The weights of its requirements profile are derived from the (H,\,H) leaves of its characteristic utility tree; its workload shape gates which patterns can carry its core; its regulatory constraints knock candidates out before scoring begins. One organisation typically operates \emph{several} classes at once -- a bank runs a C1 booking core, C3 back-office workflows, C6 overnight risk runs, C7 reporting, and increasingly a C10 advisory layer -- which is why the fit matrix of Part~\ref{part:fit} is read per subsystem, never per company logo.
\end{keypoint}

\subsection{A map of the ten classes}
\label{subsec:classmap}

Two variables discriminate more strongly between the classes than any others: the dominant workload shape and the consistency semantics that the class core requires. Figure~\ref{fig:classmap} places the ten classes on these two axes. The horizontal axis is not a continuum in the metric sense -- consistency models are qualitatively distinct \citep{kleppmann2017designing, vogels2009eventually} -- but it is ordinally meaningful: from strict ACID on the left, through hybrid and per-subsystem splits, to eventual consistency on the right. Two classes sit at semantics that are neither ACID nor eventual: C6 requires \emph{reproducibility} (``identical inputs and seeds yield bit-identical outputs''), and C7 requires \emph{freshness by refresh contract} (``consistent as of yesterday 24:00'') -- a third family of consistency semantics that Sections~\ref{sec:c6} and~\ref{sec:c7} develop.

\begin{figure}[htbp]
\centering
\resizebox{\textwidth}{!}{%
\begin{tikzpicture}[
    x=1cm, y=1cm,
    classnode/.style={rectangle, draw, rounded corners=3pt, minimum width=2.0cm, minimum height=0.85cm, align=center, font=\scriptsize\sffamily, line width=0.8pt},
    inter/.style={classnode, fill=bankblue!15, draw=bankblue},
    stream/.style={classnode, fill=bankgreen!15, draw=bankgreen},
    batchn/.style={classnode, fill=gray!15, draw=gray!60!black},
    hybridn/.style={classnode, fill=projteal!15, draw=projteal, font=\scriptsize\sffamily\bfseries},
    bandlabel/.style={font=\scriptsize\sffamily\bfseries, anchor=west, text=gray!50!black},
    axislabel/.style={font=\scriptsize\sffamily, text=gray!50!black}
]
    % --- workload-shape bands ---
    \fill[gray!6]  (0,6.0) rectangle (13.6,8.7);
    \fill[gray!12] (0,4.1) rectangle (13.6,6.0);
    \fill[gray!6]  (0,2.2) rectangle (13.6,4.1);
    \fill[gray!12] (0,0.3) rectangle (13.6,2.2);
    \node[bandlabel] at (0.15,8.45) {interactive request/response};
    \node[bandlabel] at (0.15,5.75) {continuous stream};
    \node[bandlabel] at (0.15,3.85) {scheduled batch};
    \node[bandlabel] at (0.15,1.95) {hybrid: interactive + batch/async};
    % --- consistency axis ---
    \draw[-{Stealth[length=2.5mm]}, thick, gray!60!black] (0,0) -- (13.6,0);
    \foreach \x in {1.7,5.6,9.2,12.5} \draw[gray!60!black, thick] (\x,0) -- (\x,0.12);
    \node[axislabel, anchor=north] at (1.7,-0.1) {strict ACID};
    \node[axislabel, anchor=north] at (5.6,-0.1) {hybrid (split by subsystem)};
    \node[axislabel, anchor=north] at (9.2,-0.55) {causal / per-key / by contract};
    \node[axislabel, anchor=north] at (12.5,-0.1) {eventual};
    \node[axislabel, anchor=north] at (6.8,-1.1) {consistency semantics required by the class core (guarantee weakens $\rightarrow$)};
    % --- interactive band ---
    \node[inter] at (1.7,7.7)  {C1 core banking\\ \tiny ACID ledger};
    \node[inter] at (1.7,6.6)  {C4 ERP\\ \tiny + batch runs};
    \node[inter] at (4.0,7.7)  {C3 back-office};
    \node[inter] at (5.6,6.7)  {C5 e-commerce\\ \tiny checkout ACID, catalogue eventual};
    \node[inter] at (9.2,7.6)  {C9 collab/messaging\\ \tiny connection-stateful, causal per channel};
    \node[inter] at (12.2,6.7) {C2 social/content\\ \tiny stale feed acceptable};
    % --- stream band ---
    \node[stream] at (10.9,5.0) {C8 IoT streaming\\ \tiny event time, exactly-once state};
    % --- batch band ---
    \node[batchn] at (7.3,3.2)  {C6 simulation/batch\\ \tiny reproducible (seeds)};
    \node[batchn] at (10.3,3.2) {C7 DSS/BI\\ \tiny fresh by refresh contract};
    % --- hybrid band ---
    \node[hybridn] at (5.6,1.25) {C10 AI-native advisory\\ \tiny index eventual, audit path ACID};
\end{tikzpicture}}%
\caption{The ten application classes located by dominant workload shape $S(a)$ (horizontal bands) and by the consistency semantics their core requires (horizontal axis). Positions are qualitative and follow the consolidated requirements table (Table~\ref{tab:requirements}) and its footnotes; C1 and C2 sit at opposite ends of the consistency axis within the same band -- the didactic mirror pair of this part. C10, the course project, is the only class whose \emph{shape} is constitutively hybrid.}
\label{fig:classmap}
\end{figure}

\subsection{How to read the class sections}
\label{subsec:howtoread}

Each of the following ten sections speaks the same rhythm, and it is the rhythm of Part~\ref{part:patterns} turned around -- there, a topology was priced across the twelve dimensions; here, a set of requirements is built up until the weights on those same dimensions follow. Each section opens with a plain leading question in italics and a characterisation with everyday examples; then comes \emph{the challenges it brings} -- the documented incidents, production numbers, and statutory obligations that generate the class's binding scenarios, each challenge tied explicitly to the dimension(s) it stresses; then \emph{the requirements profile} -- a twelve-row table that derives the weights from those challenges, cell-identical to the class's column in the consolidated table (Table~\ref{tab:requirements}, assembled at the end of this part once all ten classes have been seen); and finally \emph{what real systems chose -- and why} -- documented production architectures and open-source reference systems, read through the capability profiles of Part~\ref{part:patterns} (Tables~\ref{tab:cap-l}--\ref{tab:cap-sl}), closing with the class's primary and secondary recommendation. The order is the point: challenges first, weights after, structures last -- examples first, generalisation after. The formal matching of the profiles against Table~\ref{tab:capability} is the subject of Part~\ref{part:fit}; every closing recommendation in this part is a preview that Part~\ref{part:fit} recomputes through the three-stage procedure.

\begin{hinweisbox}
Classifying a concrete system as an instance of one of these classes is step~(i) of the decision procedure in Part~\ref{part:foundations} -- and it is a \emph{hypothesis about the system's ASR bundle}, to be inherited and then corrected against elicited scenarios, never a verdict. Real systems blend classes; the blend, not the label, is what the utility tree must capture.
\end{hinweisbox}

\begin{thinkbox}
Take three software systems you have used this week -- for instance your e-banking app, a messaging tool, and a streaming service. Which application classes do they instantiate? Which single quality attribute scenario, with which response measure, would you nominate as each system's most binding requirement? Where would a failure of that scenario become visible first: in revenue, in a regulator's report, or in user churn?
\end{thinkbox}

% ============================================
% SECTION: C1 CORE BANKING / TRANSACTION SYSTEMS
% ============================================
\section{C1 -- Core Banking / Transaction Systems}
\label{sec:c1}

\emph{A payment is booked twice, or not at all: which of the two can a bank survive?} Neither -- and that double impossibility is the class in one sentence. The class comprises systems of record for accounts, payments, and positions: the booking core of a bank, a payment-clearing platform, an exchange's matching and settlement layer -- the machinery behind your e-banking balance, the card authorisation at a supermarket till, the salary that arrives on the 25th. Its defining property is that a lost or double-posted booking event is an \emph{existential} defect -- it creates or destroys money -- whereas unavailability is expensive but reversible. Double-entry bookkeeping demands atomic, serialisable transactions over the ledger; this is the classical ACID territory \citep{kleppmann2017designing}. And auditability is not a preference but a regulator-enforced obligation: every state change must be journaled and reconstructable, which is why event-sourced journals and ledger data models fit this class naturally.

\subsection{The challenges it brings}

Start with the sums at stake. The Swiss Interbank Clearing system settles on average roughly CHF~226 billion per day, with peaks above CHF~386 billion \citep{snb2024sic}. At that volume a double-posted or lost booking is not a bug ticket; it is a balance-sheet event -- which is a demand on D4 (consistency and integrity) and D6 (auditability) before any other consideration. Every payment is a write, surrounded by several reads for cover checks, sanctions screening, and fraud scoring, so the class is comparatively \emph{write-critical} -- but the concurrency of those writes against shared accounts, not their raw rate, is what stresses D4.

The second challenge is a speed spread of six orders of magnitude \emph{within} one class: batch clearing takes hours, instant payments must complete in under 10\,s, card authorisation in 1--2\,s, and exchange trading operates at microseconds. Latency therefore matters everywhere but means something different in each regime -- which is why the profile weights D3 Medium with a footnote rather than High (Table~\ref{tab:requirements}, footnote~3). The SIC5 instant-payment infrastructure is dimensioned for load peaks in the order of 2{,}000 payments per second and is built on a clustered, in-memory replicated-state-machine design \citep{aeron2024six}; VisaNet states a \emph{capacity} of more than 65{,}000 transaction messages per second while its average load lies orders of magnitude below -- a textbook illustration of the difference between capacity dimensioning and normal load \citep{visa2018factsheet}, and the reason D2 (write scalability) is planned, not elastic, in this class. The load pattern itself is constant with deterministic peaks: end of day, end of month, salary runs. Unavailability, meanwhile, is a loss event on national infrastructure with regulator-defined disruption tolerances -- a demand on D5 (availability and fault isolation).

The third challenge is time. System lifetimes are measured in decades: Reuters reported in 2017 that 220 billion lines of COBOL remained in production use and that 43\,\% of US banking systems were COBOL-based \citep{reuters2017cobol} -- ossification is the class's documented failure mode, which makes D7 (evolvability) a High-weight \emph{requirement} precisely because it is so often unmet. The change-rate signature is bimodal: the booking core (account, posting) changes rarely, the periphery (channels, onboarding, products) changes constantly. Even the interfaces evolve on decade scales: SWIFT carried over one million ISO~20022 messages per day by the end of 2024, with the MT/MX coexistence phase ending in November 2025 -- a multi-year, industry-wide coordinated interface migration \citep{pymnts2024swift}, again a D7 stress. Data are structured, records small, and retention extreme (ten years and more).

Three binding scenarios compress these challenges into the (H,\,H) region of the utility tree -- Assumption A4 in action, each with its response measure:

\begin{itemize}
    \item \textbf{S1 (instant payment finality).} A customer submits an instant payment (stimulus) in normal operation (environment) to the payment core (artifact); the system clears, settles, and posts the payment with confirmed finality (response) in \textbf{under 10 seconds end-to-end, with zero transaction loss} (response measure) -- the operating regime for which the Swiss SIC5 instant-payment infrastructure was built \citep{aeron2024six}. A joint demand on D3, D4, and D5.
    \item \textbf{S2 (ledger integrity under concurrency).} Concurrent postings against the same account (stimulus) during peak load (environment) leave the double-entry invariant intact (response): \textbf{zero invariant violations, verified by a daily reconciliation job with zero unexplained discrepancies} (response measure) \citep{kleppmann2017designing}. The D4 veto scenario -- and, through the reconciliation job, a demand on D9 (testability).
    \item \textbf{S3 (audit-trail reconstruction).} An auditor requests the complete causal history of one transaction chosen at random (stimulus) up to ten years back (environment); the system reproduces the full trail (response) \textbf{within one working day, from immutable records} (response measure) -- the operational reading of BCBS~239's aggregation and reporting principles \citep{bcbs2013rdarr}. A demand on D6 and D9.
\end{itemize}

The regulatory frame turns several of these demands into knock-outs. $K(\text{C1})$ is the densest constraint set in the catalogue: BCBS~239 demands demonstrable risk-data aggregation and reporting capability -- a direct architectural requirement on data integration and lineage \citep{bcbs2013rdarr}. In Switzerland, FINMA Circular 2023/1 (in force since 1~January 2024) imposes ICT risk management, the protection of \emph{critical data} in confidentiality, integrity, and availability, and business-continuity requirements with defined disruption tolerances for critical functions \citep{finma2023oprisk}. In the EU, DORA (Regulation (EU) 2022/2554, applicable since 17~January 2025) adds ICT risk management, incident-reporting duties, resilience testing, and a third-party risk register \citep{eu2022dora}; the GDPR governs personal data throughout \citep{eu2016dsgvo}. Read as knock-outs: any candidate structure that cannot guarantee an ACID booking core, an immutable and complete audit journal, and ten-plus-year retention is eliminated \emph{before} any fit scoring -- however well it scales.

\subsection{The requirements profile}

With these challenges in mind, the weights follow -- and recall from Part~\ref{part:foundations} that every H exercises veto power in the matching. Table~\ref{tab:req-c1} derives the C1 column of the consolidated table, weight by weight.

\begin{table}[htbp]
\centering
\footnotesize
\caption{Requirements profile of C1 (core banking) -- column C1 of Table~\ref{tab:requirements}, cell-identical; note numbers refer to that table's footnotes.}
\label{tab:req-c1}
\begin{tabular}{@{}p{3.4cm}cp{8.3cm}@{}}
\toprule
\textbf{Dimension} & \textbf{Weight} & \textbf{Why} \\
\midrule
D1 Read scalability & M & every posting is surrounded by reads (cover checks, sanctions, fraud scoring), but volumes stay modest by consumer-platform standards \\
D2 Write scalability \& elasticity & M & load is constant with deterministic peaks; capacity is dimensioned ahead, not scaled elastically -- the VisaNet lesson \\
D3 Latency & M & class-internal spread of orders of magnitude, from trading microseconds to clearing hours (note~3) \\
D4 Consistency \& integrity & \textbf{H} & a lost or double-posted booking creates or destroys money; double-entry demands serialisable ACID transactions \\
D5 Availability \& fault isolation & \textbf{H} & payment rails are national infrastructure; outages are loss events with regulator-defined disruption tolerances \\
D6 Security \& auditability & \textbf{H} & the immutable audit journal is a statutory obligation (BCBS~239, FINMA 2023/1, DORA) \\
D7 Evolvability & \textbf{H} & lifetimes span decades and ossification is the documented failure mode -- the COBOL evidence \\
D8 Simplicity \& TTM & L & the class trades time-to-market for integrity without hesitation \\
D9 Testability \& deployability & \textbf{H} & reconciliation and audit-trail reconstruction must be verifiable by construction (S2, S3) \\
D10 Operating cost & L & run cost is traded for integrity as willingly as D8 \\
D11 Team scaling & M & binding only at neobank organisational scale -- the Monzo condition \\
D12 AI integrability & M & fraud and sanctions scoring dock at the edge; the booking path stays deterministic \\
\midrule
Workload shape $S(a)$ & \multicolumn{2}{l}{interactive (+ batch edges)} \\
Hard constraints $K(a)$ & \multicolumn{2}{p{9.0cm}}{BCBS 239; FINMA 2023/1; DORA (EU 2022/2554); ACID booking core; 10+ yr retention} \\
\bottomrule
\end{tabular}
\end{table}

\subsection{What real systems chose -- and why}

Two documented production systems demonstrate that this profile does \emph{not} determine a single pattern. \textbf{LMAX}, a retail-trading platform, processes six million orders per second on a \emph{single} JVM thread: an in-memory, event-sourced, deterministic sequential core surrounded by lock-free ring buffers \citep{fowler2011lmax}. In dimension terms: a single-threaded sequential core is serialisable \emph{by construction} -- the strongest possible answer to the D4 veto -- and deterministic replay of the event journal answers D6 and D9 at once; what it surrenders is elastic write scaling (D2), which the class weights only Medium. \textbf{Monzo}, a UK digital bank, operates roughly 2{,}800 Go microservices (about 1{,}600 in 2020) -- viable only through extreme technological homogeneity: one language, one monorepo, central migration automation \citep{sewell2024monzo, register2020monzo}. Monzo's binding dimension was D11 (team scaling), the one dimension on which the microservices column excels (Table~\ref{tab:cap-ms}); the price -- the $--$ on simplicity and cost that the same column carries -- was paid deliberately, and the D4 risk of sagas in the money path was mitigated by homogeneity and central tooling. Both satisfy banking-grade requirements with opposite structures: LMAX optimises the deterministic core, Monzo optimises organisational scaling -- Assumption A2's trade-off, resolved twice, in opposite directions, within one feasible set.

The open-source reference is \textbf{Apache Fineract}, the core-banking platform from the Mifos initiative and an Apache top-level project: a Java/Spring backend, API-first and multi-tenant, with relational persistence; through the Mifos/Fineract APIs it serves several hundred institutions with tens of millions of end customers \citep{fineract2024core}. Architecturally it is a modular monolith behind a REST facade -- and the modular-monolith column of Part~\ref{part:patterns} (Table~\ref{tab:cap-mm}) explains why that works: one ACID quantum serves the D4 veto, domain modules absorb the peripheral change rate that D7 demands, and the pattern's weak cell -- $-$ on D5, one process as blast radius -- is mitigated by the classical banking tactic of hot-standby replication. Fineract is a standing counter-example to the assumption that banking at scale implies microservices.

\begin{examplebox}[LMAX versus Monzo: one profile -- two structures]
LMAX and Monzo occupy the same requirements profile -- strict ordering and integrity of financial transactions, regulator-grade auditability -- yet chose structures at opposite ends of the distribution spectrum. The resolution is in the formal model: $R(a)$ constrains the \emph{feasible set}; within it, the hard constraints $K(a)$ and the organisational context (team size, skills, latency regime) select the point. LMAX's binding scenario was microsecond-scale deterministic ordering, which rewards a single-threaded event-sourced core \citep{fowler2011lmax}; Monzo's binding constraint was scaling hundreds of engineers safely, which rewards independent deployability bought with enforced homogeneity \citep{sewell2024monzo}.
\end{examplebox}

\begin{keypoint}
$R(a)$ alone does not force one pattern; it defines the feasible set, and constraints decide within it. C1's veto dimensions -- consistency (D4), availability (D5), security and auditability (D6), evolvability (D7), testability (D9) -- eliminate structures that cannot carry an ACID, journaled, decades-lived core; they do not rank the survivors. That is why the LMAX/Monzo pair is evidence \emph{for} the theory, not against it.
\end{keypoint}

\begin{ailinse}[Fraud scoring at the edge of the ledger (Axis B)]
AI enters C1 at the periphery, never in the booking path: fraud and sanctions scoring are ML classification components (millisecond-latency, deterministic after training) consulted \emph{before} a posting is committed, and increasingly LLM-based components for case triage and customer communication. The class's D12 weight is Medium precisely because of this placement: the deterministic core must be isolatable from the probabilistic edge, which is a ports-and-adapters discipline (Part~\ref{part:ai}). A fraud model that could abort or mutate a posting mid-transaction would violate the class's D4 veto -- the architectural rule \emph{agents propose, deterministic services decide and book} originates in this class.
\end{ailinse}

Where the weak dimensions of the winning structures bite, documented practice mitigates by \emph{placing} patterns rather than replacing them: the immutable event journal -- EDA's natural artefact -- serves as the regulatory audit trail at the core's edges, and end-of-day clearing, statements, and risk runs are genuine pipes-and-filters batch runs beside the interactive core. In one sentence: the primary recommendation for C1 is a hexagonal modular monolith for the booking core (MM and HX at $++$), with 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; Part~\ref{part:fit} computes this verdict through the three-stage procedure.

% ============================================
% SECTION: C2 SOCIAL MEDIA / CONTENT PLATFORMS
% ============================================
\section{C2 -- Social Media / Content Platforms}
\label{sec:c2}

\emph{Three hundred thousand people refresh their feed every second while six thousand post: what structure serves the ratio?} The class comprises consumer platforms whose product is a continuously updated content feed: social networks, media-sharing platforms, content communities -- the apps that fill the tram ride. Its defining property is the exact inversion of C1: a feed that is a few seconds \emph{stale} is acceptable; a feed that does not \emph{load} is not. Consistency is explicitly negotiable -- eventual consistency is a design choice, not a defect \citep{vogels2009eventually} -- while read scalability, availability, and feed latency carry the binding scenarios.

\subsection{The challenges it brings}

The numbers in the leading question are Twitter's documented 2013 figures, still the canonical calibration: roughly 300{,}000 timeline reads per second against roughly 6{,}000 tweet writes per second -- a ratio of about 50:1 \citep{krikorian2013timelines, hoff2013twitter}. A read path that carries the product at that ratio is a demand on D1 (read scalability) before anything else. The raw write rate is modest; what is not modest is the \emph{fan-out amplification}: one write by an account with millions of followers implies millions of logical deliveries. The naive materialisation (``\texttt{SELECT} over all follows at read time'') was tried and abandoned; the documented solution is fan-out-on-write into in-memory timeline caches (bounded to some 800 entries per home timeline), hybridised with fan-out-on-read for extreme-follower accounts \citep{krikorian2013timelines}. This is the textbook case of the architectural decision \emph{write work versus read work as a function of the read/write ratio} \citep{kleppmann2017designing} -- and the reason D2 stays Medium (Table~\ref{tab:requirements}, footnote~1): the amplification is absorbed by a dedicated fan-out subsystem, not by the write path proper.

The second challenge is the pace of the product. The feature change rate is among the highest in industry: permanent A/B experiments and daily deployments are the norm -- Instagram exemplifies the signature with roughly 100 deployments per day on a Django codebase of several million lines \citep{woodruff2019static}. That pace is a joint demand on D7 (evolvability), D9 (testability and deployability), and -- once the organisation grows into hundreds of feature teams -- D11 (team scaling). The third challenge is the load pattern: spiky and viral (breaking news, events), with traffic multiplying within minutes, which stresses D5 (availability and fault isolation) and keeps D3 (latency) binding at global peak. Data volume is very large and predominantly unstructured (text, images, video); the platform is long-lived while individual features are short-lived.

The binding scenarios, with response measures:

\begin{itemize}
    \item \textbf{S1 (feed latency).} A user opens the home feed (stimulus) at global peak (environment); the feed renders (response) with \textbf{p99 server-side latency below 200\,ms} (response measure) -- the regime that read-path architectures such as precomputed timelines and edge caches exist to meet \citep{krikorian2013timelines}. A demand on D1 and D3.
    \item \textbf{S2 (fan-out delivery).} A user posts (stimulus) in normal operation (environment); the post becomes visible to followers (response) \textbf{within 5 seconds for the vast majority of accounts} (response measure) -- Twitter's stated delivery target, missed by design for extreme-follower accounts and compensated by a hybrid fan-out \citep{krikorian2013timelines, hoff2013twitter}. A demand on D2's amplification reading -- and a licence on D4: seconds of staleness are within contract.
    \item \textbf{S3 (availability under viral spikes).} An external event multiplies traffic within minutes (stimulus); the platform continues serving feeds (response) with \textbf{SLO attainment maintained and blast radius of any single component failure below a declared bound} (response measure). The D5 scenario.
\end{itemize}

The regulatory frame is comparatively light but not empty: the EU Digital Services Act imposes content-moderation, transparency, and systemic-risk duties on platforms, and the GDPR governs profiling and personal data \citep{eu2016dsgvo}. Neither forces a consistency model, which is precisely why this class can trade consistency away -- the mirror image of C1, where regulation forbids exactly that trade. $K(\text{C2})$ therefore knocks out little; the discrimination work in this class is done by the weights, not the constraints.

\subsection{The requirements profile}

With the challenges in mind -- the 50:1 ratio, the fan-out amplification, the deployment pace, the viral spikes -- the weights follow; each H is a veto trigger in Part~\ref{part:fit}'s matching. Table~\ref{tab:req-c2} is the C2 column of the consolidated table.

\begin{table}[htbp]
\centering
\footnotesize
\caption{Requirements profile of C2 (social media / content platform) -- column C2 of Table~\ref{tab:requirements}, cell-identical; note numbers refer to that table's footnotes.}
\label{tab:req-c2}
\begin{tabular}{@{}p{3.4cm}cp{8.3cm}@{}}
\toprule
\textbf{Dimension} & \textbf{Weight} & \textbf{Why} \\
\midrule
D1 Read scalability & \textbf{H} & a ca.~50:1 read/write ratio -- the read path carries the product \\
D2 Write scalability \& elasticity & M & raw write rate is modest (ca.~6\,k/s); fan-out amplification is absorbed by the fan-out subsystem (note~1) \\
D3 Latency & \textbf{H} & the feed must render at p99 below 200\,ms at global peak or the product feels broken \\
D4 Consistency \& integrity & L & a feed seconds stale is invisible; eventual consistency is a design choice \\
D5 Availability \& fault isolation & \textbf{H} & an unavailable feed is the defect; viral spikes arrive within minutes \\
D6 Security \& auditability & M & moderation and profiling duties (DSA, GDPR) matter but do not shape the core topology \\
D7 Evolvability & \textbf{H} & permanent A/B experimentation; features live weeks while the platform lives decades \\
D8 Simplicity \& TTM & M & simplicity is welcome but is outbid by feature velocity at scale \\
D9 Testability \& deployability & \textbf{H} & ca.~100 deployments per day are impossible without cheap, safe releases \\
D10 Operating cost & M & fleet cost matters but never vetoes the read path \\
D11 Team scaling & \textbf{H} & hundreds of feature teams must deploy independently -- the documented growth bottleneck \\
D12 AI integrability & M & ranking and moderation are ML components, placed off the p99 path \\
\midrule
Workload shape $S(a)$ & \multicolumn{2}{l}{interactive read-heavy} \\
Hard constraints $K(a)$ & \multicolumn{2}{p{9.0cm}}{DSA; GDPR} \\
\bottomrule
\end{tabular}
\end{table}

\subsection{What real systems chose -- and why}

\textbf{Instagram} is the documented monolith-at-scale case: to this day a Django monolith at its core -- several million lines of Python, thousands of endpoints, roughly 100 deployments per day -- scaled horizontally across tens of thousands of identical servers over sharded PostgreSQL and Cassandra \citep{woodruff2019static}. In dimension terms, Instagram exploited exactly the cell that the layered and modular-monolith columns share (Tables~\ref{tab:cap-l} and~\ref{tab:cap-mm}, note~1 of Table~\ref{tab:capability}): stateless replication of the application tier scales \emph{reads} far, so the class's D1 High is servable from a monolith -- a monolith is a potential \emph{organisational} problem, not a read-scaling problem. The trade-off (Assumption A2) bites on D11: one release train throttles hundreds of teams, which is why \textbf{Twitter/X} historically migrated from a Rails monolith to JVM services as organisation and load grew, and why its fan-out architecture is an \emph{event flow} at heart -- fan-out-on-write is publish/subscribe, the EDA column's home turf (Table~\ref{tab:cap-eda}: $++$ on D1, D2, and D7's attach-new-consumers reading) \citep{krikorian2013timelines}. The microservices column (Table~\ref{tab:cap-ms}) serves the same three High weights -- independent scaling of feed, media, and graph services matches D1, independent team deployments match D9 and D11 -- at the documented price of its $--$ on D8 and D10, accepted at this scale.

The open-source reference is \textbf{Mastodon}: a Ruby-on-Rails monolith with Sidekiq job queues, PostgreSQL (single writer, read replicas), Redis as feed cache and queue backend, and a Node.js streaming API, federated via ActivityPub \citep{mastodon2024docs, warski2022mastodon}. It is didactically ideal because the entire fan-out mechanic -- one Sidekiq job per follower feed -- is inspectable in source code, and the scaling limits of the Rails monolith are documented rather than hidden: Mastodon \emph{is} the secondary recommendation running in public.

\begin{keypoint}
C1 and C2 are mirror images, and the mirror axis is the consistency/availability trade. C1: a stale balance is a defect, an unavailable channel is an inconvenience. C2: a stale feed is an inconvenience, an unavailable feed is the defect. Same twelve dimensions, inverted weights on D1 and D4 -- this contrast pair is the fastest way to internalise that weights, not dimensions, define a class.
\end{keypoint}

\begin{ailinse}[Feed ranking and moderation as runtime AI (Axis B)]
In C2, AI is not an add-on but the product's economic engine: feed ranking, recommendation, and content moderation are ML components in the serving path. Architecturally they inherit the class's own discipline -- ranking models are trained in offline pipelines (a C6/C7-shaped subsystem) and served from precomputed feature stores at millisecond latency, so that the p99 feed budget of scenario S1 survives; moderation classifiers sit on the asynchronous ingestion path, where seconds of latency are invisible. The class thereby illustrates a general Axis-B rule developed in Part~\ref{part:ai}: the latency class of the AI component, not its accuracy, decides \emph{where} in the topology it may live.
\end{ailinse}

In one sentence: the primary recommendation for C2 is an EDA + microservices hybrid at organisational scale (MS and EDA at $++$), with a modular monolith as secondary until that scale is \emph{measured}, not assumed -- deployments per developer per day as teams multiply is the deciding measurement; Part~\ref{part:fit} computes this verdict through the three-stage procedure.

% ============================================
% SECTION: C3 BACK-OFFICE / WORKFLOW APPLICATIONS
% ============================================
\section{C3 -- Back-Office / Workflow Applications}
\label{sec:c3}

\emph{The organisation reorganises again, and by next sprint the approval workflow must follow: which structure absorbs its fortieth process change as cheaply as its first?} The class comprises internal administration systems: case management, approval workflows, HR and procurement processes, departmental record-keeping -- the vacation request, the invoice approval, the onboarding checklist. It is the modal, unglamorous case of industrial software -- systematically under-represented in engineering blogs precisely because nothing about it is spectacular, which is itself the didactic point. Users are employees, numbering dozens to thousands; hours of downtime are usually tolerable; load is low and planable.

\subsection{The challenges it brings}

The dominant challenge is not technical at all: it is that the \emph{organisation} keeps changing under the software. The economics are dominated by evolution: maintenance and enhancement consume roughly 40--80\,\% (typically about 60\,\%) of life-cycle cost, mostly for adapting to reorganisations and process changes rather than for repair \citep{glass2002facts, sommerville2020modernes} -- the single strongest demand in this class, and it lands on D7 (evolvability). Lifetimes run 10--20 years and routinely exceed the plan, so the fortieth process change of the leading question is not rhetorical.

The second challenge is the budget. These systems are built by small internal teams against internal cost centres; every franc spent on platform machinery is a franc unavailable for the next reorganisation. That is a standing demand on D8 (simplicity and time-to-market) and D10 (operating cost) -- and, as the example box below prices out, a standing veto against premium structures. The workload itself generates almost no pressure: CRUD-dominated and moderately read-heavy (an 80/20 rule of thumb), office-hours load, small-to-medium structured data volumes (gigabytes to a few terabytes, often with document attachments) -- D1, D2, and D5 simply do not bind. A single relational ACID database is almost always sufficient; integration demand, however, is high (identity/LDAP, ERP, document management, e-mail).

The third challenge is correctness with witnesses. Internal control systems demand enforced dual control and a complete audit trail per case -- demands on D4 (transactional case state) and D6 (auditability). The binding scenarios:

\begin{itemize}
    \item \textbf{S1 (process change dispersion).} The organisation changes an approval process (stimulus) during normal evolution (environment); the change is implemented and released (response) \textbf{touching no more than the process definition and one module, within one sprint} (response measure) -- change dispersion is the operative evolvability metric here (Table~\ref{tab:dimensions}). The D7 scenario.
    \item \textbf{S2 (four-eyes integrity).} A clerk approves a case that requires dual control (stimulus); the system enforces the second approval and journals both (response) with \textbf{zero bypasses and a complete, sequential audit trail per case} (response measure) -- the internal-control-system obligation read as a scenario. A demand on D4 and D6.
    \item \textbf{S3 (interactive adequacy).} A caseworker submits a form (stimulus) during office hours (environment); the system responds (response) \textbf{within 1--2 seconds} (response measure) -- internal users tolerate more latency than customers, but not unboundedly more. D3, weighted Medium.
\end{itemize}

$K(\text{C3})$ reads as knock-outs: the GDPR for employee data \citep{eu2016dsgvo}; statutory retention duties (in Switzerland, Art.~958\emph{f} of the Code of Obligations requires business records to be retained for ten years); internal control systems with enforced dual control; for public administration additionally administrative law and accessibility requirements. A structure that cannot produce a sequential, tamper-evident audit trail per case, or that cannot guarantee retention, is excluded -- constraints that favour simple, journaled, transactional designs.

\subsection{The requirements profile}

With the challenges in mind -- evolution dominating cost, budgets that punish premium structures, audit obligations -- the weights follow, each H a veto trigger per Part~\ref{part:foundations}. Table~\ref{tab:req-c3} is the C3 column of the consolidated table.

\begin{table}[htbp]
\centering
\footnotesize
\caption{Requirements profile of C3 (back-office / workflow) -- column C3 of Table~\ref{tab:requirements}, cell-identical.}
\label{tab:req-c3}
\begin{tabular}{@{}p{3.4cm}cp{8.3cm}@{}}
\toprule
\textbf{Dimension} & \textbf{Weight} & \textbf{Why} \\
\midrule
D1 Read scalability & L & dozens to thousands of internal users at office-hours load \\
D2 Write scalability \& elasticity & L & two requests per second at the July vacation peak -- nothing to elasticise \\
D3 Latency & M & 1--2\,s form turnaround suffices for employees, but not unboundedly more (S3) \\
D4 Consistency \& integrity & \textbf{H} & case state and approvals must be transactionally correct; one skipped approval is an ICS finding \\
D5 Availability \& fault isolation & L & hours of downtime are tolerable; the work waits \\
D6 Security \& auditability & \textbf{H} & four-eyes enforcement and a sequential, tamper-evident audit trail per case (S2) \\
D7 Evolvability & \textbf{H} & ca.~60\,\% of life-cycle cost is evolution, driven by reorganisations (S1) \\
D8 Simplicity \& TTM & \textbf{H} & small teams, internal budgets: the simplest adequate structure wins \\
D9 Testability \& deployability & M & releases are weekly, not hourly; regression scope stays modest \\
D10 Operating cost & \textbf{H} & the budget belongs to the next reorganisation, not to platform staff \\
D11 Team scaling & L & one team, often part-time \\
D12 AI integrability & L & document extraction decorates the intake edge; the case core stays untouched \\
\midrule
Workload shape $S(a)$ & \multicolumn{2}{l}{interactive} \\
Hard constraints $K(a)$ & \multicolumn{2}{p{9.0cm}}{Retention law (e.g.\ OR 958\emph{f}); internal control systems; GDPR} \\
\bottomrule
\end{tabular}
\end{table}

\subsection{What real systems chose -- and why}

The modal industrial answer is a three-tier or modular-monolith application over one relational database -- and the capability tables of Part~\ref{part:patterns} explain why in two steps. The layered column (Table~\ref{tab:cap-l}) serves D8 and D10 at $++$ -- one artefact, one pipeline, near-zero platform staff -- and its ACID cell serves the D4 veto; its weakness is exactly where this class hurts most, the $-$ on D7, which is why layering fits only small, stable scope. The modular-monolith column (Table~\ref{tab:cap-mm}) buys the same run cost with domain boundaries that absorb the reorganisation-driven change rate -- D7 rises to $+$ while D4 and D10 keep their ratings, at the price of one step on D8 (boundary governance is a permanent line item) -- the Pareto choice when process change is frequent \citep{glass2002facts}.

The documented reference for the class's other big lever -- externalising the thing that changes most -- is \textbf{Camunda}, whose own product evolution is a miniature architecture lecture: Camunda~7 embeds the process engine as a Java library with relational persistence -- classical and monolith-friendly -- while Camunda~8 rebuilt the engine (Zeebe) as a partitioned, replicated, horizontally scalable distributed system; the migration between the two documents precisely what distribution buys and what it costs \citep{camunda2024zeebe}. Process models follow BPMN~2.0; when a reorganisation arrives, the process definition changes, not the codebase -- scenario S1 met by design. Open-source references for the forms-over-data core include \textbf{Flowable} and the \textbf{Frappe} framework underlying ERPNext, whose metadata-driven DocTypes generate schema, forms, and REST APIs from declarative definitions \citep{frappe2024erpnext}.

\begin{examplebox}[Why this class punishes distribution]
Consider a vacation-approval workflow serving 800 employees, peaking at perhaps two requests per second on the first workday of July. Every quality attribute that microservices buy -- independent scaling, independent deployment by many teams, fault isolation across quanta -- is priced in platform staffing and operational complexity that this workload cannot amortise \citep{fowler2015premium}. The Segment case (Part~\ref{part:foundations}) showed a small team crushed by exactly this premium \citep{noonan2018goodbye}. C3 is the clearest instance of the rule that D8 = H and D10 = H jointly veto premium-priced structures: the class needs its budget for the next reorganisation, not for a service mesh.
\end{examplebox}

\begin{keypoint}
C3 is the industry's modal case, and its profile rewards the simplest structure that meets the audit constraints: evolution dominates the cost function \citep{glass2002facts}, so D7 = H; nobody pays for scale that office-hours load never generates, so D8 = H and D10 = H jointly veto every premium-priced structure. Unglamorous is not a defect of this class -- it is its optimum.
\end{keypoint}

\begin{ailinse}[Document extraction and workflow triage (Axis B)]
The AI foothold in C3 is unstructured input: incoming invoices, applications, and correspondence are increasingly parsed by LLM-based extraction components that propose structured case data. The class's constraints shape the integration: extraction runs asynchronously before the workflow starts (latency-tolerant), its output is validated against the domain schema before any case is created (the ontology-guard tactic of Part~\ref{part:ai}), and the four-eyes obligation of scenario~S2 extends to AI proposals -- a human confirms, the system journals both the proposal and the confirmation. D12 = L in the profile because none of this touches the class's core; it decorates the intake edge.
\end{ailinse}

In one sentence: the primary recommendation for C3 is a modular monolith with externalised process logic -- a Camunda-class workflow engine behind a port -- (MM at $++$), with layered 3-tier as secondary for small, stable scope (L at $+$); Part~\ref{part:fit} computes this verdict through the three-stage procedure.

% ============================================
% SECTION: C4 ERP / ENTERPRISE CORE SYSTEMS
% ============================================
\section{C4 -- ERP / Enterprise Core Systems}
\label{sec:c4}

\emph{A sales order must update stock and ledger in the same breath -- for thirty years: what does ``integrated'' actually demand?} The class comprises integrated enterprise systems: order management, inventory, finance, HR, and production planning sharing \emph{one} data model. Its defining property is that the product's value \emph{is} the integration: an order posting updates stock and ledger in one transaction, and every module sees every other module's data consistently. This property -- cross-module ACID transactions over a shared schema -- is exactly what distribution makes structurally expensive.

\subsection{The challenges it brings}

The first challenge is the one in the leading question: cross-module atomicity. An order confirmation must commit order, stock reservation, and ledger posting together, with zero half-completed postings, ever -- the hardest possible demand on D4 (consistency and integrity), and one that couples directly to D6 (auditability), because financial-reporting law demands an unbroken, tamper-evident chain from source document to ledger entry. Eventual consistency \emph{between ledger and inventory} is not merely inconvenient -- it contradicts the audit obligation itself.

The second challenge is time, in its most extreme form in the catalogue. SAP R/3 appeared in 1992, and SAP had to extend mainstream maintenance for the ECC generation to end-2027 (optionally 2030) because customers could not complete their migrations \citep{sap2020maintenance}; ERP life cycles of 20--30 years are the normal case, and replacement projects run for years. Under that horizon, \emph{customising pressure is permanent} -- every enterprise adapts the system to itself -- so the central architectural requirement is a disciplined extension mechanism (modules and add-ons rather than core modification): a demand on D7 (evolvability) whose operative sub-requirement is that extensions survive releases. The change-rate signature is the inverse of the load signature: core processes are stable, customisations churn.

The third challenge is rhythm rather than volume. The workload is mixed: an OLTP core with deterministic batch peaks (month-end and year-end close, MRP runs, payroll); interactive latency of 1--2\,s suffices (D3 Medium), the batch window is a hard boundary, and load is almost never the problem -- D1 and D2 stay Low, and planned maintenance windows are an accepted norm, which caps D5 at Medium. Data volumes are medium to large, highly structured, with very long retention. The binding scenarios:

\begin{itemize}
    \item \textbf{S1 (cross-module posting).} A sales order is confirmed (stimulus) in normal operation (environment); order, stock reservation, and ledger posting commit atomically (response) with \textbf{zero half-completed postings, ever} (response measure). The D4 veto scenario.
    \item \textbf{S2 (period-end close).} Month-end closing starts (stimulus) at the period boundary (environment); MRP, depreciation, and reporting runs complete (response) \textbf{within the overnight batch window, with a reconciled trial balance at 06:00} (response measure). A demand on the batch edge of the workload shape -- and on D6's reconciliation reading.
    \item \textbf{S3 (customising survival).} A new release of the core is installed (stimulus) in a system carrying years of customer-specific extensions (environment); the extensions continue to function (response) with \textbf{zero core modifications required and all extension contracts verified before rollout} (response measure) -- the survival condition of 20--30-year life cycles, and the D7 scenario.
\end{itemize}

$K(\text{C4})$: financial-reporting law (Swiss CO, HGB, IFRS), audit-proof archiving duties (GoBD in Germany, GeB{\"u}V in Switzerland), the GDPR for the HR module \citep{eu2016dsgvo}, and SOX control requirements for US-listed groups. Auditability of posting chains is an obligation, not an option: a candidate structure that cannot demonstrate an unbroken, tamper-evident chain from source document to ledger entry is knocked out before scoring.

\subsection{The requirements profile}

With the challenges in mind -- cross-module atomicity, audit chains, decades under customising pressure -- the weights follow; every H is a veto trigger (Part~\ref{part:foundations}). Table~\ref{tab:req-c4} is the C4 column of the consolidated table.

\begin{table}[htbp]
\centering
\footnotesize
\caption{Requirements profile of C4 (ERP / enterprise core system) -- column C4 of Table~\ref{tab:requirements}, cell-identical.}
\label{tab:req-c4}
\begin{tabular}{@{}p{3.4cm}cp{8.3cm}@{}}
\toprule
\textbf{Dimension} & \textbf{Weight} & \textbf{Why} \\
\midrule
D1 Read scalability & L & hundreds to thousands of internal users; load rarely binds \\
D2 Write scalability \& elasticity & L & batch peaks are deterministic and planned into the window \\
D3 Latency & M & 1--2\,s interactive turnaround suffices; the batch window is the hard boundary \\
D4 Consistency \& integrity & \textbf{H} & cross-module ACID postings (order $\to$ stock $\to$ ledger) \emph{are} the product (S1) \\
D5 Availability \& fault isolation & M & planned maintenance windows are an accepted ERP norm \\
D6 Security \& auditability & \textbf{H} & unbroken, tamper-evident chains from source document to ledger entry (GoBD/GeB{\"u}V, SOX) \\
D7 Evolvability & \textbf{H} & 20--30-year lifetimes under permanent customising pressure; the extension mechanism is the survival condition (S3) \\
D8 Simplicity \& TTM & M & nobody expects an ERP overnight, but complexity still costs \\
D9 Testability \& deployability & M & release trains with extension contracts verified before rollout \\
D10 Operating cost & M & material, but never the deciding dimension \\
D11 Team scaling & M & several module teams coordinate inside one release \\
D12 AI integrability & L & AI assists at the edges; the posting core is untouched \\
\midrule
Workload shape $S(a)$ & \multicolumn{2}{l}{interactive (+ batch runs)} \\
Hard constraints $K(a)$ & \multicolumn{2}{p{9.0cm}}{GoBD/GeB{\"u}V; SOX; IFRS audit chains} \\
\bottomrule
\end{tabular}
\end{table}

\subsection{What real systems chose -- and why}

The open-source references are living proof of the pattern--class alignment. \textbf{Odoo} is a modular Python monolith over PostgreSQL: every business domain (sales, purchasing, accounting, manufacturing) is a module over one shared ORM data model, and modules extend models, views, and logic by inheritance \citep{odoo2024docs}. \textbf{ERPNext}, built on the Frappe framework (Python, MariaDB), is metadata-driven: DocTypes generate schema, forms, and REST APIs \citep{frappe2024erpnext}. Both exhibit strict module boundaries, one deployment, one database, shared transactions -- the modular monolith in its purest industrial form \citep{richards2025fundamentals, su2024modular}. Read against the capability tables: the modular-monolith column (Table~\ref{tab:cap-mm}) answers the D4 veto with one ACID quantum, answers D7 with domain modules and a disciplined extension mechanism -- exactly scenario S3 -- and its $-$ on D5 is absorbed because the class itself weights D5 only Medium (maintenance windows are the accepted norm): a rare case where a pattern's weak cell meets a class that does not care.

The trade-off analysis (Assumption A2) is starkest in this class in the opposite direction: decomposing an ERP into independently deployable services turns cross-module atomicity into distributed sagas -- microservices' $--$ on D4 (Table~\ref{tab:cap-ms}) meets the class's hardest High, the structurally strongest anti-fit in the whole grid. The occasional community attempts to cut such systems into microservices have remained marginal; the near-absence of viable microservice ERPs after a decade of microservices enthusiasm is itself empirical evidence that integration wins in this class. The mitigation for the survivors runs through the edges: hexagonal ports at the integration peripheries (EDI, banking, tax services) keep customising out of the core, and period-end closing, MRP, and payroll are canonical pipes-and-filters runs inside the batch window.

\begin{keypoint}
C4 sharpens the difference between C3 and itself: both are ACID, interactive, evolution-dominated classes, but C4's value proposition is \emph{integration across modules}, which binds the class to a single transactional quantum. Where C3 could plausibly be several small systems, C4 by definition cannot -- decomposing it into independently deployable services converts its core feature (cross-module atomic postings) into its hardest problem (distributed sagas) \citep{richardson2018microservices}.
\end{keypoint}

\begin{thinkbox}
SAP's maintenance extension to 2027/2030 \citep{sap2020maintenance} means thousands of enterprises run an ERP generation older than most of this course's students. Is that an architecture failure, an architecture success, or both? Formulate your answer as a statement about D7 (evolvability): what precisely ossified -- the pattern, the customisations, or the organisation's ability to re-derive its own requirements profile?
\end{thinkbox}

In one sentence: the primary recommendation for C4 is a modular monolith (MM at $++$) -- the strongest pattern--class alignment in the matrix -- with hexagonal discipline within it for the extension ecosystem as secondary; Part~\ref{part:fit} computes this verdict through the three-stage procedure.

% ============================================
% SECTION: C5 E-COMMERCE PLATFORMS
% ============================================
\section{C5 -- E-Commerce Platforms}
\label{sec:c5}

\emph{A hundred milliseconds of delay costs one per cent of sales, and Black Friday brings fifty times the load: what survives both at once?} The class comprises online retail platforms: catalogue, search, cart, checkout, payment, fulfilment. Its defining property is that downtime and slowness convert \emph{directly} into revenue loss -- and, equally defining, that C5 is the only class in the catalogue whose consistency profile is \emph{hybrid by definition}: the catalogue and recommendations may be stale, inventory is negotiable (oversell compensation), but checkout and payment are strictly ACID.

\subsection{The challenges it brings}

The first challenge carries a price tag, which is rare enough to be the class's signature. Two classical calibrations quantify it: Amazon's internal experiment attributing roughly $-1\,\%$ of sales to $+100$\,ms of latency \citep{linden2006data}, and Akamai's 2017 retail study measuring up to $-7\,\%$ conversion per 100\,ms of delay \citep{akamai2017retail}. Latency and availability are revenue variables here -- direct demands on D3 (latency) and D5 (availability), with documented conversion rates as the response measures. The read side is equally commercial: browse-to-buy ratios often exceed 100:1, so the catalogue is a read product -- a demand on D1.

The second challenge is the most extreme seasonality of all classes: Black Friday/Cyber Monday produces load factors of 10--50$\times$ over normal operation; Shopify reported peaks of roughly 280 million requests per minute and terabytes of traffic per minute for BFCM~2024 \citep{shopify2024bfcm}. Peaks of that shape must be absorbed, not survived -- the D2 (write scalability and elasticity) demand, rehearsed in advance: peak readiness is load-tested at 10$\times$ baseline before the season, which is simultaneously a demand on D9 (testability). The third challenge is the split personality of the data: the checkout must never lie, the catalogue may -- the hybrid consistency that Table~\ref{tab:requirements} encodes as D4 Medium with footnote~6. Data are heterogeneous (semi-structured catalogue, structured orders, media blobs); the business change rate is high (promotions, checkout experiments -- D7), and the integration surface is very wide -- payment service providers, logistics, tax, search, recommendations. The platform lives 10+ years; frontends are short-lived. The binding scenarios:

\begin{itemize}
    \item \textbf{S1 (peak elasticity).} Black-Friday traffic arrives at 10--50$\times$ the normal load (stimulus) at the seasonal peak (environment); browsing and checkout continue (response) with \textbf{p95 checkout latency within budget and zero uncompensated oversells at 10$\times$ baseline in the pre-peak load test} (response measure) \citep{shopify2024bfcm}. A joint demand on D2, D5, and D9.
    \item \textbf{S2 (page latency).} A customer opens a product page (stimulus) in normal operation (environment); the page renders (response) in \textbf{under 1--2\,s, with API calls under 100--300\,ms} (response measure) -- the budgets behind the revenue calibrations above \citep{linden2006data, akamai2017retail}. The D1/D3 scenario.
    \item \textbf{S3 (payment-scope containment).} A security assessor audits the cardholder-data environment (stimulus); the audit scope (response) is demonstrably \textbf{confined to the tokenised payment subsystem, with third-party scripts on checkout pages inventoried and controlled} (response measure) -- PCI~DSS v4.0 read as a scenario \citep{pcissc2022pcidss}. The D6 scenario.
\end{itemize}

$K(\text{C5})$ turns the third scenario into a knock-out: PCI~DSS v4.0 governs cardholder data -- v3.2.1 was retired on 31~March 2024, and the future-dated requirements became mandatory on 31~March 2025, including MFA for all access to the cardholder-data environment and the control of third-party scripts on checkout pages \citep{pcissc2022pcidss}. The direct architectural implication is \emph{payment-scope minimisation} through tokenisation and outsourcing: the audit scope is a function of the structure, so the structure is chosen to shrink it -- regulation acting on D6 as a structural force. PSD2 governs payment initiation and strong customer authentication \citep{eu2015psd2}; the GDPR governs customer data \citep{eu2016dsgvo}.

\subsection{The requirements profile}

With the challenges in mind -- revenue-rated latency, 10--50$\times$ peaks, the designed consistency split, PCI scope -- the weights follow, and this class carries more Highs than any other; each one is a veto trigger (Part~\ref{part:foundations}). Table~\ref{tab:req-c5} is the C5 column of the consolidated table.

\begin{table}[htbp]
\centering
\footnotesize
\caption{Requirements profile of C5 (e-commerce platform) -- column C5 of Table~\ref{tab:requirements}, cell-identical; note numbers refer to that table's footnotes.}
\label{tab:req-c5}
\begin{tabular}{@{}p{3.4cm}cp{8.3cm}@{}}
\toprule
\textbf{Dimension} & \textbf{Weight} & \textbf{Why} \\
\midrule
D1 Read scalability & \textbf{H} & browse-to-buy ratios beyond 100:1 -- the catalogue is a read product (S2) \\
D2 Write scalability \& elasticity & \textbf{H} & 10--50$\times$ seasonal peaks (BFCM) must be absorbed, not survived (S1) \\
D3 Latency & \textbf{H} & $+100$\,ms $\approx -1\,\%$ sales: latency carries a documented price tag \\
D4 Consistency \& integrity & M & hybrid by definition: catalogue eventual, checkout/payment strictly ACID (note~6) \\
D5 Availability \& fault isolation & \textbf{H} & downtime converts to revenue loss at documented rates \\
D6 Security \& auditability & \textbf{H} & PCI~DSS v4.0 makes payment-scope minimisation an architecture requirement (S3) \\
D7 Evolvability & \textbf{H} & promotions, checkout experiments, and provider churn arrive weekly \\
D8 Simplicity \& TTM & M & speed to market matters, but not at the checkout's expense \\
D9 Testability \& deployability & \textbf{H} & peak readiness is rehearsed: load tests at 10$\times$ baseline gate the season (S1) \\
D10 Operating cost & M & fleet cost matters; the revenue stakes dominate it \\
D11 Team scaling & M & organisation-size dependent -- the Shopify-versus-Amazon contrast (note~17) \\
D12 AI integrability & M & recommendations and search ranking serve off precomputed stores \\
\midrule
Workload shape $S(a)$ & \multicolumn{2}{l}{interactive, seasonal} \\
Hard constraints $K(a)$ & \multicolumn{2}{p{9.0cm}}{PCI DSS v4.0 scope minimisation; PSD2/SCA} \\
\bottomrule
\end{tabular}
\end{table}

\subsection{What real systems chose -- and why}

\textbf{Shopify} is the canonical case study of the modular monolith at scale: a Ruby-on-Rails core -- one of the largest Rails codebases in existence, roughly 2.8 million lines restructured from 2017 onward into business components with enforced boundaries -- with the \textbf{Packwerk} tool enforcing dependency and visibility rules between components statically, and scaling achieved by \emph{pod sharding} (tenant-wise partitioning of whole application instances) rather than service decomposition \citep{westeinde2019deconstructing, shopify2020under}. In dimension terms: pod sharding lifts the modular monolith's weak D2 cell (Table~\ref{tab:cap-mm}) to carry 280-million-requests-per-minute peaks while the single transactional quantum preserves checkout ACID against the D4 boundary -- a documented mitigation of exactly the two cells where the pattern and the profile rub. Shopify's stated rationale is developer productivity plus transactional consistency.

The contrast case is \textbf{Amazon} itself, the founding pioneer of service orientation with two-pizza team ownership: the same application class, the opposite structure, driven by organisational scale -- microservices' $++$ on D11 (Table~\ref{tab:cap-ms}) becomes decisive only when team count makes D11 bind, which is precisely what footnote~17 of Table~\ref{tab:requirements} encodes; team size, not traffic, is the deciding variable (Assumption A2 resolved by an organisational constraint, as in C1). Open-source references document the current ``headless/composable'' trend as a \emph{layering} cut, not a microservice cut: \textbf{Saleor} (Python/Django, GraphQL-first API-centric monolith) and \textbf{Medusa} (Node.js, modular commerce modules behind a REST API) \citep{saleor2024github, medusa2024github}. The event-shaped edges -- order flows, inventory updates, search indexing, recommendation training -- are served by EDA and PF beside the core, and flash-sale spikes are the textbook serverless elasticity case, which is why those three columns all earn a $+$ in this row without ever owning the checkout.

\begin{examplebox}[Hybrid consistency as a designed boundary]
The C5 consistency split is not an accident to be tolerated but a boundary to be \emph{designed and documented}: catalogue reads may be minutes stale (cache-friendly, eventually consistent), inventory may oversell within a compensable bound, and the checkout/payment path is ACID with idempotent order creation \citep{kleppmann2017designing, linden2006data}. The measurable contract from the class's central trade-off: p95 checkout latency within budget and zero \emph{uncompensated} oversells during peak-load tests at 10$\times$ baseline. Where exactly the boundary runs -- is the cart eventual or transactional? -- is a genuine ATAM tradeoff point and belongs in an ADR, not in folklore.
\end{examplebox}

\begin{keypoint}
C5 is the class where quality attributes carry price tags: latency and availability convert to revenue at documented rates \citep{linden2006data, akamai2017retail}, seasonality defines elasticity (10--50$\times$ peaks \citep{shopify2024bfcm}), and the consistency profile is hybrid \emph{by definition} -- the one class where ``ACID or eventual?'' is answered ``both, along a designed boundary''. Team size, not traffic, decides between the Shopify and the Amazon structure.
\end{keypoint}

In one sentence: the primary recommendation for C5 is a modular monolith with the hybrid consistency profile designed inside it and event-driven edges (MM at $++$), with microservices as secondary at organisational scale and MS/EDA/SL earning their $+$ at the edges; Part~\ref{part:fit} computes this verdict through the three-stage procedure.

% ============================================
% SECTION: C6 SCIENTIFIC SIMULATION / BATCH COMPUTE
% ============================================
\section{C6 -- Scientific Simulation / Batch Compute}
\label{sec:c6}

\emph{The nightly risk run must reproduce, to the bit, on ten thousand cores by 06:00: what does that demand?} The class comprises compute-dominated batch systems: computational fluid dynamics, Monte-Carlo risk simulation, ML training runs, large-scale data transformation. Its cost function is CPU/GPU-hours; availability in the online sense is irrelevant -- an aborted job is restarted from a checkpoint, not mourned. And correctness has a specific meaning here: \emph{reproducibility}. A simulation whose result cannot be regenerated from versioned inputs, versioned code, and deterministic seeds is scientifically worthless and, for regulated risk models, unlawful to rely on \citep{glasserman2003monte, bcbs2013rdarr}.

\subsection{The challenges it brings}

The first challenge is that the interactive vocabulary simply does not apply. There is no read/write ratio; the pattern is read-input $\rightarrow$ compute $\rightarrow$ write-output over immutable datasets. Per-request latency is meaningless; the response measures are \emph{makespan} (hours to weeks) and \emph{batch-window adherence} -- the overnight risk run must publish before start of trading. Throughput therefore reappears in a new reading: as makespan and batch-window compute bursts, which is what D2 High means in this class (Table~\ref{tab:requirements}, footnote~2), while D3 (latency) drops to Low in its footnote-4 reading. Load is planned and queue-based with a utilisation target near 100\,\% -- the economic opposite of the elastic-headroom regimes of C2 and C5 -- and since the bill \emph{is} the compute, cost per simulation is a first-order concern: a direct demand on D10 (operating cost), which queue-based scheduling exists to serve \citep{yoo2003slurm}.

The second challenge is the reproducibility obligation from the leading question. Bit-identical reruns from versioned inputs, code, and seeds are a scientific duty and, for regulated risk models, a supervisory one -- the demand lands on D9 (testability) in its reproducibility reading (footnote~14) and on D4 (consistency) in the ``as of this run'' semantics that the definition below makes precise (footnote~8). The third challenge is physics: scaling has a measurable ceiling. In CFD practice with OpenFOAM, domain decomposition pays down to roughly 50{,}000--200{,}000 cells per core, below which communication overhead dominates -- a quantifiable instance of Amdahl's law as an architecture boundary \citep{openfoam2024guide, weller1998tensorial}. Monte-Carlo simulation, by contrast, is embarrassingly parallel -- the ideal pipeline case \citep{glasserman2003monte}. Data volumes are large (terabytes to petabytes of result data); the change rate is split -- model code changes research-driven, while numeric kernels are extremely long-lived (Fortran/C++ codes with 30+ years of history), which keeps D7 at Medium. The binding scenarios:

\begin{itemize}
    \item \textbf{S1 (batch-window adherence).} The overnight risk run starts (stimulus) after close of business (environment); the full portfolio revaluation completes (response) \textbf{within the batch window, results published before start of trading} (response measure). The D2 scenario in its makespan reading.
    \item \textbf{S2 (bit-level reproducibility).} A model validator re-executes a historical run (stimulus) months later (environment); the pipeline regenerates the results (response) \textbf{bit-identically from versioned inputs, code, and seeds} (response measure) \citep{glasserman2003monte}. The D9/D4 scenario.
    \item \textbf{S3 (cost efficiency).} The quarterly compute bill is reviewed (stimulus); cost per simulation and cluster utilisation (response) stay \textbf{within budget at a utilisation target near 100\,\%} (response measure) -- queue-based scheduling exists to meet exactly this measure \citep{yoo2003slurm}. The D10 scenario.
\end{itemize}

\begin{definitionbox}[The third consistency semantics: reproducibility and refresh contracts]
Beside ACID (``concurrent operations preserve invariants'') and eventual consistency (``replicas converge, staleness is bounded'' \citep{vogels2009eventually}), the batch world defines a third family of consistency semantics. \emph{Reproducibility} (C6): immutable inputs and idempotent, seeded stages guarantee that a rerun yields the identical result -- consistency ``as of this run''. \emph{Freshness by refresh contract} (C7): consumers see a complete, internally consistent state ``as of the last refresh'' (e.g.\ yesterday 24:00), never a half-updated one. Both are weaker than ACID and stronger than unqualified eventual consistency -- and both are \emph{contracts with response measures}, testable in CI like any other scenario.
\end{definitionbox}

$K(\text{C6})$ in financial applications: internal models are subject to model validation and backtesting under the Basel framework, and the traceability of model runs is audit-relevant -- the BCBS~239 lineage obligation extends into the simulation stack \citep{bcbs2013rdarr}. The knock-out reading: any structure that cannot pin \emph{data version + code version + seed} per run is excluded for regulated risk computation, whatever its throughput. Deterministic seeds are thus a hard constraint, not a nicety.

\subsection{The requirements profile}

With the challenges in mind -- makespan and window, reproducibility as law, compute as the bill, communication as the ceiling -- the weights follow; each H is a veto trigger (Part~\ref{part:foundations}). Table~\ref{tab:req-c6} is the C6 column of the consolidated table.

\begin{table}[htbp]
\centering
\footnotesize
\caption{Requirements profile of C6 (scientific simulation / batch compute) -- column C6 of Table~\ref{tab:requirements}, cell-identical; note numbers refer to that table's footnotes.}
\label{tab:req-c6}
\begin{tabular}{@{}p{3.4cm}cp{8.3cm}@{}}
\toprule
\textbf{Dimension} & \textbf{Weight} & \textbf{Why} \\
\midrule
D1 Read scalability & L & no interactive readers; outputs are files and tables \\
D2 Write scalability \& elasticity & \textbf{H} & throughput as makespan and batch-window compute bursts (S1; note~2) \\
D3 Latency & L & per-request latency is meaningless; the window is the measure (note~4) \\
D4 Consistency \& integrity & M & consistency ``as of this run'': bit-level reproducibility from versioned inputs and seeds (note~8) \\
D5 Availability \& fault isolation & L & an aborted job is restarted from a checkpoint, not mourned \\
D6 Security \& auditability & M & lineage of regulated model runs is audit-relevant, but there is no online attack surface \\
D7 Evolvability & M & model code churns research-driven; numeric kernels live 30+ years \\
D8 Simplicity \& TTM & M & orchestration should stay simple; the kernels never are \\
D9 Testability \& deployability & \textbf{H} & reproducibility is the operative meaning of testability (S2; note~14) \\
D10 Operating cost & \textbf{H} & the cost function \emph{is} CPU/GPU-hours at near-100\,\% utilisation (S3) \\
D11 Team scaling & L & small research and engineering teams \\
D12 AI integrability & M & training and simulation pipelines host ML natively, at batch cadence \\
\midrule
Workload shape $S(a)$ & \multicolumn{2}{l}{scheduled batch} \\
Hard constraints $K(a)$ & \multicolumn{2}{p{9.0cm}}{Model validation and backtesting (finance); deterministic seeds} \\
\bottomrule
\end{tabular}
\end{table}

\subsection{What real systems chose -- and why}

The dominant form is pipes-and-filters on HPC or batch infrastructure -- and the pipeline column of Part~\ref{part:patterns} (Table~\ref{tab:cap-pf}) reads like a transcript of this class's Highs: immutable inputs and deterministic, idempotent stages give reproducibility (D9) \emph{by construction}, batch scheduling drives utilisation towards the D10 target, and the shape matches the gate that eliminates every interactive pattern outright. \textbf{OpenFOAM} decomposes computational domains via graph partitioning, communicates over MPI, and is scheduled by \textbf{Slurm} as the batch resource manager \citep{openfoam2024guide, yoo2003slurm}; \textbf{OpenMC} is a modern, parallel Monte-Carlo transport code of the same architectural family \citep{romano2015openmc}; data-parallel engines (\textbf{Spark} \citep{zaharia2012resilient}) and DAG orchestrators (\textbf{Airflow} \citep{beauchemin2015airflow}) are the cloud-native incarnations, with Dask/Ray as Python-native alternatives.

Where the trade-off bites (Assumption A2) is data affinity: distributing a tightly coupled numeric dataflow across expensive boundaries multiplies communication cost. The Amazon Prime Video case from Part~\ref{part:foundations} is this class's cautionary tale in miniature: a tightly coupled processing flow distributed across orchestrator transitions and S3 round-trips per frame, until consolidation into one process cut cost by over 90\,\% \citep{kolny2023primevideo, cockcroft2023prime} -- when inter-stage communication dominates, consolidate, do not distribute. The same logic explains why serverless fan-out earns only a conditional role: embarrassingly parallel, communication-light bursts (Monte-Carlo) fit FaaS elasticity, data-heavy stages recreate the Prime Video cost trap.

\begin{keypoint}
C6 replaces the interactive vocabulary wholesale: the response measures are makespan, batch-window adherence, and cost per simulation; correctness means bit-level reproducibility from versioned inputs and seeds; consistency means ``as of this run''. A structure is a good fit for this class exactly to the degree that it makes these three measurable by construction -- which is why immutable-input pipelines dominate it \citep{glasserman2003monte, yoo2003slurm}.
\end{keypoint}

\begin{projektbox}
The course project inherits this class wholesale: the ingestion pipeline (chunking, embedding, indexing) and the \emph{eval pipeline} of the Portfolio Intelligence Platform are C6-shaped subsystems. The C6 discipline transfers literally -- versioned inputs, idempotent stages, deterministic reruns, golden datasets -- and footnote~14 of Table~\ref{tab:requirements} is the bridge: for batch pipelines, \emph{reproducibility is the operative meaning of testability}. When your eval scores change, you must be able to prove whether the model, the prompt, the data, or the pipeline changed. That proof is a C6 property.
\end{projektbox}

In one sentence: the primary recommendation for C6 is pipes-and-filters on HPC/batch infrastructure (PF at $++$), with serverless fan-out as secondary for bursty, communication-light parallel sections; Part~\ref{part:fit} computes this verdict through the three-stage procedure.

% ============================================
% SECTION: C7 DECISION SUPPORT / BI ANALYTICS
% ============================================
\section{C7 -- Decision Support / BI Analytics}
\label{sec:c7}

\emph{Monday, 08:00: the management dashboard must be complete as of yesterday 24:00 -- and every number must prove where it came from. What delivers that, night after night?} The class comprises data warehouses, BI platforms, and reporting systems. It is an \emph{integration product} over classes C1--C5: it owns almost no data of its own but integrates everyone else's, which makes data quality, lineage, and governance first-class concerns \citep{kimball2013warehouse}. Its consistency semantics are the refresh contract defined in Section~\ref{sec:c6}: ``consistent as of yesterday 24:00'' is a deliberate design choice, not a deficiency.

\subsection{The challenges it brings}

The first challenge is the shape of the reads. The load is almost pure read -- but of a specific kind: heavy OLAP scans by \emph{few} users, not point reads by many (Table~\ref{tab:requirements}, footnote~7). That is still a D1 (read scalability) demand, but in a reading of its own -- scan capacity, typically \emph{delegated} to the warehouse engine, a division of labour that shapes the class's whole architecture. Writes are bundled into ELT/ETL windows (D2 Low); load follows office hours with Monday-morning and month-start peaks; the dashboard must render in seconds (D3 Medium), while an hour of downtime is an annoyance, not a loss event (D5 Low).

The second challenge is the contract from the leading question: the marts must be refreshed within the window and become visible \emph{atomically} -- consumers must never see a half-updated state. That is the freshness-by-refresh-contract semantics (D4 Medium, footnote~10), and its adherence is tracked as a fitness function -- a D9 concern. The third challenge is provenance under interrogation: when a regulator questions a reported risk figure, the platform must trace it back through every transformation to the source systems -- a D6 demand that BCBS~239 hardens into a hard constraint where banking data are involved \citep{bcbs2013rdarr}. And because the warehouse bill is the dominant run cost, cost discipline is the operative FinOps concern -- D10 High. Data volumes are large (terabytes to petabytes), dimensionally modelled -- Kimball's star schema remains the reference methodology \citep{kimball2013warehouse}; the change rate is high at report level, moderate in the core data model (D7 Medium). The binding scenarios:

\begin{itemize}
    \item \textbf{S1 (dashboard latency).} A controller opens the standard management dashboard (stimulus) on Monday morning (environment); it renders (response) \textbf{in under 5 seconds} (response measure), with ad-hoc analytical queries in seconds to minutes. The D1/D3 scenario in the class's OLAP reading.
    \item \textbf{S2 (refresh contract).} The nightly ELT run executes (stimulus); all marts are refreshed (response) \textbf{within the refresh window, atomically visible, with refresh-window adherence tracked as a fitness function} (response measure). The D4/D9 scenario.
    \item \textbf{S3 (lineage on demand).} A regulator or auditor questions a reported risk figure (stimulus); the platform traces it (response) \textbf{back through every transformation to the source systems, on demand} (response measure) -- BCBS~239 lineage where banking data are involved \citep{bcbs2013rdarr}. The D6 scenario, hardened into $K(a)$ for banks.
\end{itemize}

$K(\text{C7})$: BCBS~239 for banks (risk reporting: accuracy, completeness, timeliness, and demonstrable lineage) \citep{bcbs2013rdarr}; the GDPR (purpose limitation, anonymisation in analyses) \citep{eu2016dsgvo}; sector-specific reporting duties. The knock-out reading: a pipeline whose transformations are not versioned and traceable cannot serve regulated reporting -- lineage is a structural property, retrofitting it is a rebuild.

\subsection{The requirements profile}

With the challenges in mind -- OLAP scans, the refresh contract, lineage on demand, the warehouse bill -- the weights follow; each H is a veto trigger (Part~\ref{part:foundations}). Table~\ref{tab:req-c7} is the C7 column of the consolidated table.

\begin{table}[htbp]
\centering
\footnotesize
\caption{Requirements profile of C7 (decision support / BI analytics) -- column C7 of Table~\ref{tab:requirements}, cell-identical; note numbers refer to that table's footnotes.}
\label{tab:req-c7}
\begin{tabular}{@{}p{3.4cm}cp{8.3cm}@{}}
\toprule
\textbf{Dimension} & \textbf{Weight} & \textbf{Why} \\
\midrule
D1 Read scalability & \textbf{H} & heavy OLAP scans by few users, delegated to the warehouse engine (S1; note~7) \\
D2 Write scalability \& elasticity & L & writes are bundled into the nightly ELT window \\
D3 Latency & M & dashboards in under 5\,s; ad-hoc queries in seconds to minutes \\
D4 Consistency \& integrity & M & freshness by refresh contract -- ``consistent as of yesterday 24:00'' (S2; note~10) \\
D5 Availability \& fault isolation & L & a dashboard down for an hour is an annoyance, not a loss event \\
D6 Security \& auditability & M & lineage and purpose limitation; BCBS~239 hardens them into $K(a)$ where banking data flow (S3) \\
D7 Evolvability & M & report-level churn is high; the core dimensional model moves slowly \\
D8 Simplicity \& TTM & M & thin serving keeps the estate simple; the pipeline carries the complexity \\
D9 Testability \& deployability & M & refresh-window adherence is tracked as a fitness function (S2) \\
D10 Operating cost & \textbf{H} & warehouse compute is the bill; cost discipline is the operative FinOps concern \\
D11 Team scaling & L & a data team, not a fleet of feature teams \\
D12 AI integrability & M & text-to-SQL docks onto the governed semantic layer, not onto raw tables \\
\midrule
Workload shape $S(a)$ & \multicolumn{2}{l}{batch + thin serving} \\
Hard constraints $K(a)$ & \multicolumn{2}{p{9.0cm}}{BCBS 239 lineage (banks)} \\
\bottomrule
\end{tabular}
\end{table}

\subsection{What real systems chose -- and why}

The documented modern form is a batch/ELT pipeline in front of a thin serving layer: sources $\rightarrow$ orchestrated DAGs (\textbf{Apache Airflow}: scheduler, executor, workers, metadata database; DAGs as code \citep{beauchemin2015airflow, airflow2024docs}) $\rightarrow$ warehouse $\rightarrow$ BI frontend. The ``modern data stack'' is thus architecturally a layered application over a batch pipeline -- and the capability tables of Part~\ref{part:patterns} explain both halves: the pipeline column (Table~\ref{tab:cap-pf}) serves the refresh contract and lineage by construction (versioned transformations, immutable stage outputs -- the D4-footnote-10 and D6 demands), while the layered column (Table~\ref{tab:cap-l}) serves the thin serving tier exactly because that tier delegates the D1-High scans to the warehouse and keeps its own D8/D10 virtues.

The open-source serving references make the class's low operational demands visible in their own packaging: \textbf{Apache Superset} (Python/Flask, originating at Airbnb) is deliberately a \emph{thin} visualisation layer with no data storage of its own, connecting directly to SQL engines \citep{superset2024platform, airbnb2021superset}; \textbf{Metabase} ships as a single JAR -- a literal monolith, mirroring how little serving infrastructure the class needs \citep{metabase2024docs}. Both delegate scaling to the database: division of labour as an architectural principle. Where the trade-off bites (Assumption A2) is freshness: streaming ingestion (EDA) earns its broker-operations complexity only when the freshness contract measurably tightens below the batch window -- tightening it towards real time is not a tuning exercise but a class change into C8 economics.

\begin{keypoint}
C7 is an integration product over classes C1--C5 whose consistency semantics -- freshness by refresh contract -- is a \emph{designed} third option beside ACID and eventual. The ADR to write is the freshness contract itself; the fitness functions are refresh-window adherence and p95 dashboard latency; and tightening the contract toward real time is not a tuning exercise but a class change -- it drags the system into C8 economics.
\end{keypoint}

\begin{ailinse}[Natural-language analytics (Axis B)]
The visible AI frontier in C7 is the natural-language query: ``show me revenue by region, last four quarters'' compiled by an LLM into SQL against the semantic layer. The class profile dictates the containment: the LLM \emph{proposes} a query; the semantic layer's schema and access-control contracts \emph{validate and execute} it -- text-to-SQL against governed models rather than raw tables, so that lineage (scenario~S3) and purpose limitation survive the convenience. The failure mode to design against is silent plausibility: a syntactically valid, semantically wrong query returns confident nonsense. The eval harness of Part~\ref{part:ai} -- golden question/answer sets over a frozen warehouse state -- is the class-appropriate test instrument, and footnote~10's refresh contract is what makes such golden sets stable enough to test against.
\end{ailinse}

\begin{projektbox}
The Portfolio Intelligence Platform contains a C7 subsystem: portfolio analytics, exposure aggregation, and report generation over the deterministic data store. Its refresh contract (``analysis as of last completed ingestion'') bounds what the advisory layer may claim -- an answer must never cite data fresher than the index actually is. The freshness contract therefore appears twice in the project's measurement contract: as a pipeline fitness function (C7 discipline) and as a grounding rule for generated answers (C10 discipline).
\end{projektbox}

In one sentence: the primary recommendation for C7 is pipes-and-filters (ELT) feeding a thin layered serving tier -- the canonical hybrid of the row (PF at $++$, with L, MM, and SL at $+$) -- and EDA ingestion as secondary where the freshness contract demands it; Part~\ref{part:fit} computes this verdict through the three-stage procedure.

% ============================================
% SECTION: C8 REAL-TIME / IOT STREAMING
% ============================================
\section{C8 -- Real-Time / IoT Streaming}
\label{sec:c8}

\emph{The sensors never stop: what ingests the world at the world's own rate, indefinitely -- and stays exactly right when a node dies mid-window?} The class comprises systems that process continuously arriving event data: sensor telemetry, clickstreams, vehicle positions, market data. Its defining property is that data are produced by the world at the world's own rate, and lose value quickly: the system must sustain ingest at the production rate \emph{indefinitely}, master backpressure, and guarantee state correctness across failures.

\subsection{The challenges it brings}

The first challenge is the sheer, unending inflow. The verified magnitudes: \textbf{LinkedIn}, Kafka's birthplace \citep{kreps2011kafka}, operates more than seven trillion Kafka messages per day across roughly 100 clusters, over 4{,}000 brokers, about 100{,}000 topics and seven million partitions \citep{lee2019kafka}; \textbf{Uber} moves trillions of messages and petabytes per day through an integrated real-time stack of Kafka (transport), Flink (stream processing), and Pinot (OLAP serving), documented in a SIGMOD paper \citep{fu2021realtime}. Ingest at that rate, around the clock, with bounded consumer lag and mastered backpressure, is the class's defining demand on D2 (write scalability) -- the inversion of C2's read-heavy profile -- and running it 24/7 without pause is a demand on D5 (availability and fault isolation): the world does not stop producing while a node recovers. Value decay adds D3 (latency): an anomaly alert is worth something within milliseconds to seconds, and little after.

The second challenge is the genuinely hard one: \emph{declared correctness semantics under failure}. Correctness here has stream-specific meanings -- event time versus processing time, windowing, watermarks -- and the trade-off between correctness, latency, and cost is formalised in the Dataflow model \citep{akidau2015dataflow}; exactly-once state across failures is achievable via distributed snapshots and checkpointing \citep{carbone2017state}, but it is bought with machinery and permanent operational competence. That is the D4 demand in its stream reading (Table~\ref{tab:requirements}, footnote~11) -- and a warning on D8 (simplicity), which the class weights Low because nobody chooses streaming for its ease. The third challenge is longevity of the plumbing: topologies change moderately, but \emph{schema evolution is a permanent concern} (D7 Medium); data volume is the largest of all classes (append-only logs), retention often TTL-bounded, and the infrastructure long-lived even where the data are not. The binding scenarios:

\begin{itemize}
    \item \textbf{S1 (sustained ingest).} Sensors emit at full production rate (stimulus) around the clock (environment); the platform ingests and processes (response) with \textbf{consumer lag bounded and no data loss, indefinitely} (response measure). The D2/D5 scenario.
    \item \textbf{S2 (exactly-once state).} A processing node fails mid-window (stimulus) under load (environment); the system recovers (response) with \textbf{state restored to exactly-once semantics via checkpointing, zero duplicated or lost aggregate updates} (response measure) \citep{carbone2017state}. The D4 scenario in its footnote-11 reading.
    \item \textbf{S3 (end-to-end latency).} An anomalous reading arrives (stimulus); the alert fires (response) \textbf{within milliseconds to a few seconds end-to-end, with per-key ordering preserved} (response measure) \citep{akidau2015dataflow}. The D3 scenario.
\end{itemize}

$K(\text{C8})$ is technical rather than statutory: per-key ordering guarantees and exactly-once semantics \emph{where declared} are contractual knock-outs -- a billing stream that double-counts under failure is not ``mostly correct'', it is wrong \citep{carbone2017state, akidau2015dataflow}. Where the streams carry personal data (vehicle telemetry, wearables), the GDPR adds purpose limitation and retention duties \citep{eu2016dsgvo}. The pragmatic industry norm -- at-least-once delivery plus idempotent consumers -- is legitimate exactly where the scenario says so, and the decision is taken \emph{per stream, per scenario}, never platform-wide.

\subsection{The requirements profile}

With the challenges in mind -- the unending inflow, correctness under failure, value decay -- the weights follow; each H is a veto trigger (Part~\ref{part:foundations}). Table~\ref{tab:req-c8} is the C8 column of the consolidated table.

\begin{table}[htbp]
\centering
\footnotesize
\caption{Requirements profile of C8 (real-time / IoT streaming) -- column C8 of Table~\ref{tab:requirements}, cell-identical; note numbers refer to that table's footnotes.}
\label{tab:req-c8}
\begin{tabular}{@{}p{3.4cm}cp{8.3cm}@{}}
\toprule
\textbf{Dimension} & \textbf{Weight} & \textbf{Why} \\
\midrule
D1 Read scalability & M & consumers read the log at their own pace; serving is delegated to OLAP sinks \\
D2 Write scalability \& elasticity & \textbf{H} & ingest at the world's production rate, indefinitely, with backpressure mastered (S1) \\
D3 Latency & \textbf{H} & alerts fire within milliseconds to seconds, end to end (S3) \\
D4 Consistency \& integrity & M & stream semantics: exactly-once state, event-time windows, watermarks (S2; note~11) \\
D5 Availability \& fault isolation & \textbf{H} & the world does not pause when a node fails; recovery must preserve state \\
D6 Security \& auditability & L & low relative to the ledger classes; GDPR applies where streams carry personal data \\
D7 Evolvability & M & topologies change moderately; schema evolution is the permanent concern \\
D8 Simplicity \& TTM & L & nobody chooses this class for its simplicity \\
D9 Testability \& deployability & M & correctness under failure is verified by chaos experiments, not unit suites alone \\
D10 Operating cost & M & broker fleets cost, but the class's economics absorb them \\
D11 Team scaling & M & platform and stream teams coordinate around shared topics \\
D12 AI integrability & M & models score events in the stream as checkpointed operators \\
\midrule
Workload shape $S(a)$ & \multicolumn{2}{l}{continuous stream} \\
Hard constraints $K(a)$ & \multicolumn{2}{p{9.0cm}}{Per-key ordering; exactly-once where stated} \\
\bottomrule
\end{tabular}
\end{table}

\subsection{What real systems chose -- and why}

The documented form is event-driven architecture plus pipes-and-filters over a durable log: producers $\rightarrow$ Kafka (durable, partitioned, replayable) $\rightarrow$ stream processors (Flink) $\rightarrow$ sinks (OLAP, alerting, data lake) \citep{kreps2011kafka, fu2021realtime}. The EDA column of Part~\ref{part:patterns} (Table~\ref{tab:cap-eda}) is this class's mirror: a durable, partitioned, replayable log with decoupled producers and consumers serves D2 and D5 at $++$ -- the two demands that eliminate every single-quantum interactive pattern at the shape gate -- and the streaming incarnation of pipes-and-filters supplies the processing layer whose checkpointing answers S2 \citep{carbone2017state}. \textbf{Netflix} is the consumer-scale EDA reference, with event-driven telemetry pipelines and resilience institutionalised through chaos engineering \citep{evans2016netflix, basiri2016chaos} -- chaos experiments being exactly how this class tests its D4/D5 claims.

The counter-lessons both come from \emph{this} class's neighbourhood and were introduced in Part~\ref{part:foundations}: \textbf{Segment} -- a customer-data pipeline -- retreated in 2018 from over 140 per-destination microservices to a monolith with a central queueing system because operational and test complexity crushed a small team \citep{noonan2018goodbye, infoq2020segment}; \textbf{Prime Video} consolidated a serverless orchestration into a single process for a tightly coupled A/V monitoring flow \citep{kolny2023primevideo, cockcroft2023prime}. The shared pattern -- and the Assumption-A2 lesson: both cut \emph{one} coherent dataflow along technical rather than domain seams, and the interaction costs (queues, orchestrator transitions, storage round-trips, test matrices) consumed the benefit \citep{newman2021building}. Open-source references: Apache \textbf{Kafka}, Apache \textbf{Flink}, MQTT brokers (Mosquitto, EMQX) at the IoT edge, Apache Pinot/Druid for real-time OLAP serving.

\begin{keypoint}
C8 must keep pace with the production rate of the world -- indefinitely. Its genuinely hard requirement is not throughput but \emph{declared correctness semantics under failure}: exactly-once state and event-time correctness are bought with checkpointing machinery and permanent operational competence, so the pragmatic norm is at-least-once plus idempotence -- decided per stream, per scenario, and recorded as such \citep{carbone2017state, akidau2015dataflow}.
\end{keypoint}

\begin{ailinse}[Online inference and drift on streams (Axis B)]
C8 is where ML meets its hardest operational constraint: models score events \emph{in the stream} (fraud, anomaly, predictive maintenance) at millisecond budgets, which rules out per-event LLM calls entirely and demands pre-trained, locally served models. The stream is simultaneously the monitoring instrument: input-distribution statistics computed in the pipeline detect data and concept drift \citep{gama2014drift}, and production-readiness rubrics such as the ML Test Score assume exactly this telemetry \citep{breck2017mltest}. Architecturally, the model is one more stateful stream operator -- checkpointed, versioned, and replayable like any other, so that scenario~S2's exactly-once discipline extends to inference results.
\end{ailinse}

In one sentence: the primary recommendation for C8 is EDA over a durable log with streaming pipes-and-filters as the processing layer -- the documented Uber stack (EDA at $++$, PF and MS at $+$) -- with microservice processors as secondary where team ownership demands it; Part~\ref{part:fit} computes this verdict through the three-stage procedure.

% ============================================
% SECTION: C9 COLLABORATION / MESSAGING
% ============================================
\section{C9 -- Collaboration / Messaging}
\label{sec:c9}

\emph{Five million people are connected at this moment, and every message must reach its channel within half a second: what holds the connections?} The class comprises chat, team-collaboration, and messaging applications. Its peculiarity is a resource profile that classical request/response never modelled: the system holds \emph{millions of long-lived, stateful connections} (WebSockets) and pushes every message to all channel members immediately. Latency must feel instantaneous; ordering must be causal \emph{per channel} -- global ordering is unnecessary, a deliberate weakening that buys scalability (Table~\ref{tab:requirements}, footnote~12).

\subsection{The challenges it brings}

The first challenge is the connections themselves. \textbf{Slack} holds more than five million simultaneous WebSocket sessions at peak; when a morning peak rolls across a timezone, millions of clients connect and boot within minutes, and the boot storm -- not the message rate -- is what threatens the core databases. Slack's application-level edge cache \textbf{Flannel}, deployed at global points of presence, reduced p99 latency for channel-membership queries from roughly 2{,}000\,ms to roughly 200\,ms while shielding the core from exactly these storms \citep{slack2017flannel}. The binding load is thus \emph{connection fan-out and push}, not raw read/write rates -- which is why D1 and D2 sit at Medium with footnote~9 while the crux lands on D3 (latency) and D5 (availability): a message must reach its channel in 100--500\,ms, and a disconnected messenger is a dead messenger. Every message is one write and $N$ push-deliveries; load arrives as office-hour waves travelling around the globe with the timezones (Slack) or as evening peaks (Discord).

The second challenge is the history tail. Message histories are enormous -- \textbf{Discord} stores trillions of messages -- and users scroll deep into them expecting low-tens-of-milliseconds reads: Discord's storage migrations (MongoDB $\rightarrow$ Cassandra $\rightarrow$ ScyllaDB, behind Rust data services performing request coalescing) cut p99 read latency from 40--125\,ms to roughly 15\,ms \citep{ingram2023discord} -- a D3 demand on the read path. The third challenge is that consistency can be \emph{relaxed by design}: causal order per channel suffices (D4 Medium, footnote~12), the deliberate weakening that makes the fan-out scalable. Feature churn is high while the core protocol stays stable (D7 Medium); lifetimes exceed ten years. The binding scenarios:

\begin{itemize}
    \item \textbf{S1 (delivery latency).} A user sends a channel message (stimulus) in normal global operation (environment); all online channel members receive it (response) \textbf{within 100--500\,ms, in causal order per channel} (response measure). The D3/D4 scenario.
    \item \textbf{S2 (connection fan-out).} Morning peak rolls across a timezone (stimulus); millions of clients connect and boot (environment/response) with \textbf{connection establishment and initial payload within budget while protecting the core databases} (response measure) -- the exact scenario for which Slack built its edge cache \citep{slack2017flannel}. The D5 scenario in the class's connection reading (note~9).
    \item \textbf{S3 (history read tail).} A user scrolls deep into channel history (stimulus); the store serves the read (response) with \textbf{p99 read latency in the low tens of milliseconds} (response measure) -- the target of Discord's storage migrations \citep{ingram2023discord}. A D3 demand on the storage tier.
\end{itemize}

$K(\text{C9})$: the GDPR, with data residency as an explicit selling argument in the self-hosted market segment \citep{eu2016dsgvo}; in enterprise deployments, compliance archiving obligations (MiFID~II and FINRA record-keeping rules for trader communication) make exportable, tamper-evident message archives a hard requirement. The knock-out reading: for regulated enterprise customers, an architecture that cannot guarantee complete capture and retention of business communication is excluded -- which is precisely the market logic behind Mattermost's single-binary, self-hostable design.

\subsection{The requirements profile}

With the challenges in mind -- connection storms, push fan-out, the history tail, per-channel ordering -- the weights follow; each H is a veto trigger (Part~\ref{part:foundations}). Table~\ref{tab:req-c9} is the C9 column of the consolidated table.

\begin{table}[htbp]
\centering
\footnotesize
\caption{Requirements profile of C9 (collaboration / messaging) -- column C9 of Table~\ref{tab:requirements}, cell-identical; note numbers refer to that table's footnotes.}
\label{tab:req-c9}
\begin{tabular}{@{}p{3.4cm}cp{8.3cm}@{}}
\toprule
\textbf{Dimension} & \textbf{Weight} & \textbf{Why} \\
\midrule
D1 Read scalability & M & the binding load is connection fan-out and push, not raw reads (note~9) \\
D2 Write scalability \& elasticity & M & one write becomes $N$ push deliveries -- amplification, not raw write rate (note~9) \\
D3 Latency & \textbf{H} & delivery within 100--500\,ms or the conversation dies (S1, S3) \\
D4 Consistency \& integrity & M & causal order per channel suffices; global order is deliberately waived (note~12) \\
D5 Availability \& fault isolation & \textbf{H} & presence is the product: a disconnected messenger is a dead messenger (S2) \\
D6 Security \& auditability & M & enterprise segments harden archiving duties into $K(a)$; consumer segments do not \\
D7 Evolvability & M & feature churn is high while the core protocol stays stable \\
D8 Simplicity \& TTM & M & a small install must stay operable -- the self-hosted market demands it \\
D9 Testability \& deployability & M & staged rollouts across a heterogeneous client fleet \\
D10 Operating cost & M & connection infrastructure costs scale with concurrency, not usage \\
D11 Team scaling & M & platform teams for gateway and storage, feature teams above \\
D12 AI integrability & L & assistants and summarisation decorate the edges; the fan-out core is untouched \\
\midrule
Workload shape $S(a)$ & \multicolumn{2}{l}{interactive, connection-stateful} \\
Hard constraints $K(a)$ & \multicolumn{2}{p{9.0cm}}{Compliance archiving (MiFID/FINRA) in enterprise segments} \\
\bottomrule
\end{tabular}
\end{table}

\subsection{What real systems chose -- and why}

The class spans the full structural spectrum with one business domain. \textbf{Mattermost} ships deliberately as \emph{one} Go binary with PostgreSQL -- the monolith as a \emph{feature} for self-hosting and compliance customers \citep{mattermost2024docs}: the modular-monolith column's D8/D10 strengths (Table~\ref{tab:cap-mm}) are precisely what the enterprise $K(a)$ segment buys, and its D5 weakness is mitigated by replicated instances. \textbf{Rocket.Chat}, built on Node.js and MongoDB, sits in the middle \citep{rocketchat2024github}. \textbf{Slack}'s documented shape is a hybrid: a PHP/Hack monolithic core for persistence and business logic with a specialised distributed real-time push layer in front \citep{slack2017flannel} -- and the push layer is publish/subscribe fan-out, which is why the EDA column (Table~\ref{tab:cap-eda}) owns this row: message delivery \emph{is} event fan-out with causal per-channel ordering; the domain semantics and the pattern coincide. \textbf{Discord} represents polyglot specialisation per quality attribute -- BEAM for connection concurrency, Rust for tail latency \citep{ingram2023discord} -- targeted microservices exactly where the D3 tail demands them. Matrix/Synapse adds a federated counter-model.

Same domain, four structures: the trade-off (Assumption A2) is resolved by scale and business model, not by the domain -- below roughly $10^5$ concurrent connections a specialised push layer is premature optimisation, and the measured concurrent-connection count is the tiebreaker.

\begin{keypoint}
C9's binding load is connection fan-out and push, not raw read/write rates -- a resource profile request/response never modelled. The same business domain spans Mattermost's single, deliberately monolithic binary and Discord's polyglot specialised cluster \citep{mattermost2024docs, ingram2023discord}: the profile's core is stable, but scale and business model move the weights at its edges -- measured concurrent-connection count is the tiebreaker.
\end{keypoint}

\begin{thinkbox}
Mattermost and Discord implement substantially the same user-visible functionality. Using the twelve dimensions of Table~\ref{tab:dimensions}: which \emph{three} dimensions differ most strongly between the requirements profile of a self-hosted compliance deployment (500 users, banking client) and a global consumer platform (150 million users)? Would any weight flip from L to H? What does that imply for the claim that ``the application class determines the profile''?
\end{thinkbox}

In one sentence: the primary recommendation for C9 is a hybrid -- a monolithic persistence and business core with a specialised event-driven push layer, Slack's documented shape (EDA at $++$ at the fan-out crux, MM and MS at $+$) -- with a modular monolith alone as secondary for the self-hosted market segment; Part~\ref{part:fit} computes this verdict through the three-stage procedure.

% ============================================
% SECTION: C10 AI-NATIVE ANALYSIS / ADVISORY PLATFORMS
% ============================================
\section{C10 -- AI-Native Advisory Platforms}
\label{sec:c10}

\emph{The component your product is built around is non-deterministic, priced per call, and deprecated within months: what structure contains it?} The class comprises platforms whose core value is generated by LLM agents cooperating with deterministic services: research and analysis assistants, financial advisory platforms, domain copilots. It is the youngest class in the catalogue, the profile of the course project, and the reason this course exists in its present form. Its defining properties follow from the component it is built around: the AI component is non-deterministic, fallible, latency-heavy, and priced per call \citep{sculley2015hidden, amershi2019software}. The architecture must therefore \emph{contain} it: deterministic services for everything deterministic, LLM calls only where determinism cannot reach, and every generated statement grounded in retrievable sources.

\subsection{The challenges it brings}

The first challenge is accountability for probabilistic output. An advisory answer is only defensible if every factual claim carries a resolvable provenance reference and every agent step is logged -- observability is not an operations concern here but \emph{domain functionality} \citep{lewis2020rag}. That is a demand on D6 (security and auditability) with statutory force behind it: the EU AI Act (Regulation (EU) 2024/1689) imposes risk-based duties -- transparency, technical documentation, logging, human oversight, robustness -- and an advisory application in a financial context can fall into the high-risk class, at which point logging and oversight acquire legal force \citep{eu2024aiact}.

The second challenge is the cost model, and it is genuinely new. Requests are rare but heavy: seconds to minutes of latency, with per-request cost orders of magnitude above classical API calls (LLM inference plus multiple tool invocations). Users accept seconds-to-minutes for advisory answers, so the High-grade concern is \emph{cost per request, not speed} -- D10 High in the footnote-16 reading, with D3 relaxed to Medium (footnote~5). Two cost-model facts anchor the economics: asynchronous batch processing is priced roughly 50\,\% below synchronous calls \citep{openai2024batch}, and routing across cheap and expensive models is a first-order cost lever -- LLM cascades reach up to 98\,\% cost reduction at comparable quality \citep{chen2023frugalgpt}, and learned routers better than halve cost without measured quality loss \citep{ong2025routellm}.

The third challenge is churn at the core's edge: models, prompts, and frameworks turn over in months -- the most extreme change rate in the catalogue, and the strongest argument for ports and adapters, with the LLM as a swappable adapter behind a port, never as the core \citep{cockburn2024hexagonal, sculley2015hidden}. That is D7 (evolvability) High -- and it drags D9 (testability) with it in a new reading: \emph{evals} are the operative meaning of testability (footnote~15), because only a versioned golden set with statistical thresholds can tell whether a model migration preserved quality \citep{zheng2023judging}. The workload mix underneath is hybrid: read-heavy against knowledge stores (retrieval), write-heavy into audit and trace logs, consistency hybrid (footnote~13: the knowledge index eventually consistent through re-indexing cycles, the transaction and audit path ACID), load irregular and user-driven, with batch components (embedding and index pipelines) shaped like C6/C7. The binding scenarios:

\begin{itemize}
    \item \textbf{S1 (grounded answer).} A client asks for a portfolio recommendation (stimulus) in normal operation (environment); the platform generates an answer (response) in which \textbf{every factual claim carries a resolvable provenance reference, and answers failing validation are blocked and escalated to a human -- detection rate $\geq 99\,\%$ at $<2$\,s added latency} (response measure) \citep{lewis2020rag}. The D6 scenario -- and D12's containment discipline in action.
    \item \textbf{S2 (cost per request).} A user session triggers a multi-step agent workflow (stimulus); the request completes (response) \textbf{within a per-request token-cost budget (e.g.\ CHF~0.40 at p95) and a p95 end-to-end latency budget (e.g.\ 20\,s)} (response measure), both enforced as CI-gated fitness functions \citep{ford2022evolutionary}. The D10 scenario in its footnote-16 reading.
    \item \textbf{S3 (model migration).} The provider deprecates the production model (stimulus) with months of notice (environment) \citep{openai2026deprecations}; the platform migrates (response) with \textbf{eval-harness pass rate $\geq$ threshold on the golden set before rollout, and rollback available} (response measure) \citep{zheng2023judging}. The D7/D9 scenario.
\end{itemize}

$K(\text{C10})$ extends beyond the AI Act: the GDPR governs personal data in prompts and indexes \citep{eu2016dsgvo}; financial-advisory deployments additionally face supervisory governance expectations for AI use \citep{finma2023oprisk}. Security is a distinct knock-out family: prompt injection cannot be fully solved in the model because instructions and data share one channel, so system-level defence in depth -- least-privilege tools, output validation, human-in-the-loop, consumption limits -- is constitutive \citep{owasp2025llmtop10}. Knock-out reading: an architecture in which agent steps are not loggable, tool privileges not boundable, or provenance not reconstructable is excluded before scoring -- the same veto logic that ACID exercises in C1, transposed to accountability.

\subsection{The requirements profile}

With the challenges in mind -- accountability with legal force, cost per request, model churn -- the weights follow; each H is a veto trigger (Part~\ref{part:foundations}). Table~\ref{tab:req-c10} is the C10 column of the consolidated table -- the only column with an H on D12.

\begin{table}[htbp]
\centering
\footnotesize
\caption{Requirements profile of C10 (AI-native advisory platform -- the course-project class) -- column C10 of Table~\ref{tab:requirements}, cell-identical; note numbers refer to that table's footnotes.}
\label{tab:req-c10}
\begin{tabular}{@{}p{3.4cm}cp{8.3cm}@{}}
\toprule
\textbf{Dimension} & \textbf{Weight} & \textbf{Why} \\
\midrule
D1 Read scalability & M & retrieval reads against knowledge stores; user concurrency stays modest \\
D2 Write scalability \& elasticity & L & requests are rare; the batch pipelines are scheduled, not elastic \\
D3 Latency & M & users accept seconds-to-minutes for advisory answers (note~5) \\
D4 Consistency \& integrity & M & hybrid: knowledge index eventual, transaction/audit path ACID (note~13) \\
D5 Availability \& fault isolation & M & degraded answers beat no answers; provider outages are survivable \\
D6 Security \& auditability & \textbf{H} & provenance per claim and a log per agent step -- observability as domain functionality, with EU AI Act force (S1) \\
D7 Evolvability & \textbf{H} & models, prompts, and frameworks turn over in months (S3) \\
D8 Simplicity \& TTM & M & start with the simplest structure -- but never simpler than the audit path \\
D9 Testability \& deployability & \textbf{H} & evals are the operative meaning of testability (S3; note~15) \\
D10 Operating cost & \textbf{H} & cost per \emph{request} (tokens, GPU) -- a run-cost class no classical profile contains (S2; note~16) \\
D11 Team scaling & L & small product teams; the platform premium is unaffordable \\
D12 AI integrability & \textbf{H} & definitional: the class exists to contain the probabilistic component \\
\midrule
Workload shape $S(a)$ & \multicolumn{2}{l}{hybrid: interactive + batch/async} \\
Hard constraints $K(a)$ & \multicolumn{2}{p{9.0cm}}{EU AI Act 2024/1689 (logging, oversight; potentially high-risk); GDPR} \\
\bottomrule
\end{tabular}
\end{table}

\subsection{What real systems chose -- and why}

Three documented building blocks define the reference shape. (a) \textbf{Retrieval-augmented generation} as the grounding layer: retriever plus generator, introduced by \citet{lewis2020rag}, surveyed across its naive/advanced/modular variants by \citet{gao2023survey}; the canonical pipeline -- ingestion (chunking, embedding) $\rightarrow$ vector index $\rightarrow$ retrieval $\rightarrow$ context construction $\rightarrow$ generation with citations -- is structurally a pipes-and-filters pipeline plus an online serving layer, with seven documented failure points along it \citep{barnett2024seven}: the PF column (Table~\ref{tab:cap-pf}) serving the class's C6-shaped batch inheritance. (b) \textbf{Agent orchestration}: Anthropic's engineering guidance distinguishes \emph{workflows} (predefined chains: prompt chaining, routing, parallelisation, orchestrator--workers, evaluator--optimizer) from \emph{agents} (the model steers its own loop and tool use) and explicitly recommends starting with the simplest structure \citep{anthropic2024agents}; the quantified restraint case is Anthropic's own multi-agent research system -- 90.2\,\% better than a single agent on the internal eval at roughly \emph{fifteen times} the token consumption of a chat \citep{anthropic2025multiagent} -- the D10-High trade-off measured. (c) \textbf{Compound AI systems}: state-of-the-art results increasingly come from systems of retrievers, models, tools, and verifiers rather than from single models -- the system architecture becomes the differentiator \citep{zaharia2024compound}.

The deterministic services -- data access, computation, persistence -- form a conventional C3/C7-profiled system, and the capability tables explain the host choice: the modular-monolith column (Table~\ref{tab:cap-mm}) hosts them cheaply within one ACID quantum (the D4-footnote-13 audit path) while giving the AI subsystem a hard, CI-verifiable module boundary; the hexagonal column (Table~\ref{tab:cap-hx}) answers the class's two hardest Highs directly -- the LLM as a swappable adapter behind a port serves D7 under model churn, and the port is where the eval harness and the cost gateway dock, serving D9 and D10. Where the trade-off bites (Assumption A2): synchronous service chains would multiply seconds-scale LLM latency and failure rates, which is what keeps microservices at $\circ$ despite their blast-radius appeal; the mitigation for the monolith's weaker cells is asynchronous edges -- queues absorb LLM latency, rate limits, and outages, and create natural batching points for cost control. Open-source references: vector stores (Qdrant, Weaviate, and pgvector as the monolith-friendly option inside PostgreSQL), orchestration frameworks (LangChain/LangGraph \citep{langchain2024langgraph}, LlamaIndex), serving (vLLM), and eval harnesses (Ragas, promptfoo) \citep{cockburn2024hexagonal}.

\begin{projektbox}
The Portfolio Intelligence Platform \emph{is} a C10 instance, and its profile is best understood as an inheritance diagram plus one genuinely new element. \textbf{Inherited:} the ingestion and eval pipelines are C6 (versioned, seeded, reproducible batch -- Section~\ref{sec:c6}); the analytics and reporting subsystem is C7 (refresh contracts, lineage -- Section~\ref{sec:c7}); the deterministic services (portfolio data access, computation, audit journal) are C3 (ACID, four-eyes, boring on purpose -- Section~\ref{sec:c3}). \textbf{New:} the cost model. Classical profiles price capacity per user or per infrastructure-hour; C10 is \emph{expensive per request} -- footnote~16 of Table~\ref{tab:requirements} -- so D10 = H acquires a meaning no classical class carries: a token-cost budget per request, per feature, enforced in CI and monitored per tenant. \textbf{Also new:} D12 = H for the platform itself, and D9 = H in its footnote-15 reading -- \emph{evals are the operative meaning of testability}: a versioned golden set with statistical thresholds gates every prompt change, model update, and provider migration, exactly as the test pyramid gates deterministic code. When you design your project architecture, start from the inherited disciplines -- they are solved problems -- and spend your design budget on the two new ones.
\end{projektbox}

\begin{keypoint}
C10 does not overthrow the method; it stress-tests it. The class adds one dimension weighted High that no classical class weights High (D12), one cost semantics (per request, not per user), and one test-artefact class (the eval harness) -- and otherwise \emph{inherits} its profile from C6, C7, and C3. This is Assumption A6 made concrete: the theory absorbs AI as a tenth application class rather than being reinvented for it.
\end{keypoint}

In one sentence: the primary recommendation for C10 is a hexagonal modular monolith -- deterministic core, AI adapters at ports, an LLM gateway as the single measurement point -- plus pipes-and-filters for ingestion and evals (MM and HX at $++$), with EDA for the AI job and audit spine as secondary; Part~\ref{part:fit} computes this verdict through the three-stage procedure.

% ============================================
% SECTION: STEPPING BACK: TEN PROFILES SIDE BY SIDE
% ============================================
\section{Stepping Back: Ten Profiles Side by Side}
\label{sec:requirements-table}

Ten times over, this part has run the same movement: a leading question, the documented challenges with their dimensions, a twelve-row profile derived from them, and the structures real systems chose. Each section stood on its own. What no single section could deliver is the view \emph{across} the ten -- and that is what this closing section supplies: the consolidated requirements table, the reading rules that keep it honest, and the cross-class observations that prepare the matching in Part~\ref{part:fit}.

Table~\ref{tab:requirements} consolidates the ten requirements profiles: the twelve dimension weights $w_i(a)$, the dominant workload shape $S(a)$, and the hard constraints $K(a)$ per class -- the ten explanation views you have just walked through, assembled into one comparison view. It is the demand-side counterpart of the capability table (Table~\ref{tab:capability}) and one of the two inputs to the fit matrix of Part~\ref{part:fit}. Three reading rules apply. First, read \emph{columns} to see a class: each column repeats the per-class table of its section (Tables~\ref{tab:req-c1}--\ref{tab:req-c10}) cell for cell, and every H in it is backed by a binding scenario with a response measure. Second, read \emph{rows} to see what a dimension discriminates: D7 (evolvability) is High in six classes and Low in none -- long life is the norm, not the exception -- whereas D12 is High only in C10, the definitional case. Third, and critically: \textbf{the seventeen footnotes are part of the table's semantics, not decoration}. Several cells carry a class-specific \emph{meaning} of their dimension -- testability as reproducibility in C6 (footnote~14), testability as eval pass rate in C10 (footnote~15), read scalability as OLAP scan capacity in C7 (footnote~7) -- and using the bare letter without its footnote produces wrong matches in Part~\ref{part:fit}.

\begin{keypoint}
An H in Table~\ref{tab:requirements} is a veto trigger backed by a scenario with a response measure; an L is a licence to not pay for that dimension. The footnotes carry class-specific semantics that the letters alone cannot: whoever matches profiles by letters without footnotes has not read the table.
\end{keypoint}

\begin{sidewaystable}[p]
\centering
\caption{Consolidated requirements table: priority weights of the twelve profile dimensions (H = High, exercising veto power per the formal model of Part~\ref{part:foundations}; M = Medium; L = Low), dominant workload shape $S(a)$, and hard constraints $K(a)$ for the ten application classes. Superscripts refer to the footnotes below the table, which are integral to the cell semantics.}
\label{tab:requirements}
\scriptsize
\setlength{\tabcolsep}{2.5pt}
\begin{tabular}{@{}p{2.3cm}*{10}{p{1.72cm}}@{}}
\toprule
\textbf{Dimension} & \textbf{C1 Core banking} & \textbf{C2 Social/ content} & \textbf{C3 Back-office} & \textbf{C4 ERP} & \textbf{C5 E-com\-merce} & \textbf{C6 Simulation/ batch} & \textbf{C7 DSS/BI} & \textbf{C8 IoT streaming} & \textbf{C9 Collab/ messaging} & \textbf{C10 AI-native advisory} \\
\midrule
D1 Read scalability & M & \textbf{H} & L & L & \textbf{H} & L & \textbf{H}\textsuperscript{7} & M & M\textsuperscript{9} & M \\
D2 Write scalability \& elasticity & M & M\textsuperscript{1} & L & L & \textbf{H} & \textbf{H}\textsuperscript{2} & L & \textbf{H} & M\textsuperscript{9} & L \\
D3 Latency & M\textsuperscript{3} & \textbf{H} & M & M & \textbf{H} & L\textsuperscript{4} & M & \textbf{H} & \textbf{H} & M\textsuperscript{5} \\
D4 Consistency \& integrity & \textbf{H} & L & \textbf{H} & \textbf{H} & M\textsuperscript{6} & M\textsuperscript{8} & M\textsuperscript{10} & M\textsuperscript{11} & M\textsuperscript{12} & M\textsuperscript{13} \\
D5 Availability \& fault isolation & \textbf{H} & \textbf{H} & L & M & \textbf{H} & L & L & \textbf{H} & \textbf{H} & M \\
D6 Security \& auditability & \textbf{H} & M & \textbf{H} & \textbf{H} & \textbf{H} & M & M & L & M & \textbf{H} \\
D7 Evolvability & \textbf{H} & \textbf{H} & \textbf{H} & \textbf{H} & \textbf{H} & M & M & M & M & \textbf{H} \\
D8 Simplicity \& TTM & L & M & \textbf{H} & M & M & M & M & L & M & M \\
D9 Testability \& deployability & \textbf{H} & \textbf{H} & M & M & \textbf{H} & \textbf{H}\textsuperscript{14} & M & M & M & \textbf{H}\textsuperscript{15} \\
D10 Operating cost & L & M & \textbf{H} & M & M & \textbf{H} & \textbf{H} & M & M & \textbf{H}\textsuperscript{16} \\
D11 Team scaling & M & \textbf{H} & L & M & M\textsuperscript{17} & L & L & M & M & L \\
D12 AI integrability & M & M & L & L & M & M & M & M & L & \textbf{H} \\
\midrule
Dominant workload shape $S(a)$ & interactive (+ batch edges) & interactive read-heavy & interactive & interactive (+ batch runs) & interactive, seasonal & scheduled batch & batch + thin serving & continuous stream & interactive, connection-stateful & hybrid: interactive + batch/async \\
\midrule
\textbf{Hard constraints $K(a)$} & BCBS 239; FINMA 2023/1; DORA (EU 2022/2554); ACID booking core; 10+ yr retention & DSA; GDPR & Retention law (e.g.\ OR 958\emph{f}); internal control systems; GDPR & GoBD/ GeB{\"u}V; SOX; IFRS audit chains & PCI DSS v4.0 scope minimisation; PSD2/SCA & Model validation and backtesting (finance); deterministic seeds & BCBS 239 lineage (banks) & Per-key ordering; exactly-once where stated & Compliance archiving (MiFID/ FINRA) in enterprise segments & EU AI Act 2024/1689 (logging, oversight; potentially high-risk); GDPR \\
\bottomrule
\end{tabular}

\vspace{2.5mm}
\begin{flushleft}
\tiny
\textbf{Footnotes:}
\textsuperscript{1}~Raw write rate is modest (Twitter: ca.\ 6\,k tweet writes/s vs.\ ca.\ 300\,k timeline reads/s \citep{krikorian2013timelines}); fan-out amplification is real but is absorbed by the fan-out subsystem, not the write path proper -- hence M with the amplification noted.
\textsuperscript{2}~Throughput as makespan and batch-window compute bursts, not requests/s.
\textsuperscript{3}~Class-internal spread of orders of magnitude: batch clearing hours, instant payments $<10$\,s end-to-end, card authorisation 1--2\,s, trading microseconds.
\textsuperscript{4}~Per-request latency irrelevant; makespan and batch window are the measures.
\textsuperscript{5}~Users accept seconds-to-minutes for advisory answers; the High-grade concern is cost per request, not speed.
\textsuperscript{6}~The class-defining hybrid: catalogue eventual, checkout/payment strictly ACID \citep{linden2006data}.
\textsuperscript{7}~``Read'' here means heavy OLAP scans by few users; serving is typically delegated to the warehouse.
\textsuperscript{8}~As bit-level reproducibility (seeds, versioned inputs), a scientific and -- for risk models -- regulatory duty \citep{bcbs2013rdarr, glasserman2003monte}.
\textsuperscript{9}~Connection fan-out and push, not raw read/write rates, are the binding load (Slack: $>$5\,M concurrent WebSockets \citep{slack2017flannel}); hence M with the crux carried by D3/D5.
\textsuperscript{10}~A third semantics beside ACID and eventual: freshness by refresh contract (``as of yesterday 24:00'').
\textsuperscript{11}~Stream semantics: exactly-once state, event-time windows, watermarks \citep{akidau2015dataflow, carbone2017state}.
\textsuperscript{12}~Causal order per channel suffices; global order unnecessary.
\textsuperscript{13}~Hybrid: knowledge index eventual, transaction/audit path ACID.
\textsuperscript{14}~Reproducibility (golden datasets, versioned pipelines) is the operative meaning of testability here.
\textsuperscript{15}~Evals are the operative meaning of testability here (Part~\ref{part:ai}).
\textsuperscript{16}~Cost per \emph{request} (tokens, GPU) -- a run-cost class no classical profile contains.
\textsuperscript{17}~Organisation-size dependent: the Shopify-vs-Amazon contrast \citep{westeinde2019deconstructing}.
\end{flushleft}
\end{sidewaystable}

\subsection{Reading the catalogue as a whole}
\label{sec:catalogue-synthesis}

Five cross-class observations fall out of the catalogue and prepare the matching in Part~\ref{part:fit}.

\textbf{The strongest discriminators are the read/write ratio and the consistency semantics.} C1 (write-critical, strict ACID) and C2 (roughly 50:1 read-heavy, deliberately eventual \citep{krikorian2013timelines}) are mirror images across both variables at once -- the fastest diagnostic pair in the catalogue, and the didactic anchor of this part. C5 is the only class \emph{defined} by a hybrid consistency profile \citep{linden2006data}, and C6/C7 contribute the third semantics family -- reproducibility and freshness by refresh contract -- that neither ACID nor eventual consistency captures (Section~\ref{sec:c6}). When classifying an unknown system, ask these two questions first; they eliminate more patterns via the shape gate and the D4 row than any other pair.

\textbf{Scale does not force microservices.} The documented monolith-at-scale cases span four classes: Instagram serves a global consumer platform from a horizontally replicated Django monolith \citep{woodruff2019static}; Stack Overflow serves on the order of 1.3 billion page views per month, at more than 6{,}000 requests per second, from roughly nine on-premise web servers running a monolithic .NET application \citep{craver2016stackoverflow, milanovic2023stackoverflow}; Shopify carries ca.~280 million requests per minute at BFCM peak on a pod-sharded modular Rails monolith \citep{westeinde2019deconstructing, shopify2024bfcm}; LMAX processes six million orders per second on one thread \citep{fowler2011lmax}. Stateless replication, sharding, and mechanical sympathy scale monoliths far. What microservices primarily solve is an \emph{organisational} scaling problem -- deployments per developer as team count grows \citep{forsgren2018accelerate, conway1968committees, skelton2019team} -- which is why Monzo's 2{,}800 services are viable only with extreme homogeneity and central migration automation \citep{sewell2024monzo}. In profile terms: D1/D2 rarely force distribution; D11 = H is what does.

\textbf{The rollback case studies share one pattern.} Segment \citep{noonan2018goodbye, infoq2020segment} and Prime Video \citep{kolny2023primevideo, cockcroft2023prime} both cut \emph{one} coherent dataflow along technical rather than domain seams -- one service per integration destination, one function per processing step -- and the interaction costs (queues, orchestrator state transitions, storage round-trips, the test matrix) consumed the benefit. Granularity must follow the coupling structure of the domain \citep{newman2021building}. For the catalogue this means: a class's workload shape is not merely a gate for pattern \emph{selection}, it also predicts where the expensive boundaries lie \emph{within} a pattern.

\textbf{Regulation is a first-class architectural requirement.} Across the catalogue, the constraint sets $K(a)$ translate directly into structure: BCBS~239 and FINMA 2023/1 into immutable journals, lineage, and resilience testing \citep{bcbs2013rdarr, finma2023oprisk}; DORA into incident-reporting and third-party risk machinery \citep{eu2022dora}; PCI~DSS v4.0 into cardholder-data zoning and scope minimisation \citep{pcissc2022pcidss}; the EU AI Act into logging and human-oversight duties for AI components \citep{eu2024aiact}. None of these can be bolted on late at reasonable cost -- they are Booch-significant decisions in the sense of Part~\ref{part:foundations}, which is exactly why they live in $K(a)$ as knock-outs rather than in the weights.

\textbf{The AI-native class inherits before it innovates.} C10 inherits the disciplines of C6/C7 (batch index and eval pipelines), and C3 (deterministic transactional services), and adds exactly two genuinely new elements: a cost model that is expensive per request rather than per user, and evals as the operative meaning of testability \citep{zaharia2024compound, anthropic2024agents}. For the course project this is the design instruction in one sentence: solve the inherited profiles with the inherited, well-understood structures, and concentrate the architectural attention on the two novelties.

\begin{keypoint}
The ten requirements profiles are derivable, not arbitrary: every weight traces to binding scenarios with response measures, every constraint to a statute or a contract, every workload signature to documented production numbers. The other operand is ready: Part~\ref{part:fit} can now match these profiles against the capability profiles of Part~\ref{part:patterns} cell by cell (Table~\ref{tab:fitmatrix}), and every cell can be traced back to $R(a) \times C(p)$ rather than to fashion or taste.
\end{keypoint}

\begin{thinkbox}
The catalogue contains ten classes -- why not nine, why not fourteen? Propose a candidate eleventh class (for example: computer games, embedded control, blockchain ledgers) and test it against the definition of Section~\ref{sec:appclass-intro}: does it have a \emph{recurring} ASR bundle with typical response measures, a characteristic workload shape, and a regulatory frame -- and does its profile differ from all ten columns of Table~\ref{tab:requirements} on at least two High weights? If it does not differ, it is an instance, not a class.
\end{thinkbox}