**Je aanvullende context verfijnt het dossier op drie belangrijke punten:** de managementplane is een bewuste recoveryboundary; LootHeat is een actieve applicatie met concrete MLOps-foundations; enterprisegebruik vraagt vooral passende ondersteuning, redundancy en operationele hardening van dezelfde architectuurprincipes.

De repositorycontrole ondersteunt die richting. Ze bewijst nog geen volledig onafhankelijk disaster-recoverypad of een getraind LootHeat-model.

Alles bleef read-only tijdens het onderzoek. Alleen publieke LootHeat-health/versionendpoints werden live bevraagd; private managementservices zijn niet opnieuw live geverifieerd. Dit beschrijft het onderzoek van 13 oktober 2026, vóór de latere publicatie van deze pagina.

## 1. Gecorrigeerde architectuur: managementplane en recovery

De scheiding staat expliciet in de bootstrap-runbook:

- **Layer 0:** Proxmox, netwerk/storage, template, operatoraccess en recoverymaterial.
- **Layer 1:** management-VM/filesystem, Vault, MinIO, backupverificatie en infrastructuurstate.
- **Layer 2:** Kubernetes, GitOps, Jenkins, Nexus en toepassingen.

Layer 1 mag geen Jenkins-, Kubernetes-, Argo- of Nexusafhankelijkheid hebben. OpenTofu wordt daarvoor rechtstreeks door de operator uitgevoerd; Jenkins kan later dezelfde gereviewde commands gebruiken. Dit is een ontworpen bootstrapboundary. [Bootstrap core recovery, regels 16–22 en 55–62](C:/git/zero-foundry/zf-operations/runbooks/core/bootstrap-core-recovery.md:16)

### Wat concreet geïmplementeerd is

| Onderdeel | Repositorybewijs | Bewijsstatus |
|---|---|---|
| Management-VM provisioning | OpenTofu-module cloneert een template en definieert beschermde VM, disks, netwerk en cloud-init | **IMPLEMENTED**; historische placement/recovery beschreven |
| Guestconfiguration | Ansible beheert OS-baseline, Docker, persistent mount en servicepaths | **IMPLEMENTED** |
| Stateful managementservices | Compose-definities voor Vault, MinIO, Jenkins stable/canary en Nexus | **IMPLEMENTED**; historische runtime-evidence |
| Aanvullende hostservices | Compose-definities voor REST backupserver, frontend en chat; factory heeft een afzonderlijke host-serviceflow | **IMPLEMENTED**, actuele health niet vastgesteld |
| Infrastructurestate | MinIO/S3-backend met aparte management- en labscope, versioning en native locking | **IMPLEMENTED**, historische consumeracceptatie |
| Credentials | Vault-records; beschermde operatorinputs en begrensde Jenkinscredentialprojecties | **IMPLEMENTED CONTRACT + historische handoffs** |
| Kubesprayinventory | Script genereert hosts en control-plane/worker/etcdgroepen uit versioned OpenTofuoutput | **IMPLEMENTED**, historische uitvoering |
| Argo-bootstrap | Pinned installatie, read-only repositorycredential en rootApplication | **IMPLEMENTED**, historische uitvoering |

Provisioning: [managementmodule](C:/git/zero-foundry/zf-infrastructure/modules/proxmox-management-vm/main.tf:1). Guestownership: [management-host automation](C:/git/zero-foundry/zf-operations/automation/management-host/README.md:3). Inventory: [generator](C:/git/zero-foundry/zf-kubernetes/scripts/inventory-from-tofu-output.sh:16). Argo: [bootstrapflow](C:/git/zero-foundry/zf-gitops/docs/bootstrap.md:12).

### Jenkins: orchestratie-intentie versus bewezen uitvoering

Je ownerstatement noemt Jenkins als infrastructure-lifecycleorchestrator. De onderzochte implementation ondersteunt een preciezere formulering:

> “Jenkins automatiseert infrastructurevalidation en gecontroleerde planflows. De bootstrap- en recoverycommands behouden een rechtstreeks operatorpad, zodat Jenkins geen noodzakelijke prerequisite voor zijn eigen herstel wordt.”

