One schema for every kind of file, at its own address.

The manifest at the root of an OpenEik folder: the format and the units.

eik.json

Text: the conventions for agents. Not a record.

The project record: the schema version, the project's settings and its project information.

project/project.json

The levels, in order. Each id is unique.

project/levels.json

The order of the record lists other than elements, as lists of ids.

project/order.json

A grid line.

project/grids/<id>.json · list grids

A scope box: a named plan region that views can use.

project/scope-boxes/<id>.json · list scopeBoxes

A material of the project's material library.

project/materials/<id>.json · list materials

A dimension style (documentation profile).

project/dimension-styles/<id>.json · list dimensionStyles

A parametric 2D detail family (documentation profile).

project/detail-families/<id>.json · list detailFamilies

A record of a list that OpenEik 0.1 carries but does not define (sheets, title blocks, images, reports, renders, deviations, area adjustments, linked references). A Reader keeps it as it is.

project/title-blocks/<id>.json · list titleBlocks
project/images/<id>.json · list images
documents/reports/<id>.json · list reports
documents/renders/<id>.json · list renders
documents/deviations/<id>.json · list deviations
documents/area-adjustments/<id>.json · list areaAdjustments
documents/references/<id>.json · list references

A group placed more than once: the original whose members are elements.

project/originals/<id>.json · list originals

A placement of an original. Its elements are derived and never stored.

project/copies/<id>.json · list copies

