Skip to main content

​
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: 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.
The per-contact consent ledger itself — recording, lookup, expiry, receipts — is documented in Consent Management & Receipts. This page covers the org-level posture that resolves the contacts the ledger says nothing about.
Every (contact, channel) pair resolves to one of three states: 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.
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.

​
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:
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. 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.
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.
  3. Compliance health. The org compliance-health score 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. 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.