`Jenkinsfile.plan` draait **plan-only** op disposable Kubernetes-agents. De runbook vermeldt expliciet dat applyautomation ontbreekt en een aparte architecturedecision/recoverytest vraagt. Het bewijst dus geen volledige Jenkinsgestuurde OpenTofu-apply/Kubespray/Argo-bootstrapketen. [Jenkins plan gate, regels 3–5 en 35–37](C:/git/zero-foundry/zf-infrastructure/docs/runbooks/jenkins-plan-gate.md:3)

Dat de gewone planjob clusteragents gebruikt, ondermijnt de recoveryarchitectuur niet: die job is niet het enige executionpad.

### State en trust hebben concrete identities

Managementstate en labstate zijn afzonderlijke scopes. Een historische statefork werd op 13 september gereconcilieerd: Vaultinputs, Jenkinsconsumers en de workstationbackend werden naar de canonical labkey gebracht; eerdere versions bleven behouden. State-lineage en serial zijn daarbij afzonderlijk beoordeeld. [Canonical state handoff](C:/git/zero-foundry/zf-infrastructure/docs/runbooks/canonical-state-handoff-20260913.md:9)

Dit is een sterk interviewdetail:

> “Een hogere serial op een andere lineage maakt een statebestand niet automatisch de juiste authority.”

### Recovery per verliesscenario

| Scenario | Beschikbare herstelketen | Wat nog apart bewezen moet worden |
|---|---|---|
| **Totaal Kubernetesverlies** | Management behouden → VM’s herstellen → inventory → Kubespray → clusterchecks → Argo/CRD’s/secrets → workloads | Elke stateful workload afzonderlijk; gewenste toestand herstelt geen unieke applicatiedata |
| **Management-VMverlies, host/backups intact** | Operator/Proxmoxaccess → VM/disks herstellen → guestbaseline → state/secrets/trust/servicegegevens terugplaatsen → services gecontroleerd starten | Volledige actuele serviceacceptatie en herstel zonder oorspronkelijke VM |
| **Host- of siteverlies** | Onafhankelijke recoverymaterialen, infrastructurecode en externe backups nodig | Volledige offsite runtimebackup, onafhankelijke decryptionaccess en cold-startdrill |
| **Credential/trust-rootverlies** | Recoverybundle, afzonderlijke decryptionidentity, CA/hosttrust en herstel van scoped identities | Bewijs dat alle noodzakelijke materialen buiten de verloren failure domain toegankelijk zijn |

De Kubernetesrebuild is historisch uitgevoerd na SSD-verlies. Dat blijft iets anders dan complete disaster recovery. [Recoveryrecord van 4 oktober](C:/git/zero-foundry/zf-operations/runbooks/proxmox/ssd-jenkins-recovery-20261004.md:43)

### Belangrijke verfijning van het eerdere dossier

Er bestaat een age-encrypted Vault-recoverybundle in `zf-recovery`, met de private decryptionidentity buiten GitHub als ontwerp. Maar **WP-REC-005 registreert de onafhankelijke keycopy en independent-machineproof nog als held/onvoltooid**. Het source-preflightrecord bewijst decryptability met de bestaande operatorkey, niet herstel vanaf een onafhankelijke copy. [Recovery TODO](C:/git/zero-foundry/zf-recovery/TODO.md:33)

Daarom is de juiste claim:

> **Een Kubernetesonafhankelijke managementplane met een ontworpen zelfstandig recoverypad; volledige onafhankelijk recoverability blijft gedeeltelijk onbewezen.**

Bijkomende nuance: de encrypted bundle bevat voldoende materiaal voor volledige Vaultrecovery. De beveiliging van de decryptionidentity wordt daardoor zelf een kritieke custodyboundary. [Recoveryrepositoryboundary](C:/git/zero-foundry/zf-recovery/README.md:29)

De bootstraphelper controleert prerequisites, servicehealth en backupintegriteit en ondersteunt een disposable restore. Hij provisiont niet automatisch het volledige platform; een directoryrestore is ook geen service-level recoveryacceptatie. [Helperimplementation](C:/git/zero-foundry/zf-operations/scripts/bootstrap-core-recovery.sh:51)

Ik vond bovendien een stale README-capacity van 400 GB, terwijl het actuele managementplaybook expliciet de goedgekeurde **128 GiB** servicedisk bewaakt. Executable contract en actuele inventory zijn hier beslissend. [Actuele capacityguard](C:/git/zero-foundry/zf-operations/automation/management-host/playbook.yaml:61)

