Privacy policy

The short version

Spotbo, Inc., operating Jiclo within VCorp, holds your email, your name, your phone number, the addresses you buy for, your conversations with the assistant, the files you give it and the record of every purchase and every charge.

We do not sell any of it, we run no analytics and no advertising trackers, and there is a single cookie on the whole product: the one that keeps you logged in.

What we do is send parts of it to the companies that actually do the work: a model provider to answer you, a retailer to ship a parcel, a hotel platform to book a room, a payment company to take money, a messaging company to text you a code. Section five names every one of them.

The two answers below that people usually expect to be reassuring, and that are not, are in sections ten and eleven. Please read those two.

What we collect

What you give us

• Your account. Name, email address and a password, which we store only as a scrypt hash and never in a form we can read back.
• Your phone number, kept in full international form, together with when it was verified, which channel verified it, and whether your carrier says it is a mobile, a landline or an internet line.
• Addresses and recipients. For you, and for every person you have us ship to or book for: first name, last name, street, city, state, postal code, country, phone number and email.
• Your conversations. Every message, in full, along with what the assistant did in response: which tool it called, what arguments it used and what came back. That last part matters, because the text of a web page it read, the contents of an email in a connected account and the extracted text of a file all land in the transcript.
• Files you upload. The bytes, the filename, the type, a checksum, and what we work out about it: a short summary, a classification, the beginning of its text, and a thumbnail where one can be made.
• What you say out loud, at the moment you record it. See the note on audio at the end of this section.

What we record as you use it

• Orders, quotes and money. What you priced, what you bought, what it cost, what the supplier said about it afterwards, and every entry in the ledger behind your balance. The supplier's own status messages are stored as they arrive.
• A line per billable call. Every time the product spends money on your behalf, on a model, a search, a scrape or a text message, a row records which provider, which model or tool, which conversation, and what it cost.
• Sessions. When you log in we store a hash of your session token, the time, and a truncated copy of your browser's user-agent string. We do not store your IP address against your session.
• One IP address, for one purpose. When you ask for a verification code we record the IP address that asked, and it exists only to stop one machine requesting codes for hundreds of numbers. See section ten for how long it stays, because the honest answer is not the one we would like.
• Connected-app events. If you connect an app and set up a trigger, the event that fires it arrives as a payload from that app and we store it.

Audio, which is the one thing we do not keep

When you use the microphone, the recording is held in memory for the length of one request and dropped. It is not written to a database, not written to disk, and not kept anywhere afterwards. Even the filename your browser attached is removed before it is sent. What survives is the text, in the composer, where you can edit it before you send it.

Dictation is switched off on this deployment, and section eight says why: the transcription endpoint cannot be told to keep your words out of a training set, so the recording is refused here rather than sent without that instruction. Pressing the microphone gives you a failure rather than a transcript.

Your phone number, and the texts

When you enter your phone number and ask for a code, you consent to receive a single text message containing a one-time verification code for that request. The tick box on that screen is a separate agreement, to three kinds of message and to nothing else: a verification code when you ask for one, a reply when you text Jiclo, and the result of an errand you asked for, including one you started by phone. Message and data rates may apply. Reply HELP for help, reply STOP to opt out.

Today the code is the only one of the three that actually leaves. Jiclo has no number of its own to send from yet and the carrier registration that would give it one is not finished, so texting Jiclo gets no answer back and the result of an errand waits on your screen instead. The other two are agreed to now rather than asked for again later, and the date at the top of this page changes when they are switched on.

We do not sell or share your SMS opt-in data or personal information with third parties for marketing purposes.

Your number goes to Twilio, which sends the message and holds the code itself. We do not store the code: Twilio owns it, its expiry and its attempt counting, so there is no second copy of a live code in our database to leak. We do keep our own limits on how often a number, an account or a machine may ask.

When the reply is switched on, Twilio carries what you text in and what Jiclo texts back, and a message you send that way is answered by the assistant. That means it becomes part of a conversation, is stored like any other message, and goes to the model provider on the next step. Section eight is about what that means.

We also ask Twilio what kind of line the number is, because a landline cannot receive the message and it is better to say so than to charge for a text nobody gets. We keep that answer with the verification record.

A verified number is required before Jiclo can spend anything on your behalf. It is not used to log you in on its own, it is not shared with suppliers except where a booking needs a contact number, and it is not a marketing list.

What we do with it

• To run the assistant. Answering you means sending the conversation to a model. Reading a file means extracting its text. Looking at a picture means sending the picture.
• To buy the thing. A parcel needs a name, a street and a phone number at the supplier. A room needs a name, an email and a phone number at the hotel platform.
• To take money and give it back. Payments and refunds go through Stripe, against the record in our ledger.
• To keep the product from being abused. Verification limits, spend ceilings, and looking at patterns that suggest an account is being used for fraud.
• To know what things cost. The per-call record is how we price a plan, how we answer "why was I charged this", and how a dispute is settled against something written down at the time rather than reconstructed afterwards.
• To answer you when you write to us.

