In 2026 bouwde een ondernemingsteam een ​​agent die incidentbeheertickets uitleest, er post-mortems van maakte en automatisch reparatie-items aanmaakte. Een tweede agent in hetzelfde team keek naar nieuwe werkitems en opende concept-PR's voor elk werkitem om ontwikkelaars op weg te helpen. Een ontwikkelaar heeft een van die PR's beoordeeld, vond deze redelijk, keurde deze goed en voegde deze samen met de hoofdtak.

**Het probleem was dat de wijziging volledig verzonnen was.**

De agent had een plausibel ogende oplossing bedacht voor een probleem dat niet bestond op de manier die het beschreef. De verandering heeft een reëel productiescenario teniet gedaan. Een echte klant merkte het op. Er was een storing.

Dit is de reden waarom de EDD-grondwet bestaat.

De grondwet is een enkel bestand dat elke niet-triviale wijziging aan de codebase regelt. Het definieert hoe een voltooide verandering eruit ziet, welk bewijsmateriaal deze moet bevatten, wat een uitgebreide audit moet omvatten en hoe de regels zelf kunnen evolueren. Elke agent en elk mens die de repository aanraakt, laadt deze bij elke sessie. De balk gaat alleen maar omhoog.

Dit bericht doorloopt stap voor stap de grondwet: het incident dat de grondwet motiveerde, de ontwerpvraag die het beantwoordt, hoe het is gestructureerd, hoe het is geschreven (en wat we in het begin verkeerd hebben gedaan), hoe amendementen werken en hoe het volledige pakket zich ontvouwt in een nieuwe repository.

Stap 1 - Wat het is

Het incident is de duidelijkst mogelijke illustratie van de faalwijze die EDD wil voorkomen. De agent hallucineerde niet willekeurig. Het leverde een samenhangend, leesbaar en professioneel opgemaakt PR op. De ontwikkelaar die het beoordeelde, deed wat ontwikkelaars doen: ze lazen de bedoeling, vonden de bedoeling plausibel en keurden het goed. De kloof was niet de aandacht. Het gat was het ontbreken van bewijs. Niets in het beoordelingsproces vereiste dat de agent aantoonde dat het probleem dat hij beweerde op te lossen daadwerkelijk bestond, dat de oplossing echt gedrag aanpakte, of dat de verandering niets teweegbracht.

EDD beantwoordt die leemte met één enkele harde eis: als de agent het niet kan bewijzen, is de taak niet voltooid. Bewijs is geen samenvatting. Bewijs is geen bewering van vertrouwen. Bewijs is een artefact dat onafhankelijk kan worden geverifieerd: een mislukte test, een scanneruitvoer, een voor/na-screenshot, een planverschil. De PR draagt ​​het artefact of de PR is onvolledig.

De grondwet staat op `docs/methodology/CONSTITUTION.md`. Elke AI-agent die in het project is geconfigureerd, laadt deze bij elke sessie via zijn eigen laadbestand. De body is agent-neutraal: geen toolnamen, geen platformspecifieke syntaxis. Het definieert negen fundamentele principes, harde beperkingen met stabiele slug-ID’s, de 10-stappen implementatielus, auditdimensies, acceptatiecriteria voor bewijsmateriaal per wijzigingstype, trivialiteits-carve-outs voor werk met een laag risico, en de wijzigingsclausule.

Elke harde beperking heeft een slug zoals `[HC-EVIDENCE-BEFORE]` en verklaart drie dingen: de balk (wat waar moet zijn), de verificatie (hoe naleving wordt gecontroleerd) en de patroonbron (welk instructiebestand de implementatierichtlijnen uitwerkt).

De lus van 10 stappen is het operationele hart: definieer wat er is gedaan, schrijf een test die de kloof bewijst, zie hoe deze mislukt, leg vóór-bewijs vast, implementeer, kijk of de test slaagt, leg bewijs achteraf vast, verifieer documenten, audit over de aangegeven dimensies heen, en vervolgens menselijke beoordeling. Stappen 1 tot en met 4 vinden plaats vóór elke implementatiewijziging. Het bevel is constitutioneel omdat dit incident precies laat zien wat er gebeurt als dat niet het geval is.

