🛠️ Project exercise: AI-Augmented Portfolio Intelligence Platform

Over the whole semester, in teams, you design, build and operate a modular, AI-augmented analysis platform for stock portfolios. The platform ingests market prices (structured) and company news (unstructured), turns news into validated insights with an AI component, computes risk, performance and optimisation figures in deterministic services, and exposes everything API-first through an orchestrated multi-agent advisor – with a thin dashboard for demonstration only. It is a Software Engineering II project: its centre of gravity is architecture – how you structure a system so that it meets its quality attributes and stays maintainable while one part of it (the news understanding) is non-deterministic, fallible and costly. Whether the services ship as one modular monolith or as several deployables is your architecture decision (week 6), which you defend in week 14.

AI appears in two roles: as a tool you build the system with (Axis A) and as a component inside the system (Axis B). Everything the lecture teaches – profiles, matching, ADRs, measurement – you apply to this system. The project counts 50 % of the module grade.

❗ The single most important rule. The AI agents may only obtain and interpret quantitative values through the deterministic services – they must never compute a risk number, a return or an allocation themselves. An agent that “estimates” a volatility is an architecture defect. This separation of deterministic from non-deterministic system parts is the core engineering lesson of the course, and it is graded.

📎 Documents

Exercise sheet – project_exercise.pdf (16 pages): the normative description – overview and goals, functional requirements, reference architecture, AI integration rules, mandatory vs. distinction, semester plan and milestones, assessment, UI sketches. Read it in full. [link]
Project slides – AISE502_Projekt_Folien.pdf: the kickoff presentation of the project. The slides are the map, the sheet is the territory. [link]
UI sketches – low-fidelity sketches of the user journey and the six screens (HTML and PNG; also Section 8 of the sheet). [link]

Two phases, six milestones

Weeks 1–7 – design phase: the two-lesson exercise slot produces the requirements, studies candidate architectures against the patterns taught in the lecture, and decides and documents your architecture. Weeks 8–13 – implementation phase: the exercise slot becomes a one-lesson standup/coaching session; implementation happens mainly in self-study time. Week 14: presentations, architecture defence and peer reviews. The project work for each week is listed in the weekly sections; the exercise sheet remains the normative source.

Milestone	Weeks	Content	Deliverable / check
M1 Requirements and Ontology	1–3	Domain model and ontology; at least eight quality attribute scenarios with response measures (three of them for the AI components); utility tree; R(platform) with weights, workload shape and hard constraints; repository and tooling.	Deliverable A1 (end of week 3): requirements dossier
M2 Architecture Decision and Solution Design	4–7	Study the reference systems; run the three-stage match; ADR with rationale and C4-style diagram; bounded contexts → services and contracts; measurement contract with numbers (eval pass rate ≥ 95 %, p95 latency ≤ 20 s, token budget, zero boundary violations); walking-skeleton plan.	Deliverable A2 (end of week 7): architecture dossier + design-review gate
M3 Walking Skeleton	8–9	Thin end-to-end slice: MarketDataService delivers prices, a minimal ResearchAgent produces one validated Insight; stable API and a placeholder UI.	Check (week 9): the skeleton runs end-to-end
M4 Deterministic Core and Resilience	10–11	Performance, Risk and Optimization services fully tested against the reference vectors; resilience patterns on all external calls; graceful degradation verified.	Check (end of week 11): core fully tested and resilient
M5 Multi-Agent Orchestration, Evaluation, and Hardening	12–13	Advisor orchestrates 2–3 sub-agents through contracts, every LLM call through the gateway, ontology guard active; evaluation harness as a CI gate; cost and latency observability; topology ADR; threat model incl. prompt injection; optional distinction work.	Check (end of week 13): eval harness in CI + guard + cost observability
M6 Presentation and Architecture Defence	14	Present the system, defend the architectural trade-offs, reflect on where AI helped and hurt (Axis A and B), peer reviews; show one measurement-contract violation caught by CI.	Deliverable A3 (week 14): final presentation with architecture defence

Deliverables and assessment

A1 – requirements dossier (end of week 3): scenarios, utility tree, R(platform).
A2 – architecture dossier (end of week 7): ADR, C4 views, measurement contract – followed by the design-review gate. Production code starts only after the gate (exploratory spikes are allowed).
A3 – final presentation with architecture defence (week 14), plus peer reviews.

Evaluation of the project emphasises: architecture & trade-offs (decomposition, contracts, deterministic/non-deterministic separation, ADRs), robustness (resilience, guards, graceful degradation), quality (tests for the deterministic services, eval harness for AI), AI integration (anti-corruption layering, ontology guarding), operation (observability of cost and latency), and the distinction criteria for top marks (sheet, Section 5). The other 50 % of the module grade is the written examination (60 minutes, open book, closed internet).

Hints from the sheet

Build the walking skeleton first thing in the implementation phase – a thin end-to-end slice de-risks everything that follows.
Use the design phase fully: a decided architecture with contracts and a measurement contract makes the implementation weeks sufficient; an undecided one does not.
Pin the deterministic services with tests before you trust any agent output; keep the deterministic core free of LLM calls – this is the line that is graded.
Use a snapshot of market and news data so that demo and grading are reproducible even if the live APIs misbehave.
Commit after each milestone; record architectural decisions as ADRs as you go.