Functionele beslisregels en uitgangspunten

19.1 Doel

Dit hoofdstuk beschrijft domeinbrede functionele beslisregels en uitgangspunten die in meerdere FO-hoofdstukken terugkomen.

Het hoofdstuk is bedoeld als samenhangende interpretatielaag boven de afzonderlijke domeinhoofdstukken.

Het voorkomt dat dezelfde basisregels in ieder hoofdstuk opnieuw volledig worden uitgeschreven.

Dit hoofdstuk vervangt niet:

• usecases;
• schermdocumentatie;
• database-informatie;
• ontwerpbronnen;
• statusmodellen;
• autorisatiematrix;
• command-register;
• event-register;
• popup-register;
• TO;
• SRS.

Wanneer een detailregel in een bronregister of usecase preciezer is uitgewerkt, blijft die bron leidend voor dat detail.

19.2 Bronpositie

Functionele beslisregels hebben binnen het FO een overkoepelende rol.

Bronlaag	Rol voor dit hoofdstuk
FO-hoofdstukken	Beschrijven per domein de functionele samenhang en grensregels.
Ontwerpbronnen	Bevatten bronhoudende business rules, autorisatiematrix, statusmodellen, command- en eventregisters.
Usecases	Beschrijven concrete flows, actoren, stappen, uitzonderingen en acceptatiecriteria.
Database-informatie	Beschrijft brondata, history, readmodels, technische grenzen en persistente relaties.
Schermdocumentatie	Beschrijft zichtbare schermen, acties, lege toestanden, fouttoestanden en waardelagen.
Oefenmodule-documentatie	Beschrijft module-specifieke configuratie, payloads, rendering en antwoordcontrole.
Architectuurdocumentatie	Beschrijft systeemgrenzen, containers en technische contexten die functionele gevolgen hebben.

Dit hoofdstuk mag dus samenvatten en verbinden, maar hoort geen bronregisters te dupliceren.

19.3 Domeinafbakening

De regels in dit hoofdstuk gelden breed voor OefenHub.

Onderwerp	Binnen dit hoofdstuk	Niet binnen dit hoofdstuk
Autorisatie	Overkoepelende server-side beslisregels.	Complete autorisatiematrix per route, object en actie.
Context	Algemene regels rond rol-, relatie-, niveau-, kind-, docent- en beheercontext.	Volledige contextresolutie per usecase.
Readmodels	Functionele status van readmodels, tellers, badges en filters.	Querytechniek, indexing of performanceoptimalisatie.
Historie	Algemene reconstructie- en auditprincipes.	Volledige databasetabellen of technische retentionimplementatie.
Mutaties	Algemene regels rond command, transactie, audit en idempotentie.	Concrete commandhandlers of API-contracten.
Foutafhandeling	Algemene privacy- en veiligheidsgrenzen.	Exacte popupteksten of UI-copy.
Modules	Algemene schema- en payloadprincipes.	Module-specifieke vraaglogica en configuratievelden.
Realtime	Functionele grens van live updates.	SignalR-implementatie, verbindingstopologie of retrycode.

19.4 Regeltypen

Binnen OefenHub komen meerdere soorten regels voor.

Regeltype	Betekenis	Primaire bron
Business rule	Domeinbrede regel met stabiel BusinessRule-ID.	Ontwerpbron business rules.
Autorisatieregel	Regel die bepaalt wie wat mag zien of doen.	Autorisatiematrix, usecases en FO-domeinhoofdstukken.
Statusregel	Regel rond toegestane statussen, overgangen en afgeleide labels.	Statusmodellen en domeinhoofdstukken.
Commandregel	Regel rond een gebruikersactie of systeemactie.	Command-register en usecases.
Eventregel	Regel rond betekenisvolle domeingebeurtenissen.	Event-register en database-/historybronnen.
Schermregel	Regel rond zichtbare UI, lege toestand of foutweergave.	Schermdocumentatie en UX-hoofdstuk.
Dataregel	Regel rond brondata, readmodels, history en persistente grenzen.	Database-informatie.
Module-regel	Regel rond technische oefenmodules en payloadinterpretatie.	Oefenmodule-documentatie en module-Fo-hoofdstukken.

Wanneer regels elkaar raken, wordt de meest specifieke bron gebruikt voor de concrete uitwerking.

19.5 Interpretatieregels

Voor het lezen van alle FO-hoofdstukken gelden de volgende interpretatieregels.

