OpenEik 0.2 specification

Part XIII. Electrical installations

This part is a part of OpenEik 0.2, by the steward's decision of 15 October 2026 that electrical installations join OpenEik in 0.2. It binds every conformance class it names (section 11; Conformance). OpenEik 0.1 had it as a proposal, which no class of 0.1 required: a reader of 0.1 keeps the elements and types of its categories as a later version's (Part I, 10, rule 5), the circuits' files as kept files (Part III, 7), and a 3D view's display.lighting as a member it does not know (Part I, 10); a legend's scheme electrical or circuits (4.4) is a value 0.1's enumeration does not hold, which a validator of 0.1 refuses. A reader of 0.2 reads a model of 0.1 by 0.1's rules (Part I, 9.6, rule 3). @openeik/tools applies this part to every model of 0.2, and to a model of 0.1 when asked: checkFolder(…, { proposals: ["electrical"] }), or openeik check --proposal electrical.

1. Status and scope

This part states a building's electrical installation as design intent:

• devices and boards (section 2): outlets, switches, dimmers, buttons, sensors, lights, emergency lights, junction boxes, boards, meter cabinets, chargers, data and TV outlets, speakers, access points and hard-wired equipment, each an element of the category electrical;
• circuits (section 3): the circuits that leave a board, and the supply, each a record of its own;
• feed chains (section 4.1): the device on its circuit that each device is fed from;
• control (section 4.2): which switch, dimmer, button or sensor works which loads;
• lighting scenes (section 4.3): which luminaires are on in a 3D view, and how far each is dimmed;
• legends (section 4.4): a drawing's key to its devices, and its circuit schedule;
• cable carriers (section 5): conduits, trays, ladders and trunking, as runs;
• modelled cables (section 6): the route of a leg that a designer chooses to model, such as a main cable.

What feeds what is intent, and is stored. The wiring's geometry is derived and never stored (section 8): the arcs of a plan, the home runs, the routes and lengths of the legs, the loads and the phase balance. Only the route of a leg that someone models is a record.

The records.

The three categories are in the folders of their owner, electrical (Part III, 4.4, rule 2), a materialised framing member's in structure; in 0.1's layout they are in systems, as pipes and ducts are (Part III, 4.1). <level> and <id> are path segments (Part III, 2 and 4.2).

What it leaves out.

• National rules: how many outlets a room needs, the zones of a wet room, where a residual-current device is required, which cable a fuse allows. They are rules of a country, which applications check as hints. This part carries the data they need: the protection and the cable of each circuit, each device's power, and what feeds what.
• Symbols: their shapes are drawing production, the application's, as every symbol is in 0.1. A plan draws a device's symbol where the device is, turned by its facing, at paper size.
• Bus addresses: a KNX group address or a DALI group is the application's data, in extension members (Part I, 11), until a later version needs them.
• Every cable as a run: a leg's route stays derived unless a designer models it (section 6).

Status. The rules of this part bind every implementation of 0.2 of a class they name (section 11). They are numbered, and cited as XIII.<section>.<rule>: XIII.2.3.4 is section 2.3, rule 4. A validator reports a breach of a MUST as an error and a breach of a SHOULD as a warning (section 11). The part's schemas are among those of 0.2 (schemas/0.2/: elements/ and types/ for its categories, project/circuit.schema.json, drawings/view-lighting.schema.json), and its conformance cases in the suite of 0.2.

In 0.2 its text stays in this part. These are the sections of Parts II to VIII that it extends, where a later version may move it:

• Part II: the categories (6.2) and the members that belong to them (6.3); the payloads electrical and cableCarrier (5); electrical types among the types that set their elements' sizes (5.3); the references (7); a profile electrical (8), with the members electrical and cable, the payloads electrical and cableCarrier, and the circuits; the circuit record (1); a 3D view's display.lighting, and a legend's schemes electrical and circuits (13); the fire kind emergencyLight, deprecated (2.2);
• Part III: the paths (3 and 4.1), and the circuits of the single-file form (11);
• Part VI: a circuit's leaf in a version's tree (2, rule 1; 3.1);
• Part IV: the bodies (section 7);
• Part V: the circuit commands, view.lighting, and what a delete takes with it (section 9);
• Part VIII: the IFC mapping (section 10).

Reference: devices, boards and their types are Stomra's src/core/elements/electrical.ts (work 532, on Stomra's main since 15 October 2026); circuits, feed chains and their checks are work 534, cable carriers, modelled cables and the switch patterns work 535, the load and voltage-drop hints work 536, and the E63 and E64 plans work 537, all on Stomra's main since 16 October 2026 (merge requests !80, !83, !86 and !87). A linear device's length (2.3, rule 3) is work 554, on Stomra's main since 16 October 2026; the legend of the devices (4.4) is work 533, since 15 October 2026, and the circuit schedule work 534. A luminaire's light output (2.2), the lighting scenes (4.3) and view.lighting (section 9) are work 700, in progress on 26 October 2026. The names of this part were agreed with that work as it was built.

2. Devices and boards

A device or a board is an element of category electrical, in electrical. It is a place in plan with a facing, a height above its level that its type's mount gives a meaning to, and its type's size. In this part a device is any element of category electrical, boards and meter cabinets among them, unless the text sets them apart.

2.1 The element

and the members every element has (Part II, 6). A drawing's height of a wall device, to its centre above the finished floor, is its offset on a level at the finished floor.

The members of electrical, each optional:

A device's power is its own power, else its type's.

The examples of this part are a synthetic installation on the ground floor, level-0, of the house in examples/one-storey-house, whose outer walls are 300 mm thick on the lines x = 0, x = 10 000, y = 0 and y = 7000. Each record is in the stored form (Part III, 5).

The main board N1A1, on the inside face of the east wall (x = 9850), facing west into the room. Its type is 120 mm deep, so its at lies 60 mm out from the wall face. G1 of the meter cabinet A1 feeds it (3.2):

