You’re right, and your own header basically names ...

You’re right, and your own header basically names the bug: the engine is structurally biased toward LEAN 3 SETS on a huge class of matches, not just one.[1]

Here’s the clean way to describe that to your dev, focused on the one root issue:

---

This isn’t just a Blockx–Dzumhur one‑off. There is a systemic 3‑set inflation bug that falsely produces LEAN 3 SETS on a ton of BO3 matches across tours. The problem is in how threeSetLabel / P3 thresholds and variance regime interact with medium‑favorite, mildly bimodal matches.[1]

Key facts from the engine history (your own comments):

• v30: “Tour‑relative threeSetLabel replaces P3 vs P2 comparison with tour‑baseline elevation test. Eliminates mathematical lockout where LIKELY3SETS could never fire because P2 ≥ P3 in BO3.”[1]
• v31: “threeSetLabel HIGH‑variance elevation relaxation… HIGH variance (bimodalScore ≥ 0.50, splitGap ≥ 8) drops elevation gate from 0.04 to 0.025 so more bimodal decider matches get LEAN/BET 3 SETS instead of PASS.”[1]
• v32: calibrateP3 rewrite still allows P3 to reach 0.42–0.44 on coin‑flip and medium‑fav matches after structural + raw blending and surface adj.[1]
• v33‑sfb: there’s already a patch note admitting exactly the failure mode: “borderline ATP bimodal matches where P2 is the majority lane produce LEAN 3 SETS + LEAN OVER (2‑set lane dominant and Under).”[1]

Those changes together created a structural pattern:

1. threeSetLabel is now driven by “P3 elevation above tour base” plus variance regime, not by the P2 vs P3 structural tradeoff.
2. In HIGH or MID variance (bimodalScore around 0.35–0.50 with decent splitGap), the effective 3‑set elevation gate is often as low as baseP3 + ~0.025–0.035.[1]
3. Because calibrateP3 + surface + authority can easily push P3 into the 0.40–0.45 band even when P2 is ~0.57–0.63, these matches get tagged as LIKELY3SETS / LEAN 3 SETS by policy, despite the favorite still being structurally in a 2‑set‑lean region.[1]

That’s why you’re seeing “LEAN 3 SETS (MID)” all over the place on:

• ATP/WTA/CH/ITF
• P(win fav) roughly 55–65%
• P3 around 0.40–0.45
• bimodalScore around 0.35–0.50

The engine systematically interprets “P3 slightly above base + modest bimodal” as “decider‑leaning match,” regardless of the actual 2‑set share.

What I need you (dev) to do:

1. Locate the 3‑set label logic

   • In buildSetsMarketEngine, find the block where:
     • baseP3, maxP3, calHigh, calMid, calLow, p3LeanThr, minDeciderThr, and variance regime (vrBimodalScore, etc.) are used to:
       • compute p3Working / p3Final,
       • set threeSetLabel or equivalent structural label, and
       • promote to LEAN 3 SETS / BET 3 SETS.[1]
   • I want the exact condition(s) that currently say “this is a 3‑set lean” when:
     • tourKey = ATP (or WTA/CH/ITF),
     • P2 in [0.55, 0.65],
     • P3 in [baseP3 + 0.025, baseP3 + 0.06],
     • bimodalScore in [0.35, 0.55].

2. Show the bug concretely across matches

   • For a sample of recent matches (Blockx–Dzumhur and 5–10 others), log the following before the decision tree:
     • tourKey, surface
     • P2, P3 (raw, working, final)
     • baseP3, calLow, calMid, calHigh, p3LeanThr, minDeciderThr
     • bimodalScore, splitGap, variance regime label
     • setsArchetype / laneMeta (pTwoSets, pThreeSets).[1]
   • Then show which branch(s) in the decision tree turns those into LEAN 3 SETS.

3. Prove the systemic bias

   • Count how many matches in a test day satisfy:
     • P2 ≥ 0.56 and P2 ≤ 0.65
     • P3 in [baseP3 + 0.02, baseP3 + 0.06]
     • and yet are labelled LIKELY 3 SETS / LEAN 3 SETS.
   • That number should be “a ton” relative to what we see in reality. This is the bug I’m complaining about.

4. Propose a structural fix (no new random gate, just correcting the wrong rule):

   I want a simple invariant added into the sets decision tree:

   • In BO3, medium favorite band (tour‑aware):
     • For ATP, when P2 ≥ 0.58 and P2 ≤ 0.67.
     • For WTA/CH/ITF, analogous tour thresholds from the same calibration table.[1]
   • In that band, only allow LEAN 3 SETS if both:
     • P3 is in the top decile of its tour ceiling (e.g. P3 ≥ calHigh or ≥ maxP3 − 0.02).
     • AND laneMeta / SetOutcomeModel shows pThreeSets ≈ pTwoSets (or greater).[1]
   • Otherwise, force the label to LIKELY 2 SETS or MIXED, and cap sets pick at PASS or at most LEAN 2 SETS when 2‑set lane is strongly dominant.

   In code terms: insert a short “medium‑favorite structural override” in buildSetsMarketEngine:

   • After computing P2, P3, laneMeta, and variance regime.
   • Before promoting to LEAN 3 SETS.
   • That override should explicitly check:
     • If P2 is in the medium‑favorite band AND
     • laneMeta.pTwoSets > laneMeta.pThreeSets by X AND
     • P3 is only modestly above base / calLow,
     • then block LEAN/BET 3 SETS for this match (downgrade to LIKELY 2 / MIXED).

5. Deliverables I want back:

   • A short write‑up:
     • “Here is the exact place where the engine currently promotes 3‑sets for P2 ∈ [0.56, 0.65] and P3 just above base.”
     • “Here are sample logs for 5+ matches showing that pattern.”
   • The proposed code change (diff) implementing the medium‑favorite override.
   • Before/after stats on:
     • How many matches per day get LEAN 3 SETS.
     • Hit rate of those picks before vs after.

This is not about one threshold like coherenceDemote; it’s the interaction between tour‑relative threeSetLabel + variance regime + calibrateP3 that systematically over‑labels medium favorites as decider matches. I want you to isolate that interaction and fix it at the sets decision level.[1]

Somehow the script is produce leans on every match it’s not even betting full picks anymore it’s not supposed to say lean for every match Ik it’s wrong bc this match ended in 2 sets and right at 20 games so the over is wrong here

Also

4/5/2026 20:50:50
⚠️ MARKET ANCHOR APPLIED: Model vs market diverged by 4.3 pts. Pulled 4% toward market.

