Organization settings: defaults layer with project overrides

[unjica]

Roadmap priority

8

Goal

Provide organization-wide defaults for supported capabilities so teams can manage multiple projects consistently without duplicating configuration.

Organization settings act as the defaults layer. Project settings remain the primary override layer where supported.

Organization
↓
Default retention: 90 days
Default notifications: enabled
Default quotas: enabled
Default alert rules: enabled
Default AI preferences: enabled
Default PII settings: enabled
↓
Project A — inherit organization defaults
Project B — override retention to 30 days
Project C — override notifications configuration

Current state

• Most settings are currently configured per project.
• Organizations cannot yet provide shared defaults across multiple projects in a unified model.
• Some organization-level capabilities already exist or are tracked separately (e.g. PII settings in PII scrubbing: organization-level defaults with project overrides #477).
• There is currently no unified organization-level defaults and overrides model across supported capabilities.

Organization-level defaults

Organization-wide defaults may include:

Capability	Notes
Notifications	Default destinations and preferences (#492)
PII settings	Implemented through #477 (do not duplicate here)
Retention policies	Default retention periods
Quotas	Default quota behavior
Alert Rules	Default alert preferences / configuration where supported (#493)
AI preferences	Organization-level AI defaults (#496)
Future settings	Additional defaults may be added without changing the overall model

Team permissions and RBAC may evolve separately and are intentionally not the primary focus of this issue.

Deliverables

Organization defaults

• Organization-level defaults for supported capabilities
• Safe defaults for newly created projects
• Clear merge and override semantics between organization and project settings
• Documentation describing organization vs project responsibilities

Project overrides

• Projects may override supported organization defaults where appropriate
• Dashboard UI clearly indicates whether a value originates from:
  • Organization defaults
  • Project overrides
  • Explicit project configuration

Navigation & UX

• Organization settings UI for supported defaults
• Loading, empty, and error states
• Clear indication when projects inherit organization settings

Quality

• Audit events where applicable
• API and dashboard test coverage for merge semantics and authorization behavior

Merge semantics

Organization settings act as the defaults layer.

Organization	Project	Effective
Retention: 90 days	Inherit	90 days
Retention: 90 days	Override → 30 days	30 days
Notifications: enabled	Override → disabled	disabled

Supported project-level overrides should remain available unless explicitly documented otherwise.

Organization defaults must never silently remove supported project-level override capabilities.

Feature-specific merge rules (e.g. additive deny-keys for PII) are defined in the feature issue (#477) and must remain compatible with this model.

Technical notes

• Prefer extending existing settings models rather than introducing parallel configuration systems.
• Organization defaults should remain compatible with existing project-scoped settings.
• Existing feature-specific implementations (such as PII scrubbing: organization-level defaults with project overrides #477 for PII settings) should be reused rather than duplicated.
• Settings remain scoped by existing RBAC and organization membership rules.
• Newly added capabilities should naturally fit into the organization → project defaults model.

Related

• PII scrubbing: organization-level defaults with project overrides #477 — PII scrubbing: organization-level settings (first concrete slice)
• Notifications: multi-channel delivery (vision / parent roadmap) #492 — Notifications
• Alert rules: configurable conditions and destinations #493 — Alert Rules
• AI intelligence: release and incident summaries grounded in telemetry #496 — AI Release Intelligence (AI preferences)
• Future retention and quota roadmap items

Out of scope

• Team permissions and RBAC redesign
• Cross-organization configuration sharing
• Automatic migration of existing project settings (unless a follow-up explicitly requires it)
• SDK-level configuration changes
• Feature-specific implementations already tracked by dedicated issues (implement PII in PII scrubbing: organization-level defaults with project overrides #477, not here)

Base branch

develop

Suggested acceptance checks

1. Organization defaults apply correctly to newly created and existing projects where supported.
2. Supported project-level overrides behave according to documented merge semantics.
3. Dashboard UI clearly communicates inherited versus overridden values.
4. Authorization rules are enforced consistently across organization settings.
5. Existing project-scoped functionality continues to work when organization defaults are absent.
6. Tests cover merge behavior, inheritance, authorization, and audit events where applicable.