Conformance in OpenEik 0.2. What to meet, and how to claim it.
The classes an implementation can claim and what each must do, how a claim is made and checked, the tests today, and where the implementations stand.
Tagged privately OpenEik 0.4.0 is tagged v0.4.0 and not yet published. It keeps every class and requirement of 0.3 and adds the rules of seven sections. OpenEik 0.3 is kept at the tag v0.3.0, 0.2 at v0.2.3 and 0.1 at v0.1.0; a claim to 0.3 is a claim to its twelve classes as that tag has them (Conformance in 0.3), a claim to 0.2 to its twelve as the tag v0.2.3 has them (Conformance in 0.2), and a claim to 0.1 to its eight, without the requirements of Parts XIII to XVIII, which were proposals in 0.1 (Conformance in 0.1).
Twelve classes. An implementation claims one or several.
Each class lists the sections of the specification an implementation must meet to claim it; Parts XIII to XVIII add to most of them, each in its own section on conformance. In short:
Reader
Reads models.
Reads a model's folder, checking the format in
eik.jsonfirst and needing no built-in library, and reads its single-file form too. Refuses what it cannot read, the list of Part III, 12. The whole-model check is a SHOULD: a reader that performs it refuses a folder that fails it, and one that does not reads the folder as it is. Keeps unknown members, elements and types of unknown categories, profile members, application records and values, kept files and declared geometry, all unchanged. Leaves alone a kept file whose name a file system refuses or reads otherwise, or whose path folds to another of the model's or passes througheik.jsonorAGENTS.md, and reads on; refuses a version that no folder gives, one that holds such a file among them. It SHOULD also read a model of 0.1, by 0.1's rules, and otherwise refuses it, naming its version. Of Parts XIII to XVIII it reads circuits, sheets and people as records, the electrical categories and the drawing files as those parts define them, the files ofassets/,project/owners.json, and the files of reviews and issues.Conformance, 1 · Part III, 12 · Part III, 7 · Part I, 10 · Part I, 9.6 · Conformance, 1.1
Validator
Says whether a model is valid, and why not.
Everything a reader must do, and the whole-model check: validates every file against its schema and checks the rules of Parts I and II, among them two records' paths that fold to one and an id's length; checks the stored form and the paths, and reports a file not in the stored form and a record at a path that disagrees with it as errors; reports each kept file a reader leaves alone, as a warning in a folder and as an error in the single-file form; and names the file and the rule of every failure. It never refuses an unknown member, an extension member or a record of an unknown category. Of Parts XIII to XVIII it checks the rules each lists for it: an electrical installation's, those of the drawings that the folder decides, those of
assets/and ofproject/owners.json, and those of reviews, issues, receipts and terms accepted.Conformance, 1 · Part III, 12 · Part I, 6 · Part III, 3 · Part III, 4.2 and 5 · Conformance, 1.1
Writer
Writes models.
Writes each record at its path in the stored form, with
eik.jsonand every type that a record names, and leaves kept files alone. It keeps the members ofeik.jsonit does not know, and refuses a model with two records whose paths fold to one, an id whose path segment is longer than 200 bytes, or a kept file whose name a file system refuses or reads otherwise, or whose path folds to another of the model's or passes througheik.jsonorAGENTS.md. It never writes derived data into a record, nor costs, prices or quotes. Of Parts XIII to XVIII it writes circuits, sheets and people at their paths and a view's lighting scene, keeps issued files, and writes no asset of a kind 0.2 does not define.Conformance, 1 · Part III, 13 · Part I, 6 · Part III, 7 · Part III, 8.1 · Conformance, 1.1
Compiler (core)
Derives bodies from records.
Derives bodies by the class-A rules of Part IV: layered extrusions, outline edges trimmed to a wall's face, roof planes, attached tops, member sweeps, rectangular openings, the line and given posts of a railing on an outline, and a generic element's declared bodies. It stores nothing derived in a record, and where a supplier declares geometry, it uses it and derives nothing beyond what the declaration is authoritative for. Of Part XIII it derives the bodies of an electrical installation.
Conformance, 1 · Part IV, 2 · Part XIII, 7 · Conformance, 1.1
Command processor
Changes models by commands.
Changes a model by typed commands, the core record operations at least: each is checked before anything changes and applied all or nothing, and the whole model is checked after every command. It never creates an element or a type of a category it does not know. Of Parts XIII to XVIII it takes the electrical and the drawing commands, says which owners a change's paths need, and takes Part XVII's envelopes and bare batches: an operation applied once, its target and its mode, a precondition on every command, refusals with codes, and the answer.
Conformance, 1 · Part V, 2.1 · Part XVII, 13 · Conformance, 1.1
Version store
Keeps versions.
Keeps a model's versions as git keeps code: content-addressed objects, trees, versions, and refs moved by compare-and-swap, with diff and three-way merge by record and field. When it fetches from, pushes to, pulls from or clones a remote, it meets Part VI, 6 as well. It keeps issued files and assets in its versions, and meets Part XV, 5 and 6 for assets in a store, a push, a fetch, a pull and a clone.
Agent host
Serves models to agents.
Offers an agent the operations of Part VII, under any names and through any protocol: a summary, the tree, tiered reads, commands, validation and the guide, all working headless. It is also a reader, and if it writes, a writer and a command processor. It authenticates and attributes the envelopes it takes.
Conformance, 1 · Part VII, 1 · Part XVII, 4.2 · Conformance, 1.1
Bridge
Exports to another format.
Meets Part VIII, 1 for each format it claims. For IFC: every element of the core categories that has a body, with its type, its level and its openings, generic elements included, and a fidelity report with every export that says what it leaves out or approximates. A print names the version it was printed from.
Conformance, 1 · Part VIII, 1 · Part XVIII, 7.2 · Conformance, 1.1
Drawing validator
Checks issued drawings.
Everything a validator must do, and more of an issued drawing: works out whether it is current from what it was drawn from, verifies its sign-offs, and checks the rules that need the history where it has it. It verifies signed issues, a host's receipts and terms accepted, given the hosts' keys and the time-stamp authorities' certificates.
Drawing issuer
Issues drawings.
Issues drawings in the SVG profile, with their files, records and register, a complete read set and output that is the same for the same input. It issues no drawing while a view on the sheet holds an item an agent proposed, and never an SVG written by hand.
Host
Keeps a project's versions for several parties, and serves its reviews and issues.
Everything a version store must do, and holds a change for its owners' approvals. It keeps the events of an issue and offers receipts, publishes the keys it signs them with, and keeps the security and privacy rules of review and issue.
Authoring tool
Makes the model people issue.
Everything a writer must do, and saves what a host offers it, and records a named version of what it issues.
A requirement on “an implementation” applies to every class that performs the act it names (Part I, 2). Clash and layout checks are not a conformance class (Conformance, 1).
Meet every requirement of a class, then name the version and the classes.
An implementation conforms to OpenEik 0.4 in one or more classes. It claims a class by meeting every requirement this page lists for it; it MAY claim several. A claim names the version (
OpenEik 0.4.0) and the classes, for example "OpenEik 0.4.0 reader and validator". A claim to 0.3 (OpenEik 0.3) is a claim to the classes of 0.3 as the tagv0.3.0has them, the same twelve without the rules 0.4 adds; a claim to 0.2 (OpenEik 0.2), to those of 0.2 as the tagv0.2.3has them, without the rules 0.3 adds; a claim to 0.1 (OpenEik 0.1) is a claim to the classes of 0.1 as the tagv0.1.0has them: eight, without the requirements of Parts XIII to XVIII, which were proposals in 0.1.
How a claim is checked
- Schemas.
schemas/0.4/holds a JSON Schema (2020-12) for every kind of file of 0.4, andschemas/0.4/index.jsonmaps paths to them;schemas/0.3/holds those of 0.3,schemas/0.2/those of 0.2 andschemas/those of 0.1 beside them, for reading a model of 0.3, 0.2 or 0.1. - The check tool.
tools/check.mjschecks a folder or a single-file model against the schemas, the stored form, the paths, unique ids, references and the format version, and the rules that need geometry or the types' sizes. It is a partial validator: it does not check the framing families' expression language and parameters, or that a sheet section follows its profiled sheet. - The examples.
examples/holds two folders written by the reference implementation and migrated to 0.2. A reader MUST read both without error. A writer that reads one and writes it back without changes MUST write every record file it keeps byte for byte as it was. - Compiler vectors. Conformance vectors for the compiler (Part IV, 10) are not published yet. The pipe and duct fixtures of Part IV, 12.5 are a first set.
- Model quality.
openeik check --qualitywarns about elements modelled under a category that does not fit them. These warnings are heuristics: no claim depends on them.
Not defined in 0.4
- Who checks a claim.
- Where a claim is published, or a register of claims.
- A certificate, logo or mark that goes with a claim.
- What evidence a claim carries, or the form of a test report.
- Whether a SHOULD that is not met stands in the way of a claim.
The library's own tests, and a conformance suite for every implementation.
The tests of @openeik/tools
3098tests in 75 files
- Passed
- 3093
- Failed
- 0
- Skipped
- 5
Run on 1 November 2026 at the specification repository's commit 9077aa6c, with Node.js 22.23.3.
They cover the reader, the validator and its rules, the writer, the command processor, the compiler, canonical JSON and hashes, JSON that is not I-JSON, version trees, diff, merge, stores and remotes, result manifests, model quality, changes by discipline folder and the datums every discipline shares, the building physics of materials, layers, types and the project's envelope, which way walls, doors, windows and roof windows face, heating, ventilation and plumbing (systems, insulation by code and thickness, heat on terminals, components in a pipe or a duct and their bodies, every terminal's box, a view's filter by system, tags and symbols), the outline of a slab whose edges are trimmed to a wall's face as a reader takes it without compiling, the bodies of slab edge elements and gutters and the openings shafts cut, how doors and windows open, with the validator's findings on its trims, clashes between building services and the building, commands in an envelope, with an operation applied once, coded refusals and a precondition on every command, the IFC bridge (ifcOfModel: a print of a version, the same bytes each time, plates and bolt groups as plates and fasteners, and what buildingSMART's normative rules check of types, operations, solids and placements, every closed face set holding a volume, an application's bodies where the compiler derives none, imported property sets typed by IFC4's templates where the record says its numbers' units), sections with rounded corners and of any outline, an experimental IFCX print of the same objects (ifcxOfModel, buildingSMART's alpha), a review of the model at a version, its anchors checked against that version, issues signed and received, receipts and terms accepted, the versions of a model, 0.1 and 0.2, read and written, a model of 0.1 migrated to 0.2, the schemas of 0.2, the openeik command, every case of the conformance suite of 0.2, with the whole-model check and without it, and what 0.2 made rules of 0.1's proposals: electrical installations, drawings with their SVG profile, freshness, the verification of sign-offs and a review exported as BCF, ownership by folder and folders that follow owners, assets kept by the SHA-256 of their bytes, carried in versions, pushes, clones and pulls, a door's and a window's own body, a stair's numbers and the layout of straight, L and U stairs, a layer's grain and an element's main direction, a framing family's parts, a wall's, a roof's and a floor's timber framing laid out, reading IFC into OpenEik, a site's true north and map coordinates, classification references, a hosted railing's profile, declared geometry in its frame, retired component families, a room's boundary, ceiling and quantities, members between two points, sloped slabs and provisions for voids.
Three skipped tests need a checkout of a store's server, one a building with every pipe, duct and fixture type, which the repository does not hold, and one a Python with IfcOpenShell to validate an IFC print.
at the root of the specification repository (public at launch)npm ci && npm test
They test this library, not other implementations.
The conformance suite
In the draft
1080 cases, one suite for 0.4, in conformance/ of the specification repository (public at launch), and here as one zip, openeik-conformance-0.4.zip: 52 of Part I, 387 of Part II, 100 of Part III, 88 of Part IV, 3 of Part V, 3 of Part VI, 21 of the security and privacy considerations, 106 of Part XIII, 79 of Part XIV, 8 of Part XV, 20 of Part XVI, 143 of Part XVII and 70 of Part XVIII, each checked with no proposal. 877 of them are for the validator class, 319 for the reader, 187 for the command processor and 16 for the drawing validator. Most are a small model, a folder or a single file, that differs from one valid model by one change, with an expected.json that quotes the rule it tests and says what a validator reports and what a reader does: reads the model, refuses it, or either, where the specification allows both, as for a model that fails only the whole-model check (Part III, 12). A command processor's case gives the messages sent to it and the answers it gives; the forms freshness, verify and anchors work out whether issued drawings are current, verify signed statements and check a review's anchors. Beside them, conformance/migration/ holds a folder of 0.1 and the folder of 0.2 the migration makes of it (Part I, 9.8), migration-0.3/ a folder of 0.2 and the folder of 0.3 (9.9), and migration-0.4/ a folder of 0.3 and the folder of 0.4 (9.10). The suite is data, and its README says what a runner of your own does with each case. In the repository, node tools/run-conformance.mjs runs them against @openeik/tools, or against another implementation through an adapter; @openeik/tools passes all 1080, and passes them too as a reader that skips the whole-model check (--unchecked). Test vectors for compilers are not published yet (Conformance, 2).
OpenEik 0.1. As the tag v0.1.0 has it: the library's tests at 45cb7d88, 2242 in 68 files, 2237 passed, 0 failed and 5 skipped, run on 30 October 2026 with Node.js 22.23.3; and the conformance suite of 0.1, 335 cases for the reader and validator classes, with 678 more for its proposals for 0.2, in openeik-conformance-0.1.zip, all of which @openeik/tools 0.1.0-draft passes. Its eight classes: Conformance in 0.1.
Where the implementations stand, on 30 October 2026.
The reference implementation, and the library in the specification repository. Each row names its sources.
| Implementation | Classes | Not met yet, or limits |
|---|---|---|
Stomra The reference implementation: Stomra's engine and its Sources: Conformance, 3 · Open questions, 2 |
It reads and writes OpenEik 0.1, and refuses a folder of 0.2, so it claims no class of 0.2 yet. With a model of 0.1 it meets most of the requirements of the eight classes of 0.1.
Of 0.2's records, it reads and writes the devices, boards and circuits of Part XIII (its works 532 and 534), and issues drawings in Part XIV's files since its work 566, from sheets that are still application records of 0.1. |
Not met yet
Each with what the reference does today, and what it has met since: Open questions, 2. |
A library for apps and the Sources: |
Its README claims the writer and compiler (core) classes of 0.1.0-draft, and states no claim to a class of 0.2 yet. It implements the reader, validator and command processor without claiming them.
An implementation claims a class only when it meets every requirement the class lists; its README says which it claims, which it implements without claiming, and why. It diffs, merges three ways, and clones, pushes and pulls with a store; its version trees of four test folders, the L-house among them, have the same roots as the reference implementation's (Open questions, 2). Its tests are counted under Tests. |
Limits its README states
|
Add an implementation, with the classes it claims.
At launch, open an issue or a merge request at the specification repository. Name the version and the classes your implementation claims, as every claim does.
The specification repository is public at launch.
This page is rendered from conformance.json, its single source. It sums up the specification: where the two differ, the specification applies.