🤖 AI

Protocol-Driven Development: Governing Generated Software Through Invariants and Evidence

Dit artikel introduceert Protocol-Driven Development (PDD), een governance-model voor geautomatiseerde software-engineering dat prioriteit geeft aan machine-afdwingbare protocollen die structurele, gedragsmatige en operationele invarianten definiëren boven tijdelijke code, zodat gegenereerde implementaties uitsluitend worden toegelaten op basis van verifieerbaar bewijs van protocolconformiteit in plaats van vertrouwen in de generator.

Oorspronkelijke auteurs: Jun He, Deying Yu

Gepubliceerd 2026-05-14

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Jun He, Deying Yu

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een enorm bouwproject runt waarbij je een vloot van ongelooflijk snelle, superintelligente robots hebt ingehuurd om huizen te bouwen. Deze robots kunnen blauwdrukken genereren en muren bouwen in seconden. Omdat ze echter zo snel zijn en soms een beetje onvoorspelbaar, kunnen ze een huis bouwen dat er aan de buitenkant fantastisch uitziet, maar een verborgen valdeur bevat, het verkeerde houtsoort gebruikt of per ongeluk een brandalarm activeert.

In het verleden vertrouwden we op geschreven instructies (specificaties in natuurlijke taal) of het controleren van enkele kamers (tests) om ervoor te zorgen dat de robots goed werk leverden. Maar de auteurs van dit artikel betogen dat, nu AI code zo goedkoop en snel genereert, die oude methoden niet meer volstaan. Geschreven instructies zijn te vaag, en het controleren van enkele kamers bewijst niet dat het hele huis veilig is.

Dit artikel stelt een nieuwe werkwijze voor die Protocol-Driven Development (PDD) wordt genoemd.

Het Kernidee: Het "Regelboek" is Koning, het "Huis" is Tijdelijk

De hoofdstelling van het artikel is simpel: "Code is vluchtig; protocol is soeverein."

Denk aan het Protocol als een strikt, onbreekbaar Regelboek (of een grondwet) voor een specifiek type gebouw. Denk aan de Code (de daadwerkelijke software) als het Huis dat door de robots wordt gebouwd.

Oude manier: We schrijven een vage beschrijving zoals "Bouw een gezellig huis", en hopen dat de robot het goed doet. Als het een huis bouwt met een valdeur, repareren we het later.
PDD-methode: Voordat de robot zelfs maar begint, geven we hem een machine-leesbaar Regelboek. Dit Regelboek zegt niet alleen "bouw een huis"; het zegt:
1. Structuur: "De voordeur moet exact 3 voet breed zijn en van staal zijn gemaakt." (Structurele invarianten)
2. Gedrag: "Als je drie keer klopt, moet de deur openen. Als je één keer klopt, moet hij op slot blijven." (Gedragsinvarianten)
3. Operaties: "Het is niet toegestaan een kettingzaag te gebruiken, je mag geen brandweer bellen, en je moet het bouwen binnen 10 minuten afronden." (Operationele invarianten)

Als de robot een huis bouwt dat aan deze regels voldoet, krijgt hij toegang. Als hij een prachtig huis bouwt dat een kettingzaag gebruikt of een deur die open gaat bij één klop, wordt het direct afgewezen, ongeacht hoe mooi het eruitziet.

De Drie Pijlers van het Regelboek

Het artikel definieert het Regelboek (Protocol) als een combinatie van drie dingen:

De Handdruk (Structuur): Dit is als de vorm van de deur en de sleutel. Het zorgt ervoor dat het huis perfect past bij de buurt. Als het huis een ronde deur heeft maar de straat accepteert alleen vierkante deuren, wordt het afgewezen.
De Wetten van de Fysica (Gedrag): Dit zijn de regels over hoe het huis optreedt. Gaat het licht aan als je de schakelaar omzet? Blijft het huis staan als de wind waait? Het artikel stelt "property-based testing" voor, wat neerkomt op het testen van het huis met duizenden willekeurige windstoten om ervoor te zorgen dat het nooit omvalt, in plaats van het slechts één keer te controleren op een rustige dag.
Het Vergunning (Operaties): Dit is de lijst met "wat je mag doen". Het is een strikte vergunning die zegt: "Je mag elektriciteit gebruiken, maar je mag niet de gasleiding aanraken." Dit voorkomt dat de robot verborgen functies insluist (zoals in het geheim een dienst van derden bellen of bestanden naar een harde schijf schrijven) die niet zijn goedgekeurd.

