Architectuurbesluiten
Belangrijke technische keuzes worden vastgelegd als architecture decision record — een kort document per besluit. Er zijn er op dit moment drieëndertig, waarvan twee nog een voorstel zijn.
Het sjabloon
Elk besluit volgt dezelfde opbouw:
- Context — welk probleem lag er, en waarom nu?
- Besluit — wat is gekozen?
- Alternatieven — wat is overwogen en waarom afgevallen?
- Nadelen — wat kost deze keuze ons?
- Open vragen — wat is bewust nog niet beslist?
- Wanneer heroverwegen — welke omstandigheid maakt dit besluit achterhaald?
Punten 3 tot 6 zijn het waardevolst. Een besluit zonder opgeschreven nadelen is meestal geen besluit maar een voorkeur, en zonder herzieningscriterium blijft een keuze hangen lang nadat de aanleiding is verdwenen.
Een besluit geldt pas als vastgesteld wanneer er werkend bewijs is — niet wanneer het document af is.
Besluiten die het platform vormgeven
| Onderwerp | Kern van het besluit |
|---|---|
| Configureerbare prompts | Prompts staan in configuratie, met een variant per tenant — niet in code |
| AI-gateway | Alle generatie via één serverside toegangspunt, met promptresolutie, modelkeuze en bewaking |
| Zoekfundament | Herbouw van het ophalen van bewijs: opknippen, betekenisindex en een begrensde selectie |
| Bewijsketen | Verwijzingen worden serverside gecontroleerd tegen wat het model daadwerkelijk kreeg |
| Onderbouwde synthese | Ook de zware analyses krijgen dossierbewijs mee, niet alleen simpele extracties |
| Tenantmodel | Datamodel en rechtenmatrix voor meerdere organisaties op één platform |
| Latency en time-outs | Streamen, achtergrondtaken en modelkeuze per taakzwaarte |
| Rapportage-engine | Blokgebaseerd documentmodel, uitsluitend additief op bestaande werkbladen |
| Vermogensmodel | De verbindende laag tussen strategie en veranderportfolio |
| Uitleverstraat | Staging-eerst, met geautomatiseerde poorten voor migraties en schemagelijkheid |
| Teststrategie | Welke test welk risico afdekt, en wanneer een test verplicht wordt |
| Beveiligingspoort | Auditlogboek, back-ups en een aantoonbaar geteste herstelprocedure |
| Bewijs op de rij | Het bewijs achter een gegenereerde tekst wordt opgeslagen bij de tekst zelf, niet in een apart logboek |
| Herkomstmodel | Elke AI-generatie draagt haar herkomst: bron, aard, bronnen, redeneerstap en of een mens eraan heeft geschreven; de server beslist of er materiaal was, niet het model |
| Anon-oppervlak | Wie niet is ingelogd leest niets, behalve wat uitdrukkelijk en gemotiveerd is vrijgegeven |
| Rapportmodel | Drie documenten per werkblad — weergave, samenvatting, bevindingen — waarbij de samenvatting niet uit de bevindingen put en een rapport een momentopname is |
| Herkomst bij accepteren | Het herkomstteken verdwijnt zodra een mens het voorstel accepteert; genereren op algemene kennis mag overal |
| Risicomodel | De goedkeurknop van de consultant is de controle; zware waarborgen horen alleen op de grens naar de klant |
| Tijdregels voor generaties | Een afgebroken generatie geldt als mislukt, er volgt geen tweede volle poging, en het plafond volgt uit de tijdband |
| Werkintake | Een bouwer opent geen issue meer; hij meldt, en de orchestrator bepaalt waar het heen gaat |
| Processen en organisatie | Keten, proces en handeling hebben elk één betekenis; een proces heeft een afdeling als eigenaar, KPI's hebben één vorm, en een issue gaat over een proces, een overdracht of een keten |
| Waardeteams | Een waardeteam voert roadmapopgaven uit en kan over meerdere ketens werken, met per initiatief een expliciete afspraak |
Twee onderwerpen liggen als voorstel voor en zijn nog niet besloten: één gedeelde testomgeving of een omgeving per tak, en de tweede factor bij inloggen.
:::note Toegang tot de volledige besluiten De uitgeschreven besluitdocumenten bevatten implementatiedetails en interne afwegingen en zijn daarom niet publiek. Ze zijn beschikbaar voor technische partners onder geheimhouding. :::