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

vault backup: 2026-04-23 20:23:23

Browse Source 
Affected files:
.obsidian/bookmarks.json
.obsidian/workspace.json
99 Work/Teaching/TEP - Schulung/CAPSA SUITE proposal deep-dive.md
This commit is contained in:
Obsidian-MBPM4
2026-04-23 20:23:23 +02:00
parent 121d2b9461
commit 3b7bcb23db
3 changed files with 834 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
.obsidian/bookmarks.json vendored Normal file
View File

@@ -0,0 +1,9 @@
{
"items": [
{
"type": "folder",
"ctime": 1776967124634,
"path": "99 Work/Teaching/TEP - Schulung"
}
]
}

63
.obsidian/workspace.json vendored
View File

@@ -174,9 +174,23 @@
"icon": "lucide-file",
"title": "Home Assistant"
}
},
{
"id": "044a18f2d2633450",
"type": "leaf",
"state": {
"type": "markdown",
"state": {
"file": "99 Work/Teaching/TEP - Schulung/CAPSA SUITE proposal deep-dive.md",
"mode": "source",
"source": false
},
"icon": "lucide-file",
"title": "CAPSA SUITE proposal deep-dive"
}
}
],
"currentTab": 11
"currentTab": 12
}
],
"direction": "vertical"
@@ -195,7 +209,7 @@
"state": {
"type": "file-explorer",
"state": {
"sortOrder": "alphabetical",
"sortOrder": "byModifiedTime",
"autoReveal": true
},
"icon": "lucide-folder-closed",
@@ -481,16 +495,53 @@
],
"direction": "vertical",
"x": 0,
"y": 42,
"y": 34,
"width": 900,
"height": 777,
"maximize": false,
"zoom": 0
},
{
"id": "f1b9d015e6bf9f80",
"type": "window",
"children": [
{
"id": "ead9296ecab7eab5",
"type": "tabs",
"children": [
{
"id": "a24c733c4981be03",
"type": "leaf",
"state": {
"type": "markdown",
"state": {
"file": "99 Work/Teaching/TEP - Schulung/CAPSA SUITE proposal deep-dive.md",
"mode": "source",
"source": false
},
"icon": "lucide-file",
"title": "CAPSA SUITE proposal deep-dive"
}
}
]
}
],
"direction": "vertical",
"x": 658,
"y": -1860,
"width": 1680,
"height": 1860,
"maximize": false,
"zoom": 0
}
]
},
"active": "fac43a56fe618e9d",
"active": "a24c733c4981be03",
"lastOpenFiles": [
"99 Work/Teaching/TEP - Schulung/CAPSA SUITE proposal deep-dive.md",
"99 Work/Teaching/TEP - Schulung/CAPSA SUITE proposal deep-dive.md",
"99 Work/Teaching/TEP - Schulung",
"99 Work/Teaching",
"2 Personal/Home Lab/Backup System - Kopia Server Setup.md",
"2 Personal/1 Skills/Obisdian/Obsidian Setup.md",
"2 Personal/Projects/AlpineView/Thoughts.md",
@@ -517,8 +568,6 @@
"2 Personal/Home Lab/NAS/Photo Apps.md",
"2 Personal/Home Lab/MAC/Software Management on MacOS.md",
"Dashboard Canvas.canvas",
"Dashboard.md",
"8 Places/BusinessesDrawing 2023-10-12 16.01.52.excalidraw.md",
"Attachments/ESPSomfyRTS 2026-03-17T16_05_06.backup",
"Attachments/Pasted image 20260121121234.png",
"Attachments/ESPSomfyRTS 2026-01-18T16_26_16.backup",
@@ -534,8 +583,6 @@
"Attachments/Pasted image 20251015111504.png",
"Attachments/Pasted image 20251015092212.png",
"3 Knowledge/5 AI/PromptDB",
"3 Knowledge/5 AI",
"99 Work/0 OneSec/OneSecNotes/10 Projects/TeensyFlightcontroller",
"Attachments/Pasted image 20250922115441.png",
"Attachments/image 21.jpg",
"99 Work/0 OneSec/OneSecNotes/30 Engineering Skills/Computer Science/Untitled.canvas",

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

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