We do not use any of it for advertising, we do not build profiles for anybody else, and we do not make automated decisions about you that have a legal effect. Deciding whether an account may spend is a human decision here today.

Every company that receives your data, by name

This is the whole list as the product stands today. If we add one, this section gains a line and the date at the top of the page changes.

Resend ? support email

Delivers account support requests to [email protected]. Receives your message, account email, account identifier and request reference. We store a message hash and delivery status for duplicate prevention and abuse limits; Resend and our support inbox hold the message itself.

Stripe · payments

Takes your payment and returns your refunds. Receives the amount, your account identifier and your email address. Holds your card details itself: see section six.

Twilio · the text messages

Receives your phone number, sends the one-time code, and tells us what kind of line it is. That is all it carries today. When the texts described in section three are switched on, it also carries what you text to Jiclo and what Jiclo texts back.

OpenRouter · the model

Every model call goes through OpenRouter, which routes it to the model you or we selected. It receives your conversation, the text of files the assistant reads, pictures it opens and results returned by connected apps. Audio you record is the one thing it does not receive, for the reason in section eight. Section eight is also about what the rest of it means.

Zinc · buying goods

Receives the product, the quantity, a price ceiling and the full shipping address: first name, last name, street, city, state, postal code, country and phone number. It does not receive an email address, and it does not receive your conversation.

LiteAPI · booking stays

Receives the booking holder's first name, last name, email and phone, and the same for each named guest, plus any remark attached to a guest. Searching for a room sends dates and occupancy and nothing personal.

Decodo · searching and reading the web

Receives the search text, which is derived from what you asked for, and the addresses of pages to read. It does not receive your name, your account or your conversation.

Composio · connected accounts

Holds the connection to any app you connect and runs the actions against it. It receives an opaque identifier for your account rather than your name or email, and it receives the arguments of every action the assistant runs, which for a draft email is the recipient and the text. See section seven, including the part about it being a shared instance.

OpenStreetMap · turning an address into a place

When an address needs to be located on a map, the address text is sent to the OpenStreetMap Nominatim service.

One more is written and not switched on, and it is named here because section three mentions an errand you started by phone. The phone surface is built on ElevenLabs, which would hear the call and receive what you say on it. The dedicated number is configured for launch testing. Public phone execution remains disabled until acceptance is complete. When enabled, ElevenLabs receives call audio for processing and a transcript; audio recording is disabled and transcript retention is limited to seven days.

Beyond that list: our own hosting, and nobody else. We may also disclose data where the law requires it, and if Jiclo were ever bought or merged the data would move with the business, in which case this page would say so before it happened.

Your card, and who holds it

Jiclo never sees your card number. Paying happens on a page Stripe hosts, the card details go to Stripe, and what comes back to us is an identifier for the payment, the amount, the fee and whether it settled. There is no card number, no expiry and no security code anywhere in our systems, and no screen in the product asks for one.

Stripe is the processor and it applies its own privacy policy to what it holds. We keep the payment identifier because a refund can only go back to the payment it came from, and that identifier is how we send it there.

Where your money sits between paying and spending is a question about custody rather than privacy, and the terms of service answer it plainly in the section on balances. It is worth reading.

Connected accounts

You can connect apps such as Gmail, Google Calendar, Google Drive, Google Sheets, Slack, Notion, Outlook and Todoist, and the assistant can then read and act in them. The connection is made on the app's own consent screen and the access it grants is the access you agree to there.

Two things about this are worth knowing before you connect anything.

Anything the assistant reads out of a connected app becomes part of the conversation, which means it is stored with the conversation and goes to the model provider on the next step. An email pulled in to be summarised is an email that has been sent to a model.

Actions that change something in a connected app are proposed and wait for you to press. You can disconnect an app at any time from settings, which removes the connection at the platform. It does not remove what has already been read into a conversation.

Models, and whether your words train them

Every model call leaves through one door and goes to OpenRouter, which routes it to whichever model is selected for your account. There is one header on that request naming the product, and nothing in it identifies you: no name, no email, no account id.

The rest of what we control we have done. Audio is never stored. A picture is sent only at the moment the assistant actually opens it, never when you upload it, and what the model says about it is kept with the file so the same picture is not sent twice. And when a model call fails we deliberately do not log the error body, because a provider's error message can echo the request back, and the request has your transcript in it.

None of that is a reason to treat a conversation here as private in the way a notebook is private. It is stored, it is readable by us, and it passes through two companies on its way to an answer. It is still not the place for a password, a medical record or somebody else's secret.

Jiclo does not train models on your data. We have no training pipeline, no dataset and nothing that reads your conversations in bulk.

Cookies and tracking

There is one cookie. It is called beciel_session, it holds a random token that keeps you logged in, it cannot be read by scripts, it is sent only to us, and it lasts thirty days. The database stores a hash of it rather than the value, so the cookie in your browser is the only copy.

