FestivalOS, Executive Summary

Status: Concept Datum: 7 juli 2026

Waar het om gaat

High Energy Events zet elk jaar twee festivals neer: Kingdance en Dance4Liberation, elk 35.000 bezoekers, negen dagen na elkaar op dezelfde locatie, met één productie die tussendoor blijft staan. Achter die twee festivaldagen zit een miljoenenoperatie die in een paar maanden wordt opgebouwd en daarna weer wordt afgebroken, gedragen door een compacte vaste kern en een schil van externe partijen.

De kennis die dat elk jaar mogelijk maakt, leeft overal en nergens: taken in Asana, tickets bij Paylogic, campagnes in Brevo, de begroting in spreadsheets, afspraken in mailboxen en WhatsApp-groepen, en het belangrijkste deel in de hoofden van een handvol sleutelfiguren. Valt één van hen uit, dan verdwijnt kennis die nergens is vastgelegd, midden in het duurste kwartaal van het jaar. En elke editie begint het geheugen deels opnieuw: fouten van vorig jaar sluipen terug, en besluiten worden genomen zonder dat helder is waarom een eerdere keuze anders uitviel.

FestivalOS lost dat op. Het is het centrale besturingssysteem waarin alles samenkomt: documenten, taken, besluiten, budgetten, contracten, leveranciers, planning, marketing en kennis. En het is AI-native. AI is er geen los hulpje maar een vaste, meedenkende laag die voorbereidt, analyseert, bewaakt, waarschuwt en onthoudt. De mens houdt de regie en neemt de beslissingen.

Het uitgangspunt in één zin: AI prepares, humans decide.

Waarom nu

Twee ontwikkelingen komen samen. De festivalwereld is professioneler, duurder en risicovoller geworden, met strengere eisen op veiligheid, vergunningen en financiën. Tegelijk is AI volwassen genoeg om niet alleen tekst te genereren, maar om context te begrijpen, verbanden te leggen en betrouwbaar mee te werken binnen duidelijke grenzen. De organisaties die dat als eerste goed inrichten, bouwen een voorsprong die moeilijk in te halen is, omdat hun systeem elk jaar slimmer wordt terwijl dat van de concurrent elk jaar opnieuw begint.

De eerste toepassing, Kingdance en Dance4Liberation 2027

Beide festivals staan op dezelfde locatie, negen dagen na elkaar. De productie wordt grotendeels één keer opgebouwd voor Kingdance en blijft staan voor Dance4Liberation. Dat maakt ze de ideale eerste casus, want het dwingt FestivalOS meteen tot het onderscheid dat het platform onderscheidend maakt: wat is gedeeld, wat is festivalspecifiek, hoe verdeel je kosten eerlijk, waar zit inkoop- en onderhandelingsvoordeel, en welke nieuwe risico's ontstaan doordat een compleet terrein negen dagen blijft staan.

Wat FestivalOS is, en wat niet

FestivalOS is geen dashboard, geen chatbot en geen projectmanagementtool. Het is het besturingssysteem waarbinnen die dingen samenkomen en betekenis krijgen. Concreet functioneert het als digitale directiekamer, centrale kennisbank, AI Festival Brain, workflow engine, risicobewaker, productiemanager, finance controller, leverancierscoördinator en strategisch geheugen in één samenhangend geheel.

De kern van de aanpak

1. Eén waarheid. Alles komt terug op één plek. Geen twaalf versies van hetzelfde budget.
2. Kennis verdwijnt nooit. Niet alleen wat er gebeurde, maar vooral waarom een keuze is gemaakt.
3. Alles is verbonden. Een artiest hangt aan een contract, rider, hotel, transport, podium, timetable, campagne en budget. FestivalOS begrijpt die relaties.
4. Vertrouwen voor automatisering. We automatiseren pas als het rust en controle oplevert, nooit andersom.
5. Veiligheid vanaf dag één. Rollen, rechten, logging en AVG zitten in het fundament, niet als bijlage. Een signing-freelancer kan het AI-brein niet naar gages of aandeelhoudersbesluiten vragen.

Wat dit oplevert

Voor de directie: overzicht en grip, met dagelijkse briefings, openstaande besluiten en risico's in beeld. Voor de productie: minder losse eindjes en herbruikbare draaiboeken. Voor de commercie: scherpere forecasts op tickets en sponsoring. Voor de organisatie als geheel: een geheugen dat blijft, ook als mensen wisselen. En op termijn een platform dat verder gaat dan de eigen festivals.

De weg ernaartoe

We bouwen in fasen. Fase 0 is dit fundament: de constitutie, het manifest, de bijbels en de moduleoverzichten. Daarna het kernplatform, de kennisbank, het command center, de workflow engine, de productie-modules en pas dan de zwaardere AI-agents en commerciële modules. Elke fase moet op zichzelf waarde leveren voor de editie 2027. We bouwen geen mooi document dat nooit de tent in gaat.

Vastgestelde kaders (7 juli 2026)

• FestivalOS wordt een slimme regie- en kennislaag bovenop bestaande tools, die we de komende jaren steeds meer in eigen beheer brengen. Geen big-bang eigen software.
• Voorlopig alleen voor High Energy Events, gebouwd rond één festivalproductie, met een datamodel dat latere uitbreiding niet in de weg zit.
• De meetlat voor 2027: meer overzicht voor de directie, efficiënter werken, snellere besluitvorming, kostenefficiëntie met een streven van 15 procent besparing op het totale productiekostenhuis van €4,5 miljoen, meer automatiseringen, meer regie en minder afhankelijkheid, en zichtbare innovatie in de organisatie.
• Kerngebruikers zijn directie en managers, met externe partners op eigen access levels.
• De eerste module die we bouwen is het Executive Command Center, met een lichte kennis- en workflowbasis eronder zodat het overzicht echt gevuld is.

Terug naar de inhoud

FestivalOS Constitution

De niet-onderhandelbare principes van FestivalOS. Deze grondwet gaat boven elke module, elk dashboard en elke automatisering. Wie iets bouwt of beslist binnen FestivalOS, doet dat binnen deze kaders. Wijzigen kan alleen bewust, gedocumenteerd en met akkoord van de eigenaar.

Status: Concept Datum: 7 juli 2026

---

Artikel 1, Doel

FestivalOS bestaat om een festivalorganisatie rustiger, scherper en betrouwbaarder te laten werken. Het brengt alle informatie, beslissingen en kennis samen op één plek, en zet AI in als vaste meedenkende laag. Het doel is nooit meer techniek om de techniek, maar meer grip, minder fouten en een organisatie die elk jaar slimmer wordt.

Artikel 2, De rolverdeling tussen mens en AI

Het leidende principe is: AI prepares, humans decide. AI mag signaleren, verzamelen, samenvatten, analyseren, voorspellen, adviseren en, binnen strikte grenzen, uitvoeren. De mens blijft altijd eindverantwoordelijk voor besluiten met gevolgen. AI vervangt geen mensen en geen creativiteit. Het neemt werk weg dat mensen uitput, zodat zij hun aandacht houden voor oordeel, relaties en richting.

Artikel 3, De mens beslist over wat ertoe doet

Voor een vaste categorie beslissingen is menselijk akkoord altijd verplicht, ongeacht hoe zeker de AI is. Dit betreft in elk geval: grote budgetten en uitgaven, artiestencontracten en gages, vergunningen, alles wat met veiligheid te maken heeft, juridische documenten, sponsorcontracten, prijsstrategie, crisiscommunicatie, aandeelhoudersbesluiten, de definitieve line-up en grote leveranciersdeals. AI mag deze voorbereiden, nooit afronden.

Is het besluit eenmaal genomen, dan draait de rolverdeling om: de AI mag de uitvoering overnemen uit naam van de beslisser. Het besluit verwerken, de bijbehorende communicatie opstellen en versturen in de tone-of-voice van de betreffende persoon, taken uitzetten, systemen bijwerken. De handtekening blijft menselijk, het handwerk niet. Daarbij gelden drie grenzen: de uitvoering blijft binnen wat er besloten is, elke handeling uit naam van een persoon wordt gelogd en is voor die persoon terug te lezen, en zodra de werkelijkheid afwijkt van het besluit gaat het terug naar de beslisser in plaats van dat de AI zelf bijstuurt.

Artikel 4, Eén waarheid

Er is één bron van waarheid. Documenten, taken, besluiten, budgetten en afspraken bestaan één keer, op een vindbare plek, met een herkenbare status. Kopieën en losse versies zijn geen waarheid maar risico. Wat niet in FestivalOS staat, telt organisatorisch niet.

Artikel 5, Kennis verdwijnt nooit

FestivalOS onthoudt niet alleen wat er is gebeurd, maar vooral waarom. Bij elke betekenisvolle keuze horen de context, de afweging en de verantwoordelijke. Kennis is geen bijproduct maar een bezit van de organisatie, dat blijft ook als mensen vertrekken en dat elke editie verder wordt opgebouwd.

Artikel 6, Alles is verbonden

FestivalOS begrijpt relaties, niet losse bestanden. Een artiest hangt aan een contract, een rider, een hotel, transport, een podium, een timetable, een campagne en een budget. Een leverancier aan een offerte, een contract, een factuur, een evaluatie en een risico. Een besluit aan een meeting, een verantwoordelijke, een taak, een deadline en een gevolg. Wie één ding aanpast, moet kunnen zien wat er meebeweegt.

Artikel 7, Data is eigendom van de organisatie

Alle data in FestivalOS is eigendom van de festivalorganisatie, niet van een leverancier, een tool of een individu. De organisatie kan haar data altijd inzien, exporteren en verwijderen. Afhankelijkheid van een systeem mag nooit betekenen dat je je eigen geschiedenis kwijt bent.

Artikel 8, Transparantie en uitlegbaarheid

Elk advies, elke waarschuwing en elke actie van de AI is herleidbaar. FestivalOS laat zien waarop een uitspraak is gebaseerd, welke bronnen zijn gebruikt en hoe zeker het systeem is. Een aanbeveling zonder onderbouwing wordt niet gegeven. De gebruiker kan altijd doorvragen tot de bron.

Artikel 9, Vertrouwen gaat voor automatisering

Automatiseren mag alleen als het leidt tot meer controle, meer rust en minder fouten. Snelheid of gemak is nooit op zichzelf reden om een menselijke stap over te slaan. Bij twijfel kiest FestivalOS voor voorbereiden en voorleggen, niet voor zelfstandig handelen.

Artikel 10, Veiligheid en privacy zitten in het fundament

Bescherming van data is geen laag die je later toevoegt. Rollen, rechten, logging, versleuteling, bewaartermijnen en AVG-principes zitten vanaf het begin in de architectuur. Iedereen ziet en kan alleen wat bij zijn rol hoort. De AI antwoordt altijd binnen de rechten van de gebruiker die de vraag stelt. Een freelancer voor signing krijgt geen inzage in gages, contracten of aandeelhoudersbesluiten, ook niet via een omweg.

