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

• eik.schema.json
  eik.json

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

  eik.json

• AGENTS.md
  No schema

  Text: the conventions for agents. Not a record.

• project/project.schema.json
  project/project.json

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

  project/project.json

• project/levels.schema.json
  project/levels.json

  The levels, in order. Each id is unique.

  project/levels.json

• project/order.schema.json
  project/order.json

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

  project/order.json

• project/grid.schema.json
  Grid

  A grid line.

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

• project/scope-box.schema.json
  Scope box

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

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

• project/material.schema.json
  Material

  A material of the project's material library.

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

• project/dimension-style.schema.json
  Dimension style

  A dimension style (documentation profile).

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

• project/detail-family.schema.json
  Detail family

  A parametric 2D detail family (documentation profile).

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

• application-record.schema.json
  Application record

  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
drawings/sheets/<id>.json · list sheets
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

• project/original.schema.json
  Original

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

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

• project/copy.schema.json
  Copy

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

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

• types/type.schema.json
  Type

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

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

• elements/element.schema.json
  Element

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

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

architecture/19 categories

• slabtypeelement
• walltypeelement
• ceilingtypeelement
• rooftypeelement
• doortypeelement
• windowtypeelement
• componenttypeelement
• guttertypeelement
• roomtypeelement
• roomSeparatortypeelement
• shafttypeelement
• stairtypeelement
• railingtypeelement
• furnituretypeelement
• plantingtypeelement
• roadtypeelement
• parkingtypeelement
• firetypeelement
• generictypeelement

structure/6 categories

• foundationtypeelement
• beamtypeelement
• columntypeelement
• slabEdgetypeelement
• rebartypeelement
• meshtypeelement

systems/3 categories

• pipetypeelement
• ducttypeelement
• terminaltypeelement

site/3 categories

• terraintypeelement
• gradingtypeelement
• propertyLinetypeelement

• drawings/view-record.schema.json
  View record (view.json)

  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/views/<kind>/<id>/view.json · list views

• drawings/view-details.schema.json
  View detail chunk

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

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

• drawings/detail-item.schema.json
  Detail item

  One 2D item of a view: a line, a text, a region, a dimension, a tag and so on (documentation profile).

• drawings/view.schema.json
  View

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

• fabrication/piece.schema.json
  Piece

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

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

• fabrication/joint.schema.json
  Joint

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

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

• applications/result-manifest.schema.json
  Result manifest

  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

• applications/proposal.schema.json
  Proposal

  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

• model.schema.json
  Single-file model

  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.

• commands/index.json
  Core command

  A command of the core record operations (Part V, 2.1), 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).

• commands/create.schema.json
  create

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

  precondition expectedHostRevision, optional

• commands/update.schema.json
  update

  Patches an element (Part V, 4).

  precondition expectedRevision, required

• commands/delete.schema.json
  delete

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

  precondition expectedRevision, required

• commands/type.upsert.schema.json
  type.upsert

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

  precondition expectedRevision, optional

• commands/type.delete.schema.json
  type.delete

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

  precondition expectedRevision, required

• commands/type.duplicate.schema.json
  type.duplicate

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

  precondition expectedSourceRevision, required

• commands/level.upsert.schema.json
  level.upsert

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

  precondition expectedLevel, optional

• commands/level.delete.schema.json
  level.delete

  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

• commands/material.upsert.schema.json
  material.upsert

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

  precondition expectedRevision, optional

• commands/grid.upsert.schema.json
  grid.upsert

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

  precondition expectedRevision, when the record exists

• commands/project.rename.schema.json
  project.rename

  Renames the project.

  precondition expectedName, required

• commands/project.elevationOffset.schema.json
  project.elevationOffset

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

  precondition expectedOffset, required

• commands/project.site.schema.json
  project.site

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

  precondition expectedSite, optional

• commands/project.envelope.schema.json
  project.envelope

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

  precondition expectedEnvelope, optional

• commands/rooms.settings.schema.json
  rooms.settings

  Sets the project's room measuring rules.

  precondition expectedSettings, optional

• commands/project.information.schema.json
  project.information

  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

• commands/project.excavation.schema.json
  project.excavation

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

  no precondition

