​

Platform configuration

Control Center configuration is designed to move normal operational settings out of source-code edits and environment files when those settings can be stored safely and changed dynamically.

​

What belongs in dynamic configuration

Examples include product settings such as:

• registration enabled/disabled
• default credits
• plan limits
• allowed/default models
• upload and storage limits
• FORGE limits
• research depth/source limits
• artifact retention
• organization/business rules
• trial behavior
• tool availability
• maintenance mode
• feature flags

​

What does not belong here

Secrets such as database connection credentials, payment-provider secrets, email-service secrets, or private provider credentials should remain in protected secret-management/environment infrastructure.

​

Feature flags

Feature flags allow Starfire to stage a capability gradually rather than enabling it for every account at once. A feature can be controlled by combinations of:

• global state
• plan
• organization
• user override
• rollout cohort
• environment

Operators should record why a targeted override exists so temporary exceptions do not become unexplained permanent behavior.

​

Plan configuration

Plan configuration can connect display/commerce information with actual product entitlements and limits. Before changing a plan, evaluate the effect on existing subscribers, organizations, credits, storage, model access, build/research limits, and Stripe price mapping.

​

Tool configuration

Tools can carry settings such as enabled state, plan eligibility, timeout, maximum calls, approval requirement, and usage multiplier.

​

Maintenance mode

Maintenance should be an explicit platform state with clear operator intent. Use incidents and status communication alongside maintenance where users can be affected.

​

Change discipline

For significant configuration changes:

1. Confirm the target environment and scope.
2. Capture the current value.
3. Make the smallest required change.
4. Verify the resulting behavior.
5. Review audit/health signals.
6. Roll back if the change has unintended platform impact.

​

Configuration is not deployment

Dynamic product configuration reduces the need for code deployments for ordinary operations, but it does not replace software release processes when the underlying application or schema must change.