昨天，我確認了一件事：排名相關資料並不是完全不存在。

YouTube Music 給了我官方頭號聽眾徽章，Last.fm 回傳了 YOASOBI 的累積聽眾數，ListenBrainz 也提供部分聽眾的 listen 數，以及來源回報的帳號總數。

但拿到三份資料，不代表可以直接把它們放進同一個排行榜。

今天要解決的不是「名次怎麼算」，而是更前面的一個問題：系統如何知道，眼前這兩個數字究竟能不能比較？

有數字，不代表是在量同一件事

我的 YouTube Music 匯出檔是一筆筆活動紀錄，沒有逐筆實際播放秒數。朋友的 Spotify 則有來源提供的播放毫秒。ListenBrainz 回傳的又是它自己的 listen 計數。

這三種資料看起來都跟聽音樂有關，但不能因為最後都是整數，就認為彼此等價。

一筆活動不一定是完整播放。來源提供的播放毫秒，也不會自動變成另一個平台定義的合格 listen。朋友的資料更不能拿來填我的缺值。

因此今天我替比較資料加上的，不只是一個 value，而是「這個 value 到底在說什麼」。

它需要交代藝人、統計期間、計算規則、資料持有人、來源，以及目前已知和未知的部分。

「兩千多人」和「九筆資料」必須同時留下

昨天取得的 ListenBrainz 八月資料，是很適合拿來檢查契約的真實例子。

來源回報有 2,189 個聽過 YOASOBI 的帳號，但 API 實際列出的只有九個。

如果程式只留下收到的九列，後面就很容易把「九個看得到的帳號」當成全部聽眾。反過來，如果只留下 2,189，也可能讓人誤以為我們已經知道每個帳號的收聽量。

所以我把它們拆開保存：來源回報的帳號數、實際返回的帳號數，以及是否已獨立重算完整分母。

目前的答案是 2,189、9，以及「還沒有」。最後一項維持未知，不能把九列數一遍就宣稱完成重算。

同樣的原則也用在被截斷的藝人清單上。清單裡沒出現 YOASOBI，不等於那個帳號聽了零次；它可能只是沒被列出。

同樣叫八月，也不能省略時間的意思

另一個容易混淆的地方是日期。

一張徽章可能表示八月的收聽狀況，九月初核發，而我是在九月下旬提供截圖。這是三個不同時間。

資料契約現在把「統計期間」、「核發日期」和「取得時間或日期」分開。來源自己的更新時間也另外保留，不拿取得時間補進去。

有些來源只說某個月份，沒有說月界採用哪個時區；這時我保留月份標籤，不假裝知道精確起訖。

這樣做看起來麻煩，但否則系統只要看到兩個地方都寫八月，就可能忽略邊界與規則的差別，直接把它們放行。

徽章的原文，比我猜的單位更重要

今天也把昨天保留的 21 筆 YOASOBI 徽章逐筆放進契約檢查。

其中 16 筆新式文字寫的是「你排名前 0.01」，沒有明示百分比符號；另外五筆較早的徽章則明確寫出百分比。

對於前者，程式保存原文，單位保持未知。對於後者，已經明示的百分比就保留下來，不把它丟掉。

徽章上顯示的「4285 萬」也仍然是顯示文字，不被改成可以拿來計算精確名次的整數分母。

這不是否定徽章。它是平台給我的正式位置證據，但它沒有公開我的原始分數，也沒有提供完整排序。能保留這項證據，和能把它換成 ListenBrainz 的 listen_count，是兩回事。

更完整的新舊徽章語意解讀，仍留在後面的專題處理，今天不先猜答案。

今天真的通過了一個比較，但不是我的名次

為了避免整個系統只會回答「不行」，我也找了一個真的可以通過的案例。

同一份 ListenBrainz 八月快照裡，兩個已列出的帳號，來源 listen_count 分別是 5,712 和 923。

它們來自同一份資料、同一個藝人識別、同一套來源計數規則，以及同一個來源時間窗。系統因此允許比較這兩個來源數值。

這個正例有很清楚的範圍：它不是我的帳號，也不是全球聽眾，更不代表九列榜單已經變成完整分布。

但它證明了一件重要的事：不完整的榜單，仍然可能支持某些有限的比較；只是不能順便支持所有排名問題。

不同要求，要有不同狀態

今天的驗證器把結果分成三種。

comparable 表示這一次比較所需的條件成立。今天的正例，就是同一份快照裡兩個帳號的來源分數比較。

blocked 表示還缺少條件，例如我的 YOASOBI 分數尚未建立、活動與 listen 的規則不相容、期間對不齊，或只取得截斷分布。

unsupported 則表示目前這份證據不支持該種要求，例如把徽章當成 raw score、把藝人總聽眾數當成個人分數，或要求這些來源直接給出全球自然人名次。

這些狀態是對「一次比較要求」的判斷，不是把某個平台永久貼成有用或沒用。

而且，程式除了回傳狀態，也會列出原因。日後畫面說「目前不能比較」時，就不必只留下一句沒有解釋的錯誤訊息。

ChatGPT 今天做了什麼，又怎麼驗證？

今天由 ChatGPT 協助整理契約、實作欄位驗證與比較前檢查，再把昨天保存的實際資料放進驗收流程。沒有另外啟動獨立 Codex 任務。

我特別要求：不能靠合成一個漂亮的使用者分數，來讓真實案例通過。

因此，真實案例使用保留的 ListenBrainz 回應，以及昨天已驗收的徽章和 Last.fm 結構化轉錄；來源檔也綁定雜湊，內容改變時就必須停下來檢查。

十個要求案例中，一個可以進行有限的來源內分數比較，五個被缺少條件擋下，四個不受目前證據支持。所有名次與百分位欄位都保持空值。

另外再用明確標示的合成反例，測試未知值被改成零、九列被冒充完整分母、活動被改名成合格 listen，以及新式徽章被擅自補上百分比等情況。這些錯誤都不能偷偷通過。

最後也跑過全專案回歸測試、既有的大量活動資料測試，並重驗昨天保存的公開回應和資料前綴。今天沒有重新處理私人原檔，也沒有重新呼叫 Last.fm，更沒有下載完整的大型資料庫。

過程中還遇到一個實際失敗：同樣的證據檔，在 Windows 取出時被自動轉換了換行符號，導致雜湊不符。資料內容看起來沒變，原始位元組卻已經不同。

我沒有把驗證關掉，也沒有重新填一個「會通過的雜湊」，而是讓固定證據檔保持原始位元組。重現問題、修正後，再確認 Windows 和 Linux 的測試都通過。這也提醒我：保存證據，連儲存與取出方式都要一起驗證。

今天往全球位置問題前進了哪一步？

今天沒有新增一個可以分享的名次。

新增的是一套可執行的規則，讓後續功能知道：現在比較的是什麼、證據到哪裡、還缺什麼，以及哪些結果不能說出口。

資料契約也不等於排名引擎。完整群體的成員、同分處理和排名計算，仍然需要之後另外實作與驗收。

我的最終問題依然是：只用 YouTube Music 的我，聽 YOASOBI 的程度，放到其他平台聽眾之中會在哪裡？

下一步，就要先處理這個問題真正需要的一塊基礎：我的紀錄裡，哪些內容真的屬於 YOASOBI？

不能只因為頻道名稱或歌名看起來像，就把所有紀錄算進去。明天從真實資料的藝人歸屬開始，繼續往前走。