## 2. LootHeat: bestaande applicatie en MLOps-evolutie

### Nieuwe live-evidence — 13 oktober 2026

Veilige publieke GET-checks leverden:

| Endpoint | Belgische tijd | Resultaat |
|---|---|---|
| `/healthz` | 18:07:59 | HTTP 200, `status: ok` |
| `/version` | 18:08:00 | HTTP 200, commit `06f0e5c78437ac148dfbbd2b4f6ca738d8b5f8a2` |

De gerapporteerde commit komt overeen met de lokale LootHeat-HEAD.

**VERIFIED RUNNING:** publieke health/versionresponse op dat moment. Deze check bewijst geen werkelijk addonclientgebruik, volledige browseracceptatie of ML-inference.

### Wat LootHeat werkelijk doet

LootHeat bevat deterministic allocation/Heatregels, persona- en gearingtransitions, seeded scenario’s, simulation/replay, een browserwerkruimte en dataset/catalogusfunctionaliteit.

Een belangrijke recente architecturedecision is **één gedeelde Lua-core**:

- Addon-owned Lua bepaalt economic en gearinggedrag.
- Browser en offline runner voeren dezelfde embedded sourcebytes uit via Fengari.
- TypeScript behoudt contracts, scenario-generation, UI, metrics en transport.
- Python blijft een offline experiment/property-testcoordinator.

Dit voorkomt dat toekomstige experimenten tegen een tweede, afwijkende economische implementation optimaliseren. [Accepted ADR0028, regels 29–46](C:/git/zero-foundry/loot-heat/docs/decisions/0028-shared-lua-core.md:29)

Tradeoffs zijn interpreteroverhead en verschillen tussen native Lua5.1 en Fengarisemantics. Native paritytests, frozen referenceoutputs en source-bytechecks zijn daarom relevant. [Shared-core implementation en retirementproof](C:/git/zero-foundry/loot-heat/docs/research/shared-lua-core.md:3)

### Capabilitiesscheiding

| Categorie | Bevinding | Status |
|---|---|---|
| Applicatielogica | Deterministische rules, scoring, personas, simulations en replay | **IMPLEMENTED** |
| AI-assisted development | WP-LH-ML-001 noemt owner en Codeximplementation expliciet | **DOCUMENTED AUTHORSHIP voor die scope** |
| MLOps-foundation | Strict schemas, frozen manifests, group partitions, hashes, create-once evidence en failure records | **IMPLEMENTED** |
| Propertytesting | Hypothesis test persona-invariants en transitions | **IMPLEMENTED TESTING**, geen ML |
| Simulationdry-run | Matched seeds, replaychecks, budgets en checksummed artifacts | **IMPLEMENTED EXPERIMENTMECHANICS**, geen fitting |
| Getraind model/inference | Geen trainer of learned inference aangetoond in deze foundation | **NIET AANGETOOND** |
| Calibration/policysearch | Reviewed labels, objectives en gates ontbreken nog deels | **PLANNED/HELD** |
| Modelpublication/promotion | Foundationoutputs blokkeren promotion expliciet | **NIET GEÏMPLEMENTEERD in deze scope** |
| LLM/RAG-integratie in LootHeat | Geen concrete implementation gevonden | **HYPOTHETICAL** |

Het foundationcontract schrijft `trainingAllowed: false` en `promotionEligible: false`. Het noemt expliciet geen trainer, optimizer, holdoutevaluator of deployment. [MLOps README](C:/git/zero-foundry/loot-heat/mlops/README.md:3), [concrete contractcode](C:/git/zero-foundry/loot-heat/mlops/lootheat_mlops/contracts.py:187)

De dry-run voert de echte gedeelde simulator uit en verifieert replay/integriteit. Dat is nuttige experimentinfrastructuur, maar **simulation, parametersearch en machine learning zijn afzonderlijke begrippen**. [Simulationdry-run](C:/git/zero-foundry/loot-heat/docs/research/simulation-dry-run.md:3)

### Hoe LootHeat een end-to-end MLOps-demonstratie kan worden

Mijn voorstel: begin met **één begrensde behavior-calibrationtaak**, waarbij een model een keuze voorspelt uit toegestane observed examples. Laat de deterministic allocationcore en menselijke beslissingsbevoegdheid behouden.