Regel	Betekenis
FO is functioneel	Het FO beschrijft gedrag, samenhang, rollen, grenzen en bronpositie.
TO is technisch	Technische implementatiedetails horen in het TO, niet in dit FO.
SRS is toetsbaar	Requirements, acceptatiecriteria en testbare eisen worden later in de SRS afgeleid.
Usecases blijven leidend voor flows	Het FO dupliceert geen volledige flowstappen wanneer de usecase bronhoudend is.
Database-informatie blijft leidend voor brondata	Het FO benoemt brondata en readmodelgrenzen, maar schrijft geen DDL uit.
Schermdocumentatie blijft leidend voor zichtbare UI	Het FO beschrijft schermsamenhang, niet elk label, veld of pixel.
Ontwerpbronnen blijven leidend voor registers	BusinessRule-ID’s, popupkeys, commands, events en statuswaarden worden niet vrij hernoemd in het FO.
Open punten horen centraal	Onbesliste keuzes worden niet verspreid, maar centraal in open punten vastgelegd.

19.6 Server-side waarheid

Server-side context is leidend voor autorisatie, rolcontext, profielcontext, leerlingtoegang, docentcontext, ouder-/voogdinzage, live meekijken, beheeracties en export.

Een zichtbare knop, menuoptie, badge, kaart, teller, route of filter is nooit voldoende bewijs dat de gebruiker de onderliggende actie mag uitvoeren.

Voor iedere afgeschermde actie geldt minimaal:

• gebruiker is server-side bekend;
• account is actief;
• relevante rolcontext is geldig;
• relevante relatiecontext is geldig wanneer vereist;
• relevante objectcontext bestaat;
• object hoort bij de toegestane dataset;
• eventuele featuretoggle of systeeminstelling staat de actie toe;
• status van het object staat de actie toe;
• de actie wordt gecontroleerd op het moment van uitvoeren.

Clientstate mag deze controles niet vervangen.

19.7 Clientstate en routeparameters

Clientstate heeft uitsluitend presentatiewaarde.

Niet leidend voor autorisatie zijn:

• browsergeschiedenis;
• querystrings;
• routeparameters;
• lokaal geselecteerde context;
• oude dropdownselecties;
• cachewaarden;
• badges;
• filters;
• paginering;
• clientside storage;
• browsercookies;
• oude SignalR-state;
• reeds geladen schermdata.

Wanneer clientstate verwijst naar een object dat niet meer toegankelijk is, toont OefenHub geen gedeeltelijke data.

De applicatie kiest dan een veilige fout- of niet-beschikbaarafhandeling.

19.8 Rolcontext

OefenHub werkt vanuit expliciete rolcontexten.

Rolcontext	Kernregel
Leerling	Niet combineerbaar met ouder/voogd, docent of beheerder.
Ouder/voogd	Combineerbaar met docent en/of beheerder, maar niet met leerling.
Docent	Combineerbaar met ouder/voogd en/of beheerder, maar niet met leerling.
Beheerder	Combineerbaar met docent en/of ouder/voogd, maar geen vrije bypass op eindgebruikersflows.
TestDocent	Niet-publieke rol voor gecontroleerde testmoduletoegang waar functioneel ondersteund.

Een gebruiker met meerdere rollen krijgt geen gemengde autorisatie.

De context van de route en actie bepaalt welke rolgrens geldt.

19.9 Geen gemengde autorisatie

Combinatierollen mogen data niet vermengen.

Voorbeelden:

Situatie	Regel
Docent + ouder/voogd	Docentroutes geven geen ouder-/voogdrecht en ouder-/voogdroutes geven geen docentrecht.
Beheerder + docent	Beheerdercontext geeft geen automatische docentinzage buiten expliciete beheer- of supportflow.
Beheerder + ouder/voogd	Beheerdercontext geeft geen reguliere ouder-/voogdinzage zonder eigen ouder-/voogdrelatie.
Docent + ouder/voogd bij hetzelfde kind	De docentrelatie en ouder-/voogdrelatie blijven afzonderlijke autorisatiebronnen.
Leerling	Leerlingcontext wordt niet gecombineerd met volwassen rollen.

Een gecombineerde frontpage mag blokken uit meerdere contexten tonen, maar vervolgacties controleren opnieuw de eigen domeingrens.

19.10 Beheerdercontext is geen vrije bypass

Een beheerder heeft brede beheerrechten, maar niet automatisch dezelfde functionele positie als eindgebruikers.

Daarom geldt:

• beheerder kan geen leerlingrun maken namens een leerling;
• beheerder kan niet live meekijken als algemene eindgebruikersfunctie;
• beheerder ziet geen detaildata buiten expliciet geautoriseerde beheer- of supportflows;
• beheerder wijzigt geen identity-providercredentials;
• beheerder gebruikt centrale beheerflows voor categorieën, modules, content, popups, templates, features, systeeminstellingen en accounts;
• beheerderondersteuning binnen docentcontext blijft supportmatig, auditbaar en begrensd.

