Data Processing Agreement

Version 1.0. Effective 4 October 2026. Reviewed by Cole Maffeo, owner of Genesis Web Digital LLC, on 4 October 2026.

Applies only to managed AI. A buyer using their own Anthropic and Deepgram keys (bring-your-own-keys) gives us no personal data to process, and this agreement does not apply to them. It forms part of the Terms and takes effect when the buyer buys or starts a managed plan, including the 7-day trial, or first activates a device against our managed service, whichever is first. If it conflicts with the Terms on the processing of personal data, this agreement prevails. When the buyer has saved their own keys, a call that falls back to them and the app's out-of-call features (for example the setup wizard's draft) run on those keys and are not managed AI, so this agreement does not cover that processing; managed AI covers in-call work and post-call notes. What our own server holds about the buyer, such as the knowledge file and usage records, is covered either way. See also the subprocessors and the privacy policy.

---

1. Who is who

Role	Party
Controller	The buyer. It is their sales call, their customer, their decision to record it
Processor	Genesis Web Digital LLC
Data subjects	The people on the other end of the buyer's calls, and the buyer's own staff
Personal data	Call audio, the transcript, names and companies of the buyer's customers, the client records the app sends with a call (contact names, past-call summaries and, for the client on the call, invoice numbers, amounts, due dates and status), and whatever the buyer wrote into their own knowledge files — which in practice includes client names and agreed rates

Special categories: none. A sales call is not supposed to carry health, biometric, or other special-category data, and the service must not be used for calls that do. The buyer agrees to that.

2. What we may do with it

Only what the buyer instructs, which is: transcribe the call, generate live prompts and post-call notes, store the buyer's knowledge so each call can use it, and store the usage figures we bill from. Nothing else — no model training, no analytics across customers, no product improvement using buyer content.

That is a commitment about what we do. For our subprocessors it holds only as far as §5 describes: Anthropic's commercial terms bar training on customer content; for Deepgram we have no contract term, and rely on the model-improvement opt-out we send with every request.

3. Confidentiality

Everyone at Genesis Web Digital LLC with access to buyer data is bound by confidentiality. Today that is one person: the owner. Anthropic is bound as described in §5. For Deepgram, Neon and DigitalOcean we rely on their published terms and have not verified a confidentiality duty.

4. Security

We protect buyer data with the technical and organisational measures described in Annex II.

5. Subprocessors

Listed at the subprocessors page. The buyer authorises the current list by entering this agreement, receives 30 days' written notice before a new subprocessor begins processing, and may object on reasonable data-protection grounds — in which case either party may terminate the subscription without penalty. The subscription is monthly, so it then ends at the end of the month already paid and no further fee is charged.

Anthropic. Their Commercial Terms permit a customer to use the API to power products for its own end users, have Anthropic process Customer Content only on the customer's instructions (here Anthropic is our sub-processor and the buyer remains the controller), and state that Anthropic may not train models on Customer Content. The data processing agreement is incorporated automatically on accepting those terms. It incorporates Standard Contractual Clauses and a UK Addendum where data protection law requires them, and its processor-to-processor module is the configuration this agreement describes; we rely on none of that for an EU or UK transfer (§10). It commits to breach notice within 48 hours, deletion within 30 days of termination, and annual audit reporting. Two conditions this rests on: the commercial API, not the consumer Claude apps, and not enrolling in their Development Partner Program, which is the stated exception to the no-training term.

Deepgram. Deepgram's published terms permit it to use submitted content to improve and train its models, and its documentation states that requests join its Model Improvement Programme by default. Deepgram receives the call audio and, from the Mac app, up to 50 spoken-name hints (client and company names, contact names and aliases, and tool names) on the same request, so that names are transcribed correctly; the Chrome extension sends none. We opt every request out of that programme: our server sets the request parameter mip_opt_out=true on every request it sends to Deepgram, in a parameter set the client cannot override. That is a request parameter and not a contractual term. We have not entered into a separate data processing agreement with Deepgram, so for Deepgram the commitment in §2 is met by that configuration and not by contract.

Neon and DigitalOcean. We have not compared Neon's or DigitalOcean's terms clause by clause to §2, §7 and §8.

6. Data subject requests

If one of the buyer's customers exercises a right — access, erasure, portability — we acknowledge the buyer's request within 5 business days and carry out any export or erasure on the timing in §8, and we do not respond to that person directly. They are the buyer's data subject, not ours; answering them ourselves would be processing outside the buyer's instructions, which is the one thing §2 forbids.