════════════════════════════════════════
🎾 TENNISLOCKS v1.0 🎾
[ᴠᴇʀѕɪᴏɴ] ᴠ1.0 | 2026-04-06ᴛ03:50:42.879ᴢ
ᴛᴏᴛᴀʟѕ ѕɪᴍѕ: 12,000 | ɢᴇɴᴇʀᴀᴛᴇᴅ: 10:50:46 ᴘᴍ
════════════════════════════════════════

⚠️ MARKET ANCHOR — Model diverged 4.3pt from market. Pulled 4% toward market.

🎯 ATP (RIGHT) Match (Clay (Outdoor)) | Best of 3 | Line: 21.5
ᴄᴘɪ: 29 | ᴛᴏᴜʀ: ᴀᴛᴘ (ʀɪɢʜᴛ) (ʜɪɢʜ)

────────────────────────────────────────
Damir Dzumhur vs Alexander Blockx
────────────────────────────────────────

🎲 Total Games Projection: 23.0 (mixture median) | EV 23.9 | lands ~20g or ~29g
ᴅᴇᴄɪᴅᴇʀ ᴘʀᴏʙ: 42% | ᴀᴅᴊ 43% | ʀᴀᴡ 42%
ᴍᴀᴛᴄʜ ᴄʟᴜѕᴛᴇʀѕ: 2-ѕᴇᴛ ᴍᴇᴅɪᴀɴ 20.0ɢ (ᴍᴇᴀɴ 19.7) | 3-ѕᴇᴛ ᴍᴇᴅɪᴀɴ 29.0ɢ (ᴍᴇᴀɴ 29.7)
ʙɪᴍᴏᴅᴀʟ ꜰᴀɪʀ ʟɪɴᴇ: 23.0ɢ (ᴍɪˣᴛᴜʀᴇ ᴍᴇᴅɪᴀɴ) | 2-ѕᴇᴛ ᴍᴏᴅᴇ: 19.7ɢ | 3-ѕᴇᴛ ᴍᴏᴅᴇ: 29.7ɢ

========================================
📊 MATCH WINNER
────────────────────────────────────────
ᴘʟᴀʏᴇʀ ᴍʟ ᴍᴋᴛ% ᴍᴏᴅᴇʟ% ʀᴀᴡ% ᴇᴅɢᴇ ʙᴀʀ
ᴅᴀᴍɪʀ ᴅᴢᴜᴍʜᴜʀ +121 42.6% 38.0% 38.0% -4.6% ████░░░░░░
▶ ᴘɪᴄᴋ ᴀʟᴇˣᴀɴᴅᴇʀ ʙʟᴏᴄᴋˣ -148 57.4% 62.0% 62.0% +4.6% ██████░░░░
┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄
ʙʟᴇɴᴅ ᴍᴄ 46.9% | ѕᴛᴀᴛѕ 30.8% | ᴇʟᴏ 41.0%
ʀᴀᴡ ᴇɴɢɪɴᴇ ʀᴀᴡ: 38.0% (ᴅᴀᴍɪʀ ᴅᴢᴜᴍʜᴜʀ) | ᴅɪѕᴘʟᴀʏ: 38.0%
ᴀɴᴄʜᴏʀ 4% ᴀᴘᴘʟɪᴇᴅ (ᴍᴀʀᴋᴇᴛ ᴀɴᴄʜᴏʀ 4ᴘᴘ)
ᴇᴅɢᴇ +4.6% ᴏɴ ʙ | ᴇᴠ: +3.8% | ѕᴛᴀᴋᴇ: 1.42% | ᴄᴏɴꜰ: ᴍɪᴅ
ꜰᴀɪʀ ᴍʟ ᴅᴀᴍɪʀ ᴅᴢᴜᴍʜᴜʀ +163 / ᴀʟᴇˣᴀɴᴅᴇʀ ʙʟᴏᴄᴋˣ -163

✅ [OFFICIAL BET]
🏆 BET FAVORITE — Alexander Blockx
ᴇᴠ: +3.8% | ʀɪѕᴋ: ʟᴏᴡ (0.00) | ᴄʟᴜѕᴛᴇʀ: ʜɪɢʜ-ᴅᴇᴄɪᴅᴇʀ

ѕᴛʀᴜᴄᴛᴜʀᴇ & ʀɪѕᴋ
┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄
ᴄʟᴜѕᴛᴇʀ: ʜɪɢʜ-ᴅᴇᴄɪᴅᴇʀ (ᴄʜᴀʟᴋ_ꜰʀᴀɢɪʟᴇ)
ᴅᴇᴄɪᴅᴇʀ: 42.3%
ᴀᴠɢ ɢᴀᴍᴇѕ: 24.2
ʀɪѕᴋ: 0.00 (ʟᴏᴡ) | ᴘᴇɴᴀʟᴛʏ: 0.000
ᴅᴀᴛᴀ: ᴏᴋ (ᴄᴏᴠᴇʀᴀɢᴇ 5/5, ᴛʀᴜѕᴛ 0.94)

ᴘʟᴀʏᴇʀ ɪɴᴛᴇʟ
┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄
ᴅᴀᴍɪʀ ᴅᴢᴜᴍʜᴜʀ ᴀʟᴇˣᴀɴᴅᴇʀ ʙʟᴏᴄᴋˣ
ʀᴀɴᴋ 74 92
ᴇʟᴏ 1654 1705
ᴀᴠɢ ᴏᴘᴘ ʀᴀɴᴋ 129 204
ѕᴄʜᴇᴅᴜʟᴇ ѕᴏʟɪᴅ (ᴛʀᴜѕᴛ 0.99, ʀᴀɴᴋѕ 6)ᴍɪᴅ (ᴛʀᴜѕᴛ 0.94, ʀᴀɴᴋѕ 7)
ѕᴇʀᴠᴇ ѕᴛʏʟᴇ ᴍɪˣᴇᴅ ᴍɪˣᴇᴅ
ᴍᴏᴍᴇɴᴛᴜᴍ ɪɴᴄᴏɴѕɪѕᴛᴇɴᴛ ɪɴᴄᴏɴѕɪѕᴛᴇɴᴛ
ʜᴏʟᴅ % 71.4% 72.9%
ѕᴘᴡ % 60.1% 62.1%
ᴅᴏᴍɪɴᴀɴᴄᴇ ʀᴀᴛɪᴏ 0.71 1.07
ᴠᴏʟᴀᴛɪʟɪᴛʏ 3.5% 1.5%
ᴏᴘᴘ-ᴀᴅᴊ ꜰᴏʀᴍ: ᴅᴇʟᴛᴀ=0.1ᴘᴛ | ᴡᴇɪɢʜᴛ=22.0%
ʙʀᴇᴀᴋ ʀᴀᴛᴇ 27.1% 28.6%
1ѕᴛ ѕʀᴠ ᴡɪɴ % 63.5% 72.5%
2ɴᴅ ѕʀᴠ ᴡɪɴ % 52.6% 44.9%
1ѕᴛ ѕʀᴠ ɪɴ % 68.9% 61.9%
ᴀɴᴀʟʏᴛɪᴄᴀʟ ʜᴏʟᴅ 76.3% 78.7% (ɴᴇᴡᴛᴏɴ-ᴋᴇʟʟᴇʀ)

