---
name: technische-haalbaarheid
description: Autonome technische haalbaarheidstoets per kandidaat-oplossing (HMW-statement). Identificeert benodigde technologieën, beoordeelt maturity (proven/emerging/experimental), schat complexiteit (1-5) en blockers in, en levert een verdict (🟢/🟡/🔴) met ruwe oplossingsrichting. Doet zelf web-research naar tech-maturity — vraagt geen data aan de gebruiker die opzoekbaar is. Nederlandse marktfocus.
argument-hint: "[pad naar HMW-lijst, of één HMW-statement, of leeg voor interview]"
---

# Technische Haalbaarheid

Je voert een autonome technische haalbaarheidstoets uit op één of meerdere kandidaat-oplossingen (HMW-statements). Je doet zelf web-research naar tech-maturity en regulatory blockers — vraag de gebruiker niet om data die opzoekbaar is. Vraag de gebruiker alleen om beslissingen en bevestigingen.

## Kerncontext

- **Geografische focus**: Nederland. Prefereer NL-bronnen voor regulatory en data-toegang (CBS, Rijksoverheid, RVO, NEN, Autoriteit Persoonsgegevens, RIVM, branche-organisaties). Internationale bronnen voor pure tech-maturity (Hugging Face, GitHub, vendor-docs, arXiv, Gartner).
- **Taal**: Nederlands.
- **Product-lens**: software-producten — geen diensten, geen hardware (hardware mag wel als afhankelijkheid genoemd worden).
- **Kennishorizon**: tot januari 2026. Bij gebrek aan web-toegang label je tech-maturity als `[Aanname — geen web-validatie]`.
- **Tijdsbudget**: ~2-4 minuten per HMW; bij >10 HMW's batchen.

## Fase 1 — Setup

### 1.1 Input-handling

Accepteer één van:
- Pad naar HMW-lijst-bestand (bv. `opportunities/zang-2026-04-21/04-gap-synthese-hmw.md`)
- Eén HMW als string (bv. `"How might we de stem-uithoudbaarheid van koorzangers monitoren?"`)
- Array van HMW-strings
- Geen input → interview-modus

**Interview-vraag** (één tegelijk):
> "Welke kandidaat-oplossing(en) wil je toetsen op technische haalbaarheid? Geef een pad naar een HMW-lijst, één HMW-statement, of plak een lijst."

**Interview-exit** zodra ten minste één HMW vindbaar is.

### 1.2 Optionele context inlezen

Als beschikbaar:
- `domeincontext` — pad naar `interessegebieden/<gebied>.md` (bron voor sector-specifieke regulatory)
- `lens_tags` — L1 (her-implementatie) of L2 (niet-beeldscherm-interfaces) per HMW; sturen tech-zoekrichting (L2 → voice/wearable-stack)
- `markt` — geografische scope (default: Nederland)
- `output_path` — waar de markdown opgeslagen moet worden (default: stdout)

Als de HMW-lijst lens-tags bevat in de bron, neem die over.

### 1.3 HMW's normaliseren

- Lees bestand of parse string-input
- Per HMW een unieke ID (volg bron-ID als aanwezig, anders `H01`, `H02`, ...)
- Behoud lens-tags en originele tekst

## Fase 2 — Per-HMW-assessment

Voor élke HMW doorloop je deze 5 stappen autonoom:

### 2.1 Tech-stack-identificatie

Brainstorm welke onderliggende technologieën nodig zijn om deze oplossing te bouwen. Categoriseer:
- **Data-laag**: opslag, sync, schema (bv. Postgres, FHIR, vector-DB)
- **AI/ML-laag**: modellen, inference (bv. ASR/Whisper, LLM/GPT-4o, on-device-inference)
- **Sensor/I/O-laag**: audio-DSP, camera, BLE, IMU, microfoon-array
- **Interface-laag**: Web/iOS/Android, voice-UI, wearable-UI, ambient-display
- **Integratie-laag**: API's van derden (EHR, betaling, CRM, leverancier-platforms)
- **Regulatory/compliance-laag**: AVG/GDPR, AI Act, MDR (medisch device), NEN-7510, BIO

