The script is clean just gotta touch up stuff Ye...

The script is clean just gotta touch up stuff

Yes — there are still specific spots in the script where a 2-set match can be called 3 sets (or vice versa). Here's a precise breakdown of each one, pulled directly from the code:

---

1. Bimodal Lean/Bet Rescue can force a 3-set pick even when p2 leads

The rescue block fires when setsPick === PASS and agreementLevel === 'STRONGAGREE':[1]

text
if (p3Final > p2Final && !minDecider3Kill) → setsPick = 'LEAN 3 SETS'
else → setsPick = 'LEAN 2 SETS'

The problem: p3Final could edge out p2Final by a tiny margin (e.g., 0.38 vs 0.37) after the sweepPenalty or threshold adjustments, and the rescue picks 3 sets even though most sources said 2-set all along. The setsRescueFloor of 0.04 is meant to guard this, but only checks Math.abs(p3Final - p2Final) — it doesn't check whether the absolute p3Final actually exceeds base rates.[1]

---

2. can3Lean bimodal rescue: hold + raw together can override a dominant p2

The rescue path inside can3Lean:[1]

if (holdClears && rawNear && p2NotDom && sup3Count >= 1) → can3Lean = true

p2NotDom is only p2Final < cfg.coherenceFlip (0.66). So if p2Final is 0.65 — basically dominant — the hold and raw sources can still rescue a 3-set pick. This is a gap: p2NotDom should probably require p2Final < 0.60 or so, not < 0.66.[1]

---

3. Section 6 coherence flip has a one-way blind spot

The coherence audit in Section 6 only flips a 3-set pick to 2 sets when p2Final >= cfg.coherenceFlip (0.66):[1]

if (is3Pick && p2Final >= cfg.coherenceFlip) → force 'BET 2 SETS'

There is no mirror — nothing in Section 6 flips a 2-set pick back to 3 sets when p3Final is dominant. That's by design for caution, but it creates an asymmetry: a bad 3-set call with p2Final = 0.65 slips through the coherence gate entirely since 0.65 < 0.66.[1]

---

4. E14 totals coherence demotes but doesn't flip

The E14 block demotes confidence when the sets pick contradicts the totals direction (e.g. 3 sets + UNDER totals, or 2 sets + OVER totals):[1]

text
if (e14Is3 && e14TotDir === 'UNDER') → demote confidence
if (!e14Is3 && e14TotDir === 'OVER') → demote confidence

It only demotes, it never corrects the pick direction. So you can still get a live "BET 3 SETS / LOW confidence" output that is logically inconsistent with the totals lane.[1]

---

5. deciderVeto2 threshold is asymmetrically tight

The only guard that kills a 2-set pick when the decider is strongly supported requires both conditions:[1]

p3Primary >= cfg.maxP3 * 0.96 AND p2Final < 0.63

maxP3 for ATP is 0.46, so p3Primary needs to be ≥ 0.441 before this even activates. In practice most clear "3-set" matches sit in the 0.38–0.42 zone and this veto never fires, meaning 2-set picks can survive moderate-to-strong decider pressure.[1]

---

Quick Fix Recommendations

Issue	Where	Fix
Rescue picks 3 sets on paper-thin margin	Section 5 rescue block	Add p3Final > cfg.baseP3 as a second condition before LEAN 3 SETS
p2NotDom threshold too loose	can3Lean rescue	Lower from < 0.66 to < 0.60
Coherence flip misses 0.65 p2	Section 6	Lower coherenceFlip from 0.66 to 0.63
E14 demotes but never corrects	E14 block	Add a pick-flip when both conditions fire + confidence is already LOW
deciderVeto2 too high a bar	Section 4	Lower the p3Primary >= maxP3 * 0.96 multiplier to 0.88 or 0.90

None of these are systemic blowups — the architecture is sound — but these five edges are where the 2-vs-3 call can go wrong on borderline matches.[1]

Sources
[1] TennisLocks_v26_CAL-2.txt https://ppl-ai-file-upload.s3.amazonaws.com/web/direct-files/attachments/512947672/1333a6bc-010c-4a68-97fd-de98a6e588bd/TennisLocks_v26_CAL-2.txt

Yes, there still can be edge cases where a best‑of‑3 match is interpreted inconsistently between the simulation and the sets market layer, but the v26 structure reduces most of the obvious ones rather than fully eliminating the risk.[1]

How sets vs 3‑sets is supposed to work

