NADA is an open specification.
Anyone can build an implementation.
NADA defines how code is shown in a human language and mapped back to one canonical source. This page is the compatibility contract: what an implementation must do to interoperate with every other. The language data is CC-BY and the tools are AGPL, so anyone can build on them.
Three properties an implementation must hold.
An implementation is compatible if it holds three properties at once. They are deliberately narrow, so “compatible” means the same thing everywhere. They cover the mechanics — that the mapping is lossless, canonical, and faithful — not coverage or translation quality.
The transformation is lossless in both directions. Code rendered into a human language and saved back to disk is byte-for-byte identical to the original. No meaning, formatting, or comment is dropped.
Without it: A round-trip that changed the program would split the ecosystem into files that no longer agree.
The file that is committed, shared, and run is always the canonical English source. The reader’s language is a view over that one source, not a second copy that can drift from it.
Without it: If each language wrote its own on-disk form, the same program would fork into many incompatible files. One source on disk keeps everyone reading the same code.
Every keyword, identifier, and term shown to the reader maps to the canonical source through the published NADA language data. Nothing is invented, mistranslated, or approximated. What you read is what runs.
Without it: A rendering that changed the meaning would make the displayed language untrustworthy, which is what the standard exists to prevent.
What you read is what runs. The two never diverge.
Protection against fragmentation and capture.
A standard anyone can extend is a standard anyone can break. Two failures would end NADA’s usefulness. The contract addresses both.
If incompatible implementations all called themselves NADA, the same code would read differently, or stop running, depending on whose tool opened it. A file would no longer mean the same thing everywhere.
The language data is free and open on purpose. The risk: a company takes the data, ships a closed product on top of it, takes the audience, and lets the open project decline. Keeping the source canonical and the project open is what keeps the open version the one everyone can rely on.
This is part of how NADA stays open: free data under CC-BY, open tools under AGPL, and one canonical source everyone shares.
An open standard stays whole by being defined once, and testable by anyone.
A published spec and a test anyone can run.
Open standards define conformance by normative, testable requirements — long before any formal certification program exists. NADA follows the same path, and is honest about which parts exist today.
The published spec and the open language data define what a compatible implementation must produce. The pipeline that builds and checks the data is AGPL, so anyone can reproduce it. [TO CONFIRM: canonical URL of the published specification.]
An open compatibility test suite — reversibility, on-disk canonicalisation, rendering fidelity — is planned, so any implementation can check itself against the contract. Until it ships, NADA’s own tooling is the reference implementation. [TO CONFIRM: test-suite location and release.]
A “NADA-compatible” mark, a trademark policy, and formal certification will follow if an ecosystem of independent implementations makes them useful. Today there is one implementation — NADA’s own — so there is nothing to certify yet, and we do not pretend otherwise.
Free to build on.
The data and tools are open. The name is the one thing held back, so that “NADA” can come to mean “meets the spec” once there is a spec to meet and implementations to compare.
Language data CC-BY · pipeline AGPL · run by Chris Shelley and Rev Miller as a non-profit; entity pending. A trademark and mark-usage policy are planned, not yet in force. [TO CONFIRM: governing jurisdiction.]
Get in touch.
If you are implementing NADA, or want to, we would like to hear from you. Early implementers shape the specification and the test suite.
chris@nadalang.org · specification and tests on request.