• Source: a Python list concatenating category sub-lists (product-type exclusions, generic terms, states, cities, colleges, countries, sports terms, and pro rosters — soccer/football/basketball/baseball/hockey) — data_prep/heraldic_filter.py
• Role: pre-inference filter — a title hitting a team roster (NFL/NBA/MLB/NHL/soccer), a US city, a college/NCAA, or an Olympic-country term is dropped before YOLO ever runs. These carry prescribed team colors, not the brand's own design choices. Matched case-insensitively as \b(word)\b against both title and title_second.
• How to tune: discover-heraldic-keywords · validate-heraldic-filter
• Tuning output: 📄 candidates.csv (brand-skew-ranked additions) · 🖥 labeler.html (blind hand-labeling, prediction hidden to avoid anchoring) · 📄 analysis.txt (precision / recall / F1 + Wilson CIs). Last measured: 95.6% recall, 81.8% precision on 800 labels.

• Source: a per-brand dict (title word → Fashionpedia class synonyms) — data_prep/keyword_maps.py
• Role: picks which detected garment is the target. A title word (“hoodie”, “polo”) maps to a Fashionpedia class, and the largest YOLO mask of that class becomes the hero garment; a title with no mapped word drops the product. Recognition coverage ~80–98% by brand (98% Nike).
• How to tune: validate-keyword-map
• Tuning output: 📄 per-brand coverage % over denominator + a list of uncovered titles (mirrors the SQL regex-inversion behind the original 98% Nike figure)

• Source: float constants — data_prep/segment.py
• Role: attribute-merge gate. Once the hero garment is chosen, each detected attribute (sleeve, collar, cuff, hood, pocket, zipper, …) or secondary garment is folded into the hero mask if its IoU with the hero box > 0.15 OR its overlap with the dilated hero mask > 0.1 — capturing contrasting sleeves/collars that are part of the garment's palette. Lower = more aggressive merging.
• How to tune: no command — hand-judged. Read the per-product merge line (candidates evaluated / merged / Avg IoU / Avg Overlap) in processing_log.txt, compare the merged masks against the source images, adjust the constants, and re-run.
• Tuning output: 📄 processing_log.txt (per-product merge counts + IoU/overlap averages), inside each segmentation output folder

• Source: int constant — data_prep/cluster.py
• Role: dominant colors extracted per garment. K-means (k=5) runs on the garment's masked pixels in LAB space; the 5 centroids and their coverage % become that product's palette and feed every downstream deliverable. Clustering is done in LAB (not RGB) so Euclidean distance tracks perceptual difference.
• How to tune: no tuning command — 5 is a fixed design choice. There is no automated grader, and changing it would ripple through every downstream stage, so it's held constant.

Also configures this stage — see the shared tunables section for full detail.

• Source: int constant (CIEDE2000 ΔE diameter) — palette_explorer/build_color_clusters.py
• Role: HAC Pass 1 diameter: products within ΔE = 8 (CIEDE2000) form one cluster. Intentionally tight (over-discriminative) to keep clusters pure where dissimilar colors sit close; the resulting over-segmentation is corrected downstream by zone merging.
• How to tune: Iterative human-review loop. Run consolidate-colors <brand> --gender <g> to build clusters at the current value, then review-cluster-quality <brand> --gender <g> to render that same segment for inspection. Adjust the constant and re-run both until clusters hold together by eye.
• Tuning output: A self-contained HTML page at outputs/diagnostic_cluster_review/<brand>_<gender>/cluster_review.html — one tab per cluster, each showing that cluster's 20 most color-diverse products (farthest-point CIEDE2000 sample, chosen to surface misfits).

• Source: the hand-built reference file outputs/nike_mens/cluster_zones.json — cluster→zone assignments created via build-zones. (The ~9 files assign-zones writes for other segments are its outputs, not this tunable.)
• Role: HAC Pass-1 clusters are deliberately over-discriminative; zones merge the near-identical ones into human-meaningful groups. assign-zones trains a Random Forest on the reference labels and propagates that merging to the remaining ~9 brand/genders.
• How to tune: hand-label nike/mens once — build-zones nike --gender mens → label in the tool → export — then assign-zones <b> <g> propagates it to the other ~9 segments. (To use a different segment as ground truth, change TRAINING_BRAND / TRAINING_GENDER in palette_explorer/assign_zones.py.)
• Tuning output: cluster_zone_builder.html (the labeling tool)

