Skip to main content

Pricing model blueprint (plan-centric)

This guide explains how to map a business pricing model into Vluna with billing plan as the center.

It focuses on concept wiring and ownership boundaries, not endpoint syntax.

Core principle​

In Vluna, your pricing model is the combination of:

  • what is sold: billing plan
  • what is allowed/enforced: entitlements + gate policies
  • who gets it and when: plan assignment
  • what exceptions apply: contract terms (optional)
  • how funding enters the account: plan-issued credits, grants, purchases

Current boundary:

  • billing plan does not directly carry per-plan meter price overrides.
  • Runtime pricing is based on meter pricing baseline, optionally adjusted by contract-term-based pricing where applicable.

What pricing means in this model​

In this document, pricing in runtime decisions is:

  • meter pricing (baseline)
  • optional contract-term-based pricing (for negotiated exceptions)

It includes:

  • meter pricing rules used to compute priced outcomes
  • optional contract-term parameters used by rating policies (where applicable)

It does not include:

  • access configuration (entitlements)
  • enforcement limits/rate control (gate policies)
  • funding source state (credits/grants/purchases)

Runtime effect:

  • usage path: commit reflects active meter pricing (and applicable contract terms) at commit time
  • outcome path: ratings reflect active policy + pricing/term inputs for the evaluated window

Current model note:

  • Meter prices are configured on meter_code and should be treated as stable baseline pricing.
  • Billing plans do not act as first-class per-plan meter-price override carriers.
  • Commercial differentiation across plans is typically expressed via entitlements/limits and funding design (for example, included credits via plan-linked grants).

Three primary chains​

Use these three chains to reason about plan-centered pricing design:

  1. Access chain:
    • billing plan -> entitlements -> feature_family_code / feature_code
    • Purpose: define what the account is allowed to use.
  2. Feature-to-meter chain:
    • entitlements-selected feature_family_code / feature_code -> meter_code
    • Purpose: determine which meters are used by allowed usage paths.
  3. Enforcement chain:
    • billing plan -> limits/policy intent -> gate policy bundle/policies -> runtime allow/deny/hints
    • Purpose: define how much and how fast the account can consume.

Pricing baseline chain (global to realm/account context):

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

These chains operate together at runtime and converge into ratings/settlement/ledger.

Concept wiring​

feature_families / features / meters
  -> define billable resource vocabulary

billing plan
  -> packages commercial intent
  -> references entitlements / limits / funding strategy

plan assignment
  -> attaches plan to billing_account_id with effective window

contract terms (optional)
  -> customer-specific pricing/term overrides

funding flows
  -> plan-issued credits / grants / checkout purchases

runtime
  -> usage path: authorize -> commit
  -> outcome path: events -> event rating policies -> ratings

rating / settlement / ledger
  -> authoritative billable and accounting outcomes

What to configure for each concept​

ConceptWhy it exists in pricing modelWhat to define first
billing plansellable commercial packageplan code/id, included entitlements, limit intent, funding strategy
plan assignmentmakes plan effective for one accounttarget billing_account_id, plan code or id, window start/end
entitlementsfeature access scope under a planfeature_family_code and feature inclusion boundaries
gate policy bundle/policiesruntime enforcement behaviorbundle_key, policy kind (rate/quota/seats), policy shape
contract terms (optional)negotiated customer exceptionsexplicit override scope, effective lifecycle, audit ownership
meter pricingcanonical unit-price baselinemeter-level price rows and effective-time governance
funding objectsmake monetary value available to consumeplan-issued credit rules, grant program/assignment rules, purchase path
runtime signalsproves model works in productiondenial reasons, hints, idempotency behavior, pricing outputs
  1. Define resource vocabulary: feature families, features, meters.
  2. Define billing plan for each commercial offer.
  3. Attach entitlements and enforcement intent to plans.
  4. Define assignment strategy:
    • direct assignment for sales-led flows
    • provider-backed checkout for self-serve flows
  5. Add optional contract terms only for negotiated exceptions.
  6. Decide funding strategy (plan-issued credits, grants, purchases).
  7. Verify runtime behavior through authorize/commit and/or events-to-ratings.
  8. Verify accounting traceability through ratings, settlement, and reports.

Decision boundaries (avoid model drift)​

  • Keep catalog vocabulary stable (feature_family_code, feature_code, meter_code).
  • Keep the three chains independent in design:
    • do not use billing profile fields as entitlement inputs
    • do not encode pricing decisions as access flags
    • do not treat enforcement outcomes as a substitute for pricing configuration
  • Treat billing plan as the commercial baseline; use contract terms as additive exceptions.
  • Do not couple billing profile fields to entitlement or pricing decisions.
  • Make effective-time behavior explicit for assignments, upgrades, downgrades, and cancellations.
  • Require support-grade traceability from billed outcome back to effective plan/terms.

Verification checklist​

  • For any account and timestamp, you can explain:
    • which plan was effective
    • which terms (default vs contract override) applied
    • which funding source paid
    • which rating/ledger records prove the outcome
  • Plan changes are idempotent and auditable.
  • Runtime outcomes (allow/deny/price) match intended plan semantics.