nanaselect

Appearance

Managing cost tiers ​

In the admin: Tiers — the screen this page documents (opens in the running app).

What/why: Right-sizing — what this screen manages and why it exists.

Purpose: maintain the global cost-tier ladder — the ordered rungs (e.g. Budget → Mid-range → Premium → Ultra Premium) whose order is the right-sizing cost model.

When to use ​

  • Adding a new price tier, renaming one, or removing one that's no longer used.
  • Re-ordering the ladder after the relative pricing of tiers changes.

Prerequisites ​

  • Admin access with the edit_data capability (any data_editor or admin role).

Steps ​

  1. Open Admin → Tiers (/admin/tiers). The ladder lists every rung in cost order, with usage evidence (which systems sit on each tier).
  2. Add a tier with the add control; rename a tier inline.
  3. Remove a tier — allowed only when nothing uses it. A tier with usage is blocked from removal (the usage evidence shows exactly what's holding it), so you never orphan a system's tier.
  4. Reorder rungs with the move controls — always allowed, because ladder order is the cost model right-sizing compares against. Re-ordering takes effect on the next recommendation.

Behavior guarantees ​

  • Guards are enforced server-side regardless of client state; a blocked attempt writes no audit record — only successful mutations are audited.
  • No absolute pricing lives here: the engine compares relative tier order only. Actual prices stay in the configurator.

For how the ladder drives right-sizing (steering to the cheapest sufficient system and surfacing cheaper alternatives), see the cost-tier right-sizing reference.