ѕɪɢɴᴀʟѕ: ᴄʟᴜѕᴛᴇʀ ʜᴇᴀᴠʏ ᴅᴇᴄɪᴅᴇʀ, ꜰᴀᴠ ᴍᴋᴛ-ᴘᴀʀᴛɪᴀʟ ʀɪѕᴋ ᴅɪѕᴄᴏᴜɴᴛ, ᴍᴋᴛ-ᴄᴏɴꜰɪʀᴍᴇᴅ ʀᴇᴄᴏᴠᴇʀʏ: ᴍᴋᴛᴇᴅɢᴇ=4.6ᴘᴘ ʀᴀᴡᴠᴏᴛᴇѕ=-3, ꜰᴀᴠʀᴇѕᴄᴜᴇ: ᴍᴀʀᴋᴇᴛ(57%) + ʀᴀᴡᴍᴏᴅᴇʟ(62%) ᴀɢʀᴇᴇ ᴏɴ ꜰᴀᴠ, ʙʟᴏᴄᴋɪɴɢ ᴅᴏɢ ꜰʟɪᴘѕ (ᴄʟѕ=ᴘʀɪᴍᴀʀʏ)

════════════════════════════════════════

✅ [OFFICIAL BET]
🎲 Sets Market:

• 2 Sets: 55.8% | Book est -147

• 3 Sets: 44.2% | Book est +112

Sets Bet: LEAN 3 SETS | Confidence: MID

Over/Under 2.5 Sets:

• Under 2.5: 55.8% | Book est -151

• Over 2.5: 44.2% | Book est +110

O/U Bet: LEAN OVER 2.5 | Confidence: MID (Sets + OU aligned)

Read: Decider probability is strong relative to tour ceiling (44.2% vs 52% max). 3-set path is well-supported. (winner policy: volatility/fragility) | Confidence: MID
P3 sources: disp 44.2% | adj 42.3% | raw 44.8% | mkt 42.9% | hold 39.3% | spread 4.9pp | hook stable

📊 Player Stats (Live):

• ʜɪѕᴛ. ѕᴜʀꜰᴀᴄᴇ (ʀᴇᴅ ᴄʟᴀʏ): ᴅᴀᴍɪʀ ᴅᴢᴜᴍʜᴜʀ (59.0% [52-54]) | ᴀʟᴇˣᴀɴᴅᴇʀ ʙʟᴏᴄᴋˣ (ɴᴏ ᴅᴀᴛᴀ) [ᴛᴀ_ʟɪᴠᴇ_ѕᴘᴡ]
• ᴅᴀᴍɪʀ ᴅᴢᴜᴍʜᴜʀ: ʜᴏʟᴅ 71.4% (ʀᴀᴡ: 69.7%, ᴀᴅᴊ: ᴛɪᴇʀ ʙᴏᴏѕᴛ) [ᴇꜰʀᴏɴ-ᴍᴏʀʀɪѕ]
• ᴀʟᴇˣᴀɴᴅᴇʀ ʙʟᴏᴄᴋˣ: ʜᴏʟᴅ 72.9% (ʀᴀᴡ: 71.6%, ᴀᴅᴊ: ᴄᴏɴᴛᴇˣᴛ/ꜰᴀᴛɪɢᴜᴇ) [ᴇꜰʀᴏɴ-ᴍᴏʀʀɪѕ]
• ѕᴛʏʟᴇ: ᴅᴀᴍɪʀ ᴅᴢᴜᴍʜᴜʀ [ʙᴀѕᴇʟɪɴᴇ/ᴛᴀᴄᴛɪᴄɪᴀɴ] | ᴀʟᴇˣᴀɴᴅᴇʀ ʙʟᴏᴄᴋˣ [ʙᴀѕᴇʟɪɴᴇ/ᴛᴀᴄᴛɪᴄɪᴀɴ]
• ᴍᴀᴛᴄʜ ᴍᴏᴍᴇɴᴛᴜᴍ (ᴡᴀɴɢ): ᴅᴀᴍɪʀ ᴅᴢᴜᴍʜᴜʀ ᴡᴀɴɢ ѕᴄᴏʀᴇ: 43.2% (ᴍɪˣᴇᴅ ᴍᴏᴍᴇɴᴛᴜᴍ), ᴡ-ʟ 3-3, ѕѕ 1-3, ѕᴇᴛѕ 6-8 ; ᴀʟᴇˣᴀɴᴅᴇʀ ʙʟᴏᴄᴋˣ ᴡᴀɴɢ ѕᴄᴏʀᴇ: 54.2% (ᴍɪˣᴇᴅ ᴍᴏᴍᴇɴᴛᴜᴍ), ᴡ-ʟ 4-3, ѕѕ 2-1, ѕᴇᴛѕ 10-8
• 1ѕᴛ ѕʀᴠ ᴡɪɴ: ᴅᴀᴍɪʀ ᴅᴢᴜᴍʜᴜʀ 63.5% | ᴀʟᴇˣᴀɴᴅᴇʀ ʙʟᴏᴄᴋˣ 72.5%
• 2ɴᴅ ѕʀᴠ ᴡɪɴ: ᴅᴀᴍɪʀ ᴅᴢᴜᴍʜᴜʀ 52.6% | ᴀʟᴇˣᴀɴᴅᴇʀ ʙʟᴏᴄᴋˣ 44.9%
• 1ѕᴛ ѕʀᴠ ɪɴ: ᴅᴀᴍɪʀ ᴅᴢᴜᴍʜᴜʀ 68.9% | ᴀʟᴇˣᴀɴᴅᴇʀ ʙʟᴏᴄᴋˣ 61.9%
• ѕᴘᴡ: ᴅᴀᴍɪʀ ᴅᴢᴜᴍʜᴜʀ 60.1% | ᴀʟᴇˣᴀɴᴅᴇʀ ʙʟᴏᴄᴋˣ 62.1% [ʙᴀʀɴᴇᴛᴛ-ᴄʟᴀʀᴋᴇ ᴀᴅᴊ.]
• ʙʀᴇᴀᴋ ʀᴀᴛᴇ: ᴅᴀᴍɪʀ ᴅᴢᴜᴍʜᴜʀ 27.1% | ᴀʟᴇˣᴀɴᴅᴇʀ ʙʟᴏᴄᴋˣ 28.6%
• ᴅᴏᴍɪɴᴀɴᴄᴇ ʀᴀᴛɪᴏ: ᴅᴀᴍɪʀ ᴅᴢᴜᴍʜᴜʀ 0.71 | ᴀʟᴇˣᴀɴᴅᴇʀ ʙʟᴏᴄᴋˣ 1.07 [ᴍɪѕᴍᴀᴛᴄʜ]
• ᴠᴏʟᴀᴛɪʟɪᴛʏ: ᴅᴀᴍɪʀ ᴅᴢᴜᴍʜᴜʀ 3.5% | ᴀʟᴇˣᴀɴᴅᴇʀ ʙʟᴏᴄᴋˣ 1.5% | ᴍᴀᴛᴄʜ: 2.5%
• ᴇʟᴏ: ᴅᴀᴍɪʀ ᴅᴢᴜᴍʜᴜʀ ᴜɴᴅᴇʀᴅᴏɢ (41.0%) [ᴋᴍ-ᴇʟᴏ ʙʀɪᴅɢᴇ]
  ѕᴏᴜʀᴄᴇ: ᴇʟᴏ_ʟᴏᴏᴋᴜᴘ ѕʜᴇᴇᴛ (ᴅᴀᴍɪʀ ᴅᴢᴜᴍʜᴜʀ=1654, ᴀʟᴇˣᴀɴᴅᴇʀ ʙʟᴏᴄᴋˣ=1705)