Beheeracties zijn altijd server-side geautoriseerd en auditbaar wanneer zij functionele gevolgen hebben.

19.11 Relatiecontext

Relaties zijn functionele autorisatiebronnen.

Relatietype	Autorisatiebetekenis
Vriendschap	Voor delen van oefeningen en toegestane privécommunicatie tussen leerlingen.
GuardianStudent	Voor ouder-/voogdinzage, resultaten, geschiedenis, PDF en live meekijken.
TeacherStudent	Voor docent-leerlingtoegang, niveauautorisaties, resultaten en live meekijken binnen docentcontext.
TeacherTeacher	Voor samenwerking op niveau- en oefenaanbodlaag.
AdminAdmin	Voor beheerder-naar-beheerdercommunicatie of beheercontext waar ondersteund.

Een relatie is geen algemene vrijbrief voor alle data.

De actie bepaalt welke relatiecontext relevant is.

19.12 Relatiebeëindiging en historie

Beëindiging van een relatie werkt toekomstgericht.

Bij relatiebeëindiging geldt:

• toekomstige relatieafhankelijke toegang vervalt;
• historische oefenruns worden niet verwijderd;
• historische resultaten blijven functioneel herleidbaar volgens de rol- en privacyregels;
• berichten en systeemberichten volgen hun eigen zichtbaarheid en retentie;
• auditrecords blijven bestaan;
• gedeelde oefeningen behouden hun historische snapshotcontext waar dit functioneel is vastgelegd.

Relatiebeëindiging herschrijft dus geen historische waarheid.

19.13 Niveau- en oefencontext

Leerlingtoegang tot oefeningen wordt bepaald door actuele server-side context.

Minimaal relevant zijn:

• leerlingaccount;
• actieve leerlingrol;
• actieve niveaucontext;
• toegankelijke categorie;
• concrete actieve oefening;
• geldige modulebeschikbaarheid;
• relatie- en/of autorisatiecontext;
• status van niveau, categorie, oefening en module.

Een historisch resultaat of eerder geopende pagina geeft geen actuele starttoegang.

19.14 Readmodels

Readmodels mogen worden gebruikt voor:

• frontpages;
• overzichtsschermen;
• tellers;
• badges;
• filters;
• samenvattingen;
• zoekresultaten;
• exportvoorbereiding;
• online-overzichten;
• livebeschikbaarheid;
• resultatenoverzichten.

Readmodels zijn geen zelfstandige bron van waarheid wanneer onderliggende domeinrecords bronhoudend zijn.

Een readmodel mag nooit meer data tonen dan de gebruiker via bronrecords zou mogen zien.

19.15 Tellers en badges

Tellers en badges zijn afgeleid.

Voor iedere teller moet functioneel duidelijk zijn:

Aspect	Vraag
Objectscope	Welke objecten tellen mee?
Statusfilter	Welke statussen tellen mee of niet?
Rolcontext	Welke rol begrenst de telling?
Relatiecontext	Welke relatie is vereist?
Tijdvenster	Is er een periode zoals vandaag, week, maand of recent?
Activiteit	Tellen inactieve, verlopen, soft-deleted of testrecords mee?
Distinct-logica	Telt een object één keer of per koppeling?
Autorisatie	Telt alleen data die de gebruiker mag zien?

Een teller is nooit autorisatiebewijs.

19.16 Filters, zoeken en paginering

Filters, zoeken en paginering werken altijd binnen de geautoriseerde dataset.

Zij mogen de dataset niet verruimen.

Voorbeelden:

• mailbox zoeken zoekt alleen in eigen zichtbare mailboxitems;
• leerlinggeschiedenis filtert alleen eigen toegestane runcontext;
• docentresultaten filteren alleen binnen docentcontext;
• ouder-/voogdgeschiedenis filtert alleen binnen actief gekoppelde kinderen;
• beheerderzoekacties blijven binnen beheercontext en domeinflow;
• shared-exercise-overzichten tonen alleen eigen zichtbare records.

Geen resultaat is een geldige toestand.

19.17 Commands en mutaties

Een gebruikersactie of systeemactie die data wijzigt, wordt functioneel als command beschouwd.

Voor commands geldt:

• input wordt server-side gevalideerd;
• autorisatie wordt opnieuw bepaald;
• actuele status wordt gecontroleerd;
• domeinregels worden toegepast;
• mutaties zijn transactioneel waar zij functioneel samen horen;
• history of events worden vastgelegd waar vereist;
• gedeeltelijke mutaties worden voorkomen;
• foutafhandeling toont geen interne details.