There is no analytics, no tag manager, no advertising pixel, no session recorder and no error-reporting service. We are not being coy about a list: there is no third party script on the product at all. That is also why you have not been shown a cookie banner. Preferences like which view you last used are kept in your account rather than in a cookie.

One exception worth naming: the logos of connectable apps are loaded from the connection platform's own image service, so your browser makes a request there when you open the integrations screen.

How long we keep things

The honest summary is that most of it is kept until you or we remove it, and some of it cannot be removed at all. Here is the detail, including the parts we are not happy with.

• Conversations. Kept until you delete the conversation. Deleting one removes its messages with it, permanently.
• Files. Deleting a file removes it from your library. The bytes stay on our server: nothing in the product unlinks the stored blob, and the space still counts against your quota. That is a gap, we know it is a gap, and until it is closed a deleted file is hidden rather than gone.
• Addresses and recipients. Kept indefinitely. A one-off recipient stops appearing in the picker but the row stays, because an order has to remain traceable to where it was sent.
• Verification records, including the IP address. Kept. These should be swept daily and the sweep has not been built. It is written down as a defect in our own code and it is one of the first things on the list.
• Sessions. Expire after thirty days and can be revoked by you from settings at any time. Expired rows are not currently purged automatically.
• Connected-app event payloads. Emptied after thirty days by a job that runs every five minutes. The row that the event happened survives; its contents do not.
• Orders, ledger entries and the per-call cost record. Kept permanently. See the next section for why this one is not a choice.

Deleting your account, and what survives it

When we remove an account we can remove your login, your conversations, your files from the library, your addresses and recipients, your connected-app connections and your sessions.

We cannot remove the financial record, and that is architectural rather than a policy we chose to defend. The ledger is double-entry and append-only. There is no update in place and no delete: a correction is a new, balanced transaction that reverses an old one, and every entry has to sum with its siblings to nothing or the database refuses the write. Order history, the per-call cost record and the subscription usage record work the same way, deliberately, because a row that can be rewritten is a row that cannot answer a dispute.

So what survives a deletion is the money: what was added, what was spent, what it was spent on, what it cost and when. We keep it because we are required to keep financial records and because it is the only thing that can settle a disagreement about your money later. What it will no longer be attached to is a working account, a login or a conversation.

A privacy policy that said "we will erase everything" would be a sentence our own schema forbids. We would rather tell you exactly what stays.

People who are not our users

If you have Jiclo ship to somebody else or book a room in somebody else's name, we end up holding that person's name, address, phone number and email. They never signed up, never agreed to anything and cannot log in to see or correct it.

We hold it for you, on your instruction, to complete the thing you asked for. The relationship with that person is yours: you are the one who is supposed to have told them, and the terms of service say so. There is no expiry on those rows today and no self-service way to remove one.

If you are one of those people and you have found this page, write to [email protected]. We will tell you what we hold and remove what an order does not depend on.

Why we are allowed to hold it, and what you can ask for

Jiclo serves accounts in the United States. If you are in the United Kingdom or the European Economic Area, these are the bases we rely on.

• To perform our contract with you: your account, your addresses, your orders, your balance and the conversations that produce them. Without these the product cannot do the thing you asked it to do.
• Your consent: the verification text message, the other two kinds of text named in section three, and each connected app, all given at a screen and all withdrawable. Withdrawing consent for the texts means we can no longer verify a number, and a verified number gates spending.
• Our legitimate interests: keeping the product from being abused, enforcing the verification and spending limits, and holding the per-call cost record so a charge can be explained.
• A legal obligation: keeping financial records.

You can ask us for a copy of what we hold, ask us to correct it, ask us to delete it, ask us to restrict or object to a use, and ask us to send it to somebody else. Every one of those is handled by a person at [email protected], because none of them has a self-service route yet. We answer within thirty days.

Two limits, stated here rather than discovered later: a deletion cannot reach the financial record, for the reasons in section eleven, and a copy of your data is assembled by hand, so it will be a real export rather than an instant download.

Security

Passwords are stored as scrypt hashes. Session tokens are random, stored as hashes, and the cookie holding one cannot be read by a script. Your card details never reach us. Verification codes are held by Twilio rather than by us, so there is no table of live codes here to steal. Every action that spends money is checked on the server, and the ceilings that matter are checked inside the transaction that places the order rather than on the screen that starts it.

None of that makes us secure. It makes us careful about specific things. Jiclo is early software run by a small team and you should size what you keep here accordingly.

Children

Jiclo is not for anyone under 18 and we do not knowingly collect anything about a child. If you believe a child has an account, write to us and we will remove it.

Changes to this policy

When this changes, the version and the date at the top change with it. As with the terms, we have no way to notify you: the product sends no email and no push notification, and the texts you agreed to answer you or report an errand rather than announce a change to a document, so this page and its date are the notice.

A change that widens what we do with data already collected would need a reason we are willing to write down here, and we will write it down here.

How to reach us

Everything on this page, including a request to see, correct or delete what we hold, goes to [email protected], and a person answers it.