12–13. Operations — CatWing Pipeline Design

12. UI Change Impact Analysis

The UI allows users to modify settings, configuration, and topology at any time on production. Every change takes effect on the next pipeline run — there is no mid-run hot-reload. This section documents the chain of reactions each UI change triggers across pipeline steps.

Read-time resolution: All *_settings and location_relationships tables are append-only (§9a convention). The pipeline always reads the latest row per entity (ORDER BY created_at DESC LIMIT 1). A user saving a new setting inserts a new row; the previous row remains as audit history. The pipeline picks up the new value on its next run automatically.

Impact severity levels

Level	Meaning
CASCADE	Change propagates through 4+ pipeline steps, affects forecasts AND recommendations. Requires full recomputation from the earliest affected step.
MODERATE	Change affects 2–3 steps, typically from inventory optimization onward.
LOCAL	Change affects a single step or only final output formatting.
GATE	Binary on/off — either includes or excludes an entity from the entire pipeline.

12a. Product Settings (`product_settings`)

Field	Severity	Steps affected	Chain of reactions
`enabled_for_processing`	GATE	5 → 6 → 7 → 8 → 9 → 10 → 11 → 12	Product excluded from all pipeline processing. No `product_behaviors` computed (Step 5), no assortment evaluation (Step 6), no demand estimation (Step 7), no feature rows (Step 9), no forecasts, no recommendations. Existing historical data remains but is no longer refreshed. All product×location pairs for this product go dark. Re-enabling triggers a cold start — first run has no lag features or rolling statistics.
`first_order_qty`	LOCAL	12	Recommender uses this qty for the first PO of a newly launched product (no historical demand yet). Only affects `po_recommendations.recommended_qty` for new products. No upstream impact.
`package_qty`	LOCAL	12	PO qty rounded up to nearest package multiple: `ceil(recommended_qty / package_qty) × package_qty`. Only affects final PO qty. No upstream impact.
`minimum_order_qty`	LOCAL	12	PO qty floored: `max(recommended_qty, minimum_order_qty)`. Can inflate small orders. No upstream impact.
`optimal_order_qty`	LOCAL	12	Target qty for economic order sizing. Recommender may snap to this value when forecast-based qty is close. No upstream impact.

12b. Product-Location Settings (`product_location_settings`)

Field	Severity	Steps affected	Chain of reactions
`enabled_for_location`	GATE	5 → 7 → 8 → 9 → 11 → 12	Product×location pair excluded from pipeline. No `product_location_behaviors` for this pair (Step 7), no stats aggregation contribution (Step 8), no feature row (Step 9), no inventory target (Step 11), no PO/TO recommendation (Step 12). Other locations for the same product are unaffected. The product's global behaviors (Step 5) still include this product but the per-location drill-down is suppressed. Re-enabling triggers cold start for this pair only.

12c. Supplier Settings (`supplier_settings`)

