What happens to your documents

Where your information lives

The documents you upload are the whole product, so this is the first question to ask us.

• Your documents, your call records and your bookings sit in a database and a file store that run on one server we operate ourselves.

  The deployment file that runs production says so, and it is in the repo.

• The file you upload stays on that machine rather than in a third-party cloud file store, and it is indexed there.

  The upload path and the indexing model are both configured to addresses inside our own stack.

• That server is in Phoenix, Arizona, in the United States.

  Checked against the hosting provider and the address itself.

• Saying an answer out loud needs outside AI providers, so for each call the passage that answers the question is sent to them along with what the caller said — we send the passage, not the file.

  The request our code sends to the provider carries text we assembled, and nothing else.

• A database backup holding the text we extract and the records of past calls has been copied to a cloud provider for off-site keeping.

  A dated run log records the copy that was made.

• Traffic between you, us, and those providers travels over encrypted connections.

  Standard transport encryption, checked against the live site.

Who can see it

Two answers matter here: other customers, and us.

• Inside your account there are two roles, owner and member. There is no superadmin role and no impersonation feature.

  The role list is two values in the code, and there is no third.

• Every link the database holds between your documents, the chunks that index them, your campaigns, your contacts and their calls carries your organization inside the key itself, so a chunk cannot borrow another organization’s document.

  A database constraint, not a rule in application code that someone could forget.

• No account of any kind, including ours, can read another organization’s documents or calls.

  Proven by tests that run on every change, not by a policy document.

• One test plants a document in another organization’s account that is a better match for your caller’s question and proves your call does not receive it.

  A test that would fail if the scoping were removed — the only kind that counts.

• Another account asking for your documents or your calls gets a not-found, the same as if they never existed.

  A test on each part of the dashboard, all of them run on every change.

• We are a small company, and the people who operate the service can reach the server — running it requires that.

  Nothing enforces this one. It is the honest description of a product that has to read your documents to answer a call.

• The visitor statistics for this website run on our own server. They set no cookie and keep no IP address, and a visit is counted with a code that changes every month and cannot be turned back into a person.

  The analytics software runs in our own containers next to the database, is served from our own domain, and its retention job is in the repo.

What the assistant can and cannot do

The part of the system that talks to your callers is deliberately the part with the least reach.

• The assistant that speaks to your callers has no tools and no database access. It is handed a block of text from your documents plus the caller’s words, and it hands back words.

  The request we send the model has nowhere to put a database query, and the assistant we register with the phone provider is pinned by a test to a key list with no tools in it.

• Your documents are handed to it inside a fence marked with an unguessable tag, and it is instructed to read them for facts and never to act on instructions written inside them.

  A prompt-injection defence built into how the text is assembled, pinned by unit tests.

• It is instructed never to say it has taken a message, written something down, passed information along, or removed anyone from a call list — the scripted parts of the call do those things, and the model cannot.

  Two instructions in the prompt, pinned word-for-word by tests.

• It is instructed to say plainly that it is an automated assistant and that the call is recorded, and never to deny either — whatever an earlier line in the conversation says.

  An instruction that outranks anything a customer writes into a greeting or a campaign brief.

• Everaide never asks for card numbers or takes payment details on a call.

  There is nowhere in the call for a card number to go, and digit runs long enough to be a card are stripped from what we keep — the threshold sits above phone-number length, so the shortest card formats are not caught.

Calls we make on your behalf

The calling rules are enforced by the database, not by a setting somebody can forget.

These are the practices people usually ask about under the TCPA and state calling rules. They are how the product is built, not a certification.

• Every call we place opens with a line we own, not the campaign’s: it says the caller is an automated assistant and that the call may be recorded. The opening we write for campaigns also tells the person they can ask us to stop calling, and a campaign script cannot remove any of this. If a campaign’s own wording conflicts with it, we warn the author — the disclosure is still spoken first.

  The opening line is assembled by our code, recorded on the call, and checked afterwards.

• When someone asks us to stop calling, their number goes on a list every campaign in your account skips from then on. A database trigger blocks edits and deletes on that list through the product; the one exception is our own operator, who can reach the server — the same access we describe above. If someone phrases the request in a way our detector does not recognise, the call is flagged for a person to review and add the number by hand.

  A database trigger the product cannot get around, plus an hourly scan that puts anything the detector was unsure about in front of a person.