Artikel 11, Verantwoordelijkheid is altijd toewijsbaar

Elke taak, elk besluit en elk risico heeft een eigenaar. FestivalOS laat nooit in het midden wie waarover gaat. De AI kan voorbereiden en herinneren, maar draagt geen verantwoordelijkheid. Die ligt altijd bij een benoemd mens.

Artikel 12, Besluitvorming volgt een vast ritme

Beslissingen doorlopen een herkenbaar patroon: waarnemen, begrijpen, analyseren, voorspellen, adviseren, goedkeuren, uitvoeren, evalueren, leren. AI ondersteunt de vroege stappen, de mens bewaakt de goedkeuring, en de organisatie legt de uitkomst vast zodat de volgende keer slimmer verloopt.

Artikel 13, Schaalbaarheid en soberheid

FestivalOS is een platform, geen project. Wat we bouwen moet werken voor meer festivals en meer edities, zonder telkens opnieuw te beginnen. Tegelijk voegen we niets toe dat geen echte waarde levert. Complexiteit is de vijand. Elke functie verdient haar bestaan door de organisatie rustiger te maken, niet drukker.

Artikel 14, Ethiek en menselijke maat

FestivalOS dient de mensen die het festival maken en bezoeken. Het monitort werk, niet mensen. Data over crew, vrijwilligers en bezoekers wordt met respect en spaarzaam gebruikt, alleen voor het doel waarvoor ze is verzameld. AI wordt nooit ingezet om mensen te misleiden, te manipuleren of onder druk te zetten, niet intern en niet naar de markt.

Artikel 15, Samenwerking als uitgangspunt

De verhouding tussen mens en AI is die van collega's met verschillende sterktes. De AI is snel, onvermoeibaar en heeft een perfect geheugen. De mens heeft oordeel, verantwoordelijkheid, smaak en relaties. FestivalOS is geslaagd wanneer die twee elkaar versterken en het samen beter gaat dan alleen.

Terug naar de inhoud

FestivalOS Manifesto

Status: Concept Datum: 7 juli 2026

Elk jaar verliest de organisatie een deel van haar geheugen

Een groot festival organiseren is een van de meest complexe dingen die er zijn. In een paar maanden zet je een complete operatie neer: tientallen leveranciers, honderden crewleden, artiesten, vergunningen, budgetten, veiligheidsplannen en een marketingmachine die tienduizenden kaarten moet verkopen. Dan draait het één dag op volle kracht. En daarna breek je alles weer af.

Het probleem is niet dat mensen het niet kunnen. Het probleem is waar de kennis woont. Die zit in spreadsheets die niemand meer helemaal begrijpt, in mailboxen van mensen die misschien volgend jaar weg zijn, in WhatsApp-groepen die na afloop leeglopen, in losse tools die niet met elkaar praten, en in de hoofden van een handvol sleutelfiguren. Elke editie begint het geheugen deels opnieuw. Dezelfde fouten sluipen terug. Dezelfde discussies worden opnieuw gevoerd. En als er één iemand uitvalt, valt er een gat dat niemand snel vult.

Losse tools zijn niet genoeg meer

Spreadsheets zijn krachtig, maar ze weten niets van elkaar. Een projecttool houdt taken bij, maar begrijpt niet dat een taak vasthangt aan een contract, een budget en een risico. Een mailbox bewaart afspraken, maar kan ze niet terugvinden op het moment dat het ertoe doet. En al die losse systemen samen vormen geen organisatie. Ze vormen een verzameling eilanden waar mensen de hele dag bruggetjes tussen bouwen. Dat kost tijd, het kost rust, en het kost fouten.

De festivalwereld is de afgelopen jaren professioneler, duurder en risicovoller geworden. Strengere eisen op veiligheid en vergunningen, hogere kosten, kleinere marges, en een publiek dat gewend is aan perfectie. In die realiteit is losjes georganiseerd geen optie meer. Je hebt een systeem nodig dat de complexiteit voor je draagt in plaats van andersom.

AI verandert wat een systeem kan zijn

Tot voor kort was software passief. Het bewaarde wat jij invulde en toonde wat jij opvroeg. AI verandert dat fundamenteel. Een systeem kan nu meedenken. Het kan een vergadering samenvatten en er de besluiten en actiepunten uithalen. Het kan een contract lezen en signaleren dat een rider iets belooft dat niet in de begroting staat. Het kan zien dat de ticketverkoop achterloopt op vorig jaar en waarschuwen voordat het een probleem is. Het kan onthouden waarom je drie jaar geleden voor een bepaalde leverancier koos en dat naar boven halen precies wanneer je die keuze opnieuw maakt.

Dat is geen chatbot in een hoekje. Dat is een nieuwe manier van werken, waarin het systeem zelf een collega wordt.

AI is een hybride collega, geen knop

Wij zien AI in FestivalOS niet als een tool die je aanzet, maar als een vaste medewerker met een bijzonder profiel. Onvermoeibaar, snel, met een perfect geheugen en zonder ego. Wat die collega niet heeft, is verantwoordelijkheid, smaak en het laatste woord. Dat blijft bij mensen. Daarom is de grondregel simpel en hard: AI prepares, humans decide. De AI legt het werk klaar, brengt de opties in beeld, waarschuwt op tijd en houdt het overzicht. De mens weegt, kiest en tekent.

Die grens is geen beperking. Het is juist wat vertrouwen mogelijk maakt. Omdat je weet dat de AI nooit ongevraagd een groot besluit neemt, durf je hem veel meer werk te geven. En hoe meer werk hij goed doet, hoe meer rust er ontstaat aan de mensenkant.

Kennis is het echte kapitaal

Een festivalmerk is waardevol. Maar het stille kapitaal van een festivalorganisatie is haar kennis. Wie welke leverancier vertrouwt en waarom. Hoe een crowd zich gedraagt bij een bepaald weertype. Welke marketingfase vorig jaar wel en niet werkte. Waarom een podium daar staat en niet vijftig meter verderop. Die kennis is nu fragiel, want ze woont in mensen en in losse documenten. Zodra je ze centraal vastlegt, met de reden erbij, wordt ze een bezit dat blijft groeien.

Daarom draait FestivalOS niet om opslaan, maar om verbinden en onthouden. Niet alleen wat, maar waarom. Elke editie maakt het systeem slimmer, en daarmee de organisatie.

De toekomst van festivalorganisatie

Wij geloven dat de festivals die de komende jaren winnen, niet per se de festivals met het grootste budget zijn, maar de festivals met het beste geheugen en de scherpste voorbereiding. Organisaties waar niets tussen wal en schip valt, waar de directie op elk moment weet waar het staat, waar kennis zich opstapelt in plaats van weglekt, en waar mensen hun energie kwijt kunnen aan creativiteit en beleving in plaats van aan het najagen van losse eindjes.

FestivalOS is de infrastructuur onder die manier van werken. We beginnen bij Kingdance en Dance4Liberation, twee festivals op één terrein, omdat juist die combinatie ons dwingt scherp te zijn op wat gedeeld is en wat eigen. Maar wat we bouwen is groter dan twee festivals. Het is een besturingssysteem voor hoe evenementen in dit tijdperk georganiseerd horen te worden.

Build once. Learn forever.

Terug naar de inhoud

FestivalOS Design Principles

De 25 leidende principes voor alles wat we in FestivalOS ontwerpen en bouwen. De constitutie zegt wat onwrikbaar is. Deze principes zeggen hoe we werken en kiezen. Bij elke twijfel over een ontwerp of functie leggen we het naast deze lijst.

Status: Concept Datum: 7 juli 2026

Filosofie en fundament

1. AI prepares, humans decide. De AI legt werk klaar en adviseert. De mens weegt en beslist. Deze grens is de kern van het systeem, niet een uitzondering.

2. Rust is de belangrijkste feature. Een festivalorganisatie is al complex genoeg. FestivalOS is geslaagd als mensen zich rustiger voelen, niet drukker. Elke toevoeging moet die rust vergroten.

3. Elke functie verdient haar bestaan. We voegen niets toe dat geen echte last wegneemt. Bij twijfel laten we het weg. Complexiteit is de vijand.

4. Waarde per fase, niet pas aan het eind. Elk onderdeel dat we bouwen moet op zichzelf al bruikbaar zijn voor de eerstvolgende editie. We bouwen geen fundament dat pas over drie jaar iets oplevert.

5. Een platform, geen project. Wat we maken werkt voor meer festivals en meer edities. We ontwerpen voor herbruikbaarheid, niet voor één keer.

Mens en AI

6. De mens beslist over wat ertoe doet. Grote budgetten, contracten, veiligheid, vergunningen, line-up en crisiscommunicatie krijgen altijd menselijk akkoord, hoe zeker de AI ook is.

7. Advies zonder onderbouwing bestaat niet. Elke aanbeveling toont haar bronnen en een inschatting van zekerheid. De gebruiker kan altijd doorvragen tot de bron.

8. De AI kent zijn grenzen en toont ze. Bij onzekerheid zegt het systeem dat, in plaats van te gokken. Een eerlijk ik-weet-het-niet is meer waard dan een overtuigend fout antwoord.

9. Escaleren is een deugd, geen falen. Als iets buiten de bevoegdheid of zekerheid van de AI valt, gaat het naar een mens. Doorschuiven op het juiste moment is gewenst gedrag.

10. De AI dient de rol van de gebruiker. Antwoorden en acties blijven binnen de rechten van wie de vraag stelt. Geen omweg geeft toegang tot wat je rol niet mag zien.

Data en kennis

11. Eén waarheid. Elk gegeven bestaat één keer, op een vindbare plek, met een duidelijke status. Kopieën zijn risico, geen back-up.

12. Onthoud het waarom, niet alleen het wat. Bij elke betekenisvolle keuze horen context, afweging en eigenaar. Zonder waarom is een besluit alleen een feit zonder betekenis.

13. Alles is verbonden. We modelleren relaties, niet losse bestanden. Wie iets aanpast, ziet wat meebeweegt.

14. Data is van de organisatie. Altijd inzichtelijk, exporteerbaar en verwijderbaar. Geen enkel systeem mag de organisatie van haar eigen geschiedenis afsnijden.

15. Leg vast bij de bron. Kennis wordt vastgelegd op het moment dat ze ontstaat, in de meeting, de mail, het contract, niet achteraf gereconstrueerd.

UX en interactie

16. Snel scanbaar boven volledig. Een scherm moet in seconden vertellen wat aandacht vraagt. Diepte zit een klik verder, niet allemaal tegelijk in beeld.

17. Toon eerst wat vandaag telt. Elk overzicht opent met de vraag: wat vraagt nu aandacht. Status, risico en openstaande besluiten vóór alle rest.

18. AI is aanwezig, niet opdringerig. Aanbevelingen zijn zichtbaar maar nooit in de weg. Het systeem duwt niet, het biedt aan.

