Proof
Laat regel voor regel zien wat eruit volgde.
Bij bestuurde interacties is in het product een compliancebon zichtbaar. Die legt vast wat het systeem heeft ontvangen, besloten en vrijgegeven: als hashes, geketend aan de vorige bon en samengebracht in een Merkle-wortel. Drie van die onderdelen kan iedereen met de bon in handen vandaag narekenen: geen sleutel, geen account, geen toegang tot onze database. De vijfde, de authenticatiecode, controleert u met de sleutel die wij aan uw tenant uitgeven.
Compliancebon
Doorgerekend voorbeeld- Invoerhash
0x92f2242f4701ee89…83b61ceaGeen sleutel nodig- Uitvoerhash
0x8a09586162b314e2…d79c6b92Geen sleutel nodig- Evidencehash
0xa8154f5f53e495a5…af2231baGeen sleutel nodig- Handtekening
0xed8c2d6ef474c9e5…1433dd3cSleutel van Audact nodig
Doorgerekend voorbeeld. Acme GmbH en Nova Industries zijn verzonnen; hier staan geen klantgegevens. Dit zijn waarden uit de voorbeeldbon op /sample-receipt.json. /receipt-explorer rekent de drie sleutelvrije waarden na in uw eigen browser: invoerhash, uitvoerhash en evidencehash. De authenticatiecode wordt berekend onder een symmetrische sleutel die door Audact wordt beheerd en kan niet worden geverifieerd zonder die sleutel.
Huidige bewijsstand
- Bon in het productZichtbaar
- Productie-export (gemeten op browsergesprekken in plaats van over een telefoonlijn)Werkt vandaag · op 26 augustus 2026 na de deploy hertest
- Drie hashcontrolesOpenbaar
- Externe wortelpublicatieWerkt vandaag
- Publieke controle van de uitgeverNiet beschikbaar
Vijf standen, niet één. Elk staat hieronder, met waar hij op rust.
Veld voor veld
Wat er in een bon staat
Een bon is één object per bestuurde handeling. Het meeste erin is een vastlegging: u kunt het aflezen, en dat aflezen vertelt u waar het systeem op dat moment van uitging. Drie velden zijn door iedereen met de bon in handen na te rekenen: geen sleutel, geen account, geen toegang tot onze systemen. De authenticatiecode wordt berekend onder een symmetrische sleutel die door Audact wordt beheerd: hij authenticeert de bon maar kan niet worden geverifieerd zonder de sleutel.
- Veld
- receipt_format_version
- Wat het vastlegt
- De versie van het bonschema. '1.0.0' in dit voorbeeld.
- Controle
- Aflezen
- Veld
- call_id
- Wat het vastlegt
- De unieke kenmerkcode van de interactie.
- Controle
- Aflezen
- Veld
- timestamp
- Wat het vastlegt
- Wanneer de bon is geschreven, volgens de platformklok.
- Controle
- Aflezen
- Veld
- input_hash
- Wat het vastlegt
- SHA-256 van de invoertekst, zoals het systeem hem heeft ontvangen.
- Controle
- Narekenen
- Veld
- output_hash
- Wat het vastlegt
- SHA-256 van de uitvoertekst, zoals het systeem hem heeft vrijgegeven. MODIFY-oordeel: verschilt van input_hash.
- Controle
- Narekenen
- Veld
- verdict
- Wat het vastlegt
- De gate-beslissing: ALLOW, BLOCK of MODIFY.
- Controle
- Aflezen
- Veld
- config_version
- Wat het vastlegt
- De configuratieversie die actief was tijdens de interactie.
- Controle
- Aflezen
- Veld
- config_seal_hash
- Wat het vastlegt
- SHA-256 van de configuratie in die versie.
- Controle
- Aflezen
- Veld
- policy_version
- Wat het vastlegt
- De beleidsversie die op deze interactie is toegepast.
- Controle
- Aflezen
- Veld
- evidence_hash
- Wat het vastlegt
- SHA-256 van de voorgaande nawijsgebeurtenis in de nawijsketen van het gesprek.
- Controle
- Narekenen
- Veld
- auth_mechanism
- Wat het vastlegt
- Het authenticatiealgoritme: 'hmac-sha256'.
- Controle
- Aflezen
- Veld
- signature
- Wat het vastlegt
- HMAC-SHA256 over de signeerpayload onder een symmetrische sleutel die door Audact wordt beheerd.
- Controle
- Sleutel nodig
Elke naam in deze kolom is een veld van de voorbeeldbon op /sample-receipt.json, geschreven zoals het bestand het schrijft: open het bestand en ze staan er allemaal in.
De keten
Elke bon noemt de vorige.
Een bon staat niet op zichzelf. Voordat hij wordt geschreven gaat de hash van de vorige bon erin mee, zodat de bonnen van één tenant samen één geordende keten vormen.
Juist daardoor valt een wijziging op. Verander een waarde in een bon en zijn hash verandert; de bon erna draagt nog de oude, en die twee passen niet meer op elkaar. Niets hieraan houdt een wijziging tegen; het maakt een wijziging zichtbaar voor iedereen die de keten naloopt.
Bon RCP-899
- Draagt de hash van
0xc15f…df07- Eigen hash
0xe48f…5a07
Bon RCP-900
- Draagt de hash van
0xe48f…5a07- Eigen hash
0x627d…9389
Bon RCP-901
- Draagt de hash van
0x627d…9389- Eigen hash
0xfb45…4fd2
Als er één verandert
Elke bon daarna past niet meer, en de eerste afwijking noemt de plaats waar de keten is gebroken. Alleen toevoegen is hoe wij schrijven. Detecteerbaar is wat u kunt controleren.
Auditlog
Gebeurtenisketen waaraan alleen wordt toegevoegd. Een latere wijziging of herordening is detecteerbaar door de keten opnieuw te berekenen tegen het bewaarde commitment.
Insluiting
Reken de wortel zelf na.
Bonnen worden per tenant samengebracht in Merkle-wortels; de wortels zijn gepubliceerd op api.audact.ai/v1/metachain. De vier stappen hieronder tonen de padnarekening aan de hand van een ouder illustratief voorbeeld dat de padvelden draagt.
- Weg vanaf deze bon
- Gebruikte zusterhashes
- Overige bonnen in de stapel
Vier stappen
- 1
Hash de vijf kernvelden
Neem receipt_id, issued_at, input_hash, output_hash en previous_receipt_hash, zet ze in één vaste vorm (sleutels alfabetisch, geen witruimte) en neem er de SHA-256 van. Die waarde is het blad, en de bon draagt hem als receipt_hash. Het is geen hash over de hele bon.
- 2
Reken de eerste zuster mee
Zet het blad en de eerste hash uit merkle.path terug in bytes, plaats de zuster aan de kant die haar veld side noemt, plak ze aan elkaar en neem de SHA-256 van het paar.
- 3
Loop omhoog
Herhaal dat voor elke volgende ingang in merkle.path, laag voor laag, tot er één waarde over is.
- 4
Vergelijk
Leg die waarde naast merkle.root. Gelijk betekent dat deze bon past bij de wortel die het bestand zelf draagt. Om de insluiting te bevestigen, wordt die wortel met het insluitingsbewijs uit het artikel 50-rapport van het gesprek gecontroleerd tegen de gepubliceerde wortel op api.audact.ai/v1/metachain.
Geen van die vier stappen gebruikt een sleutel: de bon en zijn pad zijn genoeg. Wat ze vaststellen is dat de bon past bij de wortel die hij zelf draagt. De insluiting in de gepubliceerde wortel wordt gecontroleerd met het insluitingsbewijs uit het artikel 50-rapport van het gesprek; de wortels staan op api.audact.ai/v1/metachain.
Uit het oudere illustratieve voorbeeld
- Veld
- receipt_hash
- Zoals gepubliceerd
- 0xfb45e410edb4a3aa…ecb14fd2
- Veld
- merkle.leaf_index
- Zoals gepubliceerd
- 2
- Veld
- merkle.path
- Zoals gepubliceerd
- right · left · right
- Veld
- merkle.root
- Zoals gepubliceerd
- 0x8a11d892e1e07458…e1141396
Controle voor controle
Zeven controles, en ze zijn niet even beschikbaar.
Het Merkle-pad narekenen tot de wortel die een bon zelf draagt, is niet dezelfde controle als die wortel met het insluitingsbewijs uit het artikel 50-rapport van het gesprek afzetten tegen de gepubliceerde wortel op api.audact.ai/v1/metachain. De eerste kunt u vandaag doen, in het uitgewerkte voorbeeld. De tweede gebruikt het insluitingsbewijs uit het artikel 50-rapport van het gesprek. Elke regel hieronder noemt waar de controle op rust en waar hij staat.
- Controle
- De invoerhash narekenen
- Waar hij op rust
- SHA-256 over het input-blok van de bon die u in handen hebt. Meer is er niet voor nodig.
- Stand
- Beschikbaar
- Controle
- De uitvoerhash narekenen
- Waar hij op rust
- SHA-256 over het output-blok van hetzelfde bestand.
- Stand
- Beschikbaar
- Controle
- De hash van de voorgaande nawijsgebeurtenis narekenen
- Waar hij op rust
- SHA-256 van de voorgaande nawijsgebeurtenis in de nawijsketen van het gesprek. De velden van de gebeurtenis worden in een vaste volgorde pijpgescheiden, en de bon draagt de hash als evidence_hash.
- Stand
- Beschikbaar
- Controle
- Het Merkle-pad narekenen tot de wortel die de bon zelf draagt
- Waar hij op rust
- Vouw het blad omhoog langs merkle.path en leg het naast merkle.root in hetzelfde bestand. Bonnen worden per tenant samengebracht in Merkle-wortels; de wortels zijn gepubliceerd op api.audact.ai/v1/metachain, en insluiting wordt gecontroleerd met het insluitingsbewijs uit het artikel 50-rapport van het gesprek. De stappen lopen op /sample-receipt.json; de productie-export werkte bij de hertest op 26 augustus 2026 na de deploy, gemeten op browsergesprekken in plaats van over een telefoonlijn.
- Stand
- Beschikbaar in het uitgewerkte voorbeeld
- Controle
- Die wortel afzetten tegen een buiten onze systemen gepubliceerd commitment
- Waar hij op rust
- Een vierde, de insluiting in de Merkle-wortel, wordt gecontroleerd met het insluitingsbewijs uit het artikel 50-rapport van het gesprek: de klant exporteert het rapport en kan het aan een beoordelaar overhandigen, die het bewijs afzet tegen de gepubliceerde wortel.
- Stand
- Werkt vandaag
- Controle
- Met alleen publieke cryptografie vaststellen wie de bon heeft uitgegeven
- Waar hij op rust
- De bon draagt HMAC-SHA256 onder een symmetrische sleutel die door Audact wordt beheerd. Een vrij toegankelijke sleutel om hem mee te controleren is er niet, dus er is voor een derde niets om tegen te controleren.
- Stand
- Niet beschikbaar
- Controle
- De uitgever eraan houden als hij ontkent hem geschreven te hebben
- Waar hij op rust
- Een authenticatiecode onder een gedeelde sleutel levert dat niet: wie hem kan controleren, kan hem ook maken, en wij houden diezelfde sleutel. Het is geen handtekening.
- Stand
- Niet geleverd door het huidige HMAC-ontwerp
/receipt-explorer voert de eerste drie hiervan uit op het uitgewerkte voorbeeld, in uw eigen browser. Geen enkele publieke dienst controleert vandaag een bon namens een derde.
Reken het zelf na
Drie gegevens, door iedereen na te rekenen.
Begin links: drie waarden die iedereen met een bon in handen kan narekenen, zonder sleutel en zonder ons. De vierde, de insluiting in de Merkle-wortel, wordt met het insluitingsbewijs uit het artikel 50-rapport van het gesprek gecontroleerd tegen de gepubliceerde wortel. Ernaast staat waar de sleutel voor is en waar een bon een vastlegging van is. Juist daardoor kunt u de eerste kolom letterlijk nemen in plaats van op vertrouwen.
Drie gegevens, door iedereen na te rekenen
De invoerhash, de uitvoerhash, de koppeling met de vorige bon. De insluiting in de Merkle-wortel is de vierde controle; die wordt met het insluitingsbewijs uit het artikel 50-rapport van het gesprek gecontroleerd tegen de gepubliceerde wortel.
Geen sleutel, geen account en geen toegang tot onze database: de rekensom loopt op de bon die u in handen hebt.
Waar de sleutel voor is
De code is HMAC-SHA256 over de canonieke bon, onder een symmetrische sleutel die door Audact wordt beheerd. Het is een authenticatiecode en geen procedure met een openbare sleutel; een vrij toegankelijke sleutel om het na te rekenen is er niet.
Wie de code kan controleren, kan hem ook maken, en wij houden diezelfde sleutel. Hij toont dat de vastlegging ongeschonden is, niet wie haar heeft geschreven.
Waar een bon over gaat, en waar niet
Een bon is een getrouwe vastlegging van wat het systeem heeft ontvangen, besloten en vrijgegeven. Dat is wat hij vaststelt, niet of de werkelijkheid daarmee overeenkwam.
Gaf een beller een verkeerde naam op, dan legt de bon die verkeerde naam getrouw vast. Bewijs van het proces is geen bewijs van het feit, en geen enkele cryptografie dicht dat gat.
Doe het zelf
Haal een bon uit elkaar.
De explorer loopt het uitgewerkte voorbeeld veld voor veld na, met de voorbeeldbestanden ernaast. Niets daarvan vraagt om een account.
- Bonverkenner
Loop het uitgewerkte voorbeeld veld voor veld na.
- Voorbeeldbon (JSON)
Verzonnen partijen, echte rekensom: drie waarden rekenen zich na uit het bestand alleen, en de vierde vouwt op tot de Merkle-wortel die in datzelfde bestand staat.
- Voorbeeldbon (PDF)
Dezelfde vastlegging in een vorm die een functionaris gegevensbescherming kan lezen.
- Evidence Vault-API
Hoe bonnen worden geschreven en opgehaald.
- Hoe u hem narekent — de exacte vorm
De canonieke vorm, welk blok in welke waarde gaat, en vier testvectoren om op af te stellen. Geen code van ons.
Bewijsketen
Drie van die onderdelen kan iedereen met de bon in handen vandaag narekenen: geen sleutel, geen account, geen toegang tot onze database.
Het controleren van de authenticatiecode gebruikt de symmetrische sleutel die wij aan uw tenant uitgeven.
Control what AI can cause. Prove what follows.
Waar een bon vandaan komt
Een bon is wat een bestuurd gesprek achterlaat.
Voice is de toepassing waar hij uit komt: telefonie, de mededeling uit artikel 50 en het landbeleid op één plek, met een bon die voor bestuurde interacties zichtbaar is in het product.