Als extra waarborg ontleent EDD een kernprincipe van TDD: het scenario moet bewezen mislukken voordat het werk begint. Een bewijs dat aan het einde van een wijziging slaagt, is op zichzelf niet voldoende bewijs. Als de test ook vóór de wijziging is geslaagd, heeft de agent mogelijk iets gerepareerd dat nooit kapot is gegaan. Dit is een specifieke foutmodus in AI-ondersteunde workflows: een agent genereert een plausibel klinkende oplossing, de verificatie wordt uitgevoerd en de wijziging wordt verzonden alsof deze een echt probleem oplost. Door een gedocumenteerde falende toestand te vereisen voordat de implementatie begint, wordt deze kloof gedicht. De stap vóór het bewijs is niet slechts een basis voor vergelijking; het is een bewijs dat het probleem dat werd opgelost reëel was.

Van alle harde beperkingen die door de grondwet zijn doorgevoerd, hebben er twee meer gebreken geconstateerd dan alle andere samen, en ze zijn misschien wel de belangrijkste upgrade die EDD maakt voor elke AI-ondersteunde workflow: `[HC-EVIDENCE]` en `[HC-EVIDENCE-INTEGRITY]`. Beide worden gedeclareerd in `.github/copilot-instructions.md` - het gretig geladen bestand dat zich bij elke sessie in de context van de agent bevindt.

'[HC-EVIDENCE]' vereist dat elke PR feitelijke voor- en na-artefacten bevat - geen beschrijvingen van wat de artefacten zouden laten zien, geen samenvattingen van wat de agent denkt dat er is gebeurd, maar de ruwe output. `[HC-EVIDENCE-INTEGRITY]` gaat verder: het vereist dat het bewijsmateriaal in de PR kan worden herleid tot het werk dat feitelijk is verricht. Het valideert dat de PR bevat wat het zegt te bevatten.

Samen hebben deze twee beperkingen honderden door AI gegenereerde bugs onderschept voordat ze werden beoordeeld. De faalwijze waartegen zij waken is geen hallucinatie in de voor de hand liggende zin. Het is subtieler gedrag: de agent markeert een taak als voltooid, schrijft een zelfverzekerde PR-beschrijving en neemt op wat als bewijsmateriaal leest - maar het bewijsmateriaal is samengesteld en niet vastgelegd. De agent beschreef hoe de uitvoer eruit zou moeten zien in plaats van de opdracht uit te voeren en de daadwerkelijke uitvoer op te nemen.

`[HC-EVIDENCE-INTEGRITY]` is specifiek effectief bij het onderkennen van wat het 'Ik kon dat niet'-patroon zou kunnen worden genoemd. Een agent die voor een moeilijke of onbekende taak staat, zal soms beweren dat de taak onmogelijk is of buiten de reikwijdte valt, in plaats van deze te proberen. De claim wordt vaak opgevat als een beperking: een instrument dat niet bestaat, een beperking die de aanpak verhindert, een omgeving die de operatie niet ondersteunt. '[HC-EVIDENCE-INTEGRITY]' brengt dit naar voren: als de agent beweert dat een taak niet kan worden uitgevoerd, moet de PR bewijzen tonen dat de taak daadwerkelijk is geprobeerd en dat het obstakel reëel is. "Ik kon de testsuite niet uitvoeren" vereist een terminaluitvoer die de fout aangeeft, en niet een verklaring dat de fout is opgetreden. Zonder die vereiste is het vermijden van moeilijk werk door de agent tijdens de beoordeling onzichtbaar en wordt de taak onvolledig verzonden alsof deze is voltooid.

Stap 2 - Hoe we hier zijn gekomen

De grondwet is geen opeenstapeling van geleerde lessen. Het is het antwoord op één ontwerpvraag die aan het begin werd gesteld: hoe dwing je een AI-agent om zijn werk elke keer opnieuw te bewijzen, op een manier die niet te omzeilen is en niet afhankelijk is van een mens die zich herinnert om te vragen?

