From 3b7bcb23db219196b74abe346177df3d7e709b56 Mon Sep 17 00:00:00 2001 From: Obsidian-MBPM4 Date: Thu, 23 Apr 2026 20:23:23 +0200 Subject: [PATCH] vault backup: 2026-04-23 20:23:23 Affected files: .obsidian/bookmarks.json .obsidian/workspace.json 99 Work/Teaching/TEP - Schulung/CAPSA SUITE proposal deep-dive.md --- .obsidian/bookmarks.json | 9 + .obsidian/workspace.json | 63 +- .../CAPSA SUITE proposal deep-dive.md | 770 ++++++++++++++++++ 3 files changed, 834 insertions(+), 8 deletions(-) create mode 100644 .obsidian/bookmarks.json create mode 100644 99 Work/Teaching/TEP - Schulung/CAPSA SUITE proposal deep-dive.md diff --git a/.obsidian/bookmarks.json b/.obsidian/bookmarks.json new file mode 100644 index 0000000..1e1cc1d --- /dev/null +++ b/.obsidian/bookmarks.json @@ -0,0 +1,9 @@ +{ + "items": [ + { + "type": "folder", + "ctime": 1776967124634, + "path": "99 Work/Teaching/TEP - Schulung" + } + ] +} \ No newline at end of file diff --git a/.obsidian/workspace.json b/.obsidian/workspace.json index a1e1062..77dfeda 100644 --- a/.obsidian/workspace.json +++ b/.obsidian/workspace.json @@ -174,9 +174,23 @@ "icon": "lucide-file", "title": "Home Assistant" } + }, + { + "id": "044a18f2d2633450", + "type": "leaf", + "state": { + "type": "markdown", + "state": { + "file": "99 Work/Teaching/TEP - Schulung/CAPSA SUITE proposal deep-dive.md", + "mode": "source", + "source": false + }, + "icon": "lucide-file", + "title": "CAPSA SUITE proposal deep-dive" + } } ], - "currentTab": 11 + "currentTab": 12 } ], "direction": "vertical" @@ -195,7 +209,7 @@ "state": { "type": "file-explorer", "state": { - "sortOrder": "alphabetical", + "sortOrder": "byModifiedTime", "autoReveal": true }, "icon": "lucide-folder-closed", @@ -481,16 +495,53 @@ ], "direction": "vertical", "x": 0, - "y": 42, + "y": 34, "width": 900, "height": 777, "maximize": false, "zoom": 0 + }, + { + "id": "f1b9d015e6bf9f80", + "type": "window", + "children": [ + { + "id": "ead9296ecab7eab5", + "type": "tabs", + "children": [ + { + "id": "a24c733c4981be03", + "type": "leaf", + "state": { + "type": "markdown", + "state": { + "file": "99 Work/Teaching/TEP - Schulung/CAPSA SUITE proposal deep-dive.md", + "mode": "source", + "source": false + }, + "icon": "lucide-file", + "title": "CAPSA SUITE proposal deep-dive" + } + } + ] + } + ], + "direction": "vertical", + "x": 658, + "y": -1860, + "width": 1680, + "height": 1860, + "maximize": false, + "zoom": 0 } ] }, - "active": "fac43a56fe618e9d", + "active": "a24c733c4981be03", "lastOpenFiles": [ + "99 Work/Teaching/TEP - Schulung/CAPSA SUITE proposal deep-dive.md", + "99 Work/Teaching/TEP - Schulung/CAPSA SUITE proposal deep-dive.md", + "99 Work/Teaching/TEP - Schulung", + "99 Work/Teaching", "2 Personal/Home Lab/Backup System - Kopia Server Setup.md", "2 Personal/1 Skills/Obisdian/Obsidian Setup.md", "2 Personal/Projects/AlpineView/Thoughts.md", @@ -517,8 +568,6 @@ "2 Personal/Home Lab/NAS/Photo Apps.md", "2 Personal/Home Lab/MAC/Software Management on MacOS.md", "Dashboard Canvas.canvas", - "Dashboard.md", - "8 Places/BusinessesDrawing 2023-10-12 16.01.52.excalidraw.md", "Attachments/ESPSomfyRTS 2026-03-17T16_05_06.backup", "Attachments/Pasted image 20260121121234.png", "Attachments/ESPSomfyRTS 2026-01-18T16_26_16.backup", @@ -534,8 +583,6 @@ "Attachments/Pasted image 20251015111504.png", "Attachments/Pasted image 20251015092212.png", "3 Knowledge/5 AI/PromptDB", - "3 Knowledge/5 AI", - "99 Work/0 OneSec/OneSecNotes/10 Projects/TeensyFlightcontroller", "Attachments/Pasted image 20250922115441.png", "Attachments/image 21.jpg", "99 Work/0 OneSec/OneSecNotes/30 Engineering Skills/Computer Science/Untitled.canvas", diff --git a/99 Work/Teaching/TEP - Schulung/CAPSA SUITE proposal deep-dive.md b/99 Work/Teaching/TEP - Schulung/CAPSA SUITE proposal deep-dive.md new file mode 100644 index 0000000..3b98dc3 --- /dev/null +++ b/99 Work/Teaching/TEP - Schulung/CAPSA SUITE proposal deep-dive.md @@ -0,0 +1,770 @@ +# CAPSA SUITE proposal deep-dive + +## Purpose of this note + +This note turns the 70-page CAPSA SUITE proposal into a structured briefing you can use before your visit. It focuses on: + +1. what the proposal is really trying to build +2. how the business and technical pieces fit together +3. where the project is strong, weak, risky, and AI-relevant +4. how you can position a **5 x 1h course** on AI tools, software engineering, and operations in a way that fits their actual needs + +**Source:** CAPSA SUITE submitted proposal. Key themes and structure are taken from the uploaded proposal. See the original file for full detail. + +--- + +## Executive summary + +CAPSA SUITE is a proposal to build a modular software platform for **building decarbonization planning**. The core idea is to replace a slow, manual, consultant-heavy workflow with a more automated pipeline that: + +- collects building data through a mobile app +- enriches it with public, private, and inferred data +- stores it in a **Digital Building Passport (DBP)** +- generates **Decarbonization and Retrofit Roadmaps (DRR)** +- estimates **whole-life carbon / scopes 1-3** +- supports implementation tracking and reporting + +The proposal is really about **productizing expert consulting know-how**. ChillServices contributes software, app, and digital building passport capabilities. TEP contributes energy system, GIS, building stock modelling, techno-economic, carbon, and policy expertise. + +The strongest insight in the proposal is this: + +> decarbonization at scale is less blocked by lack of ideas and more blocked by fragmented data, inconsistent workflows, limited labor, and poor integration. + +That is exactly where good AI tooling and good software practices can help. + +--- + + +## Added context from TEP's public product pages + +These two TEP pages are useful because they make the proposal less abstract. They show how TEP presents the product and one of its key enabling toolchains publicly: + +- **CAPSA App und CAPSA Suite**: positioned as a solution for real estate companies, owners, managers, investors, and banks; emphasizes a combination of app, secure database, and insights portal; highlights a central digital data base, automated derivations/models, portfolio-level strategy tools, and integration of technical and economic aspects. +- **Räumliche Energie Analyse Toolbox (REAT)**: positioned as a spatial energy planning toolbox for municipalities, cities, cantons, regions, and utilities; focuses on heat planning, local energy potentials, restrictions, and infrastructure questions such as district heating, heat pumps, geothermal constraints, noise, water protection, and thermal networks. + +That public framing matches the proposal very well: + +- **CAPSA page** = the client-facing product and workflow layer +- **REAT page** = an important spatial/context intelligence layer feeding planning decisions +- **Proposal** = the attempt to integrate these layers with data completion, DRR generation, and whole-life carbon logic into one system + +### How the public pages fit the proposal + +```mermaid +flowchart LR + A[CAPSA public page +app + secure database + insights portal] --> B[Digital Building Passport / workflow layer] + C[REAT public page +spatial energy analysis and local heat planning] --> D[Spatial context and infrastructure intelligence] + B --> E[Integrated CAPSA SUITE vision in proposal] + D --> E + E --> F[Automated DRR + whole-life carbon + monitoring] +``` + +### Why this matters for your visit + +This suggests TEP already thinks in terms of **tools and reusable solution building blocks**, not just classic consulting outputs. That is good news for your course idea. It means a course on AI and software practices can be framed as: + +- improving how these toolchains are built and maintained +- accelerating how domain knowledge becomes reliable product logic +- making consulting-heavy workflows more repeatable and scalable + +### Useful interpretation + +The proposal talks a lot about **SEAT** as the spatial module. The current TEP public page calls the relevant toolbox **REAT**. For your visit, treat them as part of the same conceptual family: a spatial energy analysis / planning capability that informs feasibility and local infrastructure choices. + + +## 1. Big-picture mental model + +### CAPSA in one sentence + +CAPSA SUITE is an attempt to industrialize building decarbonization planning for real estate portfolios. + +### The whole system at a glance + +```mermaid +flowchart LR + A[On-site building data collection\nmobile app, photos, guided input] --> B[Data completion and validation\npublic data, internal data, ML/statistical imputation] + B --> C[Digital Building Passport\ncentral repository and UI] + C --> D[DRR generation\ndecarbonization and retrofit roadmaps] + C --> E[Whole-life carbon estimation\nScopes 1-3] + D --> F[Investment packages\nfinance-ready planning] + E --> F + F --> G[Monitoring and reporting\nstatus, progress, carbon, costs] +``` + +This is the central logic of the proposal. The app is only the front door. The real value is in the connected system behind it. fileciteturn0file0L72-L96 fileciteturn0file0L400-L447 + +--- + +## 2. The problem they are trying to solve + +The proposal argues that the current market for building decarbonization planning is broken in five ways: + +1. **manual data collection** is slow and expensive +2. **building data is incomplete and scattered** +3. **results depend too much on the individual expert** +4. **there are not enough qualified people** to scale the work +5. **owners of large portfolios** need consistent, comparable roadmaps, not ad-hoc reports fileciteturn0file0L99-L118 + +### Current pain points + +```mermaid +flowchart TD + A[Building owner needs decarbonization plan] --> B[Manual site visit] + B --> C[Paper notes / fragmented records / missing data] + C --> D[Expert interpretation and guesswork] + D --> E[Manual calculations across multiple tools] + E --> F[Static report] + F --> G[Limited reuse, weak monitoring, poor scaling] +``` + +### CAPSA's intended replacement + +```mermaid +flowchart TD + A[Building owner needs decarbonization plan] --> B[Structured mobile data capture] + B --> C[Automated completion and validation] + C --> D[Central Digital Building Passport] + D --> E[Automated DRR and carbon outputs] + E --> F[Monitoring, updates, portfolio comparison] + F --> G[Scalable, lower-cost, more consistent process] +``` + +This process shift is the heart of the proposal. They repeatedly describe it as a **process innovation**, not just a software feature set. fileciteturn0file0L187-L207 fileciteturn0file0L214-L244 + +--- + +## 3. The product stack in detail + +The proposal has five core building blocks. + +### 3.1 Mobile data gathering module + +The mobile app is meant to let non-experts or semi-experts collect data during regular site visits using guided flows, photos, and image recognition. fileciteturn0file0L358-L389 + +**What it is supposed to do** +- capture building and equipment data on site +- use image recognition for type plates, facades, windows, etc. +- reduce dependence on skilled auditors +- fit into real workflows of caretakers and service staff + +**What matters strategically** +This is where AI becomes visible to the user. If the app is painful, the entire system collapses because all downstream outputs depend on upstream data quality. + +### 3.2 Data completion and verification + +The proposal assumes raw building data will almost always be incomplete, so it adds a second layer that fills gaps using: + +- public registries +- GIS / 3D city data +- smart meter or other internal data +- synthetic building stock methods +- statistical and ML-based imputation fileciteturn0file0L390-L421 + +**Important:** this is not a nice-to-have. It is the real differentiator. Without it, CAPSA would just be another audit app. + +### 3.3 Digital Building Passport + +The DBP is the central data model and user-facing repository. It stores, structures, synchronizes, and exposes building information. It also manages access and standard exports. fileciteturn0file0L422-L447 + +### 3.4 DRR generation module + +The DRR module is meant to generate building-specific retrofit and decarbonization pathways based on rule-based logic, context data, lifecycle logic, and cost/carbon tradeoffs. fileciteturn0file0L458-L477 + +### 3.5 Whole-life carbon and monitoring + +CAPSA also wants to include embodied emissions and scope 3, then track progress after measures are planned or completed. This makes the platform more relevant for ESG, CSRD, and finance-linked use cases. fileciteturn0file0L448-L456 fileciteturn0file0L478-L487 + +--- + +## 4. Work package map + +The proposal is organized into four work packages over 30 months, with total project cost of about EUR 1.86M. fileciteturn0file0L32-L34 fileciteturn0file0L320-L327 + +```mermaid +gantt + title CAPSA SUITE high-level timeline + dateFormat X + axisFormat %s + + section WP1 Project management and product design + WP1 active :a1, 0, 30 + + section WP2 Data collection and completion + WP2 active :a2, 0, 30 + App alpha / beta :milestone, m1, 12, 0 + App beta maturity :milestone, m2, 24, 0 + DBP alpha :milestone, m3, 16, 0 + DBP beta :milestone, m4, 30, 0 + + section WP3 DRR and carbon functionality + WP3 active :a3, 6, 24 + TED Switzerland :milestone, m5, 12, 0 + DRR alpha :milestone, m6, 12, 0 + TED Germany :milestone, m7, 18, 0 + DRR beta :milestone, m8, 20, 0 + Monitoring :milestone, m9, 24, 0 + + section WP4 Customer-led implementation + WP4 active :a4, 0, 30 + Engage first 10 clients :milestone, m10, 6, 0 + Start whole-life carbon pilots :milestone, m11, 12, 0 + Start Swiss anchor app pilot :milestone, m12, 9, 0 + Bring SEAT to market :milestone, m13, 15, 0 + DRR pilots :milestone, m14, 20, 0 +``` + +This timeline is approximate and simplified from the work package and milestone sections. fileciteturn0file0L330-L355 fileciteturn0file0L366-L377 fileciteturn0file0L431-L438 fileciteturn0file0L498-L506 + +### Budget split by work package + +```mermaid +pie showData + title Total project cost by work package (EUR) + "WP1 Management and design" : 189522 + "WP2 Data collection and completion" : 710598 + "WP3 DRR generation and evaluation" : 636290 + "WP4 Market-oriented implementation" : 323132 +``` + +This shows where the effort sits: mostly in data/integration and DRR logic, not in generic project management. fileciteturn0file0L320-L327 + +--- + +## 5. Who does what: ChillServices vs TEP + +```mermaid +flowchart LR + A[ChillServices] --> A1[Mobile app] + A --> A2[Frontend and backend] + A --> A3[Digital Building Passport] + A --> A4[Commercial software delivery] + A --> A5[Project coordination] + + B[TEP Energy] --> B1[Spatial energy analysis / GIS] + B --> B2[Building stock modelling] + B --> B3[Techno-economic database] + B --> B4[DRR logic and evaluation] + B --> B5[Whole-life carbon and policy/market context] +``` + +### Clean interpretation + +- **ChillServices** is the software/product delivery side. +- **TEP** is the domain intelligence and modelling side. + +That is why TEP is interesting for your visit: they likely have deep expertise but may still operate with many consulting-style, research-style, and semi-manual processes that could benefit hugely from better AI-enabled workflows. + +This division of labor is described throughout the consortium and task sections. fileciteturn0file0L555-L593 fileciteturn0file0L642-L666 + +--- + +## 6. What is actually innovative vs what is mostly integration + +This is important because it tells you where to challenge them and where to help them. + +### Truly valuable innovations + +1. **Structured mobile data collection for decarbonization use cases** +2. **Gap filling via external, statistical, and model-based methods** +3. **Context-aware roadmap generation**, not just generic retrofit suggestions +4. **Linking scope 3 / whole-life carbon to retrofit planning** +5. **Turning consulting workflows into a reusable digital process** fileciteturn0file0L145-L177 fileciteturn0file0L200-L244 + +### Less novel than they imply + +1. APIs and database integration +2. standard product management and pilot loops +3. dashboards and exports +4. mobile + backend architecture in itself + +### Honest assessment + +The main novelty is not that each module is unprecedented. The novelty is that they are trying to **stitch together a coherent decision-making and execution system** for building decarbonization. + +That means their main risk is not idea risk. It is **execution risk, data quality risk, and productization risk**. + +--- + +## 7. The real business model + +The proposal mixes two business models. + +```mermaid +flowchart TD + A[CAPSA SUITE] --> B[Service-led revenue] + A --> C[Software / license-led revenue] + + B --> B1[manual + semi-automated consulting projects] + B --> B2[roadmaps for portfolios] + B --> B3[data and analysis services] + + C --> C1[subscription per building or unit] + C --> C2[module licensing to partners] + C --> C3[integration into partner ERP / platforms] +``` + +### Practical interpretation + +They are not yet a pure product company. They are moving from: + +**consulting and project work -> software-enabled services -> increasingly licensable modules** + +That matters for your visit because the internal culture and engineering approach may still feel closer to: + +- project delivery +- research and modelling +- custom client work +- prototype evolution + +rather than: + +- platform product engineering +- SRE / DevOps maturity +- disciplined release engineering +- strong internal developer platform standards + +--- + +## 8. The strongest and weakest parts of the proposal + +### Strongest parts + +#### Strong point 1: It starts from a real bottleneck +The proposal correctly identifies that building decarbonization at scale is constrained by data fragmentation and labor intensity. fileciteturn0file0L99-L118 + +#### Strong point 2: It builds on existing assets +This is not zero-to-one fantasy. They already have app, DBP, SEAT, and building stock model components. fileciteturn0file0L119-L143 + +#### Strong point 3: It has plausible commercial channels +Hypoport, Viessmann/Carrier, housing associations, and existing clients make the go-to-market story more credible than typical grant proposals. fileciteturn0file0L160-L173 + +#### Strong point 4: It understands finance and policy pressure +The proposal is grounded in regulation, sustainability reporting, and financing use cases, not just engineering enthusiasm. fileciteturn0file0L144-L159 fileciteturn0file0L488-L497 + +### Weakest parts + +#### Weak point 1: It is over-ambitious +There are too many moving parts for 30 months and two SMEs. + +#### Weak point 2: Data quality remains the Achilles heel +All outputs depend on incomplete and heterogeneous inputs. The proposal acknowledges this but still sounds optimistic. + +#### Weak point 3: User trust may be harder than model accuracy +Even decent outputs can fail if users do not trust inferred data or rule-generated roadmaps. + +#### Weak point 4: Productization is harder than consulting +Turning expert tacit knowledge into maintainable code, traceable logic, and reliable APIs is a very different discipline. + +#### Weak point 5: Partner dependency is high +Commercial success depends a lot on external distribution and integration partners. + +--- + +## 9. Where AI can create real leverage for them + +This is probably the most useful section for your visit. + +There are many possible AI use cases, but not all are equally valuable. The high-value ones are where AI reduces friction in **development**, **operations**, **knowledge work**, or **data-heavy workflows**. + +### 9.1 AI opportunities inside the product + +```mermaid +flowchart TD + A[Product AI opportunities] --> B[Image-assisted site data capture] + A --> C[Document extraction and normalization] + A --> D[Data validation and anomaly detection] + A --> E[Assisted missing-data inference explanations] + A --> F[Natural-language summary for management reports] + A --> G[Support assistant inside DBP] +``` + +#### Highest-value product AI candidates + +1. **Photo-assisted field capture** + - detect type plates + - identify heating systems / windows / facade types + - propose structured entries from images + +2. **Document ingestion** + - pull data from EPCs, PDFs, invoices, maintenance reports, permits + - normalize to DBP schema + +3. **Quality control assistant** + - flag inconsistent values + - detect suspicious combinations + - surface missing critical inputs before DRR generation + +4. **Explainability layer** + - if data was inferred, explain from what sources and with what confidence + - this is essential for trust + +5. **Report drafting** + - generate client-friendly summaries, management notes, and comparison text + +### 9.2 AI opportunities in software development + +This is likely even more relevant for your course. + +```mermaid +flowchart LR + A[Developer workflow pain] --> B[AI coding assistants] + A --> C[Test generation] + A --> D[Refactoring and code comprehension] + A --> E[API and schema documentation] + A --> F[SQL / ETL / transformation help] + A --> G[Infra and CI/CD assistance] +``` + +#### Very practical targets + +- speeding up backend boilerplate and integration code +- generating and improving unit/integration tests +- documenting APIs and data contracts +- helping with schema mapping and ETL logic +- debugging Docker, CI, and deployment problems +- accelerating GIS/data pipeline scripting +- improving developer onboarding + +### 9.3 AI opportunities in operations and internal knowledge work + +#### Internal knowledge base / RAG +They likely have knowledge scattered across: +- proposals +- methods +- reports +- partner docs +- public datasets +- policy documents +- code comments +- spreadsheets + +A strong internal knowledge assistant could answer: +- what assumptions exist in the DRR engine +- where a cost coefficient comes from +- which German or Swiss data source feeds a module +- what changed between client versions +- how a model should be interpreted + +#### Meeting and project ops +AI can help with: +- meeting summaries +- action extraction +- issue creation +- technical decision logs +- stakeholder update drafts +- synthesis of pilot feedback + +#### DevOps and reliability +AI can help teams write and maintain: +- Dockerfiles +- CI pipelines +- Terraform / deployment config +- observability dashboards +- incident runbooks +- migration scripts + +--- + +## 10. What good software practices they likely need most + +Your value is probably not teaching generic “AI is cool.” It is showing how AI becomes useful **inside a disciplined engineering workflow**. + +### The likely maturity gaps + +Based on the proposal, they probably face some mix of the following: + +1. knowledge in people’s heads instead of systems +2. evolving prototypes without strong contracts or architecture boundaries +3. data models and assumptions spread across code, reports, and spreadsheets +4. limited automated tests around domain logic +5. custom client work making the product harder to standardize +6. unclear traceability from business rules to implementation +7. limited operational visibility once modules are deployed + +### The software practices most relevant to them + +```mermaid +mindmap + root((Good practices for CAPSA-like teams)) + Architecture + clear module boundaries + API contracts + ownership per service + Data + schema versioning + lineage + assumptions marked explicitly + auditability + Quality + unit tests for rule logic + integration tests for data flows + golden datasets + regression testing + Operations + CI/CD + observability + error budgets + runbooks + Product process + design docs + decision logs + user feedback loops + release notes + AI use + human in the loop + reproducibility + traceability + secure usage policies +``` + +### Especially important for this product + +#### A. Data lineage and explainability +Because CAPSA mixes measured, reported, inferred, and synthetic data, they need extremely clear provenance. + +#### B. Rule testing and regression protection +A DRR engine is only useful if changes do not silently break decision logic. + +#### C. Strong interface contracts +Mobile app, DBP, SEAT, TED, and DRR modules should not drift semantically. + +#### D. Golden test cases +They should have representative buildings and portfolios where expected outputs are known and compared over time. + +#### E. Release discipline +If pilot clients are involved, sloppy release processes will quickly destroy trust. + +--- + +## 11. Suggested 5 x 1h course structure + +This is the course I would suggest based on their proposal and likely needs. + +### Overview + +```mermaid +flowchart LR + A[Session 1\nAI for engineers and analysts] --> B[Session 2\nAI in software development workflows] + B --> C[Session 3\nGood software architecture and testing] + C --> D[Session 4\nDevOps, operations, and observability] + D --> E[Session 5\nApplying it directly to CAPSA use cases] +``` + +## Session 1 — AI tools that actually save time + +**Goal:** demystify AI and show concrete productivity wins. + +**Topics** +- where AI helps and where it hurts +- using coding assistants, chat tools, and CLI agents safely +- prompting for engineering vs research vs documentation +- AI for synthesis of policy, technical, and market documents +- using AI to summarize meetings, proposals, client feedback + +**Hands-on examples for them** +- summarize a technical method paper into implementation tasks +- extract API requirements from a planning note +- generate a comparison of Swiss vs German data sources + +## Session 2 — AI-assisted development workflows + +**Goal:** make developers faster without destroying code quality. + +**Topics** +- how to use Claude Code / ChatGPT / Cursor / Copilot style tools well +- codebase navigation and comprehension +- test generation and refactoring +- writing migrations, ETL code, and API docs +- patterns for secure and reviewable AI usage + +**Hands-on examples for them** +- generate tests for a rule engine +- refactor a DBP schema mapper +- document a REST API from code + +## Session 3 — Software engineering discipline for modular platforms + +**Goal:** help them build a maintainable product instead of a pile of pilot features. + +**Topics** +- module boundaries and service ownership +- contracts and schemas +- design docs and decision records +- regression testing for domain logic +- golden datasets and validation harnesses + +**Hands-on examples for them** +- define interface contracts between DBP, TED, and DRR +- create a minimal testing strategy for building archetypes + +## Session 4 — DevOps, deployment, and reliability + +**Goal:** reduce operational pain and improve confidence. + +**Topics** +- Docker and reproducible environments +- CI/CD basics that matter +- structured logging and tracing +- health checks, alerts, dashboards +- secrets handling and environment management + +**Hands-on examples for them** +- what to log in a DRR generation pipeline +- how to monitor failures in data ingestion and image recognition +- how to deploy safely across staging and pilot environments + +## Session 5 — Workshop on CAPSA-specific opportunities + +**Goal:** make the training concrete and strategic. + +**Topics** +- map current workflow pain points +- identify 3 quick wins and 2 longer-term bets +- design an internal AI use policy +- agree on a tooling stack and rollout plan +- decide where product AI vs internal AI makes sense + +**Possible outputs of session 5** +- AI opportunity map +- engineering improvement roadmap +- coding assistant policy +- test strategy outline +- internal documentation / knowledge assistant pilot + +--- + +## 12. Recommended positioning for your visit + +You should not pitch yourself as “the AI guy.” + +Better positioning: + +> I can help you use AI and better engineering practices to reduce friction in development, improve reliability, and speed up the path from expert knowledge to robust software. + +That fits their actual challenge much better. + +### Suggested angle to emphasize + +#### 1. AI is an accelerator, not the product strategy +The product still lives or dies by workflow, data quality, and trust. + +#### 2. Good software practices are what make AI safe and useful +Without contracts, tests, and observability, AI speeds up the wrong things. + +#### 3. Their edge is domain expertise +AI should help them operationalize and multiply that edge, not replace it. + +#### 4. Start with internal leverage first +Before putting AI everywhere in the client-facing product, improve internal development, documentation, QA, and analysis workflows. + +--- + +## 13. Smart questions to ask during the visit + +### Product and workflow +- Where is the biggest bottleneck today: data capture, data cleaning, roadmap logic, or client delivery? +- Which part of CAPSA is already real product, and which part is still research/prototype? +- Where do users currently distrust the system the most? + +### Engineering +- How are interfaces between modules specified today? +- How do you test that DRR outputs remain correct over time? +- Do you have golden datasets or benchmark buildings? +- How do you trace where a number in the final roadmap came from? + +### Data and AI +- Which inputs are measured, user-entered, inferred, or synthetic? +- How do you explain inferred values to clients? +- Are there image/document extraction tasks where current manual effort is high? + +### DevOps / operations +- How do you manage environments across pilots and production? +- What is currently painful in deployment or integration? +- What do you monitor today when a pipeline breaks? + +### Team enablement +- Where do developers lose the most time? +- What kind of recurring documentation or reporting work is still manual? +- What would make a 5-session course clearly valuable for them? + +--- + +## 14. What I would prioritize if they want quick wins + +### Quick wins in 1-2 months + +1. **AI-assisted internal documentation and code comprehension** +2. **Test generation for critical logic and APIs** +3. **Meeting summaries and action extraction** +4. **Template-driven design docs and ADRs** +5. **Basic CI quality gates and lint/test enforcement** + +### Medium-term bets in 3-6 months + +1. **Internal knowledge assistant over proposals, methods, code, and datasets** +2. **Golden test dataset framework for DRR validation** +3. **Image/document extraction workflow for site and report data** +4. **Observability for data pipelines and model assumptions** + +### Longer-term product bets + +1. **Explainable inference assistant inside the DBP** +2. **AI-assisted field capture in the mobile app** +3. **Natural-language portfolio analysis and reporting layer** + +--- + +## 15. Final blunt assessment + +This proposal is strategically smart. It attacks a real pain point in the building transition and sits at the intersection of policy, economics, energy, and software. It also fits TEP very well because it turns their domain know-how into a repeatable digital capability. fileciteturn0file0L622-L666 + +But it is also very ambitious. The hard problem is not “can we build some features?” It is: + +- can we create a trustworthy system from messy real-world data +- can we encode expert judgment without making the system brittle +- can we keep the software maintainable as pilots and markets expand +- can we move from consulting habits to product discipline + +That is exactly where your contribution can matter. + +Your highest-value offer is likely: + +1. help them use AI to reduce day-to-day friction +2. help them adopt stronger engineering habits +3. help them avoid turning a strong concept into an unmaintainable stack + +--- + +## 16. Suggested one-line pitch for yourself + +> I can help your team use AI and better software practices to move faster, document less painfully, test more reliably, and make complex domain logic easier to build and operate. + +--- + + +## 17. Extra note on the official TEP pages + +The official TEP product pages sharpen the practical interpretation of the proposal: + +- The **CAPSA Suite** page presents CAPSA as an operational system that moves from data collection to centralized management to actionable strategy for portfolios. +- The **REAT** page presents TEP's spatial analysis capability as a planning engine for local heating supply, renewable potentials, restrictions, and thermal network opportunities. + +So in practical terms, the proposal is not just "let's build software". It is more like: + +```mermaid +flowchart TD + A[Field and document data] --> B[CAPSA workflow and DBP] + C[Spatial energy analysis +REAT / SEAT family] --> D[Feasibility and local options] + B --> E[DRR generation] + D --> E + E --> F[Portfolio strategy, finance, reporting, implementation] +``` + +That is exactly the kind of architecture where good AI tooling, good interface contracts, and good software practices matter a lot. + +## 18. Source reminder + +This briefing is based on the uploaded CAPSA SUITE proposal and summarizes its stated goals, structure, work packages, business case, and roles of ChillServices and TEP. Original file: fileciteturn0file0L1-L5