Een command mag niet slagen omdat een knop zichtbaar was.

19.18 Events en history

Events en history leggen betekenisvolle domeingebeurtenissen vast.

Niet iedere readactie hoeft een domeinevent te zijn.

Wel auditbaar zijn onder meer:

• beheeracties met functioneel gevolg;
• accountlifecycle;
• rolmutaties;
• relatievorming en ontkoppeling;
• niveauautorisaties;
• collaborators;
• eigendomsoverdracht;
• categorie- en modulemigraties;
• oefeningconfiguratiewijzigingen;
• meldingenstatus en sluitingen;
• heropenverzoeken;
• live-meekijksessies;
• systeeminstellingen en featuretoggles;
• content-, popup- en templatewijzigingen.

History is bedoeld voor reconstructie, audit en support.

History is geen gewone gebruikerscommunicatie.

19.19 Statusmodellen

Statussen moeten per domein eenduidig zijn.

Voor statusmodellen geldt:

• backendstatussen en gebruikerslabels mogen verschillen;
• afgeleide gebruikersstatussen worden niet onnodig als aparte databasewaarde opgeslagen;
• statusovergangen zijn beperkt tot toegestane flows;
• statuswijzigingen met functionele gevolgen zijn auditbaar;
• verlopen, geaccepteerd, afgerond, actief, in onderhoud en gesloten betekenen per domein precies wat in dat domein is vastgelegd.

Voorbeeld: Opgelost bij meldingen is een gebruikersgerichte afgeleide toestand en geen aparte backendhoofdstatus.

19.20 Historische reconstructie

Historische runs, gedeelde oefeningen, resultaten en exports moeten functioneel bruikbaar blijven na latere wijzigingen.

Latere wijzigingen kunnen gaan over:

• categorienaam;
• categorie-icoon;
• categoriekleur;
• modulemetadata;
• oefeningnaam;
• oefeningconfiguratie;
• relatiecontext;
• autorisaties;
• docentniveaus;
• eigenaar of collaborator;
• accountstatus;
• persoonsgegevens.

Waar actuele persoonsgegevens zijn verwijderd of geanonimiseerd, blijft reconstructie alleen toegestaan zonder actuele persoonsgegevens.

Historische reconstructie mag privacygrenzen niet doorbreken.

19.21 Geen herschrijven van historische runs

Historische exercise runs worden niet herschreven door latere beheeracties.

Dit geldt in elk geval voor:

• categoriemigratie;
• modulemigratie;
• naamswijziging;
• statuswijziging van oefening;
• intrekken van autorisatie;
• beëindigen van relatie;
• wijziging van modulemetadata;
• wijziging van content of templates.

Een run bewaart de relevante historische context die nodig is voor resultaten, geschiedenis, PDF en audit.

19.22 Payloadlagen

OefenHub gebruikt meerdere payloadlagen.

Payloadlaag	Betekenis
Oefeningconfiguratiepayload	Modulespecifieke configuratie van een concrete oefening.
Runpayload	Vraag-, antwoord- en volgorde-inhoud van een unieke run.
Vraagvoortgangspayload	Operationele voortgang per vraag waar modulespecifieke gegevens nodig zijn.
Exportrepresentatie	Eventuele module-specifieke representatie voor PDF of resultaatweergave.

Uniforme velden blijven beschikbaar voor generieke overzichten, resultaten, live meekijken en geschiedenis.

Modulespecifieke inhoud blijft binnen de modulegrens.

19.23 ModuleKey en schemaVersion

Voor module- en schemaherleidbaarheid zijn moduleKey en schemaVersion in de bestaande payloads leidend.

Er wordt geen extra generieke databasekolom geïntroduceerd om dezelfde schemaherleidbaarheid dubbel op te slaan.

Functioneel betekent dit:

• de modulepayload moet haar eigen interpretatiecontext bevatten;
• moduleversies blijven backwards compatible of leveren migratie-/leeslogica;
• historische runs blijven leesbaar op basis van opgeslagen payload en context;
• modulemigratie wijzigt toekomstig gebruik van actieve oefeningen, niet historische runs;
• het FO dupliceert geen module-specifiek schema.

19.24 Compatibiliteit van modules

Modulemigraties veronderstellen dat backwards compatibility procesmatig is vastgesteld.

OefenHub dwingt niet alle semantische compatibiliteit automatisch hard af.

Wel geldt:

• modulebeheer mag metadata beheren;
• testzichtbaarheid kan worden geschakeld waar ondersteund;
• connectiviteit kan worden getest;
• migratie kan proefgericht, docentgericht of globaal zijn;
• migratie is auditbaar;
• historische runs worden niet herschreven;
• gedeelde oefeningen en PDF-contexten blijven historisch bruikbaar.

