# Kernodeck Reprise v1 — een checkpoint dat daadwerkelijk wordt hervat

Deze oorspronkelijke oefening leert een kleine numerieke relatie op 24 synthetische regels. Het doel is om **het hervatten van een training te verifiëren**, niet om het beste model te verkrijgen of een GPU te meten. De berekening wordt expliciet geforceerd op **CPU**, in `float64`, met één PyTorch-thread.

De controle vergelijkt 10 opeenvolgende stappen met 5 stappen, een checkpoint en vervolgens 5 nieuwe stappen in **een ander Python-proces**. Een vierde proces slaat opzettelijk het herstellen van de randomgeneratoren over: de afwijking moet worden gedetecteerd. Er wordt geen enkele externe bron, klantgegeven of vooraf getrainde gewichten gedownload.

## Vereisten

- Een Python-omgeving met PyTorch en NumPy al geïnstalleerd. Het geleverde bewijs is uitgevoerd met **Python 3.14.6, PyTorch 2.11.0+cu128 en NumPy 2.4.4**.
- Ongeveer 1 MB beschikbaar voor de vier kleine uitvoermappen. De Python-afhankelijkheden nemen hun eigen ruimte in.
- Voer de opdrachten uit vanuit de uitgepakte map `kernodeck-reprise-v1`.

Het achtervoegsel `+cu128` beschrijft het pakket dat aanwezig was tijdens de test; het betekent niet dat deze oefening CUDA heeft gebruikt. **Geen enkele CUDA-, ROCm-, AMP-, multi-GPU- of gedistribueerde berekening wordt door deze bron gevalideerd.** Er worden geen DataLoader-workers gebruikt. Een andere omgeving moet zijn eigen bewijs leveren; gelijkheid tussen versies of platformen is niet gegarandeerd.

## De verificatieopdracht

```console
python -B verify_resume.py --output runs/preuve-cpu
```

`-B` voorkomt bytecode-caches in de projectmap. De uitvoermap moet nieuw zijn: geen enkele bestaande poging wordt overschreven. Om opnieuw te beginnen, gebruik je bijvoorbeeld `runs/preuve-cpu-2`.

Het programma voert vier opdrachten uit met dezelfde Python-interpreter en schrijft vervolgens `runs/preuve-cpu/verification.json`. Een volledige uitvoering verwacht:

```json
{"device":"cpu","all_checks_passed":true,"positive":true,"negative_divergence_detected":true,"report":"verification.json"}
```

De exitcode is **0** als het protocol slaagt, **1** als de vergelijking mislukt, **2** als de verificatie niet kon worden voltooid. Succes vereist zowel de positieve hervatting als het waarneembare falen van de negatieve controle. Een checkpointbestand dat simpelweg aanwezig is, is niet voldoende.

## De drie stappen handmatig uitvoeren

```console
python -B train.py --steps 10 --output runs/continu
python -B train.py --steps 5 --output runs/coupure
python -B train.py --steps 5 --resume runs/coupure/checkpoint.pt --output runs/reprise
```

Elke regel start een afzonderlijk proces. `--steps` betekent **extra stappen**, dus de derde opdracht eindigt bij stap 10. Elke map bevat `checkpoint.pt`, de bijbehorende hash `checkpoint.pt.sha256` en een leesbare samenvatting `summary.json`. De checkpoints worden tijdens de uitvoering door de oefening aangemaakt; ze worden niet in het archief meegeleverd.

Om het onvolledige geval te observeren, gebruik je een nieuwe map:

```console
python -B train.py --steps 5 --resume runs/coupure/checkpoint.pt --omit-rng-restore --output runs/reprise-incomplete
```

Deze laatste opdracht kan zonder Python-fout eindigen. **Dat bewijst geen correcte hervatting.** De opdracht `verify_resume.py` vergelijkt de resultaten en stelt het verschil vast.

## Wat het model werkelijk doet

`data.csv` bevat een raster van twee variabelen en een synthetische target: `target = 0.7*x1 - 0.4*x2 + 0.15*x1*x2 + 0.1`. Het bootst geen enkele klantmeting na. Het netwerk heeft twee invoeren, een laag van acht neuronen, `Tanh`, een dropout van 0,25 en één uitvoer, dus 33 parameters.

De training gebruikt Adam met een initiële leersnelheid van 0,03. StepLR halveert deze leersnelheid elke drie stappen. Elke batch bevat vier regels: 10 stappen verbruiken dus 40 observaties, waarbij sommige regels na de eerste epoch opnieuw worden doorlopen. De permutatie, de epoch, de cursor en het aantal verbruikte observaties worden bewaard. Bij de onderbreking na vijf stappen staat de cursor op 20 van 24: de hervatting vindt plaats **midden in de doorloop van de data**.

Drie willekeurige bronnen beïnvloeden het werk: Python stelt een lichte gain in op de invoeren, een NumPy PCG64-generator produceert de ruis en de permutaties, PyTorch produceert de dropout. Het opnieuw instellen van de initiële seed reconstrueert niet de toestanden die bij de onderbreking waren bereikt.

## Wat het checkpoint bewaart en in welke volgorde het opnieuw wordt ingelezen