• commands/project.precast.schema.json
  project.precast

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

  no precondition

• commands/project.standards.schema.json
  project.standards

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

  no precondition

• commands/original.make.schema.json
  original.make

  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

• commands/original.add.schema.json
  original.add

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

  precondition expectedRevision, required

• commands/original.remove.schema.json
  original.remove

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

  precondition expectedRevision, required

• commands/original.rename.schema.json
  original.rename

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

  precondition expectedRevision, required

• commands/original.dissolve.schema.json
  original.dissolve

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

  precondition expectedRevision, required

• commands/original.frame.schema.json
  original.frame

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

  no precondition

• commands/original.edit.schema.json
  original.edit

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

  no precondition

• commands/copy.place.schema.json
  copy.place

  Places a copy of an original.

  no precondition

• commands/copy.move.schema.json
  copy.move

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

  precondition expectedRevision, required

• commands/copy.remove.schema.json
  copy.remove

  Removes a copy.

  precondition expectedRevision, required

• commands/copy.unique.schema.json
  copy.unique

  Makes a copy ordinary stored elements.

  precondition expectedRevision, required

• registry/extensions.schema.json
  Extension registry

  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.

• proposed/adopted/detail-family-insertion.schema.json
  A detail family's insertion point

  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, proposed for 0.2). Absent, a single item hangs on the family's origin, and a repeated copy on the middle of its box.

• proposed/adopted/detail-item-build-up.schema.json
  A build-up text

  A leader whose text is a layered type's build-up (Part II, 14.4, rule 4, proposed for 0.2): 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.

• proposed/adopted/detail-item-cloud.schema.json
  A revision cloud

  A closed line drawn as a revision cloud (Part II, 14.4, rule 1, proposed for 0.2): 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.

• proposed/adopted/detail-item-cut-by.schema.json
  The instances of groups a region is cut by

  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, proposed for 0.2).

• proposed/adopted/detail-item-follows.schema.json
  The instance of a group a 2D item follows

  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, proposed for 0.2).

• proposed/adopted/detail-item-legend-title.schema.json
  A legend's heading

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

• proposed/adopted/detail-item-not-dimension.schema.json
  A text that measures nothing

  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, proposed for 0.2). Only a text carries it.

• proposed/adopted/detail-item-schedule-headings.schema.json
  A room schedule's headings

  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, proposed for 0.2).

• proposed/adopted/element-cast-with.schema.json
  Cast in one pour with

  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, proposed for 0.2): 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.

• proposed/adopted/element-notches.schema.json
  A slab edge element's notches

  Stretches of a slab edge element where its outside upstand and its facing are cut down (Part IV, 4.6, rules 12 to 14, proposed for 0.2): 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.

• proposed/adopted/index.json
  The reference implementation's members taken into 0.2

  The index of the proposal adopted (Part II, 4, 7, 14, and Part IV, 4.6, proposed for 0.2). It is a schema that asserts nothing: its member x-eik-proposal names the members the proposal adds to records of 0.1, each by its record, its path in the record (* stepping into a list's items), the categories of elements and types or the kinds of views and detail items it belongs on, where it belongs on some only, its schema and its rule; the value it adds to two enumerations of 0.1, each by its schema and its path there; and the references between records it adds, by the record they are in, their path and the kind of record they name (an instance being a copy, or an original's own placement). The proposal adds no file. Schema paths are relative to https://openeik.org/schemas/0.1/.

• proposed/adopted/type-layer-drawing.schema.json
  A layer drawn with a detail family

  How a layer's cut is drawn in a drawing of its type's build-up (Part II, 14.2, proposed for 0.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.

• proposed/adopted/type-terminal-tag-size.schema.json
  A terminal's tag without its size

  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, proposed for 0.2). Absent or true, they give it.

• proposed/adopted/view-assembly-pitch.schema.json
  A roof type's build-up drawn at a pitch

  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, proposed for 0.2). Absent, the pitch every roof of the type has, else level.

• proposed/adopted/view-camera.schema.json
  A 3D view's perspective camera

  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, proposed for 0.2). A tool that shows or renders the view in perspective looks so; a sheet draws a 3D view by its orthographic camera.

