PERMISSIONKEYS
What an identity is entitled to. Feature switches and numeric limits, resolved against the identity's tier.
A key collection is a named body of configuration that the running system reads. Between them the six collections describe who may do what, what runs when, what is recorded, how the product behaves, which privileges apply, and whatever else a particular product needs.
They are distributed together on a short refresh cycle, so a change made once is in force everywhere.
What an identity is entitled to. Feature switches and numeric limits, resolved against the identity's tier.
What runs, and how often. The declared schedule of background work for clients and backbone alike.
What is recorded. The vocabulary of measurable actions and the grain at which each is logged.
How the product acts. Copy, defaults, thresholds, sequencing and the presentation decisions that would otherwise be branches.
What an operator may do. The administrative counterpart to permissionkeys, scoping internal tools rather than the product.
Whatever this product needs that the five standard collections do not describe. The extension point, deliberately unconstrained.
Every collection uses the same primitive: a namespaced key, a value, and the scope it applies to. A switch is a key whose value is on or off. A limit is a key whose value is a quantity, optionally over a timeframe. Because the shape is uniform, the code that reads any collection is the same code — and adding a key is authoring data, never editing a parser.
Permissionkeys answer a single question: is this identity entitled to this, and how much of it? They divide into switches, which are on or off for a tier, and limits, which carry a quantity and usually a timeframe. A feature that is gated behind a tier reads a switch; a feature that is metered reads a limit and defers to the governor. Nothing about tiers is compiled into the client — the client asks whether it holds a key and renders accordingly, so a tier can be added, renamed or repriced without touching it.
Lifecyclekeys declare the system's recurring work: what task runs, on what interval, and in what order relative to the others. Clients and backbone functions both consult them, so a background refresh can be retimed, suspended or introduced without a release. Tasks sharing an interval are understood to run together, and the ordering constraints that matter are declared rather than implied.
Transactionkeys are the measurement vocabulary. Each names an action worth recording — a navigation, a setting change, a feature use, a purchase — and fixes the grain at which it is written. Because instrumentation is declared rather than coded, a feature that becomes interesting can be measured without being modified, and a noisy one can be quieted the same way.
Behaviorkeys hold the product's manners: defaults, thresholds, orderings, copy, and the small presentation decisions that accumulate into a codebase full of conditionals. This is the collection that grows fastest in practice, because it absorbs exactly the changes that used to require a release for a one-line difference.
Privilegekeys are permissionkeys pointed inward. They scope what an operator may see and do in administrative tooling — which records, which actions, which destructive operations. Keeping them in their own collection means the internal surface can be tightened without any risk of disturbing customer entitlements.
Bespoke keys are the acknowledged escape hatch. Every product has configuration that the five standard collections do not describe, and forcing it into one of them distorts both. A bespoke collection is namespaced to the product, read by the same machinery, and expected — over time — either to stay bespoke or to graduate into a standard collection once the pattern proves general.