# THIS YOU — Preferred Budget, Not Hard Budget ## Goal Change the product-selection budget logic so that the reader's budget is treated as a **strong preference**, not a hard rejection rule. This applies to: - reader profile structure; - `style_exploration.hard_constraints`; - `style_exploration.soft_preferences`; - AI product-selection prompts; - product validation; - regeneration; - admin review; - hero-input generation. The current Chapter 1 input still places `budget_max_item` inside `hard_constraints`, while the intended behavior is now that the budget is **preferred, but flexible**. --- # Core rule > The reader's per-item budget is a preferred target, not a hard ceiling, unless a future profile setting explicitly marks it as hard. The stylist should try to stay within the reader's stated budget, but may exceed it when the product gives a meaningful editorial, stylistic, fit, quality, or scene-specific advantage. Surprise mode especially may use a reasonable budget exception when it materially improves the look. --- # 1. Remove budget from `hard_constraints` ## Current structure to avoid ```json "hard_constraints": { "height_cm": "185.00", "clothing_size": "S", "shoe_size": "42", "functional_fit": "oversized", "explicit_exclusions": [], "budget_max_item": "100.00" } ``` This incorrectly tells the AI that €100 is a strict maximum. ## New structure ```json "hard_constraints": { "height_cm": "185.00", "clothing_size": "S", "shoe_size": "42", "functional_fit": "oversized", "explicit_exclusions": [] }, "soft_preferences": { "favorite_brands": "Zara, Uniqlo", "style_vibes": "minimal, sporty, Scandinavian", "usual_fit": "oversized", "preferred_budget_max_item": "100.00" } ``` --- # 2. Reader profile field The reader profile may still keep: ```json "budget_max_item": "100.00" ``` for backward compatibility. But its semantic meaning must change to: ```text preferred per-item budget target ``` not: ```text hard maximum price ``` Recommended long-term rename: ```json "preferred_budget_max_item": "100.00" ``` A migration is optional if renaming would create unnecessary breakage. --- # 3. Prompt wording ## Remove / change Avoid wording such as: ```text Hard constraints remain hard: ... any configured hard budget ceiling. ``` unless the system actually supports a separate explicitly-hard budget setting. ## Replace with ```text BUDGET POLICY: The reader's per-item budget is a strong preference, not a hard ceiling. Prefer products within budget, but a product may exceed the preferred budget when the editorial, stylistic, fit, quality or scene-specific gain is meaningful. Do not exceed the budget casually or across the entire look. Any exception should feel intentional and justified. ``` For Surprise mode: ```text SURPRISE BUDGET POLICY: Surprise mode may use a reasonable budget exception when it materially improves the look, while keeping the overall selection believable for the reader. ``` --- # 4. Product selection behavior The selector should rank products using the preferred budget, not reject all products above it. Example: ```text Reader preferred max: €100 per item ``` Candidates: ```text Product A: €89 Product B: €99 Product C: €140 ``` The system should generally prefer A or B. But C is allowed if it is clearly stronger for the final look. --- # 5. Budget exception logic A product above the preferred budget may be accepted when at least one of these is true: - it creates a significantly stronger silhouette; - it completes the editorial concept better; - it has materially better construction; - it solves the scene/function requirement better; - the product category naturally costs more; - it is the strongest available fit for the reader; - it creates the intended Surprise-mode effect; - the alternative products within budget materially weaken the look. The AI should not treat "more expensive" as automatically "better". --- # 6. Avoid runaway overspending Soft budget does **not** mean budget is ignored. Recommended rule: ```text Prefer most products within the reader's target range. Allow occasional justified exceptions. Avoid making the entire outfit meaningfully more expensive than the reader's stated preference. ``` Example: ```text preferred max: €100/item jacket: €89 shirt: €99 trousers: €65 shoes: €140 ``` This is acceptable if the €140 shoes are a deliberate editorial exception. Example: ```text jacket: €190 shirt: €160 trousers: €180 shoes: €220 ``` This should normally be rejected as incompatible with the reader's stated budget preference. --- # 7. No hard pre-HERO rejection Remove logic like: ```text IF product.price > reader.budget_max_item THEN reject product ``` This must no longer block HERO generation. Instead: ```text IF product.price > preferred_budget_max_item THEN mark as budget_exception AND require justification ``` --- # 8. Recommended product result metadata Add optional metadata: ```json "budget_fit": "within_preference" ``` or: ```json "budget_fit": "editorial_exception" ``` Optional explanation: ```json "budget_exception_note": "€140 exceeds the reader's preferred €100 per-item budget, but the shoe provides the strongest low-profile metallic finish for this look and remains a single-item exception." ``` Recommended allowed values: ```text within_preference editorial_exception ``` Do not use: ```text budget_violation ``` because the budget is not hard. --- # 9. Admin UI In admin review, visually distinguish a budget exception without treating it as an error. Example: ```text PRICE €140 Preferred reader budget €100 BUDGET Editorial exception ``` Optional note: ```text Why: Strongest product for this look; single-item exception. ``` The reviewer can still reject or replace it manually. --- # 10. Hero-input generation A selected product may continue into: ```text this_you.personalization_input.v2 ``` when: - it is product-verified; - its regular/base price is verified; - it is stylistically approved; - any budget exception is intentional. A price above the preferred budget must **not** automatically invalidate the chapter. --- # 11. Interaction with regular-price policy Budget evaluation must continue to use the **regular/base non-discounted price**. Example: ```text Regular price: €140 Sale price: €84 Preferred budget: €100 ``` Interpretation: ```text €140 = price used for budget evaluation €84 = ignored for THIS YOU pricing logic ``` Result: ```text Allowed as editorial_exception ``` not: ```text Within budget ``` This preserves the regular-price policy while keeping budget flexible. --- # 12. Current Chapter 1 example Current product: ```text New Balance 204L Regular/base price: €140 Reader preferred budget: €100 ``` This is allowed. Recommended metadata: ```json { "price": 140, "currency": "EUR", "price_basis": "regular_base_non_discounted", "budget_fit": "editorial_exception", "budget_exception_note": "Single-item editorial exception in Surprise mode." } ``` The product does not need to be replaced solely because it exceeds €100. --- # 13. Future hard-budget support If THIS YOU later needs a truly hard limit, model it explicitly. Example: ```json "budget": { "preferred_max_item": 100, "hard_max_item": null } ``` or: ```json "budget_mode": "preferred" ``` Possible modes: ```text preferred hard none ``` Do not infer `hard` merely because a numeric value exists. --- # 14. Acceptance criteria - [ ] `budget_max_item` is no longer passed as a hard constraint. - [ ] AI prompt explicitly states that budget is a strong preference. - [ ] Products above budget are not automatically rejected. - [ ] Above-budget products require an editorial reason. - [ ] Most of the look should still respect the preferred range. - [ ] Regular/base price is still used for budget evaluation. - [ ] Sale price is still ignored. - [ ] A reasonable above-budget product can proceed to HERO generation. - [ ] Admin can see when a product is an editorial budget exception. - [ ] Human review remains mandatory. - [ ] Current Chapter 1 New Balance €140 shoes are valid as an editorial exception. - [ ] Future hard-budget behavior, if added, uses an explicit separate field or mode. --- ## Summary The new rule is: > **Budget guides the stylist; it does not automatically block the stylist.** Keep the reader's target visible and meaningful, but allow deliberate exceptions when they materially improve the final look.