19. Status is altijd zichtbaar. Bij elk document, besluit en taak zie je direct waar het staat. Geen twijfel of iets af, in behandeling of vastgesteld is.

20. Rustig, krachtig, premium. De toon is die van Apple, Linear en Notion, vertaald naar de festivalwereld. Kalm, helder, zonder ruis, zonder opsmuk.

21. Mobiel is geen bijzaak. Op het terrein werkt iedereen op de telefoon. Wat op de bouwplaats moet werken, ontwerpen we mobile-first. Het command center mag desktop-eerst zijn.

Werking en operations

22. Twee merken, één productie. FestivalOS maakt op elk vlak het onderscheid tussen wat Kingdance en Dance4Liberation delen en wat eigen is. Gedeelde infrastructuur, aparte identiteit.

23. Verantwoordelijkheid is altijd toewijsbaar. Elke taak, elk besluit en elk risico heeft een benoemde eigenaar. FestivalOS laat nooit in het midden wie waarover gaat.

24. Vertrouwen voor automatisering. We automatiseren pas als het rust en controle oplevert. Gemak alleen is nooit genoeg reden om een menselijke stap over te slaan.

Bouw

25. Security by design, vanaf regel één. Rollen, rechten, logging, versleuteling en AVG zitten in het fundament, niet in een latere sprint. Wat je later moet toevoegen, had er vanaf het begin in gemoeten.

Terug naar de inhoud

FestivalOS Module Overview

Overzicht van alle modules waaruit FestivalOS bestaat, geordend in vier lagen. Dit is de kaart. De uitgewerkte bouwdocumenten per module (doel, rollen, use cases, functionele eisen, UX-flow, data-objecten, AI-functionaliteit, integraties, security, acceptatiecriteria, MVP en bouwinstructie) komen in Deel D.

Status: Concept Datum: 7 juli 2026

De vier lagen:

• Fundamentlaag, waarop alles draait
• Intelligentielaag, het brein en de agents
• Operationele laag, waar het festival gemaakt wordt
• Commerciële laag, waar geld en waarde binnenkomen

---

Fundamentlaag

1. FestivalOS Core Het fundament. Gebruikers, rollen, rechten, navigatie, basisdatabase, audit logging en de multi-festival- en multi-editie-structuur. Alles wat elke andere module nodig heeft.

2. Executive Command Center De digitale directiekamer voor directie, aandeelhouders en verantwoordelijken. Status per festival, gedeelde productie, openstaande besluiten, risico's, budget, cashflow, deadlines, dagelijkse briefing en het weekly board report. Met het blok "wat vraagt vandaag aandacht".

3. Knowledge OS Het georganiseerde geheugen. Documenten, meetings, besluiten, learnings, evaluaties en de knowledge graph. De plek waar kennis niet alleen wordt bewaard maar verbonden.

4. Security & Permissions De beschermlaag. Rolgebaseerde toegang, dataclassificatie, audit logs, versleuteling, rechten per rol, per project en per festival, plus logging van AI-vragen en -antwoorden. Zorgt dat iedereen alleen ziet wat bij zijn rol hoort.

5. UX/UI Design System De gedeelde ontwerptaal. Cards, tabellen, timelines, modals, formulieren, grafieken, statuslabels, alerts, mobiel en desktop, licht en donker. Zodat elke module hetzelfde aanvoelt.

---

Intelligentielaag

6. AI Festival Brain Het centrale brein. Leert van meetings, transcripties, mails, agenda's, notities, taken, draaiboeken, contracten, begrotingen, marketingplannen, evaluaties en ticketdata. Functioneert als strategisch en operationeel geheugen, kritische sparringpartner, besluitvoorbereider, risicosignaleerder en kennisbank. Begrijpt relaties, niet losse bestanden.

7. AI Intelligence Layer, de agents Gespecialiseerde agents die elk een domein bedienen: Executive, Production, Marketing, Commercial, Finance, Artist, Vendor, Safety, Legal, Crew, Knowledge, Risk, Decision en Reporting. Per agent leggen we doel, toegestane en verboden acties, databronnen, output, zekerheidsscore, escalatiemomenten en verplichte menselijke goedkeuring vast.

8. Workflow Engine De motor onder taken en processen. Taken, deadlines, eigenaren, goedkeuringen, automatiseringen en statusflows. Zorgt dat werk stroomt en dat niets tussen wal en schip valt.

---

Operationele laag

9. Production OS Alles op het terrein. Podia, licht, geluid, LED, aggregaten, hekken, toiletten, lockers, entree, scanners, bars, backstage, opbouw en afbouw. Het hart van de gedeelde productie tussen Kingdance en Dance4Liberation.

10. Artist OS Boekingen, contracten, riders, hotels, transport, hospitality, timetables, backstage en artiestendossiers. Met alle relaties die aan een artiest hangen zichtbaar op één plek.

11. Safety & Permits OS Vergunningen en veiligheid. Gemeente, politie, brandweer, GHOR, veiligheidsplan, calamiteitenplan, crowd management, geluidsnormen, verzekeringen en compliance. Inclusief de extra risico's van een terrein dat negen dagen blijft staan.

12. Vendor OS Leveranciers. Database, offertes, contracten, SLA's, onderhandelingen, transportbundeling en evaluaties. De plek waar inkoop- en onderhandelingsvoordeel van twee festivals samenkomt.

13. Crew OS Mensen aan de operationele kant. Crewplanning, vrijwilligers, beveiliging, barpersoneel, runners, hosts, accreditatie, briefings en shiftplanning, gedeeld waar het kan.

---

Commerciële laag

14. Marketing OS De marketingmachine, per festival gescheiden in merk en tone of voice. Marketingkalender, contentplanning, social, campagnes, AI content studio, creators, e-mail, advertenties, doelgroepsegmentatie en analytics.

15. Ticketing & Revenue Engine Ticketfases, prijsstrategie, forecasts, conversie, upsells, lockers, parking, VIP, combitickets en revenue-dashboards. Apart per festival, met inzicht in het geheel.

16. Sponsor & Partnership CRM Sponsorleads, proposities, partnerdecks, contracten, activaties, deliverables en rapportages. Aparte proposities per festival, gedeelde pijplijn waar logisch.

17. Finance OS Het financiële hart. Begrotingen, gedeelde en afzonderlijke kosten, cashflow, forecasts, facturen, scenario's, winst en verlies en break-even. Met de kostenverdeling tussen beide festivals als vast onderdeel.

---

Opmerking bij de nummering

De prompt noemde zestien modules. In dit overzicht staan er zeventien, omdat we de AI Intelligence Layer (de agents) en het AI Festival Brain (het geheugen en begrip) als twee aparte modules behandelen. Ze horen bij elkaar, maar zijn functioneel verschillend genoeg om apart te bouwen en te bewaken. Dit is een voorstel, geen vaststelling. Zie de open vragen.

Terug naar de inhoud

FestivalOS, UX/UI Bible en Cockpit-bouwplan

Het complete plan voor hoe FestivalOS eruitziet, aanvoelt en wordt opgebouwd: van dashboard-pagina naar het operating system waarin de hele festivalorganisatie draait. Geschreven na de fundamentele feedback van Ruben (9 juli 2026): professioneler, grootser, alles komt hier samen.

Status: Concept, richtinggevend voor alle bouw Datum: 9 juli 2026 Referentieniveau: A Mi Manera command-center 2.0-designtaal en het IPA Command Center, maar breder en dieper: dit wordt het systeem waar de organisatie in zit, niet naar kijkt.

---

1. Het kernidee: van dashboard naar besturingssysteem

Het huidige prototype is één pagina die status toont. Dat is het verschil tussen een rapport en een werkplek. FestivalOS wordt een werkplek: elke rol logt in, landt in zijn eigen cockpit, en doet daar zijn werk. Kijken, beslissen, toewijzen, bespreken, vastleggen. De AI zit er als vaste laag doorheen: bereidt voor, signaleert, vat samen, onthoudt.

De toekomst (het einddoel): de hele festivalorganisatie zit en draait in FestivalOS. Elke workflow, elk besluit, elke taak, elk document, elk inzicht. Hybride: AI en mensen werken er samen, met de mens aan het stuur. Wat we nu bouwen is de basis die dat einddoel aankan, zonder dat we alles in één keer bouwen.

2. Informatie-architectuur: het huis

FestivalOS krijgt een vaste structuur met drie soorten ruimtes:

A. De Directiekamer (Mission Control), voor John en Maarten. Het hart. Organisatiebreed overzicht: wat vraagt aandacht, openstaande besluiten, budget en cashflow, tickets, risico's, voortgang per afdeling, de AI-briefing. Dit is de ruimte die het huidige prototype probeerde te zijn, maar dan als startpunt van een groter huis in plaats van het hele huis.

B. Afdelingscockpits, één per afdeling uit het organogram:

1. Projectleiding (Maarten): voortgang, tijdlijnen, deadlines, projectvergaderingen, evaluatie, begroting.
2. Site Productie (Bram, Steven): terrein, vergunningen, site-leveranciers, veiligheid, omgeving, opbouw en afbouw.
3. Personeel en Processen (Bram, Henrieke): personeel, systemen, crew catering, food en activatie.
4. Technische Productie (John): techniek-leveranciers, podium design, show creatie, tekenwerk.
5. Artiesten (Marc): programma, boekingen, contracten en riders, advancing, hospitality.
6. Marketing en Communicatie (Rik, inclusief ticketing): campagnes, content, kalender, ticketverkoop, partijen.

Elke cockpit heeft dezelfde opbouw (herkenbaarheid): bovenaan de afdelingsstatus en wat er nu speelt, daaronder de werkgebieden van die afdeling, rechts de AI-copiloot met context van die afdeling.

C. Horizontale lagen, die door alle afdelingen heen snijden:

• Besluiten: de besluitenstroom van de hele organisatie, wie moet wat beslissen, wat is de context, wat was de uitkomst. Het geheugen van de organisatie.
• Taken en workflows: alles wat loopt, per afdeling, per eigenaar, per deadline (gevoed door Asana zolang dat de bron is).
• Finance: begroting, realisatie, cashflow, kostenverdeling KD/D4L, besparingsmonitor richting 15 procent. Eigenaar Maarten, inzicht John.
• Planning: de mastertijdlijn richting 27 april en 5 mei, met de opbouw- en afbraakvensters en de negen dagen ertussen.
• Leveranciers: alle partijen, contracten, offertes, evaluaties.
• Kennis en Brein: documenten, meetingverslagen, learnings, en straks het AI Festival Brain als vraagbaak.

3. Navigatiemodel

• Vaste zijbalk met de drie soorten ruimtes: Directiekamer bovenaan, dan de zes afdelingen, dan de horizontale lagen. Altijd zichtbaar waar je bent.
• Topbalk: festival-context (Kingdance, Dance4Liberation, Gedeeld), zoeken/command palette (Cmd+K), de ingelogde rol.
• AI-copiloot als paneel dat overal beschikbaar is (rechts), met de context van de plek waar je bent. In de Directiekamer praat hij over de organisatie, in Artiesten over het programma.
• Rolgebaseerde landing: John landt in de Directiekamer, Rik in Marketing, een externe partij in zijn eigen opdrachtenlijst. Je eigen cockpit is je thuis.