{
  "category": "electrical",
  "electrical": {
    "circuitId": "circuit-a1-g1",
    "designation": "N1A1"
  },
  "height": 700,
  "id": "board-n1a1",
  "levelId": "level-0",
  "name": "Main board N1A1",
  "offset": 1500,
  "profile": [
    [9790, 4000],
    [8790, 4000]
  ],
  "revision": 0,
  "typeId": "type-el-board",
  "width": 600
}

A double outlet for the dishwasher, on the inside face of the north wall (y = 6850), its centre 500 mm above the floor; its type (2.2) is 40 mm deep. It is on circuit G6 (3.1), fed from the outlet before it on that circuit (4.1). Its type gives no purpose, and the element gives its own:

{
  "category": "electrical",
  "electrical": {
    "circuitId": "circuit-n1a1-g6",
    "from": "outlet-kitchen-1",
    "purpose": "DM"
  },
  "height": 80,
  "id": "outlet-kitchen-dm",
  "levelId": "level-0",
  "name": "Double outlet",
  "offset": 500,
  "profile": [
    [8000, 6830],
    [8000, 5830]
  ],
  "revision": 0,
  "typeId": "type-el-outlet-2",
  "width": 150
}

A two-way switch by the entrance door, on the inside face of the south wall (y = 150), on the lighting circuit G2, which works the kitchen's ceiling light. A second two-way switch at the other end of the room names the same light (4.2):

{
  "category": "electrical",
  "electrical": {
    "circuitId": "circuit-n1a1-g2",
    "controls": ["light-kitchen"]
  },
  "height": 80,
  "id": "switch-entrance",
  "levelId": "level-0",
  "name": "Two-way switch",
  "offset": 1000,
  "profile": [
    [7700, 160],
    [7700, 1160]
  ],
  "revision": 0,
  "typeId": "type-el-switch-two-way",
  "width": 80
}

Its type's electrical gives the kind switch, the mount wall, the depth 20, control wired and switching twoWay.

2.2 The type

An electrical type's width and height (Part II, 5) are its body's size across the facing direction and vertically, and its elements take them, but for a linear device's width, its length, which is its own (2.3, rule 3). The type's payload electrical:

The first four are required, and the others optional. luminousFlux, colorTemperature, beamAngle and distribution are a luminaire's light output: they belong to the kinds light, spot, emergencyLight and track (rule 6), and say how much light it gives and how, so that an application can show a room lit.

A switch's switching is the pattern of its contacts, as IEC 60669-1 numbers them:

A push-button is no pattern of its own: it has the pattern of its contacts, and momentary true. A bus or radio button is the kind button, with switching oneWay and momentary true. Several switches on one base, each with its own actuator, are one device with gangs: a double two-way unit is twoWay with gangs 2.

A national value is a plain string whose values come from a national code list in practice, and a plain value one whose values are products or systems: OpenEik lists neither (Part II, 8, rule 3). The schemas accept any string of the right length in both, and mark defaultPurpose, as an element's purpose, "x-eik-values": "national". No member names a product system: a system is a value of controlSystem, never a member or an enumeration.

The kinds:

A three-phase outlet, or an industrial one, is an outlet with its connector, phases and ratedCurrent: its symbol follows from them, and an application may keep separate catalogue entries for such outlets.

The double outlet's type (2.1):

{
  "category": "electrical",
  "color": "#f1f0ec",
  "electrical": {
    "connector": "type F",
    "defaultOffset": 250,
    "depth": 40,
    "kind": "outlet",
    "mount": "wall",
    "phases": 1,
    "ratedCurrent": 10,
    "sockets": 2
  },
  "height": 80,
  "id": "type-el-outlet-2",
  "material": "Plastic, white",
  "name": "Double outlet",
  "revision": 0,
  "width": 150
}

A new element of this type gets the offset 250; the dishwasher's outlet of 2.1 gives 500, its own.

2.3 Rules

1. An electrical element's profile MUST be exactly two points, at and toward, at least 1 mm apart in plan.
2. A type of category electrical MUST carry the payload electrical, with kind, mount, depth and defaultOffset. Its schema states this rule.
3. An electrical element's width and height MUST equal its type's, but for a linear device's width. A linear device is a device whose type's mount is ceiling or floor, and whose type's kind is track, or is light with a width at least three times its depth: a lighting track, or a linear luminaire. A linear device's width is its own, its length, laid across the way it faces (2.2): it MUST be from 1 to 50 000 mm. A linear device's height MUST equal its type's. A writer gives a linear device its length; where it has none to give, it gives its type's width. An electrical type sets its elements' other sizes as the types Part II, 5.3 lists set theirs, and that section's rules 1 and 2 hold for them: a writer writes its type's sizes, a command that sets others is refused, and a file that gives others fails the whole-model check.
4. electrical.controls MUST NOT be on an element whose type's kind is not switch, dimmer, button or sensor. Each id in it MUST name an element of category electrical of the model, other than the element itself.
5. electrical.designation MUST match ^[A-Za-z0-9.:+=-]+$ and be at most 24 characters long. electrical.purpose MUST be 1 to 8 characters long. A purpose is a national value: a validator MUST NOT refuse one because a code list does not hold it (Part II, 8, rule 4). The schemas state this rule.
6. luminousFlux, colorTemperature, beamAngle and distribution MUST NOT be on a type whose kind is not light, spot, emergencyLight or track. The schemas state their ranges.
7. The fire kind emergencyLight is deprecated (Part I, 9.6). A reader reads a fire type whose fire.kind is emergencyLight, and its elements, as 0.1 does. A writer SHOULD NOT write one, and writes an emergency luminaire as an electrical element whose type's kind is emergencyLight instead, on its circuit. A validator SHOULD warn about each such fire type (fire-emergency-light). An escape sign stays a fire element.

