◆ DOSSIER
De toetsingsstap · voorstellen → vooraf bekijken → goedkeuren → toepassen

Hoe een wijziging wordt aanvaard

voorstellen → vooraf bekijken → goedkeuren → toepassen, met bij elke stap aftakkende controles die bij een fout blokkeren (vereiste bytes ontbreken, niet-geregistreerde verwijzing naar bewijsmateriaal, tegenstrijdig eigenaarschap, verouderd goedgekeurd besluit, privacyregel) en met de bevoegdheidsgrens aangegeven: adapters mogen bytes klaarzetten, alleen de pakket-CLI mag schrijven

De hoofdregel is dat geaccepteerde registervermeldingen en gegenereerde weergaven niet met de hand worden aangepast. De repository bevat wel oudere vermeldingen van vóór de huidige poort, en één verliesvrije splitsingsmigratie waarvoor de eigenaar toestemming gaf. Wat hieronder staat, is de ondersteunde route voor nieuwe en gecorrigeerde kennis die wordt aanvaard. Die route telt vier stappen. Eerst wordt de wijziging opgesteld als voorstel, met precies wat erbij komt of verandert en waarop dat berust. Dan wordt ze voorgelegd: de eigenaar krijgt alles te zien en te lezen voordat er iets wordt vastgelegd. Daarna wordt ze aanvaard, als bewuste handeling, of niet. Pas dan wordt ze toegepast en in het register zelf geschreven. De openbare weergaven die een lezer ziet, worden daarna opnieuw opgebouwd vanuit het register, als aparte stap.

Achter die vier stappen zit een regel over wie mag handelen. Aanvaarde kennis mag alleen langs één gecontroleerde route worden vastgelegd; al het andere blijft daar strikt buiten. De hulpmiddelen die naar de archieven gaan om een scan op te halen of een zoekopdracht uit te voeren, kunnen materiaal voorbereiden en als concept neerzetten, maar het register zelf kunnen ze niet wijzigen. Probeert een van die hulpmiddelen het toch, dan mislukt de poging volledig, zonder dat het register half wordt bijgewerkt. Alleen de intakecoördinator voert aanvaarde wijzigingen langs die route door.

De poort kent twee soorten fouten. Sommige houden een wijziging meteen tegen. Een verwijzing kan nergens heen leiden, naar een document dat nooit is geregistreerd. Een wijziging kan dezelfde scan onder twee vermeldingen onderbrengen, of een verwijzing bevatten die niet klopt met wat ze benoemt. Een aanvaarde beslissing kan achterhaald zijn omdat de checksum van het voorstel of de projectrevisie is veranderd. Of een regel die een levend persoon beschermt, kan worden geschonden, bijvoorbeeld door contactgegevens van een levend persoon die niet als openbaar zijn gemarkeerd of geen bron vermelden. Andere fouten worden gemarkeerd, niet tegengehouden: een bron waarvan het bestand niet bewaard is, zonder vastgelegde reden daarvoor, krijgt een markering. Zo blijft het ontbrekende document zichtbaar als ontbrekend en wordt het nooit voorgesteld alsof het er is. In beide gevallen komt de fout aan het licht voordat de wijziging vastligt.

Wat de poort controleert, reikt minder ver dan de waarheid. Ze controleert of een aanvaarde wijziging intern consistent is: de verwijzingen leiden ergens heen, de koppelingen met bewijsmateriaal zijn geregistreerd, en de vereiste bewijsbestanden zijn aanwezig, of er is een toegestane reden vastgelegd waarom ze ontbreken. Andere gevallen van ontbrekende bestanden kunnen zichtbaar blijven als validatiewaarschuwingen. De poort oordeelt niet over de geschiedenis en garandeert niet dat een bewering juist is. Het register kan twee lezingen bevatten die elkaar tegenspreken, en een keurig opgestelde wijziging kan nog steeds op een verkeerde lezing berusten. Daarom houdt de website ook openlijk bij welke waarden later gecorrigeerd moesten worden.