From the comments, v26 routes both totals and sets off the same SetOutcomeModel and a single p3 (pDeciderDisplay) that is built in _computeFullBimodal_, then passed into _buildSetsMarketEngine_.[1]
That design is specifically meant to stop “winner engine says one thing, sets market assumes another” type bugs.[1]

In a clean best‑of‑3 flow:

• Match simulation → bimodal skill/totals → p3 (probability of deciding set) is computed once.[1]
• Sets engine reads that p3 and builds its 2–0 vs 2–1 distribution off the same probabilities that drove totals.[1]
• Sets market labels (2 sets vs 3 sets) should just be a thin display layer over those probabilities.[1]

Where mismatches can still happen

Based on how the engine is organized, problems are most likely in these spots:

• Tournament / format detection
  If a tour or event is mis‑classified (e.g., a rare best‑of‑5, or a mis‑parsed format), _computeFullBimodal_ might still be assuming best‑of‑3 while the sets market overlay (or vice versa) expects a different structure.[1]

• Display vs. canonical probabilities
  You have explicit separation between “clean band label vs probability editing — bands label only, bounded adjustments”.[1]
  If a band label or display helper for “2 sets” vs “3 sets” applies any transformation that is not perfectly aligned with p3, you can get a cosmetic or even small numeric mismatch even though the underlying SetOutcomeModel is correct.[1]

• Legacy branches or hidden overrides
  v26 notes “Shadow variables and legacy branches cleaned — one definition per concept”, but any left‑over legacy helper that hard‑codes a “3‑set match feel” or uses old thresholds (like med2/med3 vs sd2/sd3) separately from the unified SetOutcomeModel could still flip the interpretation.[1]

• Heatmap / confidence band shortcuts
  The engine applies a global compression cap after penalties and uses band labels for confidence.[1]
  If a sets‑market specific presentation layer works off band labels instead of the raw p3, some very tight matches near 50% could have a visually “3‑sets” feel while the model probabilities are nearer “2 sets”, or vice‑versa.[1]

Practical implication

So:

• The core v26 design (single SetOutcomeModel, one p3, sets and totals sharing the same canonical layer) should stop systematic “this is actually 2 sets but we model it as 3” bugs that existed when each lane had its own logic.[1]
• However, you can still see mismatches in edge cases where event format detection fails, or where a display/helper function for the sets market drifts from the canonical p3 that _computeFullBimodal_ exports.[1]

If you can point to one specific match where the sheet showed “likely 3 sets” but the underlying totals or scorelines implied a straight sets distribution, I can help you trace which branch is actually causing the disagreement in the current script.

What’s the most recent match where you actually saw “2 sets” vs “3 sets” disagree between the sets market and what you expected?

Sources
[1] TennisLocks_v26_CAL-2.txt https://ppl-ai-file-upload.s3.amazonaws.com/web/direct-files/attachments/512947672/1333a6bc-010c-4a68-97fd-de98a6e588bd/TennisLocks_v26_CAL-2.txt?AWSAccessKeyId=ASIA2F3EMEYERVUSR3TJ&Signature=BP0cJ6KWJbjTS3kmAqqKccms9Y4%3D&x-amz-security-token=IQoJb3JpZ2luX2VjEFkaCXVzLWVhc3QtMSJGMEQCIGTRH9lsQj%2BkSWBWeJMcnloR%2FnSzR2EvpejXJAR6IOz%2BAiBbad9K69rS9AWjWG59%2B%2BR7vXivJ%2BZgQCqSVMs1gfg5ayrzBAghEAEaDDY5OTc1MzMwOTcwNSIMGz9K%2F3RTmEYWz9njKtAEZJWON5%2FYISD4Cch837wC4qSHzncPYyVyp4gSbEv0O8AKMoXjIOkqwhCrdQo5x1dKaJPTTSwqEuffKryjXTpO5bzNbU%2FAYB%2FxCWkE0iZuUYG7pdBarv6PfIQWNM5%2BE8NLVZXo8jyLLS1bvS59bNLTJtQLahkQOhYGiXiIqFnY9h3Zokr01xP9oL5nNxM3kahQLnttzoeR%2BcPIZ%2BUBE47MD8CQB2GZLLDftvZ9okoLZFIEHBMY2anzFcX6b8vhibBHSR1F%2B8edZwOL7zSUsUF7JIC490p%2BO1S3WEeXQVAzeuKDkgI%2FyZZNFzvb%2Brrzcy8Bb76TB%2BJXP9LZA2%2B3BmlTCCs3hRbdJPEgy6QovmL2iZ0JfR9pzbWTJFk6EhxYhFZ5CXwlrA3pVNdTPM%2F74Bf8jdOWpEcd5WydwyCVYJbo%2FfniEpVg5Uwf5CqkY8ClcULxO5pCHZFGt9zhDkOGKu31%2F7mL73bfqCcRyJrFmQJlvzrZAymxxe8N3KmlGI20xOyE%2BZ1eZmxea%2BYOgTdBHitK62oFmlyR4gTDJzWyvCJFZ3BfF4n1uVncPzv8%2BoWiosfyMUOP7hPmB%2F2UdPXzlTrf2v0NnVLyxfCWUnliap%2BR5zuTTf285%2BBl2Kw%2Fp5coPmKEV2X9nlrCgY6Iw7vp4rWlwy4BQ0klMUXLnd1%2FH8C75ELPAuf%2B3f8l4fbfkbIUrE288esbGorzdcJ8EuhdU370znYqDyNJBi7xQshlR8w8sqqyxPdpA%2BqKS407WQqw4xmtQwZp1vUR9Da1ykprqHh%2FHTDa4ajOBjqZARryy%2FT7rJZ6%2FaW3bWP0FdLqFRaUGiw33iAgbRT4Yez5fSp1B%2BhHPYYnYia%2F8riwWiFsGteidBJA%2BYawHlBi%2F9lg3Jf4ycHulQebaq5eKfOyk8dE2UfaQolUjv6WW2z8vhl4ypn9q52PJmsv2LJ8fZcUO%2BT49ZKvq%2FKm3tBK%2BLTrHoYrSq61ZMn690hIZ3OoawCUM3GLD4nlGA%3D%3D&Expires=1774860257

