Billing model
Rulith Cloud is free during public beta. Billing is not active, no payment method is requested, and no account can opt into charges yet.
The commercial model is implemented and tested before a payment processor is connected so that payment events never become the authority for usage, success, or Publisher attribution.
The usage atom
One certified Case is the only billing atom.
A message, model turn, tool call, operation, Board, conversation, Agent, intermediate Goal, or evidence-row count is never a billable unit. A Case becomes eligible only when it reaches the completed disposition and its immutable terminal receipt certifies the acceptance root.
Failed, cancelled, abandoned, and superseded Cases produce a terminal usage denominator with an explicit non-billable reason. They do not consume certified-Case quota and do not create a Publisher receivable.
Two independent commercial lines
Cloud plan
A future account plan may include a certified-Case quota plus Agents, governance seats, and retention. Plan quota is a non-cash unit and cannot fund a Publisher payable.
Capability Offer
A Publisher may attach one immutable Offer to an immutable public Release. The first paid design supports free and per_certified_case; it does not introduce marketplace subscriptions or proportional attribution.
A paid Offer pins its Release digest, integer-cent price, currency, standard platform fee, rounding rule, tax behavior, refund policy, terminal policy, and validity window. A price change creates a new Offer rather than editing history.
The accepted marketplace design pins an 85% Publisher share and 15% platform fee. This split is inactive during the free beta and does not describe current charges.
Case Commercial Pin
At Case open, the authority freezes one commercial pin containing:
- tenant, Agent, Case ID, Case Type, business-key digest, and opening generation;
- exact Case Contract and Entitlement identities;
- Offer and Release digests;
- price, currency, fee, rounding, tax, refund, and terminal policies;
- the maximum exploration ratio for Publisher eligibility.
The pin prevents a later Offer, Release, entitlement, or policy change from rewriting an in-flight Case.
Clients submit only the selected Case Type and its plain business-key values. Gateway resolves the installed owner and active Offer/Entitlement, reads the current Agent generation, computes the business-key and commercial-term digests, reserves quota/wallet atomically, and injects all authority pins into OpenCase. The Agent and model never construct these digests. Core compares an expected generation before creating the Case; a rejection releases the exact reservation, while an ambiguous transport result remains pending for reconciliation rather than being guessed away.
Success and Publisher eligibility
Certification and Publisher eligibility answer different questions.
- Certification proves that the Case Contract's acceptance root passed.
- Publisher eligibility proves that the successful effective proof path was covered by the exact Release and Case Contract pinned at open.
The default policy requires full Release coverage. The protocol can pin a bounded exploration threshold, but settlement is always full-or-zero: a passing Case below the threshold earns the full Offer amount; a Case above it earns the Publisher zero. Exploration never creates a proportional payout.
Private Capabilities never create Publisher revenue. Merely installing a Release is not evidence that it caused the outcome.
Commercial ledger
Every terminal Case projects exactly one immutable UsageRecorded record through an idempotent terminal outbox. Case closure does not wait for billing; an unavailable projector leaves an observable pending item for retry and reconciliation.
The provider-neutral ledger is append-only, hash-chained, and integer-exact. It keeps separate quota, wallet, charge, tax, platform-fee, Publisher-receivable, settlement, payout, refund, void, and dispute families. Every statement line links back to one usage record and terminal receipt.
Current public production mode is zero-rated. The same code can be started in paid-disabled mode for a deployment drill. Paid mode additionally requires an atomic production-capable store and a readiness predicate. The reference HMAC file store is not accepted as a paid backend.
Payment-provider boundary
The provider-neutral command outbox and signed-event inbox are implemented with a production SQLite store and a disabled/fake test adapter. A future Stripe adapter may create customers, subscriptions, top-ups, and payout transfers. It may not decide whether a Case succeeded, how much a Case used, whether a Release covered the proof path, or what a Publisher earned.
Wallet credit can be created only from a signature-verified provider event, never from a browser redirect. Provider events enter through an idempotent inbox; payment commands leave through an outbox. The internal ledger remains replayable without the provider.
Activation contract
Before real charging can activate, Rulith must show:
- complete Terminal Receipt to UsageRecorded reconciliation in both directions;
- idempotent quota, wallet, charge, refund, receivable, settlement, and payout mutation probes;
- production atomic-storage readiness and recovery tests;
- exact Case admission uniqueness and immutable commercial pins;
- customer Billing and Publisher statement pages;
- explicit plan, quota, overage, top-up, payout, reserve, tax, and jurisdiction rulings;
- advance notice and an explicit customer opt-in.
Until every gate is closed, Console continues to show Billing is not active.