Emaration.AIWhen Emaration runs an audit or an ongoing engagement, a small set of well-known vendors help us do the work. This page lists each one, what they do for us, what client data they could see, and where they sit. It is our canonical list, and the commitments below are the ones we make on this page.
Last updated: September 6, 2026 · Change notice: 30 days in advance, by email.
What "sub-processor" means. You (the client) decide what data is collected and why; we process it on your instructions. A sub-processor is any third party we use to help us do that: a cloud platform, an AI vendor, an analytics tool. We engage each one under the published data-protection terms linked in its card, and we hold sub-processors to obligations no less protective than the ones we owe you. These are commitments we make here, on this page, in our own name — we do not have a signed data processing addendum to point you at, and we would rather say that than borrow authority from a document you have never seen.
What we have and have not verified. The vendors, the code paths, and the data each one receives are read off our own source and re-checked by an automated gate against our internal register. Two things on this page are not independently verified, and we would rather say so than let the format imply otherwise: the policy links point at each vendor's published agreement, but we have not re-confirmed that every linked version is the current one; and the locations are the regions those vendors document, not a data-residency commitment we are making to you. If either matters to your decision, ask and we will get you the confirmed answer rather than a link.
The platforms our product runs on: edge compute, the database of record, payments, transactional email, and business email.
The core platform Emaration.AI runs on: Workers (compute + server rendering), D1, KV, Queues, Vectorize, and R2 (storage), Cloudflare Access (operator authentication), Workers AI (site concierge), plus DNS, registrar, and email routing and sending for emaration.ai.
Serverless Postgres — our database of record for the CRM: client accounts, intake responses, contacts, and the AI usage ledger. Two independent gates scope each client to its own data. The member portal connects to Postgres as a restricted, non-owner role, so for its ordinary reads the database itself enforces row-level security. The application layer filters by tenant again on top of it. Both fail closed — with no tenant in context, those reads return nothing rather than everything. The exception, stated plainly: signing in has to find your account before it knows who you are. So sign-in-link and login-by-email lookups run through a small set of fixed, owner-owned database functions that are exempt from row-level security by design. The keyed ones take an exact token or client id and each carries its own tenant check, so a signed-in session can never reach another tenant through them. list_clients() is the other path: an unkeyed pre-auth scan with an empty argument list, used so the members portal can look up an account before any tenant is known. Email matching happens afterward in findMemberByEmail — the function itself is not keyed by email.
Membership billing and the $1,500 website tool.
Bookkeeping and invoicing for paid engagements, reconciled against Stripe. The invoice push is credential-gated: with no QuickBooks connection configured, the code renders a "not connected" state and sends nothing.
Delivers the emails our product sends: sign-in links, onboarding links, audit-report notifications, and account email. Resend is the first choice in a three-step transport cascade — Resend, then MailChannels, then Cloudflare's own email sending.
The second step of the email cascade above. Our senders are written to fall through to MailChannels when a MailChannels key is configured and Resend's is not — which means it would receive exactly what Resend receives. We list it because a fallback nobody declared is the kind of omission this page exists to prevent.
human@emaration.ai and andrew@emaration.ai. Direct email correspondence and client-shared working files in Drive.
The AI vendors behind the work and the measurement. Generation runs through one audited, metered pipeline; the visibility probe queries answer engines from the outside. See the methodology for how we meter, measure, and review.
The one model behind our generation-side work: audit-narrative writing, content drafts, and fix artifacts. Every call goes through one shared, metered client on a dedicated organization key. Claude is also one of the answer engines the AI-visibility probe queries.
Powers the on-site concierge — the grounded Q&A assistant on emaration.ai — with embeddings and generation at the edge.
One of the answer engines the AI-visibility probe queries to measure whether you are cited.
One of the answer engines the AI-visibility probe queries to measure whether you are cited.
One of the answer engines the AI-visibility probe queries to measure whether you are cited — Google's grounded AI answer surface. Queried on the runs where the Gemini engine is configured; when it is not, nothing is sent to it.
One of the answer engines the AI-visibility probe queries to measure whether you are cited. Queried on the runs where the Grok engine is configured; when it is not, nothing is sent to it.
Tools that read your existing analytics, search, or site data on your property — and the scanner behind our free security check.
The two read-only grants a member can connect, from the member portal: Google Analytics 4 and Search Console. We read; we never write. When a Google API key is configured on our side, we also look up the public Core Web Vitals record (CrUX) for your site — that needs no grant from you. Our code also carries a read-only Google Ads client for our own operator desk; the member portal never asks for that grant, and without a developer token on our side it stays "not connected".
Keyword research, competitor analysis, content-gap mapping, rank tracking.
Local site-crawl analysis for audits and migration QA. Runs on Andrew's workstation.
Engaged only if you ask us to set up call tracking for you — not part of onboarding.
Runs the free security scan at emaration.ai/tools/security-scan. Someone types a hostname, we pass it to Mozilla's HTTP Observatory, Mozilla scans that site from its own infrastructure, and we render the A–F grade and the individual checks. We never fetch the site ourselves.
Where drafts, briefs, and project notes live while we work on them. Client data is kept to what the project requires.
Brief storage, internal docs, per-engagement client workspaces.
Limited workflow automation between tools.
Vendors reached only because you authorized us, in their own interface, and only for as long as that authorization stands. Your Google analytics and search connections work the same way and are listed under Analytics & measurement. Signing in with Google and granting us read-only access to your Google analytics are different permissions, so they get separate cards — we would rather list them apart than let one hide inside the other.
When a member connects the Emaration GitHub App and picks repositories, we can place an approved fix on the repository they chose as a proposed change — a PR — for them to review. We ask GitHub for a token that lasts an hour and is scoped to those repositories; we never hold a password or a personal access token, and the member revokes us from their own GitHub settings.
The "Continue with Google" button on the member sign-in page. It is one way to prove you own your email address; the emailed sign-in link is the other, and it always works. Choosing it sends you to Google's own consent screen and brings back one thing: that the address is yours. It never creates an account — if the email is not already a member's, we say so and stop.
These vendors are only engaged when a specific deliverable in your scope of work requires them, for example a local-citation push or stock imagery for a content sprint. We notify you by email before any data is sent.
When local SEO citations are in scope. Data: business name, address, phone, hours. Location: United States / United Kingdom.
For licensed visuals in content sprints. No client data passes to these vendors.
Occasionally needed for a specific vertical's data (e.g., veterinary scheduling integrations). Always disclosed before activation, always opt-in.
We commit to giving you advance notice before any vendor on this list changes in a way that affects how your data is processed.
Questions about a specific vendor? Email human@emaration.ai. A founder answers every one — we aim to respond within one business day. If you need a security questionnaire response, or a written confirmation of a sub-processor's status signed by us, ask and we will send one.
The notice above only means something if the list it protects is complete. It has not always been. GitHub and MailChannels were reachable from shipped code and named nowhere on this page: GitHub had been receiving member-authorized repository access since that channel shipped, and MailChannels was a wired fallback we have no record of using. Mozilla was the next one. Every run of our free security scan sends the hostname someone typed to Mozilla's HTTP Observatory, and this register did not name Mozilla anywhere — while four of our own published pages credited it by name as the tool behind that scan, and the machine-readable file we publish for AI answer engines told them the same thing.
Sign in with Google came next, and it is the one we are least comfortable with, because our own automated check had already found it. The "Continue with Google" button on the member sign-in page sends a member to Google and brings their email address back. The check that reads our source had recorded both Google addresses that flow touches — and they were filed under the read-only analytics permission you grant us, which is a different permission, for a different purpose, about a different person. The machine found it. A person mis-filed it, and the file read like a finished answer. It has its own card above now, and the check can no longer be satisfied by an explanation that happens to be wrong.
We added each vendor the day we found it, which means the advance notice above was not given for GitHub, Mozilla, or Google sign-in. We could not give notice in advance of a disclosure we had already missed, and we would rather record that here than let a clean page imply a clean history.
What changed so it does not recur: this page and our internal register carry the same machine-readable key on every vendor, and an automated test fails our build whenever one names a vendor the other does not. That test could only ever compare two lists we had already written, which is how Mozilla stayed off both. So a second one now reads our own source instead: it collects every outside address our code names — including anything a page would load from a third party in your browser — and fails the build unless the register accounts for each one. And because Google sign-in proved that accounting for an address can still be wrong, our register may no longer wave one away with an explanation alone: where our own code contradicts the explanation, the build fails. A list that only a person remembers to update is the failure we had.