OpenEik.org
Roadmap

Where OpenEik stands, and where it grows next.

OpenEik 0.1 is a working draft: in testing now, public in Q4 2026. This page says what the standard covers today, what comes next, and how that compares with IFC. It changes with every change to the standard. For the apps that already work with it, see Apps.

Last updated 11 October 2026Version 0.1.0-draftStatus In testing now; public in Q4 2026
  • In the draft (0.1)Written into the 0.1 working draft, with schemas where it has records.
  • Next (0.2)Decided for the next version.
  • Before 1.0Decided; lands before the first stable version.
  • PlannedWe intend to add it to the standard; no version yet. “Later” means after the building domains.
  • ExploringBeing worked out. A proposal at most, not yet decided.
Architecture (In the draft (0.1)) Structure as built (In the draft (0.1)) Site and terrain (In the draft (0.1)) Views and sheets (In the draft (0.1)) Structural analysis models (Exploring) Building services and service networks (Planned) Schedules and 4D (Planned) Costs and 5D (Planned) Quantities (In the draft (0.1)) Infrastructure (Planned) Facility management and assets (Planned) Classification (Next (0.2)) IFC export (In the draft (0.1)) IFC import (Planned)
What the standard covers

Domain by domain, beside IFC.

IFC has grown since the 1990s and covers a wide field. OpenEik starts with the building as it is designed and built, and grows from there.

Architecture

In the draft (0.1)

Walls, slabs, roofs, ceilings, doors and windows, rooms, stairs, railings and shafts, each with its type.

  • In the draft (0.1)Normative rules turn the records into bodies: layered walls and slabs, openings cut in their hosts, pitched roofs, and wall tops attached to a roof or a floor (Part IV).
  • Next (0.2)Richer railing types, so a manufacturer can read and propose them: how a railing is mounted (side or top), post shapes and the posts' positions, panel patterns and rail shapes. Decided for 0.2, from a study with a railing manufacturer; the same will follow for other building parts.
In IFC 4.3

Walls, slabs, roofs, doors, windows, spaces, stairs and railings.

Structure as built

In the draft (0.1)

Beams, columns, foundations, slab edges, reinforcement, timber framing, steel parts such as plates, bolts and welds, and precast pieces and joints.

  • In the draft (0.1)Members' reference lines, axes and joins are normative (Part IV, 6).
  • In the draft (0.1)Timber framing, trusses, precast and steel joints are reference behaviour in 0.1: an engine may derive them its own way.
In IFC 4.3

Beams, columns, footings, plates, fasteners and reinforcement.

Site and terrain

In the draft (0.1)

Terrain, grading, property lines, planting, and site roads and parking as elements.

In IFC 4.3

The site and geographic elements such as terrain; earthworks cut and fill since IFC 4.3.

Views and sheets

In the draft (0.1)

Views are records: plans, sections, elevations, 3D and drafting views, with their settings and 2D items. The drawings they show are derived.

  • In the draft (0.1)Sheets, title blocks and images stay application records: carried and kept, not defined by the standard (decided 11 October 2026).
In IFC 4.3

Annotations: points, curves, text, dimensions and hatching.

Structural analysis models

Exploring

The analysis model and its results belong to the app that made them, kept beside the building. Only what an analysis reads from the building is in the draft.

  • In the draft (0.1)Each member's axis: the line that analysis tools and analytical exports must use (Part IV, 6.5).
  • In the draft (0.1)An app keeps its analysis and results in its own folder beside the building, in units it states. Every writer keeps them as they are, so they travel with the model (Part III, 7).
  • ExploringA result manifest that names the version the results were computed from, so stale results show. A proposal.

Proven in practice by Femra, a separate structural analysis app: it reads OpenEik models by the format alone and builds its analysis models from them, and is designed to keep its analysis and results beside the building, tied to the version they were computed from.

In IFC 4.3

Structural analysis models, in the structural analysis domain.

Building services and service networks

Planned

Systems as networks: what connects to what, and which way it flows.

  • In the draft (0.1)Pipes, ducts and terminals are elements today, with sizes, a system name, a terminal's flow and the terminals a run's ends join.
  • PlannedSystems, connections between any two components, flow direction and equipment.
In IFC 4.3

Distribution systems as networks, with ports and the connections between them.

Schedules and 4D

Planned

Tasks and work schedules, tied to the elements they build.

  • In the draft (0.1)Today an app can keep a schedule beside the model, in its own folder, pointing at elements by id.
In IFC 4.3

Tasks and work schedules.

Costs and 5D

Planned