Het beantwoorden van die vraag dwong een ontbinding af. Voor bewijs is het nodig dat u weet hoe de uitvoering eruit ziet voordat de implementatie begint - dat leverde de documentatiestap op. Bewijs vereist een test die vóór de verandering faalt en daarna slaagt - wat de testdiscipline voor het falen/slaagden opleverde. Bewijs vereist een voor-toestand die werd vastgelegd voordat de implementatie iets aanraakte - wat de vereiste voor bewijs opleverde. Bewijs vereist een onafhankelijke audit die vastlegt wat bewijs per verandering niet kan: dat heeft de auditdimensies opgeleverd. En bewijs moet het beoordelingsproces overleven zonder te worden verzacht – dat bracht de harde beperking met zich mee dat de menselijke recensent de laatste poort is en de enige poort die niet kan worden geautomatiseerd.

Het resultaat is de lus van 10 stappen. Elke stap bestaat omdat het verwijderen ervan een gat creëert waar onbewezen werk doorheen kan. De lus is geen checklist. Het is een causale keten.

Van daaruit werd de vraag: welke categorieën van mislukkingen kan een agent produceren die de lus niet standaard ondervindt? Dat leverde de harde beperkingen op. Beveiligingslint zwijgde terwijl de regels werden gedegradeerd en produceerde "[HC-SECURITY-LINT]". Een karaktercoderingsfout in een ingezet artefact produceerde `[HC-ASCII-PUNCT]`. Elke HC sluit een specifieke faalklasse af met een specifieke geautomatiseerde verificatie. Regels die geen verificatie konden benoemen, werden afgewezen: als een controle niet kan worden geautomatiseerd, is de regel ambitieus en niet grondwettelijk.

De uiteindelijke ontwerpvraag was: wie bestuurt de grondwet zelf? Het antwoord is de ratel. De grondwet kan alleen maar strenger worden. Amendementen moeten het bewijs bevatten dat het gedrag van agenten verbetert of standhoudt. De vloer beweegt nooit naar beneden. Dit betekent dat de grondwet in de loop van de tijd kan worden vertrouwd op een manier die een levensstijlgids niet kan: elke versie is strikt genomen sterker dan de vorige.

Stap 3 - Hoe het is gestructureerd

De grondwet volgt een drielaagse architectuur.

**Laag 1: De canonieke hoofdtekst.** Eén bestand, `docs/methodology/CONSTITUTION.md`. Dit is de bron van de waarheid. Het is agent-neutraal: er worden geen aannames gedaan over welke AI-tool in gebruik is. Het definieert principes, harde beperkingen, de loop, auditdimensies, acceptatiecriteria voor bewijsmateriaal, uitzonderingen op trivialiteiten en de zelfverbeteringsclausule. Wanneer de hoofdtekst ongeveer 250 regels overschrijdt, worden de regels die van toepassing zijn op een specifiek padpatroon verwerkt in bestanden met een padbereik, met een aanwijzer van één regel in de hoofdtekst.

**Laag 2: Agent-laders.** Elke geconfigureerde agent krijgt precies één laadbestand op de locatie die de agent gretig laadt. Voor GitHub Copilot is dat `.github/copilot-instructions.md`. Voor Claude is dat `CLAUDE.md`. De lader importeert of lijnt het grondwetsorgaan uit, afhankelijk van wat het platform momenteel ondersteunt. De lader wordt mechanisch weergegeven vanuit het canonieke lichaam; het is niet met de hand bewerkt. Als een project drie AI-tools gebruikt, zijn er drie laadbestanden, die allemaal dezelfde constitutionele inhoud weergeven.

**Laag 3: Regels met padbereik.** Sommige regels zijn alleen van toepassing op specifieke bestandstypen. Toegankelijkheids- en lokalisatieregels zijn van toepassing op JSX- en CSS-bestanden, niet op infrastructuursjablonen. Deze regels leven in instructiebestanden met een frontmatter-glob:

De agent laadt deze bestanden alleen wanneer deze een overeenkomend pad raakt. Hierdoor blijft het contextbudget voor gretige belasting beperkt (kernregels zijn altijd aanwezig, gespecialiseerde regels worden op verzoek geladen) en wordt voorkomen dat toegankelijkheidsrichtlijnen verschijnen bij een Bicep-sjabloonbewerking.

