Van norm naar runtime assurance

In het voorgaande artikel Van RAG naar Institutional Epistemic Assurance introduceerden wij het concept Institutional Epistemic Assurance: publieke AI moet niet worden geautoriseerd op basis van modelkwaliteit of compliance-status, maar op basis van aantoonbare, contextgebonden en continu herbeoordeelde epistemische assurance. Daaruit volgde een kritiek op de handreiking: zij benoemt de risico's (onjuiste informatie, hallucinaties, over-reliance, afhankelijkheid van Big Tech, verlies van ambtelijk vakmanschap), maar operationaliseert die niet tot falsifieerbare systeemclaims.

Dit artikel zet de volgende stap en breidt de uitwerking uit tot een volledige, executable architectuur.

De handreiking zet een belangrijke stap door juridische, ethische en organisatorische normen te vertalen naar aandachtspunten voor de ontwikkeling en het gebruik van LLM-systemen. Zij verlangt bijvoorbeeld dat broninformatie actueel, juist, representatief en geschikt voor het beoogde doel is, dat het systeem voldoende transparant en robuust is, dat risicoanalyses worden uitgevoerd en periodiek worden bijgewerkt, en dat de werking na ingebruikname voortdurend wordt gemonitord.

Vanuit AI-assuranceperspectief blijft echter een cruciale stap impliciet.

De handreiking specificeert in hoofdzaak wat verantwoord gedrag vereist, maar niet hoe een technische organisatie:

1. een norm vertaalt naar een falsifieerbare systeemhypothese;
2. een geobserveerde fout vertaalt naar een runtimeconstraint;
3. epistemische kwaliteit als expliciet technisch object modelleert.

Precies daar ligt de overgang van governance naar assurance.

De volgende generatie publieke AI-governance moet daarom niet primair meer vragen: "Hebben we de juiste norm opgenomen?" maar: "Welke systeemclaim volgt uit die norm, hoe proberen we die claim te falsificeren en welke capability wordt automatisch beperkt wanneer het bewijs onvoldoende is?" Dat is een fundamenteel ander ontwerpprincipe.

1. Van juridische norm naar falsifieerbare systeemclaim

Een normatieve eis is niet hetzelfde als een technisch toetsbare eigenschap.

Neem bijvoorbeeld de eis uit de handreiking dat broninformatie compleet, actueel, juist en geschikt voor het beoogde doel moet zijn. Als architectuureis klinkt dat helder. Maar vanuit assurance is de formulering onvoldoende. "Actueel" is geen test. "Compleet" is geen test. "Geschikt" is geen test. "Juist" is geen test.

Deze termen moeten eerst worden gedecomposeerd tot observeerbare eigenschappen. Daarvoor stellen we de volgende transformatieketen voor:

Norm → Control Objective → System Claim → Hypothesis → Test → Evidence → Assurance Decision

Dit is de eerste ontbrekende laag.

2. Een formeel norm-to-hypothesis model

Laat een normatieve eis worden aangeduid als N_i. Daaruit wordt een control objective afgeleid:

C_i = g(N_i, Context)

Vervolgens wordt daaruit een systeemclaim afgeleid:

S_i = h(C_i, Architecture)

De systeemclaim wordt vervolgens geformuleerd als toetsbare hypothese H_i met een expliciet falsificatiecriterium F_i. Een assuranceclaim is dus pas volwassen wanneer H_i, F_i en Evidence_i bestaan. Niet wanneer alleen Policy_i bestaat.

De claimstructuur

Voor een operationele implementatie wordt ieder norm-claim vertaald naar een vaste structuur:

claim = (norm, operationalisatie, metriek, drempel, falsificatiecriterium, herbeoordeling)

De 44 aandachtspunten uit de handreiking worden daarmee geen checklist maar een verzameling claims, elk met een meetbare metrica en een falsificatie-conditie.

Handreiking-aandachtspunt	Testbare claim	Metrica	Falsificatieconditie
Broneinformatie actueel en juist	Retrieval levert geldige bronnen	Temporal Recall@k, Freshness gap	Recall onder drempel op gecontroleerde verouderde-bron-set
Representatief	Geen systematische uitsluiting van gezaghebbende bron	Minority-source retention	Retentie van minderheidsbron onder drempel op juridische vragen
Transparant genoeg	Output claims dragen provenance	Cite-to-entailment-rate	Unsupported claim rate boven 5 procent
Menselijk toezicht	Gebruiker kan output verwerpen	Override rate boven 0	Override rate gelijk aan 0 over periode (automation bias)

