Files
adaptive-pricing/docs/BoundaryValidation.md
2026-07-02 22:07:56 +02:00

2.3 KiB

Boundary Validation

Status: implementation-facing MVP for ADAPTIVE-WP-0004.

Purpose

This document describes the first explicit boundary engine now available in adaptive_pricing_core.boundary_engine.

The engine turns pricing-policy intent into inspectable validation outcomes instead of leaving viability checks implicit in dashboard review.

Inputs

The validator accepts:

  • a canonical PricingModel
  • a PricingConfiguration describing expected usage, fee assumptions, cost allocation, optional price overrides, and commitment terms
  • a BoundaryPolicy defining hard and soft limits

Constraint Types

Current MVP constraints cover:

  • segment eligibility
  • expected usage variance limit
  • payment fee ceiling
  • cost-floor coverage
  • minimum margin
  • target-margin approval threshold
  • discount exposure ceiling
  • discount approval threshold
  • commitment-backed concession enforcement

Hard constraints reject a configuration. Soft constraints mark it as valid only with approval.

Commitment Logic

The engine treats a concession as any configuration that weakens seller economics relative to the model baseline under the same scenario assumptions.

A concession is considered meaningfully backed only when at least one of these protections is present:

  • minimum monthly turnover at or above modeled monthly revenue
  • prepayment covering at least one modeled month
  • guaranteed platform fee at or above modeled monthly revenue
  • customer-funded onboarding that neutralizes onboarding cost
  • materially longer contract duration
  • reduced cancellation flexibility

Outputs

Validation returns a ValidationResult with:

  • decision: accepted, requires_approval, or rejected
  • valid and requires_approval
  • a human-readable summary
  • machine-readable configuration snapshot
  • machine-readable economics metrics
  • per-constraint results with reasons, thresholds, and suggested actions

Coulomb Adapter

The Coulomb observatory exposes this engine through observatory.boundary.build_boundary_validation().

That adapter currently uses:

  • observed per-period payment fee rate
  • observed AI usage cost
  • observed per-member infrastructure cost allocation
  • conservative default policy thresholds

This is intentionally an MVP policy surface. Later milestones can replace these defaults with seller-managed governance data and richer LTV-aware constraints.