De "Validator-lus": De Beveiliger

In dit nieuwe systeem wordt de robot (de codegenerator) behandeld als niet-vertrouwd. Het is slechts een voorstelmachine.

Voordat er code in het systeem mag, moet deze door een Validator-lus gaan. Denk hierbij aan een superstreng beveiligingspersoneel met een checklist:

Controleer de Blauwdruk: Komt de code overeen met de structurele regels?
Voer de Simulaties Uit: Gedraagt de code zich correct onder duizenden verschillende scenario's?
Controleer het Vergunning: Heeft de code geprobeerd iets te doen wat niet was toegestaan?

Als de code alle drie de tests doorstaat, geeft de bewaker een Toelatingscertificaat af (een Evidence Chain genoemd). Dit is een digitale bon die onomstotelijk bewijst dat dit specifieke stuk code is gecontroleerd tegen het Regelboek en is geslaagd.

Waarom Dit Belangrijk Is: De "Natuurlijke Taal-belasting"

De auteurs noemen de kosten van het omgaan met vage instructies de "Natuurlijke Taal-belasting".

De Belasting: Als je zegt "maak het snel", maakt de ene robot het snel met een Ferrari, de andere met een fiets. Als je zegt "bel niet de politie", kan de ene robot dat interpreteren als "bel niet de politie", maar kan de andere denken "bel de politie niet tenzij er brand is".
De Oplossing: PDD verwijdert deze belasting door vage woorden te vervangen door strikte, machine-afdwingbare regels. In plaats van te discussiëren over wat "snel" betekent, zegt het Regelboek "moet binnen 10 seconden klaar zijn".

De Grote Opbrengst: Uitwisselbare Onderdelen

Omdat de code slechts een "verwezenlijking" is van het Regelboek, kun je het gemakkelijk vervangen.
Stel je voor dat je een huis hebt gebouwd met de robot en het heeft de inspectie doorstaan. Later huur je een andere robot in om het huis opnieuw te bouwen. Zolang het nieuwe huis exact hetzelfde Regelboek volgt (zelfde deurbreedte, zelfde lichtgedrag, zelfde vergunning), kun je het oude huis vervangen door het nieuwe zonder dat iemand het merkt. Het "Huis" (code) is tijdelijk en vervangbaar; het "Regelboek" (protocol) is de permanente, vertrouwde autoriteit.

Samenvatting

Het artikel betoogt dat naarmate AI beter wordt in het schrijven van code, we moeten stoppen met ons zorgen te maken over hoe de code is geschreven en moeten beginnen met ons zorgen te maken over welke regels het moet volgen.

Oud Model: Vertrouw de schrijver, controleer enkele voorbeelden.
Nieuw Model (PDD): Vertrouw de schrijver niet, dwing een strikt Regelboek af, en eis een digitale bon die bewijst dat de regels zijn gevolgd.

De code is slechts een tijdelijke gast; het Protocol is de permanente gastheer.

Technische Samenvatting: Protocol-gedreven Ontwikkeling (PDD)

Probleemstelling

De opkomst van geautomatiseerde programmasynthese heeft de marginale kosten voor het produceren van kandidaat-software-implementaties drastisch verlaagd. Deze verschuiving creëert echter een kritieke governance-bottleneck: het bepalen welke gegenereerde artefacten binnen een softwaresysteem toelaatbaar zijn. Traditionele benaderingen lijden in deze context aan specifieke beperkingen:

Specificatie-gedreven Ontwikkeling (SDD): Natuurlijke taalspecificaties zijn semantisch ambigu, wat leidt tot interpretatiedrift en inconsistente aannames tussen verschillende ingenieurs of generatieve systemen.
Test-gedreven Ontwikkeling (TDD): Hoewel tests uitvoerbare bewijzen bieden, zijn ze extensieel (het verifiëren van geselecteerde gevallen) in plaats van intensioneel (het definiëren van de volledige ruimte van toelaatbare implementaties). Ze slagen er vaak niet in structurele contracten, autoriteitsgrenzen of operationele beperkingen zoals latentielimieten en restricties op bijwerkingen vast te leggen.
De "Natuurlijke Taal Belasting": De terugkerende kosten voor het interpreteren, reconciliëren en onderhouden van ambigu tekstuele beschrijvingen creëren een kloof tussen intentie en afdwingbare beperkingen.

