Who changes this standard, how, and how you object
Whether a standard deserves trust depends on whether changing it follows rules, and on whether the people who proposed it can be bound by them.
We both author this standard and build a product against it. That position has an obvious problem: referee and player at once. We state it here, and put in place the half of the constraint we can put in place now.
How a change happens
Proposed in public
Every change, including ours, starts as a public GitHub issue stating what changes, why, and who it affects. A change without a public issue does not enter a version.
An objection window
Breaking changes, which invalidate an existing implementation, stay open at least 14 days; non-breaking ones at least 7. Anyone may object; objections stay in the issue alongside our response, and are not deleted.
Vectors first
A spec change comes with a change to the conformance vectors, and those run against us first. If we cannot pass our own new rule, it is not ready to ship.
Version and changelog
Semantic versioning. Breaking changes go into a major version, and the previous version's vectors remain runnable: so anyone already integrated has time to migrate, instead of waking up non-conformant.
Three commitments
① No retroactive changes
The criteria of a published version are never altered after the fact. An implementation that passes v1.0 today does not become non-conformant tomorrow because we changed the rule. Changes go into a new version.
② The standard is not a weapon
We will not introduce a rule only we can pass. The test is concrete: every vector must run against any implementation and reference nothing internal to OceanAlt. That constraint is written at the top of the vector file and can be checked in code.
③ We are measured before anyone else is
Our own conformance results are re-run daily and published, failures included. Whether others run the tests or publish results is their call. We do not make being tested a condition for anything; we put ourselves on the scale first.
How to object
Objecting needs no permission. Three routes, pick one:
- ① Say it in the issue: Every change has a public issue; objections and our replies stay on the record.
- ② Refute it with a vector: If you think a rule is wrong, write a counter-example that makes it fail. That is the strongest form of objection, and we take it.
- ③ Write to us: business@oceanalt.com. If public is inconvenient, start privately.
The governance above works at the level of process and is in effect today. The next level is ownership: the standard held by an entity no single party controls. SWIFT is a Belgian cooperative: members are shareholders and central banks jointly oversee it, and that is what neutrality looks like. Since October 2026 the RAP specification lives in a separate GitHub organization, rap-spec (github.com/rap-spec/rap), with the text under CC BY 4.0 and the code and test vectors under Apache 2.0, so anyone can use, change and propose changes to it. OceanAlt serves as the editor today, with a set path for handing the repository to a neutral foundation or standards body, described below.
We are not setting up a neutral entity now because the order matters. When SWIFT was founded in 1973 it was a network put together by 239 banks; its governance grew over the decades after it had become infrastructure. Handing the standard over too early would tie its hands just when it most needs to iterate quickly.
So the path is: the four steps and three commitments above apply today, and once at least three unrelated organizations publish conformance runs, the editors will propose moving the repository to a neutral foundation or standards body chosen by the implementers. Both licenses allow that move without any single contributor's consent.