Contract terms

Contract terms represent customer-specific commercial terms that influence billing behavior.

Use contract terms when you have enterprise customers with negotiated exceptions:

• contract-term-based pricing overrides
• special rating parameters
• negotiated credits or grant behavior

Contract model

Contracts are account-scoped and time-effective.

• A contract has effective_at and status (active or disabled).
• Contract terms are versioned by (kind, term_key, effective_at).
• Query can resolve latest applicable term as-of a timestamp.

JSON value contract

Contract term payload is stored in contract_terms.value_json.

• value_json is required for every term write.
• The tuple (kind, term_key, effective_at) is immutable as a version identity.
• Writing the same version identity with a different value_json is rejected as conflict.

Practical rule:

• add a new effective_at for a new term value
• never rewrite a historical value in place

Supported term kinds

• pricing
• e2r_param

Use stable term_key naming so terms can be safely queried and evolved.

Term write rules

• term_key must be a normalized identifier.
• New effective versions should use a new effective_at, not mutate historical values.

Prereqs

• Outcome-based model understanding: Outcome-based billing model (events then ratings).

Recommended approach

• Keep contract terms explicit and auditable.
• Prefer additive overrides rather than redefining your entire catalog.
• Ensure support can explain how a contract term affected an outcome.

Verify

• You can trace a billed output back to the effective contract term.

Next

• DSL reference: Events to ratings DSL