OpenEik 0.1 specification

Part XVI. Ownership

This part is proposed for 0.2. It comes from the work on disciplines of 18 October 2026, which the steward asked to be carried out: on a project with several firms, each firm owns the folders of its discipline, and a change to them needs its approval. It is not part of OpenEik 0.1, and no 0.1 conformance class requires it. A 0.1 reader keeps project/owners.json as a kept file (Part III, 7). The steward decided its five questions on 18 October 2026, as this part proposed them (open questions 36 to 40; section 9), and on 25 October 2026 a party's discipline and organisation (open question 52). On 27 October 2026 he decided that in 0.2 a record's folder is the discipline that owns it (open question 85), which Part III, 4.4 writes, with this part's section 3.1. @openeik/tools reads and checks the file when asked for the proposal, since 18 October 2026, and reads, writes and migrates the owners' layout with it since 30 October 2026 (section 8).

1. Status and scope

A building is one model, and on most projects several firms write it: an architect, a structural engineer, building services engineers, suppliers. Each discipline places its records in folders of its own: in 0.1 the folder follows who places a record (Part III, 4.1), and in 0.2 who owns it (Part III, 4.4). Each firm works on a line of its own and merges (Part VI, 5). OpenEik 0.1 does not say who may change what: any writer may change any record, and review decides (Part VI, 7).

This part says it in the model, as a code base's owners file does: one file names the project's parties and which of them own which paths. A change to an owned path needs an owner's approval before it joins the building's main line. The model states it; a host enforces it; a tool reports it.

What it leaves out:

• Accounts. A party is a name in the model, with the organisation it is where it says. Which people and accounts act for it is the host's to say (section 7, rule 4).
• Reading. Ownership says who approves a change, not who reads the model: a host's read scopes are its own.
• Signatures. An approval is the host's record. A signed statement about a drawing is Part XIV's.

1.1 At 0.2 this text moves into

• Part III: project/owners.json among the standard's files (1 and 3), and the folders that follow owners, section 4.4, in place of 4.1's table;
• Part VI: ownership in place of the plan of 7, and what a diff and a merge report (4 and 5);
• Conformance: what a host and a tool do;
• Security and privacy: who may change the file, and parties that are people.

2. The file

project/owners.json, in the stored form (Part III, 5), held to schemas/proposed/ownership/owners.schema.json:

The rules of a building where the architect leads, its folders those of their owners (Part III, 4.4):

{
  "format": "openeik-owners/0.1",
  "parties": [
    {"id": "arch", "name": "Example Architects", "discipline": "architecture",
     "organisation": {"name": "Example Architects", "domain": "architects.example"}},
    {"id": "struct", "name": "Example Structures", "discipline": "structure"},
    {"id": "hvac", "name": "Example Building Services"}
  ],
  "rules": [
    {"owners": ["arch"], "paths": ["**"]},
    {"owners": ["struct"], "paths": ["structure/**", "types/structure/**", "drawings/structure/**", "fabrication/**"]},
    {"owners": ["hvac"], "paths": ["ventilation/**", "types/ventilation/**", "drawings/ventilation/**",
                                   "plumbing/**", "types/plumbing/**", "drawings/plumbing/**"]},
    {"all": true, "owners": ["arch", "struct", "hvac"], "paths": ["project/project", "project/levels", "project/grids/*"]}
  ]
}

The architect owns every path that no later rule gives to another, project/owners.json among them; the structural engineer owns its discipline's folders, its bearing walls, slabs and roofs among them, and the building services engineer the folders of ventilation and of heating and plumbing; and a change to the datums, the project record, the levels and the grids, needs all three. No glob names a category: a party's folders say what it owns (section 3.1). The architects say which organisation they are; the building services engineer, who works in two disciplines, names none.