Ondersteunende bestanden vervolledigen de structuur: `/constitute` opdrachtteksten in `.github/prompts/`, mappen per functie op `docs/methodology/features/`, eval scenario's op `docs/methodology/eval/scenarios/`, en `verify-sequence.yaml` op de repo-root die de CI-poortvolgorde definieert.

Stap 4 - Hoe we het hebben geschreven

**Context is alles. Wat niet in de context staat, is dood voor de agent.**

Dit is het allerbelangrijkste inzicht bij het schrijven van een grondwet voor door AI bestuurde ontwikkeling. Een regel die bestaat in een bestand dat de agent nooit laadt, bestaat niet. Een harde beperking die verborgen zit in een document en alleen wordt geladen als een specifiek bestandspad wordt aangeraakt, is voor geen enkel ander pad een harde beperking. De grondwet moet altijd in zijn context staan, en alles wat altijd van toepassing moet zijn, moet daarin leven.

Dit leidt tot drie auteursbeslissingen:

**Tokenoptimalisatie is niet onderhandelbaar.** De canonieke hoofdtekst richt zich op minder dan 300 lijnen en 8k tokens. Elk amendement moet de symbolische efficiëntie behouden of verbeteren; uitgebreide regels die bereiken wat beknopte regels kunnen, worden alleen al op die gronden verworpen. Dit is geen stijlvoorkeur. Het is een lastbeperking. Als de grondwet het budget overschrijdt, beginnen agenten in kleinere contextvensters deze in te korten, en ingekorte regels zijn geen regels.

**Voorwaardelijk laden via frontmatter.** Regels die alleen van toepassing zijn op specifieke bestandstypen worden buiten de canonieke hoofdtekst verwerkt en in padgerichte instructiebestanden met een frontmatter glob-declaratie. Begeleiding voor toegankelijkheid en lokalisatie wordt alleen geladen wanneer de agent JSX of CSS aanraakt. Infrastructuurbegeleiding wordt alleen geladen wanneer de agent Biceps aanraakt. Het canonieke lichaam houdt een aanwijzer van één lijn bij. De agent laadt het padgerichte bestand alleen als dit relevant is. Dit is niet alleen efficiëntie: het voorkomt dat toegankelijkheidsrichtlijnen opduiken als een afleiding bij een infrastructuurbewerking, waardoor de agent wordt getraind om deze te negeren.

Dit project maakt geen gebruik van door frontmatter gescheiden regelbestanden, omdat de constitutie klein genoeg is om volledig in de context te worden geladen: een enkele ontwikkelaar, een gefocust bereik, een gestroomlijnde regelset. Voor grotere teams verandert de calculus. Een project op ondernemingsschaal dat momenteel EDD uitvoert, heeft 75 harde beperkingen op het gebied van beveiliging, compliance, toegankelijkheid en platformspecifieke vereisten. Het samenbrengen van alle 75 in één enkel gretig bestand zou de grondwet voor de meeste agenten ruimschoots buiten het contextbudget duwen. Frontmatter-splitsing houdt de canonieke hoofdtekst onder de 250 regels (een samenvattende aanwijzer per domein) en laadt het volledige regeldetail alleen wanneer de agent overeenkomende paden aanraakt. De grondwet blijft snel en mager. De regels blijven compleet. De tokenkosten blijven beperkt.

**Amendementen als eenheden van verandering.** Een grondwetswijziging is geen woordwijziging in een afwaarderingsbestand. Het is een bundel met drie artefacten: de exacte regeldelta, het verificatiemechanisme dat toekomstige overtredingen zal opmerken, en een gedragsevaluatiescenario dat bewijst dat het gedrag van agenten verbetert. Alle drie verzenden ze samen in hetzelfde PR. Het amendement is atomair. Gedeeltelijke amendementen die beloven de verificatie later toe te voegen, worden afgewezen - later komt niet, en een niet-verifieerbare regel is decoratie.

