For developers and technical due diligence
Authority before action. Proof through finality.
This page describes the shape of the system. It is written for someone who will read the response body, not the brochure.
A request is evaluated against a mandate before anything happens outside the model. The evaluation returns one of three answers, and each of the three writes a compliance receipt. What a third party can recompute from that receipt (without a key, without an account and without access to our systems) is set out below, field by field. This page describes the shape in which your own system calls the gate; in the managed voice application Audact operates the path and the same evaluation sits inside it. The three answers and the receipt do not change between the two.
01. The path of a request
From arrival to receipt
Seven steps. The one that matters is the fourth: the check runs before the effect leaves the boundary, not after it has landed. A system that reviews afterwards can tell you what went wrong. A system that checks first can keep it from going wrong. Everything else on this page follows from that ordering. The architecture is described; the runtime is being built.
Control · In development
The check sits before the action, not after it.
- 01
Request arrives
A voice turn, a chat turn or an agent tool call asks for something with an effect outside the model.
- 02
The mandate is resolved
Tenant, agent and country decide which mandate and which policy set apply to this one request. Nothing is evaluated against a general rule when a specific one exists.
- 03
The effect is described
The intended effect is put into a structured form: what, for whom, how much, under which rules. At this point it is described. It has not been performed.
- 04
The check runs
In the model, that description is evaluated against the mandate (ceiling, scope, expiry) and against the policy set for the country. This is the step that sits before the action, and it is the whole difference.
- 05
One of three answers returns
Allow, modify or block. There is no fourth value.
- 06
Only allow and modify cross the boundary
On allow, your systems carry the action out inside the bounds that were checked; on modify, they carry out the changed version. On block it is not carried out at all.
- 07
The receipt is written
Input hash, output hash, the link to the receipt before it, and the entry that goes into the Merkle tree. This happens after every one of the three answers.
02. The gate
One call. Three answers. A receipt after each.
The gate is a single call your system makes at the point where an effect would otherwise begin. It answers with one of three outcomes, and it returns a compliance receipt whichever outcome it answers with. Nothing about the answer changes whether a receipt is written.
Three answers, one artefact.
- Outcome
- What happens to the action
- Carried out by your systems, inside the bounds that were checked.
- What comes back
- Compliance receipt
- Outcome
- Modify
- What happens to the action
- Carried out in a changed form: the part that would break the mandate is taken out or rewritten.
- What comes back
- Compliance receipt
- Outcome
- Block
- What happens to the action
- Not carried out.
- What comes back
- Compliance receipt
A block produces the same artefact as an allowance. That symmetry is the point: the record is not a list of the things that went well.
The shape of the call
Shown for orientation, not as a specification. The field-by-field reference lives in the API documentation.
Request
POST /v1/gate/evaluate
{
"tenant": "acme-emea",
"agent": "renewals-emea",
"intent": "commit.discount",
"country": "DE",
"amount": {
"value": 1240,
"currency": "EUR"
}
}Response
200 OK
{
"verdict": "BLOCK",
"reason": "above the agent ceiling",
"receipt": {
"receipt_format_version": "1.0.0",
"call_id": "7f3c2a1e-...",
"input_hash": "sha256:9f2a...",
"output_hash": "sha256:41c7...",
"evidence_hash": "sha256:0b8e...",
"auth_mechanism": "hmac-sha256",
"signature": "z3fx..."
}
}Where a blocked request stops
- Completed: Mandate
Set by a person.
- Completed: Authority
Bounded, not open.
- Blocked: Clearance
This one is over the line.
- Not started: Effect
What it would cause.
- Not started: Obligation
What follows from it.
- Not started: Finality
Follows closure evidence from an authorised source, and is re-checkable afterwards.
A blocked request does not fail silently and it does not pass. It stops at the station where the mandate rules it out, and the stop is recorded. These six stations order the screen and the conversation; they are a way of reading the state, not a mechanism claimed as such.
03. Failure behaviour
What happens when the governance layer cannot be reached
Every design of this kind has to answer one question honestly: what does the system do when the part that grants permission is not there? There are two possible answers, and only one of them keeps the record meaningful.
No answer is treated as no permission.
The gate answers
One of the three outcomes comes back inside the evaluation window. The action follows the answer, and a receipt is written.
The gate does not answer
No answer inside the window is treated as no permission. The action is not carried out, the caller gets a block rather than a silence that reads like a yes, and the unavailability itself is recorded so the gap is visible afterwards instead of invisible.
The word for this is fail-closed, and it is the right default for an action that commits money or makes a promise. It is not the right answer for every action: reading a record and booking an appointment do not carry the same consequence, and a failure contract that treats them alike either blocks harmless work or lets consequential work through. Which class falls back how is a decision per action class, made with the customer and written into the contract, not a switch we set for everyone. The opposite arrangement (proceed now, reconcile later) is the one that makes an outage indistinguishable from an approval, and that is the arrangement this design gives up. That is a deliberate trade: availability is spent so the record keeps its meaning.
04. The evidence chain
The receipt as a data structure
A receipt is not a log line with a nicer name. It is four fields, and three of them can be recomputed by anyone holding nothing but the receipt: no key, no account, no access to our systems. The authentication code is computed under a symmetric key held by Audact. Read field by field, it says exactly what the artefact carries.
Each receipt links backwards and upwards: to the one before it, and into the root, which is published at api.audact.ai/v1/metachain.
- Field
- input_hash
- What it holds
- The request exactly as it was evaluated.
- Recomputable by a third party
- Without a key
- Field
- output_hash
- What it holds
- SHA-256 of the output text, as the system released it.
- Recomputable by a third party
- Without a key
- Field
- evidence_hash
- What it holds
- The hash of the preceding evidence event in the same chain.
- Recomputable by a third party
- Without a key
- Field
- auth_mechanism
- What it holds
- HMAC-SHA256 under a symmetric key held by Audact.
- Recomputable by a third party
- Key needed
Three fields, recomputable by anyone
Input hash, output hash and the hash of the preceding evidence event: three fields, recomputable with nothing but the receipt. No key, no account, no access to our systems. The fourth field, the authentication code, is computed under the symmetric key held by Audact and authenticates the receipt against it.
That recomputation is what makes a later change to a receipt, or a reordering of the chain, detectable: the recomputed hashes stop matching the stored ones.
Open the receipt explorer05. Where the data sits
Hosting, in the order that matters
Primary application hosting is Frankfurt. The table says, layer by layer, where each part of the system runs and where each vendor processes.
- Layer
- Application and API
- Where
- Frankfurt
- Note
- Primary application hosting.
- Layer
- Evidence chain and receipts
- Where
- Frankfurt
- Note
- Stored with the tenant they belong to.
- Layer
- Speech, model and telephony vendors
- Where
- Per vendor
- Note
- Some process outside the EU under standard contractual clauses.
- Layer
- Merkle roots (published at api.audact.ai/v1/metachain)
- Where
- Public endpoint
- Note
- Digest only — no readable content
The authoritative list
The Trust Center names every subprocessor and where it processes, including the ones that process in the United States under standard contractual clauses. That list is kept current, it is the authority on this question, and this page follows it.
View current product status06. What it is not
Three things this is not, and the misreadings they prevent
These are the three assumptions that cost the most when they go unchallenged: each one sounds like a compliment, and each one describes a different product.
Not an interception layer
Not this
Nothing described on this page is placed in front of your network, and nothing here reads a stream of yours on its own initiative.
What it is instead
The gate described here is a call your system makes, at a point in your own code that you choose. If your system does not call it, nothing is evaluated — and nothing is recorded either. Coverage is a property of where you place the call, not something the network grants you. The managed voice application is the other shape: there the speech stack is run by Audact, so the check sits inside a path we operate rather than at a call you place. Which of the two applies is settled per deployment.
Not a keystore for your systems
Not this
Audact does not hold, rotate or hand out the credentials your systems use with one another, and it is not somewhere to park a key you would rather not manage.
What it is instead
The authentication code on the receipt is computed under a symmetric key held by Audact. What that key covers is set out field by field in section 04 above.
Not a ledger
Not this
The chain is not a book of account. It holds no balances, it moves no money, and it does not net a position between two parties.
What it is instead
It records what was decided and what followed from it. Where money moves, it moves in your own systems; the receipt says what was permitted and what was recorded, and it stays out of the accounting.
Next
Recompute it yourself
The fastest way to judge this architecture is not to read further. Take a receipt, recompute the chain field by field, and see for yourself that it matches.
The mechanisms described on this page belong to a patent-pending governance stack (UK IPO).