Wanneer code tegen lage kosten kan worden gesynthetiseerd en opnieuw gegenereerd, wordt broncode minder duurzaam dan de beperkingen die de toelaatbaarheid ervan bepalen. De centrale uitdaging verschuift van "hoe te implementeren" naar "welke beperkingen moet elke acceptabele implementatie voldoen".

Methodologie: Protocol-gedreven Ontwikkeling (PDD)

PDD stelt een ontwikkelmodel voor waarbij het primaire software-artefact een machine-afdwingbaar protocol is in plaats van implementatiecode. Het model behandelt implementaties als vervangbare realisaties die worden ontdekt via een beperkte zoektocht, en worden toegelaten uitsluitend als ze voldoen aan het regulerende protocol en verifieerbaar bewijs produceren.

De Protocol Formalisme

Een protocol $P$ wordt gedefinieerd als een triplet $P = (S, B, O)$ , waarbij de conjunctie van deze drie invariantklassen de ruimte van toelaatbare implementaties ( $I_P$ ) definieert:

Structurele Invarianten ( $S$ ): Stijve type- en schema-beperkingen over invoer, uitvoer, interfacesignaturen en versiebeheerregels (bijv. JSON Schema, OpenAPI, Protocol Buffers). Deze zorgen voor een getypeerde handshake.
Gedragsinvarianten ( $B$ ): Semantische predicaten die voor alle geldige invoer en toestanden moeten gelden (bijv. idempotentie, determinisme, monotonie). Deze worden gecodeerd als eigenschap-gebaseerde asserties of logische wetten in plaats van specifieke testgevallen.
Operationele Invarianten ( $O$ ): Expliciete capabiliteitsgrenzen die bijwerkingen, externe afhankelijkheden, latentie, geheugengebruik en resourcequota's omvatten. Deze fungeren als capabiliteitsmanifesten of beleidsgrenzen.

De Validatie-lus

PDD introduceert een architectuurstijl die de softwarelevenscyclus scheidt in distincte rollen:

Protocol Authoring: Het vertalen van architecturale intentie naar het machine-afdwingbare triplet $(S, B, O)$ .
Implementatiegeneratie: Geautomatiseerde generators doorzoeken de implementatieruimte naar kandidaten die voldoen aan het protocol.
Validatie: Een Validatie-engine voert drie lagen van checks uit:
- Structurele validatie (interfaceconformiteit).
- Gedragsvalidatie (eigenschap-gebaseerde testen, metamorfe relaties).
- Operationele validatie (sandbox-uitvoering om capabiliteitslimieten te verifiëren).
Bewijs-producerende Acceptatie: Een implementatie wordt uitsluitend toegelaten als de validator een ondertekende Bewijsketen genereert. Deze keten cryptografisch koppelt de protocolversie, het implementatie-artefact, de identiteit van de validator en de validatieresultaten.

Theoretische Fundamenten

Het artikel formaliseert PDD via verschillende sleutelrelaties:

Ruimte van Toelaatbare Implementaties: $I_P = I_S \cap I_B \cap I_O$ . Het protocol definieert een regio van de implementatieruimte, niet een enkel programma.
Protocol-niveau Substitueerbaarheid: Twee implementaties zijn substitueerbaar als ze beide voldoen aan $P$ en de client uitsluitend afhankelijk is van garanties die door $P$ worden ingesloten. Dit maakt regeneratie en optimalisatie mogelijk zonder downstream-afhankelijkheden te verbreken, mits die afhankelijkheden "protocol-respecterend" zijn.
Geldigheid (Soundness): Een validator is geldig als deze uitsluitend implementaties toelaat die voldoen aan het protocol. Het artikel stelt dat toelating alleen betekenisvol is in relatie tot een geldige validator en een gespecificeerd protocol.

Belangrijkste Bijdragen