**Schrijf de evaluaties en rubrieken op voordat je denkt dat je ze nodig hebt.** De evaluatie is de ratel. Als dit niet gebeurt, worden amendementen te goeder trouw aanvaard en verandert de grondwet. De rubriek beoordeelt het gedrag van agenten op basis van realistische scenario's. Elke nieuwe regel levert minstens één scenario op. De rubriek levert een numerieke score op. Het amendement wordt alleen aangenomen als de score in de werkboom gelijk is aan of hoger is dan de basislijn.

**Documenteer wat u wel en niet kunt dekken. Lieg niet tegen jezelf over de dekking.**

Al vroeg verklaarde de harde beperking van de toegankelijkheid dat nieuwe interactieve UI-oppervlakken volledige dekking vereisten met behulp van axe-core. Dit voelde veelomvattend. In de praktijk was het naïef. axe-core verwerkt een betekenisvolle subset van WCAG - het vangt ontbrekende labels, oriëntatiepuntenstructuur, focusvolgorde en contrast op in gevallen waarin de DOM volledig wordt weergegeven en kleuren worden opgelost. Het houdt geen rekening met de aankondigingslogica van de schermlezer, cognitieve laadpatronen, complexe widgettoetsenbordcontracten of contrastproblemen met gradiënten en SVG-afbeeldingsknooppunten waarbij de berekende kleur niet kan worden opgelost.

Het hebben van `[HC-A11Y-GATE]` met axe-core in de verificatie betekent niet dat alle bugs nul zijn. Het betekent dat de specifieke axe-core-regelset tegen de weergegeven DOM ingaat. Het verschil is enorm van belang bij claims voor PR-dekking.

De oplossing was ontbinding. In plaats van 'axe-core clean' werd de verificatie herschreven om op te sommen welke WCAG-succescriteria de axe-core regelset deterministisch dekt (1.1.1 voor niet-tekstuele inhoud, 1.3.1 voor informatie en relaties, 1.4.3 voor contrast waar oplosbaar, 4.1.2 voor naam/rol/waarde) en die geen geautomatiseerde dekking hebben (1.3.3 zintuiglijke kenmerken, 2.4.6 semantiek van koppen en labels, alle 3.x Begrijpelijke criteria). In het gedeelte met bekende hiaten van de auditdimensie wordt nu expliciet vermeld: axe-core hanteert deze criteria; Hiervoor is handmatig scannen vereist. PR-recensenten zien de daadwerkelijke berichtgeving, en niet een samenvatting van vals vertrouwen.

Het bredere principe: documenteer voor elke verificatie wat er wordt opgemerkt en wat niet. "Beveiligingslint gaat door" betekent niet dat de codebase veilig is. "bijl-kern schoon" betekent niet WCAG 2.2 AA-conform. Benoem de kloof. Log het in de auditdimensie in. Vereist handmatig scannen voor het spleetoppervlak. Laat de geautomatiseerde controle niet in de plaats komen van het menselijke oordeel dat zij niet kan vervangen.

Stap 5 - Hoe we amendementen schrijven

Amendementen beginnen bijna nooit als amendementsvoorstellen. Ze beginnen als insecten.

Er komt een bug naar boven. De oplossing wordt toegepast. Voordat het wordt verzonden, stelt `/reflect` één vraag: is dit een eenmalige gebeurtenis, of ontbreekt er iets in de grondwet dat deze klasse van mislukkingen zou hebben betrapt? Als het antwoord eenmalig is, wordt de oplossing verzonden en is dat het einde. Als het antwoord luidt dat er iets ontbreekt, dan wordt `/constitute` aangeroepen.

**Het /reflect -> gap -> wijzigingspad.** `/reflect` onderzoekt de oplossing en classificeert deze: constitutionele kloof (geen regel dekt deze klasse van mislukkingen) of verificatieleemte (er bestond een regel maar geen geautomatiseerde controle dwong deze af). Beide routes leiden naar `/constitute`. Een constitutionele kloof levert een nieuwe HC op. Een verificatielacune leidt tot een strengere verificatie van een bestaande HC – meestal een nieuwe subsectie van de auditdimensie, een nieuwe scannerregel of een nieuw evaluatiescenario.

