/ writings ·

Open the rails, or you don't have rails

Infrastructure makes itself replaceable on purpose. If the spec is in your private repo, the only people building on you are you. Notes from the IPTO open-source push.

By Abhishek Krishna

The OpenAPI spec is not a goodie you ship after the product works. It is the test of whether the product is actually rails. A rail you cannot fork is a product with a moat. A rail you can fork is infrastructure.

There is a quiet move every infrastructure company makes right before it actually becomes infrastructure. They stop calling it a product.

The day Stripe published Stripe Docs and the day Postgres became the default Postgres are, in the way that matters, the same day. The product was the rails. The rails were the spec. The spec was open. Everyone re-implementing it was free advertising for the canonical version.

If you are building a settlement layer of any kind in 2026, that move is the move.

What “open the rails” means in practice

For IPTO, the move took roughly six weeks of work and looked like this:

  • A public OpenAPI v1 specification, served at specs/openapi-v1.yaml. Every endpoint that a paying client touches is described in machine-readable form, with the request and response shapes anyone can codegen against.
  • A TypeScript SDK generated from that spec, with examples and a minimal-typescript starter, so a developer can clear their first license in a tab.
  • A public Developers hub at /developers: quickstart, auth, errors, idempotency, webhooks. Same surface every working API has had for the last decade. The fact that it took us a minute is part of the lesson.
  • SECURITY.md, CODE_OF_CONDUCT.md, CONTRIBUTING.md on every public repo, including the node-llama-cpp-ipto fork. Disclosure path, governance, upstream-merge plan. Not theater: a real channel.
  • The stablecoin toolkit and Meridian RWA stack open source under kcolbchain, with the production contracts and the production-grade tests in the same repo.

None of this is a marketing campaign. It is the cost of being a layer other people build on.

Why a private spec means you are not a rail

A rail is something other people build on. Building on means: read the spec, generate a client, ship something that breaks if the rail breaks. That sentence has to be true for someone outside the founding team, or you do not have a rail, you have an internal service.

If the spec is in your private repo, the only people who can build on you are you. Which is fine, if you are a product. But it disqualifies the company from any sentence that contains the word “infrastructure.”

The check is brutally simple. Can a competent stranger, without asking you, integrate against the system in an afternoon? If the answer is no, the rails are not real. The rails are a sales motion in a trench coat.

Fig. 01 · What grows around an open spec, vs what doesn't grow around a closed one many one spec public 6 months 18 months Closed spec: only first-party integrations SDKs in 3 languages community examples competing impls canonical version wins distribution Open spec: ecosystem compounds
Two trajectories on the same axis. A closed spec stays flat: every integration is a sales motion. An open spec compounds, because each new integration lowers the cost of the next. By the time competing implementations appear, the canonical version has already won the distribution. That is the bet.

Choosing to be replaceable, on purpose

The hardest internal conversation in any open-source push is the one where someone asks: doesn’t publishing the spec just let a competitor re-implement us? And the answer is yes. That is the point.

A licensing rail that nobody else can re-implement is a licensing rail nobody trusts, because rights holders cannot believe they will still get paid if your company gets bought. A rail whose spec is open is a rail whose payment guarantee survives the founder. That is what makes it a rail. That is what makes a rights holder willing to wire their catalogue to it.

The same argument applies on the other side. A developer who picks the canonical OpenAPI client and ships a feature on a Tuesday afternoon is now part of the network. They are not locked in. They could fork. They will not, because the canonical implementation is the cheapest place to do the work, and the network has already grown around it.

You become a rail by choosing to be replaceable. The reward is being chosen.

What this is not

Open-spec is not “we threw a README on GitHub.” It is not a developer marketing strategy. It is not an excuse to write less documentation because “it is open.” The minimum bar is:

  • A machine-readable spec that codegens a working client.
  • An idiomatic SDK in at least one language, with a working starter project.
  • A security disclosure channel that a stranger can find without asking.
  • A contributor path that does not require a 30-minute call with the founder.
  • Production code that matches the spec, today, in the canonical implementation.

Everything above that is good. Anything below it is theater.

Where this leaves us

IPTO is open-spec from this month forward. The licensing API is a public document. The TypeScript client is a public package. The stablecoin and RWA components running underneath kcolbchain are open-source, with production tests in the same repo. The bet is that a real licensing market needs rails, real rails need to be open, and rights holders will trust a system they can verify over a system they cannot.

If we are right, the network grows around the spec faster than anyone can re-implement it cheaper than us. If we are wrong, somebody re-implements it better, and the world still gets a working licensing layer. Both outcomes are acceptable. Only one of them is theater.

Sources