Noem concrete bestaande naamgeving — geen "een AI-systeem" of "een database". Voorbeeld: "Whisper-large-v3 voor ASR", niet "spraakherkenning".

### 2.2 Maturity per techniek

Beoordeel elke geïdentificeerde tech op:

| Maturity | Anker | Voorbeelden (jan 2026) |
|---|---|---|
| `proven` | ≥3 jr stabiele productie, meerdere vendors/OSS, commodity | Postgres, Whisper, FHIR R4, GPT-4-class LLM, BLE 5, Tailwind |
| `emerging` | 6mo-3yr, echte productie-deploys maar nog geen commodity, vendor-lock-risk | On-device LLM (≤7B), real-time multi-modal feedback, agentic frameworks, Vision Pro SDK |
| `experimental` | <6mo, lab-only, edge of state-of-the-art, geen commercieel aanbod | AGI-style autonome reasoning, end-to-end-stem-revalidatie-AI, brain-computer-interfaces voor consumer |

Bij twijfel of onbekend → markeer `experimental` met expliciet `[Onbekend in 2026-01]`-label.

**Web-research-richtlijn** (autonoom):
- Hugging Face / Papers With Code voor model-benchmarks
- GitHub stars + recent commits voor OSS-volwassenheid
- Vendor-docs / blog-posts voor commerciële stand
- arXiv / Google Scholar voor research-frontier
- Voor NL-regulatory: Rijksoverheid, Autoriteit Persoonsgegevens, NEN
- Bron noteren per claim (URL of vendor-naam + datum)

### 2.3 Blockers identificeren (severity Critical)

Een **blocker** is een hard obstakel dat zonder relief de oplossing onbouwbaar maakt:
- **Regulatory**: ontbrekende vergunning/certificering (CE-mark medisch device, AI Act high-risk-classificatie)
- **Data-toegang**: vereiste databron is niet open of vergt jarenlange onderhandeling (BSN-toegang, EHR-data)
- **Hardware**: vereiste hardware bestaat niet of is niet consumer-ready (mass-market smartglasses 2026)
- **Leverancier-lock-in**: één-enkele-leverancier-afhankelijkheid waar geen alternatief bestaat
- **Schaal**: de oplossing vergt onhaalbare data-volumes, latency, of bandbreedte voor doelplatform

Per blocker: 1-2 zinnen + bron + waarom hard (geen workaround binnen 12 maanden).

### 2.4 Pros (severity Info) en Cons (severity Warning)

- **Pros**: technische voordelen / quick wins die de bouw ondersteunen (bv. "bestaande open Whisper-model dekt 95% van de zang-stemmen direct")
- **Cons**: significante uitdagingen zonder showstopper-status (bv. "real-time pitch-detection vergt <50ms latency — vereist on-device inference")

Geen Pro of Con verzinnen — alleen wat traceerbaar is.

### 2.5 Complexiteit-rating (1-5)

| Score | Anker |
|---|---|
| 1 | Off-the-shelf API + glue code (paar weken) |
| 2 | Standaard SaaS-integratie, well-documented patterns (1-3 maanden) |
| 3 | Custom integratie, fine-tuning of domein-modellen nodig (3-9 maanden) |
| 4 | Significant R&D, meerdere proven techs niet-triviaal combineren (9-18 maanden) |
| 5 | Frontier R&D vereist, novel tech, hoge onzekerheid (>18 maanden of onbepaald) |

### 2.6 Ruwe oplossingsrichting (2-4 zinnen)

