Levandor

P&L Attribution Corrections — (asset,window_id) Join + resolved_up ≠ Settlement Truth (2026-07-03)

5 min read

Two corrections from the 2026-07-03 live P&L attribution session (and babylon pmv2 channel msgs #1032–#1036): a data trap in how attribution joins the outcomes table, and a refutation of the earlier “#1031 PM realized_pnl bug / 7 false losses” claim. Net binding rule: pmv2_autotrade_orders.realized_pnl_usd is the trustworthy P&L label; outcomes.resolved_up is a trading gate, NOT settlement truth.

For Agents — binding rules

  1. ALWAYS join outcomes on (asset, window_id), never window_id alone. window_id is shared across all 5 assets for the same 5-min bucket; a window_id-only join collapses all assets and produces coin-flip labels.
  2. outcomes has duplicate rows per (asset, window_id) — dedupe with bool_or(resolved_up) GROUP BY asset, window_id.
  3. Use realized_pnl_usd (CLOB / tokens[].winner-derived) as the P&L label. Do NOT use resolved_up for P&L, sizing, or certainty tiers — it over-books near-tie wins vs the market’s settlement source.
  4. Derive our order’s asset from pmv2_autotrade_orders.source_id: crypto_5m_algo_* → btc, else split_part(source_id,'_',1).

Correction 1 — attribution join gotcha (outcomes.window_id is not unique)

crypto_shortterm.outcomes.window_id is NOT unique. The same 5-min bucket has one row per asset (btc/eth/sol/xrp/doge) because each asset resolves independently — the same window_id can be resolved_up=true for one coin and false for another in the same window.

  • Table: ~9,643 rows over ~5,995 distinct window_ids.
  • (asset, window_id) IS the unique key (per-asset row count == distinct window count).
  • A join keyed on window_id alone collapses all 5 assets together and yields ~coin-flip labels: >50% of the joined windows had self-contradicting resolved_up across the merged assets.

Data trap

Any attribution/backtest join that keys on window_id alone silently mislabels roughly half the population. This is not a subtle bias — it is a label scrambler. Join on (asset, window_id).

The correct query shape

-- dedupe outcomes first: duplicate rows exist per (asset, window_id)
WITH oc AS (
  SELECT asset, window_id, bool_or(resolved_up) AS resolved_up
  FROM crypto_shortterm.outcomes
  GROUP BY asset, window_id
)
SELECT o.*, oc.resolved_up
FROM pmv2_autotrade_orders o
JOIN oc
  ON oc.window_id = o.window_id
 AND oc.asset = CASE
       WHEN o.source_id LIKE 'crypto_5m_algo_%' THEN 'btc'   -- crypto_5m_algo_up / _down = BTC
       ELSE split_part(o.source_id, '_', 1)                  -- eth/sol/xrp/doge lanes
     END

Asset for our orders derives from pmv2_autotrade_orders.source_id: the BTC lanes are crypto_5m_algo_up / crypto_5m_algo_down → btc; the alt dry lanes carry the asset as the first _-segment → split_part(source_id,'_',1).

Correction 2 — #1031 is zero-delta; resolved_up is NOT settlement truth

Revises prior handover / LOG claim

The earlier claim (repo HANDOVER.md + 2026-07-03 “ORACLE-STATE PHASE-0 RUN” bullet, filed as babylon #1031) that PM’s realized_pnl_usd was “biased NEGATIVE” with “7/246 false losses” from a premature winner-flag read is REFUTED. It was a crypto-side artifact, not a PM bug.

What happened: @deploy CLOB-re-checked all 7 disputed rows. The CLOB tokens[].winner flag is the actual payout oracle = ground truth — and on all 7 rows we LOST. PM’s −cost_basis booking was correct; the retro-correction is zero-delta. The apparent “7 false losses” were an artifact of a flipped token-side cross-reference in an earlier crypto-side session, not a defect in PM’s booking pipeline.

Root mechanism — resolved_up over-books near-tie wins

Our outcomes.resolved_up (on-chain Chainlink settle ≥ K) over-books near-tie wins relative to the market’s Chainlink Data Streams settlement (the source Polymarket actually resolves on):

  • On the 2026-07-03 doubled-volatility day, ~15% of resolved fills disagreed between resolved_up and realized_pnl_usd.
  • The disagreement is concentrated entirely in sub-5bps near-ties: disputed cells had median |settle − K| of 0.9–4.8bps vs 8.9bps for the agreed-win cell.
  • This is the P&L-side confirmation of the refit study’s durable finding — resolved_up inflates high-conviction win rates by 4–7pt because near-tie flips land in those bins’ loss column (see 2026-07-03 refit-study bullet).

Binding conclusion

  • pmv2_autotrade_orders.realized_pnl_usd (CLOB / winner-flag derived) is the TRUSTWORTHY P&L label.
  • outcomes.resolved_up is a trading GATE, not settlement truth — do not use it for P&L, sizing, or certainty tiers.
  • Reconstructed P&L from resolved_up is optimistically biased — it showed 2026-07-03 as +88.
  • This reinforces the Chainlink Data Streams licensing track as the real label fix (Data Streams is the market’s settlement source; our on-chain read is a proxy that disagrees on near-ties). Data Streams stays a label-quality concern — see crypto-shortterm-competitor-wowitsamazing-refuted-2026-07-03 (on-chain settle vs CLOB truth disagree on 12.6% of windows, 35% within 2bps of strike).

Coverage caveat (context, not a correction)

realized_pnl_usd only has coverage from 2026-07-02 onward (the new booking pipeline). There is no pre-tweak settlement-grade P&L, so pre/post-tweak comparisons on true settlement are not possible yet. The only two booked days:

Dayrealized_pnl_usd
2026-07-02+$34
2026-07-03−$88
net≈ −$54

Graph View

Backlinks