4. Design-DNA

Wat Ruben heeft goedgekeurd als AMM command-center 2.0-designtaal is de lat: premium, kalm, anti-slop, custom. FestivalOS krijgt daarbinnen een eigen identiteit:

• Licht, ruimtelijk, volwassen. Lichte achtergrond als default, veel wit, sterke typografische hiërarchie. Dit is enterprise-grade software voor een directiekamer, geen festivalposter.
• Eén krachtige accentkleur plus functionele statuskleuren (op koers, let op, kritiek). Het festivalgevoel zit in precisie en energie van de interactie, niet in confetti.
• Beweging met betekenis: subtiele entree-animaties, tellers die oplopen, statussen die verschuiven. Dynamisch maar zeer overzichtelijk (Rubens design-voorkeur), altijd met reduced-motion-respect.
• Vaste componentenfamilie: mission cards (KPI met context en bron), decision cards, risk cards, tijdlijnen, tabellen, kanban waar logisch, voortgangsbalken, statuslabels, AI-blokken die herkenbaar zijn als AI (aanwezig, niet opdringerig).
• Bron-badge overal: elk cijfer toont waar het vandaan komt. Dit is een merkonderdeel van FestivalOS, het maakt vertrouwen zichtbaar.
• Desktop-first voor de cockpits, mobiel volwaardig leesbaar. Op het terrein straks mobile-first modules, maar de directiekamer is een desktopervaring.

5. Hybride werken: hoe AI en mensen hier samenwerken

Elk object in het systeem (taak, besluit, risico, budgetpost) heeft twee kanten:

• De menselijke kant: een eigenaar, een deadline, een status.
• De AI-kant: wat de AI ermee doet: voorbereiden, signaleren, samenvatten, vooruitkijken.

Het werkritme dat FestivalOS draagt:

• Daily briefing per rol: wat speelt er vandaag in mijn wereld.
• Decision queue: besluiten wachten niet in mailboxen maar staan in de rij, met context, tot een mens ze neemt.
• Weekly board report: automatisch concept, mens keurt.
• Signalen: de AI bewaakt afwijkingen (verkoop, budget, deadlines, stilgevallen taken) en meldt op de juiste plek.
• Vastleggen bij de bron: elk besluit krijgt zijn waarom mee, elk overleg zijn verslag, en dat voedt het Brein.

6. Technische basis (de groei aankunnen)

• Van statisch naar echte datalaag. Het prototype is statisch. De basis wordt: Cloudflare Pages + Functions, met D1 (database) voor de objecten en KV waar snelheid telt. Zelfde stack-familie als IPA, bewezen werkwijze.
• Auth via Cloudflare Access: de ingelogde identiteit (e-mail uit de Access-header) bepaalt rol en scope, server-side afgedwongen, niet alleen in de interface.
• API-laag ertussen: de cockpits praten met een eigen API, de API praat met de bronnen (Asana, Paylogic, begroting). Zo kunnen we bronnen vervangen zonder de cockpits te raken, precies de eigen-beheer-strategie.
• Alles behoudt het bron-blok uit de Data Bible.

7. Bouwfasen (elk blok is af en bruikbaar voordat het volgende start)

Fase 1, Het huis en de Directiekamer (nu). De shell: zijbalk, topbalk, rolgebaseerde landing, design system. De Directiekamer volledig op niveau. De zes afdelingscockpits als ingerichte ruimtes met status en werkgebieden (nog handmatige data). Dit is wat John en Maarten als eerste zien.

Fase 2, Werken in het systeem. Besluiten-laag en taken-laag echt werkend: aanmaken, toewijzen, afronden, met de Asana-koppeling als bron. De decision queue wordt het eerste dagelijkse gebruik.

Fase 3, Cijfers live. Paylogic-tickets live, begroting gekoppeld, besparingsmonitor actief. De Directiekamer toont vanaf hier echte cijfers.

Fase 4, Kennis en Brein. Documenten, meetingverslagen en besluitgeschiedenis doorzoekbaar; de AI-copiloot krijgt geheugen en wordt vraagbaak.

Fase 5, Verdieping per afdeling. Artist OS (contracten, riders, advancing), Vendor OS (offertes, evaluaties, onderhandelvoordeel KD+D4L), productieplanning, crew. In volgorde van waar de organisatie het hardst om vraagt.

Fase 6, Automatiseringen. Terugschrijven naar bronnen, workflows die zichzelf aanzwengelen, rapportages die zichzelf klaarzetten. Altijd binnen: AI prepares, humans decide.

Terug naar de inhoud

FestivalOS Data Bible

Het datamodel onder FestivalOS. Dit document beschrijft de objecten, hun velden en hun relaties. Het begint klein en concreet, bij precies wat het Command Center nodig heeft, en groeit daarna mee met de modules. Dit maakt de bouwinstructie van het Command Center definitief.

Status: Concept Datum: 7 juli 2026 Scope nu: de kernobjecten plus de werkset van het Command Center. De rest staat als groeipad.

---

Uitgangspunten

Vier principes uit de constitutie sturen dit model:

1. Eén waarheid. Elk object bestaat één keer. Verwijzen mag, kopiëren niet.
2. Alles is verbonden. We modelleren relaties, niet losse tabellen. Het geheel vormt een knowledge graph.
3. Alles is herleidbaar. Elk gegeven weet waar het vandaan komt. Daarvoor is het bron-blok verplicht (zie hieronder).
4. Toegang zit in de data. Elk object hangt aan een afdeling en, waar relevant, aan een festival. Daarmee kan het rechtenmodel uit 20 altijd bepalen wie wat mag zien.

De slimme laag, hoe externe tools passen

FestivalOS is een laag bovenop bestaande tools. Daarom draagt elk object dat uit een extern systeem komt een bron-blok:

bron: {
  systeem: "asana" | "paylogic" | "fanalists" | "brevo" | "spreadsheet" | "festivalos",
  externId: "…",          // het id in het bronsysteem
  laatstGesynct: datum,
  url: "…"                // directe link naar de bron, voor herleidbaarheid
}

Zo kan het Command Center bij elke waarde tonen waar die vandaan komt, en kunnen we later per object beslissen of we het in eigen beheer nemen of gekoppeld laten.

---

Kernobjecten (fundament)

Organization

De organisatie. Nu één: High Energy Events.

Veld	Type	Toelichting
id	id
naam	tekst	High Energy Events
festivals	relatie	heeft meerdere Festivals

Festival

Een festivalmerk. Nu twee: Kingdance en Dance4Liberation.

Veld	Type	Toelichting
id	id
naam	tekst
organizationId	relatie	hoort bij één Organization
edities	relatie	heeft meerdere Editions

Edition

Eén jaargang van een festival, bijvoorbeeld Kingdance 2027.

Veld	Type	Toelichting
id	id
festivalId	relatie
jaar	getal	2027
datum	datum	27 april of 5 mei
locatie	tekst	Wijthmenerplas, Zwolle
capaciteit	getal	circa 35.000
status	label	in voorbereiding, live, geëvalueerd

Department

Een afdeling uit het organogram.

Veld	Type	Toelichting
id	id
naam	tekst	Programmering, Marketing, enz.
hoofdUserId	relatie	het afdelingshoofd
organizationId	relatie

User

Een persoon met toegang. Intern of extern.

Veld	Type	Toelichting
id	id
naam	tekst
email	tekst
type	label	intern of extern
roleId	relatie	zie Role
departmentIds	relatie	een of meer afdelingen

Role

De rechtenlaag, volgens de zes niveaus uit 20.

Veld	Type	Toelichting
id	id
naam	label	directie, afdelingshoofd, gatekeeper, intern medewerker, externe partij, ai-laag
scope	regels	wat deze rol mag zien en doen, per afdeling en festival

AuditLog

Onveranderbaar logboek van betekenisvolle acties.

Veld	Type	Toelichting
id	id
userId	relatie	wie
actie	tekst	wat
objectType, objectId	relatie	waarop
tijdstip	datum	wanneer

AIInteraction

Log van elke vraag aan en elk antwoord van de AI, verplicht vanuit de constitutie.

Veld	Type	Toelichting
id	id
userId	relatie	wie vroeg
vraag	tekst
antwoord	tekst
gebruikteBronnen	relatie	welke objecten of documenten
zekerheid	getal	zekerheidsscore
tijdstip	datum

---

Werkset van het Command Center

Dit zijn de objecten die het Command Center toont. Elk draagt een bron-blok en hangt aan een afdeling en, waar relevant, aan een editie.

Task

Een taak. Komt in eerste instantie uit Asana.

Veld	Type	Toelichting
id	id
titel	tekst
eigenaarUserId	relatie	verantwoordelijke
departmentId	relatie
editionId	relatie	optioneel
deadline	datum
status	label	open, bezig, klaar, geblokkeerd
bron	bron-blok	meestal asana

Decision

Een besluit dat genomen moet of is worden. Het hart van "snellere besluitvorming".

Veld	Type	Toelichting
id	id
titel	tekst	waar gaat het over
context	tekst	het waarom, de afweging
beslisserUserId	relatie	wie moet beslissen
status	label	open, in behandeling, genomen
openSinds	datum	om te signaleren wat te lang wacht
gevolg	relatie	gekoppelde taken of budgetposten
categorie	label	markeert of menselijk akkoord verplicht is (budget, contract, veiligheid, enz.)

Risk

Een risico.

Veld	Type	Toelichting
id	id
titel	tekst
impact	label	laag, midden, hoog
waarschijnlijkheid	label	laag, midden, hoog
eigenaarUserId	relatie
status	label	actief, beheerst, gesloten
editionId	relatie	of gedeeld tussen beide festivals

Budget en BudgetLine

De begroting, opgebouwd uit posten. Draagt de besparingsdoelstelling van 15 procent.

Veld	Type	Toelichting
id	id
editionId of gedeeld	relatie	per festival of gedeeld tussen beide
BudgetLine.categorie	tekst	bijvoorbeeld techniek, artiesten, marketing
BudgetLine.begroot	bedrag
BudgetLine.werkelijk	bedrag
BudgetLine.gedeeld	ja of nee	of de post gedeeld is tussen Kingdance en Dance4Liberation
BudgetLine.verdeelsleutel	regel	hoe een gedeelde post wordt verdeeld (nog te bevestigen door Ruben)
BudgetLine.besparing	bedrag	verschil dat meetelt voor de 15 procent

TicketPhase

Een verkoopfase. Komt uit Paylogic of Fanalists.

Veld	Type	Toelichting
id	id
editionId	relatie
naam	tekst	early bird, fase 1, enz.
prijs	bedrag
aantalBeschikbaar	getal
aantalVerkocht	getal
doel	getal	verkoopdoel voor deze fase
bron	bron-blok	paylogic of fanalists

