Per-org feature overrides let you enable or suppress a capability for a specific tenant independently of both the global feature toggle and the organization's subscription plan. You ship the code, leave the global flag off, enable the override for one tenant, observe real behavior, then expand gradually before flipping the global switch. The rollout is reversible at every step without touching your deployment pipeline. This mechanism sits on top of the broader plan gating and feature flag system that governs which capabilities each subscription tier can access.

What a Per-Org Override Is

A per-org feature override is a two-value record: an organization identifier and a feature key, with an explicit enabled or disabled state. It sits on top of the two-layer default — the global feature toggle and the plan-tier requirement — and takes precedence over both.

When the platform evaluates whether an organization can access a capability, it checks overrides first. If an override exists for that organization and feature, that state wins. If no override exists, the system falls back to the global toggle and then the plan gate. This composability is what makes overrides powerful: they do not replace the default system, they selectively override it for specific tenants.

A disabled override is equally useful. It lets you suppress a feature for one tenant even when the global toggle is on and the plan would otherwise grant access. This covers the case where one tenant's configuration or data is incompatible with a new capability and you need to exclude them while an issue is resolved, without affecting anyone else.

Why Overrides Are the Right Canary Primitive

The standard approach to canary releases — splitting traffic by percentage or routing specific users to a different code path — works at the infrastructure layer. Overrides work at the capability layer. They let you answer a different question: not "does this server handle the request correctly," but "does this capability behave correctly when a real tenant uses it through the full stack."

Because an override enables the capability for a named tenant rather than a traffic slice, you choose exactly which tenant provides the canary signal. That is usually an internal team, a design partner, or an enterprise customer who has agreed to early access. The feedback is specific, the tenant context is known, and the blast radius is bounded to one organization.

Removing the override reverts the organization to default behavior immediately. No rollback deployment, no configuration change — you delete the override record and the tenant's next request is evaluated under the standard rules.

Setting Up a Canary Rollout Step by Step

The workflow follows a consistent pattern regardless of which capability you are rolling out.

First, ship the feature behind a named flag with the global toggle off. The code is deployed but no tenant has access. The UI and API both respect the flag, so the capability is invisible at runtime.

Second, create a per-org override that enables the feature for the target tenant. The override takes effect on the next request, subject to the cache TTL. The tenant now has access while every other organization still sees the default state.

Third, observe. Run whatever validation is meaningful: functional testing, cost measurement, error rates, user feedback. The audit trail records every action taken under the capability, so you have a timestamped record of behavior to examine. For how to interpret signals during a canary window, see The Operations Dashboard for Your AI Estate.

Fourth, expand. Add overrides for additional tenants one at a time or in small groups. Each addition is a discrete step you can pause or reverse. There is no obligation to proceed to the global rollout until you are satisfied.

Fifth, flip the global toggle and remove the individual overrides. Once the global flag is on and the plan gate allows it, the overrides are redundant. Cleaning them up keeps the override set readable and avoids confusion about what is in effect for any given tenant.

How Overrides Interact with Plan Gating

Plan gating and per-org overrides are independent dimensions that compose. Plan gating asks whether the organization's subscription tier grants access to the capability. The per-org override asks whether there is an explicit decision for this organization on this feature. Overrides take precedence. For how subscription tiers map to feature entitlements, see Subscriptions, Invoices, and Contracts for AI Platforms.

This means you can grant early access to a capability that the tenant's plan does not include — useful for design partners evaluating a higher-tier feature before committing to an upgrade. It also means you can suppress a feature that the plan would otherwise include — useful for tenants who have opted out or whose configuration makes the feature unsuitable.

Neither use case requires a plan change or a custom deployment. The override is the administrative action; the platform handles the rest.

Observing Impact Before Committing

The value of a canary rollout is the measurement window between "enabled for one tenant" and "enabled for everyone." What you measure depends on the capability.

For a capability that touches agent behavior — a new guardrail rule, a changed routing strategy — you look at request logs, error rates, and any cost impact. For a UI capability, you look at user behavior and support signals. For an administrative capability, you check audit log entries for correct attribution and expected outcomes. The audit trails that hold up under cryptographic integrity checks post covers what those records look like and how to use them for post-hoc analysis. The operations dashboard for your AI estate gives you the macro view to confirm a canary is behaving within normal bounds before expanding it further.

The audit trail is append-only and associated with the organization, so all actions taken under the experimental capability are tagged and traceable. This makes post-hoc analysis straightforward: filter the audit log by organization and time window, and you see the complete picture of what happened during the canary period.

Praesidia's Override Management Interface

Praesidia exposes feature overrides as a first-class administrative surface. Administrators can list all overrides in effect across the platform, filter by feature or by organization, create or remove individual overrides, and see the effective state — the resolved combination of global toggle, plan gate, and any override — for any organization and feature pair.

Creating an override does not require a code change or a deployment. An administrator selects the feature and the organization in the management interface, sets the state to enabled or disabled, and saves. The change propagates within the cache TTL and takes effect on the next request from that organization.

The interface also surfaces aggregate state: how many organizations have overrides for a given feature, and how the override distribution compares to the global default. This is useful when cleaning up after a rollout — you can see at a glance which tenants still have explicit overrides and remove them systematically.

For the related concept of how governance mode interacts with per-org overrides, see the platform admin console.

Common questions

Can I give a tenant access to a feature their subscription plan does not include?

Yes. A per-org override enabled for a tenant grants access to that feature regardless of plan tier. The override takes precedence over the plan gate. This is the standard mechanism for early access programs and design partner arrangements where a tenant is evaluating a higher-tier capability before upgrading.

How quickly does an override take effect after I create it?

Overrides take effect quickly after creation. In practice, the next request from the affected organization will reflect the new override state within a short, bounded window. That window is short enough that overrides are a reliable operational control for most use cases.

What happens to an organization's access if I remove their override?

Removing an override reverts the organization to default behavior: the platform evaluates the global toggle and the plan gate as if no override had ever existed. If the global toggle is off or the plan gate would deny access, the capability becomes unavailable immediately. If both default conditions allow access, the capability remains available under the standard rules.

Can I use overrides to test governance or guardrail policies before enforcing them broadly?

Yes. The governance-mode flag supports an observe state where rules are evaluated and logged but do not block requests. Combined with a per-org override, you can run one organization in a stricter governance mode while the rest of the platform operates normally, giving you real signal on policy impact before committing to a wider rollout. See content guardrails for AI agents for detail on how observe-mode validation works in practice.