Plan Configurator and Structured Lead Intent

1) The problem this lesson solves

If a configurator stores only cards, display labels and a rendered total, you cannot later prove which plan, price, quantity and options the prospect selected or why that combination was valid.

2) Lesson boundary

The owned artifact is Plan Configurator Intent Contract v1. This lesson does not own the preceding information architecture or the following CRM handoff and performs no live checkout, billing or production mutation.

3) Fact: Product and Price are different objects

Stripe models products and prices separately. A Product identifies what is sold while a Price carries amount, unit and billing terms. Do not replace product_id and price_id with a human-facing plan label.

4) Fact: pricing model and price lifecycle need durable identity

Stripe documents flat-rate, per-seat and usage-based models. Current Stripe guidance says a changed amount should use a new Price while the previous Price can be archived to preserve historical records. A stored total without price_id and price_version is therefore weak reconstruction evidence.

5) Fact: form-like controls need identifiable labels and feedback

W3C guidance calls for labels or instructions for inputs and identifiable interaction feedback. That governs usable controls; it does not define plan eligibility, dependency rules or pricing.

6) Inference: reconstruct the submission without trusting the UI

If the only stored value is “Pro Annual — 490,” a later rename or price change makes the governing commercial object ambiguous. Auditability requires stable identifiers, version evidence and typed validation state.

7) Design: preserve session and selection identity

config_session_id ties a submission to the exact plan, price, quantity and options selected at that time. Human labels are useful presentation but are not durable keys.

8) Separate price identity from the estimated total

estimated_price is an output. price_id, pricing_model, billing_period and price_version are contractual inputs. A cached total must not hide a version mismatch.

9) Evaluate dependency and incompatibility explicitly

For example, a new add-on may be allowed only on annual billing. A monthly selection should become INVALID_DEPENDENCY; hiding the option in UI is not a substitute for retained constraint evidence.

10) Preserve quantity and pricing-model semantics

The number 25 could mean seats or a usage quantity. quantity_dimension records what the quantity means so price and intent can be reconstructed correctly.

11) Keep eligibility and quote-required distinct from acceptance

Enterprise can be QUOTE_REQUIRED, while eligibility can remain UNKNOWN. Missing evidence must not be coerced into eligible or invalid; preserve a bounded non-success state.

12) Core Evidence Contract

The artifact has 22 dimensions, 16 critical. The compact table shows a baseline, an invalid dependency and a historical reconstruction; JSON/CSV retains the complete field map.

13) Build Structured Lead Intent from selections

intent_payload is derived from plan, quantity, options, constraint results and validation state. Do not reverse-engineer intent from a headline, card title or rendered total.

14) Typed states prevent false certainty

ACCEPT requires sufficient evidence. QUOTE_REQUIRED, HOLD_ELIGIBILITY_UNKNOWN, HOLD_PRICE_STALE, HOLD_PRICE_VERSION_MISMATCH, INVALID_DEPENDENCY and BLOCKED_EVIDENCE_MISSING are valid outcomes too.

15) Lab and transfer

The lab has eight fixtures and 48 assertions. In transfer, a usage-based add-on appears, an old price is archived and one option becomes annual-only. A new submission must not reuse the old price, while a historical lead is reconstructable only with exact identifiers, submission time and version evidence.