Plans & Feature Gates

Adjudon's plans are not feature checklists. They are a single function from Organization.billing.plan to a set of permitted endpoints, enforced server-side by one middleware (requireFeature(<featureName>)) that returns 403 UPGRADE_REQUIRED with a structured payload listing the current plan, the required plans, and the feature name. The dashboard reads the same gates client-side to grey out the matching UI; the API enforces them regardless. There is no client that can bypass the gate by calling the API directly.

This page lists every gate, what plan unlocks it, why the line sits where it sits, and what happens when a gate fires. The billing-side mechanics — how plans change, how overage meters, how Sandbox is stripe-less — live at Billing API.

The five plans

   ┌─────────────────────────────────────────────────────────┐
   │   Sandbox    →    Scale    →   Governance               │
   │      ↓                              ↓                    │
   │   hard-block             →   Enterprise   →  Custom     │
   │   at 10K traces                                         │
   └─────────────────────────────────────────────────────────┘

Plan	Trace limit / month	SLA	Posture
Sandbox	10,000 (hard block)	best-effort	Solo developers, prototyping
Scale	100,000 + €0.003/overage	99.9 %	Early-stage teams
Governance	500,000 + €0.001/overage	99.9 %	Mid-market compliance
Enterprise	2,000,000 + €0.0005/overage	99.99 % (roadmap)	DACH banks, large deployers
Custom	unlimited	99.99 % (roadmap)	On-prem / private cloud

Sandbox is the only plan that hard-blocks at the limit. Scale, Governance, and Enterprise meter overage to Stripe and never reject a trace on usage grounds. Custom carries no published limit by contract.

The 23 feature gates

Every gate has the same shape: a constant in backend/middleware/requirePlan.js:FEATURE_GATES mapping a feature name to the array of plan keys allowed to use it. Read the gate list as the contract; the marketing tier names below are the shorthand.

Scale and above (10 features)

The Scale tier is the smallest paid plan. These features unlock at Scale and stay available on every paid plan above it.

Gate	What it covers
webhooks	Outbound webhook subscriptions, signature verification, retry queue
slackAlerts	The full Alerts API and the alert.triggered webhook event
export	CSV / JSON export from any list endpoint
auditLog	The Operations Audit Log read API
orgLogo	Custom logo upload for branded PDF exports and dashboard chrome
memorySearch	Semantic similarity search over the customer's own trace memory
mcpServer	The MCP Servers API for agent-tool registration

Governance and above (8 features)

Governance is the inflection point: this is where the audit artefact starts becoming primary evidence rather than supplementary.

Gate	What it covers
customRetention	Per-org data-retention setting (default 90 days; up to 365)
scheduledReports	Recurring PDF / CSV report jobs
sso	OIDC + SAML 2.0 single sign-on
hashChainAudit	The Decision Hash Chain anchor and verification API
complianceMapping	The ISO 42001 / EU AI Act per-clause mapping artefact
multiClockIncidents	The Multi-Clock Hub (5 regulator clocks per incident)
art26DeployerPack	EU AI Act Art. 26 deployer-compliance evidence bundle
friaWizard	The FRIA Wizard and approval workflow
mlBom	CycloneDX 1.7 ML-BOM auto-attach per trace
provOExport	W3C PROV-O export format for evidence chains

Enterprise and above (8 features)

Enterprise is where the gate flips on the features that only matter at deployer scale — ML-BOM exhaustiveness, GPAI disclosures, deeper attestations.

Gate	What it covers
auditLogPdf	Audit-grade PDF export of the operations log
decisionMining	Pattern discovery over historical reviewer decisions
scim	SCIM 2.0 user provisioning (Okta / Azure AD / OneLogin)
cpiFeedbackIngest	Compliance Performance Index feedback loops
iso42001Pdf	Audit-grade ISO 42001 PDF export
autoApprovalEngine	The Auto-Approval Engine
c2paContentCredentials	C2PA Content Credentials sealing
gpaiPack	EU AI Act General-Purpose AI obligations evidence pack
privacyBudget	Differential-privacy budget tracking on federated learning
sigstoreEvidence	Sigstore-anchored release evidence

Custom only (3 features)

A small set of features lives on Custom plans only because they require dedicated infrastructure.

