DRAFT — NOT LEGAL ADVICE, NOT IN FORCE. This document was prepared by an AI assistant, not by a lawyer, from this repository's source code and documentation. It must be reviewed by counsel qualified in every jurisdiction in which the Service is offered before it is published, offered to anyone, or relied on. Placeholders in
[BRACKETS]are decisions for the operator; nothing in them should be invented by anyone but the operator and their lawyer.The evidence base for every factual statement below is
docs/legal/data-map.md, which was derived by readingpackages/db/prisma/schema.prisma,apps/api/src,apps/agent/agent,.env.exampleanddocs/security/audit-2026-08.md. Where the code and this document disagree, the code is correct and this document is wrong.
Document version: draft-1 · Prepared: 2026-08-07 · Status: unreviewed · Effective date: [NOT IN FORCE]
1.1 The software and the hosted Service are different things. The source code is published under the MIT Licence. If you run it yourself, this policy does not apply to you and we have no relationship with your data. You choose your own database host, your own model provider and your own optional third-party API keys, and you are responsible for telling your own users and your own data subjects what you have chosen. This policy describes only the hosted Service operated by [LEGAL ENTITY NAME] at [SERVICE DOMAIN]. See §2.
1.2 We hold personal data in two capacities, and the difference decides your rights.
This is consistent with §6.2 and with
docs/legal/data-map.md §6. If you are one of the Customer's prospects — a
person whose details are in a Customer's CRM — we are not the controller of that
data. Read §3, which is written for you.
1.3 One awkwardness, disclosed rather than smoothed over. Because each
Customer's hosted instance runs against its own database, the Customer's
users' account records — including session IP addresses and stored Google OAuth
tokens — physically sit in the Customer's own database even though we are the
controller of the account relationship. [CONFIRM WITH COUNSEL: the correct
characterisation of Session.ipAddress and Account credentials in a
deploy-per-customer architecture. docs/legal/data-map.md §6 flags this as
unresolved.]
[TWO DECISIONS REQUIRED, AND NEITHER CAN BE DEFERRED PAST LAUNCH.]
- The DPDP Act requires a named, contactable Grievance Officer whose details are published. A generic
privacy@alias is unlikely to satisfy the requirement to name a person. Seedocs/legal/research.md§1.- GDPR Art 27 requires an EU representative for a controller established outside the EU that offers services to people in the EU, unless a narrow exemption applies. The equivalent applies for the UK. Whether either is required depends on where [LEGAL ENTITY NAME] is established and who it sells to. See
docs/legal/research.md§2.
This section is the honest centre of this document. Most of the personal data the Service holds is about people who never created an account, never agreed to anything, and in most cases do not know the Service exists. Pretending otherwise would be the single most misleading thing this policy could do.
3.1 What happened. A business that uses the Service — most likely one whose salesperson has contacted you, or who you have emailed or met — recorded you in its CRM. That business decided to do that. It is the controller / Data Fiduciary of your data. We process that data on its instructions and for no purpose of our own.
3.2 What may be held about you. Depending on what that business did, this can include your name, business email address, phone number, job title, employer, public social profile links, a profile photograph, notes a salesperson typed about you, the full body and recipient list of email correspondence with that business's connected mailbox, calendar events you attended with them including the other attendees, records of calls placed to you including duration and whether you answered, and written characterisations of you produced by a large language model. §5 sets this out field by field.
3.3 Who to contact. Because the business is the controller, your request is for them, not for us. If you contact us we will, where we can identify the Customer concerned, pass your request on and tell you we have done so, and we will assist that Customer in responding as the requires. We will not act on your request directly without the Customer's instruction, and we generally cannot identify which Customers hold you without searching their databases, which we will not do without instruction. Write to [PRIVACY EMAIL].
3.4 The lawful basis is the Customer's to establish, not ours. In the EU and
the UK, processing business-contact data for sales purposes is typically
justified under GDPR Art 6(1)(f) — legitimate interests, which requires the
controller to have carried out and documented a balancing assessment, and
triggers the Art 14 duty to give notice to people whose data was not collected
from them directly. In India, the DPDP Act 2023 is consent-first and has no
general legitimate-interests ground, which makes third-party prospect data
materially harder to justify. See docs/legal/research.md §§1–2.
3.5 What the software does not do, stated plainly.
lawfulBasis, no consentedAt, no
optOutAt column exists on any contact record. The software does not record
why a person is in the database or on what basis.We consider these to be defects rather than features, and they are recorded as
such in docs/legal/data-map.md §7. [The Customer is contractually required
under §5.2 to have a lawful basis for everything
it uploads. That contractual allocation does not, on its own, discharge our own
obligations, and counsel should advise on what more is needed — in particular
whether a public transparency page addressed to non-users under GDPR Art 14, and
a corresponding position under DPDP, should be published.]
A disclosure about sign-in. As at the date of this draft the shipped
configuration has email-and-password sign-in enabled alongside the identity
provider, marked in the source as "local dev only, revert before deploying" and
flagged as a release blocker in docs/security/audit-2026-08.md (finding C2).
Until that is resolved, no statement that "authentication is via Google SSO
only" would be true, and this policy does not make one.
[MUST BE RESOLVED BEFORE LAUNCH. If it is resolved, amend this paragraph; do
not delete it silently while the code still enables the path.]
Where the DPDP Act 2023 applies, [LEGAL ENTITY NAME] is the Data
Fiduciary for the data in §4.1 and processing rests on the consent the user
gives at sign-up together with the "legitimate uses" the Act permits, to the
extent any applies. [CONFIRM WITH COUNSEL — the notice and consent wording at
sign-up must be drafted to DPDP s.5 standards and is not written yet. See
docs/legal/research.md §1.]
We do not sell or share personal information as those terms are defined,
and we have never done so. Note that the CCPA's exemption for business-contact
data has lapsed, so prospect data held by a Customer is in scope of the CCPA
where the Customer is a covered business. In respect of CRM records we act as a
service provider and process personal information only to perform the
Service under a written contract — the . See
docs/legal/research.md §3.
If you submit an email address to the early-access form on the marketing site:
Set out because you are entitled to know what the Service is capable of holding,
even though the Customer decides what actually goes in. Every model named is in
packages/db/prisma/schema.prisma.
The Service does not solicit special-category or sensitive personal data, has
no field for it, and applies no control specific to it. The
§5.3 prohibit Customers from putting it in.
However, Activity.body is free text and ContactBrief.narrative is
model-written prose, and nothing in the software prevents such content from
being written into either. We state this rather than implying a technical
guarantee that does not exist.
The Service is a business tool sold to businesses and is not directed at children. It has no age field and no age-verification mechanism. Customers are prohibited from processing children's data through it. [DPDP s.9 imposes verifiable-parental-consent duties and prohibits tracking and targeted advertising directed at children. Counsel should confirm whether the prohibition in the Terms is a sufficient answer for a B2B tool with no age signal, or whether more is required.]
6.1 The mailbox sync deserves its own paragraph. When one of a Customer's
users connects their mailbox, the Service ingests the content of their
correspondence and the attendee lists of their meetings. The people on the
other end of that correspondence have no relationship with us and are not asked.
A setting (autoCreate, off by default) controls whether a person becomes a
CRM record automatically merely by having emailed a salesperson. This is
described here because it is the sharpest privacy consequence of the product's
design, and it is recorded as such in docs/legal/data-map.md §2.
Once a day the hosted API sends counts to PostHog, keyed to a random install
identifier. docs/telemetry.md is the complete account and the code matches it.
CRM_TELEMETRY_DISABLED=1 or DO_NOT_TRACK=1.SENTRY_DSN, the web app, the API and the agent send exception
messages, stack traces, the request path and the logger's context to Sentry.
sendDefaultPii is off in all three, the API never logs headers, bodies or
query strings, and no user or contact identifier is attached to an event.
Sentry appears in the sub-processor list only when that variable is set.We are describing this in detail because it is one of the few places where the
software is meaningfully better than the category norm, and because a reader is
entitled to check the claim against docs/telemetry.md and the source.
Cookies. The Service sets a session cookie required for sign-in, secured in production. [COMPLETE THIS SECTION WITH THE FULL COOKIE INVENTORY FOR THE MARKETING SITE AND THE APPLICATION, AND STATE WHETHER A CONSENT BANNER IS REQUIRED IN THE EU/UK. Not resolved in this draft.]
This is where a policy most easily becomes a misrepresentation, so it is set out against what the code does rather than against what would be reassuring.
8.1 There is no automatic retention schedule. Nothing expires. No scheduled
job deletes old activities, old email bodies, old calendar events, old agent
events, or superseded research facts. Data is retained until the Customer
deletes it or the subscription terminates. We will not state a retention period
here, because the software does not implement one, and stating one would be
stating something untrue.
[This is a storage-limitation problem under GDPR Art 5(1)(e) and a minimisation
problem under DPDP. It is a product gap, not a drafting gap. See
docs/legal/data-map.md §4.5.]
8.2 There is no soft delete and no archive. A delete is a delete, and it cascades:
8.3 Deleting a person leaves a suppression record behind, permanently. When a contact is deleted, the Service writes a suppression record containing that person's email address and a reason string that today also includes their name. Its purpose is legitimate and necessary: without it, the connected mailbox sync recreates the person from the next email thread, defeating the deletion. But the effect must be stated without softening:
Deleting a person does not remove all of their data. Their email address, and currently their name, remain in the database indefinitely, in a table with no expiry and no deletion path in the user interface. The suppression is lifted only by re-adding the contact. There is no "forget completely" operation.
This is capable of being justified as a minimal record kept precisely in order to
honour a deletion — the argument recognised in GDPR Art 17(3) and in
suppression-list practice generally — but it must be disclosed, and it is
disclosed here.
[RECOMMENDATION TO THE OPERATOR, REPEATED FROM docs/legal/data-map.md §4.3:
change the reason string so it does not embed the person's name. The name is more
data than the purpose requires, and removing it makes the justification much
stronger. Until then, no document may say erasure removes all of a person's
data.]
8.4 Removing a member of a Customer's workspace deletes, in a single transaction, that user's membership, all of their sessions, all of their stored provider credentials and their mailbox sync state. Their Google grant is revoked and their mailbox sync stops immediately. What is not deleted is the user record itself and every activity they authored, because the database prevents deleting a user who owns a deal or authored an activity without reassigning it first. A former employee therefore remains in the database as a name and an email address attached to historical activity, and honouring their own erasure request requires manual reassignment first. This is a real operational constraint and is stated rather than glossed.
8.5 Deletion on termination. Because each Customer's data sits in its own
database, deletion on termination means destroying that database and the
associated stored files. There is no scripted teardown procedure today, so
this policy states no number of days. [DO NOT FILL IN A FIGURE UNTIL A
TEARDOWN PROCEDURE EXISTS AND HAS BEEN TIMED. See docs/legal/data-map.md §4.6
and §6.5, which carries the same instruction.]
8.6 Backups. [UNRESOLVED. Backup retention is determined by the managed database provider chosen, not by this software. State the provider's actual backup retention window here before publication, and note that deletion from backups lags deletion from the live database by that window.]
The complete list, with what each recipient receives, is the . In summary:
We also disclose personal data where we are required to by law, and to professional advisers and to a successor in a merger or sale of assets under appropriate confidentiality terms. We do not sell personal data and do not use Customer Data to build a profile of any individual for our own purposes.
10.1 What is sent. The research agent reads CRM records and puts their content into prompts. Assume that names, business email addresses, job titles, employers, company website content, call and meeting note text, and the user's own question leave the deployment on every agent run.
10.2 Which company receives it is a runtime setting, not a fixed dependency. Model calls are routed through an AI gateway, and which model is a value a workspace administrator selects in Settings from a catalogue fetched live from that gateway. A single settings change alters which company receives contact names, call notes and model-written briefs about named individuals. That is why the §3.1 cannot be a static list and poses an explicit decision — restrict the catalogue, or place the choice on the Customer.
10.3 Training and retention. Whether a provider uses inputs or outputs to train models, and how long it retains them, is governed by that provider's terms, not ours. This policy therefore makes no blanket statement that your data is never used to train a model — it is not ours to give.
Two specific facts, verified and stated because they are unflattering:
docs/legal/research.md §4).[VERIFY THE CURRENT PUBLISHED POSITION OF EVERY PROVIDER IN THE CATALOGUE,
CITE IT, AND STATE IT HERE BEFORE PUBLICATION. Enabling zero data retention is a
small code change that would convert this paragraph from a disclosure into a
commitment — see docs/legal/research.md §4 and Annex B below.]
10.4 Agent session state is stored outside the application database by the
agent framework. [UNRESOLVED — establish where that state physically lives and
under whose terms before publication. docs/legal/data-map.md §3.2 flags this.]
10.5 Accuracy, and the limits of it. Model output may be wrong, incomplete or
confidently mistaken. A written characterisation of a person produced by a model
is an inference, not a fact, and is labelled with its evidence and a confidence
score in the interface. Additionally, the agent reads text it did not author —
company websites, email bodies, public profiles — any of which may contain
content crafted to influence it. We take measures against this but cannot
guarantee that output is free from the influence of injected instructions
(docs/security/audit-2026-08.md finding M1).
10.6 No solely automated decisions with legal effect. The Service is not to
be used as the sole basis for a decision producing legal or similarly significant
effects on an individual, and Customers are contractually prohibited from doing
so ( §7.3). Where the Service scores, ranks or
prioritises, a human remains in the loop. [CONFIRM WITH COUNSEL against GDPR
Art 22 and the California ADMT regulations — see docs/legal/research.md §3.]
[UNRESOLVABLE UNTIL THE ENTITY AND THE HOSTING REGION ARE CHOSEN. This section is a checklist for counsel, not a statement of position.]
docs/legal/research.md §2 and §1 respectively.Subject to the conditions and exceptions in the applicable law, you may ask us to
give you a copy of your data, correct it, delete it, restrict or object to its
processing, receive it in a portable form, and withdraw a consent you gave.
Write to [PRIVACY EMAIL]. We aim to respond within one month, which is
the GDPR deadline; [state the DPDP grievance-response timeframe here once the
Rules position is confirmed — see docs/legal/research.md §1].
You may complain to a supervisory authority: in the EU, the authority in your country of residence or work; in the UK, the Information Commissioner's Office; in India, the Data Protection Board of India, after first raising the matter with our Grievance Officer, which the DPDP Act requires.
Two disclosures about how well we can serve a request:
docs/security/audit-2026-08.md and
docs/plan/multi-tenancy.md §C.9.Your rights are against that Customer. See §3.3.
Where the CCPA/CPRA applies you have rights to know, delete, correct, and to limit the use of sensitive personal information, and to be free from discrimination for exercising them. We do not sell or share personal information, and we honour Global Privacy Control signals on the marketing site [CONFIRM THIS IS IMPLEMENTED BEFORE PUBLISHING IT — as at this draft it is not verified, and an unimplemented GPC claim is precisely the kind of statement that becomes an enforcement matter].
Everything in this section is limited to what
docs/security/audit-2026-08.md verified as present. The standing rule for this
document is to understate. Understating is safe; overstating is a
misrepresentation.
13.1 What is in place and was verified.
13.2 What is not in place. We are telling you because the alternative is a misrepresentation.
13.3 Breach notification. Where a personal data breach occurs we will notify
the relevant supervisory authority and, where required, affected individuals,
within the periods the applicable law requires — 72 hours to the supervisory
authority under the GDPR, and under the DPDP Act notification to the Data
Protection Board and to affected Data Principals with no materiality threshold
[confirm the prescribed form and timing against the current DPDP Rules position
in docs/legal/research.md §1]. Where we act as processor we will notify the
Customer without undue delay under the , and the Customer makes
the regulatory notification.
We will post any change here with a new version number and date, and we will give Customers [NOTICE PERIOD — 30 days recommended] notice of a material change by [NOTIFICATION MECHANISM]. The version history is the git history of this file in the public repository, which is a stronger record than most published policies offer and should be cited as such.
Each of these is a code change, not a drafting change. They are listed because the honest version of this policy is worse than it needs to be, and the fix is in the software.