De meeste software onthoudt wat veranderde. Veel minder software onthoudt waarom een verandering was toegestaan, wie of wat die besloot en op welk bewijs de beslissing stond. In dat gat erodeert vertrouwen stilletjes. Een operations team kan meestal beantwoorden “wat is de state nu”; vaak kan het niet beantwoorden “laat zien hoe we hier kwamen, en bewijs dat we dit mochten.”
Threada is zo gebouwd dat de tweede vraag altijd beantwoordbaar is. Elke governede actie laat een receipt achter.
Wat een receipt echt bevat
Een receipt is geen logregel. Een logregel zegt “er is iets gebeurd.” Een receipt zegt genoeg om een beslissing later te reconstrueren en te verdedigen. In Threada legt een governede actie vast:
- De actor. Een menselijke operator of een AI participant, vastgelegd als afzonderlijke actor events. Een approval van een agent doet zich nooit voor als die van een persoon.
- De inputs. Het WorkItem, zijn geëxtraheerde entities, de requester identity en het source channel waarop het verzoek binnenkwam.
- Het bewijs. De citaties, retrieval trace en, wanneer context onvoldoende was, de expliciete fallback reason. Werk kan niet worden gecreëerd zonder citaties of een vastgelegde fallback reason.
- Het beleid. Welke policy set actief was, op welke versie, en of die tenant-wide of op een smallere pack, workflow, channel of requester group van toepassing was.
- De uitkomst. Of de actie proposed, approved, rejected, executed, succeeded of failed was, met de koppeling terug naar het externe record dat ze raakte.
Lees die velden samen en je hebt een verdedigbaar verslag van één stap. Lees ze over de lifecycle van een WorkItem en je hebt de volledige geschiedenis.
Auditability als default, niet als feature die je erop schroeft
De verleiding in de meeste systemen is audit later toevoegen: feature shippen, dan logging eromheen bouwen wanneer een klant SOC 2 evidence vraagt of een regulator aanklopt. Die volgorde is achterstevoren. Audit die achteraf wordt toegevoegd is altijd gedeeltelijk, omdat het systeem nooit werd gevraagd de context te dragen op het moment dat de beslissing werd genomen.
Threada draait de volgorde om. De runtime emit structured events bij elke betekenisvolle overgang, work_item_created, approval_requested, approval_decided, action_proposed, action_executed, fallback_triggered, omdat het doen van het werk hetzelfde moment is als het vastleggen ervan. Er is geen aparte “turn on auditing” stap, omdat er geen moment is waarop werk off the record gebeurt.
Dit bedoelen we met records-and-receipts. Het record is geen rapport dat je genereert; het is het residu van het werk correct doen.
Waarom receipts veranderen hoe teams werken
Een receipt is nuttig voor de auditor aan het einde van het kwartaal. Maar de stillere waarde zit bij de operator midden op een dinsdag.
Wanneer elke actie haar bewijs en beleidsbasis draagt, worden drie dingen makkelijker:
- Review wordt snel en eerlijk. Een approver hoeft context niet uit het geheugen te reconstrueren of de requester te achtervolgen voor de oorspronkelijke vraag. Het bewijs staat naast de actie. Confidence, reversibility en clarity zijn zichtbaar op het beslismoment, zodat reviewers optimaliseren voor reviewability in plaats van alleen snelheid.
- Terugdraaien wordt veilig. Omdat de receipt policy version en inputs noemt, is een actie terugrollen een gedefinieerde operatie, geen archeologieproject. Je weet wat je ongedaan maakt en waarom het werd gedaan.
- Accountability stopt met vijandig zijn. Wanneer het record zichzelf assembleert, is “wie heeft dit goedgekeurd” geen beschuldiging maar gewoon een veld. Scheiding van taken tussen builder, approver en governance roles wordt afgedwongen en zichtbaar, zodat de accountabilityvraag beantwoord is voordat iemand die hoeft te stellen.
Werk met hoog risico blijft menselijk, op het record
Receipts betekenen niet dat alles geautomatiseerd is. Ze betekenen dat alles verantwoordbaar is. Automatiseringen met hoog risico volgen een expliciete human-in-the-loop progression, proposed, then approved, then executing, en auto-execute alleen waar beleid dat expliciet toestaat. De receipt legt vast welk pad een gegeven actie nam. Automation en approval staan niet op gespannen voet; het zijn allebei gewoon stappen die een spoor achterlaten.
Het resultaat is een systeem dat je met hetzelfde vertrouwen aan een auditor en aan een nieuwe operator kunt geven. De auditor ziet dat de controls hielden. De operator ziet hoe de vorige persoon de case vóór hem afhandelde. Beiden lezen dezelfde receipts.
Dat is de weddenschap onder Threada: dat het goedkoopste moment om vast te leggen waarom een beslissing was toegestaan het moment is waarop je die neemt, en dat een team dat nooit off the record werkt altijd de tweede vraag kan beantwoorden.