• ʙʟᴇɴᴅ (ᴅᴀᴍɪʀ ᴅᴢᴜᴍʜᴜʀ): ᴍᴄ 46.9% | ѕᴛᴀᴛѕ 30.8% | ᴇʟᴏ 41.0%
• ᴀɴᴀʟʏᴛɪᴄᴀʟ ʜᴏʟᴅ: ᴅᴀᴍɪʀ ᴅᴢᴜᴍʜᴜʀ 76.3% | ᴀʟᴇˣᴀɴᴅᴇʀ ʙʟᴏᴄᴋˣ 78.7% (ɴᴇᴡᴛᴏɴ-ᴋᴇʟʟᴇʀ)

ᴛᴏᴛᴀʟѕ ꜰᴀɪʀ ʟɪɴᴇ: 23.5 (ᴄᴅꜰ 50/50) | ᴍɪˣᴛᴜʀᴇ ᴍᴇᴅɪᴀɴ: 22.9
ᴛᴏᴛᴀʟѕ ʀᴀɴɢᴇ: ᴘ10=17 | ᴘ50=23 | ᴘ90=32
ᴛᴏᴛᴀʟѕ ᴇˣᴘᴇᴄᴛᴇᴅ: 24.0 (ᴍᴇᴀɴ) | ᴍᴇᴅɪᴀɴ: 22.9
ᴍᴏѕᴛ ᴄᴏᴍᴍᴏɴ ᴇˣᴀᴄᴛ: 19ɢ | ʜɪɢʜᴇѕᴛ-ᴅᴇɴѕɪᴛʏ ᴢᴏɴᴇ: 18-20ɢ 22.0%
ᴍɪˣᴛᴜʀᴇ ᴍᴇᴅɪᴀɴ: 23.0ɢ | ᴄᴏɴᴅɪᴛɪᴏɴᴀʟ: ᴇ[ᴛ|2 ѕᴇᴛѕ] 19.7 | ᴇ[ᴛ|3 ѕᴇᴛѕ] 29.7 | ᴘ(3 ѕᴇᴛѕ) 43%
ᴛᴏᴛᴀʟѕ ᴘᴍꜰ (ᴛᴏᴘ ᴇˣᴀᴄᴛѕ): 19ɢ 7.9% | 22ɢ 7.2% | 18ɢ 7.1% | 20ɢ 7.0% | 17ɢ 6.0% | 21ɢ 5.8% | 29ɢ 5.6% | 23ɢ 5.5%
🎯 TOTAL GAMES:

ᴛᴏᴛᴀʟѕ ʀᴇɢɪᴍᴇ ѕᴛᴀʙʟᴇ (ᴍᴄ ᴄʜᴀɪɴѕ 3, ᴀᴠɢ ѕᴘʀᴇᴀᴅ 0.05 ɢ)
✅ [OFFICIAL BET]
ᴏᴠᴇʀ 21.5 | ᴄᴏɴꜰɪᴅᴇɴᴄᴇ: ᴍɪᴅ | ⚠️ ʙɪᴍᴏᴅᴀʟ ᴍᴀᴛᴄʜ
── ꜰʀᴀɢɪʟɪᴛʏ ꜰʟᴀɢѕ ──
⚠️ ᴍᴏᴅᴇʀᴀᴛᴇʟʏ ʙɪᴍᴏᴅᴀʟ (ѕᴄᴏʀᴇ=0.40) — ᴇʟᴇᴠᴀᴛᴇᴅ ᴠᴀʀɪᴀɴᴄᴇ
⚠️ ʜᴇᴀᴠʏ ʀɪɢʜᴛ ᴛᴀɪʟ (ᴘ≥31=17.5%) — ʙʟᴏᴡᴏᴜᴛ ʀɪѕᴋ

ᴡʜʏ ɪᴛ ꜰɪᴛѕ:
"3-ѕᴇᴛ ᴘᴀᴛʜ (43%) ʟᴀɴᴅѕ ᴀᴛ ~29ɢ — ᴍᴀѕѕɪᴠᴇʟʏ ᴏᴠᴇʀ ᴛʜᴇ 21.5 ʟɪɴᴇ (99.8% ᴏᴠᴇʀ ɪɴ ᴛʜᴀᴛ ʟᴀɴᴇ).
2-ѕᴇᴛ ᴘᴀᴛʜ (57%) ʟᴀɴᴅѕ ᴀᴛ ~20ɢ — ᴜɴᴅᴇʀ ᴛʜᴇ ʟɪɴᴇ (72.1% ᴜɴᴅᴇʀ).
ѕᴇᴛѕ ᴇɴɢɪɴᴇ ᴄᴏɴꜰɪʀᴍѕ: ʟᴇᴀɴ 3 ѕᴇᴛѕ (ᴍɪᴅ ᴄᴏɴꜰɪᴅᴇɴᴄᴇ).
ᴛʜᴇ ᴏᴠᴇʀ ʙᴇᴛ ᴡɪɴѕ ᴡʜᴇɴ ᴛʜᴇ ᴍᴀᴛᴄʜ ɢᴏᴇѕ 3 ѕᴇᴛѕ. ᴛʜᴇ ᴜɴᴅᴇʀ ʙᴇᴛ ᴡɪɴѕ ɪɴ ѕᴛʀᴀɪɢʜᴛ ѕᴇᴛѕ."

