{
  "$comment": "The single source of openeik.org/roadmap; see ROADMAP.md. Update it with every change to the standard and set `updated`. It must agree with the spec: CHANGELOG.md (Planned), spec/09-conformance.md and spec/10-open-questions.md. Then run `node tools/roadmap.mjs` to refresh the page's no-script copy. Text in `backticks` is shown as code.",
  "updated": "2026-10-11",
  "version": "0.1.0-draft",
  "release": "In testing now; public in Q4 2026",
  "statuses": [
    {
      "id": "draft",
      "label": "In the draft (0.1)",
      "text": "Written into the 0.1 working draft, with schemas where it has records."
    },
    {
      "id": "next",
      "label": "Next (0.2)",
      "text": "Decided for the next version."
    },
    {
      "id": "v1",
      "label": "Before 1.0",
      "text": "Decided; lands before the first stable version."
    },
    {
      "id": "planned",
      "label": "Planned",
      "text": "We intend to add it to the standard; no version yet. “Later” means after the building domains."
    },
    {
      "id": "exploring",
      "label": "Exploring",
      "text": "Being worked out. A proposal at most, not yet decided."
    }
  ],
  "domainsLede": "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.",
  "domains": [
    {
      "name": "Architecture",
      "status": "draft",
      "what": "Walls, slabs, roofs, ceilings, doors and windows, rooms, stairs, railings and shafts, each with its type.",
      "parts": [
        {
          "status": "draft",
          "text": "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)."
        },
        {
          "status": "next",
          "text": "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."
        }
      ],
      "ifc": "Walls, slabs, roofs, doors, windows, spaces, stairs and railings."
    },
    {
      "name": "Structure as built",
      "status": "draft",
      "what": "Beams, columns, foundations, slab edges, reinforcement, timber framing, steel parts such as plates, bolts and welds, and precast pieces and joints.",
      "parts": [
        {
          "status": "draft",
          "text": "Members' reference lines, axes and joins are normative (Part IV, 6)."
        },
        {
          "status": "draft",
          "text": "Timber framing, trusses, precast and steel joints are reference behaviour in 0.1: an engine may derive them its own way."
        }
      ],
      "ifc": "Beams, columns, footings, plates, fasteners and reinforcement."
    },
    {
      "name": "Site and terrain",
      "status": "draft",
      "what": "Terrain, grading, property lines, planting, and site roads and parking as elements.",
      "parts": [],
      "ifc": "The site and geographic elements such as terrain; earthworks cut and fill since IFC 4.3."
    },
    {
      "name": "Views and sheets",
      "status": "draft",
      "what": "Views are records: plans, sections, elevations, 3D and drafting views, with their settings and 2D items. The drawings they show are derived.",
      "parts": [
        {
          "status": "draft",
          "text": "Sheets, title blocks and images stay application records: carried and kept, not defined by the standard (decided 11 October 2026)."
        }
      ],
      "ifc": "Annotations: points, curves, text, dimensions and hatching."
    },
    {
      "name": "Structural analysis models",
      "status": "exploring",
      "what": "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.",
      "parts": [
        {
          "status": "draft",
          "text": "Each member's axis: the line that analysis tools and analytical exports must use (Part IV, 6.5)."
        },
        {
          "status": "draft",
          "text": "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)."
        },
        {
          "status": "exploring",
          "text": "A result manifest that names the version the results were computed from, so stale results show. A proposal."
        }
      ],
      "proof": "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.",
      "ifc": "Structural analysis models, in the structural analysis domain."
    },
    {
      "name": "Building services and service networks",
      "status": "planned",
      "what": "Systems as networks: what connects to what, and which way it flows.",
      "parts": [
        {
          "status": "draft",
          "text": "Pipes, ducts and terminals are elements today, with sizes, a system name, a terminal's flow and the terminals a run's ends join."
        },
        {
          "status": "planned",
          "text": "Systems, connections between any two components, flow direction and equipment."
        }
      ],
      "ifc": "Distribution systems as networks, with ports and the connections between them."
    },
    {
      "name": "Schedules and 4D",
      "status": "planned",
      "what": "Tasks and work schedules, tied to the elements they build.",
      "parts": [
        {
          "status": "draft",
          "text": "Today an app can keep a schedule beside the model, in its own folder, pointing at elements by id."
        }
      ],
      "ifc": "Tasks and work schedules."
    },
    {
      "name": "Costs and 5D",
      "status": "planned",
      "what": "Cost items and cost schedules, tied to elements and quantities.",
      "parts": [
        {
          "status": "draft",
          "text": "Today an app can keep costs beside the model, in its own folder, pointing at elements by id."
        }
      ],
      "ifc": "Cost items and cost schedules."
    },
    {
      "name": "Quantities",
      "status": "draft",
      "what": "Derived by the compiler from the records, never stored. The reference engine reports volumes, layer volumes, wall areas per side and roof areas.",
      "parts": [
        {
          "status": "exploring",
          "text": "Standard quantities as typed values, each with its unit, basis and rule. 0.1 does not standardise quantities yet."
        }
      ],
      "ifc": "Element quantities, with standard quantity sets."
    },
    {
      "name": "Infrastructure",
      "status": "planned",
      "what": "Later: roads, rail, bridges and tunnels as infrastructure, on alignments.",
      "parts": [],
      "ifc": "Roads, railways, bridges, and ports and waterways, on alignments: new in IFC 4.3. Not yet tunnels."
    },
    {
      "name": "Facility management and assets",
      "status": "planned",
      "what": "Later: assets, maintenance and the building in use.",
      "parts": [],
      "ifc": "Assets, and action requests such as work requests."
    },
    {
      "name": "Classification",
      "status": "next",
      "what": "Neutral references on any record to a code of any classification system: `classifications: [{system, code, edition?}]`.",
      "parts": [
        {
          "status": "draft",
          "text": "No national code list is part of the standard: a code list belongs to its publisher, who sets its licence and editions."
        }
      ],
      "ifc": "Classification references."
    },
    {
      "name": "IFC export",
      "status": "draft",
      "what": "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.",
      "parts": [
        {
          "status": "draft",
          "text": "IFC4 export with a GlobalId per element that stays the same across versions and forks, and a fidelity report with every export (Part VIII)."
        },
        {
          "status": "planned",
          "text": "Later: an IFC 4.3 export."
        }
      ],
      "ifc": ""
    },
    {
      "name": "IFC import",
      "status": "planned",
      "what": "IFC files read into native OpenEik records.",
      "parts": [
        {
          "status": "draft",
          "text": "Today the reference implementation links an IFC file as a reference model, beside the records, not as records."
        }
      ],
      "ifc": ""
    }
  ],
  "ifcSource": "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.",
  "standard": [
    {
      "name": "Ids",
      "status": "draft",
      "what": "Every id is stable for the life of its record, and contains no `/`.",
      "where": "Part I, 6"
    },
    {
      "name": "A command envelope",
      "status": "next",
      "what": "Around every command or batch: an operation id, attribution to the person and the agent, the target, the mode and an intent.",
      "where": "Part V, 10"
    },
    {
      "name": "Error codes",
      "status": "next",
      "what": "Machine-readable codes for every refusal.",
      "where": "Part V, 6"
    },
    {
      "name": "Preconditions",
      "status": "next",
      "what": "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.",
      "where": "Part V, 3"
    },
    {
      "name": "The derived layer's format",
      "status": "next",
      "what": "The layout of the optional `.eik/derived/` folder and the schema of a result, keyed by the records it was derived from.",
      "where": "Part IV, 1.1"
    },
    {
      "name": "Materials by id",
      "status": "v1",
      "what": "Layers name their material by id (`materialId`) instead of by name, with a migration.",
      "where": "Part II, 4"
    },
    {
      "name": "Records at a declared level of detail",
      "status": "next",
      "what": "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.",
      "where": ""
    },
    {
      "name": "The conformance suite",
      "status": "planned",
      "what": "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.",
      "where": "Conformance"
    }
  ],
  "done": [
    "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."
  ],
  "open": [
    {
      "text": "Whether every writer must mint ids by one pattern, such as `<kind>-<6 base-32 characters>`. Until then it is a recommendation.",
      "where": "Part I, 6.5"
    },
    {
      "text": "The reference line and axis of a beam built from a framing family, such as a truss or a purlin.",
      "where": "Part IV, 6.5"
    },
    {
      "text": "The file name of the single-file form; `.eik.json` is proposed.",
      "where": "Part III, 11"
    },
    {
      "text": "A non-profit body to hold OpenEik, separate from any commercial service, is being considered before the public launch.",
      "where": "Governance"
    }
  ],
  "notPlanned": [
    {
      "name": "Regional profiles and national code lists",
      "text": "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."
    }
  ],
  "ifcSourceUrl": "https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/HTML/"
}