How it works
The checks run before the utterance; dispatch, aggregation and the receipt follow it.
This page walks that path in plain language. If you want the call shapes, the failure behaviour and the field-by-field detail, /architecture has them.
The path
The checks run before the utterance; dispatch, aggregation and the receipt follow it.
Inbound voice, an outbound dispatch or a chat turn reaches the governance boundary before anything with an effect outside the model happens. The channel is identified and the tenant is resolved, so the right policy set is in scope before anything else runs.
The governance gate evaluates scope of practice, brand policy and content against the active rules, before any tool call is made and before any speech is synthesised.
Consent is checked against the consent record for that jurisdiction. For outbound, the eligibility engine consults do-not-call state and quiet hours before a number is dialled.
The disclosure is spoken inside the call flow, in the language of the call and at the position the policy for that country requires (Germany active · Netherlands in progress · Belgium, Austria queued). The receipt records the disclosure step: its wording hash, the jurisdiction and its position in the call.
Audio or text goes to the recipient. Each utterance is recorded with the verdict and the hash of the text as the system released it.
The per-call hashes are gathered into a Merkle root, and the root carries an RFC 3161 timestamp from freeTSA.org, a free public service.
The receipt lands in the evidence vault: one object per governed interaction, exportable, and three of its fields recomputable by anyone holding it; a fourth, Merkle inclusion, is checked against the published root with the inclusion proof from the call's Article 50 report.
Where the boundary sits
Two shapes are described on this site, and they are not the same thing. In one, the path a request travels is operated by Audact and the check sits inside it. In the other, the check is a call your own system places at a point in your own code. Both put the evaluation in front of the action, and both return one of three answers and a receipt. What differs is who owns the path — and, as the column on the right says, how far along each one is.
The two shapes, and how far each one is
Neither of the two is generally available, and the two do not stand equally far: calls run in the first, but no paying deployment has gone through it; the second has no users and its runtime is being built. Which shape applies to a given deployment is settled when it is set up and written into the contract — not assumed from this page. /architecture describes the second shape field by field.
What follows from that difference is where coverage comes from. Where Audact operates the path, what is governed follows from what runs over it. Where your system places the call, what is governed follows from where you place it: if your system does not call the gate, nothing is evaluated — and nothing is recorded either.
The disclosure
Article 50 of the EU AI Act has applied since 2 August 2026. It requires that a person is told they are interacting with an AI system, unless that is obvious. It is a transparency duty; it does not prohibit deploying AI.
How that duty is delivered
A country is only listed once its national layer on top of Article 50 has been checked by a person against the national text. The article numbers and the Commission guidelines behind this are set out on the EU AI Act page.
What the law requires, with the article numbers so you can check us.
What is left behind
A receipt is not a log line with a nicer name. Three of its fields can be recomputed by anyone holding the receipt: no key, no account, no access to our database. A fourth, Merkle inclusion, is checked against the published root with the inclusion proof from the call's Article 50 report. The fifth is checked with the key issued to your tenant.
The authentication code is HMAC-SHA256 under a symmetric key held by Audact. Whoever can check it can also produce it. The timestamp is an RFC 3161 timestamp from freeTSA.org, a free public service. It fixes an ordering against our own chain; freeTSA.org is not an eIDAS-qualified trust service, so this is not a qualified timestamp and we do not present it as one.
What a third party can recompute, and exactly what a receipt is a record of.
No account, no API key.
What it costs in the call
A governance layer that runs beside the call and reports afterwards costs nothing in the conversation and prevents nothing in it either. Here the evaluation happens before the utterance reaches the person on the other end, so it adds time to every turn, and that is the price of an utterance being stopped rather than logged. That cost comes from the check being in front of the action, so it applies to both of the shapes above and not only to one of them.
What that costs in your configuration depends on the model, the policy set and the route, and it is measured against your own stack during onboarding rather than promised on a marketing page. There is no single answer. The failure contract differs per action class and is agreed per customer and written into the contract; /apis/governance-gate and /architecture set out the cases.
Further
The same path for a developer: diagrams, call shapes, failure behaviour.
How a rule is written, and what the engine reads.
What the platform is made of and where it sits.
See it run
The fastest way to judge this is to look at what comes out of it. The receipt explorer walks a chain field by field with the sample files next to it, and none of it needs an account.
Intake is sales-led. The first governed configuration is built with you, not handed over as a login.