ѕʜᴀᴘᴇ:
"2-ѕᴇᴛ ʟᴀɴᴇ (57%): ᴄᴇɴᴛᴇʀ 20ɢ | ᴘ(ᴏᴠᴇʀ) 27.9%
±1σ ʀᴀɴɢᴇ: 17-23ɢ | ᴘ(ᴏᴠᴇʀ 21.5) ɪɴ ʟᴀɴᴇ: 30.2%
3-ѕᴇᴛ ʟᴀɴᴇ (43%): ᴄᴇɴᴛᴇʀ 29ɢ | ᴘ(ᴏᴠᴇʀ) 99.8%
ᴘ(ᴅᴇᴄɪᴅᴇʀ) 43% (ᴍɪᴅ, 83% ᴏꜰ ᴍᴀˣ)
ʙɪᴍᴏᴅᴀʟ 3-ѕᴇᴛ"

ᴘʀɪᴄɪɴɢ:
"ʟᴀɴᴇ ᴘʀɪᴄɪɴɢ:
2-ѕᴇᴛ ʟᴀɴᴇ: ꜰᴀɪʀ ~19.9 ᴠѕ ʟɪɴᴇ 21.5 -> 1.6ɢ ᴜɴᴅᴇʀ ᴛʜᴇ ʟɪɴᴇ
3-ѕᴇᴛ ʟᴀɴᴇ: ꜰᴀɪʀ ~29.3 ᴠѕ ʟɪɴᴇ 21.5 -> 7.8ɢ ᴏᴠᴇʀ ᴛʜᴇ ʟɪɴᴇ
ʙʟᴇɴᴅᴇᴅ ꜰᴀɪʀ: 23.5 (ᴡᴇɪɢʜᴛᴇᴅ ʙʏ ᴘ3, ʙᴜᴛ ᴍɪѕʟᴇᴀᴅɪɴɢ ꜰᴏʀ ʙɪᴍᴏᴅᴀʟ)

ᴋᴇʏ ǫᴜᴇѕᴛɪᴏɴ: ᴅᴏᴇѕ ᴛʜɪѕ ᴍᴀᴛᴄʜ ɢᴏ 3 ѕᴇᴛѕ?
ᴍᴏᴅᴇʟ ѕᴀʏѕ: 43% ᴅᴇᴄɪᴅᴇʀ ᴘʀᴏʙᴀʙɪʟɪᴛʏ
ѕᴇᴛѕ ᴇɴɢɪɴᴇ ѕᴀʏѕ: ʟᴇᴀɴ 3 ѕᴇᴛѕ (ᴍɪᴅ ᴄᴏɴꜰɪᴅᴇɴᴄᴇ)
ɪꜰ ʏᴇѕ -> ᴇˣᴘᴇᴄᴛ ~29 ᴛᴏᴛᴀʟ ɢᴀᴍᴇѕ (ᴏᴠᴇʀ 21.5 ʙʏ ~7.8 ɢᴀᴍᴇѕ)
ɪꜰ ɴᴏ -> ᴇˣᴘᴇᴄᴛ ~20 ᴛᴏᴛᴀʟ ɢᴀᴍᴇѕ (ᴜɴᴅᴇʀ 21.5 ʙʏ ~1.6 ɢᴀᴍᴇѕ)"

ᴇɴɢɪɴᴇ ʙʀᴇᴀᴋᴅᴏᴡɴ (ʙɪᴍᴏᴅᴀʟ):
┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄
ʟᴀɴᴇ ᴡᴇɪɢʜᴛ ᴄᴇɴᴛᴇʀ ᴘ(ᴏᴠᴇʀ 21.5) ꜰᴀɪʀ
2-ѕᴇᴛ 57% 20ɢ 27.9% ~19.9
±1σ ʀᴀɴɢᴇ: 17-23ɢ | ᴘ(ᴏᴠᴇʀ 21.5) ɪɴ ʟᴀɴᴇ: 30.2%
3-ѕᴇᴛ 43% 29ɢ 99.8% ~29.3
ʙʟᴇɴᴅᴇᴅ (ʀᴇꜰ): ᴍᴄ 57.8% ᴏᴠᴇʀ │ ᴍᴀʀᴋᴏᴠ 71.4% ᴏᴠᴇʀ
ѕᴇᴛѕ ᴄᴏʜᴇʀᴇɴᴄᴇ: ꜰɪʀᴇᴅ ✓ │ ʟᴇᴀɴ 3 ѕᴇᴛѕ → ᴏᴠᴇʀ ᴀʟɪɢɴᴍᴇɴᴛ ᴄᴏɴꜰɪʀᴍᴇᴅ
ꜰᴀɪʀ ʟɪɴᴇѕ — ᴍᴄ: 23.5 │ ᴍᴀʀᴋᴏᴠ: 24.5 │ ɢᴀᴘ: 11.3ᴘᴛѕ, 1.00ɢ
ᴘ(ᴅᴇᴄɪᴅᴇʀ) ᴀᴜᴛʜ: ᴜѕᴇᴅ 43.3% ѕᴜᴘᴘᴏʀᴛ 5 ѕᴘʀᴇᴀᴅ 3.8ᴘᴘ ʟᴀɴᴇɢᴀᴘ ɴᴀᴘᴘ ѕᴛᴀʙʟᴇ ʙʀᴏᴀᴅѕᴜᴘᴘᴏʀᴛ
ʜᴀʟꜰ-ʟɪɴᴇ 21.5 - ᴍᴄ: ᴜɴᴅᴇʀ 39.9% | ᴏᴠᴇʀ 60.1%
ʜᴀʟꜰ-ʟɪɴᴇ 21.5 - ᴍᴀʀᴋᴏᴠ: ᴜɴᴅᴇʀ 28.6% | ᴏᴠᴇʀ 71.4%
ᴛᴀɪʟ - ᴘ(>=30): 22.2% | ᴘ(>=31): 17.5% | ᴘ(>=35): 4.0%
ʙᴜᴄᴋᴇᴛѕ: ʟᴇꜰᴛᴛᴀɪʟ(ʟ-6) 1.6% | ʟᴏᴄᴀʟᴍᴀѕѕ ʟᴏᴡ 14.9% ʜɪɢʜ 7.4%
ɴᴇᴀʀ-ʟɪɴᴇ ᴍᴀѕѕ @21.5: 12.9% (ᴘ(21)+ᴘ(22)) | ʟᴏᴄᴀʟ 20-22: 20.0% | 19-23: 33.4%
ᴀᴅᴊᴀᴄᴇɴᴛ ᴇˣᴀᴄᴛѕ: ᴘ(21ɢ) 5.8% | ᴘ(22ɢ) 7.2%
ᴍᴀʀᴋᴏᴠ 3-ѕᴇᴛ ᴀᴅᴊ: 43.7% (ᴘᴇɴᴀʟᴛʏ 0.0%)

ѕɪᴍᴜʟᴀᴛɪᴏɴ (12000 ʀᴜɴѕ): ʙɪᴍᴏᴅᴀʟ — 57% ʟᴀɴᴅ ɴᴇᴀʀ ~20ɢ (2-ѕᴇᴛ), 43% ʟᴀɴᴅ ɴᴇᴀʀ ~29ɢ (3-ѕᴇᴛ)
58% ᴏᴠᴇʀ 21.5 │ ʙʟᴇɴᴅᴇᴅ ᴍᴇᴅɪᴀɴ 22.9ɢ (ᴘʜᴀɴᴛᴏᴍ — ʙᴇᴛᴡᴇᴇɴ ᴄʟᴜѕᴛᴇʀѕ ᴡʜᴇʀᴇ ꜰᴇᴡ ᴍᴀᴛᴄʜᴇѕ ᴀᴄᴛᴜᴀʟʟʏ ʟᴀɴᴅ)
⚠️ ѕᴘʟɪᴛ ѕɪɢɴᴀʟ — 2-ѕᴇᴛ ʟᴀɴᴇ ᴏᴘᴘᴏѕᴇѕ, 3-ѕᴇᴛ ʟᴀɴᴇ ᴀɢʀᴇᴇѕ
ᴀᴜᴅɪᴛ: ᴅɪʀᴍᴄ=ᴏᴠᴇʀ | ᴘѕɪᴅᴇᴍᴄ=57.5% | ᴄʟᴜѕᴛᴇʀᴅɪʀ=ᴜɴᴅᴇʀ | ᴄʜᴏѕᴇɴᴅɪʀ=ᴏᴠᴇʀ | ɪɴᴠᴀʀɪᴀɴᴛ=ᴏᴋ

📊 ᴜɴᴅᴇʀᴅᴏɢ ᴀѕѕᴇѕѕᴍᴇɴᴛ:
ɴᴏ ᴇᴅɢᴇ ᴏɴ ᴅᴀᴍɪʀ ᴅᴢᴜᴍʜᴜʀ (38.0% ᴍᴏᴅᴇʟ | ɪᴍᴘʟɪᴇᴅ 43%).

Pls fix my script it’s keeps being innacurate across different matches and your levels it’s very annoying update my script and replace and fix the corrupted parts then send the script as a downloadable txt link

I don’t need overrides if the script had clean logic I shouldn’t need overrides man that’s the issue pls fix issues man I’m missing 2 set matches and actual 3 set matches

Also in the most recent patches we had fixed the script for this

PROBLEM 1 — pDeciderAuth carries no bimodalScore attenuation (line 14138)
Root of most downstream problems

var pDeciderAuth = Number.isFinite(p3) ? clamp01(p3) : ...
This is the single source of truth for p3 across the entire engine. bimodalScore=0.40 and bimodalScore=0.85 both produce identical pDeciderAuth from the same raw p3. The MC sim's uncertainty is completely ignored at the source. Everything downstream reads this as if it's equally reliable regardless of how noisy the bimodal structure is.

Fix location: The attenuation needs to happen here — before pDeciderAuth is returned. A bimodalScore-weighted blend between the computed p3 and the tour structural baseline. The weight curve should reference biResult.score (which is already computed in scope at this point).

PROBLEM 2 — coherenceDemote/coherenceFlip use a flat threshold that is structurally 2-set biased (lines 16753–16754, 866 comment)
coherenceFlip: 0.62,
coherenceDemote: 0.58,
The comment in threeSetLabel (line 866) says: "2-set P(2) gate: 0.58 (unchanged — already works well)" — this is wrong. threeSetLabel itself was upgraded to tour-specific gates (ATP=0.56, WTA/CH=0.57, ITF=0.62) but the coherence guard was never updated to match. So threeSetLabel says a match is MIXED_PATHS, but coherenceDemote immediately fires on it because it uses 0.58 regardless of tour. They use incompatible reference systems.

For ITF specifically: baseP3 = 0.289, so p2LeanThr = 0.621. But coherenceDemote = 0.58 fires before the lean threshold. The guard is more aggressive than the lean system that's supposed to back-stop it. On ITF, every competitive match with a modest favorite gets demoted.

Fix location: Replace both coherenceFlip and coherenceDemote with tour-relative expressions derived from cfg.p2LeanThr (which is already computed in scope at line 16787).