• proposed/adopted/view-display-electrical.schema.json
  An electrical plan's devices

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

• proposed/adopted/view-display-level-labels.schema.json
  Level heads in a section

  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, proposed for 0.2). Absent or true, with them.

• proposed/adopted/view-display-side-marks.schema.json
  A build-up's sides marked

  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, proposed for 0.2). Absent or true, it marks them.

• proposed/adopted/view-line-weights.schema.json
  A view drawn with its line weights

  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, proposed for 0.2). A print draws the line weights whatever it says.

• proposed/assets/index.json
  Assets, proposed for 0.2

  The index of the proposal assets (Part XV, proposed for 0.2). It is a schema that asserts nothing: its member x-eik-proposal maps what the proposal adds to its schema. In a folder an asset is the file itself, binary, which no schema describes; in a version's tree it is a pointer, which pointer.schema.json describes. Schema paths are relative to https://openeik.org/schemas/0.1/.

• proposed/assets/pointer.schema.json
  An asset's pointer

  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).

• proposed/classifications/classifications.schema.json
  A record's classification references

  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.

• proposed/classifications/index.json
  Classification references, proposed for 0.2

  The index of the proposal classifications (Part II, 11, proposed for 0.2). It is a schema that asserts nothing: its member x-eik-proposal names the member the proposal adds to records of 0.1, by the records that carry it (* for every record: the project's project, a level, and each record of a record list), its path in the record and its schema, and says that the proposal adds no file. Schema paths are relative to https://openeik.org/schemas/0.1/.

• proposed/components/index.json
  Components, proposed for 0.2

  The index of the proposal components (Part II, 5, and Part IV, 7.6, proposed for 0.2). It is a schema that asserts nothing: the proposal adds rules of the compiler, a component's frame and its bodies that are boxes and prisms, and no file and no member; its member x-eik-proposal names the values of 0.1 the proposal deprecates, by their record, their path and what a writer writes instead. Schema paths are relative to https://openeik.org/schemas/0.1/.

• proposed/declared/index.json
  Declared geometry's nominal sizes, and a stair kit's and a prefabricated wall's frame, proposed for 0.2

  The index of the proposal declared (Part II, 12.1.1, proposed for 0.2). It is a schema that asserts nothing: its member x-eik-proposal names the frames the proposal gives the declarations of two categories' types, each by the category, its origin and its axes, and says that the proposal adds no file and no member. Schema paths are relative to https://openeik.org/schemas/0.1/.

• proposed/derived/bodies.schema.json
  A result of the derived layer, proposed for 0.2

  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.

• proposed/derived/index.json
  The derived layer, proposed for 0.2

  The index of the proposal derived (Part IV, 1.1.1 and 1.1.2, proposed for 0.2). It is a schema that asserts nothing: its member x-eik-proposal maps each result of the derived layer to its schema, by its path in a folder, an element's at .eik/derived/elements/<id>.json and a type's at .eik/derived/types/<id>.json, each id written as a path segment (Part III, 2), and by its key where results are handed from one tool to another, elements/<id> and types/<id>. A result is never in a version (Part IV, 1.1, rule 3). Schema paths are relative to https://openeik.org/schemas/0.1/.

• proposed/drawings/defs.schema.json
  Drawings: shared definitions

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

• proposed/drawings/derivation.schema.json
  Derivation

  What a revision was drawn from (Part XIV, 6.9, proposed for 0.2): 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.

• proposed/drawings/detail-item.schema.json
  Detail item, with provenance and anchors

  A detail item of a view (Part II, 10; drawings/detail-item.schema.json), with the two members Part XIV, 3 adds (proposed for 0.2): provenance, who made it (provenance.schema.json), and anchors, its references tried in order. The members that hold a feature and a position in the feature's frame are to be fixed with the reference implementation's anchor work (XIV.3.3): the anchor here is provisional, an element, a named feature and a position [s, t].

• proposed/drawings/index.json
  Drawings, proposed for 0.2

  The index of the proposal drawings (Part XIV, proposed for 0.2). It is a schema that asserts nothing: its member x-eik-proposal maps each kind of file of the proposal to its schema, as the schemas' index.json does for OpenEik 0.1, the drawing files by their format, and lists the references the proposal adds. Schema paths are relative to https://openeik.org/schemas/0.1/. The issued drawing's SVG is held to the allowlist svg-profile.json, OpenEik drawing SVG 0.1, which the validator and any host's parser share.

• proposed/drawings/issue.schema.json
  Issue

  A transmittal, the release of revisions, versions of the model or both to recipients for a purpose: drawings/issues/<issue>.json (Part XIV, 12, proposed for 0.2). 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.

• proposed/drawings/person.schema.json
  Person

  A person or an agent of the project's registry, project/people/<id>.json, list people (Part XIV, 5.1, proposed for 0.2), 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.

• proposed/drawings/profile.schema.json
  Drawing profile

  The project's drawing conventions, drawings/profile.json (Part XIV, 4, proposed for 0.2): 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).

• proposed/drawings/provenance.schema.json
  Detail item provenance

  Who made a detail item (Part XIV, 3.2, proposed for 0.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.

• proposed/drawings/read-set.schema.json
  Read set

  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, proposed for 0.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).

• proposed/drawings/register.schema.json
  Register

  Every snapshot ever taken of one drawing, oldest first: drawings/register/<drawing>.json (Part XIV, 11, proposed for 0.2), 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.

• proposed/drawings/review.schema.json
  Review

  A review round on one revision, as structured data: drawings/reviews/<review>.json (Part XIV, 13, proposed for 0.2). 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.

• proposed/drawings/revision.schema.json
  Revision record

  What an issued revision is, drawings/issued/<drawing>/revision.json (Part XIV, 8, proposed for 0.2): 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).

