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

# App policy

> Configure what data your app may collect and where it may be processed, the per-app layer of the consent model

App policy is the per-app slice of the [three-layer consent model](/synheart-core/consent-system#three-layer-authority). It sits between the Synheart platform (master switches) and your end users (per-channel consent), and lets you express what *this specific app* is allowed to offer.

Edit it from the dashboard: **Projects → your project → Apps → your app → App Policy → Edit Policy**.

## What App Policy controls

Two kinds of controls, surfaced separately:

| Control                                           | Effect                                                                                                      |
| ------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- |
| **General Settings**: five high-level allow flags | Coarse on/off gates for the major data pathways. The runtime checks these before every upload class.        |
| **Restricted Channels**: per-channel deny-list    | Channels your app will never collect, even if the end user grants them. Restriction wins over user consent. |

There is no "Required Channels" control: the SDK already expresses positive ceilings on the [Consent Profile](/platform/consent-profiles) the user sees during onboarding. The app layer's only job is to *restrict further*, not to mandate.

## General Settings

| Toggle                     | What it lets your app do                                                                                            |
| -------------------------- | ------------------------------------------------------------------------------------------------------------------- |
| **Allow Cloud Processing** | Send session data to Synheart for processing. Required if you want any of the other cloud-bound flags to be useful. |
| **Allow HSI Uploads**      | Upload Human State Interface snapshots (the fused state your app would otherwise compute on-device).                |
| **Allow Research**         | Let users opt in to sharing their data with research and lab studies. Requires cloud processing.                    |
| **Allow Syni**             | Let users chat with Syni, the Synheart AI coach. Subject to your platform plan.                                     |
| **Vendor Sync Allowed**    | Let your app pull data from connected third-party wearables (e.g. WHOOP, Garmin).                                   |

All five default to **off** for a newly registered app. Turn on only what your app actually uses; Synheart's platform-level capability mask refuses to persist a flag that exceeds what your plan grants, so you'll get an error rather than silently being over-permissive.

## Restricted Channels

A check next to a channel here means **your app will not collect that data**. The end user's consent doesn't override it. Use this when:

* A regulator or your privacy team has told you a specific data type is off-limits for *this app*, even if the SDK supports it.
* You ship a focused product (e.g. sleep-only) and want to refuse incidental channels even if the user grants them.
* You're piloting a configuration and want to disable a channel temporarily without rolling a new SDK build.

Channels are grouped by the same taxonomy the SDK uses; see [Consent System → Granular channels](/synheart-core/consent-system#granular-channels) for the canonical list. Marking a channel restricted causes uploads tagged with that channel to be denied at the consent service before they reach the ingest pipeline.

## How it composes with the other layers

```mermaid theme={null}
flowchart LR
    P[Platform capability<br/>Synheart-controlled] --> AND{ALL must allow}
    A[App policy<br/>this page] --> AND
    U[User consent<br/>SDK consent flow] --> AND
    AND -->|yes| OK[Data flows]
    AND -->|no| BLOCK[Silently dropped at the seam]
```

* **Platform capability** caps everything. If `syni_integration` is disabled at the platform level, no app can turn on Allow Syni.
* **App policy** (this page) further restricts what your app may offer.
* **User consent** narrows down to what the end user actually grants.

A request only succeeds when all three layers say yes. See [Consent System → Three-layer authority](/synheart-core/consent-system#three-layer-authority) for the SDK-side perspective.

## Default behavior

A newly registered app has no policy until you create one. While missing, the consent service treats the app as **deny-all** for the gated upload classes, a safe default. Create a policy as soon as the app is registered.

If you change a policy after the app is live:

* **Loosening a flag** (turning Allow Research on) takes effect on the next consent token your users mint. Existing tokens carry the older snapshot until they refresh.
* **Tightening a flag** (turning Restricted Channels on, or turning Allow Cloud Processing off) is enforced at the next upload; the consent service rechecks the policy on every request, so changes apply within seconds even to already-issued tokens.

## Related

* [Consent System](/synheart-core/consent-system): the SDK reference (channel taxonomy, tiers, runtime enforcement).
* [Consent Profiles](/platform/consent-profiles): the per-app consent blueprints your SDK ships to end users.
* [Implementing consent](/guides/consent): how to wire the consent flow into your app.