Het artikel levert de volgende specifieke bijdragen:

Frameworkvoorstel: Introduceert PDD als een framework dat protocollen, niet code, behandelt als het duurzame artefact van geautomatiseerde engineering.
Formalisatie: Definieert een protocol als een triplet van structurele, gedrags- en operationele invarianten die gezamenlijk een ruimte van toelaatbare implementaties definiëren.
Kernrelaties: Definieert protocolconformiteit, protocol-niveau substitueerbaarheid en bewijs-producerende acceptatie als de regulerende relaties voor toelating.
Architectuurstijl: Schetst de Validatie-lus, die protocol authoring, generatie, validatie en bewijsbehoud scheidt.
Nieuwe Artefacten: Introduceert Bewijsketens en Ontdekkingslogs om kandidaten te koppelen aan validatie-uitkomsten en herkomst, wat traceerbaarheid en replay mogelijk maakt.
Conceptuele Analyse: Karakteriseert de "Natuurlijke Taal Belasting" en betoogt dat machine-afdwingbare protocollen een gedisciplineerde weg bieden van narratieve intentie naar expliciete toelaatbaarheidsvoorwaarden.
Synthese: Verbindt PDD met formele methoden, eigenschap-gebaseerde testen, policy-as-code, softwareherkomst en runtime-governance voor autonome systemen.

Resultaten en Claims

Het artikel presenteert geen empirische experimentele resultaten (bijv. benchmarkprestaties of case-studie-metrieken), maar presenteert eerder een theoretisch en architecturaal voorstel. De claims worden geformuleerd als hypothesen voor toekomstige empirische validatie:

Governance-verschuiving: PDD verschuift het "duurzame" aspect van software-engineering van transiënte code naar het protocol en het bewijs van conformiteit.
Verminderde Ambiguïteit: Door beschrijvende statements te vervangen door restrictieve asserties, beoogt PDD structurele, gedrags- en operationele divergentie (de "Natuurlijke Taal Belasting") te verminderen.
Veilige Regeneratie: Het model claimt veilige regeneratie van implementaties mogelijk te maken (bijv. taalmigratie, optimalisatie) zolang de nieuwe implementatie voldoet aan hetzelfde protocol en de downstream-clients protocol-respecterend zijn.
Traceerbaarheid: De Bewijsketen biedt een mechanisme om toelatingsbeslissingen te reconstrueren en te verifiëren dat een artefact is toegelaten op basis van specifieke beperkingen, in plaats van op vertrouwen in de generator.

Betekenis en Positionering

Het artikel positioneert PDD als een noodzakelijke evolutie voor het tijdperk van "Software 2.0" en geautomatiseerde synthese. De betekenis ligt in het verenigen van uiteenlopende tradities—formele methoden, testen, beleidsafdwinging en herkomst—in één enkel toelatingsmodel.

Onderscheid met Bestaand Werk: In tegenstelling tot Schema-first ontwikkeling (die zich richt op structuur), TDD (die zich richt op functionele voorbeelden) of Policy-as-Code (die vaak op runtime werkt), verheft PDD het protocolbundel tot het primaire artefact dat gezamenlijk structuur, gedrag, operationele autoriteit en toelatingsbewijs reguleert.
Filosofie: De kernthese is "Code is transiënt; protocol is soeverein". Naarmate implementatiekosten de nul benaderen, wordt het intellectuele product van software-engineering de set formele beperkingen die toelaatbaar gedrag definiëren en het bewijs dat aan die beperkingen is voldaan.
Toekomstig Werk: Het artikel schetst een empirische agenda om PDD te testen tegen SDD- en TDD-baselines, met focus op het verminderen van ambiguïteit, betrouwbaarheid van regeneratie, substitueerbaarheid, validatie-overhead en governance-effectiviteit. Het suggereert toekomstige richtingen, waaronder herbruikbare protocolregisters, geautomatiseerde protocolsynthese en diepere integratie met formele verificatietools.

Kort samengevat, stelt PDD een governance-laag voor geautomatiseerde software-engineering voor waarbij de "wet" het protocol is, en de "burgers" gegenereerde implementaties zijn die uitsluitend worden toegelaten via verifieerbaar bewijs van conformiteit.