technische-haalbaarheid

What this skill does

# 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 oplossings