De dictionary bevat de gewichten, de Adam-status, de StepLR-status, de datavoortgang, de drie RNG's, de geschiedenis van verliezen en rates, evenals de vingerafdrukken van de code en de CSV. De modus `train()` wordt hersteld voor het hervatten; de meting van de finale MSE gebruikt `eval()` en verbruikt geen dropout.

Bij het hervatten bouwt de code eerst het model, de optimizer en **de scheduler**, en laadt vervolgens de gewichten, de status van de scheduler en die van de optimizer. De RNG's worden als laatste hersteld, na de constructies die willekeurigheid verbruiken. Deze keuze respecteert de waarschuwing in de documentatie [Optimizer.load_state_dict](https://docs.pytorch.org/docs/2.11/generated/torch.optim.Optimizer.load_state_dict.html).

De Python-status is een structuur van primitieven. PCG64 levert een dictionary van integers en strings; geen enkel `ndarray`-object van NumPy wordt geserialiseerd als RNG-status. De PyTorch CPU-status is een bytetensor. De volgende trekkingen worden gecontroleerd zonder de opgeslagen status te wijzigen.

## Het bewijs lezen en tolerantie

`verification-cpu.json` is het openbare bewijs uit een echte uitvoering van deze versie. `source` bevat de SHA-256 van de scripts en van de CSV. `protocol` beschrijft de vier processen, de precisie en de tolerantie. `resume_boundary` verifieert de volgende trekking van elke RNG en de volgende rate die na onderbreking wordt gebruikt.

De vergelijking vereist dezelfde volgorde van rijen, dezelfde voortgang en dezelfde scheduler-status. De maximaal aanvaarde absolute afwijking voor de gewichten, de optimizer-status, de verliezen, de MSE en de rates is **1e-12**, zonder relatieve tolerantie (`rtol=0`). Het rapport bewaart de gemeten afwijkingen, zelfs wanneer ze nul zijn. Het verifieert eveneens de volgende trekking van de RNG's aan het einde van beide parcours.

De negatieve controle moet aantonen dat het vergeten van de RNG's het resultaat verandert. De MSE ervan kan lager of hoger zijn: deze test verifieert een hervattraject, geen kwaliteitsrangschikking. Een verwachte divergentie geeft dus `passed: false` in deze subtest en `divergence_detected: true`; het globale protocol kan dan slagen.

## Alleen je eigen checkpoint laden

De loader gebruikt expliciet `torch.load(..., map_location="cpu", weights_only=True)` en biedt geen enkele fallback naar `weights_only=False`. Hij verifieert eerst de bijbehorende vingerafdruk, beperkt de grootte en controleert het schema, de versies, de code en de data. Hij weigert een onvolledige status in plaats van stilzwijgend een deel van de training te resetten.

Gebruik uitsluitend de checkpoints die **je zelf met deze oefening hebt gemaakt en onder je eigen controle hebt bewaard**. De vingerafdruk dient om een wijziging te detecteren; ze authenticeert geen afzender. Het beperkte laden maakt een onbekend bestand niet vertrouwenswaardig. Zie [torch.load](https://docs.pytorch.org/docs/2.11/generated/torch.load.html) en [de PyTorch-serialisatie](https://docs.pytorch.org/docs/2.11/notes/serialization.html).

## De oefening aanpassen aan je project

Identificeer de statussen die je eigen training werkelijk verbruikt: sampler, augmentation, optimizer, scheduler en specifieke generatoren. Als je AMP gebruikt, voeg dan de status van de scaler toe op een coherente grens; deze oefening doet dat niet. Een gedistribueerde training vereist ook dat je de processen en hun dataverdeling aanpakt.

Leid uit dit kleine bewijs geen huurduur, doorvoer, VRAM-voetafdruk of hervatgarantie af voor een ander model. Herneem de methode: een korte representatieve set, een onderbreking midden in het werk, een ander proces, een expliciete vergelijking en een negatieve controle.

## Inhoud en licenties

- `train.py`, `verify_resume.py`, deze documentatie en het manifest: MIT-licentie, zie `LICENSE-MIT.txt`.
- `data.csv`: originele synthetische data aangeboden onder CC0 1.0, zie `DATA-LICENSE-CC0.txt`.
- `verification-cpu.json`: metingen van deze oefening, zonder persoonlijke data, volledige omgeving, paden van het toestel, tokens of sessie-identificatoren.
- `manifest.json`: exacte lijst van de gedistribueerde bestanden en hun SHA-256. Het manifest verwijst niet naar zichzelf.
- `SOURCES.md`: officiële links en documentaire beperkingen.

De afhankelijkheden PyTorch, NumPy en Python behouden hun eigen licenties. Ze worden niet opnieuw gedistribueerd in de ZIP.


## Kernodeck-presentatie en compatibiliteit van het project

Deze heruitgave van 25 september 2026 actualiseert de naam van het archief, de documentatie en het merk. De scripts `train.py` en `verify_resume.py`, de CSV en `verification-cpu.json` blijven identiek aan de levering die op 24 september 2026 is uitgevoerd. Het technische veld `project` behoudt zijn identificatie voor bestaande rapportlezers. Er is geen enkele CPU/GPU-berekening of -controle opnieuw uitgevoerd voor deze heruitgave.