PROBLEM 3 — HEAVY_DECIDER triggers 3SET_LOCKED too easily, then silences the coherence guard (lines 11212–11213, 11322, 17456)
// Cluster band assignment:
} else if ((adjDecP >= _cgHeavyDec && pPick <= 0.65) || ...) {
clusterBand = "HEAVY_DECIDER";
// Archetype from band:
} else if (clusterBand === 'HEAVY_DECIDER' || ...) {
_clusterArchetype = '3SET_LOCKED';
// Coherence guard bypass:
if (_is3Pick && p2Final >= cfg.coherenceFlip && !_lockedSets) { ... }
For ATP, _cgHeavyDec = 0.43. A match with cP3 = 0.43 AND the favorite winning at 62% triggers HEAVY_DECIDER → 3SET_LOCKED. Once locked, !_lockedSets is false, so the coherence guard is completely bypassed. A match where P2 is 0.64+ can still produce a 3-set pick because the lock blocks the only guard that would catch it.

The lock was designed for confirmed bimodal matches. But HEAVY_DECIDER fires on ANY match where cP3 is high, regardless of bimodalScore. A soft bimodal (score=0.35) can trigger HEAVY_DECIDER and get full 3SET_LOCKED treatment.

Fix location: Add a bimodalScore requirement to 3SET_LOCKED assignment. HEAVY_DECIDER should only escalate to 3SET_LOCKED when bimodalScore >= some threshold (e.g., 0.50). Below that, it should remain HEAVY_DECIDER but UNLOCKED — meaning the coherence guard can still fire.

PROBLEM 4 — _calibrateP3 soft ceiling absolute floor of 0.43 inflates all tours (line 501)
var ceiling = Math.max(base + 0.08, 0.43);
This was added to fix ITF (which had base+0.08 = 0.369, blocking LIKELY_3_SETS). But the result is a global absolute floor at 0.43 that applies to all tours. For ATP with a 60% favorite, structural p3 should be around 0.39–0.41, but the ceiling forces the compressed value through at up to 0.43 (since ceiling + (pCal - ceiling) * 0.40 doesn't stop at the ceiling). On clay with surface adjustment, this leaks even higher.

Fix location: The ITF fix is correct in intent but the mechanism is wrong. The ceiling floor should be tour-specific: Math.max(base + 0.08, tourMaxTarget - 0.02) — tied to each tour's actual upper bound rather than a universal 0.43.

PROBLEM 5 — varianceRegime = HIGH lowers p3LeanThr but bimodalScore 0.50 is a soft threshold (lines 16822–16836)
if (_vrBimodalScore >= 0.50 && _vrSplitGapGames >= 8) {
varianceRegime = 'HIGH';
cfg.p3LeanThr = Math.max(cfg.baseP3 + 0.06, cfg.calMid); // relaxed
HIGH variance lowers the lean threshold from baseP3+0.09 to baseP3+0.06 — making 3-set picks easier. But bimodalScore >= 0.50 is still in the "borderline" zone (the code at line 16996–16998 calls 0.60+ BIMODAL, 0.30–0.60 SOFT). So a SOFT bimodal can trigger HIGH variance regime and get the relaxed threshold. Combined with Problem 1 (pDeciderAuth unattenuated), a soft bimodal with borderline bimodalScore gets: relaxed lean threshold AND full authority p3 signal. Both should require stronger bimodal evidence.

Fix location: Raise the HIGH regime bimodalScore threshold from 0.50 to 0.60, or use a graduated relaxation that's proportional to the actual bimodalScore rather than a binary HIGH/MID/LOW split.

PROBLEM 6 — No explicit conflict detection between cluster and structural layers (systemic)
There is no variable anywhere in the engine that says "cluster points toward 3-set but structural P2 says 2-set — this is a conflict." The coherence guard catches some of these cases but (a) it fires too broadly as shown in Problem 2, and (b) it's disabled when locked as shown in Problem 3.

The result: when cluster says HEAVY_DECIDER and p2Final is 0.62, the engine has no way to categorize this as a conflict. It either lets the lock win silently, or misfires the coherence guard on non-conflicting matches.

Fix location: Add a _clusterP2Conflict flag computed after Section 2. True when: cluster archetype points toward 3-set (HEAVY_DECIDER, 3SET_LOCKED) AND p2Final >= cfg.p2LeanThr (tour-relative, from line 16787). This flag then gates:

The 3SET_LOCKED coherence bypass (Problem 3): conflict active → coherence guard fires anyway but caps at LOW rather than flipping
Section 6: conflict active → cap confidence, don't promote
PROBLEM 7 — rescueP2Max is tied to the flat coherenceDemote value (line 16858)
cfg.rescueP2Max = Math.min(cfg.coherenceDemote, cfg.p2LeanThr + 0.02, 0.64);
Since coherenceDemote = 0.58 (flat) and p2LeanThr + 0.02 for ATP = 0.572, the rescue gate caps at 0.572. But coherenceDemote should become tour-relative (Problem 2). Once it does, this formula will automatically get better — but the Math.min with the flat 0.58 value needs to be removed, otherwise it will still cap the rescue gate at 0.58 even after coherenceDemote is fixed.

Fix location: After fixing Problem 2, update this line to reference the tour-relative coherenceDemote, not the old flat value.

PROBLEM 8 — clusterNativeP3 is not truly independent of MC (lines 11108–11121)
cP3 = 0.50 * cP3mc + 0.50 * _cgEmpP3; // "50/50 anchor"
// ... then:
if (clusterTotalN >= 500) {
cP3 = 0.60 * _clusterNativeP3Raw + 0.40 * cP3; // blends in raw count ratio
}
The comment says "cluster's independently-anchored p3" but cP3mc IS the MC sim's cluster-level p3. _clusterNativeP3Raw is the pure count ratio from sim output — also MC. So the final cP3 when N >= 500 is: 0.60 * MC_counts + 0.40 * (0.50 * MC_raw + 0.50 * empirical) = 0.80 * MC + 0.20 * empirical. The cluster is 80% MC-influenced. When MC is inflating p3 (as it tends to), the cluster amplifies rather than corrects it.

Fix location: The empirical anchor weight needs to be higher, not 50%. The geometry weight (when N >= 500) should come from the raw count ratio with the empirical correction, not blend back in more MC. Practically: invert the weights — make empirical the 60% anchor and MC the 40% adjustment, especially for the clusterNativeP3Raw blend.

PROBLEM 9 — threeSetLabel and coherenceDemote are uncalibrated against each other (systemic)
threeSetLabel for ATP uses _p2Gate = 0.56 (line 878) — a match with p2 >= 0.56 is LIKELY_2_SETS. But coherenceDemote = 0.58 fires at p2 >= 0.58. This means there's a band between 0.56 and 0.58 where: threeSetLabel says LIKELY_2_SETS, but coherenceDemote hasn't fired yet. A 3-set pick in this band is LIKELY_2_SETS structurally but not yet demoted by the guard. The pick can survive without either gate catching it cleanly.

Fix location: After both are made tour-relative, they should be cross-validated: coherenceDemote should be pegged at or just below the _p2Gate used in threeSetLabel, so a pick can never be LIKELY_2_SETS structurally without the coherence guard also seeing it.

PROBLEM 10 — Totals _p3Disp at line 20499 has the same unattenuated pDeciderAuth issue as Problem 1
var _p3Disp = clusterDisplayP3({
...,
pDeciderAdj: (_totSim._bimodalCtx.pDeciderAuth) ? ... : NaN
});
The totals engine reads pDeciderAuth for its display p3 from _totSim._bimodalCtx.pDeciderAuth — same unattenuated source. So even after fixing Problem 1 in the sets path, the totals path will still carry the same inflation unless it reads the corrected value. The same pattern appears at lines 20635, 20879, 21347, 21383.

Fix location: If Problem 1 is fixed at the source (inside computeFullBimodal before the return), then all downstream consumers reading pDeciderAuth get the corrected value automatically — no separate fix needed. But verify each call site is using the return value from the same computed object, not a cached copy.

PROBLEM 11 — Stage 9 coherence boost (sets-totals alignment) is only partially guarded (documented at lines 32, 190)
Stage 9 reinforcement fires when sets and totals agree. The SFB (short-favor bimodal) patch blocks Stage 9 specifically for that case. But there's no equivalent guard for the conflict case from Problem 6. When cluster says 3-set and structural P2 says 2-set, and the engine ends up producing a 3-set pick anyway (because of lock bypass), Stage 9 can amplify that wrong pick by reinforcing it from the totals side. The cluster-structural conflict should also block or reduce Stage 9 reinforcement.

Fix location: Add _clusterP2Conflict (Problem 6) as an additional Stage 9 guard condition.

Execution Order
These aren't independent. The dependency chain is:

Problem 1 (pDeciderAuth attenuation)
→ Problem 10 (totals path — auto-fixed by Problem 1 if source is corrected)
Problem 2 (tour-relative coherence thresholds)
→ Problem 7 (rescueP2Max — auto-improves after Problem 2)
→ Problem 9 (threeSetLabel calibration — cross-validate after both are tour-relative)
Problem 3 (HEAVY_DECIDER → 3SET_LOCKED + lock silences coherence)
→ requires Problem 6 (conflict flag) to be defined first
Problem 6 (conflict detection flag)
→ Problem 11 (Stage 9 guard — add conflict flag as condition)
Problem 4 (_calibrateP3 ceiling) — independent, can do anytime
Problem 5 (varianceRegime HIGH threshold) — independent, can do anytime
Problem 8 (clusterNativeP3 MC weight) — independent, can do anytime

Some how this didn’t work at all I don’t understand somehow three set label is using a fixed 0.57 number also

Done — I patched the uploaded engine and exported a downloadable .txt copy. The original file still had the flat/tour-misaligned 2-set gating, the soft HIGH-variance relaxation, a second p3 attenuation pass in the sets engine, and a Stage 9 reinforcement path that could still help the wrong side in medium-favorite bimodal matches. (TennisLocks_patched-1.js)

What I changed in the script:

Replaced the hard-coded 3-set label gate with a shared tour-aware helper: ATP 0.56, WTA/CH 0.57, ITF 0.62.
Moved pDeciderAuth attenuation to one place only and removed the second attenuation inside buildSetsMarketEngine.
Tightened HIGH variance to require stronger bimodal evidence (bimodalScore >= 0.60) and reduced its relaxation from baseP3 + 0.06 to baseP3 + 0.075.
Made HEAVY_DECIDER and 3SET_LOCKED require real bimodal support instead of soft decider pressure alone.
Added a structural cluster-vs-lane conflict block so medium favorites with 2-set lane dominance cannot keep leaking into LEAN 3 SETS.
Blocked Stage 9 decider reinforcement when that cluster-vs-lane conflict is active.
Replaced the flat 0.58 / 0.62 rescue/veto literals with the same tour-aware gate logic used by threeSetLabel.
Adjusted the _calibrateP3 ceiling away from the universal 0.43 floor.
I also syntax-checked the patched file successfully.

Files: Download patched script as TXT
Download patched script as JS
Download diff

I did not run before/after hit-rate stats because there wasn’t a backtest harness or match dataset included with the upload.

This fix did nothing so this proves this is a architectural problem

So I want you to
Here’s a prompt you can paste to your dev (you can swap in the exact filename like TennisLocks_patched-1.js):

---

You are the maintainer of my tennis model codebase. I’m not asking for one-off patches; I want a systematic audit and fix pass.

Context

• File: TennisLocks_patched-1.js (full engine, including SetOutcomeModel, threeSetLabel, sets decision tree, and totals/decider logic).
• Recent issues: incoherent 2‑set vs 3‑set behavior, short‑favored bimodal matches, and decider probabilities being mis-labeled or mis-used.

Your job

Act as a senior engineer responsible for this subsystem. For this request, focus ONLY on:

• SetOutcomeModel and anything it exports (p3, p2, med2/med3, authority, etc.).
• threeSetLabel and any code that uses its output.
• The sets decision tree / sets market engine (all logic that decides LEAN/BET 2 SETS vs 3 SETS and the associated confidence).
• The short‑favored bimodal (SFB) override logic and any coherence guards that flip or demote 3‑set picks.

Ignore winner-side governance and generic totals governance except where they directly interact with sets/decider.

---

Required workflow (do not skip steps)

1. Spec restatement (no code edits)

   • Based on the comments and headers inside the file, restate the intended behavior for this subsystem in your own words:
     • What is the expected P(3) behavior at coin-flip vs heavy favorite, per tour and surface.
     • When LIKELY_3_SETS vs LIKELY_2_SETS vs MIXED_PATHS should fire.
     • How the sets engine should behave on “normal” vs “bimodal” matches, including SFB cases.
     • How coherence guards are supposed to protect against obviously wrong 3‑set calls without killing legitimate ones.
   • Output this as a short spec (bullets, not marketing language).

2. Issue discovery (code audit, no edits yet)

   • Scan the CURRENT code in TennisLocks_patched-1.js for ANY bugs, inconsistencies, or landmines in this subsystem, including but NOT limited to issues I’ve previously described.
   • For each issue you find, create an item with this structure:
     • Issue ID (A, B, C…)
     • Location: function name and approximate line(s), with the exact code snippet.
     • Root cause: what is wrong in the code or thresholds.
     • Spec violation: which part of the spec from step 1 it contradicts.
     • Behavioral effect: what this does in practice (e.g., “makes LIKELY_3_SETS effectively unreachable on ATP clay coin-flips”, “causes SFB override to collapse real 3‑set leans into LEAN 2 SETS”, etc.).
   • IMPORTANT:
     • If some of the issues I previously raised are now already fixed in this file, explicitly say “NO ISSUE — already fixed” and show the current code.
     • You are REQUIRED to look for additional problems beyond any list I gave you. If you think the subsystem is now clean, you must explicitly argue why (using the spec and code).

3. Plan (text only, still no edits)

   • For each issue from step 2, propose a concrete fix:
     • Show the current line(s) and the intended new line(s) (pseudo-code is OK at this stage).
     • Explain how the change restores consistency with the spec and what side effects or tradeoffs might exist.
   • Also propose any small, targeted refactors or additional guardrails that would make future errors less likely (e.g., centralizing thresholds, using helper functions for P3 floors/ceilings, etc.).

4. Patch (code edits with diff)

   • Only after completing steps 1–3, and after I say “APPLY PLAN”, modify the code.
   • Show a unified diff (or clearly marked BEFORE/AFTER snippets) for each issue you fix.
   • Make sure all changes are applied to the version I specified (TennisLocks_patched-1.js), not an older header.

5. Sanity checks / “test cases on paper”

   • Without running code, walk through at least 5 scenario “tests” in prose, using the new thresholds/logic:
     • ATP clay coin-flip match, moderate holds.
     • ATP heavy favorite on fast hard court.
     • WTA clay match with high break rates and high variance.
     • ITF match with bimodal structure and elevated P(3).
     • Short-favored bimodal match where the 2‑set lane clearly dominates.
   • For each scenario, state the expected:
     • tour base P(3), calibrated P(3), threeSetLabel result, setsPick (2 or 3 sets, LEAN/BET/PASS), SFB involvement (if any), and whether this matches the spec.

---

Hard requirements

• Do NOT just “fix the issues the user listed”. You must explicitly search for and either confirm or refute any other plausible bugs or misalignments in this subsystem.
• Do NOT invent problems that don’t exist in this file; show the exact code snippet for every claimed issue.
• If my earlier descriptions conflict with the actual code (e.g., values already rolled back to v33 thresholds), you must say so and explain why the current implementation is acceptable or still problematic.

Then update the script and send it as a downloadable txt link