> ## Documentation Index
> Fetch the complete documentation index at: https://docs.synheart.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# DPA outline

> What the Synapse data processing agreement covers. Not a contract: the signed DPA is the only binding version.

> [!WARNING]
>
> **This is an outline, not a contract or an offer of terms.** It summarizes what the Synapse data processing agreement (DPA) covers, with the facts we can confirm from production systems. It creates no obligations: the signed DPA is the only binding version. To request it, email **[security@synheart.ai](mailto:security@synheart.ai)**.

## 1. Parties and roles

* **Customer** (the organization using Synapse) is the **controller** of personal data in its Synapse organization.
* **Synheart AI Inc.** ("Synheart"), 1408 Robson St, Vancouver, BC V6G 0E6, Canada, is the **processor**, processing that data only to provide Synapse. Israel Goytom signs for Synheart.

## 2. Subject matter, duration, nature and purpose

* **Subject matter:** providing Synapse: organization memory for coding agents, team rules for agents, AI spend reporting, and team-level engineering views.
* **Duration:** the subscription term, plus the deletion period in section 9.
* **Nature:** collecting from tools the customer connects, storing, indexing for search, aggregating, writing explanations with a language model when the customer turns explanations on, and deleting.
* **Purpose:** only to provide and support Synapse for the customer. Customer data is not used to train models and is not sold.

## 3. Categories of data subjects

* The customer's employees and contractors who are Synapse members.
* People who appear in the customer's connected tools (for example, commit authors or Slack message authors), including people who aren't Synapse members.

## 4. Categories of personal data

* **Identity and account:** name, email, sign-in provider ID, role.
* **Tool activity:** user handles, IDs and timestamps from connected tools. Linear history rows include the actor's email.
* **Content:** only from knowledge sources an admin designates (repository docs, public Slack channels, Notion pages, shared drives) and from notes and decisions saved through agents. This may contain personal data the customer's people wrote.
* **AI tool usage:** daily usage and cost per person under an org-local pseudonym.
* **Coding-agent activity:** daily rule counts per person, rule and coding agent; decision records (mode, reason codes, evidence identifiers, a task id, the coding agent and the time); and each developer's accept/reject verdicts. No prompt, question, code, diff or branch name.
* **Consent records:** each person's opt-in and opt-out of sharing their numbers with their own team, with the disclosure version they acknowledged.
* **Billing:** billing contact name and email.

The full per-tool list is on the [Security overview](https://docs.synheart.ai/synapse/security.md#what-synapse-stores).

## 5. Special categories of data

Synapse doesn't ask customers for special-category data. Human-state data (focus and capacity signals) is processed only for people who opt in from their own Synheart Life app. Agents receive delivery hints, never scores. Employers see human state only as team aggregates:

* **Cohort floor.** Aggregates are shown only above the organization's cohort floor: default 10 people, settable from 4 to 50. Lowering it requires acknowledging a disclosure, and every change is audited.
* **Organization switch.** Team human-state views are on by default, and the customer can turn them off. Turning them off only hides data.
* **Consent-based sharing.** A team below the floor sees its own view only while every member has personally opted in. Nobody can opt anyone else in, and opting out is immediate.
* **No individual view.** There is no per-person view, and on the Synaptic Mesh a person's human state is shown only to them.

Synheart's position is that Synapse's human-state data is not health data. It consists of coarse focus and capacity signals, not medical measurements. It is shared only after a person opts in, shown to employers only as team aggregates above the cohort floor, and never used to diagnose or assess any medical or mental health condition.

## 6. Processor obligations

The DPA would commit Synheart to:

* process only on the customer's documented instructions;
* keep personnel who handle customer data bound by confidentiality;
* apply the security measures in Annex A;
* help the customer answer data subject requests. Synapse has self-serve erasure: any member can erase their own data, with or without a seat, and the organization owner can erase the organization's. Both work after the subscription has lapsed;
* help with data protection impact assessments where reasonable;
* delete or return data at the end of the service (section 9);
* make information available to show compliance, and allow audits (section 10).

## 7. Sub-processors

* Current list: [Sub-processors](https://docs.synheart.ai/synapse/subprocessors.md) (AWS, DeepInfra, Stripe, and Together AI when explanations are turned on).
* Synheart would bind each sub-processor to data protection terms at least as protective as the DPA.

## 8. International transfers

All Synapse data is hosted in AWS **us-east-1** (United States). Synheart AI Inc. is a Canadian company, so customer data is stored and processed in the US on its behalf.

For customers in the European Union, the United Kingdom or Switzerland, the DPA includes the EU Standard Contractual Clauses (Commission Decision 2021/914, Module 2: controller to processor), the UK International Data Transfer Addendum, and the Swiss amendments to the clauses.

## 9. Deletion and return at end of service

* The organization owner can erase all of the organization's Synapse data at any time from the product, without a Synapse seat and after the subscription has lapsed. The request must name the organization explicitly, and the owner types the organization's slug (or name) to confirm. It takes effect immediately and is audited.
* Some data has a fixed retention period in production today:
  * agent rule counts, decision records and accept/reject verdicts: 90 days;
  * AI usage: 90 days while a tool is connected;
  * team-sharing consents: deleted as soon as they're withdrawn;
  * tool-call activity and meeting times: 630 days;
  * the audit log: 6 years.
* Each person's team-sharing consent records are kept as proof of consent while the consent is active and for 6 years after it ends.
* Erased data stays in encrypted database backups until they age out, up to **35 days**.
* Admins can export team effectiveness reports (CSV or JSON) before erasure.

## 10. Audits and information

Synheart is undergoing its SOC 2 Type II audit and has a third-party penetration test. The SOC 2 report (once issued) and a summary of the penetration test are available on request; the DPA sets how audits work.

## 11. Personal data breach notification

Synheart notifies the customer of a personal data breach affecting its data without undue delay; the signed DPA sets the deadline and what the notice contains. Production changes are logged in AWS CloudTrail with real-time alerts on sensitive changes, and AWS GuardDuty threat detection is on.

## 12. Liability and order of precedence

Set in the signed DPA and the main agreement.

## Annex A: Technical and organizational measures

This summarizes the [Security overview](https://docs.synheart.ai/synapse/security.md):

* **Hosting:** AWS us-east-1; private subnets; no public database endpoint.
* **Encryption at rest:** AWS KMS on the database, disks and object storage. Connector tokens and API keys are also encrypted with AES-256-GCM, with keys wrapped by a Synheart-managed AWS KMS key that rotates yearly and that only the Synapse service can use for Synapse's keys.
* **Encryption in transit:** TLS 1.2+ on public endpoints, between services and to the database.
* **Access control:** role-based (Admin, Lead, Member, from the Synapse seat); members see their own department's team view, Leads and above the organization's. The organization owner alone erases the organization. Source permissions are honored at recall and search; agent tokens are scoped and short-lived.
* **Aggregation:** team figures only above a per-organization cohort floor (4 to 50, default 10), with complementary suppression. Below the floor, only with every team member's own consent.
* **Logging:** customer-visible audit log of admin and data actions; AWS CloudTrail for infrastructure, kept 365 days.
* **Minimization:** activity metadata by default; content only from admin-designated sources; email, DMs, private channels, personal drives and source code never indexed; human state opt-in and aggregate-only; decision records hold identifiers only, never prompts, questions or code.
* **Backups:** automated, encrypted, point-in-time recovery for 35 days; deletion protection on.
* **Staff access:** internal admin tools only over VPN, with an append-only audit log.

## Annex B: Sub-processors

See [Sub-processors](https://docs.synheart.ai/synapse/subprocessors.md).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.