1. The file MUST be in the stored form, and MUST validate against its schema. A reader does not interpret a file of another format.
2. Party ids MUST be unique, and each id in a rule's owners MUST name a party of the file.
3. A party's name is how people know it; nothing is decided by it. Nor is anything decided by its discipline alone: a party owns the paths that the rules give it (section 3), whatever its discipline.
4. A party's discipline, where it gives one, MUST be one of architecture, structure, ventilation, plumbing (heating and plumbing), electrical, sprinkler, site and setup (the project's setup: its record, its levels and grids and its materials). The schema states this rule. It says what the party does, so that an application can offer it its discipline's records and folders. A party that works in two disciplines gives none, or is two parties.
5. A party's organisation, where it gives one, MUST be {name, domain}: the organisation's name as people know it, and an Internet domain name that is the organisation's own, in lower case: two or more labels, each of 1 to 63 ASCII letters, digits and hyphens that neither begins nor ends with a hyphen, at most 253 characters in all. The schema states this rule. The domain says which organisation the party is; the name is for people. Several parties MAY name the same organisation.

3. Paths and rules

1. A path is a leaf path of a version's tree (Part VI, 2): a record's path without .json (ventilation/level-0/duct/duct-hall-supply, project/levels), or a kept file's own path (acme/frame-a/model.json). Shard folders (~xx) are part of no path.
2. A glob matches paths segment by segment, / between segments: * stands for any part of one segment, and ** for any number of whole segments, none included. A glob MUST NOT be empty, start or end with /, or hold an empty segment or a segment . or ... A glob that ends in .json matches a path as it is written and as if the .json were not there, so that ventilation/*/duct/*.json names the records ventilation/<level>/duct/<id>, and project/owners.json the file.
3. The owners of a path are those of the last rule with a glob that matches it. A path that no rule matches has no owner.
4. The order of the lists, project/order, has no owner whatever the rules say: it is an index that follows the lists (Part III, 9).
5. project/owners.json is a path like any other. The rule that matches it says who may change ownership.

3.1 Rules on the owners' layout (proposed for 0.2)

In the owners' layout (Part III, 4.4) a record's folder is the discipline that owns it, so a party's paths are its discipline's folders, and an owners file names them by plain globs.

1. A party that works in a discipline owns its discipline's folders: <discipline>/**, types/<discipline>/** and drawings/<discipline>/**; and, of the folders that keep their place (Part III, 4.4, rule 6), fabrication/** if its discipline is structure, and project/circuits/** if it is electrical. A file SHOULD give each such party one rule of its discipline's folders, as section 2's example does, and SHOULD NOT name a category in a glob: which records a discipline owns is the layout's to say, and a glob that names a category gives a party some of another's records, or misses some of its own.

2. Nothing is decided by a party's discipline alone (section 2, rule 3): a party owns the paths the rules give it. A party that works in two disciplines owns the folders of both by one rule, or is two parties.

3. The change of layout. The version that moves a building's records to their owners' folders (Part III, 4.4, rule 8) rewrites the file in the same version, so that its rules name the new folders:

   • a glob that names a folder of 0.1's layout that the owners' layout leaves without records (systems/…, types/systems/…, drawings/views/…, drawings/sheets/…), or that names a category (a third segment other than * or ** under a discipline folder or types/, as architecture/*/wall/* or types/architecture/wall/*), is taken out of its rule, and a rule left without a glob goes; every other glob, rule and party stays as it was, in its place;
   • for each discipline, in the order of section 2, rule 4, whose parties owned a glob taken out, one rule of its discipline's folders (rule 1) is added at the end; its owners are those parties, and the parties that lead: those that name no discipline, own ** by a rule, and owned every rule that lost a glob, in the order of the file's parties.

   A party that owned a glob taken out, names no discipline and is given no added rule loses those paths: the version's maker gives it its folders by a rule, or the party a discipline, before the version joins. A rule with all that lost a glob gives the rules added no all, and its maker says where every owner's approval is still needed. A file that would be left without a rule is kept as it was, and its rules written by hand. A file in which no glob is taken out is kept as it is, so the rewrite changes a file once.

4. What a change needs

1. A change touches the paths of the records it adds, removes or changes, and of the kept files it adds, removes or changes, as a diff reports them (Part VI, 4). A record that moves, as a wall to another level, touches the path it leaves and the path it takes; so does one that only moves (Part VI, 4, rule 3), as every record the change of layout moves (Part III, 4.4, rule 8), and as a wall, slab or roof does when it is made structural, its type with it.
2. A change needs the owners of each path it touches: one of them where the path's rule has no all, and every one where it has. The ownership that counts is that of the line the change joins, as it stands before the change: a change cannot approve itself by changing project/owners.json.
3. A party approves a change through a person who acts for it, on the host. A change made by a person who acts for every party it needs is approved by being made.
4. A host that holds a building's main line SHOULD NOT let a change join it until the change has the approvals it needs, and SHOULD show, for each change, the parties it needs and those that have approved it. A host MAY ask the same for other refs.
5. A tool that compares two folders or versions, or merges them, SHOULD say which parties each change needs.

5. Merges and proposals

1. A merge of a line of work into the main line is a change. What it touches are the paths that the merged line changed against the base (Part VI, 5): the paths of the merge's records taken from that line, and of the records merged from both sides. A record's paths are those it leaves and takes in the line it joins: a line still in 0.1's layout that merges into one in the owners' touches the paths of its records' owners (Part III, 4.4), not the paths 0.1 gave them.
2. A conflict is settled by an owner of its path.
3. A proposal (Part VI, 8.7) is a change. What it touches are the paths of the records its commands would change.
4. A line of work that touches nothing owned by another party needs no one else: two disciplines that write in their own folders merge as they did in 0.1, and an approval is asked for only where one strays into another's paths.
5. A suggestion. A change that a party offers to records another party owns, for that party to make, is a proposal: an envelope in the mode propose (Part XVII, 6.3) makes it, a proposal file (Part VI, 8.7) or a host's proposal, and it is discussed as an item of a review (Part XVIII, 2). It has no form of its own. A void that a run asks of an element another party owns is no suggestion but a provision (Part II, 6.10), a record of the asker's own.

6. In 0.1

A 0.1 reader keeps project/owners.json as a kept file, and writes it back unchanged (Part III, 7). A 0.1 host does not enforce it, and a 0.1 merge does not report it.

7. Security and privacy

1. Ownership binds where a host enforces it. Anyone who can write a folder can change any file in it. Ownership holds on the lines a host keeps, where the host asks for the approvals before a change joins (section 4, rule 4).
2. Who changes ownership. The rule that matches project/owners.json says who may change it (section 3, rule 5), and section 4, rule 2 keeps a change from approving itself. A project SHOULD give the file to the party that leads it, so that no party can give itself another's paths.
3. Parties that are people. A party is usually a firm or a team. A party that is one person names that person, and so may a domain of one person's own: personal data, kept in every version that holds it (Security and privacy, 2.4).
4. A party's organisation proves nothing by itself. Anyone who may change project/owners.json can write any domain into it. A host MUST NOT let an organisation's accounts act for a party, nor give them any right in the building, because the file names the organisation's domain, unless the organisation has proved to the host that the domain is its own, and either the building is already shared with that organisation or an administrator of the organisation has accepted the link. The building's administrators on the host MAY undo the link, or link the party otherwise, at any time.

8. Conformance

A tool that implements this part reads project/owners.json, checks the rules of section 2 and section 3, rule 2, finds the owners of a path by section 3, and says which parties a change needs (section 4, rule 5). A validator reports a breach of those rules as an error. A host that implements it holds changes for their approvals (section 4, rule 4).

9. The decisions

The steward decided open questions 36 to 40 on 18 October 2026, each as this part proposed it, question 52 on 25 October 2026, and question 85 on 27 October 2026.