About Edoxen
Edoxen is a set of information models used for representing resolution and decision information. It gives every formal resolution — from ISO technical committees to Athenian inscriptions — the same shape, the same vocabulary, and the same multilingual plumbing, so a single YAML file can travel untouched from one standards body to another.
The Name & Logo
The Name
The name comes straight out of the Athenian decree-stele tradition. Every surviving resolution of the Athenian dēmos opens with the same stock phrase — ἔδοξεν (edoxen), the aorist of the verb ἐδόκεω (edokeō), "it seemed good to":
"It was the opinion of the People and the Council that…"
That single formula is the parent of every modern phrase that begins "il a été décidé", "es wurde beschlossen", "it was resolved", "se ha decidido". Edoxen the project is named after the formula, because that formula is the least common ancestor of every resolution we model.
The full phrase appears on IG II² 1368 (Athens, 336/5 BC, the honorific decree for Demosthenes), on IG I³ 71 (the Athenian Tribute Lists), and on the hundreds of other fragments catalogued under the corpus inscriptionum Atticarum. Every one of those inscriptions begins with ἔδοξεν τῇ βουλῇ καὶ τῷ δήμῳ — and every one of those inscriptions is the same act: a body of people recorded a decision they had agreed upon.
We picked the name because the model is the same act: a body of standards committees sharing a substrate, recorded in a machine-tractable way.
The Logo
The mark is a stoichedon (στοιχηδόν, "in rows") — the formal inscription style in which every Greek letter sits in its own square cell. The cells contain the six letters Ε Δ Ο / Ξ Ε Ν, spelling out the project name Edoxen in Greek capitals:
Three design choices come straight out of the etymology:
- The 3×2 grid. Stoichedon is the inscription technique used on every surviving Athenian decree-stele. Each letter in its own cell — a row-and-column structure — also happens to be the cleanest visual metaphor for structured data: a parent field, a column of languages, and sibling entries inside a
localizations[]array. - The serif. The wordmark uses a transitional serif (Iowan Old Style → Palatino → Georgia fallback). Slab and transitional serifs are the family of letterforms that come closest to the chiselled capitals of an inscription; the gradient is the Edoxen cyan-teal brand, applied only to the wordmark so the stoichedon mark stays a neutral glyph the palette can adapt.
- The mark spells the name. The letters in the cells are not decoration — they are the name, in the alphabet of the body whose resolutions we are trying to model. Edoxen = ΕΔΟΞΕΝ.
Mark only
The stoichedon mark is also published as a square glyph for use in social cards, OG embeds, and favicons:
The Colors
The Edoxen palette is built around Attic sky-blue and sea-blue — the colour of the Aegean horizon over the Piraeus, and the colour of the cyanotypes used by 19th-century epigraphers to publish the Inscriptiones Graecae.
| Token | Light | Dark | Use |
|---|---|---|---|
--vp-c-brand-1 | #0e7490 (cyan-700) | #67e8f9 (cyan-300) | Hero name, links, accents |
--vp-c-brand-2 | #035a8f (sky-700) | #38bdf8 (sky-400) | Gradient end, hover |
--vp-c-brand-3 | #013a5e (sky-900) | #0ea5e9 (sky-500) | Active/pressed |
--vp-c-brand-soft | rgba(14,116,144,.14) | rgba(103,232,249,.14) | Card backgrounds |
The contrast stays WCAG AA against either background — the only case where a project brand ever sees an inversion is the navbar logo, which is shipped in two files (edoxen-logo-full.svg and edoxen-logo-full-dark.svg) so the mark on light and the mark on dark are each tuned for their backdrop.
Origin Story
Modern standards organizations publish thousands of resolutions every year. ISO, IEC, ITU, BIPM, OIML, ILO — each has its own document convention, its own publication workflow, its own data model. Even within one organization the format drifts over the years: a 1980 resolution carries a different heading than a 2020 resolution, and PDFs are the only canonical artefact, which is to say there is no canonical artefact.
Edoxen starts from one observation: every one of those resolutions has the same shape — who, when, considering what, deciding what, approved by whom. The shape is universal; the layout is per-body. So the project is the layer that captures the shape once, in a YAML format humans can edit and a Ruby parser can round-trip, and leaves the layout to each body.
The first reference corpus was the OIML Resolutions archive — 1,640 resolutions across 28 CIML and Conference meetings, half in English and half in French. ISO/TC 154 and ISO/TC 184/SC 4 came later. Three independent bodies, three independent publication conventions, one common model.
Mission Statement
Edoxen's mission is to give every formal resolution — past, present, and future — a single canonical representation that is human-readable, machine-roundtrippable, multilingual by default, and free at the point of use.
Concretely:
- One model, one YAML, one schema, validated by
edoxen validate. - One library to parse and serialize — built on lutaml-model, so round-trip parity is a property of the framework, not of hand-rolled code.
- One locale-neutral parent for every per-language rendering, so EN↔FR translation drift becomes visible on
git diffrather than invisible across files.
The Ecosystem
| Project | Description | Category |
|---|---|---|
metanorma/edoxen-model | LutaML/UML information-model definition (class diagrams, attribute types) | Core |
metanorma/edoxen | Ruby gem, JSON Schema, CLI (edoxen validate, edoxen normalize) | Core |
metanorma/edoxen.github.io | This site — user-facing documentation | Core |
oimlsmart/resolutions-data | Reference corpus: 1,640 OIML resolutions × EN+FR | Reference data |
isotc154/resolutions-data | Reference corpus: ISO/TC 154 resolutions | Reference data |
isotc184sc4/resolutions | Reference corpus: ISO/TC 184/SC 4 resolutions | Reference data |
| lutaml-model | Underlying serialization framework | Upstream |
Round-trip serialization (YAML → Ruby → YAML) flows through lutaml-model. There is no hand-rolled to_yaml / from_yaml anywhere in Edoxen; wire-format drift would be a framework bug and lives upstream.
Use Cases
📋 Standards-body archival
Convert decades of PDF resolutions into a single searchable, version-controllable YAML corpus.
🌐 Multilingual by default
EN + FR (or any ISO 639-3 pair) live in the same file. Translators see both blocks side by side; drift shows up on `git diff`.
✅ Schema-validated pipelines
Run edoxen validate on every commit. Wire format is locked; typos surface as data_pointer errors, not silent ignores.
🔁 Cross-body interop
Same `Resolution` shape across ISO, IEC, ITU, BIPM, OIML, ILO. Per-body quirks captured in enum extensions, not in per-body schemas.
📚 Linked-data archival
Assign DOIs and URNs to every resolution at creation time, so the canonical record is citable from day one.
🧩 Custom extensions
Fork the schema to add a new action-verb, date kind, or metadata field — no upstream PR required.
Standards Support
Edoxen is the common substrate across the resolution conventions of:
| Body | Resolutions | Locale |
|---|---|---|
| ISO, ISO/TMB | Council, TMB, TCs | EN+FR |
| IEC | Council, SMB, TCs | EN+FR |
| ITU-T, ITU-D, WTSA | Plenary, study groups | EN+FR+ES+RU+AR+ZH |
| BIPM / CGPM | Conférence générale, CIPM | EN+FR |
| OIML | CIML, Conferences | EN+FR |
| ILO | Conference, Governing Body | EN+FR+ES |
A Resolution model that satisfies one body satisfies them all, because per-body quirks (numbering prefixes, agenda-item references, date kinds, action-verb vocabularies) are expressible inside Edoxen's enums and extension points rather than baked into the schema.
The wire format itself draws on four ISO standards:
- ISO 639-3 — three-letter language codes (
eng,fra,deu). - ISO 15924 — four-letter script codes (
Latn,Cyrl,Hant). - ISO 3166-1 alpha-2 — country codes (
FR,DE,JP). - ISO 8601 — date syntax (
2025-10-14,2025-10-14/15).
Open Source
Edoxen is an open source project of Ribose, released under the 2-Clause BSD License.
- GitHub organization — github.com/metanorma
- Gem —
metanorma/edoxen - Models —
metanorma/edoxen-model - Site —
metanorma/edoxen.github.io - License — 2-Clause BSD
- Issues — on each individual repo
We welcome contributions: schema extensions, new reference corpora, CLI improvements, and localization help for non-EN/FR languages are all good first-PR territory. Open an issue on the relevant repo to discuss the change before sending the PR.
Get Started
Ready to model resolutions? Three commands:
gem install edoxen
edoxen validate resolutions/*.yaml
edoxen normalize resolutions/*.yaml --output normalized/Then read the docs in this order:
- Introduction — what Edoxen is, what problem it solves, a working YAML.
- Schema — the JSON Schema, including every invariant and extension point.
- Multilingual support — the
localizations[]rationale. - Localization sync flow — the deep-dive on EN+FR alignment inside a single file.
- CLI —
validateandnormalize, batch and per-file. - Parsing YAML / Creating resolutions — the Ruby API, with a small round-trip example.
Or step outside the docs and read the LutaML model files — that's the formal definition of every class, every attribute, every enum value, in the LutaML/UML notation. The YAML schema and the Ruby classes are both generated from those models. The docs are the introduction; the models are the ground truth.
Open source project of Ribose · maintained alongside lutaml.