Security
Conversations do not leave your machine to be designed.
Most tools in this category ask for a production connection before they can show you anything. Chawo was built the other way round, and the boundaries below are the reason it can be.
It runs where you run it.
The workbench is a local process on one machine. It does not contact a live runtime while you design, test or read back a conversation, so there is no third party sitting between you and the script you are editing.
It reads projections, not your production database.
The data behind a run is a checked-in redacted or synthetic projection. Chawo has no production database credentials and no code path that would use them. What you replay is a record shaped for reading, not a live table.
Nothing is written outward.
There is no write path to a CRM, an ad platform or a messaging channel. That removes an entire class of incident: a misconfigured test cannot reach a customer, because the build has nowhere to send anything.
The network boundary is one rule, and it is checkable.
The web process answers requests arriving over loopback and returns 421 to any other host header. It is a single rule rather than a policy document, which means you can verify it yourself in a minute instead of taking our word for it.
What this does not cover yet.
The current build has no operator authentication of its own, because it has never been reachable by anyone but the operator running it. Hosting changes that, and authentication and tenant isolation are prerequisites for hosting rather than additions to it. A data processing agreement lands with the hosted build.