Compare · Controls and settings
A setting is something someone can turn off: an administrator, a plan tier, a support ticket, a spending limit. A floor is something nobody can, because there is no value anyone could write down that would express it.
Vocapable runs four of them on every dial, on every plan, at no charge. Every call your account places arrives with a record of which ones ran and what bound it, which is what answers the question a year later without anybody having to remember it.
The two models
On a grid of checkmarks, “AI disclosure” and “opt-out handling” appear as rows in both columns, and a checkmark cannot say which kind of thing is behind it. The difference is not how well a control works. It is whether an off state exists.
A floor is a control with no off state. Not a control somebody promised not to turn off, and not a control that requires two approvals to turn off. A control for which no off state exists to be reached. The test is not who holds the switch. It is whether a switch was ever built.
An opt-in setting is something someone can turn off: an administrator, a plan tier, a support tool, a spending limit. That is not a criticism of any product, and it is not a claim about any product. It is what the word means, and it is the whole of what the right-hand column below describes.
Enforced in code · every plan · every entry point
They run in every mode, for every tenant, on every plan, through every entry point on campaign dials, ad-hoc API calls, and agent test calls alike. They are not settings, and no API field, plan tier, feature flag or support tool reaches them.
Compiled by the policy engine and played before the model produces its first token. The ordering is an interlock rather than a convention: reaching the model early raises instead of dialing, and if the opener cannot be played, the call ends.
A deterministic phrase list and a keypress detector run on every final transcript. Either one firing hands control to scripted code, writes your internal do-not-call entry mid-call, and cascades the suppression across every campaign in your workspace.
Your own suppression list is applied when the list is prepared, and read live again at dial time rather than from cache. An opt-out taken during one call suppresses the next dial. If that read is unavailable, dialing halts rather than proceeding on a stale answer.
Validation to E.164, short-code rejection, and dedupe, run as a stage of the pipeline rather than as a pre-step, so it leaves a result on the record like every other stage.
This is the whole argument of the page, and it is an engineering statement rather than a posture. A tenant’s compliance mode can only name checks drawn from a fixed waivable set, and these four are not members of it. “Waive the disclosure opener” is not a value anyone can construct, express in JSON, or store: not by an admin, not by a plan, not by a support tool with database access. Making a state unrepresentable is stronger than validating it away, because there is no code path left where a bug could permit it.
There is no plan flag, allowance, overage, or spending-limit interaction that can reduce them. An account that has reached its spending limit stops dialing; it never keeps dialing with the floor off. What a paid tier buys here is advanced policy packs and audit exports, never safety itself, which is why the rate card is a separate question from the floor.
The axes
Each row is structural: what exists, who can reach it, and what is written down afterwards. Read the middle column as the answer you can give when your own leadership asks what stops a bad call from going out.
| Axis | A floor, as Vocapable ships it | An opt-in setting, by definition |
|---|---|---|
| Can it be switched off? | No. There is no value that expresses switching it off. | Yes. That is what makes it a setting. |
| Who can reach it? | No API field, no plan tier, no support tool, no spending limit. | Whoever the product hands the switch to. |
| Where is the boundary written? | In the type. A compliance mode may only name checks drawn from a waivable set, and these are not members of it. | Wherever the product wrote it down, and wherever it remembers to check. |
| What does it cost? | Nothing, on every plan. It is never metered and never paywalled. | Whatever it is priced at, because a setting is a thing that can be sold. |
| What is recorded when it runs? | Every attempt records what ran and which values bound the call. | Whatever that product chose to log. |
| What is recorded when it does not run? | It runs on every dial. Where a check is skipped, the skip is an election naming its attestation and its signer, never an absent check. | By definition, nothing. A setting that is off leaves no record of itself unless something else keeps one. |
| What happens at the spending limit? | The account stops dialing. It never keeps dialing with the floor off. | Nothing in the definition keeps the two from interacting. |
The third column is the definition of a setting. It names no vendor and reports no vendor’s terms, because a claim about somebody else’s product would have to be re-verified against their live page on the day you read this, and nothing on this site is published that way.
The record you keep
You keep the list arrangement you already trust and run it on your own contacts. Every production account signs one attestation naming that arrangement, the officer who signed it and the date, and the platform carries it from there.
Each stage that attestation covers rides into every call’s evidence file as your election, with the signer named beside it. That is a record an auditor can read months later without asking anybody a question. Checked and clear, checked and suppressed, and elected away under signature stay three different rows, and nothing in the file lets them look alike.
The same mechanism covers your paperwork gap. A check that is simply missing, with no election behind it, is a bug rather than a waiver: an account carrying no attestation for the stages it runs upstream screens its contacts undialable, with the missing document named, so a dial waits for a signature instead of going out on an unanswered question.
And you can check all of it before you spend anything. The whole agreement set, including your Telecom Compliance Addendum, is published on this site rather than described, so what you read here and what you sign are the same document.
The division
Alongside the floor, the platform applies quiet-hours windows, frequency caps, consent-basis standards and a recording-consent class at the gate, and records the values it evaluated on every attempt. You and your advisors decide what the law requires where you dial. What you get from us is the enforcement, plus the evidence of it, in a file you can produce yourself.
Those values are also the reason the floor names four things and stops. Quiet hours and frequency caps run on every dial too, and they are deliberately not floor controls: they are values, evaluated against a record, a clock and a counter, and a value is a different kind of thing from a control with no off state. Counting them in would make the list longer and less true. The mechanism behind all of it lives on the compliance engine page.
What these controls do is block the calls that must not happen and write down what bound the ones that did. That is the part of the job you stop paying people to remember, on every call, every day, whether or not anyone is watching the queue.
The trust close
Every dial attempt, including the ones the platform held back, produces an exportable record of which checks ran, which were elected away and on whose signature, and why the call was allowed or refused. A check that cannot complete blocks the call. Uncertainty never resolves in favour of dialing, and a stage that did not run is never recorded as a stage that found nothing.
Which is the shortest way to state the axis this page is built on. A record that cannot tell checked, clear, and nobody looked apart is a log rather than evidence. And a control that can be switched off has to be proven off-or-on for every call you are ever asked about, which is a question a settings history answers and a type system does not have to.
Tenant isolation is enforced by the database itself rather than by application code remembering to filter, and the service refuses to start if that isolation is misconfigured. The rest of the posture, control by control and duty by duty, is on the Trust Center.
No, and not because a policy forbids it. A tenant’s compliance mode can only name checks drawn from a waivable set, and these four are not members of it; the unwaivable stages are derived by set difference rather than listed, so they cannot be omitted by an edit. Waiving the disclosure opener is not a state anyone can construct, express in JSON, or store. That is stronger than a promise, because there is no code path left where a bug could permit it.
A file that was written on the day of the call, by the system that placed it. Every attempt your account made, including the ones the platform held back, carries its own policy snapshot: which checks ran, which were elected away and on whose signature, the consent record relied on with its content hash, the calling window and the attempt cap evaluated in the contact’s own local time, and the pinned agent version. It leaves as CSV through the exports API, filtered to the contact and the dates you were asked about. Nobody on your team has to remember anything.
Never, on any plan or class. The local floor stages are excluded from the metered lookups by construction rather than by a billing rule someone remembers to apply, so there is no configuration in which the floor is charged for or switched off to save money. An account that has reached its spending limit stops dialing; it never keeps dialing with the floor off.
A waived stage renders as an election: elected away under a stored attestation, with the officer who signed it named. A stage that found nothing renders as a check that ran and came back clear. Those are different rows and they are never allowed to look alike. A check that is simply missing, with no election behind it, is neither one: it is a bug rather than a waiver, and an account carrying no attestation for the stages it runs upstream screens its contacts undialable with the missing document named.
No. The platform applies the policy values in force (quiet-hours windows, frequency caps, consent-basis standards and the recording-consent class) and records the values it evaluated on every attempt. That is an enforcement mechanism, not a determination of what the law requires where you dial. Vocapable does not guarantee that any call is lawful.
Open a sandbox account and read the evidence from a run you set up yourself. The floor runs there exactly as it runs in production, and the elections render exactly as they would on a live account.