12 · Signalen en voorkeuren — wat we weten, wat ontbreekt, en de weg naar de graaf

Onderzoeksagent R12 · 24 september 2026 · alleen lezen in ~/Developer/mi-casa-presentatie, niets gewijzigd, geen git, geen sleutels geraadpleegd. Bronnen: code-commentaarkoppen, server/README.md, OVERDRACHT.md §4/§7, CONCEPT-V3.md §6–9/§13, brainstorm 10/11/13/15, onderzoek/07-recht-en-ethiek.md.

Samenvatting in tien regels

1. We tellen al veel, maar bijna alles is óf per persoon (web, tafel, fans) óf volledig anoniem zonder vorm (bewijsbord). Er is nog niets ertussenin: geaggregeerd, met een thema.
2. "Leuk vinden" zien we alleen indirect: een ♥, een beantwoorde kleine vraag, warm/griezelig. Geen van die signalen wordt geteld per thema, straat of bouwperiode.
3. De rijm-thema's (ochtend·licht·buiten·rust·beneden·tuin·water·ov, teksten.json sleutel rijm.themas) worden live herkend in elk gesprek, maar nergens bijgehouden na afloop.
4. Chip-keuzes ("Wat weet je nog meer?", "Bewaar mijn huis") tellen expliciet niet mee in het bewijsbord — lib/telling.mjs noemt ze met naam als voorbeeld van wat bewust ongeteld blijft.
5. Precedent bestaat al: de Mi Data-toggle "wijkscore" (routes/midata.mjs, D15/D44) is voorbereid als opt-in doel, maar er is nog geen wijkscore die hij voedt.
6. Het huis-web (lib/web-graaf.mjs) is al een graaf met knopen en kanten in twee talen — het juiste schema om een geaggregeerde laag náást te zetten, niet in.
7. De harde grenzen (OVERDRACHT §4) raken deze laag rechtstreeks: geen coördinaten, geen prijs, en aggregatie moet aggregatie blíjven, ook in het ontwerp van de teller zelf.
8. Een geaggregeerde kant heeft dezelfde vorm als een feitelijke kant (huis→bron, feit→bron), maar zijn bron is nooit een register — "wat mensen hier zeiden", nooit "wie", zichtbaar in de graaf zelf.
9. Voor zaterdag kan het bewijsbord (al gebouwd, al gepland om 0:40) zonder nieuwe bouw getoond worden; een thema-telling voor de sessie zelf is met een paar uur werk haalbaar.
10. Wat we niet weten: of het huidige bezoekersvolume snel genoeg de drempel van vijf haalt om iets zinnigs te laten zien — een meetvraag, geen ontwerpvraag.

2 · Inventaris — signalen die we al vastleggen

3 · Wat ontbreekt en goedkoop toe te voegen is

(Alle sleutels landen in dezelfde tellerstabel, §4.) Geen cijfers hier: er is nog geen gemeten volume.

4 · De signalenlaag: schema en regels

Eén gebeurtenistabel, naar het patroon van lib/telling.mjs (tabel tellers, een groep en een sleutel die je ophoogt — geen rij per gebeurtenis, één teller per combinatie):

groep: 'signalen'
sleutel: '<soort>:<dag>:<wijkCode|"-">:<straatCode|"-">:<bouwjaarDecennium|"-">:<thema|"-">:<taal>'
waarde: geheel getal