---

Relaties, de knowledge graph in het klein

De belangrijkste verbindingen die het Command Center al gebruikt:

• Organization heeft Festivals, Festival heeft Editions.
• Department heeft een hoofd (User) en hangt aan de Organization.
• User heeft een Role en hoort bij een of meer Departments.
• Task, Decision, Risk en TicketPhase hangen aan een Department en meestal aan een Edition.
• Decision hangt aan gevolgen: Tasks en BudgetLines. Zo wordt zichtbaar wat een besluit in beweging zet.
• BudgetLine kan gedeeld zijn tussen twee Editions, met een verdeelsleutel. Dit is de plek waar de gedeelde productie financieel samenkomt.
• AIInteraction verwijst naar de objecten die als bron zijn gebruikt.

Dit is bewust de kleine versie. Naarmate modules erbij komen, groeit de graph met de objecten hieronder.

---

Groeipad, objecten voor latere modules

Deze staan al in de architectuur, maar bouwen we pas als de betreffende module aan de beurt is:

• Artist OS: Artist, Contract, Rider, Hospitality, Transport, TimetableSlot
• Vendor OS: Supplier, Quote, Invoice, SLA, Evaluation
• Marketing OS: Campaign, ContentItem, Channel
• Sponsor CRM: Sponsor, Proposal, Activation, Deliverable
• Knowledge OS: Document, Meeting, Transcript, Learning
• Safety en Permits OS: Permit, SafetyPlan, Incident
• Crew OS: CrewMember, Shift, Accreditation
• AI-laag: AIRecommendation

Elk van deze krijgt zijn velden in de betreffende module-blueprint, zodat we niet nu alles hoeven te bevriezen.

---

Wat dit betekent voor de bouw van het Command Center

Met dit model kan de bouwinstructie definitief worden:

1. Begin met de kernobjecten (Organization, Festival, Edition, Department, User, Role) en de werkset (Task, Decision, Risk, Budget, TicketPhase), plus AuditLog en AIInteraction.
2. Elk object krijgt het bron-blok, zodat herleidbaarheid en de latere overgang naar eigen beheer vanaf het begin ingebouwd zijn.
3. Toegang wordt afgedwongen op Department- en Festival-niveau, volgens Role.
4. Start met een kleine handmatige of half-geautomatiseerde dataset, met één live koppeling (ticketdata) als bewijs van het principe.

---

Open punten

• De verdeelsleutel voor gedeelde BudgetLines tussen Kingdance en Dance4Liberation.
• De precieze veldnamen en statuslabels stemmen we af op wat Asana, Paylogic en Fanalists teruggeven, zodat de koppeling soepel loopt.

Terug naar de inhoud

FestivalOS, Integratie-architectuur en randvoorwaarden

Hoe FestivalOS omgaat met de vele losse tools, hoe kennis afdelingsbreed wordt in plaats van persoonsgebonden, hoe het systeem leert, en de randvoorwaarden op kosten, snelheid en veiligheid. Geschreven naar aanleiding van Rubens vragen op 9 juli 2026.

Status: Concept, richtinggevend Datum: 9 juli 2026

---

1. Het hub-model: FestivalOS als centrum, tools als satellieten

De organisatie draait op losse tools: Asana (taken), Brevo (mail), Fanalists (dataprofielen), Paylogic (tickets, via Absolutely Fresh), Wix (site), en meer. Het antwoord is niet die tools morgen vervangen, maar een vaste architectuur:

• FestivalOS is de hub. Elke tool krijgt een connector. Data stroomt naar het canonieke datamodel (Data Bible), altijd met het bron-blok: systeem, extern id, laatst gesynct, link.
• Twee richtingen, gefaseerd. Eerst lezen (tool naar FestivalOS, veilig, geen risico). Daarna schrijven (FestivalOS naar tool, bijvoorbeeld een campagne klaarzetten in Brevo), altijd met menselijke goedkeuring: trust before automation.
• De cockpit wacht nooit op een externe API. Syncs draaien op de achtergrond (webhooks waar de tool het kan, anders geplande syncs via Workers). Het dashboard leest altijd de eigen database en is daardoor altijd snel, met een zichtbare laatst-bijgewerkt-stempel.
• Vervangen komt later. Pas als een eigen module aantoonbaar beter is dan de tool, verhuist die functie naar binnen. De connector-architectuur maakt dat mogelijk zonder verbouwing: de bron wisselt, de cockpit merkt niets.

Eerste actie die hieruit volgt: de integratie-inventaris. Per tool vastleggen: welke data, welke API en hoe goed die is, wie de accounteigenaar is, wat het kost, hoe we eruit kunnen (export). Zonder deze kaart bouwen we blind.

2. Afdelingsbreed denken: alles hangt aan objecten, niet aan personen

Rubens instinct klopt: een campagne is van een team (strateeg, designer, advertentieontwikkelaar, marketeer), niet van één persoon. Daarom is de regel:

• Werk hangt aan objecten. Een Campaign, een Artist, een Stage, een Permit. Mensen hebben rollen óp dat object.
• Communicatie hangt aan het object. Overleg over de campagne staat bij de campagne, niet in iemands mailbox of appgroep. Wie erbij komt, leest de hele geschiedenis terug.
• AI-bevindingen landen op het object en de afdeling. Als de AI in Brevo-data ziet dat een mailflow onderpresteert, komt die bevinding bij de campagne én in de marketingcockpit, zichtbaar voor het hele team, niet als privéantwoord aan wie toevallig vroeg.

Dit is het verschil tussen een AI-assistent (persoonlijk, vluchtig) en een AI-laag in het systeem (gedeeld, blijvend).

3. Zelflerend, maar dan concreet

Zelflerend is geen magie, het is een keten die we bewust inrichten:

1. Alles wat er gebeurt is een event. Elke wijziging, elke MCP-vraag, elk AI-antwoord wordt gelogd (AuditLog en AIInteraction uit de Data Bible). Ook wat via ieders eigen Claude binnenkomt is dus op het platform terug te lezen.
2. Learnings zijn objecten. Een fout, een observatie of een inzicht wordt vastgelegd als Learning, gekoppeld aan de context (campagne, leverancier, editie).
3. Evaluatiemomenten zijn proces. Na elke campagne, elke fase en elke editie vat de AI samen wat werkte en wat niet, en legt dat vast.
4. Het Brein zoekt over alles heen. Geen model-training nodig: het Brein indexeert de eigen geschiedenis en haalt die op precies het juiste moment terug ("vorig jaar viel fase 2 ook stil, toen hielp X").

Zo wordt het systeem elke editie slimmer, zonder dat we afhankelijk zijn van experimentele techniek.

4. Kosten, eerlijk beeld

• Infrastructuur (Cloudflare Pages, Workers, D1, KV, R2): verwaarloosbaar. Ook bij flinke groei praat je over tientjes per maand.
• AI-verbruik is de echte kostenpost, in twee smaken. (a) Persoonlijke AI-werkplekken: ieders eigen Claude-abonnement, per persoon per maand, vergelijkbaar met wat Ruben nu heeft. (b) Het systeem-brein: API-kosten voor briefings, signalen, samenvattingen en het Brein. Beheersbaar door routinewerk op kleine modellen te draaien, zwaar denkwerk op grote, en door briefings één keer per dag voor te rekenen in plaats van steeds live. Verwachting: tientallen tot enkele honderden euro's per maand bij volwaardig gebruik, meegroeiend met wat het oplevert.
• De besparingskant telt mee. Elke tool die later overbodig wordt en elk uur zoekwerk dat verdwijnt is de businesscase; de 15 procent kostendoelstelling is het kader.

5. Snelheid

• Eigen database als enige bron voor de cockpits: laden is altijd direct, ongeacht hoe traag een externe API is.
• Cloudflare edge: snel op kantoor, thuis en op het terrein, ook mobiel.
• AI-werk dat voorspelbaar is (daily briefing, weekrapport) wordt vooraf berekend, niet live.

6. Veiligheid en risico's waar nog niet over gesproken was

1. AVG en Fanalists. Dataprofielen van bezoekers zijn persoonsgegevens. FestivalOS haalt géén kopie van alle profielen binnen, alleen aggregaten en segmenten (dataminimalisatie). Verwerkersovereenkomsten per tool controleren.

2. Secrets centraal. Alle API-sleutels van tools leven in Cloudflare secrets, nooit los op laptops of in documenten. Eén plek, één beheerder, intrekbaar. 2b. Eigen accounts, altijd (besluit Ruben, 10 juli 2026). Alles van FestivalOS (koppelingen, API-tokens, accounts, deploys, domeinen) loopt via HEE-eigen accounts: het HEE Cloudflare-account, de GitHub-organisatie High-Energy-Events en HEE-identiteiten (highenergyevents.nl). Nooit via privé- of andere zakelijke accounts van betrokkenen (rijssenbeek.info, IPA en dergelijke). Vóór elke nieuwe koppeling is de eerste check: staat dit op naam van HEE? Zo wordt de latere eigendomsoverdracht aan HEE nooit gehinderd door verweven toegang of eigenaarschap.

3. MCP per persoon, nooit gedeeld. Iedere gebruiker (en ieders Claude) werkt onder eigen identiteit; rechten worden server-side afgedwongen; alles wordt gelogd. Een gedeeld account is verboden, anders klopt het zelflerende beeld ook niet meer.

4. FestivalOS wordt zelf kritieke infrastructuur. Hoe belangrijker het wordt, hoe harder backups (dagelijkse D1-export), uitwijk en een showdag-plan nodig zijn: op de festivaldag zelf mag een storing nooit de operatie raken (read-only modus, offline export van draaiboeken).
5. AI-misleiding (prompt injection). Data die uit externe bronnen binnenkomt kan instructies bevatten die een AI op het verkeerde been zetten. Daarom: de AI schrijft nooit autonoom naar buiten, en acties boven een drempel vragen altijd menselijk akkoord. Staat al in de constitutie, wordt hier hard technisch afgedwongen.
6. Exit per tool. Voordat we op een tool bouwen, checken we of de data eruit kan. Geen afhankelijkheid zonder uitgang.
7. Offboarding. Mensen en partijen vertrekken. Toegang intrekken (Access, GitHub, tools) wordt een checklist, geen geheugenwerk.

7. Het grootste risico is niet technisch: adoptie

Als het team naast het systeem blijft werken (mail, WhatsApp, losse lijstjes), sterft de ene waarheid vanzelf. Daarom:

• Per afdeling één werkstroom volledig verhuizen, niet alles half. Beginnen bij Marketing: daar zitten de meeste tools (Brevo, Fanalists, Paylogic via AF), meerdere mensen rond één campagne, én Ruben zelf als gatekeeper.
• De pilot: één echte campagne volledig in FestivalOS. Het campagne-object, het team erop, de communicatie erbij, de Brevo- en Fanalists-data eronder, de AI-bevindingen erop. Werkt dat, dan is het bewijs geleverd en rolt de rest uit met een voorbeeld in de hand.