19.25 Resultaten en statistieken

Resultaten zijn gebaseerd op afgeronde oefenruns.

Voor resultaten geldt:

• niet-afgeronde runs tellen niet als afgerond resultaat;
• docenttestruns tellen niet als leerlinggeschiedenis;
• uniforme runvelden zijn leidend voor overzichten;
• detaildata blijft beschikbaar via opgeslagen runpayload en voortgang;
• statistieken worden niet uit clientstate afgeleid;
• PDF-export gebruikt dezelfde historische resultaatbron;
• resultaatweergave muteert de run niet.

19.26 PDF-export

PDF-export is een read-only exportactie.

Voor PDF-export geldt:

• export gebruikt historische runcontext;
• export maakt geen verplichte permanente PDF-records aan;
• export wijzigt geen run, resultaat of geschiedenis;
• export controleert opnieuw server-side toegang;
• export toont geen data buiten de toegestane rolcontext;
• module-specifieke notatie mag via modulehulp worden geleverd;
• bestandsnaam en layoutregels volgen FO-18 en de scherm-/modulebronnen.

19.27 Realtime transport

Realtime transport, zoals SignalR, is geen bron van waarheid.

Realtime kan worden gebruikt voor:

• live meekijken;
• voortgangsupdates;
• mailboxbadges;
• notificatie van relevante communicatie;
• online-status of aanwezigheid;
• UI-verversing.

De bron blijft server-side data.

Wanneer realtime updates niet aankomen, wordt de actuele toestand bij herladen of ophalen opnieuw server-side bepaald.

19.28 Live meekijken

Live meekijken is read-only.

Voor live meekijken geldt:

• docent en ouder/voogd hebben verschillende autorisatiegrenzen;
• beheerder heeft geen algemene live-meekijkbypass;
• ExerciseRuns en voortgangsrecords blijven bron van waarheid;
• SignalR is transport;
• browsemodus is presentatiestate;
• meekijken wijzigt geen antwoord, vraagstatus, runstatus of voortgang;
• daadwerkelijke live-meekijksessie wordt auditbaar vastgelegd waar functioneel vereist.

19.29 Background jobs

Background jobs voeren periodieke of uitgestelde verwerking uit.

Voor background jobs geldt:

• zij zijn idempotent waar herhalen mogelijk is;
• zij selecteren op actuele databasecriteria;
• zij verwerken niet meer dan de functionele scope;
• zij maken geen onnodige losse jobs per object wanneer periodieke verwerking volstaat;
• fouten bij één object blokkeren niet noodzakelijk alle andere kandidaten;
• technische fouten worden gelogd;
• waar audit nodig is, ontstaat compacte history.

Voorbeeld: verlopen heropentermijnen van meldingen worden periodiek verwerkt en niet via een losse job per melding.

19.30 Systeemcommunicatie

Systeemcommunicatie wordt niet gebruikt als bron van de onderliggende domeinactie.

Een systeembericht kan een gebruiker informeren of naar een object verwijzen, maar opent of verwerkt dat object niet automatisch.

Voorbeelden:

• relatie-uitnodiging wordt niet geaccepteerd door bericht openen;
• ticket wordt niet gesloten door bericht openen;
• oplossing wordt niet geaccepteerd door bericht openen;
• gedeelde oefening wordt niet gestart door bericht openen;
• privéthread wordt niet beantwoord door bericht openen.

De vervolgactie blijft onderdeel van het eigen domein.

19.31 Systeemnotificaties

Systeemnotificaties zijn planbare overlays boven frontpages of startcontexten.

Voor systeemnotificaties geldt:

• frontpage laadt eerst;
• notificatiecontrole volgt daarna;
• notificaties blokkeren contextresolutie niet;
• systeemnotificaties zijn geen mailbox-systeemberichten;
• systeemnotificaties zijn geen popupregister-popups;
• AudienceType is geen ContextType;
• OncePerBrowser gebruikt clientside onderdrukking zonder server-side seen-tabel;
• tijdens actieve leerling-oefenrun worden overlays niet getoond.

19.32 Popups en feedback

Popups geven actiegerichte feedback, bevestiging, foutafhandeling of invoer.

Voor popups geldt:

• popupkeys blijven stabiel;
• popupteksten worden niet per usecase gedupliceerd;
• popupregister en popup-themes zijn leidend;
• foutfeedback lekt geen technische payload;
• autorisatiefouten tonen geen gedeeltelijke data;
• custom popups blijven codegedreven;
• beheer wijzigt alleen toegestane velden.