• soort uit een vaste lijst (zoals SOORTEN in telling.mjs): onbekende soorten tellen niet.
• Geen persoonId, geen sessie-id, geen IP, geen vrije tekst. Alleen buckets: wijk-code (niet straatnaam, tenzij het signaal per straat is), bouwjaar afgerond op tien jaar, thema-sleutel uit een vaste lijst, dag (Amsterdam, zoals dagVan()), taal.
• Geen rauw event-log. Zoals bij telling.mjs: de teller gaat meteen omhoog, er wordt geen losse rij met tijdstip en context bewaard — zo dwingt de code "geaggregeerd, nooit per persoon" af.
• Drempel k ≥ 5 vóór iets van deze laag naar buiten gaat — strenger dan het bestaande fan-voorbeeld ("van de dertien schreven er vier over licht", v3 §9, dat op "meer dan één" zit). Onder de drempel bestaat het getal wel in de tabel, maar geeft geen route het terug.
• Eigenaar ziet: alles van zíjn eigen huis, ook onder de drempel (zoals nu bij tafel en web). Bezoeker/zoeker ziet: nooit iets over een individueel huis of andermans straat; hooguit een wijk-brede zin bij k ≥ 5, in dezelfde toon als het fan-voorbeeld.
• Bewaartermijn: de tellers blijven staan zoals het bewijsbord vandaag blijft staan (niet geraakt door POST /api/reset, dit is bewijs voor de zaal, geen demo-data) — zie §8 voor de juridische vraag of dat zonder einddatum mag.
• Demo-modus: verandert nergens gedrag; voegt alleen een paneel toe aan het bestaande bewijsbord (/#/bewijs) — precies "demo-modus verbergt presentatie, nooit gedrag" (D51).

5 · Naar de graaf

Nieuwe, geaggregeerde kanten (nooit vertrekkend vanuit een jij-knoop):

• thema —vaak-gewenst-in→ wijk, eigenschappen { aantal, periode }
• weetje —vaak-leuk-gevonden-bij→ bouwperiode (decennium-knoop, nieuw)
• straat —vaak-gevraagd→ wijk (of een teller-eigenschap op de bestaande straat-knoop)
• soort feit —krijgt-vervolg→ thema of wijk, afhankelijk van wat het feit is

Herkenbaar naast de feitelijke kanten. De bestaande kanten weet-uit/komt-uit wijzen naar een bron-knoop met een uitgever (BAG, EP-Online, Wikipedia, …). Een geaggregeerde kant krijgt dezelfde vorm maar wijst naar een bron-knoop "Mi casa su casa, bezoekers" (analoog aan de bestaande bron "Mi casa su casa, demo") — nooit een naam, altijd "wat mensen hier zeiden". Dat houdt het spraakrecht uit relaties.mjs (magKlinken) overeind: een geaggregeerd gegeven is geen gezegd-relatie van één persoon en krijgt dus geen ik-vorm in de mond van een huis — het is weerbericht, geen citaat.

Drie inzichten, realistisch binnen een maand, gegeven dat vandaag alleen Wittevrouwen als pilot-wijk draait (OVERDRACHT.md §3):

1. Thema-verdeling van wensen binnen Wittevrouwen, per straatcluster i.p.v. per wijk (er is er nog maar één) — een eerste, kleine versie van het "weerbericht van behoeften" (brainstorm 15 §3).
2. Welk station (deur/huis/straat/wijk/web) het vaakst "griezelig" scoort — bestaat al (routes/bewijs.mjs), geen nieuwe bouw nodig, precies het gesprek van 0:40 zaterdag.
3. Welk type vervolgvraag (chip) het vaakst volgt op welk soort feit — pas mogelijk zodra §3/§4 gebouwd is, met beperkt werk (twee, drie plekken in machine.mjs).

Eerlijk erbij: of 1 en 3 de drempel van vijf binnen een maand halen, hangt af van hoeveel bezoekers door de wijk bladeren — een meetvraag, geen ontwerpvraag.

6 · Voor de teamsessie van zaterdag

Zonder nieuwe bouw: het bewijsbord staat al op het programma (TEAMSESSIE.md, 0:40 "Warm of griezelig") en telt al zes gebeurtenissen plus reacties per station — een eerste "de stad droomt"-bord, alleen nog zonder thema.

Met een paar uur, licht en tijdelijk: tel tijdens de sessie zelf, in het geheugen van het proces (geen nieuwe opslag, geen migratie), hoe vaak herkenThemas() elk thema herkende in de wensen die de zaal typt — een eerlijk, live staafje "waar de zaal vandaag van droomde", zonder de grenzen te raken.

Het eerlijke verhaal: we weten nog niet welk weetje echt raakt, welke chip het vaakst gekozen wordt, of welke straat het meest gevraagd wordt — een gat in het meten, niet in het ontwerp, en precies wat deze signalenlaag oplost zodra hij er is.

7 · Plan op agent-niveau

8 · Waar de jurist later naar moet kijken (kort, niet remmend)

• Of k ≥ 5 volstaat, of hoger moet in een kleine wijk met weinig verkeer (open vraag, brainstorm 10 §"Later toetsen").
• Of wijk + bouwperiode + thema, ook geaggregeerd, bij een kleine steekproef herleidbaar wordt — het uitsluitingsrisico dat 07-recht-en-ethiek en brainstorm 11 al signaleren, nu op een nieuwe telling.
• Bewaartermijn van de tellers: mogen ze zonder einddatum blijven, of moeten ze net als een relatie "afkoelen"?
• Grondslag voor het tellen van gedaan/afgeleid-achtig gedrag ten behoeve van een geaggregeerd getal, ook al mag het nooit individueel klinken (magKlinken()) — is aggregeren zelf al een aparte verwerking?
• Verhouding tot de Mi Data-toggle "wijkscore" (D15/D44): dezelfde belofte, of moet hij expliciet gekoppeld worden voordat hij iets telt?

Niet vastgesteld: er is geen enkele bestaande aggregatie van thema/straat/weetje-frequentie aangetroffen in de code — sectie 3 is dus een ontwerp, geen beschrijving van iets dat al draait. Ook is onbekend hoeveel verkeer de pilot vandaag draait, dus of de drempel k ≥ 5 binnen een maand gehaald wordt, kon ik niet vaststellen.