• Source: float constant CONFIDENT_MERGE_PROB = 0.80 — palette_explorer/assign_zones.py. (scipy's linkage merges on distance, so the code derives 1 − 0.80 = 0.20 inline at the merge step — there's no separate distance constant.)
• Role: the RF scores each pair of target clusters with a “same-zone?” probability; agglomerative complete-linkage merges only pairs it's ≥ 80% confident about. Higher = stricter (more, smaller zones); lower = looser (fewer, broader zones).
• How to tune: run assign-zones nike --gender mens (self-validation). Read the printed ARI/NMI agreement scores; if they're too low, use the Manual-zones vs Auto-zones counts to see whether the RF is over-merging (fewer auto zones) or under-merging (more), adjust CONFIDENT_MERGE_PROB, and re-run until the scores plateau — before propagating to the other segments
• Tuning output: auto_cluster_zones.json (the RF's version, saved for optional cluster-level inspection — the tuning decision is read from the console ARI/NMI)

• Source: a default argument radius=5 on load_brand_data() (palette_explorer/palette_explorer.py:239), passed explicitly at its only call site (palette_explorer.py:2983) — so editing the signature default alone changes nothing; edit the call. The grouping logic is find_ab_groups() in palette_explorer/hue_family_grouping.py, the single definition shared with tune_hue_family_rows.py so the explorer and its tuner can't drift.
• Role: HAC Pass 2 — complete-linkage grouping of zone centroids in the a*b* plane. Every pair inside a family must be within 5 a*b* units of every other (no chaining). Purely presentational: it sets the row scaffolding of the layout and never touches cluster or zone data.
• How to tune: run tune-hue-family-rows <b> --gender <g>, which sweeps RADII_SWEEP = [5, 7, 10, 14] (tune_hue_family_rows.py:37) and renders one full column preview per radius for that segment. Compare by eye, then write the chosen value into the radius= argument at the call site and re-run palette-explorer.
• Tuning output: outputs/<b>_<g>/hue_family_tuning/ab_neighbor_diagnostic.html — all four radii in one page, each row an L*-sorted swatch strip labeled with its zone count and L* span, plus the singletons — and ab_column_preview_R5.html, _R7, _R10, _R14 in the same folder, each a full column preview with a click-through thumbnail panel (thumbnails come from the segment's thumbs/, so they appear only once assign-zones or build-zones has generated them).

• Source: five module-level constants in archetype_taxonomy/classify_archetypes.py — DOMINANCE_RATIO=2.0 (:82), SECONDARY_COVERAGE_THRESHOLD=10 (:87), and the hue-aware significance triple SIGNIFICANCE_THRESHOLD_OPPOSITE_HUE=1 (:77), SIGNIFICANCE_THRESHOLD_DIFFERENT_HUE=3 (:78), SIGNIFICANCE_THRESHOLD_SIMILAR_HUE=5 (:79). They're read directly by filter_significant_clusters() (:204) and classify_structure() (:258); no CLI override, edit the constants.
• Role: Post-merge, the classifier walks a two-step decision tree on each product's merged palette. First filter_significant_clusters() keeps only colors whose coverage beats a hue-dependent significance floor — a color whose hue is >90° from the dominant needs ≥1% coverage to count, >45° needs ≥3%, similar hue needs ≥5% (:242-250). Then classify_structure() labels the surviving palette: 1 color → MONO; 2 colors with ratio ≥ DOMINANCE_RATIO → DOM_ACC else DUAL_BAL; 3+ colors with combined secondary coverage < SECONDARY_COVERAGE_THRESHOLD → DOM_ACC (tiny accents), else MULTI_DOM if dominant ≥ 50% else MULTI_BAL (:293-300).
• How to tune: run archetype-review to draw (or reuse) a stratified validation sample and render the browser labeling tool; hand-label archetype and merge, export from the tool as validation_results_hsb.csv, then run validate-archetypes to score. Reuse is the default — the sample is redrawn only with --resample, so the labels you already have aren't orphaned by an accidental rebuild (review_archetype_labels.py:16-20). Adjust the constants, re-run archetypes, re-open the tool (regenerated cheaply every review), re-validate.
• Tuning output: archetype_taxonomy/outputs/archetype_validation.html (the labeling tool — one row per sampled product, buttons for the archetype guesses, a merge-labeling panel) and archetype_taxonomy/outputs/archetype_accuracy.txt (the validate-archetypes report — overall accuracy with a Wilson 95% CI, 5-class confusion matrix, per-class precision/recall/F1, and the top misclassification flows, validate_archetype_classification.py:248-251).

Also configures this stage — see the shared tunables section for full detail.

• Source: int constant — drift/downsample.py:14
• Role: archive compression — how far archives are compressed before drift
• How to tune: no command — edit N_CLUSTERS by hand at drift/downsample.py:14 and re-run downsample + compute-drift for the affected brand(s). The value is a compute/fidelity trade: 1900 was picked empirically for ~10k-product archives (250k raw palette points → ~62 B pairwise comparisons before compression, ~3.6 M after). Lowering it speeds Sinkhorn but coarsens the distribution fed to drift; raising it hurts drift compute time quadratically. Smaller archives (<1k products) can drop to 500–1000.

• Source: int constants in shared/palette_merge/palette_merge.py — HUE_MERGE_THRESHOLD = 25° (max hue gap to merge two chromatic colors), LOW_CHROMA_MERGE_THRESHOLD = 15 (chroma below which a color counts as low-chroma/near-neutral), LOW_CHROMA_MAX_DELTA_L = 35 (the lightness guard), plus NEUTRAL_CHROMA_THRESHOLD = 8 (chroma below which a color has no usable hue). Shared — the same merge primitive also builds the palettes the archetype classifier consumes, so changing it moves two deliverables.
• Role: per-product merge that runs before HAC Pass 1. For each product it collapses colors that are just lighting artifacts (highlights/shadows) into one and keeps the dominant survivor as that product's color for clustering. Two low-chroma/neutral colors merge only if their lightness is within LOW_CHROMA_MAX_DELTA_L (35) — this keeps black+white from collapsing together; two chromatic colors merge if their hue is within HUE_MERGE_THRESHOLD (25°), with no lightness guard — which is why navy over-merging into royal blue is a known, unfixed limitation, not something these thresholds prevent.
• How to tune: data-driven, then by hand.
  ① Build the labeling tool: run archetype-review --strata pair-features — one command that classifies (if needed), draws a boundary-oversampled sample (deliberately loaded with color pairs sitting near the hue/chroma/ΔL thresholds, which fits merge-rule tuning far better than the default archetype-stratified sample), and renders archetype_validation_pairfeatures.html (separately named so it can't clobber an archetype-accuracy sample). The default --strata archetype also captures merge labels in passing, but under-samples the ambiguous pairs this decision hinges on.
  ② Label: open that page and click each color swatch to cycle it into the right group (which of a product's colors are really the same); export merge_labels_all_brands.csv.
  ③ Fit + apply: run tune-merge-rules --input merge_labels_all_brands.csv --propose-constants — it scores the live merge rule against your labels and proposes new values in the shape of the constants (e.g. HUE_MERGE_THRESHOLD 25 → 27, acc 94.7% → 95.1%) with a cross-validation guard. Edit the constants by hand in palette_merge.py; the tool never writes them.
• Tuning output: outputs/merge_rule_discovery/ — the proposals (merge_constant_proposals.txt, merge_constant_sweep.csv), decision-boundary HTML plots (labeled pairs against hue-difference and ΔL), and pairwise_features.csv. Adding --fit-tree instead also writes a decision tree (merge_rules_discovered.txt).