.Odin

Every industry has the same problem: systems that don't speak the same language.

Legacy "standards" lock data into proprietary formats. Point-to-point integrations multiply. When an systems such as AI processes your data, it inherits every ambiguity your format allows. ODIN was built to be the canonical layer, the single representation that every system, every transform and every pipeline can rely on.

Learn More Browse 300+ Schemas

policy.odin

Try the Playground

{policy}
id = "PLY-2024-09841"
type = "commercial-auto"
effective = 2024-06-01
expiration = 2025-06-01
payment = #$2328.80:USD
premium = #$12475.00:USD
active = ?true
{.insured}
name = !"Meridian Logistics LLC"
taxId = *"84-2190553"
drivers = ##12
{.vehicles[] : year, make, model, vin, coverage}
##2024, "Ford", "F-150", "1FTEW1EP5RFA01234", #$50000
##2023, "Ram", "2500", "3C6UR5DL4PG98765", #$50000
##2024, "Chevy", "Silverado", "1GC4YPEY3RF11223", #$75000
{.discounts[] : type, amount}
"multi_vehicle", #$284.37:USD
"autopay", #%2.5

0% Fewer Tokens 0% Smaller Payloads 0+ Industry Schemas

Built for Systems. Ready for AI.

ODIN is human readable but machine first. Every design decision serves a single goal: unambiguous meaning that survives transport between systems, standards, and language models.

Self-Describing Types

Value prefixes (#, ##, #$, ?, @, ^, ~) eliminate parsing ambiguity. A parser or an LLM sees # and knows 'number follows.' No guessing. No schema lookup required.

AI-Native Efficiency

30% fewer tokens and 40% smaller than JSON on average, while carrying more semantic information per byte. Less data, more meaning. At scale, that's a direct reduction in LLM API costs and cleaner context windows for better model reasoning.

Transform Engine

Declarative transforms bridge legacy formats to ODIN and back. Map fields, apply verbs, and convert between JSON, XML, CSV and fixed-width. No code required.

300+ Industry Schemas

Production-ready schemas for insurance, healthcare, finance, legal, and real estate. Validate data at the canonical layer, not at every integration point.

Inline Modifiers

Mark fields as required (!), confidential (*), or deprecated (-) right in the data. Metadata travels with values across every system boundary.

Deterministic Output

Same data always produces the same output. Enables hashing, digital signatures and deduplication. Not possible with formats that allow multiple representations.

One Model. Every Direction.

ODIN is the canonical data model at the center of every integration. All data flows through it: inbound from legacy systems, outbound to modern APIs, and inline with AI pipelines.

Instead of building N-to-N mappings between every system pair, every format converts to ODIN once. Schemas validate the canonical form. Transforms are declarative and version-controlled. Whether you're bridging a legacy industry standard or feeding structured data to an LLM, the path runs through ODIN.

Bridge Legacy Standards

Declarative transforms map legacy formats like AL3, HL7, FIX and EDI into a canonical model without rewriting integration logic.

AI-Ready Transport

Typed, compact, and unambiguous. 30% fewer tokens, 40% smaller payloads, and richer semantics in every byte. LLMs receive cleaner context with zero type-guessing.

Schema Validation

Validate at the canonical layer, not at every endpoint. One schema governs all inbound and outbound data.

Declarative Transforms

JSON, XML, CSV and fixed-width. Transforms are inspectable, testable and version-controlled. No glue code.

300+ Industry Schemas

Insurance, healthcare, finance, legal and real estate. Production-ready schemas you can adopt today, not build from scratch.

Deterministic Output

Same data, same output, every time. Enables hashing, digital signatures, and audit trails across multi-party exchanges.

Forms. Built Into the Format.

ODIN is the only data format with a native forms specification. Define print-first form layouts declaratively, absolute positioning, field validation, data binding, and schema integration. One definition renders to both PDF and HTML.

Print-First

Fixed page dimensions, absolute coordinates. Pixel-perfect PDF output that matches screen rendering exactly.

Data Binding

Fields bind to ODIN paths with @path.to.field. Submission produces a validated ODIN document.

Schema Integration

Form fields reference schema types directly. Validation constraints, enum options, and type safety come from the schema.

Repeating Regions

Regions bind to arrays with automatic overflow handling. 8 drivers on a 4-driver form? Pages clone automatically.

Forms Reference Form Builder

See Transforms in Action

JSON in. Declarative mapping. Typed ODIN out. No code, no glue logic.

input.json

rating.transform.odin

{$}
odin = "1.0.0"
transform = "1.0.0"
direction = "json->odin"

{$table.RATES[vehicle, factor]}
"sedan", #1.0
"truck", #1.35

{policy}
insured = %upper @.name
base = @.basePremium :type currency
factor = %lookup "RATES.factor" @.vehicle
premium = %round %multiply @.basePremium @.discountRate ##2

output.odin

Open the Transform Lab Transform Reference

Format Comparison

How ODIN stacks up against existing data interchange formats.

Feature	JSON	XML	ProtoBuf
Self-describing types
Inline modifiers
Nesting support
Token efficiency
Whitespace independent
Human readable
Deterministic output
Diffable (line-based)
Schema language	JSON Schema	XSD/DTD	Built-in
Transform engine		XSLT
Tabular mode
Native binary type			Native
References (@)
Forms specification

Limited

Open by Principle

ODIN is fully open source, specifications under CC-BY 4.0, code under Apache 2.0. Its governance model is transparent. Its schemas are community-extensible. Its transform engine is deterministic and inspectable.

No proprietary gatekeeping. No hidden licensing barriers. Contributors are welcome to refine and expand the schemas while working openly on the standard.

Shared infrastructure should remain shared.

View on GitHub Browse Schemas

Built for Industries That Can't Afford Ambiguity

ODIN replaces fragile, format-locked industry standards with a canonical model that works across systems, across parties and across pipelines.

When a carrier sends a policy to an agency, when a hospital transmits a claim, when an LLM structures a quote from unstructured input, the data flows through ODIN. One schema library. One transform engine. One source of truth.

Insurance

Healthcare

Financial Services

Legal

Real Estate

AI / LLM

Regulatory Reporting

Multi-Party Exchange

Where translation errors cost both time and money. Where schema standards drift breaks integrations.

Types Are In The Data, Not The Documentation

JSON has 6 types. XML has none by default. ODIN has nearly 3x as many, currency, percent, integer, date, duration, binary, PII-masked, and more, all self-describing on the wire.

JSON

{
  "amount": 0.1250,           // number — BTC? USD? required? unknown
  "fee": 0.0025,              // number — 0.25% or literal 0.0025?
  "executed": "2024-06-15",   // string — date? caller must guess
  "wallet": "bc1qx...k7",     // string — no signal this is sensitive
  "confirmations": 6          // number — integer or float? assume
}

Numbers, strings, and guesses. You need a data dictionary for every file.

ODIN

{trade}
amount = !#$0.1250:BTC     ; required, currency, BTC with 4 decimals
fee = #%0.25               ; percent literal (0.25%)
executed = 2024-06-15      ; date (YYYY-MM-DD)
wallet = *"bc1qx...k7"     ; string, downstream confidential (* modifier)
confirmations = ##6        ; integer (## prefix)

Currency with code, percent, date, confidential, integer. The data tells you.

Start Building on ODIN

Read the specification, browse 300+ industry schemas, define transforms, or convert your data live in the playground.

Standard Reference Schema Library Transform Reference Playground Form Builder