Reference: electricalTypeSchema (rule 2, and the values of 2.2; a luminaire's light output and rule 6 from Stomra work 700, live since 26 October 2026, main 044e36b0), electricalElementSchema (rule 5, and the values of 2.1), validateElectrical and controllingKinds (rule 4), placedElectrical and electricalAt (rules 1 and 3, when a device is placed), and isLinearDevice and deviceWidth (rule 3's linear device and its length, from Stomra work 554), in src/core/elements/electrical.ts.

3. Circuits

A circuit is a record of its own: a group of devices on a board, with its protection and its cable. The circuit that feeds the first board from outside the model is the supply. One record per circuit: a change to one circuit's fuse touches one file, and a device that joins a circuit touches only the device's file.

3.1 The record

project/circuits/<id>.json holds one circuit:

protection is {device, characteristic?, rating, rcd?}:

cable is {type, conductors, area, earth, protectiveArea?}:

So the cable "EQLQ 3G1.5" is {"area": 1.5, "conductors": 3, "earth": true, "type": "EQLQ"}, and "FXQJ 4x25/16" is {"area": 25, "conductors": 4, "earth": true, "protectiveArea": 16, "type": "FXQJ"}. A tag such as "3G1.5" is the application's to write and to read; the record holds its parts. The schemas mark cable.type and protection.characteristic "x-eik-values": "national" (Part II, 8, rule 3): a reader keeps their values as they are, and a validator refuses none because a code list does not hold it.

Circuit G6 of the board N1A1: the kitchen's outlets, in EQLQ 3G1.5 on L1, behind a C10 breaker and the 30 mA residual-current device Q1 of type A, which G6 shares with the other circuits of N1A1 that name Q1:

{
  "boardId": "board-n1a1",
  "cable": {
    "area": 1.5,
    "conductors": 3,
    "earth": true,
    "type": "EQLQ"
  },
  "designation": "G6",
  "id": "circuit-n1a1-g6",
  "name": "Kitchen outlets",
  "phases": ["L1"],
  "protection": {
    "characteristic": "C",
    "device": "breaker",
    "rating": 10,
    "rcd": {
      "designation": "Q1",
      "sensitivity": 30,
      "type": "A"
    }
  },
  "revision": 0,
  "voltage": 230
}

In the single-file form (Part III, 11), the circuits are the list circuits. In a folder, project/order.json lists their ids as it lists any record list (Part III, 9, rule 1). That order has no meaning, and implementations MUST NOT give it one: a board schedule sorts a board's circuits by designation, in natural order (3.2). In a version's tree a circuit is a record, as Part VI, 2, rule 1 names one: its leaf is project/circuits/<id>, without .json, its object the circuit's canonical JSON, and a commit counts it among its records, so that every implementation of this part gives a model with circuits one root.

3.2 The supply and feeds

• The supply. A circuit whose boardId is null is a supply: the circuit from outside the model that feeds the first board or meter cabinet. Its protection is the main fuse, and its cable the service cable.
• A board's feed. A board's or a meter cabinet's own electrical.circuitId names the circuit that feeds it: the supply, or a circuit of the board upstream. So in the examples the supply feeds the meter cabinet A1, A1's circuit G1 feeds the main board N1A1 through its cable, and N1A1's circuits feed the devices.
• A shared residual-current device. Circuits of one board whose protection.rcd.designation is the same share one residual-current device: Q1 in front of G1 to G6, say.
• A leg's cable. The leg of a device on a circuit is the cable that feeds it: from the device its from names, or else from its circuit's board (on a supply, from outside the model), to the device. The leg's cable is the device's electrical.cable where it has one, and its circuit's cable otherwise.

A board schedule lists each board's circuits by designation, in natural order, G2 before G10, whatever the order of their list.

The supply, which feeds the meter cabinet A1 (whose electrical.circuitId is circuit-supply), behind a main fuse of 25 A:

{
  "boardId": null,
  "cable": {
    "area": 16,
    "conductors": 4,
    "earth": false,
    "type": "EKKJ"
  },
  "designation": "Service",
  "id": "circuit-supply",
  "name": "Supply",
  "phases": ["L1", "L2", "L3"],
  "protection": {
    "characteristic": "gG",
    "device": "fuse",
    "rating": 25
  },
  "revision": 0,
  "voltage": 400
}

Circuit G1 of the meter cabinet A1, which feeds the main board N1A1 (2.1) through FXQJ 4x25/16. It has no name yet:

{
  "boardId": "meter-a1",
  "cable": {
    "area": 25,
    "conductors": 4,
    "earth": true,
    "protectiveArea": 16,
    "type": "FXQJ"
  },
  "designation": "G1",
  "id": "circuit-a1-g1",
  "phases": ["L1", "L2", "L3"],
  "protection": {
    "characteristic": "gG",
    "device": "fuse",
    "rating": 25
  },
  "revision": 0,
  "voltage": 400
}

3.3 Rules

1. An element's electrical.circuitId MUST name a circuit of the model.
2. A circuit's boardId MUST be null, or name an element of category electrical whose type's kind is board or meterCabinet.
3. Two circuits of one board SHOULD NOT have the same designation: it confuses a schedule, and breaks nothing. The supplies, whose boardId is null, count here as the circuits of one board.
4. Following a board to the circuit its electrical.circuitId names, that circuit to the board its boardId names, and so on, MUST NOT come back to the board it started from: no board is fed, board by board, from itself. The way up ends at a supply, or at a board without a circuitId.
5. A writer MUST NOT leave a circuitId (a device's or a cable's), a boardId, a from or a cable.to that names no record of the model. A command processor cascades or refuses, as it chooses; the reference implementation cascades (section 9).

Reference: Stomra work 534: circuitSchema (the record), wiringIssues (rules 1 to 4, and 4.1, rules 1 and 2), applyCircuitCommand and afterElectricalDelete (rule 5).

4. Feed chains and control

4.1 from

electrical.from names the device that a device is fed from: the one before it on its circuit's chain. A device that feeds two or more, a junction box or an outlet, is where the chain branches. A device fed straight from its board has no from (rule 3): the board is on another circuit, the one that feeds it, so from cannot name it (rule 1).

