obsidian/Main
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

vault backup: 2026-04-23 21:42:51

Browse Source 
Affected files:
.obsidian/workspace.json
99 Work/Teaching/TEP - Schulung/CAPSA SUITE proposal deep-dive.md
99 Work/Teaching/TEP - Schulung/capsa_suite_project_overview_short.md
99 Work/Teaching/TEP - Schulung/capsa_suite_visit_briefing.md
This commit is contained in:
Obsidian-MBPM4
2026-04-23 21:42:51 +02:00
parent e280622496
commit ee361d9a53
4 changed files with 1013 additions and 117 deletions
Download Patch File Download Diff File Expand all files Collapse all files

36
.obsidian/workspace.json vendored
View File

@@ -160,37 +160,9 @@
"icon": "lucide-file",
"title": "Home Assistant"
}
},
{
"id": "fac43a56fe618e9d",
"type": "leaf",
"state": {
"type": "markdown",
"state": {
"file": "2 Personal/Home Lab/Baerhalten/Home Assistant.md",
"mode": "source",
"source": false
},
"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": 12
"currentTab": 10
}
],
"direction": "vertical"
@@ -538,8 +510,10 @@
},
"active": "a24c733c4981be03",
"lastOpenFiles": [
"2 Personal/Home Lab/Baerhalten/Home Assistant.md",
"99 Work/Teaching/TEP - Schulung/capsa_suite_visit_briefing.md",
"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/capsa_suite_project_overview_short.md",
"99 Work/Teaching/TEP - Schulung",
"99 Work/Teaching",
"2 Personal/Home Lab/Backup System - Kopia Server Setup.md",
@@ -565,8 +539,6 @@
"2 Personal/Home Lab/NAS/Maintenance Plan.md",
"2 Personal/Home Lab/NAS/Jellyfin Installation.md",
"2 Personal/Home Lab/NAS/homelab_backup_architecture_first_draft.md",
"2 Personal/Home Lab/NAS/Photo Apps.md",
"2 Personal/Home Lab/MAC/Software Management on MacOS.md",
"Dashboard Canvas.canvas",
"Attachments/ESPSomfyRTS 2026-03-17T16_05_06.backup",
"Attachments/Pasted image 20260121121234.png",

108
99 Work/Teaching/TEP - Schulung/CAPSA SUITE proposal deep-dive.md
View File

@@ -9,7 +9,7 @@ This note turns the 70-page CAPSA SUITE proposal into a structured briefing you
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.
**Source:** CAPSA SUITE submitted proposal. Key themes and structure are taken from the uploaded proposal. See the original file for full detail.
---
@@ -22,9 +22,9 @@ CAPSA SUITE is a proposal to build a modular software platform for **building de
- 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
- 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 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:
@@ -34,46 +34,6 @@ 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
@@ -93,7 +53,7 @@ flowchart LR
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.
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.
---
@@ -105,7 +65,7 @@ The proposal argues that the current market for building decarbonization plannin
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
5. **owners of large portfolios** need consistent, comparable roadmaps, not ad-hoc reports
### Current pain points
@@ -131,7 +91,7 @@ flowchart TD
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
This process shift is the heart of the proposal. They repeatedly describe it as a **process innovation**, not just a software feature set.
---
@@ -141,7 +101,7 @@ 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
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.
**What it is supposed to do**
- capture building and equipment data on site
@@ -160,27 +120,27 @@ The proposal assumes raw building data will almost always be incomplete, so it a
- GIS / 3D city data
- smart meter or other internal data
- synthetic building stock methods
- statistical and ML-based imputation fileciteturn0file0L390-L421
- statistical and ML-based imputation
**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
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.
### 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
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.
### 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
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.
---
## 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
The proposal is organized into four work packages over 30 months, with total project cost of about EUR 1.86M.
```mermaid
gantt
@@ -215,7 +175,7 @@ gantt
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
This timeline is approximate and simplified from the work package and milestone sections.
### Budget split by work package
@@ -228,7 +188,7 @@ pie showData
"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
This shows where the effort sits: mostly in data/integration and DRR logic, not in generic project management.
---
@@ -256,7 +216,7 @@ flowchart LR
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
This division of labor is described throughout the consortium and task sections.
---
@@ -270,7 +230,7 @@ This is important because it tells you where to challenge them and where to help
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
5. **Turning consulting workflows into a reusable digital process**
### Less novel than they imply
@@ -332,16 +292,16 @@ rather than:
### 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
The proposal correctly identifies that building decarbonization at scale is constrained by data fragmentation and labor intensity.
#### 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
This is not zero-to-one fantasy. They already have app, DBP, SEAT, and building stock model components.
#### 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
Hypoport, Viessmann/Carrier, housing associations, and existing clients make the go-to-market story more credible than typical grant proposals.
#### 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
The proposal is grounded in regulation, sustainability reporting, and financing use cases, not just engineering enthusiasm.
### Weakest parts
@@ -718,7 +678,7 @@ Before putting AI everywhere in the client-facing product, improve internal deve
## 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
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.
But it is also very ambitious. The hard problem is not “can we build some features?” It is:
@@ -743,28 +703,6 @@ Your highest-value offer is likely:
---
## 17. Source reminder
## 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
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:

278
99 Work/Teaching/TEP - Schulung/capsa_suite_project_overview_short.md Normal file
View File

@@ -0,0 +1,278 @@
# CAPSA SUITE — Short Project Overview
## Executive summary
CAPSA SUITE is a proposed software platform for **decarbonizing building portfolios at scale**.
Its core promise is simple:
> turn fragmented building data and manual consulting work into a structured digital workflow that helps owners, portfolio managers, investors, and banks make faster, more consistent, and more economically grounded retrofit decisions.
In practice, CAPSA aims to connect:
- **data collection in the field** (mobile app, photos, guided input)
- **central data storage** (digital building passport / secure database)
- **data completion and contextualization** (public registries, GIS, infrastructure and building-stock data)
- **decarbonization planning** (retrofit roadmaps)
- **carbon and cost evaluation** (including whole-life carbon and scope 1–3 thinking)
- **monitoring and portfolio steering** over time
The project is positioned as a bridge between **consulting, software, energy planning, and sustainable finance**.
---
## What CAPSA wants to achieve
CAPSA wants to make building decarbonization:
- **more scalable** — so large portfolios can be handled without depending entirely on scarce experts
- **more data-driven** — less guesswork, fewer scattered PDFs and Excel files
- **more standardized** — more comparable decisions across buildings and portfolios
- **more finance-ready** — clearer investment packages, better reporting, stronger basis for green finance and ESG work
- **more operational** — not just a strategy report, but a system that links planning to execution and monitoring
The public TEP positioning reinforces this. TEP describes CAPSA as a combination of **app, secure database, and insights portal** that lets users collect building information, manage it centrally, and turn it into actionable strategies across single buildings and entire portfolios. The emphasis is on connecting strategic and operational levels and integrating technical and economic considerations in one system.
---
## Why this project exists
The proposal is built on a real market pain point:
### The current situation
Building decarbonization is often still handled through:
- manual site visits
- scattered building records
- incomplete or outdated data
- expert judgment that varies from person to person
- isolated reports instead of continuous systems
That is workable for a few buildings, but weak for **large housing portfolios**, **banks**, **real-estate firms**, or **municipal planning contexts**.
### The pressure is rising
Owners and managers increasingly need:
- decarbonization strategies
- energy and emissions reporting
- investment prioritization
- portfolio-level decision support
- stronger links to policy and financing requirements
So CAPSA exists because the old way is too slow, too manual, and too inconsistent for the scale of the transition.
---
## The main selling point
The main selling point is **not just another building database**.
The real selling point is the **end-to-end process**:
1. capture building data efficiently
2. fill in missing information intelligently
3. combine building data with spatial and infrastructure context
4. generate decarbonization and retrofit pathways
5. estimate cost and carbon impact
6. store and monitor everything in a digital building passport
That is what makes CAPSA stronger than a normal audit workflow, a normal property-management system, or a normal GIS/planning tool.
TEP’s public REAT description supports this broader system view. REAT is positioned as a spatial-energy analysis toolbox for municipalities, utilities, and regions that identifies local energy potentials and constraints while considering prices, policy, network paths, noise rules, water protection, and geothermal restrictions. That matters because CAPSA is not meant to operate in a vacuum — it depends on local infrastructure and feasibility context.
---
## How the system works in plain English
### 1. Data collection
Someone on site uses the CAPSA app to collect building data quickly and in a more structured way than paper or ad hoc notes.
### 2. Data completion
The system supplements missing information using external data sources, building typologies, public records, and model-based inference.
### 3. Central storage
All relevant information is stored in a **Digital Building Passport**, which becomes the central data layer.
### 4. Strategy generation
The platform generates **Decarbonization and Retrofit Roadmaps (DRRs)** for buildings or portfolios.
### 5. Cost and carbon assessment
Measures are evaluated economically and environmentally, including broader whole-life and scope-3 type thinking.
### 6. Monitoring
The roadmap is not supposed to remain a report on a shelf. CAPSA aims to track what is planned, in progress, and completed.
---
## Who it is for
CAPSA is aimed at:
- real estate portfolio owners
- housing associations
- property managers
- investors and banks
- municipalities and utilities in adjacent use cases
- consultants and implementation partners
The public TEP page explicitly frames CAPSA for **real-estate companies, owners, managers, investors, and banks**.
---
## Benefits
## Strategic benefits
- Creates a clearer basis for long-term decarbonization decisions
- Supports portfolio-level prioritization instead of one-off building-by-building firefighting
- Helps connect technical planning with capital allocation and reporting
## Operational benefits
- Faster and more structured data capture
- Better continuity of information over time
- Easier collaboration between field staff, analysts, managers, and external partners
- Less dependence on scattered documents and individual expert memory
## Economic benefits
- Lower manual effort per building over time
- Better comparability of measures and investment packages
- More useful basis for financing, budgeting, and sequencing works
## Climate and policy benefits
- Supports structured decarbonization instead of isolated measures
- Makes scope 1–3 style thinking more operational
- Helps align building action with wider policy and infrastructure context
## Business benefits for TEP and partners
- Converts consulting know-how into reusable product modules
- Opens recurring software and hybrid service revenue potential
- Strengthens positioning at the intersection of energy, policy, economics, and software
---
## Risks
## 1. Execution risk
This is an ambitious integration project. Mobile data collection, data completion, spatial context, carbon accounting, roadmap generation, APIs, and monitoring all need to work together well. That is hard.
## 2. Data quality risk
If the input data is weak, automated outputs may look polished but still be wrong or misleading. In this type of product, trust depends heavily on data quality.
## 3. Adoption risk
The building and real-estate sectors are often conservative. Even if the software works, adoption may be slower than expected because workflows, incentives, and responsibilities are messy.
## 4. Over-complexity risk
The product tries to serve many stakeholders at once: owners, managers, banks, cities, utilities, consultants. That can create a bloated product if priorities are not sharp.
## 5. Commercialization risk
A good prototype does not automatically become a scalable business. The gap between “useful in pilots” and “bought systematically” is often large.
## 6. Integration risk
CAPSA’s value depends on connecting with external data sources, internal systems, and planning/finance processes. Integration work is usually harder and slower than expected.
---
## Drawbacks / likely weak points
These are not fatal flaws, but they matter.
### It may be too broad
CAPSA is trying to be:
- a data collection tool
- a digital passport
- a planning engine
- a carbon tool
- a monitoring system
- a finance-enabler
- partly also a spatial energy intelligence layer
That breadth is powerful, but also dangerous. It can dilute focus.
### The hardest part is trust, not software alone
Clients will only rely on automated pathways if they trust:
- the data
- the assumptions
- the prioritization logic
- the feasibility logic
- the cost estimates
### It may remain service-heavy longer than planned
Many such platforms claim SaaS-like scalability, but in practice remain dependent on consulting, onboarding, custom data work, and customer-specific adaptation.
### It competes with existing habits, not only competitors
Sometimes the real competitor is not another software company. It is:
- Excel
- PDFs
- consultants
- internal ad hoc workflows
- “good enough” manual processes
That is a real barrier.
---
## Different viewpoints on CAPSA
## 1. From the building owner’s view
CAPSA is a way to gain a better overview, prioritize measures, and reduce chaos in building data and retrofit planning.
## 2. From the consultant’s view
CAPSA can make consulting more efficient and repeatable, but also pressures traditional manual advisory work.
## 3. From the bank / investor view
CAPSA could become a more structured basis for understanding building risk, retrofit readiness, and decarbonization pathways.
## 4. From the municipality / utility view
The link to spatial-energy context matters because building-level decisions depend on heat networks, local restrictions, and renewable potentials. This is exactly where REAT complements the CAPSA vision.
## 5. From TEP’s business view
CAPSA is a productization move: turning TEP’s modelling, energy-planning, and strategy expertise into a more scalable digital offering.
## 6. From a software practitioner’s view
CAPSA is really a systems-integration product. The key challenge is not only frontend or AI, but reliable workflows, data architecture, APIs, validation, and decision transparency.
---
## My blunt assessment
This project makes sense.
Its strongest idea is that **decarbonizing building portfolios is fundamentally a data-and-process problem**, not just an engineering calculation problem.
That is exactly why a platform like CAPSA can be valuable.
The upside is real:
- better decisions
- faster workflows
- stronger portfolio steering
- better connection between strategy, economics, and execution
But the danger is also real:
- too much scope
- too many moving parts
- too much dependence on data quality and change management
So the proposal is strong in **direction** and **market logic**, but success will depend heavily on **focus, product discipline, trust in outputs, and execution quality**.
---
## One-paragraph takeaway
CAPSA SUITE wants to become the digital backbone for building-portfolio decarbonization: a system that captures building data, enriches it with public and spatial context, translates it into retrofit and carbon strategies, and helps owners and managers act on those strategies over time. Its promise is speed, consistency, better decisions, and a stronger basis for finance and reporting. Its risks are complexity, adoption, and data trust. If it works, it can be a meaningful step from fragmented consulting work toward a scalable decarbonization operating system.
---
## Sources
- Eurostars project proposal PDF provided in this chat
- TEP Energy: CAPSA Suite page
- TEP Energy: REAT page

708
99 Work/Teaching/TEP - Schulung/capsa_suite_visit_briefing.md Normal file
View File

@@ -0,0 +1,708 @@
# 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.
---
## 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.
---
## 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
### 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.
---
## 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.
**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
**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.
### 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.
### 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.
---
## 4. Work package map
The proposal is organized into four work packages over 30 months, with total project cost of about EUR 1.86M.
```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.
### 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.
---
## 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.
---
## 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**
### 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.
#### 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.
#### 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.
#### 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.
### 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.
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. 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: