Skip to main content

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 is the per-app slice of the three-layer consent model. 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:
ControlEffect
General Settings — five high-level allow flagsCoarse on/off gates for the major data pathways. The runtime checks these before every upload class.
Restricted Channels — per-channel deny-listChannels 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 the user sees during onboarding. The app layer’s only job is to restrict further — not to mandate.

​
General Settings

ToggleWhat it lets your app do
Allow Cloud ProcessingSend session data to Synheart for processing. Required if you want any of the other cloud-bound flags to be useful.
Allow HSI UploadsUpload Human State Interface snapshots (the fused state your app would otherwise compute on-device).
Allow ResearchLet users opt in to sharing their data with research and lab studies. Requires cloud processing.
Allow SyniLet users chat with Syni, the Synheart AI coach. Subject to your platform plan.
Vendor Sync AllowedLet 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 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

  • 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 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 — 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.