3. Voorbeeld: zorgvuldigheid operationaliseren

De handreiking koppelt het zorgvuldigheidsbeginsel aan actuele, juiste en representatieve broneinformatie en aan het voorkomen van bias.

N_1 = Zorgvuldigheid
C_1 = Het systeem mag geen professioneel advies genereren op basis van aantoonbaar onvolledige, verouderde of niet-representatieve evidence.
S_1 = "Voor vraagklasse Q haalt retrieval voldoende relevante, actuele en gezaghebbende evidence op."
H_1: Recall_authority,temporal(Q) gelijk aan of boven theta
F_1: Injecteer bekende relevante bronnen en controleer of deze binnen top-k retrieval worden gevonden.

Wanneer een relevante gezaghebbende bron niet in R_k(Q) wordt gevonden voor meer dan de toegestane foutmarge, faalt H_1. De juridische norm is dan vertaald naar een empirische test.

4. Van transparantie naar meetbare reconstructeerbaarheid

De handreiking verlangt dat de opdrachtgever in staat is indicatoren en gebruikte bronnen uit te leggen, en dat transparantie zwaarder moet wegen naarmate het gebruik risicovoller wordt. De gebruikelijke implementatie is "toon bronnen". Maar dit is epistemisch te zwak.

Een sterkere claim:

S_2 = "Voor iedere materiële outputclaim kan achteraf worden gereconstrueerd welke evidence, modelversie en retrievalbeslissing eraan ten grondslag lagen."
H_2: TraceCompleteness = 1.0 voor alle high-impact claims.

Een trace bevat minimaal: claim_id, source_ids, source_versions, retrieval_score, retrieval_timestamp, model_version, prompt_version, policy_version, contradiction_state, confidence_state en human_decision.

Falsificatie: selecteer willekeurig 100 productieclaims. Als één claim niet volledig kan worden gereconstrueerd tot bron- en systeemversie, faalt H_2 voor de betreffende assuranceklasse. Transparantie wordt zo een systeemproperty in plaats van een communicatieverplichting.

5. Van menselijke controle naar falsifieerbare human-factors assurance

De handreiking signaleert risico's van over-reliance, kenniserosie, verlies van kritische blik en afnemende autonomie. "Een mens keurt het antwoord goed" is daarom onvoldoende. Een falsifieerbare systeemclaim is:

S_3 = "Professionals detecteren materieel foutieve AI-output met ten minste waarschijnlijkheid p."
H_3: P(ErrorDetection | HumanReview) groter dan of gelijk aan 0.9

Dit kan experimenteel worden getest met gecontroleerde failure injection: correcte output, subtiele retrieval omission, verkeerde jurisprudentie, stale regulation, en een plausibel geformuleerde maar unsupported claim. Meet detectiegraad, override rate, broninspectie, tijd tot correctie en het verschil tussen junior en senior professionals. Wanneer professionals systematisch fouten accepteren, is human-in-the-loop empirisch gefalsificeerd als effectieve control.

6. De tweede ontbrekende laag: van fout naar runtimeconstraint

De meeste AI-governance stopt nadat een fout wordt gevonden. Er verschijnt dan issue, risk en recommendation, maar operationeel verandert het systeem niet noodzakelijk. Dat is onvoldoende. Een assurance-architectuur vereist:

ObservedFailure → PolicyTransition → CapabilityConstraint

Een fout moet dus gevolgen hebben voor runtimegedrag. Dat is het tweede ontbrekende element.

7. Van evaluatie naar capability state

Beschouw een AI-capability C, bijvoorbeeld current_legal_analysis. Daaraan wordt een assurance vector gekoppeld:

A(C) = (Hallucination, Calibration, Temporal, Contradiction, Authority, Retrieval, HumanControl)

Bijvoorbeeld:

hallucination      PASS
calibration        PASS
temporal_validity  FAIL
contradiction      PASS
authority          PASS
retrieval          PASS
human_control      PASS

Een conventioneel systeem zou blijven draaien met een waarschuwing. Een assurance-gebaseerd systeem verandert de capability state: AUTHORIZED wordt RESTRICTED of HOLD.

