Your advisor goes live once you have checked it.
A new Chat Advisor starts out inactive. Before you can publish it, you confirm six mandatory notices one by one and put at least five real test questions through the same pipeline that will later serve your customers. If one item is missing, publishing is rejected, and the response names exactly what is missing.
The most expensive moment is the one where something goes live that nobody checked.
An advisor answering on your site speaks in your name. That is why the Trust Center turns approval into a deliberate step instead of a side effect of publishing: mandatory notices read and confirmed one by one, self-test done, release by the owner role. Only then can the touchpoint go live.
Four conditions, all four required.
The gate checks every condition separately. On a rejection you do not just get a no, you get the full list of what is still open.
Every Chat Advisor starts out inactive, and it does so per touchpoint. Without a release it stays that way.
Each notice is confirmed on its own. There is no single collective checkbox, and every confirmation is bound to a version.
Only preview questions count, and they run through the same pipeline as production, in test mode and without persistence. On top of that comes your explicit confirmation that you have seen the result.
Only the owner role can activate an advisor or switch it off again. Other roles are rejected at this point.
Six items, six deliberate clicks.
The topics cover bindingness, price statements, fallibility, disclosure towards end users, data protection and the evidence trail. Each item carries a stable key and a version number so that later changes stay traceable.
Each of the six items is confirmed on its own. Whoever agrees has had the item in front of them, not a list that gets ticked off in one go.
If a notice changes in substance, its version goes up. The old confirmation no longer counts, and the touchpoint has to pass the release again.
The wording comes out of legal review, not out of the product. Until it is delivered, placeholders sit in the system, and the switch runs through a version bump.
Every confirmation is recorded, nothing is overwritten.
The release is not a switch, it is a process with a trail. If somebody asks months later who released the advisor, and on which version of the notices, the answer sits in the data.
Every confirmation records the user, the server timestamp, the IP address, the user agent, the notice key and the notice version. Entries are appended, never edited.
If the IP address of the request cannot be determined, the confirmation is rejected instead of stored with a hole in it. Half a record is not a record.
What gets recorded is the person releasing in the Studio, meaning an account on your team. The release evidence trail has nothing to do with end customer data.
If the gate fails on publishing, you get a rejection with reasons. The response lists every open item separately: which notice was never confirmed, which one is only confirmed in an outdated version, whether the self-test confirmation is missing, and whether the number of test questions is still short.
What is protected is publishing, not every single answer.
The gate sits in front of publishing. A touchpoint that does not pass it cannot be switched live. In production, the activation status is not checked again while a question is being answered. So there is no second lock per request, and we say so on purpose.
The six mandatory texts currently sit in the system as placeholders until the final wording is delivered. The Trust Center organises confirmation, version and evidence. It is not legal advice and does not replace any.
Approval as a deliberate step, not a checkbox.
Take a look at what the approval chain looks like in your Studio: six notices, your own test, and a record that stays.