1. A device that has electrical.from MUST have an electrical.circuitId, and its from MUST name an element of category electrical whose electrical.circuitId is the same.
2. Following from from a device MUST NOT come back to that device. So the devices of a circuit and their from links make trees, and the root of each is fed from the circuit's board.
3. A device on a circuit that has no from is fed from its circuit's board, or from outside the model on a supply, unless an application derives its place in the chain (section 8).

Reference: Stomra work 534: wiringIssues.

4.2 controls

electrical.controls, on a switch, a dimmer, a button or a sensor (2.3, rule 4), names the elements it works: lights, a switched outlet, equipment.

• It is apart from what feeds them. A light's circuitId and from say how it is fed; a switch's controls says that the switch works it.
• Several controls may work one load: each of two two-way switches, and an intermediate switch between them, names the light.
• A bus or radio control, whose type's control is bus or radio, is recorded the same way. Its binding beyond that, a KNX group address or a DALI group, is the application's data, in extension members (Part I, 11), until a later version needs it.

4.3 A view's lighting

Which luminaires are on is the state of a view, not of a luminaire. A view of kind 3d (drawings/<discipline>/views/3d/<id>/view.json) may give a lighting scene, the member display.lighting, beside its display.sun. In this section a luminaire is an element of category electrical whose type's kind is light, spot, emergencyLight or track (2.3, rule 6).

display.lighting is {on, dim?}:

What it means:

• Off without it. A 3D view without display.lighting has every luminaire off, and a luminaire that on does not name is off.
• All. "all" is every luminaire of the model, those added after the scene was made among them.
• Full. A luminaire that is on and is not a key of dim is at full. 100 is never stored: a luminaire at full has no entry in dim, and one that is off has none either.
• The view's, not the luminaire's. Elements are never touched: switching a luminaire on or off changes the view, and its revision, and leaves the element as it was. So several 3D views of one model give several scenes, "Evening, kitchen on" beside "Night, all off".
• When. The date and time a scene is seen at are its view's display.sun, where it has one.
• Readers and writers. A reader that does not show light MAY ignore display.lighting. A writer keeps it with its view, as it keeps every member of a record (Part I, 10).

The scene "Evening, kitchen on" of the house of section 2: the kitchen's ceiling light on at full and its two spots at 40 %, seen at 21:00 on 21 December; every other luminaire is off:

{
  "crop": [-2000, 12000, -2000, 9000],
  "cutHeight": 1200,
  "direction": [0, 1],
  "display": {
    "lighting": {
      "dim": {
        "spot-kitchen-1": 40,
        "spot-kitchen-2": 40
      },
      "on": ["light-kitchen", "spot-kitchen-1", "spot-kitchen-2"]
    },
    "shadows": true,
    "style": "shaded",
    "sun": {
      "date": "2026-12-21",
      "time": "21:00"
    },
    "sunPath": false
  },
  "far": 30000,
  "id": "view-3d-evening",
  "kind": "3d",
  "levelId": "level-0",
  "name": "Evening, kitchen on",
  "origin": [0, 0],
  "revision": 4,
  "scale": 100
}

A scene with every luminaire on at full, those added later among them, is {"on": "all"}.

1. display.lighting MUST NOT be on a view whose kind is not 3d.
2. An id in on that names an element of the model MUST name a luminaire: an element of category electrical whose type's kind is light, spot, emergencyLight or track. An id that names no element of the model is a warning, not an error: a luminaire may be deleted after the scene was made. A writer that deletes a luminaire SHOULD take its id out of every scene, out of on and out of dim.
3. Every key of dim MUST be on in the scene: where on is a list, an id in it; where on is "all", the id of a luminaire, or of no element of the model (rule 4). The schemas state the levels' range, 1 to 99.
4. Where on is "all", a key of dim that names no element of the model is a warning, as an id in on that names none is (rule 2).

Reference: Stomra work 700, live since 26 October 2026 (main 044e36b0): display.lighting on a 3D view, which the walk shows, and the command view.lighting (section 9), pickLights and switchedScene in src/core/views/lighting.ts. The names and the meanings of this section were agreed with that work as it was built.

4.4 The legends of electrical drawings

A detail item of the kind legend lists what its view shows by a scheme, its legend.scheme: one of six in 0.1, type, department, unit, class, systems and fire (drawings/detail-item.schema.json). An electrical drawing has two of its own, which this part adds:

1. A legend's scheme MAY also be electrical or circuits. A validator MUST NOT refuse either.
2. A legend's scheme MUST be one of the six of 0.1 or one of these two: this part adds no other value (Part I, 11.2, rule 6).

The schema of a detail item of 0.2, schemas/0.2/drawings/detail-item.schema.json, holds the two in legend.scheme, and refuses any other value (rule 2). 0.1's stays as it is, without them: a validator of 0.1 refuses them, as values that 0.1 does not hold, and so does a reader of 0.1 that performs the whole-model check (Part III, 12).

What a legend draws, its symbols, the columns of a schedule and their order, is the application's, as it is for the schemes of 0.1 (Part II, 10).

A plan's display.electrical, power or data, draws a plan's power and lighting devices or its data and telecommunications devices alone (Part II, 14.3, rule 1), and a legend's own heading is its legend.title (Part II, 14.4, rule 3).

Reference: legendSchemes in src/core/sheets/legendSchemes.ts; the key and the schedule in src/core/annotations/roomTables.ts, from electricalLegend in src/core/elements/electricalLegend.ts (Stomra work 533) and circuitList in src/core/elements/circuits.ts (work 534). Its key lists the devices on a plan's level, or every device in another view, and its schedule the circuits whose board or devices are on a plan's level, or every circuit.

5. Cable carriers

A cable carrier, a conduit, a tray, a ladder or trunking, is an element of category cableCarrier, in electrical. It is a run, as a pipe or a duct is (Part IV, 12):

