Kept in its own fork
Article numbers, costing and its own design data live in the supplier's fork and folder, in its own organisation.
Suppliers on OpenEik
Suppliers on OpenEik: propose the real product, in the model.
How a building-product supplier works on a project the way an open-source contributor works on a code base: invited in, working in its own copy, checking with its own tools, and proposing the parts it will actually make, with a quote, for the client to review in the model.
The worked example is railings on balconies. The same pattern applies to every building part and every supplier. All names, versions and amounts on this page are synthetic. OpenEik is an open, non-profit, vendor-neutral standard: this page describes an open pattern that any supplier and any host can follow.
01 The problem today
Today a supplier prices its own reading of someone else's drawings.
It gets PDFs
Plans, sections and a railing schedule, exported from the design model. The model itself, if it is shared at all, is a one-off export.
It re-draws and quotes on its interpretation
The supplier re-draws the railings in its own tool to work out what it can make, then prices that. The client never sees the re-drawn version in the model.
Deviations are found late
A post in another place, a lower height, a corner the system cannot make: these surface at shop drawings or on site, not when the quote is accepted.
Quote and drawing drift apart
The design keeps changing after the quote. Nothing says which drawing a price was for, or that it no longer fits.
Comparing suppliers means comparing PDFs
Each bid describes a slightly different product in its own format. Checking them against the building is manual work.
What is missing is one shared, versioned place where the supplier's real product sits in the model, next to the design it replaces, with the price tied to it.
02 The code analogy
A supplier on a project works like a contributor on a code base.
| Open-source contributor | Supplier on OpenEik | Railing example (synthetic) |
|---|---|---|
| Invited to a repository | Invited to a project, with a supplier role | Supplier A reads the whole model, as it gets a complete IFC today |
| Forks the repository | Works in its own copy, in its own organisation; writes only there | a fork of the project at version 4f8e2a6b |
| Changes the code | Replaces the designed parts with parts it can make | 12 designed railings become Supplier A's railings |
| CI runs the tests | Its own tool checks manufacturability | green, yellow or red per railing, with deviations |
| Opens a pull request | Opens a proposal: the parts, a diff against the design, and a quote | typed commands for the railings, plus the quote as an attachment |
| Review and merge | The client reviews in 3D and accepts | the client merges Supplier A's proposal |
The building is stored as a code base: one record per file, versions, diffs, merges and typed commands. So the contributor's workflow carries over almost unchanged.
03 The flow · seven steps · synthetic example
From invitation to order, the model holds what will be made.
- Invite as a supplier: it reads the whole model and writes only to its fork.
- Read a named version; find every railing by category.
- Work in its own fork.
- Check with its own tool: green, yellow or red, with deviations.
- Open a proposal: typed commands for the changed elements, plus the quote.
- The client reviews diff, check and quote together, and merges one.
- The model holds what will be made; the order is tied to that version.
By default a supplier reads the whole model, as it gets a complete IFC today; the client may narrow it to some parts. It writes only to its own line of work, a fork or an alternative.
04 The diff · Supplier A on balcony B2 · synthetic example
The diff is the deviation report.
R-1
ManufacturablePosts 200 mm in from the corners; the design had them at the corners.
R-2
Very closeHeight 1070 instead of 1100, the system's standard height. Side-mounted on the slab edge.
R-3
Not manufacturable as drawnThe corner is outside the system's range. Alternative proposed: two runs with a shared corner post.
Every railing is one record in one file, so a host can show the change per railing and per field, in 3D and as text. Nothing has to be re-typed into a deviation list: the list is the diff, and the check status sits beside it.
architecture/level-2/railing/railing-r2h6tq9c.json · 4f8e2a6b → proposal { "category": "railing", - "height": 1100, + "height": 1070, "hostId": "slab-b2", "id": "railing-r2h6tq9c", "mark": "R-2", "railing": { "edges": ["slab-b2:edge:3", "slab-b2:edge:0", "slab-b2:edge:1"], - "inset": 50 + "inset": -25, + "posts": {"at": [200, 1350, 2500, 3650, 4800]} }, - "typeId": "type-railing-design-1100" + "typeId": "type-railing-supa-s1070" } + types/architecture/railing/type-railing-supa-s1070.json new type ~ railing-r1… railing-r3… and 9 more 12 railings
A negative inset puts the line outside the slab edge, as for side mounting. posts.at (post positions along the line, in mm) is not in 0.1: it is one of the railing additions planned for 0.2 (see the first pilot).
05 The quote · tied to a version · synthetic example
The quote is tied to the exact version it priced.
quote.json · an attachment on Supplier A's proposal{ "supplier": "Supplier A", "pricedVersion": "4f8e2a6b…", "inputs": {"count": 27, "digest": "b71c09e4…"}, "lines": [ {"marks": ["R-1", "R-4", "R-5", "…"], "type": "type-railing-supa-s1100"}, {"marks": ["R-2", "R-7"], "type": "type-railing-supa-s1070"}, {"marks": ["R-3"], "type": "type-railing-supa-s1100", "note": "alternative"} ], "total": {"amount": 486000, "currency": "SEK"}, "validUntil": "…" }
The same mechanism as analysis results. The quote names the version and a digest of the records it priced. Hash those records at the head and compare: if one changed, the quote is out of date, and the host can say which records changed. Computed, never typed in by hand.
Version tie and staleness are those of result manifests (computedFrom, inputs digest; see Apps). The openeik tools already compute stale results and name the changed records (in testing). The quote attachment and its format are planned. Amounts illustrative.
06 A tender in the model · synthetic example
Competing proposals against the same version make a tender inside the model.
| Proposal | Mount | Check, 12 railings | Main deviations from the design | Quote | Outcome |
|---|---|---|---|---|---|
| Supplier A | side, on the slab edge | 921 | posts 200 mm in from the corners; R-2 and R-7 at 1070 instead of 1100; R-3 as two runs | 486 000 SEK | merged |
| Supplier B | top, on the slab | 1011 | posts 150 mm in from the slab edge; R-3 with an added corner post | 452 000 SEK | closed |
The client compares the actual railings in 3D, their checks and their prices side by side. Merging one proposal makes it the model; the others are closed and stay in the record of the tender.
Hidden from each other. During a tender a supplier never sees another supplier's proposal, diff, checks or quote. Only the client, the project's owners, and each supplier's own organisation see a proposal.
Suppliers, amounts and deviations are synthetic.
07 Level of detail · the supplier's choice
A proposal can carry any level of detail. The supplier decides where it sits.
Interface only · the safe minimumEnvelope, fixings, clearances, positions, tolerancesExact enough for perfect geometric checks and layout control. Nothing about how the part is made.
Interface and productPlus the visible productInfill, rails and finish as they will look, for review and rendering.
Product modelPlus the main partsPosts, rails and panels as separate parts, still without fabrication data.
Full manufacturing modelEverything, if it wantsInternal profiles, joints, machining and cutting data. Allowed, never required.
The interface, at the minimum, is precise
- the exact outer envelope of each part;
- fixing and connection points, and post and fixing positions;
- clearances and access zones;
- loads on the structure;
- declared tolerances.
One way to see the minimum: publish the header file, not the source, the interface others build against without the implementation. It is one point on the scale, not the rule. A supplier can share its whole design.
Every record says what it is
a sketch: not in 0.1, proposed for 0.2"detail": { "level": "interface", "authoritativeFor": ["envelope", "fixings", "clearances", "positions", "loads"], "notFor": ["fabrication"], "tolerances": {"envelope": 3, "positions": 2} }
Checks then know what they may rely on: a clash or layout check reads the envelope and positions; nobody mistakes an interface record for shop drawings.
Records at a declared level of detail are planned for OpenEik 0.2; the declaration above is a sketch, not in 0.1. A related industry concept is the level of information need, ISO 7817-1:2024, “Building information modelling — Level of information need — Part 1: Concepts and principles”, adopted in Europe as EN ISO 7817-1:2024, which replaced EN 17412-1:2020. That standard lets a client specify the information needed for a purpose; the declaration here lets a record state what it provides. Tolerance values in mm, illustrative.
08 Level of detail · one railing, two levels · synthetic example
The same railing at two levels. Here the supplier chose interface only.
The left side is enough for the client to check every railing against the slab edges, doors and drainage, and to lay out the fixings. Whether the right side also goes in is the supplier's decision, per proposal.
09 Secrets and IP
What the supplier does not share stays with the supplier.
Sent to the project
Only the building parts at the level of detail it declared, and the quote. Product identity such as system and finish only if it chooses.
Private to the client and that supplier
The quote is an attachment on the proposal, not part of the model's shared history. In a tender, no supplier sees another's proposal, diff, checks or quote.
10 After the merge
After the merge, what is ordered is what is drawn.
The model is true
The railings in the model are the ones that will be made, at the declared level of detail.
The order names the version
The order points at the merged version, so everyone knows exactly which railings it covers.
Design responsibility is recorded
The proposal, its author and the merge are in the history. Signing the supplier's design responsibility for those records is planned with a host: the host's signature first, personal electronic signatures later.
Later changes are diffs
If the design moves on, the change shows as a diff against what was ordered, per railing, not as a surprise on site.
11 Every building part · every supplier
The same pattern for every building part.
| Part | The supplier's check | The interface it shares | In the standard today (0.1) |
|---|---|---|---|
| Railings | system rules, mount, posts | envelope, posts, fixings, loads | a railing category, with a type payload for its kind, height, posts and rails; richer railing types planned for 0.2 |
| Windows and doors | sizes, opening, hardware | frame envelope, fixings, opening clearances | window and door categories with types, hosted in walls |
| Roof trusses | span, bearing, loads | truss envelopes, bearing points, loads on walls | truss layouts, which a command turns into members; the truss rules are reference behaviour |
| Steel frames | members and connections | member envelopes, connection points, bolt access | beams and columns with sections; plates, bolts and welds as components; fabricated pieces and structural joints |
| Precast elements | production and lifting | element envelope, lifting and connection points, joints | a type's layer can be precast (hollow-core or plate units); fabricated precast pieces; the precast rules are reference behaviour |
| Building services | routing, fittings, equipment | equipment envelope, connections, service clearances | pipe, duct and terminal categories; fittings are reference behaviour |
| Lifts | shaft, pit, headroom | car and shaft envelope, loads on the shaft | no lift category; a shaft's type can have the purpose “lift” |
Invite, fork, check, propose with a quote, review, merge: the flow is the same. What differs is how rich each part's type data is in the standard, which decides how much of a supplier's product can be expressed as typed records.
12 The first pilot · a railing manufacturer · synthetic, anonymous
The first pilot: a railing manufacturer. Today's railing category works; it needs a 0.2 addition.
Works today. A supplier-style railing type and a railing on three edges of a balcony slab passed a dry run and a real run with today's reference implementation. The model validated and the checker found no errors. No new record kind was needed.
Follows the building. Moving the balcony's front edge made the reference implementation rewrite the railing, and the
openeik tools reported the supplier's result set as stale, naming both changed records.Tools disagree on posts. Same post count, different positions: the reference implementation puts posts at the corners, the supplier's engine 200 mm in from them. Explicit positions in the record settle it.
The supplier's data went into the type's product identity and a material. Its own rules stay in its own tool; only their result, such as post positions, goes into the record.
Planned for 0.2, all optional
railing type"railing": { "kind": "balusters", "height": 1150, "…": "…", "mount": "side", "postWidth": 30, "postDepth": 50, "postEndDistance": 200 }
railing element"railing": { "edges": ["slab-b2:edge:3", "slab-b2:edge:0", "slab-b2:edge:1"], "inset": -25, "posts": {"at": [200, 1308, 1525, 2633, 3525, 4642]} }
- Mount: side (on the slab edge) or top.
- Rectangular posts: width and depth, not one square size.
- Explicit post positions, in mm along the line, so tools agree.
From a test on 11 October 2026 with one railing manufacturer's configurator, the reference implementation's engine and the openeik tools, on a copy of an example house with a balcony added. Values in the snippets are illustrative. The railing additions are on the roadmap as Next (0.2).
13 Today and next · 11 October 2026
What is live today, and what comes next.
Live
- OpenEik folders and the reference implementation's
ekengine. - Kept app folders: files an app writes in its own folder are kept through save, restore and merge.
- Versions, with a hosting service if a project's owner chooses.
- The
openeikreader and checker tools: in testing, public with the specification in Q4 2026. They already compute stale results and name the changed records.
Planned for OpenEik 0.2
- Records at a declared level of detail, saying what they are authoritative for.
- The railing additions: mount, rectangular posts, post positions.
Planned with a hosting service
- Forks across organisations.
- Proposals, the pull requests of this page.
- Checks before merge.
- Quote attachments on proposals.
- Optional narrowed read access, set by the client. By default a supplier reads the whole model.
- Competing proposals hidden from each other during a tender.
Host features, not part of the standard: any host can offer them.
So the flow above is a target. The pieces it rests on, versions, typed commands, records that follow the building and results that know when they are stale, exist today.
14 Who does what
The standard defines the records. A host runs the workflow.
OpenEik · the open, non-profit standard
- The records: one building part per file, with types and their payloads.
- The level-of-detail declaration: what a record provides and what it is authoritative for (planned for 0.2).
- Typed commands: how a proposal changes the model.
- Versions: how a quote or a result names what it was made from.
- Vendor-neutral: any host, or a plain folder and git, can implement the flow.
A host · any hosting service
- Proposals between organisations, with review and merge.
- Attachments such as quotes, visible to the right parties.
- Supplier access: the whole model by default, optionally narrowed by the client; competing proposals hidden from each other.
- Checks before merge.
- A marketplace where suppliers propose against projects.
The two roles are separate on purpose. A supplier's railings are OpenEik records wherever they are hosted; a host is one place to run the proposal flow, not the only one.
In one line
Invite. Read a version. Work in a fork. Check. Propose the real product, with a quote. Review it in the model. Merge.
The supplier decides how much detail it shares. The client sees exactly what it is buying, against exactly the version it was priced for.
A supplier is one more app on the model: the same pattern as structural analysis, a schedule or a daylight study.