**De drie vereiste artefacten.** `/constitute` weigert verder te gaan zonder alle drie in dezelfde PR:

• **Regeldelta.** De exacte tekstwijziging, geclassificeerd: nieuwe regel, gewijzigde bewoording, verplaatsing (vervang en verwijder het oude), vervanging (leg de lat hoger met het oude als vloer) of verplaatsing. Duplicaten worden op zicht afgewezen.
• **Verificatiemechanisme.** De specifieke poort die een toekomstige overtreding zal opmerken: een testnaam, lintregel-ID, subsectie van de auditdimensie, controle van de scanneruitgangscode of een scenario voor gedragsevaluatie. Het moet bestaan ​​tijdens de commit-tijd. Regels zonder waarneembare overtredingen zijn decoratief.
• **Eval-scenario.** Opgeslagen in `docs/methodology/eval/scenarios/<id>.md`. Beschrijft een realistische situatie waarin de oude regel verkeerd agentgedrag veroorzaakt en de nieuwe regel het te scoren juiste antwoord oplevert.

**De ratel.** Nadat alle drie de artefacten zijn goedgekeurd, wordt de wijziging toegepast op een tak. De evaluatie druist in tegen de regels van de hoofdtak en de regels van de werkboom. De rubriek scoort beide. Pass vereist een werkboom >= main voor elk scenario. Regressie blokkeert het amendement totdat de formulering is vastgesteld. De ratel is niet optioneel voor voor de hand liggende wijzigingen: ze kunnen nog steeds subtiele regressies veroorzaken, en de evaluatie is het enige mechanisme dat ze vangt voordat ze landen.

**De retroactieve sweep.** Een amendement legt de regel voor nieuwe code onmiddellijk vast: de diff-scope van `/audit` betekent dat nieuw werk aan de nieuwe lat voldoet vanaf het moment dat het amendement binnenkomt. Reeds bestaande code die de nieuwe regel schendt, wordt afgehandeld door een afzonderlijke sweep PR die in de wachtrij staat via `/rollout`. De fixsite hoeft niet elk bestaand exemplaar inline te repareren. Dat zou wijzigingen onbetaalbaar maken. In plaats daarvan: nieuwe code voldoet meteen aan de nieuwe lat, oude code staat in de uitrolwachtrij en de sweep PR heeft zijn eigen bewijs dat reeds bestaande exemplaren zijn opgelost.

De vier geldige triggers voor '/constitute' zijn: een bug, een incident, een autopsie en een nieuwe contractuele standaard. Voorstellen in de vorm van "we zouden waarschijnlijk..." zonder een van de vier triggers worden afgewezen en in plaats daarvan doorgestuurd naar `/reflect`.

Stap 6 - Hoe we het ontvouwen

De Portable Methodology Kit (`EDD - Portable Methodology Kit.md`) is een op zichzelf staand document dat u aan elke AI-agent kunt overhandigen met de instructie om `/begin` uit te voeren. De agent inspecteert de opslagplaats, voert een ontdekkingspas uit, bevestigt de gedetecteerde waarden samen met u in één enkele tabel, vraagt ​​alleen wat Discovery niet kan beantwoorden, en zendt de minimaal haalbare basis voor uw project uit. Eén sessie om de volledige EDD-infrastructuur op te zetten.

Hoe je het ontvouwt, hangt volledig af van of je nieuw begint of het in een bestaande codebase brengt. De twee paden zijn verschillend genoeg om afzonderlijk te behandelen.

