Methodologie van onze probabilistische huurcheck

1. Probleem#

Het Nederlandse woningwaarderingsstelsel (WWS, Beleidsboek 2026) bepaalt het wettelijke maximum huurbedrag op basis van 11 rubrieken (1 t/m 11) plus rubriek 3b Koeling (toegevoegd 1-7-2024):

In onze parsed representatie bestaan deze 11 rubrieken uit ~36 sub-features- rubriek 4 Sanitair alleen al heeft 10: aantal badkamers, extra toiletten, bad, douche, inloopdouche, wastafels, dubbele wastafel, vloerverwarming bad, bidet, urinoir. Een precieze item-voor-item mapping van WWS-rubrieken naar onze features (we dekken ~25–26 van de 36 items) staat op de data-transparantie pagina.

Het probleem: van een typische huurwoning op WoonBusters kennen we maar een handvol van deze inputs uit de advertentie zelf - oppervlakte, energielabel, tuin, balkon, soms aantal slaapkamers en lift. De overige features - vooral sanitair-details, verwarmingstype en berging - zijn vrijwel nooit beschikbaar. Maar het WWS vereist ze allemaal om tot een exact puntentotaal te komen.

Onze aanpak: bereken een waarschijnlijkheidsverdeling over het puntentotaal door gebruik te maken van empirische kansverdelingen voor de onbekende kenmerken, gebaseerd op echte data van fysiek vergelijkbare woningen. Dat geeft een 90% betrouwbaarheidsinterval op de maximale huur - geen alles-of-niets oordeel.

Wat zegt "X% betaalt te veel" eigenlijk?#

Per peildatum 2026-04-29: twee aparte cijfers, niet één. We rapporteren WWS en WWSO altijd los van elkaar omdat ze fundamenteel verschillende regimes zijn. Een blended cijfer (57,7%) is mechanisch opwaarts vertekend door WWSO en hoort niet als losse headline gebruikt te worden.

De zelfstandige-markt-headline is 50,2% te duur op 16.496 appartementen + studio's. Dat is het cijfer dat het reguliere huurmarkt-debat karakteriseert. WWSO (kamers) zit mechanisch hoger omdat onzelfstandige woonruimte geen vrije-sectorgrens heeft - er is altijd een legaal maximum, dus elke kamer boven die grens telt automatisch als "te duur".

Wat doen we met listings zonder geverifieerd adres?#

Van de ~52.800 gescraapte listings hebben er ~31.400 geen exact adres in een vorm waar we Kadaster mee kunnen bevragen. We splitsen die in drie categorieën, en voor alle drie tonen we geen verdict:

• Lat/lon-only (~15.000): hebben coördinaten maar geen adres-tekst (typisch HousingAnywhere, Vesteda, een deel van Kamernet en VBT). De coördinaten wijzen het juiste gebouw aan (mediane afwijking <3m), maar in een appartementencomplex met meerdere units kan reverse-geocoding niet betrouwbaar de juiste woning kiezen. Het verschil tussen de WOZ van de geraden unit en de werkelijke unit heeft een mediane fout van 5.6%, een 90e-percentielfout van 59% en incidentele uitschieters tot >200%. We hebben getest of gebouw-mediaan aggregeren materieel beter is - dat blijkt niet zo (mediaan zelfs iets slechter omdat WOZ binnen één gebouw fundamenteel heterogeen is: penthouse vs. studio op de begane grond). Conclusie: zonder unit-niveau identificatie is een eerlijke huurcheck niet mogelijk.
• Tier 2 (~13.900, met CBS wijk-code): getest of CBS-wijk WOZ × hedonische correctie materieel beter is dan stad × m². Verdict: nee, beide hebben mediane fout van ~36%. WOZ varieert te sterk binnen één wijk.
• Tier 3 (~2.500, alleen postcode): te weinig data om eerlijk te scoren.