19.33 Leerlingrust tijdens oefenen

Tijdens actieve oefenruns heeft rust voor de leerling prioriteit.

Daarom worden tijdens de actieve oefencontext visueel verborgen of uitgesteld:

• berichtenbadges;
• meldingenterugkoppelingen;
• systeemnotificatie-overlays;
• actie-indicaties;
• andere niet-noodzakelijke signalering.

Onderliggende data blijft wel correct opgeslagen.

Na verlaten, onderbreken of afronden van de oefenrun worden relevante signalen opnieuw beoordeeld.

19.34 Geen gedeeltelijke datalekken

Bij autorisatiefouten wordt geen gedeeltelijke data getoond.

Dit geldt nadrukkelijk voor:

• kindnamen;
• leerlingnamen;
• runinhoud;
• antwoorden;
• juiste antwoorden;
• statistieken;
• payloads;
• technische snapshots;
• tokens;
• stacktraces;
• interne identifiers;
• relaties buiten context;
• meldinginhoud buiten eigenaar/beheercontext;
• privéberichtinhoud buiten participantcontext.

Een foutmelding mag functioneel duidelijk zijn, maar niet informatief voor ongeautoriseerde verkenning.

19.35 Privacy en anonimisering

Privacygrenzen gelden ook wanneer historische reconstructie nodig is.

Bij anonimisering of accountverwijdering geldt:

• actuele persoonsgegevens worden verwijderd, vervangen of afgeschermd volgens domeinregels;
• historische audit blijft zo nodig reconstructief bruikbaar;
• open relaties worden beëindigd of niet langer autoriserend;
• actieve toegang, sessies en frontendcontexten vervallen;
• berichten, tickets, runs en history blijven binnen eigen retentie- en zichtbaarheidregels;
• exports mogen geen actuele persoonsgegevens terughalen die functioneel geanonimiseerd zijn;
• beheerweergaven gebruiken geanonimiseerde actor- of gebruikerweergave wanneer actuele persoonsgegevens niet langer nodig zijn.

19.36 Retentie en bewaartermijnen

Retentie is functioneel relevant wanneer zij bepaalt wat gebruikers, beheerders of historische reconstructie later nog mogen zien.

Voor alle domeinen gelden de volgende overkoepelende regels:

Regel	Betekenis
Retentie verruimt geen autorisatie	Een record dat technisch nog bestaat, mag alleen zichtbaar zijn binnen de actuele rol-, relatie-, participant- of beheercontext.
Cleanup herstelt geen zichtbaarheid	Verwijderde mailboxzichtbaarheid, beëindigde relaties of ingetrokken autorisaties worden niet opnieuw zichtbaar door retentie- of cleanupverwerking.
Historie wordt niet blind herschreven	Oefenruns, tickets, berichten, audit en shared records blijven waar nodig reconstructief bruikbaar, maar met geanonimiseerde persoonsgegevens waar vereist.
Domeinregels blijven leidend	Privéberichten, systeemberichten, tickets, runs, auditregels en technische snapshots volgen hun eigen functionele retentieregels.
Technische bewaartermijnen horen elders	Exacte jobs, SQL, backupretentie, fysieke verwijdering, logrotatie en opslagbeleid horen in TO, SRS of beheerbeleid.

Functionele bewaartermijnen die al in het FO zijn vastgelegd, zoals de bewaartermijn van drie maanden voor privéberichten, blijven leidend totdat zij documentatiebreed worden gewijzigd.

19.37 Identity-providergrens

Authenticatie en credentialbeheer liggen bij de identity provider.

OefenHub beheert:

• intern applicatieaccount;
• rollen;
• profielgegevens;
• gebruikersinstellingen;
• applicatiecontext;
• relaties;
• domeintoegang;
• accountlifecycle binnen OefenHub.

OefenHub beheert niet rechtstreeks:

• wachtwoorden;
• credential reset;
• primaire identity-provider-sessies;
• identity-provider-tokens als functionele domeindata;
• externe credential lifecycle.

Een geslaagde externe login geeft pas OefenHub-toegang wanneer interne accountcontext geldig is.

19.38 Geen automatische herstelillusie

Voor technische edge cases wordt geen onbetrouwbare automatische herstelroute beloofd.

Voorbeelden:

• externe login slaagt maar interne provisioning faalt;
• profiel- of contextinitialisatie is inconsistent;
• modulepayload kan niet geïnterpreteerd worden;
• readmodelopbouw faalt;
• exportgeneratie faalt;
• realtime verbinding valt weg.

In zulke situaties zijn veilige foutmelding, logging, contactroute, beheeranalyse of technische correctie belangrijker dan schijnbaar automatisch herstel.