**Greenfield.** Zet bij een nieuw project vanaf de eerste dag elke regel die je maar kunt bedenken in de grondwet. Je hebt geen bestaande code die je moet controleren, geen teampraktijken die je moet beschermen, geen bestaande PR’s naar grootvader. De kosten van striktheid zijn op de eerste dag vrijwel nul. Voeg alle harde beperkingen, alle auditdimensies en alle padgerichte regels toe. Voer vervolgens de lus uit. Wat je snel zult ontdekken, is waar de grondwet voor wrijving zorgt: bouw tijden die ballon omdat elke verandering een volledige audit teweegbrengt, testsuites die traag zijn omdat de dekkingsbalk te hoog is ingesteld voor de huidige complexiteit, symbolische budgetten die krap zijn omdat het canonieke lichaam te uitgebreid is. Dag één striktheid brengt deze problemen bij de ontwikkeling aan het licht, niet bij de productie. Dan optimaliseer je: verscherp de bouwpoorten, pas de dekkingsregels aan, trim het constitutionele orgaan tot het minimum. Je stabiliseert alles in één keer, zonder dat klanten worden getroffen en geen team wordt verstoord. De kosten op de korte termijn zijn een iets langzamere eerste sprint. De langetermijnwinst is een constitutie die vanaf de eerste commit aan een stresstest is onderworpen.

**Brownfield.** Een bestaande codebase heeft een bestaand team, bestaande praktijken en bestaande PR's die EDD niet volgden. De ontplooiing is hier stapsgewijs en moet additief zijn en niet ontwrichtend. Het doel van de eerste maand is niet om elke eerdere beslissing terug te draaien; het is om te beginnen met het genereren van het onderpand dat EDD betrouwbaar maakt: één auditdimensie die iets reëel vastlegt, één harde beperking die een beoordeling automatiseert die het team al handmatig deed, één wijzigingscyclus van begin tot eind. Gebruik de bestaande kwaliteitssignalen van het team als grondstof. Als het team al een lintregel voor beveiliging heeft, voeg dan `[HC-SECURITY-LINT]` toe en wijs deze naar de bestaande poort. Er verandert niets voor ontwikkelaars, maar nu weerspiegelt het grondwettelijke record wat de poort feitelijk afdwingt.

De hoofdregel in brownfield is: win bondgenoten voordat je argumenten wint. Dring in de eerste week niet aan op een volledige grondwet die elk gebied van de codebase raakt. Begin met de dimensie waar het team al het meest om geeft: meestal beveiliging of betrouwbaarheid. Laten zien dat het wijzigingsproces een echte kloof dicht die ze eerder hebben gezien. Laat de ratel vanaf daar compounderen. Een team dat EDD een echte bug heeft zien ontdekken die door hun bestaande proces is geglipt, zal ruimte maken voor de volgende regel. Een team dat EDD tegenkomt als een document dat hen vertelt dat ze alles verkeerd hebben gedaan, zal er omheen gaan.

**Wat het ontsluit.** De reden om de ontplooiing door te voeren, of het nu greenfield of brownfield is, is niet het grondwetsdocument. Het is wat de grondwet mogelijk maakt zodra het verificatiemechanisme draait.

De kwaliteit van de productiecode en de leveringssnelheid komen samen op een manier die echt contra-intuïtief is als je het nog niet hebt gezien. Ingenieurs stoppen met het wisselen van context om regressies te debuggen die de lus zou hebben opgevangen. Beoordelingscycli worden korter omdat PR’s bewijs bevatten in plaats van uitleg. De audit wordt automatisch uitgevoerd en markeert de problemen die door de meest ervaren reviewer zouden zijn opgemerkt, waardoor die reviewer zich kan concentreren op de architectonische beslissingen die daadwerkelijk hun oordeel vereisen.

Het duidelijkste bewijs hiervan: een nieuwe ingenieur die zich bij het team voegt, met volledige toegang tot de grondwet, de featurespecificaties en de loop, kan binnen 48 uur na de eerste dag een featurebijdrage van productiekwaliteit leveren die in de main wordt ingecheckt. Geen speelgoedwissel. Geen documentatie-update. Een echt kenmerk, met bewijsmateriaal, dat de volledige audit doorstaat. Het is geen toevalstreffer en het is geen bijzonder ongebruikelijke ingenieur. De vangrails maken het voor elke bekwame ontwikkelaar mogelijk om vanaf dag één te werken volgens de kwaliteitsnorm van het team, omdat de kwaliteitsnorm automatisch wordt opgeschreven, verifieerbaar en gehandhaafd, in plaats van als institutionele kennis te worden meegedragen in de hoofden van degene die er het langst mee bezig is.

