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

# Consent Posture: The Unknown-Consent Policies

> The two tenant-owned policies that decide what a contact with no recorded consent receives — unknown_marketing_policy for marketing sends, consent_default_policy for CDP fanout — and how to choose between refuse-by-default and allow_with_logging.

# Consent Posture: The Unknown-Consent Policies

A consent ledger answers questions about the contacts it has rows for.
This page is about everyone else: the contact you imported last night,
the recipient a form integration never wrote a record for, the B2B lead
your CRM sync created without a consent flag. Orbit ships two
tenant-owned policies — owner-gated, audit-logged, both readable and
writable over the API — that decide what those contacts may lawfully
receive:

| Policy                       | Endpoints                                                            | Values                                            | Governs                                                                                                 |
| ---------------------------- | -------------------------------------------------------------------- | ------------------------------------------------- | ------------------------------------------------------------------------------------------------------- |
| **Unknown marketing policy** | `GET` / `PATCH /api/v1/settings/compliance/unknown-marketing-policy` | `refuse` (default) · `allow_with_logging`         | Whether **marketing sends** may reach a contact whose consent state is `unknown`                        |
| **Consent default policy**   | `GET` / `PATCH /api/v1/settings/compliance/consent-default-policy`   | `permit_on_missing` (default) · `deny_on_missing` | Whether a **CDP destination fanout or subscription check** reaches a contact with no consent ledger row |

Both are posture knobs, not legal advice: Orbit enforces the posture you
set and keeps the audit trail — it never decides that a send is
"compliant." Choosing the policy that matches your jurisdictions and
lawful bases remains your responsibility, ideally with counsel.

<Note>
  The per-contact consent ledger itself — recording, lookup, expiry,
  receipts — is documented in
  [Consent Management & Receipts](/compliance/consent-management). This
  page covers the org-level posture that resolves the contacts the
  ledger says nothing about.
</Note>

***

## The consent-state model

Every `(contact, channel)` pair resolves to one of three states:

| State       | Where it comes from                                                                                           | What each policy does with it                                                                |
| ----------- | ------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- |
| `opted_in`  | A grant recorded through the Consent API, a signed DPDP receipt, or an operator write bridged into the ledger | Always allowed — no policy consults it                                                       |
| `opted_out` | An explicit revocation, a STOP keyword, or a suppression write                                                | **Always refused, under every policy.** Neither posture knob can re-open an explicit opt-out |
| `unknown`   | No consent record exists for the pair, and the contact's profile carries no explicit channel preference       | Resolved by the policy — this is what the two knobs decide                                   |

The `unknown` state is the policy surface. Under `refuse` (the default)
the marketing-send gate answers "no" for an unknown contact — the same
conservative posture opt-in jurisdictions (GDPR, UK PECR, Brazil LGPD)
expect, where marketing before consent is a violation regardless of any
flag. Under `allow_with_logging` the same lookup answers "yes" **and
emits a per-contact audit row** recording the contact, the channel, the
resolved policy, and the timestamp — the durable trail a reviewer
compares against your lawful-basis claim.

<Warning>
  A policy change resolves only the `unknown` state. It never inverts
  an explicit opt-out — a revoked contact stays refused under
  `allow_with_logging` exactly as under `refuse`. Universal legal gates
  (revoked consent, erasure, suppression entries) apply regardless of
  either knob.
</Warning>

***

## The two policies

### Unknown marketing policy — `refuse` vs `allow_with_logging`

Endpoint: `GET` / `PATCH /api/v1/settings/compliance/unknown-marketing-policy`
(owner-only on the write).

The marketing-send gate resolves this policy per send. `refuse` is the
fail-closed default every unconfigured tenant ships with: unknown
contacts receive no marketing. `allow_with_logging` opts into the open
model — the US double-opt-out posture, CAN-SPAM, TCPA non-consumer
paths, and B2B legitimate-interest programs — where "we never asked"
does not by itself block a send you can substantiate under another
lawful basis.

Because loosening widens who you lawfully market to (every
unknown-consent contact at once), the PATCH is a deliberate, documented
decision — not a frictionless toggle:

```bash theme={null}
curl -X PATCH https://api.orbit.devotel.io/api/v1/settings/compliance/unknown-marketing-policy \
  -H "Authorization: Bearer $ORBIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "unknown_marketing_policy": "allow_with_logging",
    "reason": "B2B outbound program under existing business relationship; approved by DPO review 2026-08",
    "lawful_basis": "existing_business_relationship"
  }'
```

| Field                      | Type   | Notes                                                                                                                                     |
| -------------------------- | ------ | ----------------------------------------------------------------------------------------------------------------------------------------- |
| `unknown_marketing_policy` | enum   | `refuse` or `allow_with_logging`.                                                                                                         |
| `reason`                   | string | **Required when loosening** to `allow_with_logging` — a written justification of 10–500 characters. Optional when tightening to `refuse`. |
| `lawful_basis`             | enum   | **Required when loosening** — one of `legitimate_interest`, `existing_business_relationship`, `consent`, `contract`, `other`.             |

Omit either field while loosening and the API refuses with
`422 VALIDATION_ERROR`. Tightening back to `refuse` carries no fields —
it never widens marketing reach, so it needs no justification.

Every accepted change — in either direction — is written to the
tamper-evident audit log as an immutable before→after record: the
previous policy, the new policy, the administrator (user + IP), and the
reason and lawful basis you supplied. Separately, once
`allow_with_logging` is active, the marketing-send gate emits a
**per-contact audit row** for each unknown-consent contact it lets
through. If a regulator later argues the lawful basis was unsupported,
those rows identify exactly who was reached under the policy so you can
substantiate — or remediate — at row-level granularity instead of
arguing from a global claim.