19.39 Featuretoggles

Featuretoggles schakelen expliciet togglebare functies aan of uit.

Een featuretoggle:

• verwijdert geen bestaande domeindata;
• herschrijft geen geschiedenis;
• wist geen berichten;
• verwijdert geen resultaten;
• maakt geen verborgen autorisatiepad;
• bepaalt alleen beschikbaarheid van ondersteunde functies;
• wordt auditbaar gewijzigd.

Verplichte kernfunctionaliteit hoort niet als gewone toggle te worden behandeld.

19.40 Systeeminstellingen

Systeeminstellingen bevatten gecontroleerde configuratiewaarden.

Zij zijn geen vrije sleutel/waarde-opslag voor ongedocumenteerde runtimevariabelen.

Voor systeeminstellingen geldt:

• sleutelset ontstaat via code/migratie;
• datatype en invoervorm zijn bekend;
• beheer wijzigt alleen bestaande ondersteunde instellingen;
• cache wordt veilig ververst;
• wijziging is auditbaar;
• autorisatie- of privacygrenzen worden niet door cache doorbroken.

19.41 Contentbeheer

Contentbeheer beheert tekstuele inhoud op vaste plekken.

Contentbeheer is geen pagebuilder.

Contentbeheer wijzigt niet:

• layout;
• routes;
• componenttypes;
• autorisatie;
• tellerdefinities;
• popupflows;
• systeemnotificatiegedrag;
• systeemberichten;
• featuretoggles;
• formulierlogica.

Nieuwe pagina- of blokstructuur is een code- en documentatiewijziging.

19.42 Beheerbare templates

Systeemberichttemplates leveren inhoud voor toekomstige concrete systeemberichten.

Een templatewijziging:

• wijzigt niet automatisch bestaande systeemberichten;
• maakt geen nieuwe technische referentie aan;
• verwijdert geen verplichte systeemcommunicatie;
• mag alleen ondersteunde placeholders gebruiken;
• is auditbaar;
• blijft gescheiden van popups, systeemnotificaties en privéberichten.

19.43 Lege toestanden

Lege toestanden zijn normale toestanden.

Voorbeelden:

• geen toegankelijke oefeningen;
• geen recente resultaten;
• geen hervatbare run;
• geen gekoppelde leerlingen;
• geen gekoppelde kinderen;
• geen berichten;
• geen meldingen;
• geen actieve systeemnotificaties;
• geen zoekresultaten;
• geen modulemigratiekandidaten;
• geen recente beheerwijzigingen.

Een lege toestand is geen autorisatiefout wanneer de gebruiker de pagina wel mag openen.

19.44 Fouttoestanden

Fouttoestanden ontstaan wanneer context, object, status, autorisatie, validatie of techniek niet voldoet.

Voor fouttoestanden geldt:

• geen gedeeltelijke data tonen;
• geen technische details lekken;
• geen ongeautoriseerde context herstellen;
• geen clientstate vertrouwen;
• geen stille datamutatie uitvoeren;
• geen half afgeronde transactie achterlaten;
• fout auditbaar of technisch logbaar maken waar nodig;
• passende popupkey of inline foutstatus gebruiken zonder tekstduplicatie.

19.45 Bronconflicten

Wanneer bronnen elkaar tegenspreken, geldt de bronhiërarchie uit FO-00.

Als de bronhiërarchie geen eenduidige oplossing geeft, wordt het punt niet lokaal opgelost.

Dan geldt:

• conflict expliciet benoemen;
• geen stille keuze introduceren;
• open punt opnemen in FO-20 of relevante bron;
• geen dubbele waarheid creëren;
• pas na besluit registers, usecases, FO en schermdocumentatie in lijn brengen.

19.46 Beslisregels per functioneel domein