| Stap | Bestaande basis → ontbrekend | Acceptance/demo |
|---|---|---|
| 1. Taak en baseline | Personas → expliciete predictiontarget en reviewed baseline | Definieer input, label, foutkosten en wanneer ML meerwaarde moet leveren |
| 2. Lawful observed data | Frozen-manifestcontracts → echte reviewed keuzevoorbeelden | Consent/provenance, classification, datakwaliteit en group isolation |
| 3. Bounded training | Integritysmoke → echte trainer | Vast plan, training-only toegang, exacte environment/checkpoint/evidence |
| 4. Evaluation | Matched simulations → predictive en gedragskwaliteit | Onafhankelijke validation; holdout pas na candidatefreeze; exploit/nonregressioncases |
| 5. Artifacts | Nexus/CI bestaat → LootHeat-specifieke modelbundle en authority | Exact model/data/code/config identity; publisher en promoter afzonderlijk |
| 6. Staging/inference | Applicationdelivery bestaat → versioned inferenceconsumer | Private advisorydemo, bounded resources, fallback naar deterministic baseline |
| 7. Promotion/operation | Deploymentchecks bestaan → modelacceptatie en monitoring | Qualitygate, menselijke approval, model/versiontelemetry en bewezen rollback |

Observed attendance en rankingexports zijn geen voldoende labels voor echte lootkeuzes. De readinessdocumentatie noemt die ontbrekende labels en objectives expliciet. [Experimentreadiness](C:/git/zero-foundry/loot-heat/docs/research/experiment-readiness.md:32)

**Priority:** hoge interviewwaarde, maar pas uitvoering na hervatte scope en datagates. Begin klein; voeg geen GPU of modelregistryservice toe zonder aantoonbare behoefte.

## 3. Homelab naar enterprise: principes behouden, garanties versterken

Ik volg je stelling dat geen fundamenteel andere architectuur noodzakelijk is. De huidige scheiding tussen provisioning, clusterlifecycle, artifacts, secrets, reconciliation en menselijke acceptatie blijft verdedigbaar.

“Enterprise-grade” beschrijft hier de vereiste **garanties, ondersteuning en operating model**, niet de licentieprijs.

| Boundary | Wat behouden kan blijven | Enterpriseaanpassing waar nodig |
|---|---|---|
| Managementplane | Buiten het te herstellen Kubernetesruntime houden | Onafhankelijke failure domains, backup/custody, tested failover of rebuild |
| IaC/CaC | Gereviewde provisioning en guestconfiguration | Ondersteunde lifecycle, changeownership, driftcontrole en uitvoerbare recovery |
| Kubernetes | Declaratieve workloadlifecycle | Managed of ondersteunde distributie wanneer SLA/skills dat rechtvaardigen |
| Secrets/artifacts | Gescheiden authority en scoped identities | HA, contractuele support, custody, audit en lifecyclemanagement |
| CI | Disposable workers en aparte releasecredentials | SLO-capacity, platformteamownership, plugin/librarybeheer |
| Networking | Expliciete trust crossings en toegestane flows | VLAN/VRF/firewallsegmentatie met geteste rules en beheerde netwerkapparatuur |
| Evidence | Exact revisions, outcomes en retained failures | Retentie, authenticity, onafhankelijke assessment en operational response |
| AI | Data/model/evaluation/promotion scheiden | Mission-specific kwaliteit, authorization, oversight en lifecycleverantwoordelijkheid |

### VLANsegmentation

De budgetbeperking is **owner testimony**. De onderzochte provisioningcode toont een configureerbare Proxmoxbridge, maar levert geen bewijs van volledige fysieke VLANsegmentation.

Namespaces en NetworkPolicies helpen binnen Kubernetes. Ze segmenteren niet automatisch het householdLAN, hypervisorbeheer, managementservices en backupnetwerk.

Een concrete volgende verbetering is een geteste flowmatrix voor management-, workload-, backup- en householdzones, gevolgd door de noodzakelijke netwerkconfiguratie. VLANs alleen zijn onvoldoende: inter-zone firewallpolicy en negatieve bereikbaarheidstests horen erbij.

Commerciële support of managed platforms voegen waarde toe wanneer ze aantoonbaar incidentrespons, lifecycleondersteuning en SLA’s leveren. Een supportcontract herstelt geen fout ontworpen failure domain.