To exercise any of these, the buyer writes to cole@genesisweb.org. What we can export or erase is limited to what §8, §8a and Annex II describe, on the timing in §8.

7. Breach notification

We notify the buyer without undue delay and in any event within 48 hours of becoming aware, with what is known, what is being done, and who to contact.

8. Deletion and return

When the agreement ends, or at any time before that, the buyer may ask us in writing (cole@genesisweb.org) to return or delete the personal data described in §1. We do both by hand. We delete within 30 days of the later of the buyer's request and the end of the buyer's billing, including settlement of any final overage invoice. Our erasure tool refuses while a subscription is still billing, so either we stop the subscription first or the buyer cancels it first in Stripe's customer portal; a subscription cancelled at the end of its paid period stops billing then, and the 30 days run from that date if it is later than the request. We do not delete automatically when a subscription ends; until the buyer asks, we keep the data.

On request we send, by hand and within 30 days of the request, a machine-readable export. It contains the licence, subscription, device and call records, the usage records and the current knowledge. It leaves out the contents of superseded knowledge versions (listed by metadata only), each call's copy of the knowledge, and overage and billing-period records (Annex II). Ask for the export before the erasure: afterwards the knowledge is gone and cannot be exported.

Erasure deletes the knowledge, its history and each call's copy of it from our live database, overwrites every device token so none can authenticate again, and clears the email address and the device names and identifiers. Our database provider keeps point-in-time history for a limited period, currently seven days; deleted data ages out of that history and is not individually rewritten. Usage, call, device and subscription records are not deleted: they are kept pseudonymised, with the Stripe identifiers, as accounting records (see §8a).

8a. What deletion does not cover, and why

On erasure, usage records that still carry the direct link to the licence lose both identifying links — that link and the link through the call record — and keep their dollar and token figures, the operation and the time. Destroying the record of what was charged would destroy an accounting record, so we keep it. Stripe identifiers are retained for the same reason.

