Two documents govern using MADDOX: the privacy policy, which is about personal data, and the terms of service, which is about the agreement. Both are linked below. This page describes what each one covers and what is true of the software underneath them today, so that a reader who needs an answer before the documents are final has somewhere to get one.
The documents
- Privacy policy — what personal data MADDOX collects, why it is held, how long for, and how to have it exported or erased.
- Terms of service — what is being provided, to whom, on what basis, what the platform may be used for, and what happens to your data when the agreement ends.
What this page is, and what it is not
It is an index and a description. It is not a summary of the documents it links to, because summarising a contract is how a reader ends up relying on the summary; when the final text lands, the documents themselves are what govern. Where the two ever disagree, the documents win and this page is wrong.
Nothing here sets a governing law, a liability position, a warranty, a notice period or a retention figure. Those are terms, they are counsel’s to write, and a marketing page inventing one is worse than a marketing page that says nothing. What follows instead is a description of how the software behaves today, which is a different kind of statement and one we can be held to on the evidence.
What is already true of the software
These are properties of the platform as built rather than commitments in a document, and they are here because they are the questions people ask before the documents are ready.
Where your data sits
Every record carries the workspace it belongs to, and that filter is applied by the model on every read and every write rather than being added by each query. A workspace is the boundary; nothing crosses it by default and the paths that legitimately run without a signed-in user state their workspace explicitly instead of inheriting one.
Consent, per contact and per channel
Consent is recorded against a contact for a specific channel and a specific purpose, with its source, the time it was given and the time it was withdrawn. Withdrawal is a state on the record rather than a deleted row, which is what makes it possible to answer when somebody opted out rather than only whether they are opted out now. Cookie consent on the marketing surface is configured and recorded separately.
Retention, and the thing that is deliberately not retained
Retention is policy-driven and set per workspace. A call-audio retention policy stays inert until both a switch is on and a window is set — deleting permanently is not something a half-finished settings page should be able to start. Uploaded meeting and coaching recordings are different: their files are removed by default once transcribed and thirty days old, keeping the transcript, unless an administrator switches that off. Call audio is deliberately transient: once a recording has produced a transcript, or has been examined and found to contain nothing assessable, the audio is deleted and everything derived from it is kept.
Export and erasure
A data-subject request is a first-class object with a type, a due date and a completion state, not a support ticket and a hand-written query. A contact’s data can be exported in full, and erasure is recorded on the audit trail like any other change. Erasure is also on the short list of domains that neither the assistant nor a support operator working inside your workspace may ever perform, on any subscription level and under any role.
Reporting something, or asking about it
Questions about personal data, suspected vulnerabilities, and anything else — including a question about the terms before they are final — go through the request form; say what it is about in the message and it reaches a person. For a vulnerability, tell us what you did and what you saw, and we will confirm receipt and tell you what we are doing about it.
The security page describes the controls in more depth: how customer data is held.