diff --git a/INTENT.md b/INTENT.md
new file mode 100644
index 0000000..e832962
--- /dev/null
+++ b/INTENT.md
@@ -0,0 +1,362 @@
+# INTENT.md
+
+## Project
+
+`adaptive-pricing`
+
+## Purpose
+
+`adaptive-pricing` exists to provide a practical framework for defining, evaluating, adapting, and implementing pricing models for digital products, services, platforms, and marketplace offerings.
+
+The project starts from the assumption that pricing is not merely an administrative billing concern. Pricing is a central mechanism for discovering product-market fit, expressing value, managing risk, recovering cost, shaping customer behavior, and optimizing long-term business success.
+
+The project therefore treats pricing as an adaptive product capability.
+
+## Core Intent
+
+The intent of `adaptive-pricing` is to build an **auto-regulating market value exploring pricing engine**.
+
+The engine should help sellers define pricing models that can evolve across the product lifecycle while allowing customers to choose or tune pricing-model parameters within controlled boundaries.
+
+The system should support both:
+
+1. **Seller-side optimization**
+   Helping vendors, builders, and product owners select pricing models that improve business success, customer lifetime value, contribution margin, adoption, retention, and sustainable growth.
+
+2. **Customer-side preference tuning**
+   Allowing customers to adjust non-fixed pricing parameters to better match their own preferences, such as lower upfront cost, lower usage cost, stronger predictability, higher flexibility, or better volume economics.
+
+Customer tuning must not create arbitrary discounts. Instead, tunable parameters are solved against seller-defined business goals and boundary conditions.
+
+## Problem Space
+
+Pricing strategy requires understanding at least three economic dimensions:
+
+### Cost Floor
+
+The minimum economically viable price boundary derived from fixed costs, variable costs, operating cost, support cost, payment-provider fees, capital requirements, risk, and desired margin.
+
+The cost floor answers:
+
+> What must we charge to avoid building an unsustainable offering?
+
+### Value Range
+
+The range of prices that can reasonably be justified by the value created for different customer segments, use cases, maturity levels, and usage patterns.
+
+The value range answers:
+
+> What could this be worth to customers under different conditions?
+
+### Market Competition
+
+The externally visible pricing context created by competing products, substitutes, alternative workflows, internal build options, open-source alternatives, manual workarounds, and customer budget expectations.
+
+Market competition answers:
+
+> What price can we ask while still being attractive compared with available alternatives?
+
+`adaptive-pricing` should help sellers reason across these dimensions instead of relying on static guesses.
+
+## Product Lifecycle Awareness
+
+Pricing should adapt to the phase of the product lifecycle.
+
+The project should support pricing strategy across the following lifecycle phases:
+
+1. **Exploration**
+   Pricing is used to learn about willingness to pay, customer value perception, cost structure, and viable business models.
+
+2. **Introduction**
+   Pricing supports market entry, early adoption, pilot customers, controlled risk, and customer education.
+
+3. **Growth**
+   Pricing supports scalable acquisition, segmentation, expansion revenue, repeatability, and business-model validation.
+
+4. **Maturity**
+   Pricing supports margin optimization, packaging, predictable revenue, customer retention, and operational efficiency.
+
+5. **Saturation**
+   Pricing supports differentiation, bundling, portfolio logic, retention, efficiency, and defense against competition.
+
+6. **Decline**
+   Pricing supports harvesting, migration, transition offers, reduced investment, long-tail maintenance, or graceful shutdown.
+
+The engine should not assume that one pricing model is appropriate for all phases.
+
+## Pricing Model Framework
+
+The project should provide a structured way to define pricing models.
+
+A pricing model may include fixed and non-fixed parameters such as:
+
+* base price
+* subscription period
+* setup fee
+* included usage
+* usage unit
+* usage price
+* usage tiers
+* minimum commitment
+* contract duration
+* volume discounts
+* prepayment discount
+* risk premium
+* support level
+* service-level commitment
+* cancellation flexibility
+* onboarding effort
+* customer segment
+* feature package
+* payment terms
+* renewal conditions
+
+Some parameters may be fixed by the seller. Others may be tunable by the customer.
+
+The framework should distinguish clearly between:
+
+* fixed parameters
+* seller-controlled parameters
+* customer-tunable parameters
+* calculated parameters
+* constrained parameters
+* payment-provider implementation parameters
+
+## Customer-Tuned Pricing
+
+Customers should be able to tune non-fixed pricing-model parameters according to their preferences.
+
+Examples:
+
+* lower monthly base price in exchange for higher usage price
+* lower usage price in exchange for higher minimum commitment
+* lower risk for the seller through upfront payment
+* higher flexibility in exchange for a higher price
+* volume discounts in exchange for guaranteed minimum turnover
+* longer commitment in exchange for more favorable unit economics
+* lower onboarding fee in exchange for higher monthly minimum
+* stronger predictability through capped usage or prepaid packages
+
+When a customer adjusts one or more pricing parameters, the engine should solve the remaining non-fixed parameters so that the seller’s expected average comparable customer lifetime value improves by a required percentage compared with the most favorable predefined pricing model available to that customer.
+
+This means customer tuning is allowed, but only inside an economically valid solution space.
+
+## Comparable Customer Lifetime Value
+
+The engine should use a seller-side comparison metric tentatively called:
+
+`average_comparable_customer_lifetime_value`
+
+This metric estimates the expected lifetime value of a customer under a given pricing configuration, compared against similar customers, customer segments, usage expectations, risk classes, and contract conditions.
+
+Customer-tuned models should be evaluated against a reference model:
+
+`most_favorable_predefined_model`
+
+A tuned model is valid only if:
+
+```text
+average_comparable_customer_lifetime_value(tuned_model)
+>= average_comparable_customer_lifetime_value(most_favorable_predefined_model)
+   × required_improvement_factor
+```
+
+The required improvement factor is seller-configurable.
+
+This prevents tuning from becoming unmanaged discounting.
+
+## Boundary Conditions
+
+Customer-tuned pricing must be evaluated against explicit boundary conditions.
+
+Boundary conditions may include:
+
+* cost floor
+* minimum margin
+* payment-provider fees
+* expected usage variance
+* support effort
+* onboarding effort
+* contract duration
+* churn risk
+* default risk
+* upfront investment risk
+* capital lockup
+* implementation effort
+* operational capacity
+* service-level risk
+* abuse risk
+* compliance constraints
+* tax and accounting constraints
+* customer segment eligibility
+* sales approval thresholds
+* minimum turnover commitment
+* maximum discount exposure
+
+The engine should make boundary conditions inspectable and testable.
+
+## Volume Discounts
+
+If a pricing model allows volume discounts, those discounts should not be based on optimistic usage assumptions alone.
+
+Volume discounts must be tied to enforceable or economically meaningful commitments, such as:
+
+* minimum monthly turnover
+* minimum annual turnover
+* prepaid usage packages
+* committed usage bands
+* longer contract duration
+* take-or-pay structures
+* reduced cancellation flexibility
+* customer-funded onboarding
+* guaranteed minimum platform fee
+
+The engine should reject discount structures that reduce seller economics without an offsetting commitment or risk reduction.
+
+## Automation Scope
+
+`adaptive-pricing` should not remain a theoretical pricing strategy document.
+
+The project should provide practical implementation components for:
+
+* pricing-model definition
+* pricing-model validation
+* pricing simulation
+* customer-specific price solving
+* price recommendation
+* lifecycle-aware pricing strategy
+* pricing health checks
+* payment-provider synchronization
+* customer-facing pricing configuration
+* seller-facing pricing governance
+* auditability of pricing decisions
+
+The engine should be usable by products and platforms that need to create, update, and manage pricing models automatically.
+
+## Payment Provider Integration
+
+A core implementation goal is automated integration with payment providers such as Stripe.
+
+The system should be able to translate internal pricing-model definitions into payment-provider artifacts without requiring manual configuration in the provider dashboard.
+
+For Stripe this may include automated creation and maintenance of:
+
+* products
+* prices
+* recurring subscriptions
+* metered usage prices
+* usage records
+* tiers
+* coupons or discounts where appropriate
+* promotion structures where appropriate
+* customer-specific subscription configurations
+* invoices
+* billing periods
+* tax-relevant metadata
+* product and price metadata
+* lifecycle states
+
+The internal pricing model should remain the source of truth.
+
+Payment providers are execution backends, not the primary modeling layer.
+
+## Design Principles
+
+### Pricing as Discovery
+
+The system should support learning. Especially in early product phases, pricing is a discovery mechanism, not merely a revenue mechanism.
+
+### Cost as Boundary, Not Strategy
+
+Cost floor matters, but pricing should not be reduced to cost-plus calculation. The engine should help explore market value above the cost floor.
+
+### Value Before Mechanics
+
+Pricing mechanics should serve value communication, adoption, sustainability, and customer success.
+
+### Customer Choice Within Seller Safety
+
+Customers may tune pricing parameters, but only within a bounded solution space that protects seller economics.
+
+### No Hidden Manual State
+
+Pricing models should be represented explicitly in code and data. Payment-provider state should be generated, synchronized, and auditable.
+
+### Lifecycle Awareness
+
+The system should expect pricing to change as the offering moves from exploration to introduction, growth, maturity, saturation, and decline.
+
+### Explainability
+
+The engine should explain why a pricing configuration is valid, invalid, recommended, risky, or strategically useful.
+
+### Composability
+
+Pricing models should be reusable across products, vendors, tenants, customer segments, and platforms.
+
+## Intended Users
+
+The primary users of `adaptive-pricing` are:
+
+* builders
+* vendors
+* product owners
+* SaaS operators
+* marketplace operators
+* platform owners
+* pricing strategists
+* finance operators
+* customer success teams
+* sales teams
+* AI agents assisting with product and pricing decisions
+
+The framework should support both human decision-making and automated agent-driven workflows.
+
+## Initial Deliverables
+
+The project should initially produce:
+
+1. A canonical pricing model definition format
+2. A pricing strategy vocabulary
+3. A pricing lifecycle model
+4. A model validator
+5. A customer-tuning solver concept
+6. A comparable customer lifetime value calculation model
+7. Boundary-condition definitions
+8. A simulation interface
+9. A Stripe integration design
+10. A minimal implementation path for automated price creation
+
+## Non-Goals
+
+The project is not intended to become only a theoretical pricing research repository.
+
+It is also not intended to hard-code one universal pricing model.
+
+It should not assume that all products are SaaS subscriptions, all services are usage-based, or all customers optimize for the same thing.
+
+It should not treat payment-provider configuration as the source of truth.
+
+## Success Criteria
+
+`adaptive-pricing` is successful when it enables a product team or builder to:
+
+* define pricing models in a structured format
+* reason about cost floor, value range, and market competition
+* adapt pricing to product lifecycle phase
+* expose safe pricing choices to customers
+* evaluate customer-tuned pricing against seller economics
+* enforce boundary conditions
+* connect pricing definitions to Stripe or similar payment providers
+* create and update payment-provider pricing artifacts automatically
+* simulate expected economic outcomes before activation
+* explain why a pricing model is valid, invalid, risky, or recommended
+
+## Strategic Direction
+
+`adaptive-pricing` should become the pricing capability layer for Coulomb offerings and related product platforms.
+
+It should allow pricing to become adaptive, inspectable, customer-aware, seller-safe, and operationally executable.
+
+The long-term ambition is to support pricing as a dynamic control system for product-market fit, customer value exploration, sustainable revenue, and market learning.
+
diff --git a/research/PricingOntology.md b/research/PricingOntology.md
new file mode 100644
index 0000000..52ff854
--- /dev/null
+++ b/research/PricingOntology.md
@@ -0,0 +1,380 @@
+# Pricing Ontology
+
+Status: draft.
+
+## Purpose
+
+This document defines the canonical vocabulary for `adaptive-pricing`. It separates strategic intent from billing mechanics, names composable pricing primitives, and provides stable terms for downstream modeling, validation, simulation, and payment-provider mapping.
+
+Patterns and market context live in `PricingPatternsAndStrategies.md`. Research sequencing lives in `PricingResearchRoadmap.md`.
+
+---
+
+## Design Principles
+
+1. **Strategy before mechanics.** A pricing strategy explains why a price exists; a pricing model explains how a customer is charged.
+2. **Internal model is source of truth.** Payment providers execute artifacts; they do not define the conceptual model.
+3. **Composable primitives.** Complex offerings are built from meters, fees, commitments, discounts, and constraints—not from provider-dashboard concepts alone.
+4. **Explicit commitments.** Discounts and favorable unit economics require offsetting commitment or risk reduction.
+5. **Inspectable boundaries.** Cost floor, margin, risk, and governance limits are first-class concepts.
+
+---
+
+## Core Concepts
+
+### Pricing Strategy
+
+The seller-side rationale for how an offering should be priced.
+
+A pricing strategy answers why a price should exist and what business outcome it should optimize. It draws on cost floor, value range, market competition, lifecycle phase, customer segments, willingness to pay, growth objectives, margin objectives, and risk tolerance.
+
+A pricing strategy may recommend one or more pricing models but is not itself a billing configuration.
+
+### Pricing Model
+
+The structured definition of how a customer is charged for an offering.
+
+A pricing model specifies charge components, parameters, tiers, commitments, discounts, billing cadence, and eligibility rules. It may include fixed, seller-controlled, customer-tunable, calculated, and constrained parameters.
+
+Examples: flat subscription, per-seat, usage-based, tiered package, credit block, outcome fee, hybrid subscription plus usage.
+
+### Pricing Configuration
+
+A resolved instance of a pricing model for a specific customer, segment, contract, or lifecycle phase.
+
+A configuration binds parameter values, applies discounts, enforces commitments, and produces an auditable price outcome. Customer-tuned configurations must remain inside seller-defined boundary conditions.
+
+### Value Metric
+
+The unit of value that scales price with customer benefit or consumption.
+
+The value metric is the primary scaling dimension of a pricing model. It should correlate with delivered value, be hard to game, and be legible to buyers.
+
+Examples: seats, API calls, documents processed, revenue influenced, tickets resolved, tokens consumed, active projects.
+
+A strong value metric aligns revenue growth with customer success. A weak value metric creates adoption friction or margin leakage.
+
+### Lifecycle Phase
+
+The stage of the product or offering lifecycle that informs pricing strategy and acceptable tradeoffs.
+
+Canonical phases:
+
+1. **Exploration** — learn willingness to pay and viable business models
+2. **Introduction** — support market entry and early adoption
+3. **Growth** — scale acquisition, segmentation, and expansion revenue
+4. **Maturity** — optimize margin, packaging, and retention
+5. **Saturation** — differentiate, bundle, and defend share
+6. **Decline** — harvest, migrate, or wind down gracefully
+
+Lifecycle phase influences recommended models, discount tolerance, and migration policy.
+
+---
+
+## Charge Components
+
+### Access Fee
+
+A recurring or one-time charge for entitlement to use the product, platform, or feature package regardless of measured usage.
+
+Also called base fee, platform fee, or subscription fee. May be fixed or vary by tier, segment, or commitment.
+
+### Setup Fee
+
+A one-time charge covering onboarding, implementation, migration, or provisioning effort.
+
+Often negotiable or waivable in exchange for stronger commitment or higher recurring minimums.
+
+### Usage Meter
+
+A measured unit of consumption that drives variable charges.
+
+A meter defines what is counted, how it is aggregated, the measurement window, and the billing treatment. Multiple meters may exist in one pricing model.
+
+Examples: API requests, compute minutes, stored gigabytes, messages sent, seats active in period.
+
+### Included Usage
+
+Usage quantity bundled into an access fee or package before overage charges apply.
+
+Included usage creates predictability for customers and anchors expansion revenue for sellers.
+
+### Overage
+
+Variable charge applied when measured usage exceeds included usage or committed quantity.
+
+Overage makes usage-based models predictable at the package level while preserving upside from heavy consumption. Overage rates are often higher than in-band usage rates.
+
+### Tier
+
+A bounded band of quantity, capability, or segment that maps to specific prices or entitlements.
+
+Tiers may be customer-selected packages (Good/Better/Best), graduated usage bands, or enterprise capability sets.
+
+### Volume Discount
+
+A unit-price reduction triggered by higher quantity, subject to enforceable or economically meaningful commitment.
+
+Volume discounts must not rely on optimistic usage alone. Valid triggers include minimum turnover, prepaid packages, committed usage bands, longer contract duration, or reduced cancellation flexibility.
+
+### Graduated Price
+
+A price schedule where each usage band has its own unit rate and contributes independently to the total charge.
+
+Distinct from volume pricing, where the qualifying band sets one unit rate across all units.
+
+### Stairstep Price
+
+A price schedule where each quantity range maps to a single fixed charge for the whole step.
+
+Useful when offerings are sold in discrete capacity blocks.
+
+---
+
+## Commercial Terms
+
+### Commitment
+
+An enforceable or economically meaningful obligation that reduces seller risk in exchange for more favorable pricing.
+
+Commitments offset discount exposure, revenue volatility, or upfront investment. They are central to safe customer tuning.
+
+Examples:
+
+- minimum monthly or annual turnover
+- contract duration
+- prepaid usage packages
+- committed usage bands
+- take-or-pay structures
+- guaranteed platform fee
+- reduced cancellation flexibility
+- customer-funded onboarding
+
+A pricing model should make commitments explicit, measurable, and auditable.
+
+### Discount
+
+A reduction from a reference price, expressed as percentage, fixed amount, coupon, promotional rate, or improved unit economics.
+
+Discounts should be attributable to a rule, segment, lifecycle policy, or commitment. Unbounded discounting is an anti-pattern.
+
+### Credit
+
+Prepaid purchasing power denominated in currency or meter units.
+
+Credits decouple cash collection from consumption timing. They can improve budget control, create commitment, and introduce breakage risk. Credit models require explicit expiration, rollover, refund, and revenue-recognition rules.
+
+### Outcome Fee
+
+A charge tied to an observed business result rather than raw usage alone.
+
+Outcome fees align price with customer value but require clear attribution, measurement windows, dispute handling, and baseline definitions.
+
+Examples: percentage of revenue generated, share of cost saved, fee per qualified lead, bounty per resolved ticket.
+
+### Risk Adjustment
+
+A pricing modifier reflecting seller exposure to default, churn, support burden, abuse, implementation effort, or capital lockup.
+
+Risk adjustments may appear as higher base fees, larger prepayment requirements, shorter billing periods, or tighter usage caps.
+
+### Prepayment
+
+Payment collected before service delivery or before usage is consumed.
+
+Prepayment reduces seller risk and may unlock discounts or improved unit economics.
+
+---
+
+## Economic Boundaries
+
+### Cost Floor
+
+The minimum economically viable price boundary derived from fixed costs, variable costs, operating cost, support cost, payment-provider fees, capital requirements, risk, and desired margin.
+
+The cost floor answers: what must we charge to avoid building an unsustainable offering?
+
+### Value Range
+
+The range of prices that can reasonably be justified by value created across segments, use cases, maturity levels, and usage patterns.
+
+The value range answers: what could this be worth to customers under different conditions?
+
+### Market Competition
+
+The externally visible pricing context created by substitutes, alternative workflows, internal build options, open-source alternatives, and budget expectations.
+
+Market competition answers: what price can we ask while remaining attractive?
+
+### Boundary Condition
+
+A seller-defined constraint that a pricing configuration must satisfy to be valid.
+
+Examples:
+
+- minimum margin
+- maximum discount exposure
+- payment-provider fee coverage
+- expected usage variance limits
+- support and onboarding capacity
+- churn or default risk thresholds
+- compliance and tax constraints
+- sales approval thresholds
+- segment eligibility
+
+Boundary conditions should be inspectable, testable, and versioned.
+
+---
+
+## Parameter Classes
+
+### Fixed Parameter
+
+A pricing parameter set by the seller and not negotiable by the customer.
+
+Example: tax treatment, core meter definition, product SKU identity.
+
+### Seller-Controlled Parameter
+
+A parameter the seller may vary by segment, lifecycle phase, or sales policy but that is not directly tuned by the customer in self-serve flows.
+
+Example: list price, standard tier packaging, default contract duration.
+
+### Customer-Tunable Parameter
+
+A non-fixed parameter a customer may adjust within allowed bounds.
+
+Examples: monthly base versus usage mix, commitment length, prepaid balance, support level.
+
+Customer tuning must not create arbitrary discounts. Tunable choices are solved against seller goals and boundary conditions.
+
+### Calculated Parameter
+
+A parameter derived from other parameters by rule or solver.
+
+Example: effective unit price, expected LTV, required prepayment amount, overage rate after tuning.
+
+### Constrained Parameter
+
+A parameter restricted to a domain, range, or conditional dependency.
+
+Example: usage price may only decrease if minimum commitment increases.
+
+### Payment-Provider Parameter
+
+An implementation-specific field required to map the internal model to a provider artifact.
+
+Example: Stripe price ID, billing scheme, aggregate usage mode, tax behavior.
+
+Provider parameters are downstream of the canonical model, not replacements for it.
+
+---
+
+## Evaluation Concepts
+
+### Comparable Customer Lifetime Value
+
+A seller-side comparison metric estimating expected lifetime value for a customer under a given pricing configuration, normalized for comparable segments, usage expectations, risk classes, and contract conditions.
+
+Abbreviation: `average_comparable_customer_lifetime_value`.
+
+Used to ensure customer-tuned models do not reduce seller economics below an approved reference.
+
+### Reference Model
+
+The predefined pricing model used as the baseline for comparison.
+
+The most favorable predefined model available to a customer segment sets the comparison anchor for tuned configurations.
+
+### Required Improvement Factor
+
+A seller-configurable multiplier that tuned pricing must meet or exceed relative to the reference model.
+
+```text
+average_comparable_customer_lifetime_value(tuned_model)
+>= average_comparable_customer_lifetime_value(reference_model)
+   × required_improvement_factor
+```
+
+---
+
+## Governance Concepts
+
+### Pricing Experiment
+
+A controlled test of price, packaging, or model changes to estimate willingness to pay, conversion, retention, or margin effects.
+
+Examples: Van Westendorp, conjoint analysis, Gabor-Granger, A/B pricing tests.
+
+### Dynamic Pricing
+
+Pricing that changes with demand, capacity, inventory, or market signals.
+
+Requires governance, explainability, audit trails, and often customer-visible policy.
+
+### Personalized Pricing
+
+Pricing that varies by customer characteristics, behavior, or predicted willingness to pay.
+
+Benefits revenue optimization but raises trust, fairness, and regulatory concerns.
+
+### Grandfathering
+
+A policy that preserves legacy pricing for existing customers after list prices or models change.
+
+Important for trust-preserving lifecycle migrations.
+
+### Pricing Explainability
+
+The ability to show why a configuration is valid, invalid, recommended, risky, or favorable.
+
+Explanations should reference strategy, boundary conditions, commitments, and comparison metrics—not opaque optimizer output alone.
+
+---
+
+## Primitive Composition Map
+
+Complex pricing models are usually compositions of:
+
+| Primitive | Role |
+| --- | --- |
+| Access fee | Entitlement and predictability |
+| Usage meter | Value alignment and expansion |
+| Included usage | Package framing |
+| Overage | Heavy-usage economics |
+| Tier | Segmentation and packaging |
+| Commitment | Risk offset for concessions |
+| Discount | Promotional or earned price reduction |
+| Credit | Prepaid consumption control |
+| Outcome fee | Value-based alignment |
+| Risk adjustment | Protection against seller exposure |
+| Boundary condition | Economic safety |
+| Lifecycle phase | Strategic context |
+
+---
+
+## Non-Canonical or Context-Dependent Labels
+
+These terms appear in provider dashboards and sales conversations but should be mapped to canonical concepts rather than used as roots in the model.
+
+| Label | Canonical mapping |
+| --- | --- |
+| Stripe Price | Payment-provider artifact for a charge component |
+| Coupon | Discount rule with provider execution metadata |
+| Plan | Customer-facing package; usually Tier + Access fee + entitlements |
+| SKU | Commercial identifier; not a strategy |
+| List price | Seller-controlled reference price before discounts |
+| Negotiated deal | Pricing configuration with bespoke commitments |
+| Take-or-pay | Commitment with penalty or minimum billing rule |
+
+---
+
+## Open Ontology Questions
+
+Tracked for Phase 1 research in `PricingResearchRoadmap.md`:
+
+- Standard naming for hybrid models with multiple active meters
+- Outcome fee evidentiary objects and dispute lifecycle
+- Revenue-recognition mapping for credits, breakage, and prepaid balances
+- Minimum viable primitive set for marketplace and platform fee models
+- Relationship between segment eligibility and personalized pricing
\ No newline at end of file
diff --git a/research/PricingPatternsAndStrategies.md b/research/PricingPatternsAndStrategies.md
new file mode 100644
index 0000000..11bf159
--- /dev/null
+++ b/research/PricingPatternsAndStrategies.md
@@ -0,0 +1,470 @@
+# Pricing Patterns and Strategies
+
+Prepared for the `adaptive-pricing` project.
+
+## Purpose
+
+This document summarizes common pricing models, pricing strategies, B2B/B2C differences, lifecycle considerations, and implications for building an adaptive pricing framework and implementation platform.
+
+Canonical terminology lives in `PricingOntology.md`. Adjacent research is prioritized in `PricingResearchRoadmap.md`.
+
+---
+
+## 1. Pricing Strategy vs. Pricing Model
+
+### Pricing Strategy
+
+Answers:
+
+> Why should this price exist?
+
+Considers:
+
+- Cost floor
+- Value range
+- Market competition
+- Product lifecycle
+- Customer segments
+- Willingness to pay
+- Growth objectives
+- Margin objectives
+- Risk
+
+### Pricing Model
+
+Answers:
+
+> How is the customer charged?
+
+Examples:
+
+- Flat rate
+- Per-seat
+- Usage-based
+- Tiered
+- Freemium
+- Enterprise contract
+- Credits
+- Outcome-based
+- Hybrid models
+
+---
+
+## 2. Common Pricing Models
+
+### Flat Rate
+
+One product, one price.
+
+Strengths:
+
+- Simple
+- Easy to communicate
+- Easy to implement
+
+Weaknesses:
+
+- Poor segmentation
+- Limited expansion revenue
+- Over- or under-monetization
+
+---
+
+### Per-Seat
+
+Pricing scales with users, employees, agents, or accounts.
+
+Strengths:
+
+- Easy budgeting
+- Familiar to enterprise buyers
+
+Weaknesses:
+
+- Discourages adoption
+- Weak fit for AI-heavy products
+
+---
+
+### Usage-Based
+
+Customers pay for consumption.
+
+Examples:
+
+- API calls
+- Documents
+- Emails
+- Storage
+- Compute
+- Tokens
+
+Strengths:
+
+- Aligns revenue with usage
+- Low entry barrier
+
+Weaknesses:
+
+- Revenue volatility
+- Requires metering infrastructure
+
+---
+
+### Tiered Pricing
+
+Customers select from packages.
+
+Examples:
+
+- Basic
+- Pro
+- Enterprise
+
+Strengths:
+
+- Segmentation
+- Upsell paths
+
+Weaknesses:
+
+- Packaging complexity
+
+---
+
+### Volume Pricing
+
+Unit price decreases at higher volumes.
+
+Strengths:
+
+- Supports large customers
+
+Weaknesses:
+
+- Can destroy margins if discounts are not tied to commitments
+
+---
+
+### Graduated Pricing
+
+Each volume band has its own price.
+
+Strengths:
+
+- Smooth incentives
+- Fairer than pure volume pricing
+
+Weaknesses:
+
+- More complex to explain
+
+---
+
+### Stairstep Pricing
+
+Quantity ranges map to fixed prices.
+
+Strengths:
+
+- Predictable billing
+
+Weaknesses:
+
+- Threshold effects
+
+---
+
+### Package / Credit Pricing
+
+Customers purchase blocks of units.
+
+Strengths:
+
+- Budget control
+- Commitment generation
+
+Weaknesses:
+
+- Breakage and accounting complexity
+
+---
+
+### Freemium
+
+Free tier with paid upgrades.
+
+Strengths:
+
+- Acquisition
+- Viral growth
+
+Weaknesses:
+
+- Infrastructure burden
+- Conversion challenges
+
+---
+
+### Trial Models
+
+Temporary access before purchase.
+
+Strengths:
+
+- Reduces uncertainty
+
+Weaknesses:
+
+- Abuse potential
+- Activation challenges
+
+---
+
+### Enterprise / Custom Pricing
+
+Negotiated pricing.
+
+Strengths:
+
+- Flexible
+- Captures high value
+
+Weaknesses:
+
+- Sales overhead
+- Discount sprawl
+
+---
+
+### Outcome-Based Pricing
+
+Customer pays based on achieved outcomes.
+
+Examples:
+
+- Revenue generated
+- Cost saved
+- Tickets resolved
+
+Strengths:
+
+- Strong value alignment
+
+Weaknesses:
+
+- Attribution disputes
+
+---
+
+### Hybrid Pricing
+
+Combination of multiple pricing mechanisms.
+
+Examples:
+
+- Subscription + Usage
+- Platform Fee + Transaction Fee
+- Minimum Commitment + Usage
+
+Strengths:
+
+- Flexible
+- Increasingly dominant
+
+Weaknesses:
+
+- Greater implementation complexity
+
+---
+
+## 3. Pricing Strategies
+
+### Cost-Plus
+
+Price = Cost + Margin
+
+Useful for establishing a cost floor.
+
+---
+
+### Value-Based
+
+Price reflects customer value.
+
+Useful for maximizing economic alignment.
+
+---
+
+### Competition-Based
+
+Price references alternatives in the market.
+
+Useful for positioning.
+
+---
+
+### Penetration Pricing
+
+Low entry pricing to gain adoption.
+
+Best suited for:
+
+- Exploration
+- Introduction
+
+---
+
+### Premium / Skimming Pricing
+
+High initial pricing.
+
+Best suited for:
+
+- Strong ROI
+- Low competition
+- Urgent customer pain
+
+---
+
+### Good-Better-Best Packaging
+
+Multiple tiers designed to segment willingness to pay.
+
+---
+
+### Dynamic Pricing
+
+Prices adapt to:
+
+- Demand
+- Capacity
+- Market conditions
+
+Requires careful governance and explainability.
+
+---
+
+### Personalized Pricing
+
+Prices vary by customer.
+
+Benefits:
+
+- Revenue optimization
+
+Risks:
+
+- Trust
+- Fairness
+- Regulation
+
+---
+
+### Segmented Pricing
+
+Different pricing for different customer categories.
+
+Examples:
+
+- Individual
+- SMB
+- Enterprise
+- Education
+- Nonprofit
+
+---
+
+### Lifecycle Pricing
+
+Different strategies across:
+
+1. Exploration
+2. Introduction
+3. Growth
+4. Maturity
+5. Saturation
+6. Decline
+
+---
+
+## 4. B2B vs B2C
+
+### B2B
+
+Primary concerns:
+
+- ROI
+- Procurement
+- Predictability
+- SLA
+- Compliance
+- Integration
+
+Common models:
+
+- Seat-based
+- Usage-based
+- Enterprise contracts
+- Hybrid models
+
+---
+
+### B2C
+
+Primary concerns:
+
+- Simplicity
+- Trust
+- Immediate value
+- Easy cancellation
+
+Common models:
+
+- Subscription
+- Freemium
+- Family plans
+- In-app purchases
+- Bundles
+
+---
+
+## 5. Implications for adaptive-pricing
+
+Pricing should be represented as composable primitives.
+
+Examples:
+
+- Access fee
+- Usage meter
+- Commitment
+- Discount rule
+- Risk adjustment
+- Lifecycle phase
+- Segment rule
+- Boundary condition
+- Payment-provider mapping
+
+Pricing should be modeled independently from Stripe or other payment providers.
+
+Payment providers execute pricing artifacts.
+
+The adaptive-pricing engine owns:
+
+- Model definition
+- Constraints
+- Simulations
+- Recommendations
+- Explanations
+- Versioning
+
+---
+
+## References
+
+- Stripe Billing Documentation: https://docs.stripe.com/
+- Paddle Pricing Guides: https://www.paddle.com/blog/
+- Chargebee Billing Documentation: https://www.chargebee.com/docs/
+- Reuters coverage on algorithmic pricing regulation: https://www.reuters.com/
+- Research on trial subscriptions: https://arxiv.org/
+- Nature Index article on psychological pricing: https://www.nature.com/
\ No newline at end of file
diff --git a/research/PricingResearchRoadmap.md b/research/PricingResearchRoadmap.md
new file mode 100644
index 0000000..2164ce2
--- /dev/null
+++ b/research/PricingResearchRoadmap.md
@@ -0,0 +1,263 @@
+# 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.
\ No newline at end of file