Dat is de vorm die het bereikt: een team waar de AI het verificatiewerk doet, de vangrails de foutklassen opvangen die anders door de codebeoordeling zouden glippen, en de ingenieurs hun denktijd besteden aan de problemen die feitelijk technisch inzicht vereisen.

Dit is op verschillende schaalniveaus geverifieerd: eerst bij soloprojecten, daarna bij middelgrote teams en vervolgens bij organisaties op ondernemingsniveau. De mechanica houdt stand bij alle drie. De kosten voor het ontvouwen zijn anders (een solo-ontwikkelaar kan vereistenregisters en vijandige beoordelingen door verschillende leveranciers overslaan; een ondernemingsteam heeft ze nodig). Het tempo van de wijzigingen is anders (bij een soloproject kan het weken duren tussen '/constitute'-aanroepen; een ondernemingsteam met meerdere bijdragende agenten voert ze wekelijks uit). Maar de kernlus, de ratel en de bewijsvereiste gedragen zich op dezelfde manier, ongeacht de teamgrootte. De kwaliteitsvloer gaat alleen maar omhoog, en het verificatieapparaat houdt dat zo, zonder afhankelijk te zijn van degene die die week de meest ervaren recensent in de zaal is.

AI-haken

De grondwet regelt het gedrag van agenten via geladen context. Hooks handhaaft het op het moment van actie, voordat het werk al gedaan is en er al een PR openstaat. Zonder haken wordt een overtreding betrapt bij beoordeling: de agent heeft de code al geschreven, de PR bestaat, en het repareren ervan betekent dat het werk opnieuw moet worden gedaan. Bij hooks gebeurt de onderschepping vóór elke toetsaanslag.

**Zowel Claude Code als GitHub Copilot voeren een hook uit bij prompt submission.** Wanneer er een nieuwe taak arriveert, wordt de hook geactiveerd voordat de agent iets doet. Zijn taak: controleren of de taak niet triviaal is, en vervolgens de takenlijst herbedraden in de `/wow`-lus - de 10-staps EDD-reeks die de agent moet volgen voordat hij iets verzendt.

Een agent die stap 5 bereikt zonder de stappen 1-4 te voltooien, heeft de lus geschonden. De hook bepaalt de volgorde bij het begin van de sessie, en niet achteraf.

**Claude Code** vuurt bovendien een pre-tool-call hook af vóór het schrijven van bestanden, terminalopdrachten of git-bewerkingen. Er kan niet worden geprobeerd een commit uit te voeren als niet aan de lusstappen is voldaan.

**GitHub Copilot** vuurt bovendien een PR-creatiehook af. Voordat de PR-beschrijving definitief is, voert de hook '/audit' uit in de zelfbeoordelingsmodus, waarbij dimensieschendingen, ontbrekend bewijsmateriaal en lege testplannen worden opgemerkt voordat een menselijke recensent het concept ooit ziet. Wat de recensent bereikt, is al vooraf gescreend.

**Codex en andere agenten** hebben op het moment van schrijven geen native hook-oppervlak. De fallback is een CI-watcher-bot die direct na het aanmaken commentaar geeft op PR's en overtredingen signaleert. Het is een backstop, geen poort aan de eerste oppervlakte - het werk is al gedaan tegen de tijd dat het vuurt, dus het verhindert niet dat de haken worden geëlimineerd.

Bij een project met actieve hooks worden overtredingen tijdens de sessie inline gecorrigeerd. De agent vangt het gat op, produceert het bewijsmateriaal en neemt het vanaf het begin op. Bekijk de tijddalingen. Nabewerking verdwijnt. De constitutie gaat van een document dat de agent leest naar een beperking waarbinnen de agent in realtime opereert.

Bijlage - De volledige grondwet

Wat volgt is de daadwerkelijke `CONSTITUTION.md` van dit project - een volledig autonoom, door AI ondersteund ontwikkelproject met één ontwikkelaar. Het regelt elke niet-triviale wijziging die in deze codebase wordt aangebracht. Dit is geen sjabloon of illustratie. Dit is het livedocument dat door elke agent bij elke sessie wordt geladen.