• proposed/drawings/sheet.schema.json
  Sheet

  A sheet, drawings/sheets/<id>.json (Part XIV, 2, proposed for 0.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.

• proposed/drawings/signoff-predicate.schema.json
  Sign-off predicate

  The predicate of a sign-off statement, https://openeik.org/attestation/drawing-signoff/v0.1 (Part XIV, 14.1, proposed for 0.2): 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.

• proposed/drawings/signoff.schema.json
  Sign-off

  One signer's action on one revision: drawings/issued/<drawing>/signoffs/<n>.json (Part XIV, 14.2, proposed for 0.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).

• proposed/drawings/statement.schema.json
  Sign-off statement

  The statement a sign-off's envelope carries: an in-toto Statement v1 (Part XIV, 14.1, proposed for 0.2). 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.

• proposed/drawings/svg-profile.json
  OpenEik drawing SVG 0.1

  The profile of an issued drawing's SVG (Part XIV, section 6, proposed for 0.2) 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.

• proposed/drawings/view-details.schema.json
  View detail chunk, with provenance and anchors

  One chunk of a view's detail items, in order: drawings/views/<kind>/<id>/details/<index>.json (Part III, 10), each item with the members Part XIV, 3 adds (proposed for 0.2).

• proposed/electrical/circuit.schema.json
  Circuit

  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, proposed for 0.2). 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.

• proposed/electrical/elements/cable.schema.json
  cable element

  An element record of category "cable" (Part XIII, 6, proposed for 0.2): the modelled route of one leg of a circuit, or a piece of it, in the systems discipline folder. A round run as Part IV, 12, its mep.size the cable's outer diameter. The pieces that name one to make up one leg.

• proposed/electrical/elements/cableCarrier.schema.json
  cableCarrier element

  An element record of category "cableCarrier" (Part XIII, 5, proposed for 0.2): a conduit, a tray, a ladder or trunking, in the systems discipline folder. A run as Part IV, 12: its profile, a height above its level for each point (mep.z), its width (mep.size) and, for a rectangular one, its height (mep.height).

• proposed/electrical/elements/electrical.schema.json
  electrical element

  An element record of category "electrical" (Part XIII, 2.1, proposed for 0.2): a device or a board, in the systems discipline folder. Its profile is two points, [at, toward]: at is the centre of its body in plan (a wall device's lies half its type's depth out from the wall face), and toward a point in the direction it faces. Its offset is the height above its level of a wall device's centre, a ceiling device's top face or a floor device's base. Its width and height are its type's.

