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
This commit is contained in:
9
.obsidian/bookmarks.json
vendored
Normal file
9
.obsidian/bookmarks.json
vendored
Normal file
@@ -0,0 +1,9 @@
|
|||||||
|
{
|
||||||
|
"items": [
|
||||||
|
{
|
||||||
|
"type": "folder",
|
||||||
|
"ctime": 1776967124634,
|
||||||
|
"path": "99 Work/Teaching/TEP - Schulung"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
63
.obsidian/workspace.json
vendored
63
.obsidian/workspace.json
vendored
@@ -174,9 +174,23 @@
|
|||||||
"icon": "lucide-file",
|
"icon": "lucide-file",
|
||||||
"title": "Home Assistant"
|
"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"
|
"direction": "vertical"
|
||||||
@@ -195,7 +209,7 @@
|
|||||||
"state": {
|
"state": {
|
||||||
"type": "file-explorer",
|
"type": "file-explorer",
|
||||||
"state": {
|
"state": {
|
||||||
"sortOrder": "alphabetical",
|
"sortOrder": "byModifiedTime",
|
||||||
"autoReveal": true
|
"autoReveal": true
|
||||||
},
|
},
|
||||||
"icon": "lucide-folder-closed",
|
"icon": "lucide-folder-closed",
|
||||||
@@ -481,16 +495,53 @@
|
|||||||
],
|
],
|
||||||
"direction": "vertical",
|
"direction": "vertical",
|
||||||
"x": 0,
|
"x": 0,
|
||||||
"y": 42,
|
"y": 34,
|
||||||
"width": 900,
|
"width": 900,
|
||||||
"height": 777,
|
"height": 777,
|
||||||
"maximize": false,
|
"maximize": false,
|
||||||
"zoom": 0
|
"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": [
|
"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/Home Lab/Backup System - Kopia Server Setup.md",
|
||||||
"2 Personal/1 Skills/Obisdian/Obsidian Setup.md",
|
"2 Personal/1 Skills/Obisdian/Obsidian Setup.md",
|
||||||
"2 Personal/Projects/AlpineView/Thoughts.md",
|
"2 Personal/Projects/AlpineView/Thoughts.md",
|
||||||
@@ -517,8 +568,6 @@
|
|||||||
"2 Personal/Home Lab/NAS/Photo Apps.md",
|
"2 Personal/Home Lab/NAS/Photo Apps.md",
|
||||||
"2 Personal/Home Lab/MAC/Software Management on MacOS.md",
|
"2 Personal/Home Lab/MAC/Software Management on MacOS.md",
|
||||||
"Dashboard Canvas.canvas",
|
"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/ESPSomfyRTS 2026-03-17T16_05_06.backup",
|
||||||
"Attachments/Pasted image 20260121121234.png",
|
"Attachments/Pasted image 20260121121234.png",
|
||||||
"Attachments/ESPSomfyRTS 2026-01-18T16_26_16.backup",
|
"Attachments/ESPSomfyRTS 2026-01-18T16_26_16.backup",
|
||||||
@@ -534,8 +583,6 @@
|
|||||||
"Attachments/Pasted image 20251015111504.png",
|
"Attachments/Pasted image 20251015111504.png",
|
||||||
"Attachments/Pasted image 20251015092212.png",
|
"Attachments/Pasted image 20251015092212.png",
|
||||||
"3 Knowledge/5 AI/PromptDB",
|
"3 Knowledge/5 AI/PromptDB",
|
||||||
"3 Knowledge/5 AI",
|
|
||||||
"99 Work/0 OneSec/OneSecNotes/10 Projects/TeensyFlightcontroller",
|
|
||||||
"Attachments/Pasted image 20250922115441.png",
|
"Attachments/Pasted image 20250922115441.png",
|
||||||
"Attachments/image 21.jpg",
|
"Attachments/image 21.jpg",
|
||||||
"99 Work/0 OneSec/OneSecNotes/30 Engineering Skills/Computer Science/Untitled.canvas",
|
"99 Work/0 OneSec/OneSecNotes/30 Engineering Skills/Computer Science/Untitled.canvas",
|
||||||
|
|||||||
@@ -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. fileciteturn0file0L72-L96 fileciteturn0file0L400-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 fileciteturn0file0L99-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. fileciteturn0file0L187-L207 fileciteturn0file0L214-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. fileciteturn0file0L358-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 fileciteturn0file0L390-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. fileciteturn0file0L422-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. fileciteturn0file0L458-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. fileciteturn0file0L448-L456 fileciteturn0file0L478-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. fileciteturn0file0L32-L34 fileciteturn0file0L320-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. fileciteturn0file0L330-L355 fileciteturn0file0L366-L377 fileciteturn0file0L431-L438 fileciteturn0file0L498-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. fileciteturn0file0L320-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. fileciteturn0file0L555-L593 fileciteturn0file0L642-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** fileciteturn0file0L145-L177 fileciteturn0file0L200-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. fileciteturn0file0L99-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. fileciteturn0file0L119-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. fileciteturn0file0L160-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. fileciteturn0file0L144-L159 fileciteturn0file0L488-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. fileciteturn0file0L622-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: fileciteturn0file0L1-L5
|
||||||
Reference in New Issue
Block a user