# Fase 4 — Releasegates

## Gateprincipe

GeoIntel gebruikt een conjunctieve, fail-closed beslissing: iedere verplichte
gate moet groen zijn. Een hogere gemiddelde score compenseert nooit een
ernstige regressie, ontbrekende support of een critical miss in een vereiste
regio, bron, context of taak.

Er wordt in Phase 4 geen arbitrair hoog accuracydoel verzonnen. Numerieke
releasecriteria blijven `not_frozen_without_reviewed_representative_incumbent_baseline`.
Ze worden pas vastgesteld uit taakrisico, operationele productvereisten,
datakwaliteit en een representatieve, gereviewde incumbentbaseline, en altijd
vóór protected-testtoegang.

## Lokale harnasgates

De volgende controles zijn in `release-gate-report.json` groen:

| Gate | Status | Bewijs |
| --- | --- | --- |
| Alle gedeclareerde taakfamilies | pass | zeven families en 15 capabilities gedeclareerd en geobserveerd |
| Split leakage | pass | zes code-owned rollen; exacte/near-duplicate/identity/2-km-gates groen voor de fixture |
| Training firewall | pass | protected path/role/lineage en padloze of gewijzigde bytes worden geweigerd |
| Geen protected modelselectie | pass | vooraf geregistreerde config; diagnostische curves selecteren niets |
| Ruwe voorspellingen | pass | exacte referenties, pre-/postfilteroutputs, config en lineage behouden |
| Referentie-implementatie | pass | vier golden cases via de echte `QaService` |
| Subgroepcontract | pass | alle 13 dimensies, support, CI en worst-stratum zichtbaar |
| Null-semantiek | pass | ongedefinieerd is `null`; promotion blijft uit |

Deze gates bewijzen dat de evaluator zich lokaal correct gedraagt. Ze bewijzen
niet dat het productiemodel voldoet.
Een test-only governed-contractfixture met 70 cases bewijst dat de groene route
structureel bereikbaar is en dat tampering wordt geweigerd. De gemockte runtime
en handgemaakte cases zijn uitdrukkelijk geen productbewijs.


## Productgates

De volgende actuele gates blokkeren Phase 4:

| Gate | Status | Objectief bewijs |
| --- | --- | --- |
| Actief model bereikbaar en hashbaar | not_evaluable | geconfigureerd `/app/models`-asset is lokaal afwezig |
| Volledige gezagsportfolio | not_evaluable | geen governed GRB/PICC/UrbIS/DHMV/SPW/MDK-taak-/zonebewijs |
| Representatieve menselijke review | not_evaluable | geen checksumgebonden reviewledger; historisch 0/180 |
| Ruimtelijke split-onafhankelijkheid | not_evaluable | geen productgebonden geometrische audit; historisch 24 paren <2 km |
| Phase-3 leakage opgelost | fail | actuele status `attention` |
| Fysieke protected storage isolation | not_evaluable | geen vaultbewijs met hash-chained accesslog |
| Uitgevoerde product-incumbent | not_evaluable | geen model/raw/config/CUDA-gebonden productmanifest |
| Representatieve subgroup-support | not_evaluable | geen productmetrics over alle 13 dimensies |

Door `fail > not_evaluable > pass` is de productbenchmarkstatus `fail`. Dat is
geen gemeten accuracy failure: de bevestigde leakagegate faalt en de overige
productmetingen zijn nog niet evalueerbaar. `promotion_allowed` blijft `false`.

## Toekomstige numerieke gatefreeze

Een latere gatefreeze moet per taak minimaal vastleggen:

- exacte model-, evaluator-, preprocessing-, bron- en splitmanifesthashes;
- klasse- en matchbeleid, operating threshold en NMS-configuratie;
- globale primaire metric met betrouwbaarheidsinterval;
- vereiste regio-, gemeente-, stedelijkheids-, objectgrootte-, bron-, sensor-,
  resolutie-, seizoen-, datum-, vegetatie-, occlusie-, moeilijkheids- en
  contextsubgroepen;
- minimale onafhankelijke AOI-/objectsupport per groep;
- non-inferioritymarge tegenover de incumbent;
- harde maxima voor kritieke false negatives, false positives,
  topologiefouten en calibration error;
- abstention/coverage-regel voor onzekere gevallen;
- runtime-, GPU-, latency- en resourcecontract waar operationeel relevant.

Een releasebeslissing is alleen positief wanneer zowel de globale gate als
iedere kritieke subgroepgate groen is. `insufficient_support`, `null`, een
ontbrekende groep, ongeldige lineage, een checksumverschil of een gemiste
blocker/critical anomaly blokkeert.

## Beschermde evaluatievolgorde

1. Herstel of excludeer Phase-3-quarantine-items traceerbaar.
2. Laat representatieve labels menselijk beoordelen en freeze een nieuwe
   corpusversie; wijzig V56 niet in place.
3. Genereer onafhankelijke `train`, `val`, `calibration`, `test`,
   `background-test` en sealed `challenge`-manifesten; laat alle leakage-gates
   slagen.
4. Plaats test/background-test en externe challenge-labels in een afzonderlijke
   vault met beperkte credentials en hash-chained immutable accesslog.
5. Voer de incumbent uit en freeze targets op `val`, operating points op
   `calibration` en operationele vereisten vóór protected toegang.
6. Train uitsluitend op `train`; selecteer checkpoints alleen op `val`.
7. Pre-registreer één immutable kandidaat en open `test` en `background-test`
   één keer; challenge-labels blijven sealed.
8. Bewaar raw predictions, herbereken paired/subgroepmetrics in-process en neem
   één fail-closed releasebeslissing.
9. Gebruik protected resultaten nooit als feedback voor dezelfde kandidaat- of
   trainingsfamilie.

## Actuele fasebeslissing

Phase 4 blijft `in_progress`: het reproduceerbare lokale harnas is klaar, maar
de echte protected productbaseline kan nog niet geldig worden uitgevoerd.
Phase 5 blijft `not_ready`. Deze status verandert pas wanneer alle productgates
in dezelfde checksumbare workflow groen zijn; documentatie of fixture-scores
kunnen die voorwaarde niet omzeilen.

Normatieve evidence-run: `p4-2.0.1-9677d0ef37db82bcf39b`, gebonden aan
codecommit `70fb4b94e5cb7c248beec5a936ce186f38cc183c` en canonieke
benchmarkmanifesthash `0ea5ab07f46c509a7a24943b31d5e9bfd6368920609227bc47613e18e52c4642`.