What erasure does not remove, and what stays linked to one another and to the licence identifier (a hash of the licence key, with the email address gone): the licence record (plan, expiry, issue and erasure dates, region); device records (creation, last-seen and expiry times, with the name and device identifier cleared); call records (open and close times, close reason, budget and amount settled, and which device); and the subscription record (Stripe customer, subscription and item identifiers, billing period dates, status, overage settings). Because the Stripe identifiers let us and Stripe tie that record to the buyer, this is pseudonymised data, not anonymous data. Three more kinds of record also stay: the overage ledger, with its licence and Stripe links removed (billing period, minutes, amount and state); the log of Stripe webhook deliveries (event ids, types, outcomes and the subscription id, with its error text cleared); and any chargeback record (Stripe's dispute and charge ids, status and the subscription id). The billing-period work-list rows used to charge overage are deleted. We have not set a deletion date for any of these retained records. Erasure does not reach Stripe, which keeps its own records under its own terms, or our server and proxy logs (Annex II).

Separately, a daily job removes the direct licence link from usage records older than 400 days. It does not remove the link to the call record. A usage row that belongs to a call keeps that link, and the call record names the licence, so such a row can still reach the licence record, including after erasure: erasure removes the links only from usage rows that still carry the direct one. After erasure that licence record no longer carries the buyer's email address, but it keeps the licence identifier and, through the subscription record above, the Stripe identifiers.

9. Audit

The buyer may, once in any twelve-month period, request our security documentation and a completed security questionnaire, which we return within 30 days.

On-site or live audit only where there has been an actual security incident affecting the buyer's data, on 30 days' written notice, during business hours, at the buyer's cost.

10. International transfers

• Where we hold it: our database (Neon, us-east-1) and our server (DigitalOcean, nyc3) are in the United States. We sell managed plans to buyers in the United States only, and we do not offer an EU or UK region.
• Anthropic and Deepgram are US companies, and we send call audio and name hints to Deepgram and transcript text to Anthropic from the United States. We do not pin where Anthropic runs inference, so Anthropic may process requests outside the United States. We connect to Deepgram's standard API endpoint (api.deepgram.com), not a regional one, and we do not control where Deepgram processes audio.

Anthropic's data processing agreement incorporates Standard Contractual Clauses and a UK Addendum where data protection law requires them. Buyers are in the United States only, so we do not rely on them, or on the Data Privacy Framework, for any EU or UK transfer, and this agreement offers no mechanism for one. We have not entered into Standard Contractual Clauses with Deepgram. On a managed plan call audio is relayed through our own server in the United States before it reaches Deepgram; our server streams it and does not write it to disk.

---

Annex I — the processing

• Subject matter: real-time assistance during the buyer's sales calls.
• Duration: for as long as the buyer's subscription runs, and until the buyer instructs deletion under §8.
• Nature and purpose: transcription (the call audio and, from the Mac app, up to 50 spoken-name hints go to Deepgram, §5), prompt generation, post-call note generation, usage metering, and storage of the buyer's knowledge, held encrypted per licence with up to twenty earlier versions kept so an overwrite can be undone, and a copy on each call's record. The knowledge, its history and each call's copy are deleted on erasure; what remains is described in §8a.
• Types of data: §1. Data subjects: §1.

Annex II — technical and organisational measures

• In transit: TLS to the database with full certificate and hostname verification (sslmode=verify-full), and TLS to every subprocessor.
• Credentials: device tokens are 32 bytes from the OS CSPRNG, stored only as a SHA-256 digest. A database disclosure yields nothing that authenticates. Tokens expire and are revocable server-side; the licence signing key is not on the server at all.
• Content is not deliberately written to our application logs. Our server's own log lines carry ids, counts, costs, operation names and error class or status, and some carry the text of an error message from Stripe or the database, which can quote a value from the record it concerns. We do not log transcript, knowledge, card or prompt text, and request bodies are not logged. Usage records hold token counts, dollar amounts and operation names, never what was said. Three things sit outside that: our reverse proxy keeps a standard access log (IP address, time, request line, status and size, and the Referer and User-Agent headers; the request line carries a method, a path and call ids, not content); a larger request, such as the notes request that carries a call transcript, can be held briefly in a temporary file by the reverse proxy until the request ends; and if the server process itself crashes the runtime prints the failing error to the system log, which we do not claim is free of content.
• Audio passes through our server and we do not store it. The client streams to our server, which relays it to Deepgram over a socket we open, together with, from the Mac app, up to 50 spoken-name hints (client and company names, contact names and aliases, and tool names); the Chrome extension sends none. Because every Deepgram connection is one we open, we can record transcription usage in our own ledger (which feeds a daily spend ceiling on new calls), limit how many connections exist at once, and set the transcription parameters ourselves, which a direct client-to-Deepgram stream does not allow. The audio is streamed and our server does not write it to disk. mip_opt_out is sent on every request, in a parameter set the client cannot override, so every request is opted out of Deepgram's model improvement; that is a request parameter, not a contract (§5). The relay does not stop transcription at an allowance or cap: once the month's minutes are used (or an agreed overage limit is reached) a new call cannot start on our service, and a call already running keeps transcribing while its suggestions pause.
• Spend and access are bounded per device, per licence and per day (the daily ceiling refuses new calls), and model spend per call, which limits what a compromised credential can do before it is noticed.
• Access: one named person, keys held in a password manager, server secrets in a mode-600 file that is not in version control.
• Knowledge encrypted at rest: AES-256-GCM, unique IV per write, authenticated so a tampered record fails rather than decrypting to something else. Tested: the client name is not present in the stored bytes.
• Region: all buyer records are held in the United States (database on Neon, us-east-1; our server on DigitalOcean, nyc3). We sell managed plans to buyers in the United States only and offer no EU or UK region. Call audio and name hints go to Deepgram and transcript text to Anthropic, both US companies, and we do not pin where either processes them (§10).
• Export: performed by hand by us on request, within 30 days; there is no self-service endpoint. It returns, as JSON and without device token hashes: the licence record, subscription, devices, call records (times, close reason and charge; content is not stored), usage records and the current knowledge, decrypted. Superseded knowledge versions are listed by metadata only, and per-call knowledge copies and overage and billing-period records are not included.
• Erasure: knowledge, its history and each call's copy of it are deleted, every issued device token is overwritten so none can authenticate again, and the email address is cleared. What remains is described in §8a.
• Retention: after 400 days a daily job removes a usage row's direct link to the licence; a row that belongs to a call still reaches the licence record through the call record (§8a).
• Restore tested: on the production database, a point-in-time copy was created on 29 September 2026 and specific records were read back from it and matched. The complete procedure (write a canary, snapshot, delete it, restore, read it back, run the full test suite) was rehearsed on a separate non-production database on 11 September 2026. Restoring over the production database itself has not been rehearsed. The production database currently keeps seven days of history.