A circuit of an electrical installation, a group of a board, or the supply: project/circuits/<id>.json, one record per circuit (Part XIII, 3.1. A device names the circuit that feeds it (electrical.circuitId), and so does a board or a meter cabinet, for the circuit that feeds the board. A circuit whose boardId is null is the supply, from outside the model. Circuits of one board with the same rcd.designation share one residual-current device.

project/circuits/<id>.json · list circuits

A person or an agent of the project's registry, project/people/<id>.json, list people (Part XIV, 5.1, with the keys of those who sign. Every file of Part XIV names people by these ids, never by an email address: an id that holds @ is the validator's to refuse (person-email). A name is personal data, kept in every version that holds it. A key is revoked by giving it a validUntil, never by removing it.

project/people/<id>.json · list people

A type record. The category-specific schemas in this folder add the rules of each category.

types/<discipline>/<category>/<id>.json · list types

An element record. The category-specific schemas in this folder add the rules of each category.

<discipline>/<level>/<category>/<id>.json · list elements

A view as stored in a folder's view.json: its detail items are in chunk files beside it, so details is absent or an empty list.

drawings/<discipline>/views/<kind>/<id>/view.json · list views

One chunk of a view's detail items, in order: details/<index>.json.

drawings/<discipline>/views/<kind>/<id>/details/<index>.json · list views

One 2D item of a view: a line, a text, a region, a dimension, a tag and so on (documentation profile). With the provenance and the anchors of Part XIV, 3.

A 3D view's lighting scene, its display.lighting (Part XIII, 4.3: which luminaires are on, and the level of each that is on and dimmed. A view without it has every luminaire off; the elements are never touched. Only on a view of kind 3d (rule 1); an id of on names a luminaire, an electrical element of the kind light, spot, emergencyLight or track (rule 2); every key of dim is on (rule 3).

A view with its detail items inline, as the single-file form holds it.

A record of the list sheets (drawings/<discipline>/sheets/<id>.json): a sheet of Part XIV, 2.1 where it gives every member that section requires, else a sheet of 0.1 kept as an application record, which a reader keeps and no drawing is issued on (Part XIV, 2.1, rule 1).

drawings/<discipline>/sheets/<id>.json · list sheets

A view as stored in a folder's view.json: its detail items are in chunk files beside it, so details is absent or an empty list.

drawings/<discipline>/views/<kind>/<id>/view.json · list views

One chunk of a view's detail items, in order: details/<index>.json.

drawings/<discipline>/views/<kind>/<id>/details/<index>.json · list views

The project's drawing conventions, drawings/profile.json (Part XIV, 4: its status, purpose, decision and review-state codes mapped onto OpenEik's neutral states, the revision series of each status, the cloud rules, the sign-offs each status needs, and the pinned font set. A drawing file, not a record. Every code is a plain value: OpenEik lists none and checks none against a code list (Part II, 8, rules 3 and 4).

drawings/profile.json

The profile of an issued drawing's SVG (Part XIV, section 6 as data: the elements and attributes it allows, what it forbids, the forms of its values and references, and its limits. A validator and a host's parser share it. It is a schema that asserts nothing: its member x-eik-svg-profile holds the profile. Safety comes from this allowlist and a validator, not from sanitising: anything it does not allow is refused. The rules that read it are XIV.6.12, rules 1 to 27.

drawings/issued/<drawing>/drawing.svg

What an issued revision is, drawings/issued/<drawing>/revision.json (Part XIV, 8: its sequence, which is its identity, the revision code shown, its state and status, its derivation (equal to the SVG's) and the SVG's digest, or for an unlinked drawing its file, an asset; the changes since the revision it supersedes, and whether clouds mark them. An unlinked revision has file and no svg, derivation or read set (XIV.8.5, rule 11, which a validator checks in code).

drawings/issued/<drawing>/revision.json

Every record an issued revision's drawing read, with its hash, and the elements its views' volumes held: drawings/issued/<drawing>/read-set.json (Part XIV, 9.2. A pair is [path, hash] as Part VI, 8.3 says: a record's leaf path and its hash, or a kept file's own path and the hash of its text as a canonical JSON string; a view gives one pair for view.json and one for each detail chunk. Each list is sorted by path, each path once (XIV.9.7, rule 1, which a validator checks in code).

drawings/issued/<drawing>/read-set.json

One signer's action on one revision: drawings/issued/<drawing>/signoffs/<n>.json (Part XIV, 14.2, <n> s- and the first 12 hexadecimal digits of the envelope's hash. A DSSE envelope whose payload is an in-toto Statement v1 (statement.schema.json) about the digests of drawing.svg and revision.json, signed over DSSE's pre-authentication encoding; for each signature an RFC 3161 time-stamp token whose message imprint is the SHA-256 of the signature's bytes; and the legal tier's container, where there is one. A signature made with a passkey carries the WebAuthn data its signature covers (XIV.14.7, rule 9).

drawings/issued/<drawing>/signoffs/<n>.json
drawings/issues/<issue>/signoffs/<n>.json
drawings/issues/<issue>/receipts/<n>.json
project/terms-accepted/<n>.json

Every snapshot ever taken of one drawing, oldest first: drawings/register/<drawing>.json (Part XIV, 11, append-only. An issued entry is a revision, by its revision record's hash and its SVG's digest and derivation's hash (linked) or its file's digest (unlinked), and what it was drawn from; a rendition entry a PDF rendition kept as an asset; a withdrawn entry the drawing's end. Superseded is implied: each issued entry supersedes the one before. The issuer adds entries, in the building; a host never writes it.

drawings/register/<drawing>.json

A transmittal, the release of revisions, versions of the model or both to recipients for a purpose: drawings/issues/<issue>.json (Part XIV, 12. Each revision by its revision record's hash, each version by its root tree hash (Part XVIII, 3, proposed beside it), the prints sent with it by their digests and the terms it is sent under by theirs; recipients by their ids in the registry, or by name for someone outside it, never by an email address. Delivery, links and read receipts are the host's, and stay there.

drawings/issues/<issue>.json

A review round on one revision, as structured data: drawings/reviews/<review>.json (Part XIV, 13. The revision reviewed by its digests: the SHA-256 of drawing.svg (linked) or of the unlinked drawing's asset, and the hash of revision.json, as reviewed. A host keeps reviews and their working state; at the close the authoring tool saves the review into the building. Seen ticks, read receipts and each person's progress are the host's, and stay out.

drawings/reviews/<review>.json

The definitions the schemas of the proposal drawings share (Part XIV: hashes, times, ids, the people they name, codes and the status of a revision. It asserts nothing of its own.

What a revision was drawn from (Part XIV, 6.9: the version, the sheet and views, the generator and its fonts, the read set by hash. An issued drawing.svg holds it in <metadata id="openeik-derivation"> as the text of its canonical JSON (RFC 8785), and the revision record holds the same object as its derivation. It never holds the SVG's digest nor the revision record's. Its hash (Part III, 6) is the derivation's digest.

Who made a detail item (Part XIV, 3.2. An item an agent writes carries it: the agent, the person it acts for, the instruction by its SHA-256 and an opaque reference under access control (never the instruction's text), the model version it saw, and its status, proposed until a person accepts it, then accepted, with who accepted it and when. The AI rule: a person accepts every agent's item, and no sheet is issued while it holds a proposed item.

A sheet, drawings/sheets/<id>.json (Part XIV, 2: a paper, the views placed on it and its title-block fields. Its number is the drawing's, stable across revisions, and names the folder of its issued drawing. The values that change with each revision (the date of issue, the revision code, the status, the revision table) come from the revision record and the register, never from the sheet.

The predicate of a sign-off statement, https://openeik.org/attestation/drawing-signoff/v0.1 (Part XIV, 14.1: the revision signed, its status, what the signer did and in which role, the model it was drawn from, and when, by the signer's own clock (the time-stamp is the trusted time). A decision is a code of the profile's decisions; a withdrawal names the sign-off file it withdraws by its hash; a tool's check names the result manifest that holds what it found.

The statement a sign-off's envelope carries: an in-toto Statement v1 (Part XIV, 14.1. Its subjects are drawings/issued/<drawing>/drawing.svg with the SHA-256 of its bytes, or an unlinked drawing's asset, and drawings/issued/<drawing>/revision.json with its hash (Part III, 6): exactly two, which a validator checks in code (XIV.14.7, rule 3). Its predicate, of the type https://openeik.org/attestation/drawing-signoff/v0.1, is held to signoff-predicate.schema.json.

A fabricated unit: what leaves the factory as one piece (fabrication profile).

fabrication/pieces/<id>.json · list pieces

A structural joint: the plates, bolts and welds where members meet (fabrication profile).

fabrication/joints/<id>.json · list joints

What a result set was computed from: <application>/<model>/results/<run>/manifest.json, a kept file (spec Part VI, 8.2 to 8.5). Written by hand from the text, not generated. A reader also reads the earlier id openeik-result/0.1-proposal as this format.

format openeik-result/0.1, and the earlier openeik-result/0.1-proposal
<application>/<model>/results/<run>/manifest.json

A change an application offers to a model's records, as commands of Part V: <application>/<model>/proposals/<id>.json, a kept file (spec Part VI, 8.7). Written by hand from the text, not generated. A reader also reads the earlier id openeik-proposal/0.1-proposal as this format.

format openeik-proposal/0.1, and the earlier openeik-proposal/0.1-proposal
<application>/<model>/proposals/<id>.json

One result of the derived layer (Part IV, 1.1.2): what a producer derived for one record, an element or a type, at .eik/derived/elements/<id>.json or .eik/derived/types/<id>.json in a folder, and keyed elements/<id> or types/<id> where it is handed from one tool to another, as a result's sources are keyed; with every record it was derived from by its hash (rule 3), so that a reader uses it only while those hashes hold (rule 4). Its result is the record's bodies in the kinds of Part IV, 1.1.1, an element's with its quantities and a member's lines, and nothing else. Coordinates are in millimetres, z up (Part I, 3): an element's in the model's coordinates, a type's in its own frame, which a mapped body places. Every body may carry the tags of tags.

.eik/derived/elements/<id>.json
.eik/derived/types/<id>.json

A whole model as one JSON object: the single-file form of Part III. Lists hold their records in order; views hold their detail items inline; extras holds the folder's kept files, text by path. From 0.2 it names its format and units at its top, as eik.json does for a folder (Part III, 11).

A command of the core record operations (Part V, 2.1), view.upsert of the documentation profile (Part V, 2.2), or of the kinds a part adds (Part XIII, 9), checked against the schema of its kind. x-eik-commands lists the kinds, their schemas and their preconditions (the member, and whether it is required, optional, required when the record exists, or none).

Adds an element; its id is new (Part V, 2.1).

precondition expectedHostRevision, optional

Patches an element (Part V, 4).

precondition expectedRevision, required

Removes an element and what depends on it (Part V, 5).

precondition expectedRevision, required

Writes a type whole. A new type counts as revision 0 (Part V, 3.2).

precondition expectedRevision, optional

Removes a type no element uses (Part V, 5.4).

precondition expectedRevision, required

Copies a type under a new id and name, optionally assigning it to one element.

precondition expectedSourceRevision, required

Adds or changes a level; a new level gets its own plan unless plan is false.

precondition expectedLevel, optional

Removes a level with its plans; refused while anything stands on it or reaches up to it, unless moveTo names the level they move to (Part V, 5.4).

precondition expectedLevel, required

Writes a material. expectedRevision, when given, names an existing material's revision.

precondition expectedRevision, optional

Writes a grid line. Strict: expectedRevision is given exactly when the grid exists (Part V, 3.2).

precondition expectedRevision, when the record exists

Renames the project.

precondition expectedName, required

Sets the project's zero above a shared datum, in mm.

precondition expectedOffset, required

Sets where the project stands, or clears it with null.

precondition expectedSite, optional

Sets the envelope's air leakage and thermal bridges (Part II, 2.1), or clears them with null.

precondition expectedEnvelope, optional

Sets the project's room measuring rules.

precondition expectedSettings, optional

Sets the project information: information replaces it whole; patch changes the fields it names, null taking one away and custom merged name by name. One of the two.

precondition expectedInformation, optional

Sets or clears (null) the project's excavation rule.

no precondition

Sets or clears (null) the project's precast rules.

no precondition

Sets or clears (null) the project's drawing standards, an application value (Part II, 9.2).

no precondition

Makes elements an original (a group placed many times): they and what is hosted on them name it in original. origin, left out, is the lower left corner of the profile points of the elements that have no host.

no precondition

Adds elements, and what is hosted on them, to an original.

precondition expectedRevision, required

Takes elements, and what is hosted on them, out of an original.

precondition expectedRevision, required

Names an original, or takes its name away with null.

precondition expectedRevision, required

Makes an original's elements ordinary elements again; refused while it has copies.

precondition expectedRevision, required

Writes an original's kept elements out at another of its instances.

no precondition

Runs commands as one step with the original open to them: outside this command an element of an original is not changed.

no precondition

Places a copy of an original.

no precondition

Moves, turns, lifts or re-levels a copy; levelId null makes it follow its original's level.

precondition expectedRevision, required

Removes a copy.

precondition expectedRevision, required

Makes a copy ordinary stored elements.

precondition expectedRevision, required

Writes a view whole, its detail items inline as the single-file form holds them (Part V, 2.2): a changed view keeps nothing the command does not carry, and is at its revision plus one. A new view counts as revision 0 (Part V, 3.2); expectedRevision, when given, is the view's revision as read.

precondition expectedRevision, optional

Writes a circuit whole (Part XIII, 9). A new circuit gets revision 0, and a changed one its revision plus one. expectedRevision, when given, names an existing circuit's revision.

precondition expectedRevision, optional

Removes a circuit, and lets go of its devices (Part XIII, 9): every element whose electrical.circuitId names it loses its circuitId and its from, and the modelled cables whose cable.circuitId names it are deleted.

precondition expectedRevision, optional

Switches luminaires on, off or to a level in a 3D view's lighting scene, display.lighting (Part XIII, 9 and 4.3), and writes the view whole, adding 1 to its revision; it changes no element. The luminaires it works on are given by one selector or more: within a selector they are a union, and across selectors an intersection. level is required with set dim, may be given with only, and is not given with on or off.

precondition expectedRevision, required

What a command processor answers a batch (Part V, 9), with what Part XVII adds: the mode, the operation and the target it met, and every refusal with its code, a JSON pointer into the command, a message for people and a fix where one is known. A processor may add members of its own (the reference processor's joins and the like): a reader ignores what it does not know.

What a writer sends a command processor around a batch of commands of Part V (Part XVII, 2): the operation's id, who sends it, the line of work and the version the commands were made from, the mode, an intent for people, and the commands. A member it does not define is refused, an extension member (<prefix>:<name>, Part I, 11.2) aside.

What a version's tree holds of an asset at its path assets/<sha256>.<ext> (Part XV, 3, rule 1): the canonical form of {"asset": {"bytes": <n>, "sha256": "<sha256>"}}. bytes is the file's length in bytes; sha256 its name's digest, which a reader checks against the name (rule 2). The bytes themselves are kept by the store, beside its objects (section 5).

assets/<sha256>.<ext>

project/owners.json (Part XVI, 2: the parties of a project, and the rules that say which of them own which paths, by globs (Part XVI, 3). The owners of a path are those of the last rule with a glob that matches it. A file of the standard's own folder, not a record.

project/owners.json

An element's, a type's or a view's owner, set by hand (Part III, 4.4, rule 1): one of the eight disciplines of Part XVI, 2, rule 4. It wins over every rule that gives the record an owner, and the record's folder in the owners' layout is its owner's.

A review round on one version of the model, in 3D: project/reviews/<review>.json (Part XVIII, 2. The version by its root tree hash; items on its elements, each seen from a viewpoint; the reviewers, states and decisions of the drawing profile, as a drawing's review has them (Part XIV, 13). A host keeps a round while it is open; at the close the authoring tool saves it into the building.

project/reviews/<review>.json

The keys a host signs its receipts and its attestations of terms accepted with (Part XVIII, 5.6, which a verifier takes as trust anchors (XVIII.5.3, rule 7): the host as people know it, the host.name of its receipts; and its keys, each in the shape of a key of the registry (Part XIV, 5.1) with no rpId, the window it signs in from validFrom and before validUntil. A retired key keeps its validUntil and stays listed, a key id is never used again, and a key is never removed once the host has signed with it; a validator checks in code that each key id is listed once, that a public key is of its algorithm and that no window ends before it begins.

The predicate of a statement about an issue, https://openeik.org/attestation/issue/v0.1 (Part XVIII, 4.1: the issue by its id and hash; issued, the sender's word that they released exactly it; received, a recipient's that they received it; withdrawn, a signer's withdrawal of their own statement about it, named by its file's hash; the signer, a person of the registry, in a role; and when, by the signer's clock (the time-stamp is the trusted time).

The predicate of a host's receipt of an issue, https://openeik.org/attestation/issue-receipt/v0.1 (Part XVIII, 5.2: the issue by its id and hash, the host as people know it, the recipient, one the issue names or one the host sent it to, and then who on the host sent it (sentBy) and the host's own id for that sending (transmittal), which a validator asks for in code (XVIII.5.3, rule 3); the events the host saw for that recipient, oldest first, by the host's clock, a print the issue does not list named with what it was printed from (of); and when the host made the receipt. Signed with a key the host publishes, which a verifier is given as a trust anchor.

The predicate of a record that a person accepted named terms, https://openeik.org/attestation/terms-accepted/v0.1 (Part XVIII, 6.1: the person, a person of the registry; the terms by the SHA-256 of their text, with their title and version; the building, by its project's id, and the issue where they are an issue's; whether the person signed it with their own key or a host attests it; and when. Personal data, kept in every version that holds it.

The point of a detail family that a placed copy hangs on, in the family's own x and y, each a number or bound to its parameters as a sketch's points are (Part II, 14.5. Absent, a single item hangs on the family's origin, and a repeated copy on the middle of its box.

A leader whose text is a layered type's build-up (Part II, 14.4, rule 4: its layers, outermost or topmost first, each its thickness and its name, under the type's U value unless uValue is false. The text is worked out from the type each time it is drawn; a text the leader gives is drawn in its place.

A closed line drawn as a revision cloud (Part II, 14.4, rule 1: its points are the cloud's corners, joined by scallops of arc mm on the paper, outward, or inward where inward is true; revision is the mark its tag shows, a triangle centred on tag, else on its first corner, and not shown where tagHidden is true or the mark is empty.

In a plan, the marks of the instances of groups, copies' ids or originals', whose floors are taken out of a region where it is drawn, worked out where they stand (Part II, 14.4, rule 7.

In a plan, the mark of the instance of a group, a copy's id or an original's, that a free 2D item moves and turns with (Part II, 14.4, rules 5 and 6.

A legend's own heading, in place of the one the drawing application gives its scheme (Part II, 14.4, rule 3.

true: a text whose words read as a number measures nothing, and a check of the drawing's dimensions does not hold it to the model (Part II, 14.4, rule 8. Only a text carries it.

A room schedule's own column headings, by the field each column shows, in place of the headings the drawing application gives (Part II, 14.4, rule 2.

The id of another element this element is cast with in one pour, as a foundation poured with the slab on it (Part II, 14.1: where their cut regions of one material meet in a section, a drawing draws them as one region, with no line between them. It changes no body.

Stretches of a slab edge element where its outside upstand and its facing are cut down (Part IV, 4.6, rules 12 to 14: from and to in mm along its host's edge from the edge's first point, and depth from the section's top. Only an L or a U section has an outside upstand to notch; a notch is at least 10 mm long, ends on its edge, keeps above the flange, is at least as deep as a chamfer, and overlaps no other.

How a layer's cut is drawn in a drawing of its type's build-up (Part II, 14.2: copies of the detail family familyId, of its type typeId, repeated along the layer in place of its material's pattern, spacing mm apart centre to centre (side by side where absent), the first offset mm from the layer's start, turned by rotation degrees, and across the layer on its middle or against its inside or outside face (align). Without familyId the layer draws nothing of its own.

false: the tags of a terminal type's elements leave out its size, its connection's size, which they otherwise give (Part II, 14.6. Absent or true, they give it.

The pitch in degrees, 0 to 75, a roof type's vertical cut is drawn at in a drawing of its build-up (Part II, 14.3, rule 4. Absent, the pitch every roof of the type has, else level.

Where a 3D view's perspective camera stands and looks, position and target in mm in the model's axes, at least 1 mm apart, and its field of view, fov, in degrees (Part II, 14.3, rule 6. A tool that shows or renders the view in perspective looks so; a sheet draws a 3D view by its orthographic camera.

Which electrical devices a plan draws (Part II, 14.3, rule 1: power, its power and lighting, or data, its data and telecommunications outlets, speakers and access points; absent, all of them.

false: a section's, an elevation's or a callout's level lines are drawn without their heads, the mark with the level's name and elevation (Part II, 14.3, rule 2. Absent or true, with them.

false: a drawing of a type's build-up (a view's assembly) does not mark its sides, outside and inside, or top and underside (Part II, 14.3, rule 3. Absent or true, it marks them.

true: the view is drawn on screen with its line weights; absent, in thin lines, every line one device pixel wide (Part II, 14.3, rule 5. A print draws the line weights whatever it says.

Codes of classification systems that OpenEik does not list (Part II, 11): each names its system, by its name or a URI, a code of it, the system's edition where it matters, and the code's own URI as its publisher gives it. One reference is not carried twice; the list's order has no meaning. OpenEik does not check that a code is one of its system's.

The material a door family's leaves are of, where it is not its frame's (Part IV, 4.3.1, rule 14): wood, aluminium or steel, as a wood leaf in a steel frame. Without it, a leaf is of its family's material. A family of another kind has no leaf of its own.

The section of a door's or a window's frame members, mullions and transoms, or sash members (Part IV, 4.3.1, rule 15): an outline as a custom section's is (Part II, 5.2, rules 8 and 9), points, the contour of its outside, less each of voids, each {points}, the contour of a hole through it, in mm in the members' section plane, x across the member in the wall's plane and y across the wall. Its bounding box is its members' width by their depth, within 0.1 mm.

What a layer whose framing rule runs horizontally is battened with (Part IV, 7.4.8, rule 1): service battens, inside the frame for the installations, where it gives none; nailing battens, that a cladding is nailed to; or counter battens, that hold a ventilated gap open.

The header across a roof opening that a layout of rafters frames (Part IV, 7.4.13, rule 10): none, "none", where a modelled beam carries the opening; or one piece of its own section, width up the slope and depth square to it from the rafters' top, a glulam or a laminated veneer header for a wide opening. Where it gives none, the header is the layout's openingFraming.headerPlies plies of its family's Width by its ChordDepth.

The grain of a layer of a slab, wall, roof, ceiling or foundation type (Part II, 5.1.1, rule 1): along where its fibres, or a sheet's strong direction, run along the element's main direction, across where they run square to it in the layer's plane. A layer without it states none.

The direction its layers' grain is told from, in degrees counter-clockwise in plan from the model's x axis, read modulo 180 (Part II, 5.1.1, rules 2 and 4). A slab, a ceiling or a foundation with panels has its main direction square to their direction, and where it carries both they agree; a roof's every face takes it, projected vertically onto its plane.

The direction its layers' grain is told from, in the wall's plane (Part II, 5.1.1, rule 3): vertical, up the wall, or horizontal, along its baseline; vertical where the wall gives none.

Where the predefined type a record was read with is USERDEFINED (ifcSource.predefinedType), the type its object named for it: an occurrence's ObjectType, a type's ElementType, as IFC holds it, at most 255 characters.

The IFC predefined type of the object a record was read from, as IFC writes an enumeration's value without its dots (FLOOR, GUTTER, USERDEFINED): an occurrence's own, else its type's; a type's own. With the class (ifcSource.entity) it is what the object is in IFC, and a bridge prints both for an element whose shape is given (Part VIII, 2.3, rule 6).

given: the element's shape is the body its reader gave, a result of the derived layer keyed elements/<id> (Part IV, 1.1.1), and not its record's members, which place it and nothing more (Part VIII, 2.3, rule 2). A compiler derives no body from them and a bridge prints the given body. A rule that recognises the element natively writes its record's own members and leaves shape out (Part VIII, 2.6).

Where the project stands and which way north is (Part II, 2 and 2.2): true north, in degrees clockwise from the plan's +Y, alone or with the site's location, its latitude, longitude and IANA time zone, which are given together; and, with the location, the coordinate reference systems the plan is placed in on a map and its heights given in. The latitude and the longitude name the plan's origin at the project's zero.

The plane of a slab's top face (Part II, 6.3.1): its gradient as slope, in degrees, or as rise over run, in mm; and its direction as edgeId, the edge of the outline from whose line the top rises into the outline, at the slab's level plus its offset, as a roof's slope-defining edge, or as fall, the direction in plan in which the top falls, in degrees counter-clockwise from the model's x axis, the top at the slab's level plus its offset at its profile's first point. Exactly one of slope and rise with run, and exactly one of edgeId and fall.

The prefixes registered for applications' extensions, and the names OpenEik reserves (spec Part I, 11.1): registry/extensions.json in the specification's repository. The rules a schema cannot state (each name once and in order, no prefix reserved, none given to another registrant) are checked by the repository's tests and kept by its editors. Unlike the schemas of a model's files, which keep the members they do not know (Part I, 10), this schema refuses them: the registry is edited by hand and read by tools, and a misspelt member (contacts for contact) would otherwise pass unnoticed.