## 4. Compliance als continuous engineering

Je filosofie komt vrijwel letterlijk terug in de security-assurancestandaard: één canonical controlmodel met ownership, enforcement, evidence, freshness, exceptions en mappings naar externe frameworks. Een mapping bewijst niet dat de control werkte. [Security-assurance standard](C:/git/zero-foundry/zf-engineering-playbook/docs/standards/security-assurance.md:3)

### Wat bestaat versus wat ontbreekt

| Onderdeel | Bevinding |
|---|---|
| Policy-as-Code | OPA/Rego met concrete dispatch/post-controlregels en fail-closed errors |
| CIsecuritycontrols | Concrete scanner-, artifact- en boundaryimplementaties; adoption verschilt per consumer |
| Controlcatalogue/evidencemodel | Sourcefoundations en executable referencefixtures |
| Frameworkmappings | **Draft** NIS2- en ISOmappingbestanden bestaan |
| Evidenceprojection | Referenceimplementation; geen algemene live controlcoverage |
| Continuous securitytelemetry | Sourceledger, detections en replaymechanics; delen blijven disabled/unverified |
| Volledig ISMS/applicabilityassessment | Niet aangetoond |
| Certification/accreditation | Niet aangetoond |

De eerdere formulering “geen mappings” was te breed. Er bestaan draft referencepacks; ze zijn geen afgeronde organisatie- of productassessment. [Draft NIS2mapping](C:/git/zero-foundry/zf-reference-architectures/examples/security-assurance/mappings-nis2.json:1), [draft ISOmapping](C:/git/zero-foundry/zf-reference-architectures/examples/security-assurance/mappings-iso27001.json:1)

WP-OPS-154 staat **held** en noemt ontbrekende scope, riskregister, Statement of Applicability, NIS2assessment en CRAassessment. [Compliancewerkpakket](C:/git/zero-foundry/zf-operations/TODO.md:476)

Een waardevol negatief resultaat: een caller-forged receipt kon ondanks passing tests worden geaccepteerd. De unauthenticated consumer werd verwijderd; echte projection bleef gated. Dat ondersteunt engineeringdiscipline, niet algemene authenticiteit van alle evidence. [Retained finding en correctie](C:/git/zero-foundry/zf-reference-architectures/TODO.md:38)

### Begrippen die je uit elkaar moet houden

| Begrip | Betekenis |
|---|---|
| Legal applicability | Valt deze entiteit, activiteit of dit product onder de regeling? |
| Regulatory obligations | Welke bindende maatregelen, meldingen en assessments volgen daaruit? |
| Standard | Een norm met requirements, zoals ISO/IEC27001 voor een ISMS |
| Certification | Onafhankelijke assessment van conformiteit binnen een bepaalde scope |
| Security accreditation | Bevoegde toestemming om een systeem onder bepaalde voorwaarden/classificaties te gebruiken |
| Internal controls | Eigen technische, organisatorische en operationele maatregelen |
| Compliance-as-Code | Geautomatiseerde controle/evidenceondersteuning; geen automatische juridische beslissing |