Do not give to a sub agent

---

1. Never “add alongside” – always replace the old block

For any core engine piece (winner prob, bimodal, sets, confidence):

• Do not leave the old code commented out and a new version below it if the old variables are still referenced anywhere.
• Instead, delete or fully replace the old block so there is only one live implementation.

Example:

Bad (colliding):

js
// OLD:
// var p3 = someOldBlend(...);

// NEW:
var p3 = bimodal.pDeciderAuth;

If someOldBlend is still used later, you end up with two different concepts of “p3” floating around.

Correct:

js
// Replace the old code entirely:
var p3 = bimodal.pDeciderAuth;

And make sure any references to the old computation are gone.

---

2. One source of truth per concept

For these keys, there must be exactly one definition:

• Match win probability: a single pWinA (or pFinal) that MATCH_PREVIEW uses.
• Decider probability: a single pDeciderAuth from _computeFullBimodal_.
• BO3 sets thresholds: cfg.p2LeanThr, cfg.p2BetThr, cfg.p3LeanThr, cfg.p3BetThr computed once from tour+32k.
• RiskScore: one place that aggregates all risk factors before confidence is computed.

If you see:

• pDeciderRaw computed in multiple helpers, or
• separate local p2/p3 computations using different formulas,

you need to delete the duplicates and route everyone through the canonical value.

---

3. When you refactor a function, remove all legacy branches

Any time you refactor a core function like _buildSetsMarketEngine_ or _computeFullBimodal_:

• Replace the full function body, not just parts of it.
• Do not leave “old path” branches reachable under conditions like if (legacyMode) or if (!bimodal) unless you are 100% sure they’re dead.

Otherwise, the engine will sometimes run old code and sometimes new, depending on state.

---

4. Avoid “shadow variables” that hide bugs

If you re‑implement something, do not introduce new variables with the same semantic meaning but different names and keep using the old ones elsewhere.

Example:

Bad:

js
var p3Raw = bimodal.pDeciderAuth;
var p3New = _clamp_(p3Raw, ...);

// but later:
if (p3Old >= SETS_MARKET_CFG.READ_STRONG_3SET_BO3) { ... }

Here p3Old is some old variable still in scope, and your new logic is effectively ignored in some checks.

Correct: rename everything to the new canonical name or delete the old, e.g.:

js
var p3 = _clamp_(bimodal.pDeciderAuth, ...);

// and *only* use p3 downstream

Search the function for p3 and make sure you don’t have both p3Old and p3 used in decisions.

---

5. Enforce a “no double computation” rule

When you or an agent makes a change, always check:

• Did we compute match win prob in more than one place?
• Did we compute P(3 sets) in more than one place?
• Did we compute sets thresholds in more than one place?

Update my script then send it as a downloadable test link