Domein	Overkoepelende beslisregel
Account en profiel	Identity provider is bronhoudend voor credentials; OefenHub beheert applicatiecontext.
Rollen en autorisatie	Server-side context is leidend; zichtbare UI is geen bewijs.
Relaties	Actieve relatiecontext bepaalt relationele toegang; historie wordt niet herschreven.
Frontpages	Read-only oriëntatiepagina’s; geen diepe mutaties zonder objectselectie.
Oefencatalogus	Centrale categorie-identiteit en concrete oefeningconfiguratie blijven gescheiden.
Oefenmodules	Modulepayload bevat moduleKey en schemaVersion; geen dubbele generieke schema-kolom.
Leerlingruns	ExerciseRun en voortgangsrecords zijn bron voor oefenen, resultaten en live meekijken.
Resultaten en PDF	Resultaatpresentatie en PDF-export zijn read-only op historische runcontext.
Gedeelde oefeningen	Shared record is administratief; ontvanger krijgt pas bij start een eigen run.
Docentfunctionaliteit	Docentcontext begrenst leerlingen, autorisaties, resultaten en live meekijken.
Ouder/voogd	Actieve GuardianStudent-relatie is voortdurende autorisatiebron.
Beheerderfunctionaliteit	Beheerder heeft beheercontext, geen vrije eindgebruikersbypass.
Berichten	Mailboxweergave is readmodel; berichten en threads blijven eigen domeinrecords.
Meldingen	Tickets hebben eigen lifecycle; systeemcommunicatie verwerkt geen ticketactie automatisch.
Live meekijken	Read-only; realtime transport is geen bron van waarheid.
Contentbeheer	Tekstueel beheer op vaste plekken, geen pagebuilder.
Popups en notificaties	Popup, systeemnotificatie en mailbox-systeembericht zijn verschillende mechanismen.

19.47 Relatie tot andere FO-hoofdstukken

Hoofdstuk	Relatie
Bronnen en afbakening	Bepaalt bronhiërarchie, DRY, linkbeleid en conflictregels.
Productvisie en scope	Geeft productkader en initiële scope-afbakening.
Rollen, context en autorisatie	Werkt rol- en contextregels inhoudelijk uit.
Applicatieschil, header, footer en navigatie	Past UI- en navigatiegrenzen toe rond zichtbaarheid, badges en anti-afleiding.
Frontpages en overzichtsschermen	Past read-only en tellerregels toe op frontpages.
Account, profiel en voorkeuren	Past identity-providergrens, profielcontext en instellingen toe.
Relatiebeheer	Past relatiecontext en historische grenzen toe.
Oefencatalogus, niveaus, categorieën en oefeningen	Past categorie-, niveau- en oefeninggrenzen toe.
Leerling: oefenen, voortgang en resultaten	Past run-lifecycle, voortgang en resultaatregels toe.
Gedeelde oefeningen	Past shared-record en historische snapshotregels toe.
Docentfunctionaliteit	Past docentcontext, niveauautorisatie en samenwerking toe.
Ouder-/voogdfunctionaliteit	Past ouder-/voogdrelatie en read-only grenzen toe.
Beheerderfunctionaliteit	Past beheercontext, audit en geen-bypassregels toe.
Berichten, communicatie en notificaties	Past communicatiescheiding, readstates en realtimegrenzen toe.
Meldingen en ticketafhandeling	Past statusmodel, discussie, closures, reopen en TickerQ-regels toe.
Live meekijken	Past realtime, audit en read-only meekijkregels toe.
Contentbeheer, vaste pagina’s en footer	Past contentbeheer- en pagebuildergrenzen toe.
Popups, templates, features en systeemnotificaties	Past popup-, template-, feature- en notificatiegrenzen toe.
PDF-export en resultaatpresentatie	Past historische resultaat- en exportregels toe.
Open punten en buiten scope	Centraliseert onbesliste keuzes en buiten-scopeafbakening.
Schermlaag en UX-specificaties	Past schermlaag-, UX-, lege-toestand- en foutregels toe.
Oefenmodules en modulepayloads	Past modulecontract, payloadlagen en schema-evolutie toe.
Functionele architectuurcontext	Verbindt deze regels met systeemgrens, containers en infrastructuur.

19.48 Gerelateerde bronverwijzingen

Bron	Link
Technisch Ontwerp — applicatielagen	Applicatielagen, projectstructuur en dependency-richting
Technisch Ontwerp — autorisatie	Autorisatie, policies en server-side contextcontrole
Technisch Ontwerp — logging en foutafhandeling	Logging, audit, securitylogging en technische foutafhandeling
Technisch Ontwerp — privacy	Privacy, retentie, anonimisering en gegevensbescherming
Ontwerpbron — business rules	Business rules
Ontwerpbron — autorisatiematrix	Autorisatiematrix
Ontwerpbron — statusmodellen	Statusmodellen
Ontwerpbron — command-register	Command-register
Ontwerpbron — event-register	Event-register
Ontwerpbron — popup-register	Popup-register
Database-informatie — audit, historie en technische uitgangspunten	Audit, historie en technische uitgangspunten
Database-informatie — oefenruns, delen en voortgang	Oefenruns, delen en voortgang
Architectuur — niveau 2 container diagram	Containerdiagram
Architectuur — niveau 3 componentdiagram	Componentdiagram
FO — bronnen en afbakening	Bronnen en afbakening
FO — functionele architectuurcontext	Functionele architectuurcontext
FO — open punten en buiten scope	Open punten en buiten scope