Skip to main content

Policy design patterns

This page provides practical policy composition patterns using the current gate model.

Pattern 1: Free tier baseline​

Goal:

  • broad access with strict quota and rate limits

Shape:

  • wildcard feature baseline for conservative rate/quota
  • explicit feature policies for product-critical exceptions

Use when:

  • onboarding or trial plans with low risk tolerance

Pattern 2: Paid tier with burst tolerance​

Goal:

  • stable monthly quota with short-window burst control

Shape:

  • quota policy with longer window
  • rate policy with short window on same feature

Use when:

  • you want predictable spend plus abuse protection

Pattern 3: Seat-gated collaboration feature​

Goal:

  • cap concurrent active identities for a feature

Shape:

  • seats policy (unit=seat)
  • optional feature-level quota/rate policies for usage inside each seat

Use when:

  • entitlement alone is not enough and active seat cardinality matters

Pattern 4: Add-on controlled uplift​

Goal:

  • enable higher limits only when add-on is purchased

Shape:

  • base bundle with conservative policies
  • add-on plan/bundle path with higher-priority selection

Use when:

  • packaging needs commercial upsell without meter price changes

Pattern 5: Enterprise negotiated behavior​

Goal:

  • preserve shared meter pricing baseline, customize runtime guardrails

Shape:

  • enterprise-focused bundle variants
  • optional contract terms for pricing/e2r parameters

Use when:

  • sales-led accounts need controlled exceptions

Anti-patterns to avoid​

  • relying only on wildcard policies for all features
  • in-place mutation of active high-traffic bundles without staged rollout
  • using seats as a substitute for entitlement design
  • coupling product UX to checkout redirect success instead of runtime decision results

Design checklist​

  • Is each feature's primary business risk covered by at least one explicit policy?
  • Are rate and quota windows aligned to product UX expectations?
  • Is seat policy used only where identity cardinality is a true requirement?
  • Can support explain deny/quarantine outcomes using bundle + policy + hints?

Next​