Why is IFC so hard to edit?
Explained like you are 8. Then the other side of the story: why IFC was built this way, and why it made sense when it was.
Your LEGO house, stored as an instruction book.
Imagine your LEGO house isn't stored as the house, but as a giant instruction book with 50,000 numbered steps.
Step 4711 is “the window”. It doesn't say where; it says “see step 9182”. Step 9182 says “placed relative to step 233”. Step 233 is the wall, placed relative to step 87, the floor, which is placed relative to step 12, the building.
The hole in the wall is a separate step. Another step says “this hole belongs to that wall”, and another says “this window fills that hole”. The window's colour and size are on another page, tied on with yet another numbered string.
That is how an IFC file stores a building. A real one is hundreds of thousands of lines that point to each other by number.
Now: “make the window 20 cm wider”.
Find every piece.
Find the right page among 50,000, then follow the strings from step to step to find every piece that belongs to the window.
Redraw the hole too.
Change the window's shape. But the hole doesn't follow: it is a separate drawing of a box. Redraw the hole too.
Nothing adjusts itself.
Shapes are stored as finished drawings, not ideas. The book doesn't say “a wall from here to there, 20 cm thick”; it says “a box with these exact corner points”. Make the wall longer, and the window, the corner joint and the roof connection stay where they were.
One wrong string, and nobody tells you.
If one string points to the wrong number, the house breaks silently. The book still looks fine: a valid file can hold a wrong building.
The numbers change every time.
The step numbers are like page numbers in the book: the program needs them to find its way, but they don't tell you anything about the house. And the book may be renumbered every time it is saved: compare yesterday's book with today's and almost every line looks changed, even if you moved one window.
lines changed between two exports of the same, unchanged model.
of the file rewritten after five objects were removed and five added.
Liu, Gao, Gu, EG-ICE 2023[4]
Thousands of references to follow, and nothing checking the work.
The numbers matter to the program, which uses them to link the pieces. To an AI working on a task they say nothing about the building, yet thousands of them fill its working memory, the context window, with bookkeeping. It has to follow chains of them to find the few lines that matter, and change several far-apart pages exactly in step, with nothing checking its work.
Independent research agrees. On BIM-Edit, the first shared benchmark for editing IFC, the best of seven current models averages 49.5%, and none fully solves more than 3.4% of its 324 tasks[1]. Even reading IFC is hard: the best agent on ifc-bench v2 answers 56.6% of questions[3]. Agents lose track of coordinates and relative placement[2].
One small file with a real name.
Each thing is one small file, in a sensible folder, saying what it is: window W-12 in wall A, 1.2 m wide, sill at 0.9 m.
The engine works out the shapes, the holes and the joints. Every change is a command, checked against the whole model before it is applied. So the window gets wider in one file, the engine cuts the new hole, and the diff shows exactly that.
architecture/level-0/window/w-12.json { "category": "window", "id": "w-12", "hostId": "wall-a", "along": 3000, "offset": 900, - "typeId": "type-window-1200", - "width": 1200, + "typeId": "type-window-1400", + "width": 1400, "height": 1200 } ✓ checked · 1 file · the hole re-cut
| The same window | In the instruction book (IFC) | In OpenEik |
|---|---|---|
| Where is it? | Follow the strings: #4711, #9182, #233, #87, #12 | architecture/level-0/window/w-12.json |
| What does it say? | A finished shape, a separate hole, and the relations that tie them | What it is: in wall A, 1.2 m wide, sill at 0.9 m |
| Make it wider | Edit the shape and the hole, and keep every string right | One command; the engine cuts the new hole |
| Is it right? | A valid file can still be a wrong building | Checked against the whole model before it is saved |
| What changed? | Almost every line, after the next export | The one file |
Why IFC looks like this: it is a 3D PDF.
IFC was designed to carry the output of every BIM program, each with its own private rules. The one thing they all share is the result, so that is what IFC stores: finished shapes, their places and their properties. Not the intent behind them[5][6].
A PDF
Make one from a Word document, a Mathcad sheet or a drawing program, and it looks exactly right. But it is lines and letters. The formula in the Mathcad sheet is gone: change a number and nothing recalculates. It is a print.
An IFC file
Export one from any BIM program, and it opens anywhere and looks right. But the wall is a finished solid. “From here to there, attached to the roof” is gone: make it longer and nothing follows.
So
A print is right for handing a finished model over and keeping it for the record, and that is what IFC is for. It is the wrong place to keep editing the building. That is what OpenEik is for, and it exports IFC as the bridge.
Its ISO title says what it is for: “Industry Foundation Classes (IFC) for data sharing in the construction and facility management industries”[7].
What OpenEik keeps from IFC, and what it changes.
Keeps
- Meaning. A wall is a wall, a door is a door, each in its storey, not a heap of shapes.
- Types. Elements share a type that sets their layers, sections and sizes.
- Properties. Data rides on the element it describes.
- Neutrality. No program owns the model, and any program can read it.
- An open standard. Open text, open schemas, open tools. And IFC stays the bridge: OpenEik exports it.
Changes
- Intent, not frozen results. The record says what the thing is; the engine derives its shape, holes, joints and quantities.
- Names, not numbers. Every record has an id that stays for its whole life.
- One record per file. In meaningful folders, so a change touches the files it changes.
- Typed commands. Every change is checked against the whole model before it is applied.
- Versions. Diffs, history, branches and merges, as a code base has.
- Nithyanantham, Kujat, Sesterhenn, Telgmann, Nedungadi, Plönnigs, Bartelt, Lüdtke. BIM-Edit: Benchmarking Large Language Models for IFC-Based Building Information Modeling. arXiv:2606.20146, 2026.
- Heimig-Elschner, Du, Scheuvens, Borrmann, Beetz. A Modular Reference Architecture for MCP-Servers Enabling Agentic BIM Interaction. arXiv:2601.00809, 2025.
- Hellin, Jang, Fuchs, Nousias, Borrmann. BIM Information Extraction Through LLM-based Adaptive Exploration. arXiv:2605.01698, 2026.
- Liu, Gao, Gu. A Parallel IFC Normalization Algorithm for Incremental Storage and Version Control. EG-ICE 2023, pp. 511–520 (arXiv:2312.14931).
- Ji, Borrmann, Beetz, Obergrießer. Exchange of Parametric Bridge Models Using a Neutral Data Format. Journal of Computing in Civil Engineering 27 (6), 2013, pp. 593–606.
- Kim, Pratt, Iyer, Sriram. Data Exchange of Parametric CAD Models Using ISO 10303-108. NISTIR 7433, 2007.
- ISO catalogue: ISO/PAS 16739:2005; ISO 16739:2013; ISO 16739-1:2024, Industry Foundation Classes (IFC) for data sharing in the construction and facility management industries.