# Part XVI. Ownership

*This part is a part of OpenEik 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 binds every conformance class it names (section 8; [Conformance](https://openeik.org/spec/0.2/conformance)). OpenEik 0.1 had it as a proposal, which no class of 0.1 required: a reader of 0.1 keeps `project/owners.json` as a kept file (Part III, 7). The steward decided its five questions on 18 October 2026, as the proposal had 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](https://openeik.org/spec/0.2/code-base#4.4) writes, with this part's section 3.1. `@openeik/tools` reads and checks the file for every model of 0.2, and for a model of 0.1 when asked, since 18 October 2026, and reads, writes and migrates the owners' layout 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 The parts it extends

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

- 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/0.2/project/owners.schema.json`](https://openeik.org/schemas/0.2/project/owners.schema.json):

| Member | | Meaning |
|---|---|---|
| `format` | required | `"openeik-owners/0.1"` |
| `parties` | required | 1 to 100 `{id, name, discipline?, organisation?}`: a party's id, a plain name of a lower-case ASCII letter and then up to 31 lower-case letters, digits and hyphens (`^[a-z][a-z0-9-]{0,31}$`); its name as people know it, a firm or a team; the discipline it works in, where it has one (rule 4); and the organisation it is, by its name and its domain (rule 5) |
| `rules` | required | 1 to 200 `{paths, owners, all?}`: the paths the rule covers, 1 to 50 globs (section 3); the ids of the parties that own them; and `all`, true where a change needs every owner's approval, absent or false where it needs one |

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

```json
{
  "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.

*Note (informative).* A file names no host's account ids and no organisation numbers: those are the host's, and change from host to host, while the model travels between them. The domain is what an organisation can prove to any host (section 7, rule 4).

## 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

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.

*Note (informative).* Rule 3 gives the rules that the reference implementation's owners file means: it writes one rule for the folders of 0.1 that each discipline places records in, with every party that may write the project as an owner of each, and where a folder holds two disciplines' records both own it, so that the structural engineer co-owns every wall and the ventilation engineer every terminal (its `ownersFile`, its work 670, step 8). Rewritten, each discipline owns its own folders, with the parties that lead. `@openeik/tools` implements the rewrite as `ownersForLayout`, which `openeik migrate` applies, and reports the parties and rules a person must look at.

## 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](https://openeik.org/spec/0.2/envelope#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](https://openeik.org/spec/0.2/review#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](https://openeik.org/spec/0.2/language#6.10)), a record of the asker's own.

*Note (informative).* Rule 5 was decided by the steward on 30 October 2026 (open questions, section 4, D9). The reference implementation's suggestions (its work 670, step 6.2, live since 26 October 2026) keep a change that a person's disciplines do not cover as a draft, sent to the parties that own its records, who accept it as one change; its exchange as BCF carries a suggestion's commands in a document of a form of its own, kept until this specification named one. By rule 5 that form is the envelope's.

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

*Note (informative).* `project` is a folder name that 0.1 gives, and so reserves (Part I, 11.1, rule 2). A writer of 0.2 writes the standard's own file into the standard's own folder, as Part XIII's note says of `project/circuits/`.

## 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 of 0.2 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 (Conformance, 1) holds changes for their approvals (section 4, rule 4).

*Note (informative).* For a model of 0.2, and for one of 0.1 with the proposal `ownership`, `@openeik/tools` also reads a record in either layout, writes the owners' layout, accepts each record in 0.1's folder or its owner's, and makes the change of layout with its owners file, `openeik migrate` (`migrateFiles`, `migrateFolder`, `ownersForLayout`), since 30 October 2026; `openeik diff` reports a record that only moved as moved, and `openeik merge --proposal ownership` finds what theirs needs where its records land in ours.

*Note (informative).* `@openeik/tools` implements the tool's part since 18 October 2026: `openeik check` checks the file of a model of 0.2, and `--proposal ownership` that of a model of 0.1 (`ownershipChecks`), `openeik owners <folder> [<path> …]` names the owners of paths (`ownersOf`), and `openeik diff` and `openeik merge` say which parties a change needs, by the file of the line it joins (`partiesNeeded`). EikHub, the host the reference implementation pushes to, holds changes for their owners since 23 October 2026 (section 4, rule 4): a proposal joins a building's main line once each owner it needs has approved it, and a push to the main line that changes paths owned by parties the pusher does not act for is refused, but for a push from the reference implementation, which joins and is marked as made without its owners. A party acts through the organisations the building's administrators link to it (section 7, rule 4).

*Note (informative).* What the guide [*Working across disciplines*](https://openeik.org/guides/disciplines.md) recommends beside it: each discipline works on a line of its own and writes in its own folders; `openeik diff` and `openeik merge` say which top folders a change touches, so that review sees when a line strays.

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

| Question | Decision | Decided |
|---|---|---|
| 36 | Where ownership is kept | in the model, `project/owners.json`, so that it travels and is versioned with the building, rather than on each host (section 2) |
| 37 | Who an owner is | a party named in the file, a firm or a team, whose accounts the host knows, rather than the people of Part XIV's registry (section 2) |
| 38 | How rules match | globs over leaf paths, and the last matching rule wins (section 3) |
| 39 | What ownership asks for | one owner's approval, or every owner's where a rule says `all`; a host SHOULD hold a change until then, and a tool SHOULD report it (section 4) |
| 40 | The datums | the file says who approves a change to the project, the levels and the grids; the example and the guide give them to every party, with `all` (section 2) |
| 52 | A party's discipline and organisation | optional: a discipline of eight plain values, and an organisation by its name and a domain of its own; neither decides anything alone, and a host links an organisation's accounts to a party only once the organisation has proved the domain and the building is shared with it or its administrator accepts (section 2, rules 3 to 5; section 7, rule 4) |
| 85 | Folders that follow owners | for 0.2, a record's folder is the discipline that owns it, by one set of rules, and an owners file names a party's discipline's folders by plain globs; the first version in the new layout moves every record once, needs the owners of all its paths and rewrites the owners file (Part III, 4.4; section 3.1) |