The apps that work with OpenEik today, and how any app reads a version of the building, keeps its results beside it, proposes changes and stays in step with everyone else.
OpenEik is non-profit and vendor-neutral, so this is a directory and an open pattern, not an advertisement. Any app that reads or writes OpenEik models can be listed.
BIM authoring for people and AI agents, and the reference implementation of OpenEik.
ek engine reads, checks and edits OpenEik folders, every change a checked command.Structural analysis by the finite element method, to Eurocode, as a connector for AI assistants.
openeik command and libraryRead, check, hash, diff, push and pull OpenEik models, from the command line or inside an app. Written from the specification alone, with no dependencies.
A supplier reads a model, checks its railings against what it can make, and proposes changes.
The study is behind the roadmap's richer railing types, and behind the supplier pattern.
How suppliers propose in the model → No public link yet| In a code base | In an OpenEik project | For example |
|---|---|---|
| Small source files in one repository | One record per file, in discipline folders | structure/level-1/beam/beam-r8n2wc4d.json |
| Tools check out a commit and do their own job | Apps read a version, named by its hash, and do their discipline | Femra reads hall-b@c3d41f9a |
| CI results belong to one commit | Results name the version they were computed from | "computedFrom": {"version": "c3d41f9a…"} |
| A pull request carries code changes | A proposal carries typed, validated commands | beam B3: type-beam-360 → type-beam-450 |
| Required checks before merge | Checks before merge | utilisation ≤ 1.0 for every member |
| Code owners review their paths | Disciplines own their folders | analysis/frame-a/**: the structural engineer |
| A fork for an experiment | A fork or an alternative for a simplified model | a stick model for seismic analysis |
| “This branch is behind main” | “These results are stale” | computed from v2; the beam changed in v3 |
One difference, on purpose. A code host keeps CI results beside the repository. OpenEik keeps the results people rely on inside the tree, so they travel with the model: on disk, in any git host, or with a hosting service.
Steps 1–3 touch only the app's own folder. Steps 4–5, in oak, are the only way the building itself changes.
analysis/frame-a/.Hashes shortened and illustrative. ◆ a results commit: it touches only analysis/frame-a/. ○ a building version. The proposal carries the command and the results computed on it, so the reviewer sees the change and its check together. Today an app writes an alternative rather than the main line, and a person merges it.
hall-b/ ├── eik.json format, units ├── project/project.json levels.json materials/ ├── types/architecture/window/type-window-b.json ├── architecture/level-1/window/window-m4c8tq2h.json ├── structure/level-1/beam/beam-r8n2wc4d.json ├── analysis/frame-a/ Femra · structure │ ├── model.json source.json members/ loads/ … │ ├── results/r-5d1c0e9a7b32/manifest.json … │ └── proposals/p-b3-deeper.json ├── analysis/daylight/study-2f7k9xq4/ daylight ├── schedule/ project management ├── procurement/ procurement ├── requirements/daylight.json the project's requirements └── .eik/ generated, never committed
project/, types/, architecture/, structure/, systems/, site/. Changed only by commands, through review.
Written by that app, owned by its discipline. One item per file, in the stored form; text files of at most 1 MiB.
Per-member extremes, utilisations and summaries. Meshes, node displacements and full fields stay out: cheap to compute again.
Indexes, bodies, drawings and quantities are derived and rebuilt locally. Never committed.
Live in the reference implementation since 11 October 2026: files it does not know, such as analysis/…, are kept byte for byte through export, save, restore and merge. The layout of an app's folder is proposed for the specification.
Decided on 11 October 2026: results live in the tree, as long as it is clear which version they belong to. Two ways make it clear, and they work together.
analysis/frame-a/results/r-5d1c0e9a7b32/manifest.json{ "app": {"name": "femra", "version": "…"}, "computedFrom": { "inputs": {"count": 41, "digest": "3b0f6c2e…"}, "model": "a41e0c7d…", "upstream": null, "version": "c3d41f9a…", "versionKind": "openeik" }, "engine": {"codePack": "…", "kernel": "femra …"}, "format": "openeik-result/0.1-proposal", "kind": "structural-analysis", "made": {"at": "…", "by": "…"}, "summary": {"maxUtilisation": 0.71} }
The file says it itself, so it survives an export, a copy and any git host. inputs.digest is one hash over the path and hash of every record read; source.json lists them. The result manifest is proposed for the specification.
computedFrom.version is the version before the results were saved, and the commit that adds them is its child.The latest set per model, and every set an engineer signed, stay in the tree. The history keeps the rest; deleting an old run's folder is a normal change.
Computed, never written into a file. Hash the records source.json selects at the head and compare with inputs.digest. “Not the head” alone is not enough: saving results is itself a commit.
A run's id comes from its inputs, model and engine, so the same inputs give the same files. A new run gets a new folder, and the two compare member by member.
Today it is an alternative, whose start is recorded as its base; forks in another repository that remember their origin are planned. Ids stay the same, so each stick member can name the elements it stands for.
Analysed under a model id of its own, analysis/seismic-stick/. computedFrom.version is the line's version, and computedFrom.upstream names main's e5f6a0b2.
Never the simplification. A proposal to main with commands, such as bracing, reviewed like any other. Merged back by mistake, its folder still says it was not computed from main.
| Risk | Mitigation |
|---|---|
| Stale results read as current | The manifest is required: no result set without computedFrom and its inputs digest. Staleness is shown on every read, in viewers and in checks. A release can require fresh results. |
| Repository size | Per-element extremes and summaries only, as text files of at most 1 MiB. Meshes, node displacements and full fields stay out: cheap to compute again. The latest set per model and the signed ones stay; the history keeps the rest. |
| Results conflict in a merge | Never merged field by field: take one side, then run again on the merged version. After any merge, the inputs digest says whether a set still holds. |
| It blurs “build output is never committed” | Keep the line: bodies, drawings, quantities and indexes stay out. Results someone signs or relies on are a discipline's work, kept with their version. |
computedFrom names its version and digests its inputs; the manifest is proposed for the specification. Staleness is computed, never stored. Large fields stay out, and build output is still never committed.structure/; walls, slabs and roofs in architecture/; their types and materials; the levels. From its own folder: the analysis model, with members, panels, supports, loads, combinations and assumptions. No building record holds a load.analysis/frame-a/: the analysis model, one item per file; source.json with the records read and their hashes; results/<runId>/ with the manifest, one result per member and the report.beam-r8n2wc4d. Other items get ids from element and role, never a counter.model.json.analysis/frame-a/model.json units, basis, site source.json records read, with their hashes members/ panels/ supports/ loads/ … assumptions/ generators/ results/r-5d1c0e9a7b32/manifest.json results/r-5d1c0e9a7b32/members/beam-r8n2wc4d.json results/r-5d1c0e9a7b32/report.html proposals/p-b3-deeper.json
results/r-5d1c0e9a7b32/members/beam-r8n2wc4d.json{ "extremes": {"ULS-2": {"My": 41.3, "Vz": 18.9}}, "governing": {"check": "bending", "combination": "ULS-2"}, "id": "beam-r8n2wc4d", "utilisation": 0.71 }
Femra lives in its own repository and reads OpenEik folders by the format alone. Writing its analysis and results beside the building, as shown here, is designed and not built yet. Values and hashes are illustrative.
analysis/frame-a/proposals/p-b3-deeper.json{ "base": {"records": {"beam-r8n2wc4d": {"hash": "…", "revision": 4}}, "version": "e5f6a0b2…"}, "by": {"app": "femra …", "person": "…"}, "commands": [{ "expectedRevision": 4, "id": "beam-r8n2wc4d", "kind": "update", "patch": {"height": 450, "typeId": "type-beam-450"} }], "dryRun": {"ok": true}, "evidence": {"after": 0.86, "before": 1.08, "check": "bending", "run": "analysis/frame-a/results/r-…/manifest.json"}, "format": "openeik-proposal/0.1-proposal", "intent": "Deeper B3: bending utilisation 1.08" }
source.json says which.The proposal file is proposed for the specification. Commands are the reference implementation's command kinds today; a common command envelope is planned for OpenEik 0.2.
schedule/: tasks linked to element ids (4D), the status of each element, change orders. Each task names the version it was planned from.schedule/tasks/task-4k2m9q7d.json{ "elements": ["beam-r8n2wc4d", "beam-t5x1hb2k"], "finish": "2027-03-12", "id": "task-4k2m9q7d", "name": "Erect level 1 beams, grid A–C", "plannedFrom": "c3d41f9a…", "start": "2027-03-08", "status": "planned" }
The diff c3d41f9a → 9d01b7e4 (v2 → v4), building records only~ structure/level-1/beam/beam-r8n2wc4d.json profile 600 mm longer v3 height 360 → 450 v4 typeId type-beam-360 → type-beam-450 v4 analysis/, schedule/: not building records, left out
schedule/change-orders/co-0007.json{"changed": ["beam-r8n2wc4d"], "from": "c3d41f9a…", "id": "co-0007",
"impact": {"cost": "from the estimate", "days": 2},
"tasks": ["task-4k2m9q7d"], "to": "9d01b7e4…"}
procurement/: packages, orders, supplier quotes and delivery status. Each order line names the type id and the type's hash, and the order names the version it was ordered from.types/** between the ordered version and the head: a type whose hash changed after it was ordered. Counts by type are compared too.procurement/orders/po-0012.json{ "delivery": {"due": "2027-02-15"}, "id": "po-0012", "lines": [{"quantity": 24, "typeHash": "5a1c07e2…", "typeId": "type-window-b", "unit": "pcs"}], "orderedFrom": "e5f6a0b2…", "package": "pkg-windows", "status": "confirmed", "supplier": "supplier-a" }
types/architecture/window/type-window-b.json e5f6a0b2 → 2c9e71fa- "width": 1210, + "width": 1410,
Suppliers can take part directly: a supplier reads a version, checks what it can make, and proposes its own parts as checked commands, with a quote tied to that version. Supplier proposals →
analysis/daylight/study-2f7k9xq4/: study.json with the requirement used; results/<runId>/ with a manifest and one result per room. Grids are computed again, not stored. It may run on a simplified line.requirements/.…/study-2f7k9xq4/results/r-…/rooms/room-h3v8kd1p.json{ "meets": false, "ofRequired": 0.82, "requirement": "requirements/daylight.json", "room": "room-h3v8kd1p", "use": "bedroom" }
analysis/daylight/study-2f7k9xq4/proposals/p-bedroom-2.json{ "base": {"version": "9d01b7e4…"}, "commands": [{"expectedRevision": 2, "id": "window-m4c8tq2h", "kind": "update", "patch": {"typeId": "type-window-c"}}], "evidence": {"after": 1.04, "before": 0.82, "room": "room-h3v8kd1p"}, "format": "openeik-proposal/0.1-proposal", "intent": "Bedroom 2 below the daylight requirement" }
Values are illustrative and cite no regulation. A typed window's width and height are its type's: the reference implementation refuses a record that says otherwise, and the specification states the same rule.
| App | Reads | Writes | Proposes | Check before merge | Diffs and history for |
|---|---|---|---|---|---|
| Femra | beams, columns, slabs, walls, roofs, foundations, types, materials, levels; its analysis model | analysis/frame-a/ | a deeper section | utilisation ≤ 1.0 for every member | linked records changed; a run against a run |
| Project management | elements, levels, quantities, the history | schedule/ | rarely: time and cost on others' proposals | tasks hit; no task on a deleted element | change orders from version to version |
| Procurement | types, materials, takeoff by type | procurement/ | a substitute type | ordered types need procurement's review | types/** since the ordered version |
| Daylight | rooms, windows, walls, materials, site and true north | analysis/daylight/<studyId>/ | a larger window type | the requirement in every habitable room | rooms that crossed the line |
Every row reads a named version, writes only its own folder with a manifest naming that version, and changes the building only through a reviewed proposal.
analysis/<modelId>/; one item per file, in the stored form; text files of at most 1 MiB.computedFrom with the version and an inputs digest; the app, the engine, the settings.expectedRevision; reviewed and merged by a person.eik.json or AGENTS.md.The result manifest and the proposal file are proposed for the specification.
analysis/…, kept byte for byte through save, restore and merge (Stomra, 11 October 2026).eik.json in every version (Stomra, 11 October 2026).openeik command and library: in testing, public with the specification in Q4 2026.Host features, not part of the standard: any host can offer them. EikHub, a commercial host, is one being built.
The implementation guide and the openeik tools open with the specification in Q4 2026.
The directory at the top is rendered from apps.json, its single source, and changes whenever an app's status does.