A metered limit can cover one provider or all of them, with nothing in between #68

New Issue

2026-09-21T07:18:20Z

cgalo5758 commented

2026-09-21 07:18:20 +00:00

The question

A resource key carries one optional provider, which says where its usage facts come from: one named provider, or none, meaning the key is pooled across everything or is native to the console. A single column expresses only those two ends. It cannot say that one storage limit is shared by two named providers while a third meters separately, and it cannot express a pooled limit with a per-provider limit nested inside it. Should a metered resource be scoped to an arbitrary set of providers, and what carries that set?

What depends on the answer

The shape of the metering model before usage ingest is built on it. Per-provider and pooled-across-everything are the two ends of the same axis, so a construct that carries a set covers both, and a scalar that has to grow one later is a migration of every resource key and every usage row.

Options known so far

Keep the scalar for the first version and say in the model that a key meters for one provider or for all.
A junction between a resource key and the providers that feed it.
A named metering scope that both keys and providers attach to, with usage rolling up over its members and limits allowed on the scope, on a member, or on both with the tighter one enforced.

Decided when

The metering model states which of the three it adopts, and either the schema carries the set or the model records the scalar as a deliberate limit of the first version.

Migrated from status/issues.md at b7a0e15

## The question A resource key carries one optional provider, which says where its usage facts come from: one named provider, or none, meaning the key is pooled across everything or is native to the console. A single column expresses only those two ends. It cannot say that one storage limit is shared by two named providers while a third meters separately, and it cannot express a pooled limit with a per-provider limit nested inside it. Should a metered resource be scoped to an arbitrary set of providers, and what carries that set? ## What depends on the answer The shape of the metering model before usage ingest is built on it. Per-provider and pooled-across-everything are the two ends of the same axis, so a construct that carries a set covers both, and a scalar that has to grow one later is a migration of every resource key and every usage row. ## Options known so far - Keep the scalar for the first version and say in the model that a key meters for one provider or for all. - A junction between a resource key and the providers that feed it. - A named metering scope that both keys and providers attach to, with usage rolling up over its members and limits allowed on the scope, on a member, or on both with the tighter one enforced. ## Decided when The metering model states which of the three it adopts, and either the schema carries the set or the model records the scalar as a deliberate limit of the first version. Migrated from status/issues.md at b7a0e15

cgalo5758 added this to the Usage metering milestone 2026-09-21 07:18:20 +00:00

cgalo5758 added the

kind

design

area/entitlements area/integrations labels 2026-09-21 07:18:20 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: wiki-cafe/member-console#68