The other members of mep are a pipe's or a duct's, and mean nothing for a carrier. A carrier's width and height are not used for its body.

Its type's payload is cableCarrier, {kind, sizes, height?}:

1. A cable carrier or a modelled cable (section 6) MUST be a run as Part IV, 12.1 says of a pipe: it MUST carry mep with one height in mep.z for each point of its profile, and its profile MUST have two points or more, not all at one place (Part IV, 12.1, rules 1 and 2).
2. A type of category cableCarrier MUST carry the payload cableCarrier, with kind and sizes. Its schema states this rule.

A type of conduit for the ground, which comes in 50 mm and 110 mm, and a 50 mm conduit of it in the ground, 600 mm below the level, from under the meter cabinet A1 to under the main board N1A1:

{
  "cableCarrier": {
    "kind": "conduit",
    "sizes": [50, 110]
  },
  "category": "cableCarrier",
  "color": "#e07b39",
  "height": 50,
  "id": "type-conduit-ground",
  "material": "PE",
  "name": "Ground conduit",
  "revision": 0,
  "width": 50
}

{
  "category": "cableCarrier",
  "height": 50,
  "id": "conduit-a1-n1a1",
  "levelId": "level-0",
  "mep": {
    "size": 50,
    "z": [-600, -600, -600]
  },
  "name": "Ground conduit 50",
  "offset": 0,
  "profile": [
    [10250, 1500],
    [10250, 4000],
    [9790, 4000]
  ],
  "revision": 0,
  "typeId": "type-conduit-ground",
  "width": 50
}

6. Modelled cables

Most cables stay derived (section 8): the arcs on a plan, and an estimated route for the metres. A designer may model the route of any leg that matters, a main cable or a sub-board's feed, and leave the others derived. A modelled route is an element of category cable, in electrical: a round run, as a pipe is (Part IV, 12), whose mep.size is the cable's outer diameter. Section 5, rule 1 holds for its run as for a carrier's.

The cable itself, its type, conductors and area, is not here: it is the leg's cable (3.2), the electrical.cable of the element cable.to names, or else its circuit's cable. A route says only where the cable runs. Its width and height are not used for its body, and the other members of mep mean nothing for it. Its type, of category cable, has no payload in this part.

1. cable.to MUST name an element of category electrical whose electrical.circuitId is cable.circuitId.
2. Each id in cable.carrierIds MUST name an element of category cableCarrier.
3. The pieces that name one to make up one leg, the leg that feeds to, and its length is the sum of their lengths (Part IV, 12.4, rule 2). A route may be modelled in pieces: one for each storey, or one in the ground and one in the building.
4. A leg's route SHOULD start at the leg's upstream end and end at to: one of its pieces SHOULD start within 500 mm of the upstream device or board, and one SHOULD end within 500 mm of to. A piece starts at its first point and ends at its last, at their heights; a device or a board is at its at, at the height elev(levelId) + offset; the distance is measured in 3D. A leg of a supply has no upstream end in the model, and only its end is checked.
5. For its leg, a modelled route replaces the derived one: in the leg's length, in what is derived from it (the cable metres, a voltage-drop hint), and on drawings, where a plan draws the cable along its route. The other legs keep their derived routes and their arcs.

The feed of the main board N1A1 from the meter cabinet A1 (3.2), modelled in two pieces. The first drops from under A1 into the ground, and runs in the conduit of section 5 to under the board; the second rises from there into the board:

{
  "cable": {
    "carrierIds": ["conduit-a1-n1a1"],
    "circuitId": "circuit-a1-g1",
    "to": "board-n1a1"
  },
  "category": "cable",
  "height": 28,
  "id": "cable-n1a1-feed-1",
  "levelId": "level-0",
  "mep": {
    "size": 28,
    "z": [1075, -600, -600, -600]
  },
  "name": "N1A1 feed, in the ground",
  "offset": 0,
  "profile": [
    [10250, 1500],
    [10250, 1500],
    [10250, 4000],
    [9790, 4000]
  ],
  "revision": 0,
  "typeId": "type-cable-route",
  "width": 28
}

{
  "cable": {
    "circuitId": "circuit-a1-g1",
    "to": "board-n1a1"
  },
  "category": "cable",
  "height": 28,
  "id": "cable-n1a1-feed-2",
  "levelId": "level-0",
  "mep": {
    "size": 28,
    "z": [-600, 1150]
  },
  "name": "N1A1 feed, up to the board",
  "offset": 0,
  "profile": [
    [9790, 4000],
    [9790, 4000]
  ],
  "revision": 0,
  "typeId": "type-cable-route",
  "width": 28
}

Together they are one leg, 6385 mm long: 4635 mm and 1750 mm. The meter cabinet A1, 200 mm deep on the east wall's outside face (x = 10 150), is at [10250, 1500], 1400 mm up to its centre; the first piece starts 325 mm below that, at its body's underside. The board N1A1 is at [9790, 4000], 1500 mm up; the second piece ends 350 mm below that, at its body's underside. Both are within the 500 mm of rule 4. The cable is the leg's, FXQJ 4x25/16, from the circuit G1 of A1.

7. Bodies

A device is its declared geometry, where it or its type has one (Part II, 12.1; the element's wins for each aspect it declares). Its type's is placed in the frame of a category placed at a point: its origin at at, at the height elev(levelId) + offset, which is its mount's point (a wall device's centre, a ceiling device's top face, a floor device's base); its x axis along the facing, from at towards toward; and z up.

Otherwise its body is a box its width across the facing, its type's depth along it and its height high, centred on at in plan whatever its mount. Its width and height are its type's, but a linear device's width, which is the element's own, its length (2.3, rule 3). With z0 = elev(levelId) + offset, it reaches:

So a wall device, whose at lies half its depth out from its wall (2.1), has the back of its body on the wall and is centred on its height; a ceiling device hangs from its height; a floor device stands on it.

Carriers and cables have the body and the quantities of a pipe or a duct (Part IV, 12), with no insulation:

