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