Budget Set Reconstruction¶
Reconstruction procedure — instantiates Revealed Preference Validation Against Indifference Curves
Rebuilds the set of options a chooser could actually afford and reach at the moment of choice, so a selection can be read as a preference rather than as a constraint.
A revealed choice means nothing on its own — it only carries information relative to what else was on the table and affordable when it was made. Budget Set Reconstruction is the discipline of rebuilding that table: for each observed choice, it recovers the full menu that was actually available, the prices and budget in force, and the constraints that were binding. Its single defining idea is that a preference can only be inferred against a known feasible frontier; picking the store brand tells you nothing if the national brand was out of stock or unaffordable that week. Everything downstream — substitution rates, consistency tests, indifference contours — is only as trustworthy as the option set this step reconstructs beneath it.
Example¶
A supermarket chain mines two years of loyalty-card data and notices that one segment of shoppers "always chooses" the house-brand pasta over the leading national brand. The tempting read is a strong brand preference worth exploiting with a price rise. Budget Set Reconstruction stops that inference cold. Working choice by choice, it rebuilds each trip's feasible set from the store's own shelf-availability and pricing logs: on roughly a third of those visits (illustrative) the national brand was out of stock, on many others it sat outside the basket's evident budget, and during the handful of weeks it was both in stock and on promotion, that same segment switched to it readily.
The reconstructed record reframes the whole picture. What looked like preference was largely a constraint artifact — availability and price, not loyalty. The output is a per-trip table pairing the chosen item, the options genuinely present and affordable, and the active budget, with a flag on every occasion where the budget was binding versus slack. That table is what lets a later step estimate the shopper's real willingness to pay instead of mistaking a stock-out for a taste.
How it works¶
The procedure runs one loop per observed choice:
- Log the selection. Record the option chosen with its timestamp, quantity, and price paid — the raw observed choice.
- Reconstruct the menu. Rebuild the set of alternatives that actually existed at that moment, deliberately excluding options that were absent, sold out, or unreachable, and imputing gaps only where availability data is missing.
- Recover the context. Attach the prices, budget envelope, and hard constraints (time, eligibility, minimum order) in force at that instant.
- Mark the binding constraints. Note which choices hit a wall — the only affordable option, a stock-out, a rationing rule — versus which had genuine slack, because a choice made with slack reveals far more preference than a corner solution.
Tuning parameters¶
- Feasibility strictness — what counts as "available": physically present, or present-and-known-to-the-chooser. Strict definitions shrink the set and lower false preference signal; loose ones risk crediting options the chooser never saw.
- Reconstruction horizon — how far back the record is rebuilt. Longer horizons add statistical power but drag in stale prices and shifted assortments.
- Constraint breadth — price-only, or price plus time, attention, and eligibility. Broader constraint models catch more artifacts but demand more data.
- Imputation aggressiveness — how freely missing availability is filled in. Aggressive imputation completes the set but can fabricate options that were never really there.
- Budget granularity — a single spend cap versus a modeled, category-specific envelope.
When it helps, and when it misleads¶
Its strength is that it converts a raw behavior log into evidence that can actually bear weight: by separating "chose freely among these" from "had no real alternative," it prevents the single most common error in preference inference — reading a constraint as a taste. It is the foundation the rest of the validation stands on.
Its failure mode is that the true feasible set is never fully observable. Search costs, unadvertised substitutes, and options the chooser considered but that left no data trace all sit outside the reconstruction, and reconstructing too generously — assuming an option was available when the chooser never encountered it — manufactures phantom constraints just as surely as a stock-out hides real ones. The classic misuse is treating a corner solution as a strong preference: a shopper who bought the only thing on the shelf has revealed almost nothing.[1] The guarding discipline is to carry the binding-versus-slack flag downstream and to weight choices made under slack far more heavily than choices made against a wall.
How it implements the components¶
Budget Set Reconstruction realizes the archetype's data-foundation layer — the components that establish what the choice was and what it was against:
observed_choice_record— logs each selected option with its price, quantity, and timestamp.feasible_option_set— reconstructs the alternatives genuinely available at the moment of choice, excluding the absent and unreachable.constraint_and_budget_context— recovers the prices, budget, and binding constraints that framed the decision.
It does not re-express those options as comparable attribute bundles (attribute_bundle_model) — that is Choice Bundle Normalization — nor infer the trade-off rates behind the choice (revealed_substitution_trace), which is Marginal Substitution Estimator. This step supplies the raw material both of them consume.
Related¶
- Instantiates: Revealed Preference Validation Against Indifference Curves — this is the front-end that grounds every later inference in a known feasible set.
- Sibling mechanisms: Choice Bundle Normalization · Marginal Substitution Estimator · Indifference Region Visualization · Dominance Violation Scan · Revealed Preference Consistency Matrix · Preference Reversal Probe · Choice Architecture Confound Audit · Stated vs Revealed Gap Report · Ethical Preference Inference Review
Editorial Notes¶
Form Classification¶
Form family: Analysis, Modeling & Optimization
Rationale: Rebuilds the set of options a chooser could actually afford and reach at the moment of choice, so a selection can be read as a preference rather than as a constraint, making its operative form a computation or analytic transformation that produces an inference, comparison, or optimized result.
Independent corroboration: The frozen evidence defines Budget Set Reconstruction as 'Rebuilds the set of options a chooser could actually afford and reach at the moment of choice, so a selection can be read as a preference rather than as a constraint', so its operative form is Analysis, Modeling & Optimization.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Economics & Finance
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Revealed-preference economics requires reconstructing the feasible budget set, prices, availability, and binding constraints that surrounded each observed choice before preference can be inferred.
Related originating lineages:
- Statistics & Experimental Design — Statistics contributes sampling, uncertainty, blocking, blinding, controlled comparison, or inferential discipline used here.
Review resolution: Economics and finance is the agreed primary lineage through reconstructing feasible consumption or allocation sets from observed prices, resources, and constraints. Statistics supports estimation under incomplete evidence; the specialized technique is established rather than newly synthesized.
Review outcome: Reconciled after independent review; high confidence.
References¶
[1] Paul Samuelson's revealed preference theory (1938) rests on exactly this premise: choosing bundle A when B was affordable reveals A is preferred to B — but the inference is empty unless B really was in the budget set. Reconstructing that set is what makes the "was affordable" clause checkable rather than assumed. withdrawn registry ↩