Mint
At the end of a governed interaction the platform writes a receipt: the disclosure event, the jurisdiction, and the hashes of what went in and what came out.
Part of the Audact layer
A receipt you can hand over.
Receipts: Working today · public verifier: Not available yet
Every governed interaction mints a compliance receipt: hashed, chained to the one before it, and aggregated into a Merkle tree whose root carries an RFC 3161 timestamp.
Three of the fields on that receipt can be recomputed by anyone today: the input hash, the output hash and the link to the previous receipt. The fourth, inclusion in the Merkle root, is checked against the published root with the inclusion proof from the call's Article 50 report. For the three that stand there is no key, no account and no call to us.
- Included in Agency Voice & Enterprise
- Patent-pending governance stack (UK IPO)
How it works
Mint, anchor, recompute.
Anchor
Receipts are hashed and aggregated into a Merkle tree. The daily root carries an RFC 3161 timestamp, so a later change or reordering is detectable by recomputation against a retained commitment.
Recompute
Public verifier: Not available yet
Public verifier not available yet: the roots are published at api.audact.ai/v1/metachain, but a service that performs the steps for you does not exist today, and no date is committed. The fourth field, inclusion in the Merkle root, is checked against the published root with the inclusion proof from the call's Article 50 report. The other three are checked from the receipt itself, by whoever holds it — no key, no account.
Scope
What the receipt covers, and what it is about.
A receipt records that a governed interaction happened and what the governance decided about it. It is a record of the decision, not a transcript: it carries the hashes rather than the words.
That is deliberate. It means a receipt can be handed to a client, an insurer or a supervisory authority without handing over the conversation, and it means the record survives when the underlying audio is deleted under your retention policy.
- Digest only — no readable content
- One receipt per governed interaction, chained to the previous one.
- The export returns the receipts. That is not the same as an outsider being able to check the export: the export envelope refers to a key of ours, and that key is not published.
- The authentication code on the receipt is HMAC-SHA256 under a symmetric key issued to your tenant; that field is the one that needs your key.
Where it goes next
Into the audit dashboards you already run.
The roadmap includes native connectors for the major privacy and trust-management platforms, so receipts reach an existing audit dashboard without an integration project first.
Connectors are planned. Until then the export is REST and file-based.
Next step
See it before you buy it.
Read a sample receipt field by field and see for each field whether a third party can recompute it, read it, or needs a key for it. Then decide whether that is the artefact your clients need.
Related
The Audact platform Control and Proof are the layer; Voice is the application on it.
Proof The receipt explained field by field, with the chain and the Merkle path.
Observability Layer Receipt coverage is one of its four SLOs.
Evidence Vault API Where receipts are stored and exported from.