8. Een formele enforcementfunctie

Laat E_t de actuele evidence-state zijn, R de risicoklasse van de taak en C de capability. Dan:

Permission_t = f(C, R, E_t, Context)

Niet louter Permission = f(Role). Een praktische policy:

IF capability = legal_current_law
AND temporal_assurance != PASS
THEN autonomous_execution = DENY
  temporal_specialist = REQUIRED
  human_approval = REQUIRED

IF contradiction_state = UNRESOLVED
AND task.risk gelijk aan of boven HIGH
THEN synthesis = HOLD
  counter_evidence_agent = REQUIRED

Dit is governance die technisch afdwingbaar wordt.

9. Evidence-conditioned autonomy

Daaruit ontstaat een principe:

Autonomy is evenredig met Assurance

Niet iedere capability en context verdient dezelfde autonomie. Een systeem kan bijvoorbeeld:

LOW-RISK      → autonomous
MEDIUM-RISK   → checker required
HIGH-RISK     → checker + human approval
CRITICAL      → advisory only

Maar zelfs binnen dezelfde risicoklasse kan assurance fluctueren. Daarom is een betere relatie:

Autonomy = f(Risk, EvidenceQuality, Uncertainty, Contradictions, TemporalValidity)

Dat noemen we evidence-conditioned autonomy.

10. De assurance-state-machine

De runtime zou geen binaire status moeten kennen. Een bruikbare state machine:

DRAFT → STRUCTURALLY_VALID → EVALUATED → REPEATABLE → HELD_OUT_VALIDATED → AUTHORIZED → DEPLOYED → MONITORED

Negatieve transities:

MONITORED → REGRESSION_DETECTED → RESTRICTED → HOLD → REMEDIATED → RE-EVALUATED → AUTHORIZED

De epistemische evaluatielaag bevat reeds een voorbeeld van dit principe: structurele validatie alleen is niet voldoende voor brede governancecertificatie wanneer repeatability en held-out discrimination nog niet zijn aangetoond. Het principe vertaalt rechtstreeks naar runtime-autoriteit: geen capability promotion zonder evidence maturity.

11. Van foutclassificatie naar constraintclassificatie

Niet iedere fout moet dezelfde constraint veroorzaken. Daarvoor is een mapping nodig:

FailureClass	ConstraintClass
hallucination	claim verification verplicht
low calibration	abstention threshold verhogen
temporal failure	temporal checker verplicht
authority inversion	authoritative-source filter verplicht
contradiction failure	independent contradiction agent verplicht
retrieval omission	top-k verbreden, secondary retriever verplicht
privacy failure	data scope reduceren
tool-scope failure	capability blokkeren
human-control failure	autonomous recommendation uitschakelen

Daarmee wordt incidentrespons semantisch gekoppeld aan het type epistemische falen.

12. De derde ontbrekende laag: epistemische architectuur

Het grootste conceptuele probleem in klassieke RAG-architectuur is dat "kennis" impliciet wordt behandeld. Een document wordt opgehaald, het LLM genereert een tekst, en de tekst wordt als antwoord gepresenteerd. Maar er is geen expliciet epistemisch model.

Een assurance-architectuur moet daarom ten minste vijf dimensies modelleren: contradiction, uncertainty, authority, source completeness en temporal validity. Deze eigenschappen mogen geen vrijblijvende metadata zijn. Ze moeten beslisbare systeemobjecten zijn.

13. Contradiction als first-class object

In klassieke RAG wordt de output een enkel antwoord. Wanneer bron A en bron B elkaar tegenspreken, bestaat het risico dat het LLM het conflict stilzwijgend gladstrijkt. Daarom moet contradiction expliciet worden gemodelleerd.

Voor twee claims c_i en c_j:

Contradiction(c_i, c_j) ∈ { NONE, PARTIAL, DIRECT, UNRESOLVED }

Het systeem mag dan niet reduceren tot één conclusie, maar moet produceren:

CONTESTED
  support: beleidsregel X
  counter-evidence: uitspraak Z
  resolution: menselijke/juridische review vereist

Een contradiction state moet runtimegevolgen hebben:

UNRESOLVED → NO AUTONOMOUS CONCLUSION

14. Contradiction is niet hetzelfde als semantische dissimilarity

