Your clients’ books are
isolated by design
Everything below describes the system as it actually runs, checked against it rather than intended. Where something is policy rather than a shipped mechanism, we say so.
The agent cannot
name another business
Most AI systems keep tenants apart by telling the model which business it is working for, and trusting it to stay there. That is a rule, and a rule can be argued with. A carefully written message can talk a model out of a rule.
CaribBooks does it differently. The identity of the business is not something the agent is told. It is bound by the system, from the phone number the message arrived on, before the agent runs at all. There is no field, no parameter and no phrasing through which it can ask for another business’s ledger, because no such input exists.
It is not a rule the agent follows. It is a capability it was never given.
One business, one enclosure
Every business sits in its own partition, reached by its own authorised numbers. Nothing crosses between them, because there is no line to cross on.
A practice sees its own client list from the dashboard. The agent working inside any one of those clients has no view of the others and no way to ask for one.
A message arrives
WhatsApp, inbound
a phone number
The number is looked up
against the authorised senders
a business
The business is bound
resolved by the system
fixed for the whole turn
Everything above this rule happens before the model is invoked.
The agent runs
it cannot change it, name another, or ask
one business, and only that one
Every record CaribBooks holds is partitioned by business. Reaching another business’s data is not a filter someone could forget to apply. It is a different partition, and nothing in the agent’s vocabulary points at it.
A posted transaction cannot be deleted by the agent either. To undo one it posts a reversing entry, so the original stays in the ledger and the audit trail survives the correction.
Encryption, residency
and access
Three questions every practice asks, answered with specifics rather than adjectives.
Encrypted, both ways
AES-256 at rest across every database and file store. TLS 1.2 and 1.3 in transit, with no plaintext path anywhere in the chain. Requests over plain HTTP are refused rather than upgraded.
Named jurisdictions
The books sit with Amazon Web Services in the United States. WhatsApp message content sits with Unipile in France, inside the European Union, under the GDPR. No Caribbean provider offers a local region, so we name the real ones.
No password to steal
Sign-in is a one-time code to a verified address; no password exists to be reused or leaked. Access is scoped by role, and a staff seat at a practice cannot delete a client's history.
The Jamaica Data
Protection Act
The Act sets eight standards every data controller must meet. Below is each one against the mechanism in our products that satisfies it. We have written mechanisms rather than assurances, because a mechanism can be checked.
This applies across everything we build. CaribBooks isolates by partition, because it is one system serving many businesses. An Automations system is built for a single business, so there is no second business inside it to reach. The standards are the same either way; only the mechanism differs.
Processed fairly and lawfully
We process on the basis of the contract with you, and on your practice's documented instructions where we act as processor. We do not repurpose your data, and we do not sell it.
Obtained for specified, lawful purposes
CaribBooks exists to record transactions and produce reports. Data collected for that is not used for anything else, and a practice's client data is never used to improve our products.
Adequate, relevant and not excessive
We hold what a set of books requires: the transaction, its evidence, the accounts it touches. We ask for no demographic data, and CaribBooks is not designed to receive special category data.
Accurate and kept up to date
Entries are proposed and confirmed rather than assumed. When CaribBooks is unsure it asks, and it names the account it would add rather than guessing. Corrections post as reversing entries, so the record shows both the error and the fix.
Not kept longer than necessary
A published retention schedule: message history 24 months, reasoning records 90 days, server logs 30 days. The accounting record is held for the statutory period because the law requires it of you.
Processed in accordance with the rights of data subjects
Access, correction, erasure, restriction, portability and objection, answered within 30 days. Erasure covers message history, learned facts and reminders; the statutory accounting record is exempt, as the Act allows.
Appropriate technical and organisational measures
AES-256 at rest, TLS 1.2 and 1.3 in transit, no plaintext path anywhere. Passwordless sign-in, role-scoped access, and tenant isolation the agent cannot address around. Backups with 35-day recovery and deletion protection on every table.
Not transferred without adequate protection
Named jurisdictions rather than vagueness: the books in AWS United States, message content in the European Union with Unipile under the GDPR. Each transfer under contractual safeguards, and a data processing agreement for practices that need one.
One standard,
every island
The region does not have one data protection law, it has many, at different stages of force. Rather than build a different posture for each, we hold every business to the strictest standard that applies to any of them, and meet the local instrument where it asks for more.
Serving somewhere not listed? Tell us and we will confirm the position before you onboard a single client.
Ask us
anything
Practices reviewing us for their own compliance file can have a data processing agreement, the full retention schedule, and a written answer to anything here. We would rather answer a hard question than have it go unasked.