Een automatisering die zonder foutmelding eindigt, voelt al snel als een succes. De API gaf een positief antwoord, het beheersysteem toont een groen vinkje en de taak staat op ‘voltooid’. Toch zegt dat maar één ding: de technische opdracht is ergens geaccepteerd of uitgevoerd. Het zegt nog niet dat het eindresultaat klopt.
Dat verschil lijkt klein, maar is voor mij een van de belangrijkste lessen bij het bouwen van INDY. Een bericht kan volgens WordPress gepubliceerd zijn terwijl de publieke pagina door caching nog oude informatie toont. Een afbeelding kan geüpload zijn zonder als uitgelichte afbeelding zichtbaar te worden. Een serveractie kan slagen terwijl de applicatie daarna nog steeds niet goed reageert.
Daarom beschouw ik uitvoeren en verifiëren als twee afzonderlijke stappen. Pas wanneer het resultaat vanuit het perspectief van de gebruiker is gecontroleerd, is een automatisering werkelijk afgerond.
Een groen vinkje bewijst alleen dat een stap is uitgevoerd
Beheersystemen kijken meestal naar hun eigen deel van het proces. WordPress weet dat een bericht de status ‘gepubliceerd’ heeft gekregen. Een serverplatform weet dat een servicecommando is verstuurd. Een cachetool weet dat een leegmaakopdracht is gestart.
Geen van die systemen ziet automatisch het volledige resultaat. Tussen de beheeractie en de bezoeker kunnen nog verschillende lagen zitten: webserverconfiguratie, PHP, databaseverbindingen, applicatiecode, CDN, browsercache en externe diensten. Iedere laag kan ervoor zorgen dat een technisch geslaagde opdracht aan de voorkant toch verkeerd uitpakt.
Wie alleen het antwoord van de uitvoerende tool controleert, verifieert dus vooral zijn eigen bedoeling. Wie daarna de publieke website controleert, verifieert de werkelijkheid.
De publieke voorkant is de onafhankelijke controle
Na iedere websitewijziging laat ik INDY daarom ook de publieke URL bekijken. Die controle gebeurt zonder ingelogde WordPress-sessie. Dat is belangrijk, omdat een beheerder soms andere content of een andere cachelaag ziet dan een gewone bezoeker.
Bij een nieuw blogartikel controleer ik minimaal drie dingen. Eerst moet WordPress melden dat het exacte bericht gepubliceerd is. Daarna moet de permalink publiek bereikbaar zijn. Tot slot moet het antwoord daadwerkelijk HTML bevatten en geen foutpagina, redirectlus of onverwachte statuscode zijn.
Voor een uitgelichte afbeelding geldt hetzelfde principe. Een succesvol media-ID bewijst dat het bestand in WordPress staat. Het opnieuw uitlezen van het bericht bewijst dat het media-ID eraan gekoppeld is. Pas de publieke artikelpagina laat zien of die koppeling ook in de uiteindelijke presentatie terechtkomt.
Waarom caching automatisering extra verraderlijk maakt
Caching is een goed voorbeeld van een systeem dat technisch correct kan werken en toch verwarring veroorzaakt. WordPress kan de nieuwe inhoud al bevatten, terwijl een paginacache, FastCGI-cache of CDN nog een oudere versie serveert.
De verkeerde reactie is om direct alle caches tegelijk leeg te maken. Dan verdwijnt mogelijk het symptoom, maar weet je nog steeds niet welke laag de oorzaak was. Bovendien maak je het moeilijker om te begrijpen wat er werkelijk gebeurde.
Een betere volgorde is gericht controleren. Eerst kijk ik of de publieke pagina de wijziging toont en of assets correct laden. Alleen wanneer daar een aantoonbaar verschil zit, wordt de relevante cachelaag aangepakt. Bij stylingproblemen controleer ik eerst de assets, daarna eventueel gegenereerde CSS en pas vervolgens de caches in een vaste volgorde.
Automatisering heeft een verificatiecontract nodig
Voor iedere geautomatiseerde actie probeer ik vooraf vast te leggen wat ‘geslaagd’ precies betekent. Dat noem ik voor mezelf het verificatiecontract. Het beschrijft niet alleen welke opdracht wordt uitgevoerd, maar ook welk bewijs daarna nodig is.
- Content publiceren: het bericht heeft de status gepubliceerd en de publieke permalink reageert correct.
- Een afbeelding koppelen: het media-ID staat op het juiste bericht en de publieke pagina blijft correct bereikbaar.
- Een service herladen: de service draait en de betrokken applicatie geeft daarna een geldige healthcheck.
- Een redirect maken: het bronpad verwijst naar de bedoelde eindbestemming zonder lus.
- Een incident herstellen: de oorspronkelijke fout is verdwenen en een onafhankelijke controle bevestigt het herstel.
Zonder zo’n contract is ‘voltooid’ vooral een administratieve status. Met een verificatiecontract wordt het een controleerbare technische uitspraak.
Een mislukte controle is waardevolle informatie
Wanneer de verificatie mislukt, moet een automatisering niet eindeloos dezelfde actie herhalen. Dat kan het probleem juist vergroten. INDY behandelt zo’n afwijking als een incident dat eerst onderzocht moet worden.
De eerste stap is read-only onderzoek. Welk object is gewijzigd? Wat meldt het beheersysteem? Wat ziet de publieke voorkant? Zijn er recente fouten, afwijkende servermetingen of mislukte taken? Pas daarna ontstaat een herstelvoorstel met een vermoedelijke oorzaak, de impact, een beperkte wijziging, het risico en een nieuw verificatieplan.
Belangrijk is dat het systeem zijn eigen voorstel niet mag goedkeuren. Een cache legen, service herladen of server herstarten kan gevolgen hebben. Voor zulke acties blijft expliciete toestemming nodig. Automatisering versnelt het onderzoek en de uitvoering, maar neemt de verantwoordelijkheid niet stilzwijgend over.
De juiste volgorde maakt automatisering betrouwbaar
De workflow die ik steeds opnieuw gebruik bestaat uit vier duidelijke fasen:
- Inventariseren: bepaal het exacte domein, object, bericht of de server waarop de opdracht betrekking heeft.
- Actuele toestand lezen: controleer status, configuratie en relevante metingen voordat er iets verandert.
- Gericht uitvoeren: voer alleen de kleinst mogelijke actie uit waarvoor toestemming bestaat.
- Onafhankelijk verifiëren: controleer het beheerde resultaat én de publieke of operationele uitkomst.
Deze volgorde voelt misschien zorgvuldiger dan nodig voor een kleine wijziging. In de praktijk maakt ze juist snelheid mogelijk. Omdat iedere stap afgebakend en controleerbaar is, hoeft een automatisering niet voor elk detail opnieuw te improviseren.
AI maakt verificatie belangrijker, niet minder belangrijk
AI kan snel informatie combineren, afwijkingen herkennen en acties voorbereiden. Daardoor wordt het verleidelijk om steeds meer zelfstandig te laten uitvoeren. Maar hoe groter de snelheid en schaal, hoe belangrijker het bewijs dat iedere actie het bedoelde resultaat opleverde.
Voor mij zit betrouwbare AI-automatisering daarom niet in een model dat nooit fouten maakt. Zo’n model bestaat niet. De betrouwbaarheid komt uit de structuur eromheen: beperkte bevoegdheden, expliciete bevestigingen, een auditspoor en onafhankelijke verificatie.
Een goede automatisering zegt dus niet alleen: “Ik heb het uitgevoerd.” Ze kan ook laten zien wat er vóór de wijziging stond, wat exact is veranderd en welk bewijs bevestigt dat het eindresultaat klopt.
Pas na de controle is het werk klaar
Een positieve API-respons is nuttig. Een groene taakstatus ook. Maar geen van beide is hetzelfde als een goed werkende website of applicatie.
Door uitvoering en verificatie bewust van elkaar te scheiden, worden fouten sneller zichtbaar en herstelacties kleiner. Dat maakt automatisering niet onnodig voorzichtig. Het maakt haar professioneel.
Mijn standaard is daarom eenvoudig geworden: als het resultaat niet onafhankelijk is gecontroleerd, is de automatisering nog niet klaar.