Consumer Coordinability 的核心責任是把「可協調」從一個感覺變成四項查得到的事實。版本與退場決策常用「消費者少而可協調」這類判準，而多數人不會問「可協調」的成立條件是什麼，於是它變成一個沒有人反對也沒有人驗證的形容詞。這張卡處理的是「有沒有能力通知與協調」；通知本身怎麼發、退場時程怎麼排，是另一件事（見 Deprecation Lifecycle）。適用對象是 API Consumer Shape 裡第一種形態（有人格的整合團隊）——其餘三種形態不需要這份判定：非人格中介恆為零、內部呼叫端恆為滿、聯絡不到的外部整合方恆為零。

概念位置

可協調度由四項獨立事實組成，它們可以任意組合，而缺任何一項都會讓遷移計畫在不同的地方失效。

列得出名單：查得出誰在呼叫，而且是可以逐一點名的清單而非一個總數。判準綁在憑證來源上——名單必須來自服務端自己核發存取憑證、且憑證不可轉授的系統。憑證可被下游代持或整合方可再包裝販售時，名單只涵蓋直接客戶而非實際使用者。

發得出通知：名單上每一列都有一個現在還有效的聯絡方式，而且是工程師會看到的地方。聯絡人會離職、共用信箱會停用，因此這一項的強度隨名單年齡衰減，而帳面上的名單長度看不出這件事。in-band warning（在 response 裡回 deprecation 標頭或欄位）的觸及率不依賴聯絡資料的新鮮度，因此不隨名單老化衰減；要觸及所有仍在呼叫的整合方則仍需 brownout——退場前刻意讓舊行為短時間失效，用一次真實故障找出既沒讀公告也沒看標頭的那些（三種工具各自觸及誰見 Deprecation Lifecycle）。

握有 SDK：消費者透過官方維護的 SDK 呼叫時，一部分變更可以在 SDK 內部吸收，消費者只需要升版——契約責任通常要兩端配合，而 SDK 是少數服務端單方面就能履行的位置（契約責任的全貌見 API Contract）。這一項把「改 client 的程式碼」降級成「升一個依賴」，是四項裡槓桿最大的。反過來說，社群自製的 client 不在這個範圍內，而它們的比例通常沒有人統計過。

有強制力：合約、平台審核、或商業關係構成要求對方在期限前完成遷移的依據。多數公開 API 沒有這一項，而少數有的（app store、支付平台）會發現它同時是最強與最貴的手段——用一次消耗的信任，比省下的協調成本多。

可觀察訊號與例子

四項的常見組合各有典型後果。列得出名單但發不出通知，退場當天的客訴會來自名單上確實有的整合方。發得出通知但沒有 SDK 也沒有強制力，遷移完成率取決於對方的排程優先序，而這個變更在對方的 backlog 裡通常排在很後面。四項都有的情境（自家 mobile app 走自家 SDK）實際上已經接近可原子更新，判準應該直接跳到 API Consumer Shape 的第三種形態（可原子更新的內部呼叫端）。

集中度是四項之外的修正項。單一客戶佔九成流量時，協調得動的是那九成、永遠協調不動的是那條長尾，而退場當天的事故全發生在長尾上。可協調度因此不是一個整體數字，而要看「協調不動的那部分佔多少」——可觀察的形式是近三十天流量的 per-consumer 佔比排序與尾部合計。

設計責任

判定可協調度要留下產物而非結論：一份名單（來源標明）、一次通知的實際送達率、SDK 涵蓋的呼叫比例、以及尾部佔比這個數字。寫成「可協調」兩個字的判定無法複驗，而它會在幾年後被當成仍然成立的前提沿用——四項裡每一項都會隨時間衰減，而沒有人負責觀察它們。

這份判定在版本策略裡是選型判定序的一環，見 版本策略流派之爭；名單與尾部佔比要靠 11.12 API 消費者用量觀測 提供；通知鏈的三種工具與各自的觸及對象見 Deprecation Lifecycle。