Plus filteren we op contracttype/property_type voor de drie categorieën die wettelijk buiten WWS/WWSO vallen (totaal 32 listings):

• contract_type="short_stay" (1 listing): formeel een verblijfsrecht/hospitality-contract, géén huurovereenkomst.
• contract_type="anti_squat" of property_type LIKE "%anti-kraak%" (31 listings): bruikleenovereenkomst onder leegstandsbeheer - geen huurregime.
• contract_term_months ≤ 6 (effectief 0 listings extra na bovenstaande filters; veld is voor maar 0,13% van Tier 1 geparseerd).

Voor de live /huurcheck tool is dit géén beperking - gebruikers vullen daar hun eigen adres in waardoor we altijd Tier 1 data hebben. De beperking geldt alleen voor de listings-page badges en de gepubliceerde populatiestatistieken.

2. Data#

2.1 Trainingsdata: Funda ground truth#

Om te weten welke feature-combinaties bij welk type woning voorkomen, hebben we een trainingsdataset nodig. Funda is daarvoor uitermate geschikt omdat het:

• Diepgaande detailpagina's heeft met gestructureerde characteristics (Badkamervoorzieningen, Verwarming, Isolatie, Tuin, etc.)
• Nationale coverage heeft - niet beperkt tot één makelaar
• Via pyfunda (Python library die Funda's mobile API reverse-engineered) stabiel en bulk te scrapen is

Dataset (peildatum 2026-04-26): 2.850 huurlistings + 9.217 koop-listings = 12.162 Funda-rijen in totaal, uit 30+ steden. De set blijft groeien - we draaien periodiek nieuwe pyfunda-runs en UPSERT op global_id, dus elke run voegt nieuwe advertenties toe en ververst bestaande. Voor de relevantie van de koop-data voor het schatten van een huur-prijs zie §2.5.

Opgeslagen in PostgreSQL-tabel ground_truth_funda (68 kolommen), waaronder global_id, url, title, address, price, living_area, construction_year, energy_label, characteristics (JSONB) en raw_data.

2.2 Feature parsing#

Funda's characteristics is een losse dict van vrije-tekst velden. Onze parser (scraper/funda_characteristics_parser.py) extraheert hier 22 sampleable features uit waar de Probabilistische sampler direct uit trekt, plus een aantal afgeleide features (isolatie-score, parkeer-type) die we als hard condition gebruiken.

De volledige lijst van 22 sampleable features (de empirische verdelingen die in priors_v1.json worden opgeslagen):

• Badkamervoorzieningen (10) → num_bathrooms, num_extra_toilets, has_bath, has_shower, has_walk_in_shower, num_sinks, has_dual_sink, has_underfloor_heating_bath, has_bidet, has_urinal
• Verwarming + Warm water (2) → heating_points_per_room (1.5 of 2.0), has_heat_recovery
• Energie (1) → energy_label (gebruikt als soft condition voor verwarming/isolatie-cohort)
• Tuin/balkon (4) → outdoor_type, has_tuin, has_balkon, has_dakterras
• Schuur/berging (2) → has_storage, storage_type
• Voorzieningen (3) → has_lift, has_private_parking, has_parking_garage

Daarnaast extraheert de parser ook isolatiekenmerken (has_double_glazing, has_hr_glass, is_fully_insulated) en tuin_m2 als afgeleide gegevens; die gebruiken we als deterministische input of laten we vallen waar Funda ze te zelden vult (tuin_m2 komt voor in <5% van de rows).

2.3 Kwaliteitsfilter#

Niet alle Funda-rows zijn bruikbaar als training. We vereisen:

• living_area en construction_year gevuld
• Badkamervoorzieningen-veld aanwezig (anders zijn alle bathroom-features None en zijn ze niet echt "False" maar "onbekend")
• Verwarming-veld aanwezig (zelfde reden)
• Geen Studentenkamer. Funda heeft géén eigen top-level "Studentenkamer" categorie, maar enkele listings dragen dit label in het Soort appartement veld; die vallen onder WWSO en filteren we uit de WWS-trainingsset (huidige run: 2 rows uitgesloten).

Na filtering: 1.116 huur-trainingsrows (van 2.850 ruwe huurlistings). De ratio (~44%) wordt bepaald door hoe vaak verhuurders het Badkamervoorzieningen- en Verwarming-blok invullen op Funda. Plus daarbij komen nog 8.243 koop-trainingsrows (zie §2.5 voor waarom we koop-data poolen) → eindgebruik 9.359 trainingsrows in totaal, waarvan een deel feature-specifiek wordt gefilterd op offering_type (rent-only voor 9 features met persistente selectie-bias, rent+sale voor de overige).

2.4 Kamernet faciliteit-data (voor WWSO)#

Voor kamers hebben we aanvullend nodig: is de keuken gedeeld of privé? De douche? Het toilet? En met hoeveel huisgenoten? Kamernet's mobile-API geeft deze informatie expliciet via kitchenId, showerId, toiletId, housematesNumberId.

Opgeslagen in tabel kamernet_facilities. Na backfill: 2.624 rows met geverifieerde faciliteit-data (peildatum 26-04-2026).

2.5 Rent vs. Sale: zijn de datasets poolbaar?#

Naast huurlistings hebben we ook 9.217 koop-listings uit Funda (peildatum 26-04-2026). Een logische vraag: kunnen we die koop-data direct meenemen in de priors voor onze huurcheck? De fysieke kenmerken (sanitair, verwarming, isolatie) hangen niet af van of een woning verhuurd of verkocht wordt - een bad is een bad. Maar er is selectiebias: koop-woningen zijn voornamelijk eengezinswoningen, huur-woningen voornamelijk appartementen.

Om dit te kwantificeren hebben we voor elk van de 22 sampleable features een per-feature statistische vergelijking gedraaid (chi-squared voor booleans en categorieën, Kolmogorov-Smirnov voor numeriek), met als oordelen:

• similar = p > 0.05 (geen statistisch significant verschil)
• moderate = 0.01 < p ≤ 0.05
• different = p ≤ 0.01 (substantieel afwijkend)

Aggregaat: rent vs. sale (alle dwelling types)#

Cohort: 20–200 m², bouwjaar 1900–2026. n_rent = 2.470, n_sale = 7.871.

Op het eerste gezicht ziet het er slecht uit: 13 van de 22 features verschillen significant. Maar de grootste gaten zijn één-op-één een afspiegeling van het dwelling-type-verschil:

Sample-compositie: rent is 88% appartement / 12% huis; sale is 44% appartement / 56% huis. Het echte antwoord vereist een like-for-like vergelijking binnen dwelling type.

Within-type: alleen appartementen#

Cohort: appartementen, 20–200 m², 1900–2026. n_rent = 2.195, n_sale = 3.508.

Beter, maar nog steeds 11 features verschillen. Deze gaten zijn echte selectie-bias: rent-appartementen zijn nieuwer / vaker gerenoveerd, met meer luxe-voorzieningen.

Within-type: alleen huizen#

Cohort: eengezinswoningen, 20–200 m², 1900–2026. n_rent = 275, n_sale = 4.363.

Veel beter: 15 van de 22 features statistisch gelijk. De vijf afwijkingen zijn praktisch verwaarloosbaar (has_lift 2% vs 0% - huizen hebben gewoon geen lift) of betreffen parkeer-features die alsnog enige selectiebias hebben.

Liggen de verschillen aan oppervlakte of bouwjaar?#

Rent en sale verschillen mogelijk niet alleen op dwelling type, maar ook op oppervlakte en bouwjaar - bijvoorbeeld als rental investors systematisch nieuwere appartementen targeten. We hebben gemiddelde en mediane waarden vergeleken:

Oppervlakte is bijna identiek, maar bouwjaar verschilt dramatisch: rent-appartementen zijn gemiddeld 28 jaar nieuwer dan sale-appartementen. Dat verklaart een groot deel van de selectie-bias: rental investors kopen / bouwen nieuwere complexen voor de verhuurmarkt; sale-listings bestrijken de hele woningvoorraad terug tot 1900.

Test: appartementen-only én bouwjaar 2000+. n_rent = 1.375, n_sale = 1.073:

Door ook op bouwjaar te matchen convergeren de sanitair-features (bad, inloopdouche, vloerverwarming, warmteterugwinning) van "different" naar "similar". De resterende verschillen zitten bijna allemaal in parkeer- en lift-features:

Dit is echte selectiebias die niet weggaat met fijner cohort-matchen: rental investors kiezen specifiek modernere appartementenblokken met garages en liften. Sale-data van "dezelfde periode" is daarom nog steeds geen zuivere vervanging voor rent-data op deze features.

Conclusie en gevolgen voor de priors#

Onze aanpak: een per-feature-policy. Elke training-row wordt getagd met zijn offering_type (rent of buy). Bij het sampelen van een feature bepaalt een whitelist of we uit beide pools mogen trekken of alleen uit rent:

De per-feature filter wordt toegepast bij elke Monte Carlo iteratie in sample_feature() in api/huurcheck/priors.py. Voor de rent-only features blijft het effectieve cohort dus klein (1.116 rent rows verdeeld over alle dwelling/area/jaar combinaties); voor de mixable features krijgen we een echte cohort-uitbreiding.

Sale-listings hebben overigens een hogere kwaliteit op de WWS-relevante velden: 89% van de sale-rows passeert het Badkamervoorzieningen + Verwarming kwaliteitsfilter, vs 39% voor rent. Eigenaren vullen op Funda meer detail in dan verhuurders. Deze hoge invul-graad maakt sale-data extra waardevol om sparse cohorten in de rent-set aan te vullen op de features waar het veilig is.

De rauwe vergelijkingsdata staan in docs/comparisons/rent_vs_sale_*.json in onze repo. We draaien de vergelijking opnieuw bij elke materiele uitbreiding van de sale-set zodat we kunnen monitoren of de balans verschuift.

3. Probabilistische inferentie#

3.1 Basisformule#

De WWS-puntenberekening is additief: elke rubriek draagt los punten bij, het totaal is de som, en de maximale huur is een deterministische functie van het totaal.

totaal_punten = oppervlakte + verwarming + sanitair + energie + buitenruimte
              + berging + WOZ + lift + monument_bonus
max_huur     = WWS_tabel(totaal_punten)

We kunnen de berekening splitsen in een deterministisch deel (wat we exact weten) en een gesampled deel (wat we uit priors moeten trekken).

3.2 Wat we deterministisch berekenen#

Deze 5 rubrieken zijn identiek in elke Monte Carlo iteratie. Geen sampling.

3.3 Wat we gesampled uit priors#

Bij WWSO komt daar nog bij: keuken gedeeld/privé, douche gedeeld/privé, toilet gedeeld/privé, aantal huisgenoten (voor delingsfactor).

3.4 De empirische priors (kernel-bootstrap, v6)#

Voor elke sampleable feature bouwen we een empirische verdeling op uit trainingsdata. De kernvraag: "Van huurwoningen die fysiek lijken op dit aanbod, hoe vaak komt feature X voor?"

Sinds v6: we gebruiken een Gaussian-kernel weighting in plaats van discrete cohort-windows. Elke training-row krijgt een continu gewicht op basis van log-area en bouwjaar afstand tot het target:

weight = exp(-0.5 × ((log(area / target_area) / 0.20)²
                   + ((year - target_year) / 15)²))

Bandwidth defaults h_log_area = 0.20 (1σ ≈ ±22% area) en h_year = 15. Een row ver weg krijgt verwaarloosbaar gewicht; een row dichtbij krijgt bijna 1. We trekken vervolgens met random.choices gewogen uit de pool.

Effective sample size (Kish 1965) meet hoeveel "effectieve" rows er in de pool zitten: ESS = (Σw)² / Σ(w²). Bij ESS ≥ 25 sampelen we direct. Bij sparser cohort verbreden we de bandwidth gladsmooth: 1.6× → 2.5× → 4×. Pas daarna laten we soft of hard conditions vallen.

Voorbeeld: voor een 55 m² woning uit 1965 krijgt een 50 m² 1960 row gewicht ≈ 0.96, een 80 m² 1970 row gewicht ≈ 0.27, een 200 m² 1990 row gewicht ≈ 0.001.

3.5 Conditionele sampling#

Een WoonBusters-listing kan gedeeltelijke info hebben die de prior moet respecteren:

• Hard conditions (feit over de woning, altijd toepassen): has_garden, has_balcony, has_lift, has_parking_garage, shared_kitchen, shared_shower, shared_toilet.
• Soft conditions (proxy, mag wegvallen bij sparse data): energy_label.

De sampler filtert het cohort eerst met alle hard+soft conditions. Als er < 25 rows overblijven, laat hij één soft condition tegelijk vallen (greedy: de meest restrictieve eerst). Hard conditions blijven altijd staan.

3.6 Per-feature onafhankelijke sampling#

We trekken elke feature onafhankelijk uit zijn eigen subset van rows waar die feature bekend is (niet None).

3.7 MNAR-handling#

Sommige features zijn "presence features" - Funda vult het veld alleen in als het kenmerk aanwezig is. has_tuin is True als Funda "Tuin" vermeldt, anders None (niet False). Maar in werkelijkheid betekent het ontbreken van het Tuin-veld meestal dat er geen tuin is.

Oplossing: bij fit-tijd zetten we None → False voor deze 7 presence features: has_tuin, has_balkon, has_dakterras, has_storage, has_lift, has_private_parking, has_parking_garage.

3.8 Monte Carlo#

Input: area_m2, price, energy_label, build_year, city, has_garden,
       has_balcony, num_bedrooms, property_type

Stap 1 - bepaal cohort
  find Funda rows met area±25%, year±25, same type

Stap 2 - bereken deterministische punten
  area_pts     = area_m2 × 1.0
  energy_pts   = WWS_tabel[energy_label]
  outdoor_pts  = 3.0 if has_balcony else 0 + 3.25 if has_garden else 0
  woz_pts      = WOZ_formule(area_m2, city)
  deterministic_total = area_pts + energy_pts + outdoor_pts + woz_pts

Stap 3 - Monte Carlo loop (N=10.000 iteraties):
  for i in 1..N:
    heating_pts_i = sample(heating_points_per_room) × num_rooms
    sanitair_pts_i = som van 8 gesamplede sanitair features
    storage_pts_i = sample(has_storage) × sample(storage_type)
    lift_pts_i = sample(has_lift) × 1.0

    total_pts_i = deterministic_total + heating_pts_i + sanitair_pts_i +
                  storage_pts_i + lift_pts_i
    max_rent_i = WWS_tabel(total_pts_i)

Stap 4 - aggregeer:
  median_pts = mediaan van total_pts_1..N
  p5_raw, p95_raw = 5% en 95% percentielen
  # Schaalfactor k=1.15 (zie §4, gecalibreerd tegen deterministisch oracle):
  p5  = median - 1.15 × (median - p5_raw)
  p95 = median + 1.15 × (p95_raw - median)

  P(overpaying) = fractie van iteraties waar price > max_rent_i
  verdict =
    'free_market' als >50% van iteraties ≥187 punten
    'overpaying'  als P(overpaying) > 0.7
    'uncertain'   als 0.3 < P(overpaying) ≤ 0.7
    'fair'        anders

4. Calibratie: betrouwbaarheidsinterval#

Monte Carlo-sampling geeft van nature intervallen, maar die zijn empirisch te smal: onze "90% CI" bevat de waarheid maar in ~70% van de gevallen. Dit komt door:

1. Pool tightness: bootstrap uit 18 distinct values comprimeert de staarten.
2. Independent per-feature sampling: verliest joint correlaties, schuift massa naar het midden.

Calibratieprocedure#

We doen een 60/20/20 train/calibrate/test split op de quality-filtered Funda-rows (peildatum 2026-04-26: 9.359 rijen):

1. Train priors op 60%.
2. Op 20% calibratie-set: bereken voor elk listing de ratio |true_points − median_points| / gem_half_CI, vind empirisch de scale factor k die 90% coverage oplevert.
3. Test op 20% held-out data: pas k toe en controleer coverage.

Uitkomst calibratie (5 seeds, deterministisch oracle):

5. Accuratesse (cross-validation)#

Holdout-test: 80/20 random split op de quality-filtered Funda-rows. Priors gefit op train-set, predict op test-set met alleen WB-listing-level info (oppervlakte, energielabel, tuin, balkon, lift, parkeer-flags). De "oracle" gebruikt dezelfde calculator maar krijgt elk parsed sub-feature als override - zodat alle deterministische bijdragen (oppervlakte, WOZ, monument) wegvallen en de MAE puur de prior-driven onzekerheid meet.

Holdout-resultaten met deterministisch oracle#

10 random seeds × 400 stratified test rows = 4.000 holdout-comparisons (data: docs/comparisons/robustness_v6.json). Bootstrap 95% CI berekend over de 10 seed-gemiddelden. Stratificatie: random binnen offering_type (rent vs sale) en within-area-bin om te voorkomen dat één fold disproportioneel uit één segment komt.

Richting van de regulated bias: +1,99 pt betekent dat we gereguleerde listings (oracle <187 pt) gemiddeld te hoog scoren - we zien ze als minder gereguleerd dan ze zijn. Dat impliceert dat de gepubliceerde 57,7% te duur op Tier 1 een ondergrens is van het werkelijke percentage; het echte cijfer ligt waarschijnlijk 1-2 pp hoger (rond 60%). Individuele predicties kunnen ±10 pt afwijken; de systematische bias is statistisch significant maar materieel klein.

Root-cause analyse van regulated bias#

We hebben drie hypotheses getest om te begrijpen waarom regulated listings überhaupt een bias hebben (n=823, dezelfde holdout):

Conclusie: er is geen makkelijke fix voor de bias zonder structurele verandering aan de calculator. Voor de gepubliceerde headline (57.7% op Tier 1) kan dit betekenen dat het echte cijfer ~1-2 pp hoger ligt, maar we kunnen het niet exact corrigeren. We rapporteren daarom het "onbevooroordeelde" cijfer en vermelden deze nuance expliciet.

Reliability diagram (calibratie per CI-niveau)#

Standaard statistische toets: bij elk nominaal CI-niveau, hoeveel van de waarheden valt binnen het voorspelde interval? Idealiter 50% nominaal = 50% empirisch. Resultaat (n=4.000):

Conclusie: bij 50% is de calibratie correct (54%), maar bij hogere niveaus convergeert de empirische dichtheid bij ~80%. De CI's zijn niet breed genoeg in de staarten. Dit suggereert dat het Monte Carlo sampling de echte verdeling niet helemaal vangt voor outliers - wat een logische beperking is van bootstrap-sampling binnen een eindige cohort.

Bias per cohort - waar zit de afwijking?#

De gemiddelde bias op de full-WWS holdout is +0.36 pt (zie tabel boven), maar er zit heterogeniteit onder. Onderstaande sub-cohort-uitsplitsing komt uit een eerdere kleinere holdout-run (n=499, deterministisch oracle, vooral bedoeld om te zien waar de bias zich concentreert; voor de productie-MAE-cijfers zie de tabel hierboven). Bron: docs/comparisons/holdout_extras.json.

* Cellen met n < 100: bias/MAE puntschattingen - bootstrap-CI niet gerapporteerd vanwege beperkte sample size. De Regulated-cel met n=37 in het bijzonder is beperkt informatief; de productie-headline blijft de n=4.000 holdout-bias +1,99 (zie tabel boven). Deze sub-cohort tabel is bedoeld om waar de bias zich concentreert te tonen, niet om absolute getallen vast te leggen.

Binaire classificatie: gereguleerd vs vrije sector#

Op de full-WWS holdout (n=4.000) is de binaire classificatie (predicted <187 pt = gereguleerd) ~94% correct tegen het deterministische oracle. False-negatives (true gereguleerd gemarkeerd als vrije sector) zijn schadelijker voor huurders dan false-positives en concentreren zich aan de bovenrand van het regulated segment (180-186 pt) waar de MC-spreiding rond 187 ligt. Bron: docs/comparisons/robustness_v6.json.

6. WWSO (onzelfstandige woonruimte)#

Voor kamers geldt het Woningwaarderingsstelsel Onzelfstandige Woonruimte - een compleet ander puntenstelsel:

• Geen vrije-sectorgrens (kamers zijn altijd gereguleerd)
• Andere puntwaarden
• Gedeelde keuken/sanitair telt ÷ aantal_huurders
• WOZ via 3-tier COROP-vergelijking (10/12/14 punten)
• Onbekend energielabel: zelfde behandeling als bij WWS - per Monte Carlo iteratie gesampled uit P(label | bouwjaar, type), zie §10

Kern-onbekendheden#

Kamernet's mobile-API (~43% van onze kamerlisting-pool) geeft al deze velden expliciet. Voor andere bronnen vallen we terug op empirische priors:

Deze priors zijn empirisch gefit op 2.624 Kamernet-rows met bekende faciliteit-status.

7. Routing: WWS vs WWSO#

Elk listing moet naar de juiste calculator. Beslissingsregel:

if kamernet facility data says "any shared" → WWSO
if kamernet facility data says "all private" → WWS
elif property_type in {Kamer, Room} → WWSO
elif property_type in {Studio, Appartement, Woning, Flat, ...} → WWS
elif wws_is_onzelfstandig flag from pipeline → WWSO
else → WWS (default)

Geïmplementeerd in api/huurcheck/route_calculator.py.

8. Datapijplijn samenvatting#

1. FUNDA GROUND TRUTH (ad hoc, periodieke pyfunda runs)
   pyfunda → ground_truth_funda (12.162 rows totaal)
                                  ├─ 2.850 huur (offering_type='rent')
                                  └─ 9.217 koop (offering_type='buy')
   parser → parsed_features JSONB
   kwaliteitsfilter → 9.359 mixed training rows
                      (1.116 rent + 8.243 sale; zie §2.3 + §2.5)

2. KAMERNET FACILITIES (continu - groeit elke scrape-cyclus)
   kamernet_runner.py → kamernet_facilities (2.624 rows)
   Voor WWSO: keuken / douche / toilet / aantal huisgenoten

3. PRIORS (fit bij start van sessie)
   PriorStore.load() vanuit ground_truth_funda
   Per-feature kernel-bootstrap: rent-only voor 9 features
   met selectie-bias, rent + sale voor de overige
   Continue Gaussian-kernel weighting op (log-area, year)

4. INFERENCE PER LISTING
   route_calculator → wws of wwso
   calculate_wws_bayesian / calculate_wwso_bayesian
   N=10.000 Monte Carlo iteraties, k=1.15 CI-schaalfactor
   → BayesianResult (median, p5, p95, p_overpaying, verdict)

5. BACKFILL STORAGE
   bayesian_huurcheck tabel (listing_id primary key)
   Upserted na elke berekening, samen met data_quality_tier

9. Softwarecomponenten#

10. Belangrijke aannames en beperkingen#

Wat we expliciet NIET modelleren#

• Bouwjaar via BAG-lookup: voor het grootste deel van de Tier 1 listings hebben we het bouwjaar direct (uit listing of via BAG-koppeling); voor de rest fallback op 1975. Voor productie-niveau accuraatheid zou je postal_code + house_number → BAG → construction_year volledig integreren - dat is op de roadmap.
• Exacte WOZ-waarde via Kadaster: voor Tier 1 listings (n=22.614, ~40% van onze populatie) halen we de WOZ direct uit Kadaster's WOZ-waardeloket API op het exacte adres. Voor de overige listings zonder geverifieerd huisnummer geven we geen verdict - een schatting via stad × m² zou een mediane afwijking van ~36% hebben t.o.v. de werkelijke WOZ (zie §2.5 voor de tier-uitsplitsing).
• Rijksmonument-status: we koppelen elke listing aan het Rijksmonumentenregister via de RCE linked open data SPARQL endpoint (54.930 monumenten geladen, 547 listings gematcht = 1,0%, iets onder het NL gemiddelde van ~1,7% - verwacht omdat onze populatie urban-geconcentreerd is en rijksmonumenten gelijkmatiger over het land verspreid zijn). Bij match krijgt de listing de +35% rent-surcharge per Beleidsboek 2026 bijlage I.
• Energielabel-fallback (9% van Tier 1 listings, 1.941 stuks): voor 91% van Tier 1 hebben we een echt EP-online label; voor de overige 9% sampelen we per Monte Carlo iteratie een label uit de empirische verdeling P(label | bouwjaar, dwelling_type) gefit op 10.245 Funda-rows (zie api/huurcheck/energy_label_dist.json). Het 90% CI verbreedt daarmee automatisch voor listings zonder label - geen vals-tight interval. We hebben een deterministische bouwjaar-tabel-fallback ook getest: 30,8% exact match en −6,87 pt systematische bias. Door per iteratie te sampelen verdwijnt die bias en blijft alleen de echte epistemische onzekerheid over, weerspiegeld in de breedte van het interval. Bron: docs/comparisons/energy_label_validation.json.
• Tuin-oppervlakte: Funda populeert dit veld in <5% van de rows. We gebruiken typische waarden per outdoor_type.

Bias-waarschuwingen#

• Funda is mid/high-end biased: 93% van onze Funda-sample scoort in de vrije sector. Voor gereguleerde-segment inferentie gebruiken we Funda daarom alleen als bron voor fysieke structuur (sanitair, verwarming), niet voor prijs.
• Funda filter bias: training rows moeten Badkamervoorzieningen hebben. Dit filtert ~50% weg. Hierdoor zijn onze priors over sanitair gebaseerd op rows van verhuurders die het veld wél invulden - mogelijk iets hoger geklassificeerde woningen.

Onbekende onbekenden#

• We herkennen niet als een listing "zorgwoning" is (+35% rubriek 1-11).
• We herkennen niet als een listing "nieuwbouw na 1-7-2024" is (+10% op totaal volgens Wet betaalbare huur).
• Gemeentelijk/provinciaal monument (+15% rent surcharge) en beschermd stads-/dorpsgezicht (+5%) modelleren we niet - er is geen openbaar landelijk register met BAG-id-koppeling. Alleen rijksmonumenten (+35%) krijgen we via RCE LOD.

Voor aggregate marktrapportage is dit verwaarloosbaar (<2% van de populatie is getroffen). Voor individuele huurcheck-verdicts zou dit een apart signaal moeten zijn.

11. Referenties#

• Besluit huurprijzen woonruimte (Bijlage I, onderdeel A - zelfstandige)
• Besluit huurprijzen woonruimte (Bijlage I, onderdeel B - onzelfstandige)
• Beleidsboek Waardering Woonruimte 2026 (Huurcommissie)
• Wet betaalbare huur (Staatsblad 2024, 195) - introductie 187-punten grens