ISO/IEC27001 behandelt een managementsysteem; een scannerdashboard of Annex-Amapping is daarvoor onvoldoende. Certificering kan vrijwillig zijn, maar ook contractueel of via een toepasselijk assessmenttraject vereist worden. [ISO](https://www.iso.org/standard/27001), [Belgisch CCB over NIS2assessment](https://ccb.belgium.be/nl/news/aanname-van-het-koninklijk-besluit-betreffende-nis2)

NIS/NIS2 en CRA vragen een toepasselijkheidsanalyse per entiteit/activiteit/product. Defensiegebruik maakt ze niet automatisch allemaal van toepassing: er bestaan specifieke uitzonderingen en andere beveiligingsverplichtingen. [CCB NIS2scope-uitleg](https://atwork.safeonweb.be/sites/default/files/2024-12/NIS2%20in%20BE%20_Video_20240913_0.pdf), [CCB CRA](https://ccb.belgium.be/regulation/cra)

Op **13 oktober 2026** zijn de CRA-reportingbepalingen van artikel14 al van toepassing sinds **11 september 2026** voor de relevante scope; volledige toepassing volgt op **11 december 2027**. Een roadmap mag toepasselijke huidige verplichtingen dus niet als uitsluitend toekomstig behandelen. [Europese Commissie](https://digital-strategy.ec.europa.eu/en/policies/cra-summary)

### Beoordeling van je filosofie

> “Certificering hoort voort te bouwen op een effectief security- en governancesysteem dat dagelijks werkt. Wanneer formele certification of accreditation een prerequisite is, plan ik die vanaf het begin en behandel ik ze als een expliciete admissiongate.”

Dat verenigt effectieve engineering met externe beslissingsbevoegdheid. Voor systemen die classified information verwerken kan accreditation vóór gebruik vereist zijn; interne evidence verleent die toestemming niet. De concrete Defensieregels moeten door hun bevoegde authority worden vastgesteld. [EU Council accreditation responsibilities](https://www.consilium.europa.eu/en/council-eu/search-the-list-of-council-preparatory-bodies/security-committee/)

## 5. Drie interviewnarratieven

### A — Resilience via een Kubernetesonafhankelijke managementplane

**30 seconden**

> “Zero Foundry houdt bootstrap en recovery buiten Kubernetes. Vault, infrastructuurstate en belangrijke managementservices draaien op een Compose-based management-VM. OpenTofu en Kubespray kunnen het cluster reconstrueren via een rechtstreeks operatorpad. Jenkins automatiseert normale validation en planflows, maar is geen noodzakelijke bootstrapdependency. De grens is bewust ontworpen. Volledige disaster recovery vraagt daarnaast onafhankelijke backups, credentials en trustmaterialen.”

**Twee minuten — technisch**

> “Ik begin bij de dependency graph. Layer0 levert hostaccess, storage, netwerk, template en recoverymaterial. Layer1 levert de management-VM, Vault, MinIO en backupverificatie. Pas daarna herstel ik Kubernetes en de afhankelijkheden erboven.
>
> OpenTofu bezit VM’s en disks; Ansible bezit guestconfiguration. OpenTofuoutputs voeden de Kubesprayinventory. Na clusterhealth komen Argo CD, repositorytrust, operators en applicatiereconciliation.
>
> Jenkins heeft een gecontroleerde planjob, maar die draait op clusteragents en doet geen apply. Daarom behoudt core-recovery een rechtstreeks operatorpad. Bij SSD-verlies is die reconstructieketen werkelijk gebruikt en zijn daarna echte ephemeral Jenkins-agents geverifieerd.
>
> Ik onderscheid drie zaken: configuration opnieuw opbouwen, unique state terughalen en access/trust herstellen. Een Kubernetesrebuild bewijst niet automatisch het tweede en derde.
>
> De managementplane deelt vandaag nog fysieke failure domains met andere services. De onafhankelijke recovery-keycopy is ontworpen, maar haar independent-machineproof staat nog open. Dat is mijn volgende bewijsstap.”

**Evidence:** bootstrapboundary, provisioningsource en recoveryrecord hierboven.

**Tradeoff:** eenvoudige Compose-controlservices; gedeelde host/storage en operatorinterventie.

**Tegenvraag:** “Hoe herstel je de management-VM wanneer state en Vault daar staan?”

**Eerlijk antwoord:** “Via de Layer0/operatorrecoveryroute en retained state/recoverymaterialen. Een volledige actuele cold-start vanaf onafhankelijke copies is nog niet bewezen.”

**Volgende verbetering:** onafhankelijke decryptionproof, gevolgd door een disposable managementrestore met service-level checks en gemeten RTO/RPO.

### B — Van platformengineering naar AI/MLOps via LootHeat

**30 seconden**

> “LootHeat is een echte applicatie met deterministic rules en simulation. Ik noem dat geen machine learning. Er bestaat wel MLOps-foundation: frozen inputs, groepsisolatie, bounded runs en immutable experimentrecords. De volgende stap is één reviewed calibrationtaak met echte labels en een onafhankelijke evaluation. Daarmee kan ik AIkwaliteit verbinden met de bestaande CI-, artifact- en deploymentketen.”

**Twee minuten — technisch**

> “LootHeat geeft mij een concreet productprobleem en een baseline. De allocation- en personaregels zijn deterministisch. Sinds de gedeelde-corebeslissing gebruiken addon, browser en offline experiments dezelfde Lua-source. Daardoor optimaliseert een toekomstig experiment tegen de regels die ook werkelijk uitgevoerd worden.
>
> De huidige MLOpslaag valideert plannen, inputmanifests, hashes en groepspartities. Runs overschrijven eerdere evidence niet. Hypothesis controleert state-machinegedrag; de dry-run controleert matched simulations en replay. Geen van beide traint een model.
>
> Voor een learned component zou ik eerst één target vastleggen, bijvoorbeeld observed choices voorspellen. Daarvoor ontbreken nog reviewed keuzevoorbeelden en volledige quantitative gates. Daarna freeze ik data en plan, train ik bounded, selecteer ik via validation en gebruik ik protected evaluation afzonderlijk.
>
> Jenkins en Nexus kunnen de gecontroleerde artifactflow ondersteunen. Promotion moet daarna quality en security toetsen, en de consumer moet modelversion, fallback en rollback kennen.
>
> De website is vandaag bereikbaar en meldt de huidige sourcecommit. Dat is applicationevidence; modelinference wordt niet geclaimd.”

**Evidence:** shared-coreADR, MLOpscontracts, readiness en nieuwe publieke probe.

**Tradeoff:** interpreter/paritycomplexiteit; beperkt observed data; mogelijk volstaat de deterministic baseline.

**Tegenvraag:** “Waar is je getrainde LootHeat-model?”

**Eerlijk antwoord:** “Dat is nog niet geïmplementeerd. De huidige capability is experimentintegriteit en simulation, met expliciet geblokkeerde training/promotion.”

**Volgende verbetering:** één approved predictiontask met lawful reviewed labels en een vooraf vastgelegde baseline/gate.

### C — Security en compliance als meetbare engineering

**30 seconden**

> “Ik definieer securitycontrols één keer, met owner, enforcement, evidence en vervaldatum. Dezelfde evidence kan verschillende frameworks ondersteunen. OPA, CIchecks en recoverydrills leveren concrete signalen, maar een mapping of passing scan bewijst geen algemene compliance. Certification en accreditation blijven aparte bevoegde assessments, en zijn harde gates wanneer de context dat vereist.”

**Twee minuten — technisch**

> “Een securitycontrol moet een risico adresseren en op een concrete boundary werken. Daarom registreer ik scope, owner, enforcementpunt, evidenceidentity, freshness, exceptions en failurebehaviour.
>
> OPA beoordeelt bijvoorbeeld provider-, data-, tool- en controlfacts. Een evaluatorfailure kan geen authorization geven. CI levert scan- en validationevidence. Recovery en permissiondenial leveren ander bewijs; een green test vervangt die checks niet.
>
> De workspace heeft een controlcatalogue, observationschemas, draft mappings en referenceprojection. Ze heeft geen volledig bewezen live complianceprogramme. Telemetry- en authenticityadoption hebben nog gaten. Een gevonden forged-receiptprobleem is behouden en de onveilige consumer is verwijderd.
>
> Mijn doel is operationele effectiveness: een control moet werken, failure moet zichtbaar zijn en een verantwoordelijke moet reageren. Automation helpt daar bij, maar organiseert geen riskacceptance of juridische applicability.
>
> In Defensie vraag ik daarom eerst naar classificatie, missionrisk en bevoegde authority. Vereiste certification of accreditation plan ik als admissiongate; ik beschouw die niet als iets dat automatisch uit mijn dashboard volgt.”

**Evidence:** security-assurancestandaard, OPAcontract, draft packs en retained negative finding.

**Tradeoff:** traceerbare evidence vraagt maintenance; governancevolume kan operatingcapacity overstijgen.

**Tegenvraag:** “Zijn jullie dan compliant?”

**Eerlijk antwoord:** “Ik kan specifieke controls en outcomes aantonen. Applicability, volledige scope en onafhankelijke assessment zijn niet afgerond.”

**Volgende verbetering:** één beperkte pilot met echte producerbound evidence, freshness/lossdetectie en aantoonbare menselijke opvolging.

### Aangepaste kernzin voor morgen

> “Zero Foundry verbindt drie dingen: een bewust herstelbare managementarchitectuur, echte applicaties als brug naar AI/MLOps, en securitycontrols waarvan ik werking én beperkingen kan aantonen.”