• a conduit's and a cable's section is round, mep.size across;
• a tray's, a ladder's and trunking's section is a rectangle mep.size wide and mep.height high (mep.size without it), kept upright as a rectangular duct's is (Part IV, 12.3, rule 3);
• a bend has the radius of the outer width (Part IV, 12.2), the volume and the length are Part IV, 12.4's, and a compiler's body conforms within Part IV, 12.5.

A carrier's body is the space it takes: an open tray or ladder takes its whole section. These are closed-form rules, of class A (Part IV, 2), for a compiler of 0.2; a compiler of 0.1 derives no body for these categories (Part IV, 1, rule 4).

Reference: electricalSpan and electricalSolids in src/core/elements/electrical.ts, and electricalAt, which puts a wall device's at half its depth out from the wall face; for runs, runSolids in src/core/elements/mep.ts, as for pipes.

8. What is derived

These are derived, and never stored (Part IV, 1):

• for each leg without a modelled route (section 6): its route, its length, and how a drawing shows it, an arc from device to device or a home run towards the board;
• for each leg: its cable (3.2), and the cable metres of a circuit or of a model, cable by cable;
• a circuit's load, the sum of its devices' power (each device's electrical.power, else its type's power), and the load on each of its phases;
• the hints of national rules: a voltage drop, a cable against its fuse, where a residual-current device is required;
• where an application places a device without from in its circuit's chain (4.1, rule 3).

How a leg's route is estimated is the application's. An application that keeps derived results keeps them in its own folder with a result manifest (Part VI, 8), never in a record.

Reference: circuitLegs and cableLengths (Stomra work 534). The reference estimates a leg's route up from where it starts to an installation zone 2400 mm above its floor, along the plan's two axes, through the floors between, and down to what it feeds; a leg of a supply has no route.

• Load: a circuit's load is its devices' power plus that of the circuits of the sub-boards it feeds.
• Current: taken at 230 V single-phase, or 400 V balanced over three phases.
• Voltage drop: to the farthest device along the legs, using a modelled route's length where there is one, with copper's resistivity 0.0225 Ω·mm²/m, plus the drop of what feeds the board.
• Hints: a load beyond the circuit's protection; a protection beyond the cable's carrying capacity (IEC 60364-5-52, installation method B2); a drop over 4 %; outlets on a circuit with no RCD.

9. Commands

Commands on these records are Part V's, and three of their own. What a delete takes with it is the reference implementation's behaviour: a command processor cascades or refuses (3.3, rule 5), and the reference cascades as this section says.

create, update, delete and the type commands (Part V, 2.1) work on the three categories as on any other (Part V, 1, rule 5): a processor holds their records to this part's schemas. A processor gives an electrical element its type's width and height, but a linear device the length its command gives, else its type's width (2.3, rule 3). The reference also places a device that a create gives by one point: on the nearest wall face within a metre, facing the room, its at half its depth out from the face (2.1), or else facing −y. The element it stores has two points (2.3, rule 1).

Two commands write circuits, and one a view's lighting scene (4.3):

view.lighting. id names a view of kind 3d (4.3, rule 1). The luminaires the command works on, its selection, are given by one selector or more:

Each selector but all is a list. Within one selector the luminaires it selects are a union, and across selectors an intersection: {"kinds": ["spot"], "rooms": ["room-hall", "room-kitchen"]} selects the spots of the hall and of the kitchen. A selection holds luminaires only (4.3): an id of ids, or an element a switch works, that is no luminaire selects nothing.

set says what the command does to its selection, and level, an integer from 1 to 100 in per cent, at what level. level is required with dim, and may be given with only:

What it writes is the scene of 4.3:

• Levels. level 100 is full: it takes the luminaire's entry out of dim. A level from 1 to 99 is the luminaire's entry in dim, so that a stored level is always 1 to 99.
• Off. A luminaire the command turns off loses its entry in dim. Where on was "all", it becomes the list of the luminaires left on, in the model's order of its elements.
• All. A command that names all: true, with on, dim or only, and after which every luminaire is on, writes on: "all", whatever its other selectors; with dim, each luminaire's level is its entry in dim. off never writes "all".
• Nothing on. A scene left with nothing on is removed: the view has no display.lighting, and every luminaire is off. A processor never writes on: [], which the schemas refuse.

The command that dims the kitchen's spots in the scene of 4.3 to 20 %, turning on any of them that is off, and leaves every other luminaire as it is. The view's revision becomes 5:

{
  "expectedRevision": 4,
  "id": "view-3d-evening",
  "kind": "view.lighting",
  "kinds": ["spot"],
  "level": 20,
  "rooms": ["room-kitchen"],
  "set": "dim"
}

What a delete takes with it, and what that does to revisions:

• The cascade.
  • Deleting a board or a meter cabinet deletes the circuits on it, those whose boardId names it.
  • Deleting a circuit, by circuit.delete or with its board, clears circuitId and from on every element whose electrical.circuitId names it, the boards it feeds among them, and deletes the modelled cables whose cable.circuitId names it.
  • Deleting a device gives each device whose from names it the deleted device's own from, or none, so that it is fed from its board. It takes the deleted device's id out of every controls, and a controls left empty goes. And it deletes the modelled cables whose cable.to names it.
  • Deleting a cable carrier takes its id out of every cable's carrierIds.
  • Deleting a luminaire takes its id out of every view's lighting scene, out of on and out of dim, and removes a scene left with nothing on (4.3, rule 2). The reference does so since its work 700, beside the cascade of controls (src/core/elements/circuits.ts), adding 1 to each changed view's revision.
