這套標準由誰改、怎麼改、你怎麼反對
一套標準值不值得信，不取決於誰提出它，取決於改它有沒有規矩 —— 以及提出它的人能不能被約束。
我們現在既寫這套標準，又按它做產品。這個位置天然有問題：既當裁判又當運動員。我們不打算假裝這個問題不存在，而是把它擺出來，並先做能做的那一半約束。
變更流程
公開提出
任何變更 —— 我們自己提的也一樣 —— 先在 GitHub 開一個 issue，寫清改什麼、為什麼、會影響誰。沒有公開 issue 的變更不進版本。
留出異議期
破壞性變更（會讓已有實現失效的）至少留 14 天；非破壞性變更至少 7 天。期間任何人可以反對，反對意見連同我們的回應一起留在 issue 裡，不刪。
向量先行
改了規範就要改一致性向量，而且要先跑我們自己 —— 如果新規則連我們自己都不過，那它還不成熟，不該發。
版本與變更記錄
語義化版本。破壞性變更進大版本，並且舊版本的向量繼續保留可跑 —— 讓已經接入的人有時間遷移，而不是某天早上發現自己不合規了。
三條承諾
① 不追溯
已發佈版本的判定標準不會被事後改動。今天按 v1.0 通過一致性測試的實現，明天不會因為我們改了規則而變成不合規。要改，改的是新版本。
② 不用標準打擊對手
我們不會引入一條只有我們能通過的規則。判斷方法很簡單：每條向量都要能對任何實現跑，而且不引用任何 OceanAlt 內部概念 —— 這條約束寫在向量文件的註釋第一段，不是口號，是可以拿代碼檢查的。
③ 測別人之前先測自己
我們自己的一致性跑分每天自動重跑並公開，包括沒通過的。要求別人接受檢驗，自己得先站上去。
怎麼反對
反對不需要許可。三條路，任選：
- ① 在 issue 裡說 —— 每個變更都有公開 issue，反對連同我們的回應一起留檔，不刪。
- ② 用向量反駁 —— 如果你認為某條規則不合理，寫一個能讓它失敗的反例。這是最有力的反對方式，我們照收。
- ③ 直接寫信 —— business@oceanalt.com。不方便公開的，可以先私下說。
上面是程序層面的治理，今天已經生效。更進一步的是所有權層面：標準由一個任何單方都不能控制的實體持有。SWIFT 是比利時的合作社，會員即股東，由各國央行聯合監督，這是中立的樣子。RAP 目前由 OceanAlt 維護，所有權還沒有中立化。
為什麼不現在就成立中立實體？順序不能反。SWIFT 1973 年成立時是 239 家銀行湊起來的一張網，治理結構是在它成為基礎設施之後的幾十年里長出來的。一個還沒人用的標準，治理機構只會是空殼；過早把標準交出去，也會在它最需要快速迭代的時候綁住手腳。
所以路徑是：程序層面的約束今天就生效（上面四步和三條承諾），所有權中立化在形成真實採用之後啟動。什麼算真實採用、由誰接手，目前還沒有定論。