Terug naar de inhoud

FestivalOS, Integratie-inventaris

De kaart van alle tools en systemen waar FestivalOS mee moet koppelen. Per tool: wat het doet, hoe koppelbaar het is, wie de accounteigenaar is en wat het kost. Dit document stuurt de volgorde en aanpak van alle connectors.

Status: In aanvulling (Ruben, Maarten, John vullen aan) Datum: 9 juli 2026 Legenda API-inschatting: Sterk = volwassen API, goed gedocumenteerd. Redelijk = API aanwezig, setup vraagt werk. Beperkt = maatwerk of exports nodig. Onbekend = uitzoeken.

---

Bevestigde tools (lijst Ruben, 9 juli 2026)

Tool	Domein	Wat erin zit	API-inschatting	Accounteigenaar	Kosten p/j
Asana	Hele organisatie	Alle taken van de complete organisatie	Sterk (REST plus webhooks). Ruben levert API-toegang z.s.m.	aan te vullen	aan te vullen
In2Event	Personeel en Processen	Eventplanning, crew, accreditatie	Redelijk (B2B API, toegang via accountmanager)	aan te vullen	aan te vullen
V-plan	Personeel en Processen	Personeelsplanning (uit organogram, te bevestigen)	Onbekend	aan te vullen	aan te vullen
Brevo	Marketing	Mailing, flows, contacten	Sterk (REST, webhooks, transactioneel)	aan te vullen	aan te vullen
Fanalists	Marketing	Dataprofielen en databeheer, werkt samen met Brevo	Beperkt (waarschijnlijk maatwerk of exports; afstemmen met Fanalists). Let op AVG: alleen aggregaten en segmenten naar FestivalOS	aan te vullen	aan te vullen
Paylogic	Marketing (ticketing)	Ticketverkoop, fases, kopers	Redelijk (API en reporting; toegang loopt via Absolutely Fresh, Onno)	Absolutely Fresh?	aan te vullen
Meta	Marketing	Organische posts plus Meta Ads (Facebook, Instagram)	Redelijk (Graph en Marketing API; app-review nodig)	aan te vullen	advertentiebudget
Google Ads	Marketing	Search, Display, YouTube Ads	Redelijk (Google Ads API; developer token en setup zwaar)	aan te vullen	advertentiebudget
TikTok Ads	Marketing	TikTok-advertenties	Redelijk (Marketing API)	aan te vullen	advertentiebudget
Snapchat Ads	Marketing	Snapchat-advertenties	Redelijk (Marketing API)	aan te vullen	advertentiebudget
Google Analytics (GA4)	Marketing	Websitegedrag en conversie	Sterk (Data API via serviceaccount; werkwijze bekend van IPA)	aan te vullen	gratis
Outlook 365	Hele organisatie	Mail en agenda's, meerdere organisaties (High Energy Events én Absolutely Fresh)	Sterk (Microsoft Graph), maar per organisatie-tenant apart toestemming regelen; AF is een externe partij, alleen met hun akkoord	HEE en AF apart	aan te vullen
Wix	Marketing	Websites Kingdance en D4L	Beperkt tot redelijk	aan te vullen	aan te vullen

Nog te inventariseren (uitvraag bij Maarten en John)

Verwachte categorieën waar nog tools achter zitten:

