> ## 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.

# Consent profiles

> Define what your app may offer end users at consent time, the per-profile blueprint the SDK uses to render the consent flow

A consent profile is the blueprint your SDK reaches for when an end user goes through the consent flow. It's the **per-app slice of what's offered to the user**: the channels, tiers, and high-level capabilities your app may request consent for.

Edit profiles from the dashboard: **Projects → your project → Apps → your app → Consent Profiles**.

## Profiles vs. App Policy

These two layers do related-but-distinct jobs:

| Layer                                  | Where you set it                   | What it expresses                                                              |
| -------------------------------------- | ---------------------------------- | ------------------------------------------------------------------------------ |
| [**App policy**](/platform/app-policy) | Dashboard → App → App Policy       | Hard deny-list and coarse allow\_\* gates the runtime enforces on every upload |
| **Consent profile** (this page)        | Dashboard → App → Consent Profiles | The set of options the SDK shows the user during the consent flow              |

App policy is a *backstop*. Consent profile is the *menu*. The user sees the consent profile; the runtime enforces app policy. A user can only grant something that's both **offered by the consent profile** and **allowed by app policy**; see [the three-layer model](/synheart-core/consent-system#three-layer-authority).

## What a consent profile contains

Open or create a profile in the dashboard. You'll see two sections:

### General settings

The high-level capabilities your app may offer. End users still pick from these; the profile just says "this app is allowed to ask."

| Toggle                     | Meaning                                                                                          |
| -------------------------- | ------------------------------------------------------------------------------------------------ |
| **Allow cloud processing** | The profile may include cloud upload as an option. Required for research participation.          |
| **Vendor sync allowed**    | The profile may include third-party wearable sync (WHOOP, Garmin, etc.).                         |
| **Allow research**         | The profile may include research / lab-export participation. Requires cloud processing.          |
| **Allow Syni**             | The profile may include Syni AI coach access. Subject to your platform plan and your app policy. |
| **Set as default profile** | New users see this profile first when your app requests consent. Exactly one default per app.    |

### Channels

The granular data types the SDK consent UI offers, grouped by source:

* **Biosignals**: vitals, cardio advanced, neuromuscular, wearable motion, sleep
* **Phone context**: device motion, device context, system state
* **Behavior**: digital activity, notification patterns, app context
* **Interpretation**: focus estimation, emotion estimation

This is the same taxonomy the SDK consumes; see [Consent System → Granular channels](/synheart-core/consent-system#granular-channels) for what each one unlocks.

A check next to a channel here means "the consent UI may offer this channel"; an unchecked channel is simply not surfaced. The end user then grants whichever subset they're comfortable with at runtime.

## Multiple profiles, one default

You can ship more than one profile per app, for example a Standard and a Research variant, and pick which one is the default. The SDK fetches the default at consent time; your app can request a specific non-default profile by id if your flow needs it.

Only one profile may be flagged default. Toggling default on one automatically clears it from the others.

## Versioning: edits publish a new snapshot

Profiles are **immutable once published**. Editing the channels or any of the General Settings doesn't overwrite the old data; it creates a new version row and marks it current. Each consent token your SDK mints references the version the user agreed to, so old tokens stay valid against the snapshot they were issued from.

When you edit a profile in the dashboard you'll be asked for:

* A **version name** (required for any payload-changing edit), e.g. "v2: added sleep channel".
* A **description** (optional): release notes for the change.

Metadata-only edits (renaming the profile, changing its description, toggling Set as default, deactivating it) don't create a new version.

## How profiles compose with the other layers

A channel offered in a profile still needs [App policy](/platform/app-policy) to allow it and the user to grant it; all three layers must agree. See [App policy → How it composes](/platform/app-policy#how-it-composes-with-the-other-layers) for the full diagram.

The key distinction between the two layers:

* Use a **consent profile** to shape what the user sees and can grant.
* Use **App policy → Restricted Channels** to forbid a channel entirely, even if a profile would otherwise offer it.

## Default profile workflow

When a developer first wires up a new app, the dashboard auto-creates a default profile with sane defaults (Cloud on, Research off, Syni off, Vendor sync off; biosignals + behavior channels checked, interpretation off). That profile is what users see at first launch.

You can then:

* **Edit the default** to expand or narrow what your app offers.
* **Add additional profiles** if you have a Pro tier, research arm, or other variants, and point your app at them by profile id when needed.

## Related

* [App policy](/platform/app-policy): the per-app enforcement layer that backstops what profiles offer.
* [Consent System](/synheart-core/consent-system): full SDK reference for the channel taxonomy, tiers, and runtime enforcement.
* [Implementing consent](/guides/consent): how to wire the consent flow into your app.