# Osolix · Feature-Flag Policy — v1

**Status:** Wave-B Foundation evidence · 2026-Q2
**Owner:** Chief Architect + DevOps Lead
**Audit dimensions:** #4 Fully developed · #14 Performance · #25 Test/DR

This document is the canonical policy for how Osolix uses feature flags
to ship safely. Every new feature lands behind a flag; a flag has an
owner, a status, and a sunset date.

## 1 · Flag types

| Type | Use | Default state |
|---|---|---|
| **Release** | Hide an in-progress feature from all tenants | OFF |
| **Experiment** | A/B test for product / UX choices | 50/50 split |
| **Operational** | Toggle a feature on incident response (e.g. disable AI Online for the day) | ON |
| **Permission** | Per-tenant entitlement above the standard plan | Per tenant |
| **Killswitch** | Emergency disable (e.g. Anthropic outage → switch every tenant to Offline) | ON (= feature live) |

## 2 · Flag lifecycle

1. **Created** — Flag added with owner, type, default state, intended-rollout date.
2. **Soft launch** — Enabled for the Osolix demo tenant + 1 friendly customer.
3. **Gradual rollout** — 5% → 25% → 50% → 100% of tenants over 4 weeks.
4. **General availability** — Default flips to ON in code; flag marked deprecated.
5. **Sunset** — After 90 days of GA, the flag is REMOVED from code (no permanent flag debt).

## 3 · Anti-patterns (forbidden)

* Permanent flags — a flag MUST have a sunset date.
* "Tenant X gets feature Y" without a permission flag — use the entitlement system instead.
* Flag-gating bug fixes — fix the bug; don't gate the fix.
* Conditional bypasses based on tenant ID hardcoded — use proper RBAC + entitlement.

## 4 · Inventory

Active flags (as of 2026-Q2):

| Flag | Type | Owner | Default | Sunset |
|---|---|---|---|---|
| `wave-b.cookie-consent` | Release | Compliance | ON | 2026-Q3 (then permanent) |
| `wave-b.right-to-erasure` | Release | Compliance | ON | 2026-Q3 |
| `wave-b.audit-charter-v1` | Release | AI Development | ON | (becomes core; never sunset) |
| `wave-b.locale-fr-es` | Release | Localisation | OFF (tenant opt-in) | 2026-Q4 |
| `wave-b.auditor-portal` | Release | Compliance | OFF (per-tenant invite) | 2026-Q4 |
| `wave-c.mobile-lease-cwip` | Release | Mobile | OFF | 2026-Q3 |
| `wave-d.k6-perf-baseline` | Operational | SRE | ON | n/a |
| `ai.online-killswitch` | Killswitch | AI Development | ON (= Online available) | n/a |

## 5 · Storage + evaluation

* Flags live in `Tenant.FeatureFlags` (jsonb column) for tenant-scoped flags.
* Global flags live in `appsettings.json` + `IFeatureManager` from `Microsoft.FeatureManagement`.
* Frontend flags hydrated via `/api/me` on login + cached for the session.
* CI gate: every flag merged into main MUST appear in this inventory within 24h.

## 6 · Open items
* Build the per-flag rollout dashboard (currently jsonb-only).
* Add per-flag telemetry: how many tenants currently see it, how many of those used the gated feature, abandonment rate.
* Wire kill-switch alerts to PagerDuty.