Policy & Rules Engine Mapping

Enterprise CMP evaluators often ask for a "policy/rules engine by regulation, region, site, app, and business unit." Consenti doesn't have a component literally named a rules engine — it doesn't need one, because the same outcome falls out of three pieces that already exist for other reasons: compliance groups, geo-resolution, and multi-tenancy. This page maps that vocabulary onto Consenti's actual architecture so it's discoverable during an evaluation.

"Policy by regulation" → compliance groups

Rather than branching logic per individual law (GDPR vs. CPRA vs. DPDPA vs. LGPD as separate code paths), every supported regulation is bucketed into one of eight compliance groups that share identical consent-collection behavior: opt-in, opt-out, opt-out-strict, opt-in-dpdpa, opt-in-china, opt-in-brazil, general-privacy-consent, and notice-only. A profile declares which group it belongs to; the group determines default-deny vs. default-grant behavior, GPC handling, and CPRA-specific sale/share denial — see the regulation-by-regulation compliance pages for the full country-to-group table.

This is deliberately coarser than "one policy object per law" — most of the world's ~90 tracked regulations behave identically from a consent-collection standpoint once you group them this way, so there is no meaningful behavior difference to configure per-law beyond group membership.

"Policy by region" → geo-resolution

When a profile is configured with compliance.type: 'auto', the visitor's region determines which compliance group (and therefore which profile) applies, resolved from IP geolocation or a timezone+language heuristic — no manual region-to-policy mapping to maintain, though a manual override map is supported for edge cases.

createConsenti({
  compliance: {
    type: 'auto',              // resolve by visitor region
    geoDataProvider: 'default', // or a custom resolver function
  },
})

"Policy by site / app" → per-tenant profiles

Each tenant_id in multiTenantmode has its own independent set of profiles, consent templates, and settings — one organization's config never leaks into another's, and a single deployment can serve multiple sites/apps each with their own active compliance group per region.

createConsenti({
  multiTenant: { enabled: true },
})

Within one tenant, multiple profiles can coexist for different sites or apps — e.g. a marketing site and a checkout app under the same organization, each with its own cookie inventory and banner content, both still governed by the same compliance-group rules for a given region.

"Policy by business unit"

Not a distinct concept in Consenti today — a business unit maps most naturally onto either a separate tenant (if it needs fully isolated data/config) or a separate profile within a tenant (if it shares infrastructure but needs its own banner/cookie set). There's no third tier between tenant and profile; evaluators asking for business-unit-level policy should map that requirement onto whichever of the two fits their actual isolation needs.

Putting it together

A concrete example: an org with sites in the EU and California, each needing different default behavior:

createConsenti({
  multiTenant: { enabled: true },     // "site/app" axis
  compliance: { type: 'auto' },       // "region" axis — resolves complianceGroup per visitor
})

// Per-tenant profile setup (via the admin dashboard or admin API):
// - EU visitors  → profile with complianceGroup: 'opt-in'          ("regulation" axis: GDPR)
// - CA visitors  → profile with complianceGroup: 'opt-out-strict'  ("regulation" axis: CPRA)
// Both profiles belong to the same tenant if it's one organization's site,
// or separate tenants if "site" isolation is also required.

Frequently asked questions