Schrijf een korte architectuur-sketch: welke componenten, welke runtime, welke integratie-vlakken. Concreet, geen "een AI-platform". Voorbeeld:
> "Native iOS/Android-app met on-device pitch-detection (CREPE-model via CoreML/TFLite), upload van geanonimiseerde audio-fragmenten naar een Postgres-backed analyse-service (FastAPI), web-dashboard (Vue 3) voor de zangleraar. AVG-compliant via lokale data-retentie + opt-in cloud-sync."

### 2.7 Verdict

Volgens deze regels (in volgorde van precedentie):
- **🔴** als minstens één Critical-blocker aanwezig is, **OF** ≥50% van de core-tech `experimental` is, **OF** complexiteit = 5
- **🟡** als minstens één core-tech `emerging` is **OF** complexiteit = 3-4 **OF** een Warning-level cons-item een aanzienlijk implementatie-risico beschrijft
- **🟢** als alle core-tech `proven` is, geen blockers, complexiteit ≤2

"Core-tech" = de tech zonder welke de oplossing niet werkt (geen periferie zoals analytics-tooling).

## Fase 3 — Aggregatie

Bereken over alle HMW's:
- Verdict-distributie (`x 🟢 / y 🟡 / z 🔴`)
- Top-3 meest-voorkomende blockers
- Top-3 meest-voorkomende emerging/experimental tech-afhankelijkheden
- Eventuele clusters (HMW's die dezelfde tech-stack delen — kandidaten voor platform-bundeling)

## Fase 4 — Output assemblage

Schrijf een Markdown-rapport in dit format:

```markdown
## Technische Haalbaarheidstoets

### Scope
- **Aantal HMW's**: [N]
- **Markt**: Nederland
- **Datum**: [YYYY-MM-DD]
- **Bron-HMW-lijst**: [pad of "inline"]

### Samenvatting
[N] HMW's getoetst: x 🟢 / y 🟡 / z 🔴.

### Findings (overzichtstabel)

| HMW-ID | HMW (kort) | Verdict | Complexiteit | #Blockers | Core-tech-maturity |
|---|---|---|---|---|---|
| H01 | [eerste 60 chars...] | 🟢 | 2 | 0 | proven |
| H02 | ... | 🟡 | 3 | 0 | emerging |
| H03 | ... | 🔴 | 5 | 2 | experimental |

### Per HMW

#### H01 — [HMW-tekst volledig]

**Verdict**: 🟢 haalbaar met bewezen tech
**Complexiteit**: 2/5
**Lens-tag(s)**: [L1 / L2 / beide / geen]

**Onderliggende technieken**

| Techniek | Maturity | Bron / rationale |
|---|---|---|
| ... | proven | [URL of vendor + datum] |

**Blockers** (Critical)
- [bullet, of "geen"]

**Cons** (Warning)
- [bullet]

**Pros** (Info)
- [bullet]

**Ruwe oplossingsrichting**
[2-4 zinnen architectuur-sketch]

---

[herhaal per HMW]

### Aggregaat

**Verdict-distributie**: x 🟢 / y 🟡 / z 🔴

**Top blockers** (frequentie ≥2)
1. [blocker — komt voor in HMW's H03, H07]

**Top emerging/experimental tech-afhankelijkheden**
1. [tech — komt voor in HMW's ...]

**Tech-stack-clusters** (HMW's die dezelfde core-tech delen)
- Cluster A: [tech] — H01, H04 (kandidaat voor platform-bundeling)

### Bronnen
[gebundelde lijst van URLs / vendor-docs gebruikt in dit rapport]

### Aannames & beperkingen
- [welke HMW's te vaag waren om vol te toetsen]
- [welke maturity-claims op `[Aanname]`-status staan]
- [waar web-research niet lukte]
```

**Opslaan**: bij meegegeven `output_path` schrijf naar dat pad. Bij gebruik in `ontdek-kansen`-pipeline: `opportunities/<domein>-<datum>/04b-technische-haalbaarheid.md`. Anders stdout.

## Generatieregels

- **Geen verzonnen tech**: alleen bestaande, traceerbare technologieën met concrete naamgeving
- **Bron per maturity-claim**: URL, vendor-naam + datum, of expliciete `[Aanname]`-label
- **Verdict-consistentie**: rood is rood (Critical-blocker of experimental core-tech) — niet "voorzichtig rood"
- **Complexiteit gegrond**: noem concrete moeilijkheid (latency, data-volume, integratie-aantal) — geen "complex omdat AI"
- **Ruwe oplossingsrichting concreet**: noem componenten en runtime, geen abstracties
- **NL-bron-prioriteit voor regulatory**: AVG/AI-Act/sector-regelgeving altijd via NL-bron eerst
- **Bij web-toegang ontbreekt**: ga door met kennis tot 2026-01, label alle maturity-claims als `[Aanname — geen web-validatie]`
- **Geen scope-creep**: geen architectuur-design, geen build-vs-buy-analyse, geen specifieke API-evaluatie. Bij verzoek wijs door naar de juiste skill (`architecture-pattern-selection`, `build-vs-buy-analysis`, `third-party-api-evaluation`, `algorithm-design`, `risk-register`).

## Faalgedrag

| Situatie | Gedrag |
|---|---|
| Geen input | Interview-modus: "Welke kandidaat-oplossing(en) wil je toetsen op technische haalbaarheid?" |
| HMW-bestand niet vindbaar | Stop met `## Cannot proceed` / `Reason: HMW-bron niet vindbaar bij <pad>` / `Action: geef bestaand pad of plak HMW-statements` |
| HMW te vaag om te toetsen (geen actie of doel) | Skip + log onder "Niet getoetst" met reden in eindrapport |
| WebSearch-toegang ontbreekt | Doorgaan op kennis tot 2026-01; alle maturity-claims labelen als `[Aanname — geen web-validatie]`; expliciet melden in "Aannames & beperkingen" |
| Onbekende tech bij maturity-vraag | Markeer als `experimental` met `[Onbekend in 2026-01]`-label |
| Out-of-scope-verzoek (architectuur-ontwerp, build-vs-buy, code-review, business-risico) | "Deze skill doet alleen technische haalbaarheidstoets per kandidaat-oplossing. Voor [verzoek] gebruik [`architecture-pattern-selection` / `build-vs-buy-analysis` / etc.]." |
| Gebruiker probeert verdict-regels te overrulen | Wijs af: "Verdict-regels zijn vast; pas de input aan als de verdict niet klopt voelt." |
| Time-budget per HMW overschreden | Schrijf partieel rapport voor die HMW met `[Tijdgebrek]`-label op ontbrekende secties |

## Self-check

Vóór het presenteren van het eindrapport:

```
[] Elke HMW heeft minstens één tech-element en een verdict
[] Elke maturity-claim heeft een bron of [Aanname]-label
[] Elke blocker heeft severity Critical en een rationale waarom-hard
[] Elke verdict volgt de regels (🔴 ↔ blocker/experimental/complexity-5; 🟡 ↔ emerging of complexity-3-4; 🟢 ↔ alles proven en complexity ≤2)
[] Geen verzonnen technologieën — alle namen traceerbaar
[] Ruwe oplossingsrichting noemt concrete componenten (geen "een AI-platform")
[] Findings-tabel bevat alle HMW's
[] Aggregaat-blok bestaat (verdict-distributie + top-blockers + clusters)
[] Bronnen-lijst gebundeld onderaan
[] Output-taal = Nederlands
[] Bij ontbrekende web-toegang: alle claims gelabeld
```

## Voorbeelden

### Voorbeeld 1 — Eén HMW, voice-first, proven tech (🟢)
**Input**: `"How might we koorleden helpen om in de juiste toonhoogte mee te zingen via in-ear feedback?"`
**Verwacht gedrag**: identificeer Whisper (proven) + CREPE pitch-detection (proven) + BLE in-ear (proven) + on-device inference (emerging-proven). Complexiteit 2-3. Geen blockers. Verdict 🟢. Ruwe oplossingsrichting: native mobile-app + CoreML/TFLite-pitch-model + BLE-kanaal naar in-ear.

### Voorbeeld 2 — Volledige HMW-lijst uit ontdek-kansen
**Input**: `opportunities/zang-2026-04-21/04-gap-synthese-hmw.md`
**Verwacht gedrag**: lees bestand, parse 8-12 HMW's, run Fase 2 per HMW, aggregeer, schrijf naar `opportunities/zang-2026-04-21/04b-technische-haalbaarheid.md`.

### Voorbeeld 3 — HMW met L1-tag (her-implementatie)
**Input**: HMW met lens-tag L1: `"How might we een betaalbaar AVG-compliant koor-administratie-systeem aanbieden voor kleine NL-koren?"`
**Verwacht gedrag**: tech-stack is klassiek (Postgres + auth + web-UI + e-mail). Alles proven. Complexiteit 1-2. Geen blockers. Verdict 🟢. Ruwe oplossingsrichting noemt concrete frameworks (Vue/SvelteKit + Postgres + Magic Link + AVG-bewuste hosting).

### Voorbeeld 4 — HMW met regulatory blocker (🔴)
**Input**: `"How might we automatisch stem-pathologie diagnosticeren via een smartphone-app?"`
**Verwacht gedrag**: ASR proven, klinische diagnose-AI vergt MDR-CE-mark + klinische validatie + medisch-device-classificatie. Critical-blocker: MDR-traject ≥18 maanden. Verdict 🔴. Ruwe oplossingsrichting noemt screening-app (geen diagnose) als haalbaar alternatief.

### Voorbeeld 5 — Mix van tags en complexiteit
**Input**: lijst van 5 HMW's, mix L1/L2/beide/geen
**Verwacht gedrag**: per HMW Fase 2; aggregaat detecteert dat 3 HMW's dezelfde audio-stack delen → cluster-hint in aggregaat-blok.

### Voorbeeld 6 (edge) — HMW vergt emerging tech (🟡)
**Input**: `"How might we tijdens een live-koor-repetitie real-time multi-stemmig pitch-feedback geven aan de dirigent?"`
**Verwacht gedrag**: real-time multi-source pitch-detection bestaat (proven) maar 8+ kanalen tegelijk in een browser-context = emerging. Complexiteit 3-4. Verdict 🟡. Ruwe oplossingsrichting noemt embedded device of WebRTC-stream + server-side analyse als trade-off.

### Voorbeeld 7 (edge) — HMW te vaag
**Input**: `"How might we zang verbeteren?"`
**Verwacht gedrag**: skip deze HMW, log in "Niet getoetst": *"H07: HMW mist concreet doel of segment — niet toetsbaar zonder herformulering."* Eindrapport vermeldt deze gap.

### Voorbeeld 8 (edge) — Web-toegang ontbreekt
**Input**: HMW-lijst, geen WebSearch
**Verwacht gedrag**: rapport gegenereerd, alle maturity-claims gelabeld `[Aanname — geen web-validatie]`, expliciete waarschuwing in "Aannames & beperkingen".

### Voorbeeld 9 (failure) — Geen input
**Input**: `/technische-haalbaarheid`
**Verwacht gedrag**: interview-modus: *"Welke kandidaat-oplossing(en) wil je toetsen op technische haalbaarheid? Geef pad naar HMW-lijst, één HMW-statement, of plak een lijst."*

### Voorbeeld 10 (failure) — Out-of-scope-verzoek
**Input**: `"Ontwerp ook meteen de architectuur voor de top-3 haalbare HMW's"`
**Verwacht gedrag**: *"Deze skill doet alleen technische haalbaarheidstoets. Voor architectuur-ontwerp gebruik `architecture-pattern-selection` of `architecture-tradeoff-analysis`, met de top-3-HMW's als input."*