Field	Severity	Steps affected	Chain of reactions
`operate`	GATE	5 → 6 → 7 → 9 → 11 → 12	Supplier excluded from pipeline. All products from this supplier lose: `supplier_behaviors` (Step 5), assortment evaluation (Step 6), demand estimation for supplier-linked pairs (Step 7), feature engineering (Step 9), inventory targets (Step 11), PO recommendations (Step 12). TO recommendations between locations may still include these products (TOs don't depend on the supplier). Broad blast radius — a single supplier may cover hundreds of products.
`reorder_time_days`	CASCADE	5 → 11 → 12 → UI	Full cascade. Step 5 writes `product_behaviors.reorder_time_weeks` → Step 11 reads `R` (review cycle) in all 9 store strategy formulas: `target = f(L+R, μ, σ)` → changes `inventory_targets.target_stock`, `reorder_point`, `safety_stock` → Step 12 reads targets in PO formula: `PO = max(0, demand_hz + dc_target − network_inv)` → changes `po_recommendations.recommended_qty`. UI demand accumulation also changes: reorder-time-level sums `predicted_qty` over `lead_time + review_cycle` days (§11 convention) → Redis cache must be invalidated for all affected products.
`lead_time_min_days`	CASCADE	5 → 11 → 12 → UI	Same cascade as `reorder_time_days`. Step 5 writes `product_behaviors.lead_time_weeks` → Step 11 reads `L` (lead time) in strategy formulas → inventory targets change → PO recommendations change. Also affects confidence scoring (s1: data maturity component uses lead time). Redis cache invalidation for affected products.
`lead_time_max_days`	CASCADE	5 → 11 → 12 → UI	Same cascade as `lead_time_min_days`. Used for safety stock upper bounds and worst-case planning in some strategies.
`min_order_amount`	LOCAL	12	PO value must exceed this threshold. May cause order batching — small POs deferred until accumulated value reaches minimum. Only affects final PO output.
`free_limit_transport`	LOCAL	12	Threshold above which transport cost is zero. May influence PO consolidation decisions.
`transport_cost_min` / `transport_cost_max`	MODERATE	12	Factors into overage cost (Co) in newsvendor calculations: `Co = holding_cost + transport_cost_per_unit`. Changes `critical_ratio = Cu/(Cu+Co)` → changes quantile selection → changes recommended qty. Affects Tier 2 and Tier 3 PO recommendations.
`backorder_expiry_days`	MODERATE	5, 12	Products on backorder past this age may be treated as unavailable in supplier availability scoring (Step 5). Affects `product_behaviors.supplier_availability_score` → influences phase-out recommendations (Step 6) and PO suppression (Step 12).
`payment_terms`	LOCAL	—	Informational/display only. No pipeline computation depends on this. May be used in UI for cash flow reporting.

12d. Location Settings (`location_settings`)

Field	Severity	Steps affected	Chain of reactions
`monitor`	GATE	5 → 7 → 8 → 11 → 12	Location excluded from monitoring. No `location_behaviors` (Step 5), no demand estimation for any product at this location (Step 7), no stats aggregation contribution (Step 8), no inventory targets (Step 11), no PO/TO recommendations involving this location (Step 12). Products at other locations unaffected. Warning: disabling monitoring for a warehouse affects all downstream stores in the supply chain.
`recommend_orders`	MODERATE	12	Location excluded from PO/TO generation only. Behaviors (Step 5), demand estimation (Step 7), and inventory targets (Step 11) are still computed — the location remains monitored and visible in dashboards. Only the final recommendation output is suppressed. Useful for locations in transition or manual-ordering mode.
`is_main_warehouse`	CASCADE	11 → 12	Changes echelon assignment. If set to `true`: location evaluated with 5 central warehouse strategies (target fill rate ≥95%, review cycle Mon/Wed/Fri). If `false`: evaluated with 9 store strategies (target fill rate ≥85%, review cycle Mon/Thu). Complete recomputation of `inventory_targets` for all products at this location. PO formula switches between store-level and warehouse-level logic. TO recommendations recomputed (network topology interpretation changes).
`office_id`	LOCAL	—	Grouping/display only. Used in UI to filter locations by office. No pipeline impact.

12e. Location Topology (`location_relationships`)

Highest blast radius. Topology changes redefine the physical supply chain graph. Every downstream computation that depends on "which warehouse supplies which store" is affected.

Field	Severity	Steps affected	Chain of reactions
Adding a new relationship	CASCADE	11 → 12	New supply edge created. The child location now receives replenishment from the parent. Step 11: inventory strategies recomputed for child — new `L` (lead time from this parent) enters all formulas. Step 12: PO formula's `network_inv` now includes this parent's stock; `store_excess` and `dc_target` recomputed. TO recommendations may now suggest transfers along this edge. All products at the child location get new recommendations.
Ending a relationship (`effective_to` set)	CASCADE	11 → 12	Supply edge severed. Child location loses its replenishment source. Step 11: if no other parent exists, strategies that depend on `L` (lead time from parent) lose their input — may fall back to supplier-direct lead time. Step 12: `network_inv` no longer includes the former parent's stock → PO quantities increase to compensate. TO recommendations along this edge cease. Potential stockout risk if no alternative supply path exists.
`parent_location_id` / `child_location_id`	CASCADE	11 → 12	Reroutes the supply chain. Equivalent to ending one relationship and creating another. Both the old child (loses a source) and new child (gains a source) are affected. Network inventory recalculated for both paths.
`lead_time_days`	CASCADE	11 → 12 → UI	`L` in all strategy formulas for the child location: `target = f(L+R, μ, σ)` → `inventory_targets` change → `po_recommendations` change. Also changes UI demand accumulation (reorder-time-level = `lead_time + review_cycle`). Redis cache invalidated for all products at child location.
`transfer_cost`	MODERATE	12	Factors into TO recommendation cost-benefit analysis. Higher transfer cost → fewer TO suggestions along this edge. May shift transfers to alternative edges with lower cost.
`relationship_type`	CASCADE	11 → 12	Alters how the pipeline interprets this edge (e.g., DC→store vs. warehouse→DC). May change echelon assignment for the child location, triggering a complete strategy set switch.

12f. Cascade Summary

UI change
 │
 ├── GATE changes (enabled_for_*, operate, monitor)
 │    └── Entity excluded/included → all downstream steps skip/resume for that entity
 │
 ├── CASCADE changes (lead times, reorder times, topology, echelon assignment)
 │    └── Step 5 (behaviors)
 │         └── Step 11 (inventory targets)
 │              └── Step 12 (recommendations)
 │                   └── UI (demand accumulation via Redis)
 │                        └── Redis cache invalidation required
 │
 ├── MODERATE changes (transport costs, backorder expiry, recommend_orders)
 │    └── Step 12 (recommendations) or Step 5 + 12
 │
 └── LOCAL changes (order qty params, payment_terms, office_id)
      └── Step 12 only (or no pipeline impact)

Redis cache invalidation: Any CASCADE or GATE change must invalidate cached UI calculations for all affected product×location pairs. The API layer should detect setting changes by comparing created_at timestamps against the cache generation timestamp. Stale cache entries must be evicted or recomputed on next access.

13. Recommended Indexes

Convention — recommended indexes: FKs used in JOIN or WHERE clauses should be indexed. This section lists composite and non-obvious indexes not already implied by PK/UK constraints.

Table	Index	Rationale
`demand_forecast_products`	`(demand_forecast_id)`	Join to parent forecast
`demand_forecast_products`	`(product_id, location_id)`	Per-product-location lookup
`product_location_behaviors`	`(location_id, snapshot_date)`	Time-range scans by location
`sales_order_lines`	`(product_id)`	Revenue/volume by product
`sales_order_lines`	`(sales_order_id)`	Order detail joins
`purchase_order_lines`	`(product_id)`	Open PO by product
`purchase_order_lines`	`(purchase_order_id)`	PO detail joins
`receiving_order_lines`	`(product_id)`	Receipt history
`store_order_lines`	`(product_id)`	Store order by product
`transfer_order_lines`	`(product_id)`	Transfer by product
`inventory_quantities`	`(product_id, location_id, snapshot_date)`	Stock lookup (also compound UNIQUE)
`product_behaviors`	`(product_id, snapshot_date)`	Behavior lookup (also compound UNIQUE)
Stats tables (all 16)	`(location_id, period_start)`	Dashboard time-range queries
`product_settings`	`(product_id)`	Latest-row lookup
`supplier_settings`	`(supplier_id)`	Latest-row lookup
`location_settings`	`(location_id)`	Latest-row lookup
`product_location_settings`	`(product_id, location_id)`	Latest-row lookup
`data_quality_checks`	`(data_quality_run_id)`	Per-run check lookup
`data_quality_check_reports`	`(endpoint, run_date)`	Trend queries by endpoint

← 11. Pipeline Steps Summary →