Stigg feature modeling: the five mistakes that bite (seats, IDs, cadence)

Context: Official docs (Stigg skills repo, stigg-pricing-modeling/references/features.md): documents the five common feature-modeling mistakes that trip integrations, plus feature type rules, metered aggregation behavior, and reset-cadence guidance. Features are the building blocks: boolean (has access or not), configuration numeric/enum (a bound value), metered (consumption over time paired with a meter). The feature type is fixed at creation and cannot be changed later.

The five mistakes, with fixes straight from the reference: 1. Modeling seats as a metered feature. Fix: use a configuration feature with a per-unit charge. Metered is for time-series consumption (api calls, tokens), not counts that change rarely. 2. Putting feature IDs in user-facing copy. Fix: IDs (api_calls, active_seats) are referenced from your code on every entitlement check, treat them as part of your public API. Keep them stable and machine-readable; show the name in UI. 3. Adding boolean features for tiered values. Fix: one configuration feature carrying the value beats five booleans. 4. Mismatching reset cadence and billing period. Fix: daily resets on a monthly bill confuse customers; align them (monthly resets for monthly periods). 5. Designing aggregation around current product behavior. Fix: aggregations other than count need an explicit dimension (sum needs the bytes dimension, count_unique needs the customerId dimension). Add as many event dimensions as you can up front; backfilling them later is painful. Also: editing a feature group propagates to all plans using it, and archiving hides a feature from new plans while existing subs keep their values.