• proposed/electrical/index.json
  Electrical installations, proposed for 0.2

  The index of the proposal electrical (Part XIII, proposed for 0.2). It is a schema that asserts nothing: its member x-eik-proposal maps each kind of file of the proposal to its schema, as the schemas' index.json does for OpenEik 0.1, names the members it adds to records of 0.1 with their schemas, names the values it adds to enumerations of 0.1 (values: each enumeration by its schema and its member's path in a record, which a validator with the proposal widens by the values listed, and only by them), and lists the references the proposal adds. Schema paths are relative to https://openeik.org/schemas/0.1/.

• proposed/electrical/types/cable.schema.json
  cable type

  A type record of category "cable" (Part XIII, 6, proposed for 0.2): the common type schema, and no payload of its own in this proposal. The cable itself (its type, conductors and area) is the leg's: the electrical.cable of the element the leg feeds, else its circuit's cable.

• proposed/electrical/types/cableCarrier.schema.json
  cableCarrier type

  A type record of category "cableCarrier" (Part XIII, 5, proposed for 0.2): the common type schema plus the payload cableCarrier, its kind and the sizes it comes in. A conduit is round; a tray, a ladder and trunking are rectangular.

• proposed/electrical/types/electrical.schema.json
  electrical type

  A type record of category "electrical" (Part XIII, 2.2, proposed for 0.2): the common type schema plus the payload electrical. Its width and height are the body's size across the direction it faces and vertically, and they set its elements' (Part XIII, 2.3, rule 3); depth is its size along that direction.

• proposed/electrical/view-lighting.schema.json
  A view's lighting

  A 3D view's lighting scene, its display.lighting (Part XIII, 4.3, proposed for 0.2): 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).

• proposed/envelope/answer.schema.json
  Command answer

  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.

• proposed/envelope/envelope.schema.json
  Command envelope

  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.

• proposed/envelope/index.json
  Commands with an envelope, proposed for 0.2

  The index of the proposal envelope (Part XVII, proposed for 0.2). It is a schema that asserts nothing: its member x-eik-proposal names the two messages the proposal adds, the envelope a writer sends and the answer a processor gives, with their schemas, and the precondition each command kind takes in an envelope. Schema paths are relative to https://openeik.org/schemas/0.1/.

• proposed/frames/index.json
  A door's and a window's own body, proposed for 0.2

  The index of the proposal frames (Part IV, 4.3.1, proposed for 0.2). It is a schema that asserts nothing: the proposal adds a rule of the compiler, a door's or a window's frame, its leaves or sashes and its glass, closed, and no file; its member x-eik-proposal names the members it adds to records of 0.1, a door family's leafMaterial and a family's profiles, each by its record, its path, the categories whose records carry it and its schema. Schema paths are relative to https://openeik.org/schemas/0.1/.

• proposed/frames/leaf-material.schema.json
  A door's leaf's material

  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.

• proposed/frames/profile.schema.json
  A profile of a door's or a window's members

  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.

• proposed/framing/index.json
  A framing family's parts, proposed for 0.2

  The index of the proposal framing (Part IV, 6.6, proposed for 0.2). It is a schema that asserts nothing: the proposal adds rules of the compiler, a beam's or a slab edge element's framing family evaluated with the element's parameters, each part that exists outlined, cut and carried across the family's plane, and no file or member of a model. Schema paths are relative to https://openeik.org/schemas/0.1/.

• proposed/framingLayout/battens.schema.json
  A batten layer's battens

  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.