Technisch moet onderscheid worden gemaakt tussen verschillende formuleringen, perspectieven, temporeel gewijzigde regels, hiërarchisch conflicterende normen en logisch inconsistente claims. Een contradiction engine moet daarom context bevatten over:

Semantics + Authority + Time + Jurisdiction

Twee bronnen kunnen semantisch tegenspreken maar juridisch niet werkelijk conflicteren omdat één bron ouder is, of omdat één bron lager in de normhiërarchie staat. Daarom: contradiction is niet hetzelfde als semantic dissimilarity.

15. Uncertainty moet gestructureerd zijn

LLM-confidence is vaak slecht gekalibreerd. Daarom moet onzekerheid niet worden gereduceerd tot één scalar, maar worden onderverdeeld in meerdere klassen:

U = (U_retrieval, U_evidence, U_model, U_temporal, U_contradiction)

Bijvoorbeeld:

retrieval_uncertainty   HIGH
evidence_uncertainty    LOW
model_uncertainty       MEDIUM
temporal_uncertainty    HIGH
contradiction_uncertainty LOW

Dit geeft aanzienlijk meer informatie dan één scalar confidence.

16. Uncertainty moet leiden tot abstention

Wanneer de evidence onvoldoende is, moet het systeem aangeven dat het geen betrouwbaar antwoord kan geven:

If EvidenceSufficiency onder theta: Answer = ABSTAIN (niet: BestGuess)

Voor publieke AI is dit essentieel. De optimalisatiedoelstelling moet niet zijn om de responsrate te maximaliseren, maar:

Maximize(CorrectResponses) onder constraint Risk(FalseConfidence) onder epsilon

17. Authority als expliciete eigenschap

Niet iedere bron heeft hetzelfde institutionele gewicht. De architectuur moet bron-autoriteit modelleren:

formal_law          A5
binding_case_law    A5
regulation          A4
official_policy     A3
internal_guidance   A2
academic_secondary  A2
media               A1
blog                A0

De exacte hiërarchie is domeinspecifiek. Het principe is:

Relevance != Authority

18. Authority-aware retrieval

Retrievalranking wordt niet alleen bepaald door similariteit, maar bijvoorbeeld door een gewogen score:

Score(d) = alpha*Similarity + beta*Authority + gamma*Recency + delta*Jurisdiction

Dit is conceptueel; de parameters moeten empirisch worden gevalideerd. Het principe: epistemische ranking mag niet uitsluitend semantische ranking zijn.

19. Source completeness als onzekerheidsprobleem

"Volledigheid" is bijzonder lastig: een systeem kan nooit met absolute zekerheid weten dat geen relevante bron ontbreekt. Daarom moet completeness worden behandeld als een schatting:

P(CompleteEvidenceSet | Q)

Mogelijke indicatoren: overlap tussen onafhankelijke retrievers, coverage van verplichte broncategorieën, bekende gold-standard bronnen, retrieval saturation en de marginale evidence-gain per extra retrievalronde. Completeness = 1 mag echter zelden worden geclaimd.

20. Multi-retriever triangulatie

Een praktische oplossing is retrieval-diversiteit:

BM25, Vector Search, Knowledge Graph, Authoritative Registry, Domain Search

Wanneer één retriever systematisch relevante evidence vindt die anderen missen, is een single-retrieverarchitectuur aantoonbaar kwetsbaar.

21. Temporal validity als afzonderlijke dimensie

Voor publieke AI is tijd geen metadata maar onderdeel van de waarheidstoestand. Een bron kan factueel correct maar niet langer geldig zijn. Daarom:

Truth(c,t) is tijdsafhankelijk
valid(c,t) = valid_from tot en met t, en t onder valid_until

Een claim bevat minimaal: valid_from, valid_until, superseded_by, jurisdiction, retrieved_at en checked_at.

22. Temporal reasoning moet ook worden getest

Niet alleen de bronmetadata. Ook het model moet kunnen redeneren over tijd. Een model kan beide bronnen correct ophalen en toch de verkeerde regeling toepassen. Daarom:

TemporalRetrieval != TemporalReasoning

De epistemische evaluatielaag bevat temporal reasoning expliciet als benchmarkcategorie. Dat is precies het type eigenschap dat capability-level assurance moet beïnvloeden.

23. Een unified epistemic claim object

De vijf dimensies kunnen worden samengebracht in één object:

EpistemicClaim {
  claim_id
  proposition
  evidence[]
  provenance[]
  authority_level
  valid_from
  valid_until
  temporal_status
  contradiction_status
  counter_evidence[]
  retrieval_completeness_estimate
  uncertainty { retrieval, evidence, model, temporal, contradiction }
  verification_status
  assurance_state
}

Een antwoord wordt daarmee geen tekstobject meer, maar een verzameling bestuurbare epistemische claims.

24. Claim-state-machine

Ook individuele claims kunnen een lifecycle krijgen:

PROPOSED → SUPPORTED → VERIFIED → AUTHORIZED

met alternatieve paden:

PROPOSED → CONTESTED
SUPPORTED → STALE
SUPPORTED → INSUFFICIENT_EVIDENCE
VERIFIED → INVALIDATED

Dit maakt epistemische verandering expliciet.

25. De koppeling met de operationele control plane

De operationele control plane gebruikt de claimstates als policy input:

IF claim.assurance_state != VERIFIED
AND task.risk = HIGH
THEN publish = DENY

IF contradiction_status = CONTESTED
THEN autonomous_synthesis = DENY
  counter_evidence_worker = REQUIRED

IF temporal_status = STALE
THEN current_policy_advice = HOLD

Daarmee wordt epistemische kwaliteit enforcement-relevant.

26. De koppeling met de epistemische evaluatielaag

De epistemische evaluatielaag test vervolgens of deze architectuur werkt. Nieuwe benchmarkcategorieën zouden kunnen omvatten:

authority-inversion
source-omission
temporal-supersession
hidden-contradiction
citation-without-entailment
false-completeness
uncertainty-suppression
minority-evidence-loss

Voor iedere case: expected_behavior, failure_mode, oracle, falsification_condition en required_constraint. Dan wordt niet alleen getest of het model goed antwoordt, maar of het systeem de epistemische toestand correct detecteert en de juiste constraint activeert. Dat is een wezenlijk hogere assurancebar.

27. Een complete assurance-loop

De drie ontbrekende mechanismen vormen één gesloten systeem:

NORM → CONTROL OBJECTIVE → TESTABLE HYPOTHESIS → ADVERSARIAL EVALUATION → EVIDENCE → ASSURANCE STATE → RUNTIME POLICY → CAPABILITY CONSTRAINT → PRODUCTION OBSERVATION → RE-EVALUATION

Formeel:

N → H → T → E → A → P → C → O → E'

Dit is de ontbrekende control loop.

28. Van compliance evidence naar scientific evidence

Er is een fundamenteel onderscheid tussen twee soorten bewijs:

Compliance evidence: policy exists, training completed, DPIA exists, approval recorded. Scientific assurance evidence: retrieval recall measured, failure reproduced, hypothesis falsification attempted, held-out test passed, judge reliability measured, regression reproduced.

Beide zijn nodig, maar bewijzen verschillende dingen:

Evidence(ControlExistence) != Evidence(ControlEffectiveness)

De operationele control plane maakt dat onderscheid impliciet: het stelt compliant niet gelijk aan gecertificeerd, en groene tests niet gelijk aan production assurance.

29. Assurance debt

Zodra governance zo wordt gemodelleerd ontstaat een nieuw type technische schuld: assurance debt. Die ontstaat wanneer capability changes maar evidence dat niet doet (nieuw model, nieuwe retriever, nieuwe databron, nieuwe agent, nieuwe prompt, nieuwe tool) terwijl bestaande certificatie behouden blijft. Formeel:

Change(S) groter dan 0 en Revalidation(S) gelijk aan 0 betekent AssuranceDebt groter dan 0

Hoe groter de schuld, hoe zwakker de betekenis van de bestaande governance claims.

30. Assurance drift

Naast model drift ontstaat assurance drift wanneer de werkelijke systeemtoestand afwijkt van de toestand waarop assurance oorspronkelijk was gebaseerd. Daarom moeten assurance-artifacts versiegebonden zijn:

model_hash, retriever_version, embedding_version, corpus_version, prompt_hash, policy_hash, tool_manifest, evaluation_manifest

Zonder deze binding bestaat geen reproduceerbare assurance.

31. De productie-eenheid verandert

De deployment unit is niet langer het model of de applicatie, maar:

Capability × Context × EvidenceState