• Revisions. A cascade that changes a record changes it by a command, so it adds 1 to the record's revision (Part I, 8, rule 2), and the answer names the record among those that the command changed (affected, Part V, 9).
• Deletes in a batch. Within one batch, an element's delete MAY give as its expectedRevision the revision its element had before a cascade of an earlier command of the same batch changed it, and a processor accepts it as it accepts the element's current revision. Only a delete may: any other command names the revision its record has when it runs (Part V, 3, rule 1). A processor that replays a log (Part V, 8) accepts such a delete the same way. So an application that deletes a selection as one batch, a chain of outlets say, with the revisions it read, is not refused by its own cascade.
• A delete of what a cascade already took. Within one batch, a delete of an element that a cascade of an earlier command of the same batch has already deleted, a modelled cable taken with its device for example, is done, and is not refused, when its expectedRevision is the revision the element had when the cascade took it (or it gives none). It changes nothing more. A processor that replays a log accepts it the same way. So a selection that holds a device and the cable to it can be deleted as one batch.
• The whole model. A processor of 0.2 checks this part's rules after every command, with the rules of Parts I and II (Part V, 6), and refuses a command that would leave a model that breaks a MUST of them.
• A processor that does not cascade so. One that deletes what a reference of this part names, electrical.circuitId or from, a circuit's boardId, an id in controls, a cable's to, circuitId or carrierIds, changes or deletes the records that name it in the same command, or refuses the delete, so that no rule of this part breaks (2.3, rule 4; 3.3, rule 5; section 6). The reference's cascade above is one such way. A deleted luminaire's id left in a scene breaks no MUST: it is a warning (4.3, rules 2 and 4).

Reference: applyCircuitCommand, afterElectricalDelete and refuseNewWiringErrors (Stomra work 534, and step 4 for cables and carriers); placedElectrical and electricalAt in src/core/elements/electrical.ts; view.lighting and the cascade into scenes, Stomra work 700, in progress on 26 October 2026.

10. IFC (informative)

This section is informative. It says how a bridge can export these records to IFC4, and where IFC4.3 differs, as buildingSMART's documentation of IFC4 ADD2 TC1 and IFC4.3 ADD2 gives the pattern. No single page of that documentation shows the whole of it: it is put together from the pages listed at the end of this section.

Kinds and classes. A device exports as the IFC class and predefined type of its kind, as the reference bridge writes them:

A USERDEFINED type carries its value in ObjectType. The standard property sets are filled where IFC has them: Pset_ElectricalDeviceCommon, Pset_OutletTypeCommon, Pset_SwitchingDeviceTypeCommon and Pset_LightFixtureTypeCommon. Each property is written where its value is given:

A switch's three properties are in the next table.

• The rated voltage is its circuit's. A device is on one circuit at most: the one its electrical.circuitId names, which feeds it. A board's or a meter cabinet's names its feed (3.2). Its rated voltage is that circuit's voltage. A device on no circuit, or on a circuit that gives no voltage, has no rated voltage written. None is assumed from its type's phases: 230 V for one phase and 400 V for three are a country's values, and a circuit gives its own.
• Which devices. Pset_ElectricalDeviceCommon applies to IfcDistributionElement and its subclasses, and every class of the table of kinds is one. A device written as another class has none of these properties: the kind other whose ifcClass names one, or a device written as an IfcBuildingElementProxy. buildingSMART's rule PSE001 holds a set to the classes its template names, and a bridge's fidelity report says what it leaves out.
• Where a plug fits. IsPluggableOutlet is TRUE where a plug fits the outlet: a socket outlet, a data outlet and a TV outlet, each with its sockets (2.2). A ceiling outlet is where a light is connected: plugged in some countries and wired in others. It is given no value. Nor is any other kind, which is no IfcOutlet.
• On the type. Pset_OutletTypeCommon holds its type's values alone, the same for each of its elements. It goes on the outlet's IFC type, in its HasPropertySets, as IFC4 has a type carry a set it drives by type. The other sets go on the device, as the reference bridge writes them; Pset_ElectricalDeviceCommon holds the device's rated voltage, which is its circuit's.

A switch's switching and gangs go into three properties:

IFC's SwitchFunction has no value for a two-circuit switch: its two circuits show as twice the gangs. A push-button is no SwitchFunction either, but the predefined type MOMENTARYSWITCH.

Light output. IFC4's Pset_LightFixtureTypeCommon holds a luminaire's wattage and none of its light, and a light source (IfcLightSourceGoniometric) needs its light distribution too, which 0.2 does not carry. A bridge writes a luminaire type's light output (2.2) in a property set OpenEik_Light: LuminousFlux (IfcLuminousFluxMeasure, lm), ColorTemperature (IfcThermodynamicTemperatureMeasure, K), BeamAngle (IfcPlaneAngleMeasure, in the file's angle unit) and Distribution (IfcLabel), each where the type gives it. OpenEik_Light is no Pset_ set: IFC keeps that prefix for buildingSMART's own. The reference bridge writes the same values in Stomra_Electrical.

Circuits.

• One IfcDistributionSystem of the predefined type ELECTRICAL, named LV, aggregates (IfcRelAggregates) one IfcDistributionCircuit, ELECTRICAL, for each circuit. The circuit's Name is its designation (G6), and its LongName its name.
• A circuit's devices are assigned to it by IfcRelAssignsToGroup. That is a set, and holds no order.
• A circuit starts at a port of its board: IfcRelAssignsToProduct assigns the circuit to the board's SOURCE port Circuit#n (or to the Load port of a protective device that an exporter writes in the board). Ports hang on their element by IfcRelNests.
• A supply has no board in the model, and so no port to start at.

Chains and feeds. IFC holds order and branches only as connections of ports: IfcRelConnectsPorts from a SOURCE port to a SINK port. Each leg exports as one: from the board's Circuit#n port, or a SOURCE port of the device its from names, to the Line SINK port of the device it feeds. A sub-board's feed is the same, from the upstream circuit's port to the sub-board's Line; Pset_DistributionBoardOccurrence.IsMain is TRUE on the topmost board and FALSE on the others.

Control. IFC has no relation for a switch that works a light. A wired control can be written as its wiring, the switch's Load SOURCE port connected to the light's Line SINK port. A bus or radio control has no IFC concept, and goes in a property set.