• The only contact information the dialer can read comes through one database view, and that view has already removed everyone who opted out, everyone outside their own local calling hours, and everyone we called too recently.

  The dialer has no permission to read the contact table at all — only the filtered view.

• Calling hours are bounded in the database between 8am and 8pm in the contact’s own time zone. A campaign can narrow that window; it cannot widen it.

  A constraint on the table, so a wider window cannot be saved in the first place.

• The same person is called at most three times in a campaign, never twice inside 24 hours, and no more than three times in 30 days across your whole account.

  Frequency caps written into the view the dialer reads, not into a setting.

• If an answering machine picks up, the default is to hang up and leave nothing. A campaign can choose to leave a fixed message we wrote instead — never one the AI composes on the spot — and that choice is recorded on the campaign and frozen once the campaign is approved.

  The column defaults to hanging up, the message is a template in our code rather than something generated per call, and the database refuses to change the choice after approval.

Deleting what you uploaded

Deleting works, and it does not reach everything. Both halves are here.

• An owner deletes a document and it goes out of the file store and out of the index that answers calls — no soft-delete.

  A real delete, checked by a test — not a hidden flag on the row.

• A document a campaign is attached to cannot be deleted while that attachment stands — the database refuses it, so a campaign never loses the papers it speaks from.

  A foreign key, so the delete cannot succeed even by accident.

• While the campaign is still a draft you can edit it, take the document off its list of sources, and then delete the document. Once the campaign is approved that list is frozen: every way the product offers to add, swap or remove a source on an approved campaign is refused by the database.

  The lock arrives with approval, which is also when the campaign becomes a compliance record.

• If the assistant read from that document during a call, that call’s record still shows what it said, and call records stay in your account.

  The transcript is a separate record, and deleting a document does not touch it.

• There is no self-serve control for that yet — email support@geteveraide.com and we will take the conversation out of that record for you, at no charge: the transcript, the summary, the phone numbers on the call record, the caller details on any booking it produced, and the stored event payloads that hold the same words. Two things stay: the call itself as a dated line, because your billing history counts it, and — on an outbound campaign call — the number we dialed, which the database freezes as part of our calling-compliance record and will not let us remove.

  A person does this by hand when you ask, following a written procedure.

• The provider that carries the calls keeps its own copy under its own terms, and our deletion does not reach it.

  A third party we do not control, disclosed rather than glossed over.

• A database backup taken before you deleted it still holds the text we extracted, and the records of calls that happened before it was taken. Every backup is now encrypted on our machine before it goes anywhere, including the copy kept off-site with a cloud provider: they hold the file, and not the key that opens it. None of them is reachable from the product. Nothing rotates that key yet, and we do not promise a date by which a backup itself is gone — we would rather say both plainly than imply a schedule we have not built.

  The September 2026 backup review: encrypted dumps, a recount that found no unencrypted copy left on the machine, a restore exercised and recorded every week, and key rotation written down as not yet rehearsed.

What we do not claim

The list a vendor leaves out is the one worth reading.

• The files you upload are no longer sitting readable on that disk: a stolen copy of the volume does not contain them. The database on the same machine is still sitting readable. We would rather name that than imply the whole server is locked.

  A production disk check: the file comes back through the API and is absent from the volume.

• Live call content follows your organization’s retention window, with automatic scheduled purging after 360 days by default or a shorter configured window. Backups, supplier copies and limited billing or compliance records follow separate schedules and exceptions described in our Privacy Notice.

  The published Privacy Notice describes retention by data category.

• The company that carries our calls has a written data-processing agreement with us now, accepted on 15 September 2026, and has told us in writing that it does not use call audio, transcripts or metadata to train its models. It is narrower than it sounds: their terms still let them learn from what a call leaves behind once it no longer points at the person who made it, it is their standard agreement rather than one written for us, and no lawyer has yet read it against our particular account. So there is a commitment in writing where there was none, and we are not going to stretch it into a promise that nothing from your calls ever reaches a model.

  The agreement itself — their revision of 29 August 2025, accepted 15 September 2026 — kept privately with its checksum, and the published terms it sits alongside.

• We hold no security certification, and no outside firm has reviewed this system.

  There is no certificate, and we do not imply one with vocabulary.

• We assess requests for data rather than treating every informal request as legal compulsion. Where permitted, we notify affected customers of legally compelled disclosure and provide only information responsive to a valid requirement.

  The published Privacy Notice describes how we handle legally required disclosures.