The Philosophy
Every system speaks a dialect. Every integration is a translation. And every translation introduces the possibility of error.
For decades, industries have solved this with point-to-point mappings, proprietary standards and format-specific schemas. The result is an ever-growing web of brittle integrations where meaning is lost in transit.
ODIN-L, the Open Data Interchange Notation Language, starts from a different premise: what if there were a single canonical representation that every system could translate to and from? Not a replacement for JSON or XML, but a governed middle layer where meaning is preserved, types are explicit and validation happens once.
This is the canonical data model. All formats flow through it. Schemas validate the canonical form. Transforms are declarative, inspectable and version-controlled. Whether data moves between legacy systems, modern APIs or AI pipelines, it passes through ODIN with its meaning intact.
The Name
In Norse mythology, Odin was the god of wisdom.
He sacrificed certainty for knowledge. He sought structure beneath chaos. He understood that symbols, when properly defined, carry power.
Data is our modern symbol system. And like the runes of old, poorly defined symbols create confusion. Ambiguous structure creates fragile integrations. Repeated translation introduces error.
The name is the philosophy. A notation named after wisdom, not force. A system designed to remove ambiguity from shared meaning, not to impose a single way of working.
ODIN exists to remove ambiguity from shared meaning.
Design Principles
Canonical by default
Same data always produces the same output. No optional formatting, no key ordering ambiguity, no multiple valid representations.
Types travel with values
A number is a number. A currency is a currency. A boolean is a boolean. The format tells you, not the schema, not the documentation, not the developer who wrote it.
Metadata belongs in the data
Required fields, confidential values and deprecated paths are marked inline. When data crosses a system boundary, its constraints cross with it.
Transforms are first-class
Bridging legacy standards should not require custom code. Declarative transforms map fields, apply conversions and produce validated output across formats.
Schemas are shared infrastructure
Industries should not each reinvent their data models. ODIN provides 300+ production-ready schemas as a starting point, not a constraint.
Open by principle
Fully open source, specifications under CC-BY 4.0, code under Apache 2.0. No proprietary gatekeeping. No hidden licensing barriers. Shared infrastructure should remain shared. Contributors are welcome to refine and expand the schemas while working openly on the standard.