Cost items and cost schedules, tied to elements and quantities.

  • In the draft (0.1)Today an app can keep costs beside the model, in its own folder, pointing at elements by id.
In IFC 4.3

Cost items and cost schedules.

Quantities

In the draft (0.1)

Derived by the compiler from the records, never stored. The reference engine reports volumes, layer volumes, wall areas per side and roof areas.

  • ExploringStandard quantities as typed values, each with its unit, basis and rule. 0.1 does not standardise quantities yet.
In IFC 4.3

Element quantities, with standard quantity sets.

Infrastructure

Planned

Later: roads, rail, bridges and tunnels as infrastructure, on alignments.

In IFC 4.3

Roads, railways, bridges, and ports and waterways, on alignments: new in IFC 4.3. Not yet tunnels.

Facility management and assets

Planned

Later: assets, maintenance and the building in use.

In IFC 4.3

Assets, and action requests such as work requests.

Classification

Next (0.2)

Neutral references on any record to a code of any classification system: classifications: [{system, code, edition?}].

  • In the draft (0.1)No national code list is part of the standard: a code list belongs to its publisher, who sets its licence and editions.
In IFC 4.3

Classification references.

IFC export

In the draft (0.1)

IFC is a bridge, not the base: OpenEik is the source, and IFC is a delivery format produced from it. Part VIII is informative in 0.1, apart from its few rules.

  • In the draft (0.1)IFC4 export with a GlobalId per element that stays the same across versions and forks, and a fidelity report with every export (Part VIII).
  • PlannedLater: an IFC 4.3 export.
In IFC 4.3

—

IFC import

Planned

IFC files read into native OpenEik records.

  • In the draft (0.1)Today the reference implementation links an IFC file as a reference model, beside the records, not as records.
In IFC 4.3

—

The IFC 4.3 column follows the official IFC 4.3.2.0 documentation (ISO 16739-1:2024). Tunnels are not in IFC 4.3; buildingSMART is adding them in IFC 4.4. standards.buildingsmart.org/IFC/RELEASE/IFC4_3/HTML/

The standard itself

Commands, ids and the derived layer.

Ids

In the draft (0.1)

Every id is stable for the life of its record, and contains no /.

Part I, 6

A command envelope

Next (0.2)

Around every command or batch: an operation id, attribution to the person and the agent, the target, the mode and an intent.

Part V, 10

Error codes

Next (0.2)

Machine-readable codes for every refusal.

Part V, 6

Preconditions

Next (0.2)

A precondition on every command: it names the state the command was based on, and a mismatch is refused, so two writers cannot overwrite each other unseen.

Part V, 3

The derived layer's format

Next (0.2)

The layout of the optional .eik/derived/ folder and the schema of a result, keyed by the records it was derived from.

Part IV, 1.1

Materials by id

Before 1.0

Layers name their material by id (materialId) instead of by name, with a migration.

Part II, 4

Records at a declared level of detail

Next (0.2)

From interface only (envelope, fixings, clearances) up to the full manufacturing model, the supplier's choice, each record saying what it is authoritative for. Interface only is the valid minimum, not the rule.

The conformance suite

Planned

The full suite comes with the public release in Q4 2026. The draft has the schemas, the checker and two examples; test vectors for compilers are not published yet.

Conformance
Done in 0.1.0-draft
  • The specification text, Parts I–VIII: foundations, language, code base, compiler, commands, history, agent interface and bridges.
  • Eight conformance classes: reader, validator, writer, compiler, command processor, version store, agent host and bridge.
  • 81 JSON Schemas (2020-12), one for every kind of file in a model folder and one for the single-file form, with an index that maps paths to them.
  • Two example models: a one-storey house built with typed commands only, and an L-shaped house.
  • The openeik checker and library: check, hash, tree, diff and log; no dependencies, written from the specification alone.
  • Licences: the text under CC-BY-4.0 with a royalty-free patent commitment (OWFa 1.0); schemas and examples under CC0; tools under Apache-2.0.
To be decided
  • Whether every writer must mint ids by one pattern, such as <kind>-<6 base-32 characters>. Until then it is a recommendation. Part I, 6.5
  • The reference line and axis of a beam built from a framing family, such as a truss or a purlin. Part IV, 6.5
  • The file name of the single-file form; .eik.json is proposed. Part III, 11
  • A non-profit body to hold OpenEik, separate from any commercial service, is being considered before the public launch. Governance
Not planned
  • Regional profiles and national code lists. OpenEik will carry no national classification or code list. A code list belongs to its publisher; fields that hold such values stay plain strings, and classification references name codes of any system.

This page is rendered from roadmap.json, its single source. The specification itself opens with the public release.