Cables and carriers. A modelled cable exports as an IfcCableSegment, CABLESEGMENT, with its swept body. It sits between the ports of its leg, the upstream one connected to its Input and its Output to the Line of to, and is a member of its circuit. A carrier exports as an IfcCableCarrierSegment: CONDUITSEGMENT, CABLETRAYSEGMENT, CABLELADDERSEGMENT or CABLETRUNKINGSEGMENT, by its kind.

What IFC cannot hold. IFC has no property for a residual-current device's type or a fuse's utilisation category, and a breaker's tripping characteristic fits only the free text CurveDesignation of a separate IfcProtectiveDeviceTrippingUnit. A circuit's protection therefore goes into a property set on the circuit, and the OpenEik record is the only place where it is whole.

Details.

• A cable's cross-section goes out in the project's unit of area: 1.5 mm² is 1.5E-6 in a project in metres.
• A linear device's body, and so its representation, is as long as the element's width, its own length (2.3, rule 3; section 7). One IfcLightFixtureType serves tracks of many lengths, as one type serves them in the model.
• IFC4.3 deprecates IfcElectricDistributionBoard for IfcDistributionBoard, but still binds the board's property sets to the deprecated class, so an exporter branches on the version.
• IFC's own enumeration of fuse types holds trade names. OpenEik copies none (Part II, 8).

The reference bridge writes IFC4: the classes of the table, the standard property sets and one of its own (Stomra_Electrical), with a switch's controls as the GlobalIds of what it works; one IfcDistributionSystem LV aggregating an IfcDistributionCircuit for each circuit, its devices assigned by IfcRelAssignsToGroup, its start at the board's Circuit#n port by IfcRelAssignsToProduct, and its legs as IfcRelConnectsPorts from that port, or from a device's Out port, to the next device's Line; and on each circuit its protection, its cable and its estimated length, in its own property set. Its standard properties differ from the rows above in three ways (open questions, 94):

• it writes RatedVoltage from a type's phases, 230 V for one and 400 V for three;
• it writes HasProtectiveEarth TRUE for an outlet whose connector is type F;
• it writes Pset_OutletTypeCommon on the device, and only for a type of the kind outlet that gives its sockets.

Reference: electricalIfc in src/core/elements/electrical.ts; writeCircuits in src/core/io/ifcCircuits.ts (Stomra work 534).

Sources. buildingSMART's documentation:

• IfcDistributionSystem: IFC4, IFC4.3;
• IfcDistributionCircuit: IFC4, IFC4.3;
• IfcDistributionPort (IFC4.3), and IfcRelConnectsPorts (IFC4.3);
• the board and its ports, IFC4.3: IfcElectricDistributionBoard (IFC4.3) and IfcDistributionBoard (IFC4.3); IfcProtectiveDevice (IFC4.3); IfcLightFixture (IFC4.3);
• a switch's properties, IFC4.3: Pset_SwitchingDeviceTypeCommon (IFC4.3) with its SwitchFunction (IFC4.3), and Pset_ElectricalDeviceCommon (IFC4.3);
• IfcCableSegment (IFC4.3) and IfcCableCarrierSegment (IFC4.3);
• the enumerations of IFC4 ADD2 TC1, in buildingSMART's EXPRESS schema, IFC4.exp.

11. Conformance

A claim of conformance to OpenEik 0.2 is a claim to what this section asks of each class it names (Conformance, 1.1). A claim to 0.1 says nothing about it: what 0.1 asks of every implementation covers these records, in a model of 0.1, as follows:

• a reader keeps the elements and types of the three categories, with all their members, as a later version's, and writes them back unchanged (Part I, 10, rule 5), keeps the circuits' files as kept files (Part III, 7), and keeps a view's display.lighting as a member it does not know (Part I, 10);
• a validator does not refuse them, warns about them, and checks them against the common schemas only (Part I, 10, rule 5);
• a compiler derives no body for them, but may place declared geometry of their own (Part IV, 1, rule 4), and a command processor makes none (Part V, 1, rule 5).

Of 0.2, each class does as follows:

• a validator checks the rules of sections 2.3, 3.3, 4.1, 4.3, 4.4, 5 and 6. It reports a breach of a MUST as an error: 2.3, rules 1 to 6; 3.3, rules 1, 2 and 4; 4.1, rules 1 and 2; 4.3, rules 1 to 3; 4.4, rule 2, as a schema error; 5, rules 1 and 2; and 6, rules 1 and 2. It accepts the two schemes of 4.4, rule 1. It reports a breach of a SHOULD as a warning: 3.3, rule 3, and 6, rule 4; and as a warning too, what 4.3, rules 2 and 4 say is one, an id of a scene that names no element. It names the file and the rule, as XIII.4.1.1;
• a reader reads the circuits as records, and the elements and types of the three categories as the categories this part defines;
• a writer meets 2.3, rule 3, and 3.3, rule 5, writes the circuits at their paths, and keeps a view's lighting scene with it (4.3);
• a compiler derives the bodies of section 7;
• a command processor implements section 9, and checks this part's rules with the whole model after every command;
• a bridge may follow section 10, which is informative.

The other rules say what the records mean: 3.3, rule 5 binds writers, whose breaches the validator's errors show; 4.1, rule 3, and 6, rules 3 and 5, say how a leg is fed and measured.

@openeik/tools checks this part for every model of 0.2, and for a model of 0.1 when asked: checkFolder(…, { proposals: ["electrical"] }), or openeik check --proposal electrical. Its command processor applies it so, to every model of 0.2 and, when asked, applyCommands(…, { proposals: ["electrical"] }) or openeik apply --proposal electrical, to a model of 0.1: it makes and changes the records of the three categories, and checks this part's rules with the whole model (Part V, 6, stage 3), so that it refuses a delete that would leave a reference of this part that names nothing, cascading nothing. It does not implement this part's three kinds of its own (section 9). Its conformance cases are in the suite of 0.2 (conformance/).