Gate	What it covers
federatedLearning	The Federated Learning split-architecture
teeAttestation	Trusted-Execution-Environment attestation chain

The teeAttestation gate, in particular, requires deployment on a TEE-capable host; Custom is what the contract negotiates the hardware around.

What a gate fires when it triggers

Every requireFeature middleware fires the same response on a plan mismatch:

{
  "success": false,
  "error":   "The feature 'autoApprovalEngine' is not available on your current plan (scale). Please upgrade to access this feature.",
  "code":    "UPGRADE_REQUIRED",
  "data": {
    "currentPlan":   "scale",
    "requiredPlans": ["enterprise", "custom"],
    "feature":       "autoApprovalEngine"
  }
}

The code is always UPGRADE_REQUIRED. The data envelope is machine-readable; dashboards drive their upgrade-prompt UI off requiredPlans and the dashboard's Billing page handles the upgrade flow itself. Hand-rolled clients should treat the code as the contract and the message as log-only.

Where gates live in the request lifecycle

   ┌─────────────────────────────────────────────────────────┐
   │   Request                                                │
   │     ↓                                                    │
   │   apiLimiter (IP)                                        │
   │     ↓                                                    │
   │   requireApiKey  /  protect  (auth)                      │
   │     ↓                                                    │
   │   requireFeature('hashChainAudit')   ← plan gate         │
   │     ↓                                                    │
   │   userApiLimiter / agentRateLimit                        │
   │     ↓                                                    │
   │   controller                                             │
   └─────────────────────────────────────────────────────────┘

The plan gate runs after auth so that an unauthenticated request returns 401 UNAUTHORIZED, not 403 UPGRADE_REQUIRED. The asymmetry is deliberate: returning a plan-gate error to an anonymous caller would leak the org's plan tier through the exception path. The same logic applies to feature names that do not exist — an unknown featureName returns 403 UNKNOWN_FEATURE rather than silently falling through, so a typo in a requireFeature('autoaprovalEngine') (sic) call is caught loudly rather than letting the request through on every plan.

Rate limiters run after the plan gate, not before it. This is also deliberate: a Sandbox plan that hammers a Governance-only endpoint should burn its rate-limit budget exactly once and then receive a clear 403 UPGRADE_REQUIRED, not be silently throttled into exhaustion before learning the actual reason. Each layer answers its own question.

What this is NOT

• Not a per-feature pricing matrix. Plans bundle features by what the deployer profile asks for, not à la carte. The marketing tier names are stable; the gate list above is the contract. If you need a single Enterprise feature on a Governance plan, the conversation is a Custom plan, not a feature-pack.
• Not editable client-side. The dashboard reads the gates to decide what to render, but the source of truth is server-side. An attacker bypassing the dashboard hits the same 403 UPGRADE_REQUIRED on the API.
• Not a permission system. Feature gates are about plan tier; per-user permissions are the role system (owner, admin, member, reviewer). A Sandbox owner cannot access webhooks; a Scale member with reviewer role can resolve the Review Queue on a tier where webhooks are also unlocked. The two layers stack.
• Not a dynamic catalogue. New features land in a deploy with a FEATURE_GATES entry; there is no runtime config that flip-toggles them per-org. Beta features are mounted on the same gate as their launch tier; cancellations are explicit deprecations on the Versioning page.

Regulator mapping

Regulator surface	What this concept satisfies
EU AI Act Art. 26	Deployer obligations — the art26DeployerPack gate is what unlocks the deployer-compliance evidence bundle
EU AI Act Art. 27	FRIA — gated by friaWizard (Governance+)
EU AI Act Art. 13	Transparency — the underlying Decision Hash Chain is gated by hashChainAudit (Governance+)
ISO 42001	Per-clause mapping gated by complianceMapping (Governance+); audit-grade PDF gated by iso42001Pdf (Enterprise+)
BaFin MaRisk	DACH-bank deployers map to Enterprise + Custom; the SCIM, autoApprovalEngine, and gpaiPack gates correspond to the controls auditors expect at this tier

See also

• Billing API — the Stripe facade that drives plan changes
• Usage API — the trace-count meter that interacts with the per-plan trace limits
• Performance & SLOs — the uptime SLA differences between plans
• Versioning — the deprecation policy that protects feature gates across releases
• Error Codes — the UPGRADE_REQUIRED code in the broader taxonomy