Entitlements vs economics
Access, measurement, rating, funding, and bounds are separate decisions that happen to be reviewed together.
A plan places access, economics, and limits next to each other because they must be reviewed together. They remain independent mechanisms.
Entitlement: may the customer do this?
A route or frontend-integration grant admits the operation for subscribers on that compiled plan. Managed RBAC may narrow a member further. A grant alone does not say the operation is metered or billed.
Measurement: what happened?
A fs.meterRoutes() binding says the backend reports a meter on that route; the
backend's report({ meter, values, dims }) supplies the facts. fs.requests()
costs are gateway-known structural counts used for admission bounds. An
unbound route creates no rated usage for that meter, even when the plan binds a
catalog that could price it.
Rating: what is it worth?
The plan's usagePricing binding resolves to a rating context — an immutable
catalog version plus contract modifiers — and the rating engine turns each
measurement into an exact nanodollar RatedCharge. Rating is a pure function
of the measurement and the served context; backends never supply money, and
Stripe never rates.
Funding: who pays first?
Funding buckets (fs.included, fs.prepaid, fs.promo, fs.referral) pay
rated charges before anything is owed. The remainder is amount due, settled by
Stripe. A recurring price is rail-settled independently. Trials gate accrual;
taxes are a settlement concern on amount due.
Bounds: when does the platform deny?
Structural: requests limits bound the request rate; resource limits bound
persistent inventory; capacity limits bound one request. Monetary: on a block
plan the gateway reserves each request's economic maximum against available
funding and denies credit_exhausted when it cannot. An included allowance on
an overage plan is not a wall — it defines where amount due begins.
Platform cost is another axis
Farther Shore can account for the infrastructure work required to serve the builder without charging the subscriber for that same operation. Frontend integrations are the clearest example: they consume platform operations but cannot carry customer meter costs.
Do not infer subscriber billing from platform accounting or vice versa.
Review every operation as five questions
- Which plan grants it?
- Which meter binding records it, and which measures and dimensions arrive?
- Which catalog entry rates it, under which binding?
- Which funding pays first, and what happens on exhaustion?
- Which structural or monetary bound can deny it?
The compiler catches structural mistakes and kind/control mismatches, but it cannot decide whether those five commercial answers match your intended product. Verify them in a preview environment — including the bill preview — before production publish.