• proposed/framingLayout/index.json
  Timber framing laid out, proposed for 0.2

  The index of the proposal framingLayout (Part IV, 7.4, proposed for 0.2). It is a schema that asserts nothing: its member x-eik-proposal names the members the proposal adds to records of 0.1, each by its record, its path in the record (* stepping into a list's items), the categories whose records carry it, and its schema, and says that the proposal adds no file. Schema paths are relative to https://openeik.org/schemas/0.1/.

• proposed/framingLayout/roof-opening-header.schema.json
  A roof opening's header

  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.

• proposed/grain/index.json
  A layer's grain and an element's main direction, proposed for 0.2

  The index of the proposal grain (Part II, 5.1.1, proposed for 0.2). It is a schema that asserts nothing: its member x-eik-proposal names the members the proposal adds to records of 0.1, each by its record, its path in the record (* stepping into a list's items), the categories whose records carry it, and its schema, and says that the proposal adds no file. Schema paths are relative to https://openeik.org/schemas/0.1/.

• proposed/grain/layer-grain.schema.json
  A layer's grain

  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.

• proposed/grain/main-direction.schema.json
  A slab's, a ceiling's, a foundation's or a roof's main direction

  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.

• proposed/grain/wall-main-direction.schema.json
  A wall's main direction

  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.

• proposed/ifc-read/index.json
  Reading IFC, proposed for 0.2

  The index of the proposal ifc-read (Part VIII, 2, proposed for 0.2). It is a schema that asserts nothing: its member x-eik-proposal names the members the proposal adds to records of 0.1, each by its record, its path in the record and its schema, and the message a reader hands with the records it writes: the bodies it read, as results of the derived layer in the form of the proposal derived. It adds no file. Schema paths are relative to https://openeik.org/schemas/0.1/.

• proposed/ifc-read/object-type.schema.json
  The user-defined type a record was read with

  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.

• proposed/ifc-read/predefined-type.schema.json
  The predefined type a record was read with

  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).

• proposed/ifc-read/shape.schema.json
  An element whose shape is given

  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).

• proposed/member/elements/member.schema.json
  member element

  An element record of category "member" (Part II, 6.2.1, proposed for 0.2): a brace, a strut, a tie or another linear member that is neither a beam nor a column, in the structure discipline folder. Its profile's two points, at its levelId and offset and at its end's, are the two ends of its reference line, the line through the middle of its section (Part IV, 6.5 and 6.7); they may be one point in plan, so that it stands plumb. It may carry roll, taper and joins, as a beam does, and none of endRise, turn, base and connection.

• proposed/member/index.json
  A member between two points, proposed for 0.2

  The index of the proposal member (Part II, 6.2.1 and Part IV, 6.7, proposed for 0.2). It is a schema that asserts nothing: its member x-eik-proposal names the category the proposal adds and its discipline folder, maps each kind of file of the category to its schema, as the schemas' index.json does for OpenEik 0.1, and lists the references the proposal adds. Schema paths are relative to https://openeik.org/schemas/0.1/.

• proposed/member/types/member.schema.json
  member type

  A type record of category "member" (Part II, 6.2.1, proposed for 0.2): the common type schema; it may carry a section (Part II, 5.2), as a beam's or a column's type does, its width across the member and its depth square to it, and no framing family.

• proposed/ownership/index.json
  Ownership and folders that follow owners, proposed for 0.2

  The index of the proposal ownership (Part XVI and Part III, 4.4, proposed for 0.2). It is a schema that asserts nothing: its member x-eik-proposal maps the proposal's one file to its schema, as the schemas' index.json does for OpenEik 0.1, names the member it adds to records of 0.1, and the folders of the owners' layout. Schema paths are relative to https://openeik.org/schemas/0.1/.

• proposed/ownership/owner.schema.json
  Owner

  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.

