Skip to main content
Kerne sits between two things that change at different speeds: what you sell, which changes whenever the business decides it should, and what your product does, which you would rather not redeploy every time. So Kerne holds the part in the middle — the rules that connect a customer’s commercial situation to what they can actually do — and answers questions about them.

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.
None of that lives in your application. Your application asks.

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:
Which comes back as one of three things, depending on what you asked for: 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 — the customer 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.