What Kerne holds
Four kinds of rule, and they compose:What you sell
Your catalog: the plans, the prices, and what each plan includes. Configured once, versioned every
time you change it.
What each customer bought
Their subscription, the version of your offer it’s attached to, and its current state — active,
past due, canceling at the end of the period.
What they've used
Counters for anything with an allowance: how much this period, against what limit, and what
happens once it runs out.
What was agreed with them specifically
Overrides — the negotiated limit, the goodwill credit, the deal that exists for exactly one
customer and isn’t part of your catalog.
How a decision gets made
Your app names a capability —export_pdf, api_calls, support_level — and who it’s asking about. Kerne resolves the rules that apply to that person, in this order:
The point isn’t the shape of the call. It’s that the answer changes when your pricing changes, when a customer upgrades, when a payment fails, or when you grant someone an exception — and none of those events touch your code.
Who a decision is about
Every decision is about someone — thecustomer your SDK calls name. Usually that’s one of your users, signed up through Kerne’s own auth. It doesn’t have to be: pass any id you pick (an org id, your own user id from another auth system) and Kerne treats it the same way, with no separate registration step — see Users and sessions. Billing a company as one unit is a full fit this way: the company itself is the customer, no user required. What isn’t built is several people sharing access to that one company’s account from your frontend — see Current limits.
Next
Offers & versions
What you sell, and why changing it doesn’t change existing customers.
Entitlements
The three kinds of capability an offer can grant.
Meters & usage
Flat vs metered, what a meter measures, and spending caps.
Overrides
Different terms for one customer, outside your catalog.

