The operations track. Where development decides what the system is made of, behavior decides what it does — continuously, in production, without a release.
No build. No review queue. No store approval in the path.
The loop closes in minutes, and it closes without engineering capacity — which is what makes it usable by the people who actually own the product decision.
Transaction keys declared the measurement vocabulary in advance, so the data for the decision exists before the question is asked.
A new tier is a set of keys. A tighter limit is an edited value. Neither touches the client, the functions, or the release calendar.
Because behaviour is data, a variation is a scoped key set and a rollback is the value it replaced. Nothing has to be cleaned out of the codebase afterwards.
Rows, not code paths. Introducing a tier is authoring a set of keys; repricing or renaming one never reaches the client, because the client only ever asked whether it held a key.
Rate limits and throttles are limit keys enforced by a single governor, rather than bespoke checks scattered through the code. Tightening one under load is an edit.
What the system does on a timer — refreshes, sweeps, reconciliations — is declared in lifecycle keys with its own interval. Retiming or suspending a task is a data change.
Transaction keys declare which actions are recorded and at what grain, so a feature that becomes interesting can be measured without being modified.
Configuration that can change the product in minutes is configuration that can break it in minutes. The track is only safe with the disciplines that go with it.
Who may author a key collection, and the record of who changed what, matter exactly as much as they do for code. Treat an unaudited key edit as an unaudited deploy.
A missing or malformed key must deny rather than permit, and the client must behave sensibly when a collection cannot be fetched at all.
Anyone operating the system should see the effective configuration at a glance, not reconstruct it by reading several collections against each other.
Changing what the product does should be a configuration change, not a release.