RFC-019: Chronolexogram types + MBO/FCID integration + CJIB casus#690
Draft
anneschuth wants to merge 13 commits into
Draft
RFC-019: Chronolexogram types + MBO/FCID integration + CJIB casus#690anneschuth wants to merge 13 commits into
anneschuth wants to merge 13 commits into
Conversation
…orstel Voorstel om RegelRecht en Mijn Betaaloverzicht (MBO, voorheen VORIJK) te koppelen in twee richtingen: RegelRecht als producer van FCID-events (via nieuwe decision_type-waarden + fcid_emit/fcid_category op produces), en als consumer via een wrapper-regeling met CJIB als competent_authority. Hergebruikt RFC-009 FSC-trust-model volledig. Drie deliverables: - proposals/cjib-mbo-bridge.md — voorstel-document voor CJIB-directie - docs/concepts/cjib-uitvoeringslandschap.md — inventarisatie CJIB-portfolio - docs/rfcs/rfc-019.md — technische uitwerking (Proposed)
Volledige conceptuele herziening op basis van het Chronolexografie-position paper (Olthof & Van Andel, dec 2025) en Nieuwland (Achterkant van de Overheid, dec 2025). Belangrijkste verschuivingen: - Strikt onderscheid lexogram / decretogram / executogram. BETALING_VERWERKT uit decision_type-enum gehaald; betalingen zijn executograms (registratie van feit), geen besluiten. - Nieuwe top-level corpusmap corpus/executogram/ met eigen schema, parallel aan corpus/regulation/. Respecteert Nieuwland §5.2 "respectvol onderscheid tussen registreren en interpreteren". - RegelRecht-engine herbenoemd als chronolexocel; executie als chronolexoreductie; output als lexostatus. - decision_type-uitbreiding nu alleen decretogram-types: BETALINGSVERPLICHTING, STRAFBESCHIKKING, BESTUURLIJKE_BOETE, INCASSO_BESCHIKKING, INTREKKING_BESCHIKKING. - Voorstel-document herframed met expliciete Nieuwland-verbinding, inclusief Olthof als brug-figuur naar VORIJK en Eelco's rol als geïnterviewde. - Inventarisatie kreeg chronolex-rol-kolom per opdrachtgever (decretogram-cel vs executogram-cel) en aparte sectie "Mapping op de drie chronolexogram-types".
Eelco's feedback: een RFC die zowel chronolexogram-architectuur als één specifieke integratie als één casus dekt, doet drie dingen tegelijk en overleeft externe veranderingen niet. Opgesplitst in drie samenhangende deliverables: 1. RFC-019 (generiek): chronolexogram types als eerste-klas concepten in schema en corpus. Lexogram = regulation, decretogram = BESCHIKKING, executogram = nieuwe corpus/executogram/. decision_type uitgebreid met vijf financiële-domein waarden. outbound_emit/outbound_category als neutrale integratie-hooks. Geen FCID, MBO of CJIB in de definities. 2. docs/integrations/mbo-fcid.md (nieuw): concrete spec voor FCID v4.x integratie. Veld-derivaties, signing, consumer-wrapper. Target FCID v4.x en kan mee-evolueren zonder RFC-proces. 3. proposals/cjib-mbo-bridge.md: casus. Korter en sterker, verwijst naar de andere twee plus inventarisatie. Concrete pilot-doelstelling met tijdslijn van een maand na werksessie. CJIB-uitvoeringslandschap: cross-links bijgewerkt naar zowel RFC-019 als integratie-doc; FCID-mappingsectie ingekort onder verwijzing naar integratie-doc. Build groen (64 pagina's), em-dashes in voorstel 0, kruislinks werken in beide richtingen.
Zes punten van conceptuele kritiek opgepakt: 1. Cel is een juridisch/organisatorisch domein, geen engine. Engine is een component dat in een cel kan draaien, naast andere componenten of legacy. Cel-definitie en taalgebruik door alle 4 documenten consistent gemaakt. 2. corpus/executogram/ verhuisd naar chronicles/ als top-level directory naast corpus/. Een chronicle-stream is een registratie-specificatie, geen regeling; ze horen niet onder corpus/ vermengd met normatieve inhoud. 3. Anonieme outbound_emit/outbound_category vervangen door namespaced extensions-blok (produces.extensions.mbo_fcid.category). Schema toont nu welke integratie het gedrag drijft. Activatie verhuist naar cel-config: een gemeente die Wahv uitvoert maar geen MBO-link heeft, hoeft niet de regeling te forken. 4. Wrapper-regeling procedureregeling_vorderingenoverzicht_rijk weg. Vervangen door nieuw source.kind: lexostatus_query met velden cell en lexostatus. Geen valse procedureregeling meer in corpus/regulation/. 5. decision_type-uitbreiding opgeschoond naar drie schone types: BETALINGSVERPLICHTING, STRAFBESCHIKKING, BESTUURLIJKE_BOETE. INCASSO_BESCHIKKING weg (executoriale titel, niet primair besluit). INTREKKING_BESCHIKKING weg (modaliteit, niet type) en vervangen door produces.modality.is_intrekking_van/is_wijziging_van. 6. Nieuwland §7.2.1 (wat als straf uitwerkt verdient rechtsbescherming als straf) als ontwerp-eis geoperationaliseerd: verplicht bezwaarbaar-blok op decretogrammen en executogrammen met rechtsgevolgen. bezwaar_route reist mee in FCID-emissie. Geen citaat-zonder-implementatie meer. 64 pagina's groen, voorstel-document 0 em-dashes, kruislinks geverifieerd.
De begrippentabel-vóór-Context oogde academisch en hield de lezer op
voordat het probleem was geïntroduceerd. Bovendien sloot de Decision-
volgorde niet logisch aan op de naamgevende kapstok van de RFC.
Veranderingen:
- Open met Context (proza), niet met tabel.
- Korte Terminology-paragraaf in RFC-005-stijl, alleen voor het misverstand
dat de meeste RegelRecht-lezers zullen hebben: engine ≠ cel.
- Decision herstructureerd:
§1 De drie chronolexogram-types als naamgevende kapstok
§1.1 Lexograms (bestaan al)
§1.2 Decretograms (decision_type uitbreiding)
§1.3 Executograms (chronicles/ directory)
§2 De cel als juridische eenheid (drager van wat §1 introduceert)
§3 Drie cross-cutting velden die op elk chronolexogram gelden
§3.1 modality
§3.2 extensions
§3.3 bezwaarbaar
§4 Cross-cell queries (source.kind: lexostatus_query)
§5 Out of scope
- §-verwijzingen bijgewerkt in integratie-doc en inventarisatie:
§2 → §1.2, §2.1 → §3.1, §3 → §1.3, §5 → §3.2, §7 → §3.3
…orpus review Drie samenhangende reparaties op basis van een cross-RFC review: 1. **RFC-008 respecteren.** Eerdere versie introduceerde een per-rule `bezwaarbaar`-blok met `termijn_dagen: 42`. Dat dupliceerde precies wat RFC-008 al netter doet: bezwaartermijn wordt berekend bij BEKENDMAKING (AWB 6:8), niet bij BESLUIT, en kan dus geen statische hint op een produces-blok zijn. Verwijderd. In plaats daarvan: integraties leiden `bezwaar_route` af uit RFC-008 procedure-state op het moment van emissie (typisch BEKENDMAKING). Mapping per stage in de integratie-doc. Intrekking is geen modaliteit-met-eigen-event maar een nested BESCHIKKING per RFC-008 (Open Question 5, resolved). 2. **Bredere framing van Context.** Eerdere versie zei "23 regelingen" alsof dat een maatstaf was. Vervangen door verwijzing naar het conceptueel raamwerk (BESCHIKKING, decision_type, IoC, AWB lifecycle, FSC-federatie, IoC, federated corpus, provenance) dat schaalbaar is naar duizenden wetten. De 23 zijn voorbeelden, niet de scope. 3. **Cross-RFC review verwerkt.** RFC-002: cell-identiteit IS competent_authority, geen nieuw begrip. RFC-010: chronicle-streams gebruiken dezelfde federated-corpus loading. RFC-013: chronicle-streams in Execution Receipt's loaded_artifacts voor reproduceerbaarheid. Schema-bump v0.5.2→v0.6.0 expliciet als minor: alle changes additief, source.kind default `regulation` voor backward compat. Depends-on header toegevoegd voor alle zes RFC-afhankelijkheden. Build groen (64 pagina's), voorstel 0 em-dashes, kruislinks geverifieerd.
Acht punten uit een cross-document consistency-audit: - RFC-019 §3.2: emit_at_stage expliciet opnemen in het extensions YAML- voorbeeld en uitleggen als integration-namespaced field (was eerder alleen in integratie-doc, niet erkend in RFC-019). - Integratie-doc tabel: BetalingsverplichtingIngetrokken-rij verduidelijkt dat decision_type hetzelfde blijft als het origineel, alleen modality wijst naar het origineel. - Integratie-doc Activation: cell-config sketch is provisioneel gelabeld met expliciete forward-reference naar future cell-config RFC. - Voorstel: YAML-voorbeeld toegevoegd van Wahv-artikel inclusief intrekking-variant met modality.is_intrekking_van, zodat de drie pilot-artefacten ook in code-vorm zichtbaar zijn. - Voorstel "Volgende stap": circulaire framing weggehaald (RFC-019 hoeft niet "in de RegelRecht-repo" gespecificeerd te worden; ze leeft er al). - Voorstel: schema-bump-versie v0.5.2 → v0.6.0 expliciet genoemd in de volgende-stap-paragraaf. Niet aangepakt (audit-suggesties waar bewust van afgeweken): - references_decision parameter-binding: extensions is per definitie een free-form namespaced map, de integratie kiest wat erin staat. - Mapping-tabel dupliceren in voorstel: voorstel verwijst naar integratie- doc voor details, duplicatie zou alleen lengte toevoegen. Build groen (64 pagina's), voorstel 0 em-dashes, kruislinks consistent.
Dutch juridical/domain terms (beschikking, bezwaar, bekendmaking, intrekking, kwijtschelding, gemeente, opdrachtgever, rechtsbescherming, etc.) in markdown italics when they appear in English-language prose, per the convention already established in RFC-008 and RFC-009. Italicized at first introduction per section, not at every occurrence (avoids markup soup). Voorstel-document blijft onaangepast (is in Dutch geschreven). Bonus: RFC-019 Context-zin "Three things are still missing" suggereerde een complete inventarisatie. Vervangen door "That coverage is still being built out. This RFC picks up three pieces that block a concrete next step." Eerlijker over scope.
Cross-RFC "uitvinden-vs-hergebruiken" audit leverde drie punten op: 1. Cell-section in RFC-019 §2 framede "cell" alsof het een nieuw concept was. Het is gewoon de Chronolexografie-naam voor wat RFC-002 al `competent_authority` noemt en RFC-009 als `EngineIdentity` aan de engine-kant beschrijft. Sectie hernoemd naar "Naming the cell: it is RFC-002's competent_authority" en de tabel verwijst nu per regel naar welke bestaande RFC het concept dekt. 2. Modality-section §3.1 leek een orthogonaal mechanisme te introduceren. In werkelijkheid is `modality.is_intrekking_van` alleen een backlink- veld binnen RFC-008's al-bestaande nested-procedure model (Open Question 5, resolved). Tekst herformuleerd om dat duidelijk te maken. 3. Source.kind: lexostatus_query — verzon `kind`, `cell:`, `lexostatus:` waar het bestaande `source.regulation` + `source.output` (RFC-007) al precies hetzelfde uitdrukken. Volledig geschrapt. Resolver krijgt alleen een nieuwe semantiek: als source.regulation in de FSC service registry een cel is, ACCEPT-path; anders huidige resolutie. Geen schema-change voor cross-cell queries, geen nieuwe velden, geen nieuwe discriminator. Eén regulator-conventie hergebruikt. Schema-bump v0.5.2 → v0.6.0 nu nog kleiner: alleen drie decision_type- waarden, modality, extensions. Source-blok onaangeraakt. Build groen (64 pagina's), kruislinks consistent.
…n framing-fixes Voorstel-doc absorbeert nu het CJIB-uitvoeringslandschap en de FCID-mapping als bijlagen A en B. RFC-019 blijft generieke architectuur. De twee aparte docs in docs/concepts en docs/integrations vervallen. Feiten-fixes na audit: - Awb 3:9 (advisering) vervangen door Awb 3:46 (motiveringsplicht) - FCID v4.2.0 is experimenteel; baseline v3.0.0, pad naar v4.x - Schema-bump v0.5.2 -> v0.6.0 consistent als voorgesteld geframed - CRI-aantal: 8 oorspronkelijk, ~15 inclusief Betalingsregeling Rijk Framing-fixes voor CJIB-lezer: - Expliciete 'naast, niet vervangen'-sectie aan kop - Woordenlijst voor Chronolexografie-termen in CJIB-taal - Eigen tegenprestatie expliciet (lexogram, sandbox, koppelteam) - Wahv-pilot-keuze beargumenteerd (helder kader, meetbare baseline, lage foutmarge) - Bezwaar-routing-vraag scherper: formele vs operationele realiteit - MBO/VORIJK naamgeving consistent (MBO als hoofdnaam) - Em-dashes uit voorstel
Mijn Betaaloverzicht draait op Blauwe Knop Connect, een pull-based, citizen-initiated standaard met on-device aggregatie en data-at-source. Het eerdere voorstel framed dit als 'push naar MBO-endpoint', wat het on-device-only principe brak. Deze commit corrigeert dat: - extensions.mbo_fcid -> extensions.blauwe_knop met FCID als payload-type - emit_at_stage -> visible_from_stage (Blauwe Knop is pull, geen push) - Cel publiceert een Blauwe-Knop-source-endpoint dat op burger-pull een ondertekende FCID-response teruggeeft; geen centrale aggregatie - Cross-cell queries (RFC-019 §4) ondersteunen nu twee transporten: Blauwe Knop voor citizen-clients, FSC voor authorised servers - Cel-runtime kiest transport op grond van cel-context (blauwe_knop_client vs fsc_client rol); regeling-YAML blijft transport-agnostic - Design principle 8 toegevoegd: citizen-side aggregation preserved - Alternatives 8 en 9 toegevoegd: FSC-only en push-based afgewezen Voorstel-doc herframed: RegelRecht maakt elke uitvoeringsorganisatie een Blauwe-Knop-source met volledige juridische provenance. CJIB-pilot draait een tweede source naast CJIB's bestaande Blauwe-Knop-implementatie ter verificatie. Geen vervanging, geen centrale aggregatie, geen nieuw broker- mechanisme.
Conceptuele scherpstellingen: - Lexostatus expliciet gedefinieerd als resultaat van chronolexoreductie; cellen declareren capabilities.yaml met reductie-logica per lexostatus. openstaande_vorderingen is geen impliciete engine-output maar een cel-eigen samenvoeging van meerdere chronicles met expliciete filters. - Vocabulair: decretogram IS engine-output, executogram IS chronicle-stream- entry. FCID is een serialisatie ervan, geen tweede laag. Tabellen en paragrafen herfraseerd. - 'role' framing weg waar het op Blauwe-Knop-rollen leek (BK kent geen rollen-concept). Cell-config heeft directe feature-blokken: blauwe_knop_source, blauwe_knop_client, fsc_client. Harde guards: - visible_from_stage is een harde guard, niet een hint. Decretogrammen zonder BEKENDMAKING vallen weg uit FCID-response: geen placeholder, geen partial bezwaar_route. Voor financiele-handhavings-decision-types is verlagen onder BEKENDMAKING niet toegestaan. Pilot-uitbreiding: - Drie casuistiek-klassen in plaats van alleen Wahv: Wahv-baseline + CAK-eigen-bijdrage (mandaat-test) + optioneel OM-strafbeschikking (UOV-procedure). Mismatch in CAK-bezwaarroute is showstopper voor week 2 van de werksessie. - Deduplicatie-strategie tussen bestaande en RegelRecht-source als expliciete vraag 6 aan CJIB + open vraag 11 in bijlage A. trace_id toegevoegd als sleutel voor MBO-app-deduplicatie. Eerlijke positionering: - Samen-zien wederkerigheid expliciet als out-of-scope: voorstel adres- seert burger-kant van Nieuwland §5.4, niet de organisatie-kant. - chronicles/ als architectuurvoorbereiding op toekomstige Wet gegevens- boekhouding (Nieuwland §7.3.2). - RFC-019 raakt RFC-007 (cel-resolutie in source.regulation) en RFC-009 (sleutelhergebruik FSC <-> Blauwe Knop JWS): canonieke amendementen na werksessie, voor pilot pragmatisch geaccepteerd. FCID-mapping aanscherpingen: - juridische_grondslag_omschrijving als artikel-verwijzing (niet eerste zin van article.text die FCID-veldlimiet overschrijdt). - bedrag afronding expliciet als beleidsregel-detail dat in lexogram wordt gecodificeerd. - zaakkenmerk gedeeld over meerdere FCID-records van een verplichting, onderscheiden door category. - signature per response (BK-spec), niet per record.
anneschuth
force-pushed
the
proposal/cjib-mbo-bridge
branch
from
c66a711 to
346fff1
Compare
anneschuth
added a commit
that referenced
this pull request
Jun 10, 2026
RFC-016 is al geclaimd door PR #510/#511 (foreach) en RFC-019 door PR #690, dus dit RFC krijgt nummer 020. Daarnaast de tekst in lijn gebracht met de implementatie: de EQUALS-datumfallback is gescoped tot de gemengde vorm (string vs {iso}-object), de canonieke-vorm-afwijzing geldt luid voor de ordeningsoperatoren en datumoperaties maar stil voor EQUALS, en de non-breaking-claim benoemt nu expliciet dat de strikte parsing ook AGE/DATE_ADD/DAY_OF_WEEK bereikt. Status naar Accepted. Versie-register in schema.md aangevuld met v0.5.3 (incl. de onafhankelijke versionering van het annotatieschema) en de operatietabel in law-format.md bijgewerkt naar 22 operaties.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Drie samenhangende deliverables die RegelRecht conceptueel inhaken op Chronolexografie/Nieuwland en concreet op Mijn Betaaloverzicht (FCID), met CJIB als eerste pilot-cel:
docs/src/content/rfcs/rfc-019.md): generieke architectuur. Lexogram/decretogram/executogram als first-class concepten.chronicles/als nieuwe top-level directory voor registratie-specs (parallel aancorpus/).decision_typeuitgebreid met drie financiële-domein waarden.extensionsnamespace voor integratie-hooks.source.kind: lexostatus_queryvoor cross-cell queries. Cel als juridisch/organisatorisch domein, met de engine als één mogelijk component.docs/src/content/docs/integrations/mbo-fcid.md): concrete spec voor FCID v4.x. Velden-mapping, stage-binding op RFC-008 BEKENDMAKING,bezwaar_route-derivatie uit RFC-008 procedure-state.docs/src/content/docs/concepts/cjib-uitvoeringslandschap.md): inventarisatie van CJIB-portfolio (eigen + 15+ opdrachtgevers), met chronolex-rollen per cel, BWB-IDs, en data-gaps expliciet gemarkeerd.proposals/cjib-mbo-bridge.md): casus voor CJIB-pilot met Wahv, vijf concrete vragen, werksessie-agenda.Hoe dit past op de RFC-corpus
Bouwt op RFC-002 (cell-identiteit = competent_authority), RFC-007 (
source.kinddiscriminator), RFC-008 (AWB lifecycle voor stage-aware emissie en bezwaar_route-derivatie), RFC-009 (FSC, cel-identiteit, signing), RFC-010 (federated loading ook voor chronicles), RFC-013 (chronicle-streams in Execution Receipt voor reproduceerbaarheid).Schema-bump v0.5.2 → v0.6.0 is minor: alle changes additief,
source.kinddefaultregulationvoor backward compatibility, geen bestaande YAML breekt.Status
Draft. De RFC is door zeven iteraties heen gegaan, inclusief een Olthof-review en een cross-RFC-corpus-review. Klaar voor inhoudelijke discussie met Eelco Hotting, Timen Olthof en CJIB. Implementatie is bewust uitgesteld tot na werksessie en goedkeuring.
Commits
Test plan
just docs-buildgroen (64 pagina's)/rfcs/rfc-019/,/integrations/mbo-fcid/,/concepts/cjib-uitvoeringslandschap/