• proposed/ownership/owners.schema.json
  Owners

  project/owners.json (Part XVI, 2, proposed for 0.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.

• proposed/provision/elements/provision.schema.json
  provision element

  An element record of category "provision" (Part II, 6.10, proposed for 0.2): a void that a run asks of an element it crosses, its host, which the host's owner answers. Its profile is one point, its centre in plan, at its level's elevation plus its offset; width and height are its size across its axis, a round one's width its diameter. In 0.1's layout its folder is architecture.

• proposed/provision/index.json
  Provisions for voids, proposed for 0.2

  The index of the proposal provision (Part II, 6.10, proposed for 0.2). It is a schema that asserts nothing: its member x-eik-proposal maps each kind of file of the proposal to its schema, as the schemas' index.json does for OpenEik 0.1, and lists the references the proposal adds. Schema paths are relative to https://openeik.org/schemas/0.1/.

• proposed/provision/types/provision.schema.json
  provision type

  A type record of category "provision" (Part II, 6.10, proposed for 0.2): the common type schema; it carries no payload of its own. In 0.1's layout its folder is architecture.

• proposed/railings/index.json
  A hosted railing's profile, proposed for 0.2

  The index of the proposal railings (Part II, 12.2.1, proposed for 0.2). It is a schema that asserts nothing: its member x-eik-proposal names the member of a record of 0.1 that the proposal makes optional, and that it deprecates, each by its record, its categories, its path and when it applies, and says that the proposal adds no file and no member. Schema paths are relative to https://openeik.org/schemas/0.1/.

• proposed/review/host-keys.schema.json
  A host's keys

  The keys a host signs its receipts and its attestations of terms accepted with (Part XVIII, 5.6, proposed for 0.2), 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.

• proposed/review/index.json
  Review and issue, proposed for 0.2

  The index of the proposal review (Part XVIII, proposed for 0.2, from plan 688). It is a schema that asserts nothing: its member x-eik-proposal maps each kind of file of the proposal to its schema, and each statement to its predicate type and predicate's schema. A statement is a file of Part XIV, 14.2's format, its envelope and time-stamps as a drawing's sign-off has them. The members it adds to an issue are in proposed/drawings/issue.schema.json. Its member served names the file a host serves and no building holds: a host's keys, at a path on the host's origin (XVIII.5.6). Schema paths are relative to https://openeik.org/schemas/0.1/.

• proposed/review/issue-predicate.schema.json
  Issue statement predicate

  The predicate of a statement about an issue, https://openeik.org/attestation/issue/v0.1 (Part XVIII, 4.1, proposed for 0.2): 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).

• proposed/review/model-review.schema.json
  Model review

  A review round on one version of the model, in 3D: project/reviews/<review>.json (Part XVIII, 2, proposed for 0.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.

• proposed/review/receipt-predicate.schema.json
  Issue receipt predicate

  The predicate of a host's receipt of an issue, https://openeik.org/attestation/issue-receipt/v0.1 (Part XVIII, 5.2, proposed for 0.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.

• proposed/review/terms-predicate.schema.json
  Terms accepted predicate

  The predicate of a record that a person accepted named terms, https://openeik.org/attestation/terms-accepted/v0.1 (Part XVIII, 6.1, proposed for 0.2): 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.

• proposed/rooms/index.json
  A room's boundary, ceiling and quantities, proposed for 0.2

  The index of the proposal rooms (Part IV, 7.5, proposed for 0.2). It is a schema that asserts nothing: the proposal adds rules of the compiler, a room's boundary found from the walls, columns and room separators round its point, its ceiling under the slabs, ceilings and roofs over it, and its quantities, and no file or member of a model. Schema paths are relative to https://openeik.org/schemas/0.1/.

• proposed/site/index.json
  The site, proposed for 0.2

  The index of the proposal site (Part II, 2.2, proposed for 0.2). It is a schema that asserts nothing: its member x-eik-proposal names the member of a record of 0.1 that the proposal holds to a schema of its own in place of 0.1's (swaps), by its record, its path in the record and the schema, and says that the proposal adds no file. Schema paths are relative to https://openeik.org/schemas/0.1/.

• proposed/site/site.schema.json
  A project's site

  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.

• proposed/slopedSlab/index.json
  A slab on a sloped plane, proposed for 0.2

  The index of the proposal slopedSlab (Part II, 6.3.1 and Part IV, 4.2.1, proposed for 0.2). It is a schema that asserts nothing: its member x-eik-proposal names the member the proposal adds to records of 0.1, by its record, its path in the record, the categories whose records carry it, and its schema, and says that the proposal adds no file. Schema paths are relative to https://openeik.org/schemas/0.1/.

• proposed/slopedSlab/plane.schema.json
  A slab's plane

  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.

• proposed/stairs/index.json
  A stair's numbers and layout, proposed for 0.2

  The index of the proposal stairs (Part IV, 7.3, proposed for 0.2). It is a schema that asserts nothing: the proposal adds rules of the compiler, a stair's risers, going and location line, the treads and landings of a straight, L or U stair, and a cast concrete stair's flights and landings, and no file or member of a model. Schema paths are relative to https://openeik.org/schemas/0.1/.