### Consent default policy — `permit_on_missing` vs `deny_on_missing`

Endpoint: `GET` / `PATCH /api/v1/settings/compliance/consent-default-policy`
(owner-only on the write).

This is the sibling posture for the CDP side: the destination-fanout and
subscription consent checks (`/cdp/consent/check`) read it when a
contact has **no consent ledger row at all** — a shape distinct from a
ledger-mediated `unknown` state.

* `permit_on_missing` (default) — the US TCPA legitimate-relationship
  posture: a missing row does not block the fanout. Existing tenants
  behave exactly as before the toggle shipped.
* `deny_on_missing` — the EU GDPR Art 6/7 affirmative-opt-in posture:
  an unrecorded data subject is treated as a refusal.

```bash theme={null}
curl -X PATCH https://api.orbit.devotel.io/api/v1/settings/compliance/consent-default-policy \
  -H "Authorization: Bearer $ORBIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "consent_default_policy": "deny_on_missing" }'
```

The write takes effect within a minute (a 60-second in-memory policy
cache is dropped on PATCH, so the next fanout picks up the new value
without lag). Universal legal gates — revoked consent, erasure
(`rtbf`), explicit opt-out — are never inverted by this setting.

***

## How the posture meets the rest of the stack

The two knobs sit between the consent ledger and the send path — they
are read by gates, not consulted by the ledger itself:

1. **Marketing-send gate.** Every marketing send (live and scheduled)
   passes a per-contact consent check before dispatch. `opted_in`
   passes; `opted_out` fails the send with a recorded block reason;
   `unknown` resolves through your unknown marketing policy. Under
   `refuse` a blocked live send returns `403` with
   `consent_required: true`; under `allow_with_logging` the send
   proceeds and the per-contact audit row lands in your audit log.
2. **Suppression layer.** Suppression entries are dropped **before**
   dispatch regardless of policy — a suppressed address loses to
   `allow_with_logging` exactly as it loses to `refuse`. See
   [Opt-Out & Suppression Lists](/compliance/opt-out-suppression).
3. **Compliance health.** The org
   [compliance-health score](/compliance/compliance-health) counts
   consent coverage as 30% of its 0–100 blend. Loosening the policy
   does not raise coverage — it widens reach without adding evidence.
   A loosened posture with a low coverage score is the combination a
   reviewer flags, so treat the score's ranked fixes as the prompt to
   record consent, not just to permit sends.
4. **CDP fanout and subscriptions.** The destination-fanout and
   subscription consent checks resolve row-absence through the consent
   default policy. With `deny_on_missing`, an unrecorded contact
   simply does not fan out to the destination.
5. **Audit chain.** Both PATCH surfaces are owner-only and both write
   an immutable before→after entry to the tamper-evident audit log.
   The loosening justification + lawful basis are part of that entry,
   so an accidental or insufficiently-reviewed loosening is always
   attributable after the fact.

***

## Choosing a posture

Match the policy to the regime your traffic actually falls under. When
your program spans regimes, the conservative knob wins for the strict
half of your audience.

| Program                                                           | Unknown marketing policy                                                            | Consent default policy                                               | Rationale                                                                                                                                             |
| ----------------------------------------------------------------- | ----------------------------------------------------------------------------------- | -------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| **EU consumer marketing** (GDPR / UK PECR / LGPD)                 | `refuse` (keep the default)                                                         | `deny_on_missing`                                                    | Opt-in regimes treat un-asked marketing as a violation; there is no lawful widening to justify                                                        |
| **US B2B / double-opt-out program** (CAN-SPAM, TCPA non-consumer) | `allow_with_logging` with `existing_business_relationship` or `legitimate_interest` | `permit_on_missing` (keep the default)                               | The open model is defensible only with a documented basis — the API forces that documentation, and the per-contact audit rows are your substantiation |
| **Mixed global sender**                                           | `refuse`; record consent explicitly for the jurisdictions that require it           | `deny_on_missing` if your fanout destinations reach EU data subjects | One tenant-wide knob cannot be per-region; honor the strict regime in the posture and file consent records for the audiences you may reach            |

A posture choice is defensible exactly as much as the consent records
behind it. If you loosen the policy, expect the audit trail — your own
justification, the lawful basis you attested, and the per-contact rows —
to be the first thing a reviewer reads.

***

## Limits

* **Orbit enforces; it does not advise.** The platform applies the
  posture you set, blocks what the posture blocks, and logs what it
  permits. It never decides that a send is "compliant," and this page
  is not legal advice.
* **No platform-mandated default beyond the refuse fallback.** Both
  knobs ship at their conservative values (`refuse`,
  `permit_on_missing` is the historical fanout behavior) and loosen
  only by explicit owner write. On a lookup error the marketing posture
  fails to `refuse` — the conservative direction — rather than opening.
* **Policies never invert explicit signals.** An opt-out, a suppression
  entry, revoked consent, or an erasure beats both knobs, always.

***

## Related references

* [Consent Management & Receipts](/compliance/consent-management) —
  the per-contact ledger both policies resolve against.
* [Your Tenant Compliance Posture: The Toggle Map](/compliance/posture-overview) —
  where these two knobs sit among the rest of the posture surface.
* [Opt-Out & Suppression Lists](/compliance/opt-out-suppression) —
  the layer that gates sends before the policy is ever consulted.
* [Compliance Health Scores](/compliance/compliance-health) — the
  consent-coverage signal to watch after a posture change.
* [Assembling a GDPR Posture End to End](/compliance/gdpr-posture-guide) —
  the full opt-in-regime walkthrough.
* [API Reference → Settings](/api-reference/endpoints/settings) — full
  request/response schemas for both endpoints.