Skip to main content

Tutorial: pricing model setup (plan-centric)

Goal: turn your business pricing design into a working Vluna configuration model without focusing on SDK calls.

This tutorial follows the three primary chains:

  • Access chain: plan -> entitlements -> feature_family/feature
  • Feature-to-meter chain: feature_family/feature -> meter
  • Enforcement chain: plan -> limits -> policies -> runtime decisions

And one pricing baseline chain:

  • Pricing chain: meter -> meter pricing baseline (+ optional contract-term-based pricing) -> priced outcome

Prereqs​

Step 1: define the billing owner and identity mapping​

Decide your stable billing owner and keep mapping deterministic:

  • principal_id: customer/org/team that owns billing
  • billing_account_id: Vluna account anchor (1:1 mapped from principal)

Verify:

  • For any business customer, support can identify one stable principal_id and one stable billing_account_id.

Step 2: define resource vocabulary​

Define the catalog vocabulary before plan design:

  • feature_family_code: packaging group
  • feature_code: billable/gated action
  • meter_code: pricing measurement unit

Verify:

  • Every sellable feature maps to explicit feature_code.
  • Every priced feature family/feature path has a clear meter_code strategy.

Step 3: define the billing plan baseline​

For each commercial offer, define one billing plan baseline:

  • included entitlements
  • limit intent (rate/quota/seats)
  • funding strategy (included credits/grants where applicable)

For this tutorial, pricing means:

  • meter pricing rules for priced outputs
  • optional contract-term parameters used by rating policies (where applicable)

It does not mean:

  • entitlement rules
  • policy/rate/quota enforcement rules
  • funding sources (credits/grants/purchases)

Current model note:

  • Keep meter pricing stable per meter_code.
  • Use plan design (entitlements/limits) and funding design (included credits/grants) for plan differentiation.

Verify:

  • You can explain "what this plan sells" without referring to implementation details.

Step 4: wire plan and runtime chains​

Wire all three chains explicitly:

  1. Access chain:
    • plan -> entitlements -> allowed feature families/features
  2. Feature-to-meter chain:
    • allowed feature families/features -> meter_code
  3. Enforcement chain:
    • plan -> limit intent -> gate policy bundle/policies

Then confirm pricing baseline chain:

  • meter_code -> meter pricing baseline (+ optional contract-term-based pricing) -> priced meters

Verify:

  • A plan change impacts access/pricing/enforcement consistently for the same account.

Step 5: choose how plan becomes effective​

Choose one or both application paths:

  • direct assignment (sales-led)
  • provider-backed self-serve purchase

For both paths, keep effective-time behavior explicit (upgrade, downgrade, cancel).

Verify:

  • For any timestamp, you can answer which plan was effective for one account.

Step 6: add optional overrides and funding​

Add only when needed:

  • contract terms for negotiated exceptions
  • funding via plan-issued credits, grants, and purchases

Verify:

  • You can explain which source paid for one billed outcome.

Step 7: run runtime and accounting verification​

Run one runtime path and one accounting review:

  • runtime: allow/deny/hints/pricing outcome
  • accounting: trace rated outcome to settlement/ledger evidence

Verify:

  • Support can explain one disputed amount with plan + terms + funding + rating evidence.

Completion checklist​

  • Plan baseline exists for each commercial offer.
  • Plan/runtime chains and pricing baseline chain are configured and reviewed separately.
  • Effective plan assignment logic is deterministic.
  • Optional overrides are explicit and auditable.
  • Runtime and accounting traceability are support-grade.

Next​