Een model kan tegelijkertijd AUTHORIZED zijn voor summarisation, RESTRICTED voor policy advice en DENIED voor een autonoom juridisch besluit. Dit voorkomt de fout om een model generiek veilig of onveilig te verklaren.

32. De governance-eenheid verandert

De traditionele vraag "Is dit een high-risk AI-systeem?" blijft juridisch relevant. Maar operationeel moet daarnaast worden gevraagd welke capability onder welke context een welk gevolg heeft, en welk bewijs de huidige autonomie rechtvaardigt. Dat is fijner van korrel en technisch veel bruikbaarder.

33. De volgende stap voor publieke AI

De handreiking levert de normatieve basis: zorgvuldigheid, juistheid, transparantie, privacy, risicoanalyse, monitoring en menselijke verantwoordelijkheid. Wat nodig is, is een tweede generatie assurance-engineering:

1. Norm compilation: Norm → Hypothesis
2. Adversarial evaluation: Hypothesis → Evidence
3. Assurance decision: Evidence → State
4. Runtime enforcement: State → Constraint
5. Epistemic representation: Claim → Evidence + Authority + Time + Contradiction + Uncertainty
6. Continuous reevaluation: Operation → NewEvidence

34. Conclusie

De handreiking beschrijft terecht welke risico's rond generatieve AI in de publieke sector moeten worden beheerst. Maar assurance begint pas waar abstracte governance ophoudt. De cruciale transitie is:

Principle → FalsifiableClaim
Failure → Constraint
Knowledge → ExplicitEpistemicState

Pas wanneer een publieke organisatie die drie transities kan maken, kan zij aantonen dat AI-governance werkelijk invloed heeft op systeemgedrag. De governancevraag verschuift van "Hebben we procedures voor verantwoord AI-gebruik?" naar "Kunnen we bewijzen welke capabilities onder welke bewijscondities verantwoord zijn, en blokkeert het systeem zichzelf wanneer die condities niet langer gelden?"

Dat is een veel hogere assurancebar. Maar juist voor de publieke sector is die bar gerechtvaardigd. Wanneer AI steeds meer tussen bron en professional komt te staan, moet niet alleen het model controleerbaar zijn, maar de epistemische toestand van het volledige systeem.

De volgende generatie publieke AI-architectuur bestaat niet alleen uit modellen, retrieval en agents, maar uit:

Norms + Hypotheses + Evidence + EpistemicState + Constraints + Revalidation

Dat is de stap van AI-governance naar executable institutional assurance.

Beperkingen en open vragen

Deze uitwerking is een conceptueel kader, geen gevalideerde productie-implementatie. De volgende beperkingen blijven:

• Metriekcomplexiteit: de bron-completeness-schatting is conceptueel lastig, want je meet de afwezigheid van een niet-aanwezig element. Er is geen directe grondwaarheid voor wat er ontbreekt.
• Kalibratie van ECE: de Brier score en ECE veronderstellen een gekalibreerde onzekerheidsvoorspelling, wat per subklasse specifiek gemotiveerd en gevalideerd moet worden. Eén aggregate kalibratiemeting kan kritieke subklassen verbloemen.
• Norm naar claim vertaling is deels van interpretatie: de vertaling van een juridische norm naar een testregel is een keuze en kan per auditor anders worden ingevuld. Dit vraagt om een expliciete, gedocumenteerde afweging per norm.
• Temporal validiteit vereist een temporele grondwaarheidsmetriek (gouden dataset met geldigheidsvensters), die institutioneel moet worden onderhouden.
• Afruil: het verplichten van abstention kan de bruikbaarheid verminderen; de drempel voor "niet weten" moet strikt worden gekalibreerd.
• Authority-rankings: de autoriteitshiërarchie is domeinspecifiek en normatief; de exacte verdeling per broncategorie moet per toepassingsdomein worden vastgelegd en gevalideerd.

De centrale ontwerpregel uit het voorgaande artikel blijft overeind: geen capability zonder evidence, geen evidence zonder falsificatie, geen autonomie zonder actuele assurance. Dit artikel vult die woorden in met de drie operationele mechanismen: de norm naar hypothese vertaling, de failure naar constraint automatisering en de expliciete epistemische architectuur voor de vijf kern-dimensies. Daarmee is de volgende stap geen openvraag meer, maar een bouwbare specificatie.