LAST UPDATED 3 SEPTEMBER 2026 · BETA
cavicom.ai is an engineering assistant. This page says what it stores, what it sends elsewhere, and what you can switch off. It is short because the service does few things with your data, not because detail has been left out.
An email address and a hashed password, plus the subscription tier attached to them. Passwords are hashed with bcrypt and are never stored or logged in a readable form. Signing in sets a session cookie; there is no advertising, tracking, or third-party analytics on this site.
Projects you save are stored against your account: the blocks, the wiring between them, the layout, and the name you gave it. They are visible to you and to nobody else using the service. Nothing is published, shared, or used to answer anybody else's question.
Messages you send to the assistant leave your browser for cavicomdb.com, the service that holds your account, and are forwarded from there to DeepSeek, which runs the language model that answers them. They are subject to DeepSeek's handling as well as ours. Send nothing to the assistant you would not send to a third-party API.
That first step changed on 1 September 2026. Messages used to go to a small function on this site before reaching DeepSeek; they now go to cavicomdb, which is the same service this site already uses for your account and your saved projects. What reaches DeepSeek is unchanged, and so is what is kept: the conversation is not stored. It lives in the page, and closing the tab ends it. If you are signed in, your session cookie travels with the request so the service knows which account is asking — it is not attached to the message, and no conversation is written to the database.
When catalogue components are switched on, the canvas can draw a real product — its block, its ports and their labels — instead of one of its nine built-in types. To do that it asks cavicomdb.com for that product by its catalogue id. What leaves your browser is the id and nothing else: not your drawing, not the rest of the canvas, and not your conversation. The request only reads. Nothing about you is written by it.
How that request identifies itself depends on whether you are signed in. If you are, it carries the same session cookie it already sends for your account. If you are not, the canvas first asks the service for a short-lived anonymous token and presents that instead. The request that asks for the token deliberately sends no cookie, the token is tied to nothing but itself, and it is never written to storage — it lives in the page, and closing the tab discards it. It exists so that the canvas draws for a first-time visitor without the service being told who they are.
Answering your question can involve the catalogue as well: before the assistant replies, cavicomdb looks up products matching what you asked so it can offer them. That reads the message you had already sent it and sends nothing further from your browser.
When that lookup finds nothing — you asked about a kind of equipment we hold none of, or about a product whose ports nobody has catalogued yet — we keep a count of what was missing, so the catalogue can be filled where people actually need it. A record holds the catalogue words the lookup matched, such as a brand or a connector type, together with how many times that gap has been reached. Those words come from our own product list rather than from your message: the message itself is not stored, and neither is its length nor a fingerprint of it, nor anything identifying you or your session. There is no row per question — only a running total per gap — so there is nothing from which a conversation could be pieced back together. Like the failure log below, it holds no content at all.
What it is. When you correct something the assistant produced on the canvas — move a block it placed, delete one it added, change a value it generated — we record that correction: what it suggested, what you changed it to, which part of the canvas you were in, and which model tier answered. It is how the assistant stops making the same mistake.
What a record contains:
node.gps1.positionWhat a record does not contain: your name, your email, your account id, or your IP address. The write is not authenticated — it does not send your session cookie — so nothing about who was signed in when a correction was made is recorded, and a correction made on a canvas you have never saved is tied to nothing at all. Records are stored to improve the assistant and are not sold, shared, or used for any other purpose.
Two honest caveats. The first is the project id in the list above. A saved project belongs to your account, so a correction carrying one can be traced back to you through it. Nothing in the record names you, but it is not anonymous either, and until 3 September 2026 this page said it was — that was wrong, and this paragraph replaces it. The second is the snapshot, which is drawn from your design: if a block is named after a client or a site, that name is in the record. The switch below turns both off together, which is exactly why it exists.
Open Save project on the canvas and tick “Exclude this project from improvement logging”. It takes effect immediately — not when you next save — and from that moment nothing about that project leaves your browser: no block names, no spec detail, no record that an edit happened at all. The setting is stored with the project, so it stays off every time you open it.
Use it for anything under NDA. The demo build is excluded the same way and always has been.
Logging is on by default for other projects. If you would like records that have already been collected from a project of yours removed, ask us and we will delete them.
What it is. When the assistant fails — the model is unreachable, an answer comes back empty, a request is refused for being too frequent — we record that it happened. Only that. It is how we find out something is broken, instead of waiting for somebody to mention it.
What a record contains:
empty_completionWhat a record does not contain: nothing you typed, nothing the assistant wrote, and no part of the instructions it runs on. No name, no email, no account id, no IP address, no session identifier. This is not a narrower version of the improvement log — it holds no content at all. The fields above are the only ones that can be stored, and the code enforces that by listing them rather than by filtering out what it recognises as personal, so a field nobody thought of cannot arrive by accident.
No cookie is sent with the write, so a failure cannot be tied to your account after the fact, in the same way and for the same reason as the improvement log above. There is no switch for this one, because there is nothing in it that belongs to you.
Correction records and account data are reachable only by an administrator signed in with an admin session — not by other users, not by an API key, and not by anyone without that session. Every read of the correction queue is logged with the account that made it, the time, and the address it came from, so access can be reviewed afterwards.
Data is held in a managed PostgreSQL database in London (DigitalOcean) and is encrypted in transit. Accounts and projects are kept until you delete them or ask us to close your account. Correction records are kept while they are still useful for improving the assistant; access logs are kept as a security record.
Write to [email protected]. This is a beta service and we answer these by hand.
If what we log changes, this page changes with it, and the date at the top moves. It is versioned alongside the code that does the logging rather than written once and left.