diff --git a/moodle/src/BRIEF_content_extraction.md b/moodle/src/BRIEF_content_extraction.md
new file mode 100644
index 0000000..9f8fbb1
--- /dev/null
+++ b/moodle/src/BRIEF_content_extraction.md
@@ -0,0 +1,108 @@
+# Brief: weekly Moodle content for AISE502 (Autumn Semester 2026)
+
+You extract the content of ONE lecture week into a JSON file. The JSON is later rendered into the
+Moodle course page (one section per week: learning objectives, theory summary, self-study and
+assignments). Students read this page before and after the lecture. Nothing in it may contradict
+the slides, the script or the project exercise sheet.
+
+## Audience, language, tone
+- Audience: BSc students, 5th semester, module AISE502 "AI in Software Engineering II" (lecturer Dr. Florian Herzog, FH Graubünden). Teaching in German, ALL materials in English.
+- Language: British English (organise, behaviour, catalogue). Plain text only: NO HTML, NO LaTeX, NO Markdown in the JSON strings.
+- Learning objectives: first person, the FHGR template style "I can ..." / "I know ...". Use "I can" with an action verb (explain, construct, derive, apply, run, defend, distinguish, read, name, judge) and "I know" for facts/vocabulary. One objective per bullet, at most 20 words.
+- Theory bullets: third person, declarative, at most 30 words each; they summarise what the lecture teaches. Use the exact vocabulary and numbering of the deck (assumptions A1–A6, maxims by number, R(a), C(p), fit(a,p), classes C1–C10, patterns L, MM, HX, MS, EDA, PF, SL, deliverables A1–A3, milestones M1–M6). Named systems, figures and numbers only if the deck states them.
+- Project bullets: imperative, addressed to the team ("Finalise ...", "Run ...").
+
+## LaTeX -> plain text conversion (mandatory)
+- `--` -> en dash "–" (with the spaces the source has); `---` -> "–" as well
+- `$R(a)$` -> R(a); `$C(p)$` -> C(p); `$\mathrm{fit}(a,p)$` -> fit(a,p); `$K(a)$` -> K(a)
+- `$\to$`, `$\rightarrow$` -> "→"; `$\times$` -> "×"; `\geq` -> "≥"; `\leq` -> "≤"; `\%` -> "%"; `\,` -> " " (or nothing inside numbers: "95 %", "20 s")
+- `\textbf{x}`, `\emph{x}`, `\texttt{x}`, `\textcolor{..}{x}` -> x (plain)
+- ``quotes'' -> “quotes”; `\dots` -> "…"; `\&` -> "&"
+- Remove every remaining backslash command. Check with: grep for a backslash in your output – there must be none.
+
+## Output: one JSON object, written to the path given in your task
+```
+{
+  "week": 7,                       // integer 1..14
+  "lecture": 7,                    // integer, same as week
+  "phase": "design",               // "design" (weeks 1–7), "implementation" (8–13), "presentation" (14)
+  "lessons": "2 lessons lecture + 2 lessons exercise",   // weeks 1–7; weeks 8–13: "3 lessons lecture + 1 lesson standup/coaching"; week 14: "1 lesson synthesis + 3 lessons presentations and defence"
+  "section_title": "Week 7: The Fit, Formally – Three Cases, the Procedure, the Matrix",   // "Week N: " + the deck subtitle's main title (text before the script line), at most 90 characters; shorten sensibly if longer
+  "deck_subtitle": "Lecture 7: The Fit, Formally – Three Cases, the Procedure, the Matrix",  // converted to plain text
+  "one_liner": "one sentence (≤ 30 words) saying what this lecture does, for the top of the theory block",
+  "script_sections": [30, 31, 32, 34, 37],   // integers: the script sections this lecture covers (the renderer adds part and titles). Week 14: []
+  "script_note": "Section 37: introduction only",   // optional; "" if none. Use it for partial sections, e.g. "Section 42: subsections 42.1–42.5 only"
+  "objectives": ["I can ...", "I know ..."],   // 5–10 items (2-lesson decks 6–8, 3-lesson decks 8–10, week 14: 5–6)
+  "theory": ["...", "..."],                    // 5–10 items, same scaling; in the order of the deck's sections; include the lecture's maxim(s) if the deck states one
+  "preparation": ["..."],                      // 0–3 items to do BEFORE the lecture, taken from the PREVIOUS deck's "Next week" frame (reading is added automatically – do NOT repeat "read Sections ..."); e.g. "Bring the raw stakeholder wishes collected in week 1". Week 1: []
+  "exercise_session": "one sentence: what happens in this week's exercise slot (2 lessons in weeks 1–7, 1-lesson standup/coaching in weeks 8–13, presentations in week 14)",
+  "project_work": ["...", "..."],             // 2–5 imperative bullets for THIS week from the exercise sheet's semester table row + milestone box + the deck's exercise frame ("This week's exercise"/"The course project")
+  "milestone": "M2 – Architecture Decision and Solution Design (weeks 4–7)",   // exactly one of the six milestone strings listed below
+  "deliverable": "Deliverable A2 (end of week 7): architecture dossier + design-review gate",   // or null when nothing is due this week
+  "sources": ["Folien/AISE502_Vorlesung_7_Folien.tex: frames Agenda, Summary, This week's exercise, Next week", "project_exercise/project_exercise.tex: M2 box"]
+}
+```
+Validate the file with `python3 -c "import json;json.load(open('<path>'))"` before you finish, and grep it for a backslash.
+
+## Sourcing rules
+1. PRIMARY source: the lecture deck `Folien/AISE502_Vorlesung_N_Folien.tex`. Read it completely. The "Agenda", the section headers, the "Summary" frame and the exercise/"Next week" frames carry the structure; the content frames carry the claims.
+2. For weeks 7–13 also read the plan `Folien/Planung_7-13_json/LN.json` (keys agenda, recap, summary, exercise_frame, next_week) – it is consistent with the deck and gives the script line ranges.
+3. For preparation items read the "Next week" frame of the PREVIOUS deck (weeks 2–14).
+4. Project work: the reference data below (copied verbatim from the exercise sheet) is normative. Add deck-specific detail only from the deck's own exercise frame.
+5. Never invent: no new examples, no new numbers, no new tool names. If the deck is silent, leave it out.
+6. The six module learning objectives (below) are the frame; the weekly objectives are more specific than these and must be achievable with this week's content.
+
+## Reference data (verbatim from project_exercise/project_exercise.tex, Section 6)
+Semester table – Week | Lecture (script) | Project work:
+1  | Part I: decision problem, framework | Kickoff: teams, tooling, domain model, ontology draft
+2  | Part I: twelve dimensions; scenarios, utility tree | Quality attribute scenarios with response measures
+3  | Part I: capability profiles, fit, mini-match, ADR | R(platform) finalised → Deliverable A1
+4  | Part II: layered, modular monolith, hexagonal | Architecture study I (Fineract, Cosmic Python)
+5  | Part II: microservices, event-driven | Architecture study II: edges, contracts, resilience
+6  | Part II: pipes-and-filters, serverless; stepping back; class C10 | The match: three stages, decision, ADR draft
+7  | Part IV: three cases, procedure, matrix; measurement contract | Solution design, design-review gate → Deliverable A2
+8  | Part III: classes C1–C5 | Walking skeleton (start)
+9  | Part III: classes C6–C9 | Walking skeleton runs end-to-end
+10 | Part IV: hybrids, evolution, eight-step procedure | Deterministic services + exact tests
+11 | Part IV: measurement contract in depth (fitness functions, DORA) | Resilience complete; core fully tested
+12 | Part V: Axis A; Axis B (gateway, eval basics) | Advisor + sub-agents behind the gateway
+13 | Part V: Axis B (security, orchestration economics) | Eval harness in CI; hardening; distinction work
+14 | Synthesis (1 lesson) | Presentations, architecture defence, peer reviews (A3)
+
+Phases: weeks 1–7 design phase (2 lessons lecture + 2 lessons exercise); weeks 8–13 implementation phase (3 lessons lecture + 1 lesson standup/coaching; implementation mainly in self-study); week 14: 1 lesson synthesis + 3 lessons presentations.
+
+Milestone strings (use exactly):
+- "M1 – Requirements and Ontology (weeks 1–3)" – deliverable A1 end of week 3
+- "M2 – Architecture Decision and Solution Design (weeks 4–7)" – deliverable A2 end of week 7
+- "M3 – Walking Skeleton (weeks 8–9)" – check week 9: skeleton runs end-to-end
+- "M4 – Deterministic Core and Resilience (weeks 10–11)" – check end of week 11
+- "M5 – Multi-Agent Orchestration, Evaluation, and Hardening (weeks 12–13)" – check end of week 13
+- "M6 – Presentation and Architecture Defence (week 14)" – deliverable A3
+
+Milestone boxes:
+M1: Domain model and ontology of the investment domain. Quality attribute scenarios with response measures (at least eight scenarios, at least three of them for the AI components: answer correctness, token cost per request, provider migration – Lecture 2); utility tree; the requirements profile R(platform) with weights, workload shape, and hard constraints. Project and tooling setup (repository, environment, agentic dev tools). Deliverable A1 (end of week 3): requirements dossier.
+M2: Study the open-source reference systems from the lecture; evaluate candidate architectures for the deterministic core and the edges. Run the three-stage match (knock-out and shape gate; veto with documented mitigations; ordinal reading); record the decision as an ADR with rationale; C4-style diagram. Bounded contexts → service decomposition and contracts; measurement contract (token budget, eval threshold, module-boundary checks); walking-skeleton plan. Set numbers in the contract (reference values from Lectures 3 and 11: eval pass rate ≥ 95 % on a versioned golden set, p95 latency ≤ 20 s for the advisory scenario, a token-cost budget per request at p95, zero module-boundary violations). Deliverable A2 (end of week 7): architecture dossier + design-review gate. Production code starts only after the gate (exploratory spikes are allowed).
+M3: End-to-end thin slice running: MarketDataService delivers prices and a minimal ResearchAgent produces one validated Insight. Stable API and a placeholder UI that calls it.
+M4: Performance, Risk, Optimization services implemented and fully tested against the reference vectors. Resilience patterns on all external calls; graceful degradation verified.
+M5: Week 12: advisor orchestrates 2–3 sub-agents through contracts, every LLM call through the gateway (mandatory); ontology guard active on all insights. Week 13: evaluation harness as a CI gate; report accuracy and failure modes; observability of token cost and latency per request; an ADR that justifies the chosen orchestration topology (task-signature table, Lecture 13) with its token budget and eval threshold. Threat model including prompt injection via news; basic hardening; scaling/optimisation (caching, batching). Optional distinction work: autonomy, self-repair, model routing, CI/CD, tracing.
+M6: Present the system and defend your architectural trade-offs. Reflect on where AI helped and where it hurt – in building (A) and in the system (B). Peer reviews: each team reviews the other teams' presentations and defences. Be prepared to show one measurement-contract violation being caught by CI (Lecture 11).
+
+Assessment: project 50 % (A1, A2, implementation, final presentation with architecture defence); written examination 50 % (end of semester, 60 minutes, open book: script and own notes on paper, closed internet; focus: architecture reasoning – profiles, matching, trade-offs; in English).
+
+## The six module learning objectives (deck 1, "Learning objectives")
+1. explain why architecture selection is a matching problem – no pattern is good or bad in itself
+2. construct a requirements profile R(a): scenarios with response measures, utility tree, weights
+3. derive the capability profile C(p) of seven architectural patterns from their tactics
+4. run the three-stage, non-compensatory match and defend the result
+5. record decisions as ADRs and attach a measurement contract (fitness functions, DORA)
+6. engineer AI components into a system (Axis B) and use AI tools in the process (Axis A) – with the same discipline
+
+## Script sections (numbers and titles, from the compiled table of contents)
+Part I – Architecture as a Decision Problem: 1 The Decision Problem; 2 The Coordinate System: Twelve Profile Dimensions; 3 Constructing the Demand Side: The Requirements Profile R(a); 4 Constructing the Supply Side: The Capability Profile C(p); 5 The Match: fit(a,p); 6 Recording and Testing the Decision; 7 Summary: The Red Line
+Part II – Capability Profiles: The Seven Architectural Patterns: 8 L – Layered Architecture / 3-Tier; 9 MM – Modular Monolith; 10 HX – Hexagonal Architecture / Ports and Adapters; 11 MS – Microservices; 12 EDA – Event-Driven Architecture; 13 PF – Pipes-and-Filters / Batch Pipeline; 14 SL – Serverless / FaaS; 15 Stepping Back: What Seven Patterns Generalise To; 16 Reading the Catalogue as a Whole; 17 Outlook: Agent Orchestration as an Emergent Composition Pattern
+Part III – Requirements Profiles: The Ten Application Classes: 18 Application Classes as Requirements Profiles; 19 C1 – Core Banking / Transaction Systems; 20 C2 – Social Media / Content Platforms; 21 C3 – Back-Office / Workflow Applications; 22 C4 – ERP / Enterprise Core Systems; 23 C5 – E-Commerce Platforms; 24 C6 – Scientific Simulation / Batch Compute; 25 C7 – Decision Support / BI Analytics; 26 C8 – Real-Time / IoT Streaming; 27 C9 – Collaboration / Messaging; 28 C10 – AI-Native Advisory Platforms; 29 Stepping Back: Ten Profiles Side by Side
+Part IV – The Fit: Matching, Decision Procedure, and Measurement: 30 Three Matches, Three Stages; 31 The Procedure in General; 32 The Matching Matrix; 33 Cell Rationales: The Ten Rows in Detail; 34 Reading the Matrix as a Whole; 35 Hybrids and Evolution Paths; 36 The Decision Procedure; 37 The Measurement Contract; 38 The Third Fit Dimension: Conway's Law and Team Topologies; 39 Limits of the Theory – Applied to Itself
+Part V – The AI Dimension: Tool and Component: 40 Two Axes, One Method; 41 Axis A: AI as a Tool Shifts the Economics of the SDLC; 42 Axis B: AI as a Runtime Component; 43 How AI Shifts the Matrix; 44 Agent Orchestration: The Emergent Eighth Pattern; 45 Synthesis: One Theory, Five Parts
+
+Deck subtitles (script lines) for orientation – verify against the deck itself:
+L1 Part I §1–2 | L2 Part I §2–3 | L3 Part I §4–6 | L4 Part II L/MM/HX (§8–10) | L5 Part II MS/EDA (§11–12) | L6 Part II PF/SL + closing (§13–17) and Part III C10 (§28) | L7 Part IV §30–32, 34, §37 introduction | L8 Part III §18–23 | L9 Part III §24–27, 29 | L10 Part IV §35–36 and 33 | L11 Part IV §37–39 | L12 Part V §40–41, §42.1–42.5 | L13 Part V §42.6–42.7, §43–45 | L14 synthesis of Parts I–V, no new material; project sheet M6