adaptive-pricing/research/PricingResearchRoadmap.md

# 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.