• Boekhouding en facturatie (John doet facturatie, bank en administratie: welk pakket?)
• Begroting (Maarten: spreadsheet of tool?)
• Plansystemen productie en techniek (tekenwerk, draaiboeken, stroomschema's)
• Personeelssystemen en uitzenders (ZZP, UZB, S&E via Lucky: welke systemen?)
• Vergunningen en veiligheid (dossiers gemeente, veiligheidsplannen)
• Contractbeheer (waar leven artiestencontracten en leveranciersovereenkomsten nu?)
• Horeca en muntensystemen (Food en activatie: welk kassasysteem?)
• Toegang en scanning (entree: welk scanplatform naast Paylogic?)

Toekomstmodules die uit deze inventaris volgen

1. Contracten en documentverwerking (organisatieniveau). Eén standaardproces voor alles wat getekend moet worden: artiestencontracten, leveranciersovereenkomsten, sponsorcontracten. In het dashboard: status per document (concept, verstuurd, getekend, afgerond), zodat altijd zichtbaar is welk papierwerk openstaat. Ondertekenen via een e-sign-dienst (DocuSign of Adobe Acrobat Sign, beide met volwassen API's). Documentbewerking via de Adobe PDF Services API: tekst eruit halen, aantekeningen maken, wijzigingen markeren. En de AI-laag checkt documenten standaard: klopt de gage met de begroting, wijkt een clausule af van onze standaard. Dit wordt een eigen module in Deel D.

2. Meeting-intelligentie (organisatiebreed). Een standaardvoorziening die iedereen in de organisatie kan gebruiken bij online meetings (Google Meet, Zoom, Teams), intern én met externe partijen. De meeting wordt vastgelegd, samengevat en verwerkt: samenvatting en besluiten naar de juiste afdeling in FestivalOS, actiepunten worden taken met eigenaren, en het Brein onthoudt wat besproken is. Technisch haalbaar via een meeting-bot-platform of de native API's van de vergaderplatformen; uitwerken als onderdeel van Fase 4 (Kennis en Brein), met privacy-afspraken (deelnemers weten dat het meedoet, externe partijen geven akkoord).

Terug naar de inhoud

FestivalOS, Organisatiestructuur en organogram

Hoe de organisatie in elkaar zit, wie waarover gaat, en hoe dat vertaalt naar rollen en toegang in FestivalOS. Dit document is de brug tussen de echte organisatie en het rechtenmodel van het systeem.

Status: Concept, gedeeltelijk (twee afdelingen ingevuld, rest te leveren) Bron: Organogram 2026 (High Energy Events) Datum: 7 juli 2026

---

Het model van de organisatie

De organisatie is opgebouwd in vier niveaus, precies zoals in het organogram:

1. Afdeling, het functionele blok (Artiesten, Marketing en Communicatie, en verder)
2. Hoofd, de verantwoordelijke voor de afdeling
3. Medewerkers of partijen, intern personeel of externe bureaus die aan de afdeling hangen
4. Taken, wat er concreet gebeurt

Twee dingen vallen op en sturen het ontwerp van FestivalOS:

• De kern is bewust slank. Veel werk wordt gedaan door externe partijen. Dat is een kracht, maar het maakt overzicht en kennisborging kwetsbaar, want kennis zit bij derden.
• Intern en extern lopen door elkaar. In één afdeling staan eigen mensen naast externe bureaus. FestivalOS moet die twee scherp uit elkaar houden qua toegang.

---

Afdeling: Artiesten

Hoofd boeker: Marc van Oosterbaan Taken: programmavoorstel (in samenwerking met Ruben), programma boeken.

Onder Artiesten:

• Assistent boeker: Kaylee Ticheloven (intern), taak: administratieve afwikkeling boekingsproces.
• Advancing: Just in Case (externe partij), taken: technische artist advancing (met Ruben), hospitality advancing (met Kaylee).

Rol van Ruben hier: medebeslisser op programma en technische advancing, bewaker van het concept.

---

Afdeling: Marketing en Communicatie

Strategie Gatekeeper: Ruben Rijssenbeek Taken: concepting, visie en positionering, merkconsistentie, campagnes, budgetten en externe samenwerkingen.

Hoofd marketing: Rik van de Merwe Taken: campagneplanning en coördinatie, budgetbeheer en ROI-monitoring, advertentie check-up en bewaking.

Onder Marketing:

• Marketeer: Anne Kardijk (intern), taken: contentplanning en publicatie, campagne-implementatie, social en e-mailmarketing, websiteontwikkeling en optimalisatie, brede operationele opvolging, ambassadeurs en influencers, bijhouden info-mail.
• Start Moovin (externe partij), taken: online ads en social media beheer, paid advertising (Meta, Google), performance monitoring, social media advertising strategie.
• Innercrowd (externe partij), taak: ambassadeursplatform (ticketverkoop, contentcreatie).
• Design en DTP: Frank Kuiper, taken: creatie visuals (online en offline), branding-uitingen, campagne-assets, DTP en doorvertaling concepten.
• Design en DTP: Designificance (externe partij), taken: opschaling bij piekdrukte, specialistische designklussen.
• Steroyd (externe partij), taken: trailer- en aftermovie-videoproductie, productie en montage, event-aftermovies.

---

De volledige organisatie (organogram YTD, juli 2026)

Op 9 juli 2026 leverde Ruben het actuele organogram "YTD Organisatie KD & D4L". Daarmee is de eerdere hypothese vervangen door de werkelijkheid. Zes afdelingen, met namen en taakverdeling. Afkortingen: "ism" is in samenwerking met, "MQ" is Maarten Quak.

Site Productie en Personeel/Processen (gedeeld hoofd)

Hoofd productie: Bram Kempen, staat boven zowel Site Productie als Personeel/Processen.

Site Productie:

• Site producent: Steven Boer. Taken: DWG tekenwerk, site leveranciers (offertes en planningen), vergunningen (omgevingsvergunning en evenementenvergunning), veiligheid (beveiliging, EHBO, overige diensten ism MQ), F&B uitvoer (materialen en praktische afstemming ism Tom Spijkerman), omgeving (contact buurt en ondernemers, ism MQ).
• Crewboss site: Robbin Mollink. Taken: uitvoer sitewerkzaamheden en CP TD show (aansturen team site).
• V&V Traffic Support (externe partij, verkeer).

Personeel/Processen:

• Proces manager: Henrieke Ebbekink. Taken: personeel (ZZP, UZB, S&E ism Lucky), systemen en processen (V-plan, In2Event, hotellerie, secretariaat, crew catering), food en activatie management show (contact, munten wegen).
• Facilitair medewerker: stagiair AF. Taak: ondersteuning procesmanager.

Projectleiding

• Projectleider: Maarten Quak. Taken: finance (begroting en afwikkeling), projectvergaderingen (kickoff, voortgang), voortgang (tijdlijn en deadlines), evaluatie (organiseren, inrichten).
• Onder projectleiding: hoofd veiligheid Toni Denneboom, entree manager show Tigo van Amerongen, hoofd horeca show Tom Spijkerman, hoofd finance Pay Systems ism Onno.

Technische Productie

• Projectleider hoofd techniek: John Althoff. Taken: techniek leveranciers (offertes), techniek leveranciers (planningen ism MQ), show creatie (showmomenten, tijdcodes).
• Partijen: podium design KAN Creations, technisch tekenwerk Timo van Hout, crewboss decor Laurent Geene.

Artiesten

Zoals eerder beschreven (Marc van Oosterbaan, Kaylee Ticheloven, Just in Case), met één toevoeging: Ruben staat er nu expliciet in als Strategie Gatekeeper met de taak sparringpartner programma en controle riders/contracten.

Marketing en Communicatie

Ongewijzigd ten opzichte van de eerdere beschrijving hierboven.

De directielaag (toelichting Ruben, 9 juli 2026, nieuwe opzet)

Boven de afdelingen staat een driehoek van drie mensen, elk met een eigen zwaartepunt:

• John Althoff, eigenaar. Moet overkoepelend alles kunnen inzien en overal iets van kunnen vinden, in alle workflows. Doet daarnaast de finance-uitvoering (facturatie, bank, administratie), maar is niet verantwoordelijk voor de begroting. Is tegelijk projectleider hoofd techniek.
• Maarten Quak, uitvoerend producent, in samenwerking met John. Maakt en bewaakt de begroting. Door Ruben bevestigd als een van de belangrijkste schakels in het festival.
• Ruben Rijssenbeek, strateeg en AI-lead. Stuurt marketing en programmering overkoepelend aan, met uitvoerende mensen daaronder. Trekt de FestivalOS-ontwikkeling. Naast de AI-directierol is Ruben ook strateeg en senior marketeer; dat zijn aparte rollen op één persoon.

Finance-bewaking gebeurt door Maarten in samenspraak met John (de directie), met aansturing en advies van AI. Precies het model van de constitutie: AI adviseert, de mens beslist.

Voor wie we bouwen. FestivalOS wordt gebouwd voor John als eigenaar van de festivals, en voor Maarten als uitvoerend producent. Zij moeten vanuit hun directiekamer alles veel inzichtelijker krijgen: workflows, besluitvorming, inzichten, taken, overzichten en automatiseringen, ingericht via en met AI. Ruben is de architect en AI-lead die het bouwt en vanuit zijn betrokkenheid en marketingkennis in de directie zit, maar hij is niet de primaire gebruiker. Elk ontwerpbesluit toetsen we dus eerst aan de vraag: worden John en Maarten hier beter van.

Ticketing valt onder marketing (Rik van de Merwe). De inrichting en uitvoering in Paylogic (de ticketprovider) ligt bij Onno of een collega binnen Absolutely Fresh (AF), een extern bureau. De verwijzingen "Pay Systems ism Onno" en "stagiair AF" in het organogram horen daarbij.

Gevolgen voor het rechtenmodel

Dit verfijnt de zes rolniveaus:

• John (eigenaar): volledige leestoegang over alles, inclusief finance. Het Command Center op directieniveau is primair voor hem.
• Maarten (uitvoerend producent): volledige toegang op productie, projectleiding en begroting; het budgetblok is van hem.
• Ruben (drie rollen op één persoon): AI-directierol (de AI-laag en FestivalOS zelf), strateeg (overkoepelend marketing en programmering) en senior marketeer (uitvoerend binnen marketing). Elk met een eigen scope, net als bij John.
• Absolutely Fresh (Onno): externe partij met scoped toegang op ticketing-inrichting, geen inzage in de rest.

Observaties voor FestivalOS

1. Maarten Quak is de spin in het web (begroting, voortgang, evaluatie, en "ism MQ" bij veiligheid, omgeving en techniekplanningen). FestivalOS moet zijn werk het eerst verlichten en zijn kennis het hardst borgen.
2. Sponsoring/commercie is nog niet belegd als afdeling. Open punt.
3. Veel rollen zijn showdag-specifiek (entree manager show, hoofd horeca show, food en activatie show). FestivalOS moet onderscheid maken tussen de voorbereidingsorganisatie en de showdag-organisatie.
4. John combineert eigenaar en hoofd techniek. In het rechtenmodel zijn dat twee rollen op één persoon; we modelleren rollen los van personen zodat dit netjes blijft.

---

Van organisatie naar toegang in FestivalOS

Uit deze structuur volgt direct het rechtenmodel. Zes rolniveaus, elk met een eigen scope.

Niveau	Wie	Wat ze zien	Wat ze mogen
Directie	Directie en aandeelhouders	Alles, over alle afdelingen en het financiële hart	Alles inzien, grote besluiten goedkeuren
Afdelingshoofd	Marc, Rik, en de andere hoofden	Hun hele afdeling plus wat gedeeld is	Beslissen binnen hun afdeling, taken toewijzen
Strategie/Gatekeeper	Ruben	Concept, merk, marketing en artiesten breed, plus overzicht	Bewaken, adviseren, goedkeuren op concept en merk
Intern medewerker	Kaylee, Anne, Frank	Hun eigen taken en de context die ze nodig hebben	Uitvoeren, bijwerken, aanleveren
Externe partij	Start Moovin, Innercrowd, Designificance, Steroyd, Just in Case	Alleen hun eigen taken, briefings en benodigde assets	Uitvoeren en aanleveren binnen hun opdracht
AI-laag	Het systeem zelf	Alleen wat de vragende gebruiker mag zien	Voorbereiden en adviseren binnen die rechten

Kernregels, in lijn met de constitutie:

• Een externe partij ziet nooit budgetten, gages, contracten of aandeelhoudersinformatie. Alleen de eigen opdracht en wat daarvoor nodig is.
• De AI antwoordt altijd binnen de rechten van de gebruiker die de vraag stelt. Geen omweg geeft toegang tot wat de rol niet mag zien.
• Elke taak en elk besluit heeft een benoemde eigenaar uit deze structuur.

Dit rolmodel wordt in detail uitgewerkt in de Security en Privacy Bible (14) en is een harde eis voor de eerste bouwfase, omdat directie, managers en externe partners vanaf dag één door elkaar heen werken.

Terug naar de inhoud

Module Blueprint, Executive Command Center

De eerste module die we bouwen. De digitale directiekamer van FestivalOS: één scherm waar directie en managers in seconden zien waar het festival staat, wat aandacht vraagt en welke besluiten open staan.

Status: Concept Datum: 7 juli 2026 Prioriteit: Fase 1, eerste bouw Gekoppeld aan succescriteria B2: overzicht, snellere besluitvorming, regie, kostenefficiëntie.

---

1. Doel

Het Command Center vervangt het rondbellen, het zoeken in mappen en het samenstellen van losse statusupdates. Het geeft de leiding op elk moment een eerlijk, actueel beeld van de organisatie, en het brengt de eerstvolgende beslissingen naar voren in plaats van ze te laten wachten tot een overleg. Het is de plek waar overzicht ontstaat en waar regie voelbaar wordt.

2. Doelgroep

Primair: John Althoff (eigenaar) en Maarten Quak (uitvoerend producent), de directiekamer. Zij moeten hier alles inzichtelijk krijgen: workflows, besluiten, taken, budget en voortgang. Secundair: de afdelingshoofden (Rik, Marc, Bram, Henrieke) binnen hun scope, en Ruben als strateeg en AI-lead. Externe partijen hebben hier geen toegang. Elk ontwerpbesluit toetsen we aan de vraag: worden John en Maarten hier beter van.

3. Gebruikersrollen en wat ze zien

• Directie: het volledige beeld, alle afdelingen, het financiële hart, alle openstaande besluiten.
• Afdelingshoofd: het eigen afdelingsblok volledig, plus de gedeelde onderdelen en de organisatiebrede status op hoofdlijnen.
• Strategie-gatekeeper (Ruben): concept, merk, marketing en artiesten breed, plus de organisatiebrede status.

Toegang volgt het rolmodel uit 20-Organisatiestructuur.md.

4. Belangrijkste use cases

1. Ik open 's ochtends het Command Center en zie in één blik wat vandaag aandacht vraagt.
2. Ik wil weten of we op koers liggen met de begroting en de ticketverkoop, zonder een rapport op te vragen.
3. Ik zie welke besluiten op mij of op een collega wachten, en hoe lang al.
4. Ik wil weten welke deadlines en risico's er deze week spelen.
5. Voor het directieoverleg genereer ik met één klik een weekrapport.
6. Ik volg de voortgang op de doelstelling van 15 procent kostenbesparing.

5. Functionele eisen

Het scherm is opgebouwd uit blokken (cards), van boven naar beneden op afnemende urgentie.

• Wat vraagt vandaag aandacht. Bovenaan. Een korte, door de AI samengestelde lijst van de belangrijkste punten van nu: naderende deadlines, achterblijvende KPI's, besluiten die te lang open staan, gesignaleerde risico's.
• Openstaande besluiten. Wie moet wat beslissen, sinds wanneer, en met welke context. Elk besluit is aanklikbaar naar de onderbouwing.
• Kritieke deadlines. Komende twee tot vier weken, met eigenaar en status.
• Risico's. Actieve risico's met inschatting van impact en waarschijnlijkheid, en de verantwoordelijke.
• Budget en cashflow. Stand versus begroting, en de voortgang op de 15 procent besparingsdoelstelling.
• Ticketstatus. Verkoop per fase versus doel en versus vorige editie.
• Afdelingsstatus. Per afdeling een beknopte voortgang: Artiesten, Marketing, en de rest zodra ingevuld.
• Daily briefing en weekly board report. De briefing is een korte tekstsamenvatting bovenaan. Het weekrapport is een genereerbaar document voor het directieoverleg.

Elk cijfer en elke bewering is herleidbaar naar de bron. Klikken op een KPI toont waar de data vandaan komt.

6. UX-flow

• Eén overzichtsscherm, desktop-eerst want dit is een directiekamer, met een leesbare mobiele versie voor onderweg.
• Rustig en scanbaar. Statuslabels in heldere kleuren (op koers, let op, kritiek). Geen ruis, geen overdaad aan grafieken.
• De AI-samenvatting bovenaan is aanwezig maar niet opdringerig, in lijn met principe 18.
• Doorklikken vanaf elk blok naar de details, zonder het overzicht te verliezen.

7. Data-objecten

Het Command Center toont data, het is niet de eigenaar ervan. Het leest uit: Decision, Task, Risk, Budget, TicketPhase, Meeting, Festival, Edition en Role. Deze objecten worden gedefinieerd in de Data Bible (13). Voor de eerste bouw houden we het datamodel bewust klein.

8. AI-functionaliteit

• Stelt het blok "wat vraagt vandaag aandacht" samen uit de onderliggende data.
• Schrijft de daily briefing en het concept-weekrapport.
• Signaleert afwijkingen: verkoop loopt achter, een besluit staat te lang open, een budgetpost wijkt af.
• Beantwoordt vragen over de status binnen de rechten van de gebruiker, met bronverwijzing.
• Bereidt voor, beslist nooit. Alles wat de AI voorstelt, wacht op een mens (principe 1 en 6).

9. Integraties (de slimme laag)

Dit is waar de keuze voor een laag bovenop bestaande tools concreet wordt. Het Command Center haalt data uit:

• Asana voor taken, deadlines en eigenaren.
• Paylogic en Fanalists voor ticketverkoop per fase.
• Brevo voor marketing- en e-mailprestaties.
• De begroting (nu waarschijnlijk een spreadsheet) voor budget en cashflow.

We beginnen met lezen, niet schrijven. Zodra dat vertrouwen geeft, kan het Command Center ook terugschrijven, bijvoorbeeld een besluit dat een taak in Asana aanmaakt.

10. Security-eisen

• Rolgebaseerde toegang vanaf dag één, volgens 20-Organisatiestructuur.md.
• Externe partijen hebben geen toegang tot het Command Center.
• Alle AI-vragen en -antwoorden worden gelogd.
• Financiële data alleen zichtbaar voor directie en de daartoe bevoegde hoofden.

11. Acceptatiecriteria

De module is klaar voor gebruik als:

• Een directielid in één scherm ziet wat vandaag aandacht vraagt, zonder iets op te vragen.
• Budget, tickets, deadlines, risico's en openstaande besluiten actueel en correct zijn, met bron.
• Het weekrapport in één klik te genereren is en klopt.
• De toegang per rol aantoonbaar werkt: een afdelingshoofd ziet niet meer dan zijn scope.
• Elke KPI herleidbaar is naar de bron.

12. MVP, wat we eerst bouwen

Bewust klein, zodat het snel echt in gebruik gaat voor 2027:

1. Het overzichtsscherm met de blokken: wat vraagt aandacht, openstaande besluiten, deadlines, ticketstatus, budgetstatus.
2. Handmatige of half-geautomatiseerde datatoevoer waar koppelingen nog niet af zijn, zodat het scherm niet leeg blijft wachten op integraties.
3. Eén werkende live koppeling om het principe te bewijzen, voorstel: ticketdata uit Paylogic of Fanalists.
4. De AI-samenvatting bovenaan en de daily briefing.
5. Rolgebaseerde toegang voor directie en hoofden.

13. Latere uitbreidingen ("zoveel mogelijk", gefaseerd)

• Volledige koppelingen met Asana, Brevo en de begroting.
• Het weekly board report als genereerbaar document.
• Risicomodule met impact en waarschijnlijkheid.
• De besparingsmonitor die de 15 procent doelstelling volgt over alle kostenposten.
• Terugschrijven naar tools (besluit maakt taak aan).
• Aparte weergaven voor Kingdance-specifiek, Dance4Liberation-specifiek en gedeeld, zodra de tweede-festival-logica erin komt.

14. Bouwinstructie voor Claude Code

• Bouw als losstaande webapplicatie in dezelfde lijn als de IPA Command Center (Astro of vergelijkbaar, Cloudflare Pages), zodat het past bij de bestaande manier van werken en later kan doorgroeien.
• Begin met een statisch overzicht op basis van een klein, expliciet datamodel (JSON of een lichte database), nog niet op live koppelingen. Eerst het scherm dat waarde geeft, dan de integraties.
• Houd data, presentatie en de AI-laag gescheiden, zodat we onderdelen los kunnen vervangen naarmate we meer in eigen beheer brengen.
• Bouw rolgebaseerde toegang in vanaf de eerste versie, niet als latere toevoeging.
• Elke getoonde waarde moet een bron-veld hebben, zodat herleidbaarheid vanaf het begin in de data zit.
• Volg de FestivalOS design principles, met nadruk op rust, snel scanbaar en status altijd zichtbaar.

Het datamodel hiervoor is nu uitgewerkt in 13-Data-Bible.md (kernobjecten plus de werkset van het Command Center: Task, Decision, Risk, Budget, TicketPhase, met bron-blok en rolgebaseerde toegang). Daarmee is deze bouwinstructie compleet genoeg om te starten. Enige resterende afstemming: de exacte veldnamen op wat Asana, Paylogic en Fanalists teruggeven, en de verdeelsleutel voor gedeelde budgetposten.

Terug naar de inhoud

FestivalOS, Open vragen en beslissingen

Levend document. Hier verzamelen we de vragen die het plan scherper maken, en de beslissingen die we onderweg nemen. Vragen verhuizen naar "Beslist" zodra we ze samen hebben beantwoord.

Status: Open Datum: 7 juli 2026

---

A. Scope en ambitie

1. Bouwen we FestivalOS uiteindelijk als echte software (webapplicatie met database, zoals de IPA Command Center), of eerst als een werkend systeem bovenop bestaande tools (Notion, Asana, koppelingen) dat we later vervangen? Dit bepaalt bijna alle technische keuzes.
2. Wat is voor jou het succescriterium voor editie 2027? Wanneer zeg je achteraf: dit heeft echt geholpen? Één of twee concrete uitkomsten helpen ons prioriteren.
3. Bouw je dit primair voor High Energy Events, of zie je FestivalOS vanaf het begin als een product dat je ook aan andere organisaties wilt verkopen? Dat verandert hoe generiek we alles moeten opzetten.

B. Organisatie en rollen

4. Jij bent nu extern strateeg en conceptbewaker bij Kingdance en Dance4Liberation, niet meer in de dagelijkse operatie. Wie is binnen High Energy Events de eigenaar en dagelijkse gebruiker van FestivalOS? Voor wie ontwerpen we het command center in de eerste plaats?
5. Het organogram in de prompt is uitgebreid. Klopt dat met de echte organisatie van beide festivals, of is het een ideaalplaatje? Kun je me de echte rollen en namen geven, zodat we op de werkelijkheid ontwerpen en niet op een sjabloon?
6. Hoeveel mensen werken er in de kern het hele jaar door, en hoeveel komen er pas in de aanloop bij? Dat bepaalt hoeveel het systeem moet dragen buiten het seizoen.

C. Bestaande tools en data

7. Welke tools gebruiken jullie nu echt, en hoe bevalt dat? Uit eerdere context ken ik Asana, Paylogic en Fanalists voor ticketing, Brevo voor mail en Wix voor de site. Klopt dat, en wat mist of irriteert?
8. Wat mag FestivalOS vervangen en wat moet het juist met rust laten? Ticketing bijvoorbeeld draait op gespecialiseerde systemen. Willen we die koppelen of overnemen?
9. Waar staat de kennis van vorige edities nu? Zijn er evaluaties, draaiboeken en begrotingen die we kunnen gebruiken om het AI Festival Brain vanaf dag één te voeden?
10. Mogen we opnames en transcripties van meetings gebruiken als bron voor het brein? Zo ja, van welke overleggen, en hoe gaan we om met wat daarin gevoelig is?

D. Gedeelde productie Kingdance en Dance4Liberation

11. Hoe verdelen jullie de gedeelde kosten nu tussen beide festivals? Is er een vaste verdeelsleutel, of wordt dat elk jaar opnieuw bepaald? FestivalOS moet dit kunnen vastleggen en bewaken.
12. Wat blijft er precies staan tussen 27 april en 5 mei, en wie is verantwoordelijk voor beveiliging en verzekering van het terrein in die tussenperiode? Dit is een risicogebied dat we goed willen modelleren.
13. Zijn er leveranciers die je bewust voor beide festivals samen inkoopt, en zitten daar contracten of onderhandelingen bij die nu suboptimaal lopen?

E. AI en vertrouwen

14. Waar zou je AI als eerste écht durven vertrouwen, en waar absoluut niet? Dat helpt ons bepalen welke agent we eerst bouwen en waar de menselijke slotsom hard blijft.
15. Hoe belangrijk is uitlegbaarheid voor jou en voor de directie? Willen jullie bij elk advies de onderbouwing kunnen zien, of is een korte samenvatting meestal genoeg?
16. Zijn er dingen die je AI juist expliciet níet wilt laten doen, ook al zou het kunnen? Grenzen die je vooraf wilt vastleggen.

F. Bouw en prioriteit

17. Als we na dit fundament één module echt zouden bouwen voor editie 2027, welke zou dat dan zijn? Mijn eigen voorstel: het Executive Command Center of het Knowledge OS, omdat die het snelst rust en overzicht geven. Wat is jouw gevoel?
18. Wat is de tijdshorizon? Wil je iets werkends vóór de campagne van 2027 losbarst, of bouwen we rustig richting 2028 en verder?
19. Wie gaat dit naast jou bouwen en beheren? Doe je dit vooral zelf via Claude Code, of komt er een team bij?

G. Commercieel en toekomst

20. De prompt eindigt met een SaaS-visie. Is dat een serieuze ambitie of voorlopig een stip aan de horizon? Als het serieus is, nemen we multi-tenant en onboarding veel eerder mee in het ontwerp.

---

Beslist (7 juli 2026)

B1. Slimme laag, geen big-bang eigen software. FestivalOS wordt een regie- en kennislaag bovenop bestaande tools (Asana, Paylogic, Fanalists, Brevo, Wix). Doel: over de komende jaren zoveel mogelijk in eigen beheer brengen en stap voor stap zelf doorontwikkelen. Tools blijven waar ze beter zijn, worden vervangen waar het eigen systeem beter kan.

B2. Succescriteria editie 2027. In volgorde van waarde: (1) meer overzicht voor de directie, (2) efficiënter werken, (3) snellere besluitvorming, (4) kostenefficiëntie met als streven een totale besparing van 15 procent op het productiekostenhuis van €4,5 miljoen (bijgesteld 10 juli 2026, was 20 procent), (5) meer automatiseringen, (6) meer gevoel van regie en minder afhankelijkheid, (7) innovatie binnen de organisatie. Deze zeven worden de meetlat voor elke module.

B3. Eén organisatie, één festivalproductie. FestivalOS is voorlopig alleen voor High Energy Events, gebouwd rondom één festivalproductie. We houden het datamodel wel netjes gescheiden (organisatie, festival, editie) zodat uitbreiding later kan, maar bouwen nu geen multi-tenant of onboarding.

B4. Gebruikers en toegang. Directie en diverse managers als kerngebruikers, plus mogelijke externe partners met eigen access levels. Rolgebaseerde toegang is dus vanaf het begin nodig, met een duidelijk onderscheid tussen intern (directie, managers) en extern (partijen zoals Start Moovin, Innercrowd, Designificance, Steroyd, Just in Case).

B5. Organisatie is bewust slank met veel externe partijen. Bron: organogram 2026 (Artiesten en Marketing & Communicatie ingevuld, overige afdelingen nog te leveren). Structuur: Afdeling, Hoofd, medewerkers of partijen, taken. Zie 20-Organisatiestructuur.md.

B6. Eerste module: Executive Command Center, met de wens om daaromheen zoveel mogelijk mee te nemen. Aanpak: Command Center als kern, gevoed door een lichte Knowledge- en Workflow-basis, zodat het overzicht echt is en niet leeg. Zie 30-Command-Center.md.

Nog te beantwoorden

• Volledige organogram: welke afdelingen zijn er nog naast Artiesten en Marketing (vermoedelijk Productie, Finance, Ticketing, Veiligheid en Vergunningen, Operations, Hospitality)? Wie zijn de hoofden?
• Welke verdeelsleutel gebruiken jullie voor gedeelde kosten tussen Kingdance en Dance4Liberation? (nodig voor de 15 procent besparingsdoelstelling)
• Waar staat de kennis van vorige edities die we in het Knowledge OS kunnen laden?

Terug naar de inhoud