Confidentiality
Your material, and what actually happens to it.
Written from how the system is built, including the parts most policies leave out: what we can see, and what stops working when we do.
01
What this covers, and what it doesn't
This page is about the work: what happens to your business's own material once it's inside a system Todreamalife, LLC builds for you. The separate privacy page covers this website (form submissions, analytics, cookies), and the two don't overlap.
If there's a signed agreement between us, it governs. This page explains how the system is actually put together, which is the part an agreement usually asserts without showing.
02
Your system is its own system
Every client gets their own databases and their own document folder. Not a shared database with a column naming the client. Separate bases, with separate identifiers, reached through separate credentials.
That's a structural boundary rather than a policy one. There's no query anyone here could write that returns your records alongside another client's, because they aren't in the same place to be joined. When we add a capability, it reaches every client's system; the contents never meet.
The same split runs inside your own setup if you take both arms of the service. Work and personal are separate systems that can't read each other, which is the point of having two.
03
Nothing you give us trains anything
We don't train models. We don't fine-tune on your material, we don't pool it into a shared corpus, and we don't use one client's material to improve another's system. What gets better across clients is the software and the method, never the content.
Your assistant runs in your own account with the AI provider, under your agreement with them, not ours. That's deliberate: it means your conversations are yours, they aren't routed through us, and we're not sitting in the middle of them.
04
What we can actually see, honestly
We built your system, so we can reach the databases and documents inside it. Pretending otherwise would be false. What's true is that we don't read them as a matter of course, and there's no dashboard here showing us your day.
Three things do reach us by design, and you should know about all three. If you report a problem with the tool, the report comes to us, because that's how it gets fixed. If your system flags something as a possible fault, that record comes to us too. And anything you or your team explicitly send us for review arrives here rather than staying with you.
Everything else stays where it is. When your assistant looks something up for you, the answer is assembled in your account and shown to you; it doesn't travel here on the way.
There's a stricter version available if you'd rather: you hold the credential to your own data yourself, and we get no standing access at all. It costs a few more steps at setup and it means we can't diagnose a problem without you handing us access for the occasion. Some businesses want that trade and some don't. Ask, and we'll set it up whichever way you choose.
05
What stops your name appearing somewhere it shouldn't
Two guards, and both refuse rather than warn.
The first strips our own internal identifiers (database ids, file references, our session numbers, other clients' names) out of anything your assistant is about to show you. It runs on the way out, every time, and it matches credentials before anything else so a key can never be half-redacted and published.
The second refuses to WRITE a document into your folder if it mentions another client, our own company, or an internal reference. It fails the write and names the line rather than letting it through with a note. It caught a real mistake the first time it ran, which is the only reason we trust it. A guard nobody has watched refuse anything is decoration.
06
Who at our end can reach it
A small team, and access is granted per person per system rather than to everyone by default. Staff working on your engagement can reach your system; staff who aren't, can't.
Anyone we bring in is under the same obligation we are. If a contractor ever needs access to your material, we'll tell you before it happens rather than after.
07
Turning it off
Access is a switch, not a deployment. Your system's access can be cut in under a minute, and it takes effect for every credential at once, including ones already issued and not yet expired. We test that switch in both directions rather than assuming it works, because a cut-off that's never been exercised is a promise, not a control.
Credentials expire on their own as well. They're scoped to one system and one purpose, so a credential for your setup can't be pointed at anyone else's even by mistake.
08
When the engagement ends
You keep what we built. The databases, the documents and everything recorded in them are yours, in your own accounts, and they don't stop working when we stop. The memory of how your business does things is the asset, and it isn't rented.
What ends is the ongoing service: the improvements, the new automations, the person on the other end of a question. Those are what the recurring fee pays for and they're deliberately separate from the thing you keep.
There's one case where that's different, and it's worth being plain about it before you start rather than after. A pilot is priced well below what it costs to build, because the build is how we earn the engagement. If it doesn't become one, the pilot doesn't stay. Everything that was already yours stays yours, your files, your documents, your own accounts, and we remove the layer we built on top of them. Nothing of yours is taken. What ends is the discounted build, and that's the trade the discount was.
One honest caveat, because it's easy to get wrong. Anything running on OUR credentials, such as a scheduled job that reaches an outside service on your behalf, stops when our credential does. Your own tools and your own data carry on; a pipeline we were operating for you doesn't. We'll tell you which is which before the engagement ends, in writing, so nothing goes quiet without warning.
Ask us to delete our copies of your material and we'll do it, then confirm when it's done.
09
The services underneath
Your system is built on services you hold accounts with, in your own name: a database, a document store, and an AI provider. We build inside them rather than in front of them, so you're never locked out of your own material and you're never waiting on us to export it.
Where we run something on our own infrastructure, such as the connector your assistant talks to, it's hosting and delivery only. Those providers process on our instruction and don't get your material for their own purposes.
10
If something goes wrong
If your material is exposed or reached by someone who shouldn't have, we'll tell you. Promptly, with what we know, what we don't yet know, and what we're doing about it, not a polished summary weeks later.
Our systems record faults and unusual access to a log we keep separately from the systems themselves, so an incident can be reconstructed rather than guessed at.
11
Changes to this page
If how we handle any of this changes materially, this page changes first and the date at the top changes with it. Questions go to info@runonchip.com or 650-855-2716, and a person answers them.