# Pricing Research Roadmap Status: draft. ## Purpose This document prioritizes adjacent research topics for `adaptive-pricing` into phased workstreams. It assumes the market patterns summarized in `PricingPatternsAndStrategies.md` and the vocabulary in `PricingOntology.md`. The roadmap is research-first: each phase should produce inspectable artifacts, scenario tests, and downstream recommendations before implementation hardens. --- ## Roadmap Overview | Phase | Focus | Primary outputs | | --- | --- | --- | | 1 | Ontology, lifecycle pricing, value metrics | Stable vocabulary, lifecycle playbooks, value-metric selection guide | | 2 | Solver design, comparable customer LTV | Constraint model, optimization objectives, LTV estimation spec | | 3 | Stripe/payment-provider abstraction | Provider mapping layer, artifact lifecycle, sync semantics | | 4 | Dynamic/adaptive pricing governance | Policy model, explainability rules, fairness and audit patterns | | 5 | AI-assisted pricing recommendations | Recommendation interfaces, guardrails, human-in-the-loop workflows | --- ## Phase 1: Ontology, Lifecycle Pricing, Value Metrics **Goal:** Finish the conceptual foundation and connect it to lifecycle-aware strategy. ### Workstreams #### 1.1 Ontology completion - Resolve open questions in `PricingOntology.md` - Define primitive composition patterns for hybrid models - Produce terminology conflict map for overloaded market terms (`plan`, `price`, `tier`, `package`) - Specify canonical parameter classes and validation rules - Draft scenario tests for common B2B, B2C, marketplace, and platform-fee models #### 1.2 Lifecycle pricing - Define lifecycle phase objectives, risks, and acceptable tradeoffs - Produce lifecycle playbooks for Exploration through Decline - Specify migration patterns: grandfathering, opt-in upgrades, forced migration, sunset pricing - Map strategy patterns from `PricingPatternsAndStrategies.md` to lifecycle phases - Identify metrics that signal when to change pricing phase #### 1.3 Value metrics - Research value metric selection criteria: value alignment, legibility, metering cost, gaming risk - Compare seat, usage, outcome, and hybrid metrics for AI-heavy products - Define anti-gaming mechanisms and abuse detection considerations - Document outcome metric attribution requirements - Produce a value-metric decision guide tied to offering type and lifecycle phase ### Exit criteria - Ontology terms are stable enough for schema design - Lifecycle playbooks cover all six canonical phases - Value-metric guide supports at least ten representative offering archetypes ### Dependencies - None. This phase is the foundation. --- ## Phase 2: Solver Design, Comparable Customer LTV **Goal:** Specify how customer-tunable pricing is solved safely against seller economics. ### Workstreams #### 2.1 Boundary and constraint model - Formalize boundary conditions from `INTENT.md` into testable constraints - Define hard versus soft constraints and approval escalation paths - Model commitment offsets for discounts and concessions - Specify invalid-configuration explanations #### 2.2 Comparable customer LTV - Define `average_comparable_customer_lifetime_value` estimation inputs - Specify segment normalization, risk classes, and usage expectations - Define the `most_favorable_predefined_model` selection algorithm - Specify required improvement factor semantics and seller overrides - Identify data requirements and confidence intervals for estimates #### 2.3 Solver design - Research constraint-solving approaches for customer-tunable parameters - Evaluate multi-objective optimization: LTV, margin, predictability, adoption, churn risk - Define explainable optimization outputs for sales and customer-facing flows - Produce solver scenario suite: valid tuning, rejected tuning, edge cases, abuse attempts - Draft simulation interface for pre-activation evaluation ### Exit criteria - LTV comparison spec is sufficient for prototype implementation - Solver accepts tunable parameters and returns validated configurations or rejections with reasons - Scenario suite covers volume discounts, commitment trades, prepayment trades, and hybrid models ### Dependencies - Phase 1 ontology and lifecycle framing --- ## Phase 3: Stripe/Payment-Provider Abstraction **Goal:** Keep the internal pricing model as source of truth while executing cleanly on providers. ### Workstreams #### 3.1 Provider abstraction model - Define provider-neutral artifacts: product, charge component, meter, subscription, invoice, discount execution - Specify mapping from canonical primitives to provider objects - Model idempotent create/update/sync semantics and drift detection - Define metadata strategy for auditability and reconciliation #### 3.2 Stripe reference mapping - Map access fees, recurring prices, metered prices, tiers, credits, and coupons to Stripe Billing - Research usage record ingestion, billing thresholds, and tax behavior - Define customer-specific subscription configuration patterns - Document limitations where provider models do not align cleanly with ontology primitives #### 3.3 Multi-provider survey - Compare Stripe, Paddle, Chargebee, Lago, Orb, Stigg, and m3ter - Identify provider capability gaps for outcome fees, complex commitments, and negotiated deals - Recommend minimum abstraction surface for future provider adapters ### Exit criteria - Stripe mapping spec covers the primitive set defined in Phase 1 - Sync and reconciliation rules are documented - Provider comparison informs adapter interface design ### Dependencies - Phase 1 primitive definitions - Phase 2 validation semantics for publishable configurations --- ## Phase 4: Dynamic/Adaptive Pricing Governance **Goal:** Enable adaptive pricing without sacrificing trust, fairness, or auditability. ### Workstreams #### 4.1 Governance model - Define policies for dynamic price changes, segment changes, and personalized offers - Specify approval workflows and exposure limits - Model grandfathering, price locks, and renewal behavior - Define pricing version history and decision audit trails #### 4.2 Trust-preserving adaptation - Research transparent dynamic pricing and customer-selected tradeoffs - Define explainability requirements for customer-facing price changes - Specify fairness constraints for personalized pricing - Document regulatory and reputational considerations, including algorithmic pricing scrutiny #### 4.3 Experimentation and regulation - Research pricing experiments: Van Westendorp, conjoint, Gabor-Granger, live A/B tests - Define experiment guardrails tied to lifecycle phase and segment sensitivity - Research revenue-recognition implications for discounts, credits, breakage, and bundles - Produce compliance checklist for EU and other relevant jurisdictions ### Exit criteria - Governance policy model covers publish, change, rollback, and sunset operations - Explainability standard is defined for both seller and customer views - Experimentation playbook exists with explicit guardrails ### Dependencies - Phase 1 lifecycle playbooks - Phase 2 solver and simulation outputs - Phase 3 provider sync for operational enforcement --- ## Phase 5: AI-Assisted Pricing Recommendations **Goal:** Support human and agent workflows for pricing discovery, tuning, and governance. ### Workstreams #### 5.1 Recommendation surfaces - Define seller-facing recommendations: model selection, packaging, migration, discount risk - Define customer-facing safe tuning assistance within solver bounds - Specify inputs: lifecycle phase, segment, usage forecast, competitive context, boundary conditions #### 5.2 Guardrails and evaluation - Require recommendations to cite ontology terms, constraints, and comparison metrics - Define refusal conditions for under-specified or high-risk requests - Evaluate recommendation quality against scenario suite from Phase 2 - Specify human approval paths for non-self-serve changes #### 5.3 Agent integration - Define agent-readable interfaces for pricing-model definition, validation, simulation, and publish - Map recommendation outputs to workplans, ADRs, and implementation repositories - Document prompt and tool boundaries for pricing agents operating on seller data ### Exit criteria - Recommendation contract is machine- and human-readable - Guardrails prevent unmanaged discount suggestions - Agent integration guide connects research artifacts to implementation repos ### Dependencies - Phases 1–4 artifacts - Operational telemetry and simulation data from pilot implementations --- ## Cross-Cutting Research Backlog These topics span multiple phases and should be revisited as the canon matures: | Topic | Primary phase | Notes | | --- | --- | --- | | Revenue recognition for credits and breakage | 4 | Accounting constraints affect credit and prepayment primitives | | Marketplace and take-rate models | 1, 3 | May require extension of ontology | | Tax and invoicing semantics | 3, 4 | Provider-specific but policy-driven | | Sales-assisted negotiation workflows | 2, 4 | Approval thresholds and deal desk integration | | Pricing health checks | 2, 5 | Ongoing monitoring of margin, churn, and discount exposure | | Migration tooling | 3, 4 | Operational safety for lifecycle transitions | --- ## Suggested Research Artifacts Per Phase | Phase | Artifact examples | | --- | --- | | 1 | `PricingOntology.md` revisions, lifecycle playbooks, value-metric guide, scenario catalog | | 2 | LTV spec, solver spec, simulation contract, boundary-condition schema | | 3 | Provider abstraction spec, Stripe mapping guide, adapter interface card | | 4 | Governance policy spec, explainability standard, experiment playbook | | 5 | Recommendation contract, agent integration guide, evaluation rubric | --- ## Relationship to Implementation This repository remains research-first. Implementation repositories should consume canon outputs as: 1. Vocabulary and schema definitions from Phase 1 2. Validation and solver rules from Phase 2 3. Provider mapping specs from Phase 3 4. Governance and publish policies from Phase 4 5. Recommendation interfaces from Phase 5 See `INTENT.md` for the intended adaptive-pricing engine scope and success criteria.