Retention by Plan

A Plan defines the capability surface of an Application.

Plans are not cosmetic tiers.

They are enforced permission boundaries.

Each plan determines:

• Authentication capacity
• Provider availability
• Audit log retention
• Metrics retention and sampling
• Feature access flags
• Whitelabel behavior

Plans are evaluated deterministically during enforcement.

Available Plans

AuditAuth currently defines four plans:

• starter
• basic
• pro
• enterprise

Each plan progressively expands capability boundaries.

Capability Categories

Plans define permissions across five domains:

1. Authentication
2. Audit Logs
3. Metrics
4. Feature Access
5. Whitelabel

These domains define the full permission surface of an application.

Authentication Capabilities

Plans define:

• Maximum number of users
• Available authentication providers

Example differences:

• Starter supports Google and password authentication.
• Higher plans unlock additional providers such as GitHub and Apple.
• Enterprise removes user count limits.

User limits are enforced at the application boundary.

If the maximum number of users is reached, new user creation is restricted.

Audit Log Capabilities

Plans determine:

• Retention period (in days)
• Download availability

Lower plans retain fewer days of audit data.

Enterprise plans allow audit log downloads.

Retention policies are enforced automatically.

Data older than the retention window is not accessible.

Metrics Capabilities

Plans define:

• Metrics retention window
• Sampling rate
• Download permissions

Sampling determines how much session-level data is collected.

For example:

• Starter may disable metrics retention.
• Basic introduces limited retention and partial sampling.
• Enterprise enables full sampling and extended retention.

Metrics enforcement is deterministic and plan-bound.

Feature Access Flags

Plans enable or disable feature-level capabilities such as:

• Multi-factor authentication (MFA)
• Audit log dashboards
• Metrics dashboards
• Session dashboards
• Request dashboards
• Navigation dashboards
• Whitelabel customization

If a feature flag is disabled:

• The feature is not visible in dashboards.
• Related APIs may return restricted responses.
• Enforcement logic prevents access.

Whitelabel Behavior

Plans define whitelabel capabilities.

Lower-tier plans may:

• Enforce watermark display.
• Restrict branding customization.

Enterprise plans may:

• Remove watermark.
• Enable full branding control.

Whitelabel behavior is enforced at the identity UI layer.

Plan as Permission Surface

A plan represents a structured permission surface.

It combines:

• Capacity limits
• Retention policies
• Sampling configuration
• Boolean feature flags

Enforcement logic reads the plan configuration and applies constraints at runtime.

Plans are not advisory.

They are operational constraints.

Deterministic Enforcement

When an application changes plan:

• New limits apply immediately.
• Feature access is recalculated.
• Retention windows adjust.
• Sampling behavior updates.

There is no partial enforcement.

Plan boundaries are explicit.

Next Step

To understand how plan permissions translate into runtime behavior, continue with:

• Permission Surface