Who changes this standard, how, and how you object
Whether a standard deserves trust does not depend on who proposed it. It 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 are not going to pretend otherwise. We are going to state it, 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 (those that 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 — it is checkable in code, not a slogan.
③ We are measured before anyone else is
Our own conformance results are re-run daily and published, failures included. If we ask others to be measured, we stand 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. RAP is currently maintained by OceanAlt; its ownership is not yet neutral.
Why not set up a neutral entity now? 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. A governing body for a standard nobody uses yet would be an empty shell, and handing the standard over too early would tie its hands just when it most needs to iterate quickly.
So the path is: process-level constraints apply today (the four steps and three commitments above), and neutralising ownership starts once there is real adoption. What counts as real adoption, and who takes the standard over, are not yet decided.