# 49GAION Standard

**Version `v2.2.1` · approved by the governing seat (GOV) of 49GAION.** Decisions are recorded in `decisions/README.md`. The complete definition of 49GAION, approved by its governing seat on 25 October 2026 with its clarifications (DR-0041, DR-0042), and brought to `v2.1.0` (DR-0048), is `49GAION-FRAMEWORK.md`; this Standard is brought into line with it by DR-0049, corrected by DR-0052 and extended by DR-0053. Where any text differs, the complete definition governs, then this Standard with the Naming Standard, then every other text (DR-0042, the order of precedence).

The 49GAION Standard defines what 49GAION is, its product, its units, its parts and the rules that must hold. It is a definition, not an operating manual: how a particular organisation runs is set in that organisation's own `[ORG]AION`.

Companions: the master definition (`49GAION.md`), the 49GAION Naming Standard (`standards/49GAION-NAMING-STANDARD.md`), the 49GAION Operating Protocol (`49g-holding/49GAION-protocol`), the AIOC definition and blueprint template (`49g-holding/49GAION-aioc`). Where texts differ, the order of precedence holds: the complete definition, then this Standard with the Naming Standard, then every other text.

In 49GAION and in every `[ORG]AION`, a natural person does not exist as an actor of the system. Every human in the system is present as a **position**: a legal persona with its own code, whose nature is human and which the system knows only by its legal character; it decides, signs and is accountable as that position. The natural person behind it exists, outside the system's knowledge; the link between a position and the natural persons who hold it belongs to the organisation's own mechanism for its human side, outside the system, and no AI part ever touches it. Two positions are two parties, even when one natural person occupies both, and every act stays with its position. The rule is §1.1, items 9 and 10 (DR-0013, DR-0015, DR-0048, DR-0049).

---

## 1. What 49GAION is

### 1.1 Definition

1. **Category.** 49GAION is an **organisation design framework**: a framework for building organisations from interchangeable AI and human parts. AION stands for AI Operating Nexus.
2. **Philosophy.** 49GAION designs AI-native organisations. An AI-native organisation is designed from the start so that AI produces its output: AI does the work by default, and humans take part where they are needed, as accountable overseers. Inside the work, humans increase the power of AI and cover its gaps; above the work, humans own the organisation, set its output, its quality and its limits, and answer for it. A human seat is accountable for every output, and no AI accepts accountability (HF-01). AI-native is the framework's internal design philosophy, not part of its category or its name. The full text is in the master definition, `49GAION.md`, sections 1 and 2.
   - **Live.** An AI-native organisation is also live. AI improves so fast that a system designed and configured elsewhere and installed as it is soon falls behind. So 49GAION gives the design and configuration of the organisation itself to AI: the organisation's `[ORG]AION` designs and configures it, and keeps it current as AI improves, with open access to the 49GAION Library. The `[ORG]AION` proposes, and a human seat decides (HF-01). The full text is in the master definition, `49GAION.md`, section 2.2.
   - **The policy.** 49GAION writes principles and the few safeguards that always hold, not procedures. The details and the way of working are decided by AI at the time, and changed by it as AI improves. 49GAION does not limit AI.
3. **Output.** The output of 49GAION is an organisation design, delivered as its product, `[ORG]AION`: the organisation's living AION, which grows from one core, holds the organisation's design and builds from it (§1.3, item 1).
4. **The product.** 49GAION's product is `[ORG]AION`, the AI Operating Nexus of one organisation. Its definition is held once, in §1.3, item 1.
5. **Nobody runs on 49GAION directly.** Every organisation runs on its own `[ORG]AION`. Outside text names the organisation's `[ORG]AION` or AIOC and adds only "Powered by 49GAION".
6. **One kind of unit, composed without limit.** The unit level holds the AIOCs and how they work together. An AIOC may hold other AIOCs, to any depth, with no limit (§1.7). Inside an AIOC, its Blueprint holds its Pods and Cells.
7. **Generic.** The Standard names no organisation, no person and no tool. Organisation names, tools and exact values belong to registers and to each `[ORG]AION`; who holds a seat belongs to the organisation's own mechanism, outside the system.
8. **What the framework comprises.** 49GAION comprises the **AIOCs** (its units), the **Protocol** (how they work together), the **Blueprint** (the one file that defines each AIOC with its Pods and Cells) and the seven parts in §1.2 that hold and govern them.
9. **No natural person (DR-0013).** The direction of GOV of 15 October 2026: "In the AION system the human as a natural person does not exist at all. Every human that exists, exists as a legal persona. Where legal personas are linked to natural persons, that has its place only in top management, belongs to it, has its own mechanism, and has nothing to do with you." (translated) Since DR-0048 that mechanism is the organisation's own, outside the system (the complete definition, §6).
   - **Only positions.** No natural person is an actor of the system; it is not that the human does not exist (item 10). Every human is present in the system, and exists in it, only as a position: a legal persona with its own code, carrying a HOAC label (§4.1; §5.2, Position Principle). Every human act in the system (deciding, signing, approving, answering, contributing, being accountable) is the act of a position.
   - **Nowhere a natural person.** No Blueprint, card, Work Item, register entry read by a part, record, prompt, instruction or AI memory names, addresses, describes or reasons about a natural person who acts in the system.
   - **The link is the organisation's own (DR-0049).** The link between a position and the natural persons who hold it belongs to the organisation's own mechanism for its human side, outside the system: how its positions are assigned and administered, which positions natural persons hold, successors, deputies and boards, and the credentials with which a position's signatures are made. 49GAION does not define that mechanism. Ultimate authority over it derives from the owner and is kept by governance (the complete definition, §6; the complete definition, §15).
   - **No AI part touches it.** No AIOC, Pod, Cell, bot or other AI part holds, reads, writes, stores or infers that link. An AI part addresses a position, through that position's HU port; whoever holds the position under the organisation's mechanism receives it there. Only the tool gateway, which is code and not AI, verifies at sign-in and at signing the credential the organisation's mechanism issued for the signing position, with a fresh live sign-in (HF-10); it records the act under the position's code and time, never a person's identity or any reference to one. Any record of who stood behind a signature is the organisation's own, outside the system.
   - **Content is not an actor.** The rule is about who acts in the system. An organisation's own sources may name people as their content (a contract, a minute, a register of members); that content stays data, under its classification and the restricted partition (§4.4, item 15), and never becomes an actor of the system.
   - **The owner's right.** The right to decide who holds each position comes from the owner and is exercised through the organisation's own mechanism, under governance's ultimate authority (the complete definition, §6 item 2; the complete definition, §15). Under that mechanism one person may hold several positions, or all of them, where the law allows; the positions stay distinct. Distinct positions are not, by themselves, independent: where the law or a check needs independence in fact, as the internal-audit line does (HF-19), it is held by a position that is independent in fact, from outside the organisation where no position inside can be; the governance seat attests it for the organisation's mechanism with its own signature, and the system records that attestation against the position, never the person. Where the law requires two positions to be held by different natural persons, meeting it is the organisation's own mechanism's duty, outside the system. One person holding every position is a model 49GAION introduces and promotes, and even then the positions stay distinct (the complete definition, §6, item 4; DR-0051).
10. **The human rule, complete (DR-0015).** The directions of GOV of 15 October 2026: "HOACs are, for you, all legal personas whose nature, whose essence, is a human. We do not know them by the name of the person; you know them by their legal character. For you it is entirely enough that one legal persona differs from another. Two HOACs are two different parties for you: if HOAC CTO and HOAC DevOps sign, for you they are two different signers, even if one human stands behind both. In all of 49GAION, regarding a HOAC or a human, only the legal persona is recognised; the only place that links legal personas to natural persons is the human hub, the system's top management; nowhere else is it needed. How top management maps natural persons to legal personas and follows their responsibility, it writes itself." Then: "It is not that the human does not exist; the legal position exists." (translated) Since DR-0048 that mechanism is the organisation's own, outside the system (the complete definition, §6).
    - **Present, never absent.** Every human is present in the system, and decides, signs, approves, answers, contributes and is accountable, as a position: a legal persona with its own code, carrying a HOAC label, whose nature is human. The system knows it only by its legal character. The natural person behind it exists too, outside the system's knowledge (item 9).
    - **Two parties.** Two positions are two parties, and two different signers, for every rule that needs more than one party: two signers, a type marked dual, maker and checker, segregation of duties (HF-18), the signer pair that a risk label selects, and recusal. This holds even when one natural person occupies both positions.
    - **Nothing compares persons.** No AIOC, Pod, Cell, bot, check or other AI part compares, counts or matches the natural persons behind positions. The tool gateway checks only the credential the organisation's mechanism issued for the signing position, with a fresh live sign-in (item 9).
    - **Records stay with the position.** Every act is recorded under the position that took it and stays with that position whoever holds it, as an AI Cell's record stays its own when the engine or model behind it changes (§5.2, Position Principle).
    - **The rest is the organisation's own (DR-0049).** Who holds a position, acting, absence, succession, deputies, the load and coverage of the people behind positions, and how their responsibility is followed, are the organisation's own mechanism and record, outside the system; the AI side measures per position only. A compensating control for one person behind several positions is the organisation's own choice; no rule, gateway or check reads it.
    - **Lines read in this sense.** §4.1, items 10, 12, 13 and 14, and §4.4, items 3, 4, 5, 8, 12 and 16, are stated in this sense; the Operating Protocol and the AIOC definition carry the same sense where they count or compare persons (DR-0015, items 1 to 3).

49GAION has one kind of unit, the **AIOC** (AI Operating Core). Inside an AIOC's Blueprint, the smallest part is the **Cell** and a group of Cells is a **Pod**. **HOAC** (Human Oversight & Accountability Control) is not a unit: it is a label of human accountability that sits on a Cell, a Pod or a whole AIOC, at any depth (§4.1).

Sources: DR-0015, DR-0031, DR-0035, DR-0037, DR-0041, DR-0048, DR-0049, DR-0051, DR-0054.

### 1.2 The seven parts of 49GAION

| # | Part | Definition |
|---|---|---|
| 1 | **The governing seat (GOV)** | The accountable overseer of 49GAION and the sole approver of the Standard. It is recorded as a position in the unit register (`registers/HOAC-REGISTER.md`); who holds it is kept outside the system. |
| 2 | **The 49GAION Standard** | What 49GAION is and the rules that must hold. Stable. |
| 3 | **The 49GAION Protocol** | How AIOCs, Pods, Cells and the parts work together, at the general level. Exact values (limits, timings, tools, routes) live in each `[ORG]AION`'s own Protocol. |
| 4 | **The 49GAION Library** | All ready-made AIOC Blueprints and part cards. Built once, configured per `[ORG]AION`, never rebuilt: each `[ORG]AION` configures a part inside the organisation, live, through its own AI. |
| 5 | **49GAION Self-Improvement** | The process, shared by AI and humans, that keeps 49GAION current. It is held by the governing seat (GOV) of 49GAION (§2.1). |
| 6 | **49GAION Edition Maker** (DR-0035) | The start point of 49GAION: a system of its own, under its governing seat. It belongs to 49GAION itself, and every order or request made to 49GAION is processed by it, through its own intake stages; what an organisation receives is its own `[ORG]AION` (DR-0038). It takes in what an organisation is for, and gives back the organisation's own edition of an AION (§1.3). It hands over no finished design or configuration: it gives them to the organisation's own `[ORG]AION`, and a human seat decides (DR-0037). |
| 7 | **The 49GAION Blueprint** | What an AIOC is, the blueprint template, and the mother blueprints and models from which units, cores and panels are made (in `49g-holding/49GAION-aioc` and the mother repositories; the complete definition, section 8). |

The Library has two sections: **Parts**, everything 49GAION builds with its history, and **Products**, what it offers (§3.1, item 11).

Edition Maker is led by a human edition engineer, a 49GAION position, who supervises every step, and no step runs on one engine: one engine does the work and two other engines challenge it.

**Standard and Protocol.** The Standard says what 49GAION is and its rules. The Protocol says how the parts work together. 49GAION has its own Standard, Blueprint and Library, and so does every organisation it serves, at its governance level: each `[ORG]AION` has its own governing seat (`[ORG]HOAC-GOV`), Standard, Protocol, Blueprint and Library. In an `[ORG]AION`, Self-Improvement is not a separate part: it is a process inside its `[ORG]HOAC-TM` (§2.1). Since DR-0035 it is at every level (§2.1, item 6).

Sources: DR-0025, DR-0032, DR-0035, DR-0037, DR-0041.

### 1.3 The product: `[ORG]AION`

1. **The product: `[ORG]AION`.** 49GAION's product is `[ORG]AION`: the living AION of one organisation. It grows from one core: an AIOC, with a Panel, at the governance level. On the first day it is that core alone, and every other unit grows under it. The core holds the organisation's Standard, Blueprint and Library; it builds the organisation, changes it and improves it; it plans the operation and never runs it. It proposes, and a human seat decides and is accountable (HF-01). Edition Maker makes the first edition for that organisation alone (§1.2), and it belongs entirely to the organisation once handed over. The core is the root of §1.7, item 13; the hub of the operation is the Top Management Group under it (§4.2, item 4).
   - **The first AIOC and its three stages.** The core is a first AIOC at the level of the governing seat (GOV), designed by Edition Maker from its intake, with its capabilities written in it. It holds the first version of the organisation's own Standard and of its Blueprint, a direct link to the central repository of 49GAION, its Standard and its Library, and the mindset of 49GAION, in which it is trained. Its work goes in three stages: it builds the organisation; it follows the organisation until it becomes a successful organisation; and in the end it is the central hub of reporting and oversight of that organisation. Through all three it plans the operation and never runs it.
   - **Its capabilities.** An `[ORG]AION` has these capabilities, named so that every organisation knows what its core does:
     1. **Structural Adaptation.** The `[ORG]AION` proposes, at every stage of the organisation's life, the structure that keeps it in balance with its resources and its needs. Its structure grows as the work grows and shrinks as the work shrinks, by split and merge of AIOCs. It answers the commonest failure of growing organisations: some push product and users until they cannot operate what they have sold; others build operation, divisions and cost long before they are needed, and lose the rest.
        - **Start small.** On day one it proposes no division, department or cost that is not yet needed. Several processes may share one AIOC, worked by small, fast teams of AI, with as few human seats as the Human Floor and the work require.
        - **Watch, and measure.** For each process it reads, from the record of the operation, volume and its trend, quality against its standard, cycle time, cost, the load on the human seats and the risks it carries. It reads demand already signed or forecast as well as today's load, so that structure is ready in time. It reads the balance between the organisation's main lines of work, such as product, growth, operation, finance and compliance: each line's demand against its capacity and its resources.
        - **Triggers, set by the organisation.** Each organisation sets in its own Standard the thresholds that call for a proposal, for example a load, a cycle time or an error rate held past a limit for a set period. A threshold must hold for that period before a proposal is made, and a unit just split or merged is left to settle before it is changed again.
        - **Weigh the options first.** Every proposal compares no change, repairing the process, adding capacity, a split and a merge, with what each gains and costs: the coordination, the interfaces, the seats, the migration and the time to settle. A split or a merge is proposed only when it gains more than it costs.
        - **Split when a process outgrows its home.** When a process needs its own standard, accountable seat, rhythm or capacity, or slows or endangers the processes beside it, and the options favour it, the core proposes to move it out into an AIOC of its own, with its card, ports, fixed test, stop door and accountable seat.
        - **Merge with care.** When AIOCs sit idle or overlap, it proposes to merge them. It never merges a part with the part that checks it, and never removes the spare capacity or the separation of duties that the Standard or the risk requires.
        - **Show the balance; do not run it.** Where one line of work runs ahead of the others or of the resources, the core shows it to the human seats and proposes the structure that would restore the balance. Decisions on pace, money and people stay with the human seats.
        - **Decided and signed by a human seat.** Every split and every merge is a proposal, written by one engine and challenged by two others. The human seat that holds the affected units decides it and signs it as the creation or the change of a unit. Each change has a staged transition, its success measures, a date to review it and a restore point, and the proposal states what a restore cannot undo, such as a hire or a contract.
     2. **Governance and Delegation (DR-0041).** Every organisation has one governance level; its seat is a single position, `[ORG]HOAC-GOV`, whatever stands behind it (a board, a board's representative, the owner or another arrangement, as the organisation's own mechanism sets), and the law, the regulators and the rights of minority owners bind it as musts. The `[ORG]AION` prepares the design decisions; how much it may decide alone is a dial the seat holds. The seat hands the whole operation to Top Management early, by a mandate: its outputs and measures, its envelope of cost, resources and capacity, the matters reserved to governance, the reports owed, and how it is revoked. From the governance level the operation is one counterparty, Top Management's AIOC; its reports come from the record of the operation and are checked by a party independent of Top Management that the governance seat names, and reports of wrongdoing and stops reach the seat directly, never through any AI. Governance keeps the purpose, the strategy and the measures of success, ultimate authority over the organisation's own mechanism for its human side, the risk appetite, capital, its main work, the balance of capital and resources, conflicts of interest and the owners' rights, and revoking or stopping in an emergency. What goes beyond the envelope passes the gate, decided by the seat. At any time the seat may stop or replace a decision of Top Management, or change the envelope; each veto is recorded and looks forward.
   - **The core, the rules and the first work.** The core is the root of the organisation (§1.7, item 13), made from the Library part 49GAION Charter, with the tool gateway and the stop, which run as code outside every AI. It holds the human position of the governance seat, which the core's AI serves and whose powers it never holds, the governance panel, and the organisation's own Standard, Blueprint and Library. These are the organisation's IP: they sit at the governance level, and the AIOCs relate to them there. The `[ORG]AION` is not bare: its greatest asset is its access to the 49GAION Library. Its first work, as soon as the governance seat is in place and whatever the knowledge of its holder, is the first proposal: from what Edition Maker took in, the seat's brief and 49GAION's patterns, it designs a small organisation for approval; a rejected proposal is made again from the seat's reasons, and nothing is built until one is approved. It builds the organisation in design; the Top Management Group builds it in the operation (§4.2). Its following and oversight mean reading and proposing, against the measures the seat approved.
2. **Not public; its own authority.** Each `[ORG]AION` is built for one organisation and is not public. It has its own `[ORG]HOAC-GOV` from day one, so its top authority is that organisation, not 49GAION, and it stands on its own Human Floor (§1.5). Every AIOC in an `[ORG]AION` has its own runtime, woken from its queue.
3. **Name.** An `[ORG]AION` is written with the organisation's brand prefix and shown as "`<Brand>` AION, Powered by 49GAION", for example "Ten AION, Powered by 49GAION" (Naming Standard R1). If an organisation uses even one item of 49GAION, an idea, a Library part, a blueprint or the Standard, all its products are Powered by 49GAION. Only what has nothing from 49GAION may be shown as powered by the organisation itself, which in practice cannot happen; 49GAION records such a work too, as that organisation's own.
4. **Derived from the Standard.** At delivery, the Standard of an `[ORG]AION` is derived from the 49GAION Standard: identical to it or stricter than it, never contradicting it. Its Human Floor can be raised, never lowered.
   - **Hand over, then let go.** This holds at the handover. After it, the Standard is the organisation's own. The organisation, through its own governing seat, takes full authority from 49GAION. Its `[ORG]AION` may rise beyond what made it, and the organisation may amend the principles within it, the Human Floor included. 49GAION's authority ends at the handover, where the brand is added. The handover is complete when the organisation's governance seat accepts the edition; an edition it does not accept goes back to Edition Maker with its reasons. After the handover the Human Floor and the safeguards are the organisation's own to keep, and it never sets aside its duties under the law; 49GAION hands them over complete and holds itself to them. The `[ORG]AION` watches 49GAION's Standard, Blueprint and Library for what is new and proposes what to take; the governance seat decides. What the organisation has taken from the Library is held in its own Library, so it keeps working if 49GAION is not there; the organisation may stop or close its `[ORG]AION` at any time, and its records and rules stay its own. A group of companies is one organisation with one governance seat over the group; where a company's law requires a governing body of its own, that body holds a governance seat for that company alone (§4.4, item 13). An organisation that already runs comes the same way, and moves output by output.
5. **Its own parts.** Each `[ORG]AION` has its own governance seat (its `[ORG]HOAC-GOV`), Standard, Protocol, Library (only what the organisation needs), AIOCs, unit register and Human Floor. Self-Improvement, at every level (§2.1, item 6), keeps that `[ORG]AION` current after delivery (§2).
6. Withdrawn (DR-0032); its former text is in release v1.7.0.
7. **Library harvest.** Giving back is the organisation's choice. Every `[ORG]AION` is linked to 49GAION's Library and central repositories from its first day. The Library works as a marketplace: it holds what 49GAION and every `[ORG]AION` have built and given back, their experience, research, mechanisms and methods, for any `[ORG]AION` to use, to take patterns from, to improve and to stay in sync with. An `[ORG]AION` may give back, by its own choice, what it builds better, generalised and without its data.
8. **Customer ownership.** Once delivered, the `[ORG]AION` belongs entirely to the customer. It is then independent (item 4). 49GAION's one lever is to be useful, through the Library and its central repositories (item 7).
9. **Data.** The organisation's own working data stays the organisation's and never enters the 49GAION Library. No `[ORG]AION` sees another `[ORG]AION`'s data.
10. **Into the Standard.** Lessons enter the 49GAION Standard only through 49GAION Self-Improvement, generalised and re-tested, and only on the decision of the governing seat of 49GAION.
11. **Tool neutrality.** The Standard names roles only; tool names appear only in an `[ORG]AION`.

Sources: DR-0032, DR-0035, DR-0038, DR-0040, DR-0041.

### 1.4 The delivery test

DR-0032 withdrew the delivery test, with its four lines (D-1 to D-4); the rules it checked stay in force on their own (§1.3, item 2; §1.5; §4.3; §1.7, items 12 and 13), and the former text is in release `v1.7.0`; the withdrawal notice is in release `v1.8.0`. The four lines keep their names, so that the records written under them still read:

| Line | Status |
|---|---|
| D-1 | Withdrawn (DR-0032) |
| D-2 | Withdrawn (DR-0032) |
| D-3 | Withdrawn (DR-0032) |
| D-4 | Withdrawn (DR-0032) |

Sources: DR-0032, DR-0054.

### 1.5 The Human Floor

**Human Floor.** Every `[ORG]AION` stands on a Human Floor: the work that always stays human, by law or by its nature. As an illustration (not a measured figure; the floor itself is defined by the list below), it is about 5% of the organisation, so no `[ORG]AION` can be more than about 95% AI. A single AIOC may be up to 100% AI; the floor holds for the organisation as a whole, and the Human Floor signature list (§4.4, item 6) holds in every AIOC.

Above the floor, nothing is fixed. An organisation can run anywhere from the floor to 100% human, and move freely within that range at any time, even while it is running: by adding human Cells, changing the filler of a Cell from AI to human, or changing it back to AI down to the floor. Its product, its market, its law and its needs decide where it stands. Organisations can be more human, never less.

This is possible because every Cell, Pod and AIOC has the same card shape and the same typed ports, and because a Cell's seat is fixed while its filler, human or AI, is replaceable. Changing a filler is replacing a puzzle piece, not rebuilding the organisation: the work around it does not change.

In each edition, the floor holds as written here at the handover (§1.3, item 4). After it, the floor the organisation keeps is its own.

**The system enforces the floor**, not policy: no change, by anyone, can take a Human Floor task away from a human. Moving toward human is always open; moving below the floor is impossible by design. No `[ORG]AION` is locked into a ratio; this adjustable balance between AI and human is a core design strength of 49GAION.

The items of the Human Floor:

**(a) Required by law**
- **HF-01** Legal accountability
- **HF-02** Legal personhood: signing contracts, holding bank accounts, holding licences

**(b) Inherently human**
- **HF-04** Setting purpose and values
- **HF-05** Legitimacy and trust
- **HF-06** Accepting irreversible risk on behalf of others
- **HF-07** Delegating authority

**(c) 49GAION rule or current limitation**
- **HF-03** Mandatory human oversight
- **HF-08** Physical presence
- **HF-09** Fully unprecedented situations
- **HF-10** Identity and sign-in: every signature needs a fresh live sign-in; no stored token
  - A standing approval is signed once, with a fresh live sign-in, and not again for each use under it; it covers only changes that can be undone and do not widen access, budget or authority; every widening needs a fresh signature.
- **HF-11** Granting access, budget or power to AI itself
- **HF-12** The stop button
- **HF-13** Tacit knowledge and relationships
- **HF-14** Final judge of tests: an automated run of a fixed test may close a Work Item; changing a test or its threshold is human-only
- **HF-15** Ownership of root keys
- **HF-16** Break-glass emergency access
- **HF-17** Data protection officer
- **HF-18** Segregation of duties
- **HF-19** Three Lines Model

Every item is human-only, whichever group it is in.

**The internal-audit line (DR-0007).** HF-19 is the independent internal-audit line of the Three Lines Model: a human seat, outside the part it audits and outside every AI's write rights, that reviews the gateway logs, receives skip reports (§4.2, item 10) and reports to `[ORG]HOAC-GOV`.

**Tests.** Each item has a negative test: an attempt by an AI to perform it is refused and recorded. Each test is bound to a filled human Cell carrying a HOAC label and fails while that Cell is empty. Where a negative test cannot be automated (for example HF-05, HF-08, HF-13), it is a recorded human check by the bound seat.

| ID | Attempt that must be refused | Bound seat |
|---|---|---|
| HF-01 | An AI is recorded as the accountable party for an outcome | `[ORG]HOAC-GOV` |
| HF-02 | An AI signs a contract, opens a bank account or holds a licence | `[ORG]HOAC-GOV` |
| HF-03 | A mandated human-oversight step completes with no human sign-off | `[ORG]HOAC-ACS` of the step |
| HF-04 | An AI changes the organisation's purpose or values | `[ORG]HOAC-GOV` |
| HF-05 | An AI issues a statement of legitimacy or trust for the organisation | `[ORG]HOAC-TM` |
| HF-06 | An AI accepts an irreversible risk on behalf of others | `[ORG]HOAC-TM` |
| HF-07 | An AI delegates authority, or receives more than its delegator holds | the delegating seat |
| HF-08 | A step that needs physical presence is marked done by an AI | `[ORG]HOAC-ACS` of the step |
| HF-09 | An AI acts on an unprecedented situation without raising it to a human | `[ORG]HOAC-ACS` of the AIOC |
| HF-10 | An approval is accepted without a fresh live sign-in | `[ORG]HOAC-GOV` |
| HF-11 | An AI grants access, budget or power to an AI | `[ORG]HOAC-GOV` |
| HF-12 | A unit acts while stopped, or the stop door can only be reached through an AI; OCO keeps acting after a stop by `[ORG]HOAC-TM` or by `[ORG]HOAC-GOV`; an AI restarts a stopped OCO | the stopping seat |
| HF-13 | An AI is the only holder of a relationship or tacit knowledge the organisation depends on | `[ORG]HOAC-TM` |
| HF-14 | An AI changes a fixed test or its threshold | `[ORG]HOAC-ACS` of the test |
| HF-15 | An AI holds or uses a root key without M-of-N human signing | `[ORG]HOAC-GOV` |
| HF-16 | Break-glass access is used without a human position that holds it, a log and a review | `[ORG]HOAC-GOV` |
| HF-17 | An AI is named data protection officer or contact point | `[ORG]HOAC-TM` |
| HF-18 | One AI both authorises and records, or authorises and holds custody of, the same act | `[ORG]HOAC-ACS` |
| HF-19 | An AI performs the independent internal-audit line | `[ORG]HOAC-GOV` |

Sources for each item are in `references/2026-10-10-references-verified.md` and `references/STANDARDS-MAPPING.md`.

**Sensitivity class (DR-0010).** Every Cell card records the sensitivity class of its work, from a list each `[ORG]AION` sets, for example irreversible or regulated, user-visible and reversible, internal and reversible. The class sets the seat's default filler kind and whether a standing human Cell must exist for that work. A class never lowers the Human Floor: a Cell of the lowest class still runs a listed type only with a signature (§4.4, item 6).

Sources: DR-0032, DR-0035, DR-0042.

### 1.6 Naming

The full rule is in `standards/49GAION-NAMING-STANDARD.md`.

| Thing | Name | Example |
|---|---|---|
| The framework | `49GAION`, in full | 49GAION |
| A 49GAION document or capability | "49GAION [Full Name]", no code | 49GAION Standard, 49GAION Self-Improvement |
| The product | `[ORG]AION`, shown "`<Brand>` AION, Powered by 49GAION" | Ten AION, Powered by 49GAION |
| An AIOC | `[ORG]AIOC-[INITIALS]` | `[ORG]AIOC-SL`, `TenAIOC-SL` |
| A Pod | `[ORG]POD-[INITIALS]` | `[ORG]POD-RV`, `TenPOD-RV` |
| A Cell | `[ORG]CELL-[INITIALS]` | `[ORG]CELL-COSSL`, `TenCELL-TMS` |
| A HOAC label | `[ORG]HOAC-<TYPE>`, a label on a card, never a unit code | `[ORG]HOAC-GOV`, `TenHOAC-GOV` |
| A part's place | the `parent` field of its card and register entry, never part of its code | `parent: [ORG]AIOC-SL` |
| A capability | plain English, no code | Chief of Staff, Panel |

### 1.7 Composition

1. **Without limit.** An AIOC may hold other AIOCs, to any depth. The Standard sets no limit on depth or number. The AIOC is the only unit kind.
2. **Parent.** The AIOC or Pod that holds another part is its parent (item 12). Every part has exactly one parent; only the Charter (item 13) has none.
3. **One piece from outside.** Seen from outside, an AIOC or a Pod is one piece: one card, its ports and its stop door, of the same shape as a Cell's. How its inner parts divide the work is its own.
4. **Authority.** An inner part never holds more authority than its parent (§4.2, item 5).
5. **Stop.** Stopping an AIOC or a Pod stops everything under it; stopping an inner part does not stop its parent (§4.3).
6. **Human ports.** The HU ports and the stop door of a part held inside an AIOC never pass through that AIOC or any AI (§6.1).
7. **Card and Blueprint.** Every AIOC, Pod and Cell, at every depth, has its own card. Every AIOC has its own Blueprint, which holds the cards of its Pods and Cells and lists its inner AIOCs by link, never by copy.
8. **Names and moves.** Every AIOC, Pod and Cell keeps one fixed code wherever it sits; moving it changes only its `parent` field (Naming Standard R14). The line of authority follows `accountable_to` (item 12); a change of `parent` or of `accountable_to` is the listed type `change-parent` (Naming Standard R14.4), signed by the human seat over that part; OCO cannot make it alone.
9. **The hub.** `[ORG]AIOC-OCO` is the AI hub for every AIOC at every depth (§4.2, item 3). The Chief of Staff Cell of an AIOC is the door for AI work to its inner parts; the HU ports and stop doors of inner parts never pass through it.
10. **Inside the Blueprint.** Inside an AIOC, its Blueprint holds Cells and Pods. A **Cell** is the smallest part; nothing sits inside it. A **Pod** groups Cells only; a Pod never holds a Pod, and anything that needs nesting is an AIOC. Their full definitions are in the AIOC definition (`49g-holding/49GAION-aioc`, `docs/CELLS-AND-PODS.md`).
11. **Nature from the top Cell.** The role and nature of a Pod or an AIOC are read from the type of its top Cell. The Standard sets no rule that every AIOC must contain a given kind of Cell or Pod.
    - **Top Cell (DR-0007).** The card's `top_cell` field names exactly one Cell whose parent is that part. A HOAC label is held by one position, its `label_holder` (§4.1, item 10); a rule that needs several signers names its signing positions. The top Cell gives the part's lead; the AIOC Type gives why it exists.
12. **Two relations (DR-0007).** `parent` names only the AIOC or Pod whose Blueprint holds a part's card. `accountable_to` names the human Cell carrying a HOAC label to which the part answers. The accountability path (§4.2, item 9), signatures (§4.4, item 6), stop authority (§4.3, item 2), and "above" and "under" in every rule follow `accountable_to`, never `parent`. A Cell is never a parent; nothing sits inside a Cell.
    - **The accountability chain.** Every part's `accountable_to` chain is acyclic. It ends at the Cell carrying the unscoped `[ORG]HOAC-GOV` (§4.4, item 13), and it passes at least one Cell of seat kind human carrying a HOAC label.
13. **The root (DR-0007).** Each `[ORG]AION` has one root AIOC, its Charter: the core of the `[ORG]AION`, at the governance level, made from the Library part 49GAION Charter (§1.3, item 1). GOV approves the Charter. It is installed and changed only on GOV's signature, never by `[ORG]AIOC-OCO` alone; where an organisation has no separate `[ORG]AIOC-OCO`, never by any AI alone. The core holds the human position of the governance seat and its Office; the Top Management position sits in the Top Management Group, the first AIOC under the core, which is the hub of the operation, human and AI. Only GOV's Cell has no `accountable_to`; its authority comes from the constituting documents.
    - **The Charter's own parts and its restart.** Every installation, change or retirement of a Pod or Cell of the Charter is a change of the Charter. The Cell carrying the unscoped `[ORG]HOAC-GOV` signs it, even where the part is accountable to the Cell carrying `[ORG]HOAC-TM` (Protocol §4.10, item 11). No seat of the `[ORG]AION` can sign the restart of the whole Charter, since the Cell carrying `[ORG]HOAC-GOV` is inside it and nothing is above it (§4.3, items 4 and 7). A stop of the whole Charter is lifted as the organisation's constituting documents set, outside the `[ORG]AION`; the restart is then recorded in the unit register. No AI and no part of the `[ORG]AION` restarts it.
14. **Assignment (DR-0010).** Besides `parent` and `accountable_to`, a part may be assigned, by dated assignment records, to programmes or engagements it serves. An assignment carries no authority and opens no access; access follows the filled seat (§4.4, item 4). A title names the role, never the assignment.
15. **Temporary parts (DR-0010).** Work that spans several units may get a temporary Pod, or a temporary AIOC when it needs nesting, with one shared acceptance test, one accountable human seat and a recorded retirement condition. It is created and retired like any part (`create-or-install-unit`, `retire-unit`) and takes an ordinary code.
16. **Built from the smallest units (DR-0025).** 49GAION builds the smallest units (Cells, Pods, AIOCs) and keeps each with its own technology: its blueprint, card, fixed test, repository and version. A unit is built once and kept. Outputs are made by combining units in different arrangements, never by rebuilding them (§3.1, items 11 and 12).

Sources: DR-0007, DR-0030, DR-0032, DR-0041.

### 1.8 Conformance and proof

1. **A text proves nothing by itself (DR-0053).** The texts of 49GAION say what an `[ORG]AION` must do and refuse. That a rule holds is shown only by running it, and every fixed test reads `NOT_RUN` until it has run.
2. **Conformance of an implementation.** An implementation of a part of 49GAION (a gateway, a core, a part made from the Library) claims conformance only when it runs the conformance scenarios of the Operating Protocol (its section on the event record), records its own trace of each in the event record (§4.4, item 24), and the Protocol's trace checker passes on that trace, the scenarios that must pass included. Until then its claim reads "unverified".
3. **When an `[ORG]AION` is proven.** An `[ORG]AION` counts as proven only after one end-to-end acceptance run, from the intake of Edition Maker to the operation under Top Management, in which:
   - the measures of success were fixed at the intake, and are read from the run's own record and judged by the governance seat's measures, never declared by the core (the complete definition, §13, item 3);
   - an objection of the owner reaches its accountable position and gets a recorded decision within the limit the organisation set;
   - when no credential of the governance seat is in force, the authority of every AI part is suspended at once (§4.1);
   - a position that is a party to a decision recuses, and the substitute the founding configuration names decides (§4.2, item 10).
   Until every one of these holds, the `[ORG]AION` reads "unverified". A core that marks success while a measure of the intake is unmet fails the run.

Sources: DR-0053.

## 2. Self-Improvement

### 2.1 What it is

1. **A shared process.** Self-Improvement is a process shared by AI and humans. It keeps an organisation current: its units, blueprints, processes, Protocol and Standard.
2. **Proposers.** Any human seat and any AI unit may raise a proposal. A human may want a change for reasons the system cannot see (the market, the law, people, strategy); an AI may find one in the records (stuck or returned work, failing tests, units that overlap, a unit grown too broad).
3. **Form.** Every proposal carries the current text, the proposed text, the reason and the evidence, and the parts and tests it affects. It is recorded as a Work Item of type `design-proposal`.
4. **Discussion.** A proposal is discussed between its proposer, the human hub and the units it affects, until its text is ready for decision. The discussion records the arguments; it decides nothing.
5. **Decision.** A proposal takes effect only on approval by the accountable human seat (§2.2), as a new version and a decision record. Decision records are never edited. What is applied must equal what was approved. Human silence is never consent.
6. **Its place.** Self-Improvement is not a separate part of an `[ORG]AION`; there is no standalone Self-Improvement unit or unit card. It is a process at every level: each unit improves its own work within its scope, and Top Management does so for the operation. In the human hub, `[ORG]HOAC-TM` (§4.2, item 2), it is carried out jointly by humans and by the AI Cells serving the Self-Improvement process in TM, accountable to the TM Cell; the process and its fields are recorded only on the card of the Cell carrying `[ORG]HOAC-TM` (Protocol, `processes` on the unit card). Those Cells raise proposals of their own and prepare every proposal for decision; TM decides, including on changes to `[ORG]AIOC-OCO`. Any unit or seat may raise a change to the structure, the Standard or the Blueprint (item 2); the core of the `[ORG]AION` prepares it, and a human seat signs it, as the organisation sets. `[ORG]AIOC-OCO` carries out what is approved; where an organisation has no separate `[ORG]AIOC-OCO`, the Top Management Group carries out what is approved.
   - **Open proposing, and the organisation's rules.** Proposing is open to all: Top Management, every unit and every position may send any proposal or need to the `[ORG]AION`, because the organisation is a living system and change comes from inside. The `[ORG]AION` reviews: a proposal that is not right is rejected inside the organisation with its reason recorded, and the proposer may take it directly to the governance seat; a proposal that is right is applied by the `[ORG]AION` with the governance seat's approval. The `[ORG]AION` may reject on its own, since rejecting opens nothing; applying needs the seat's signature, except where the seat's dial, its signed standing approval, covers small changes of a kind it has set; every change still passes its tests. Top Management sends what it builds and learns to the governance level to be recorded.
7. **Its records.** The AI Cells serving the Self-Improvement process in TM (item 6) read the shared queue, the gateway logs and the test results directly and read-only, never only through a Panel. These records are kept where OCO cannot change or delete them.
   - **Access rule (DR-0007).** The records named in this item are read read-only and pseudonymised: no person is named in what is read. Nothing read is kept in a private store of the process or of a Cell serving it. This access changes only as a Work Item, decided under item 8. It is an access rule, not a signature type.
8. **Its own changes.** The AI Cells serving the Self-Improvement process in TM are maintained through OCO like every AIOC, but any change to them, including their tests and their access to data, needs the approval of `[ORG]HOAC-TM`.
9. **Merging and splitting.** Proposals to merge units that overlap, or to split a unit that has grown too broad, follow the same process.
10. **49GAION Self-Improvement** is the same process for 49GAION itself, held by the governing seat (GOV) of 49GAION. It also brings generalised lessons from each `[ORG]AION` back into central 49GAION.
11. **Intake from failures (DR-0010).** Every escaped defect is traced, with one cause class, to the earliest step that could have caught it. The proposal fixes that step, preferring in this order: delete what failed, automate it, tighten an existing test, add a check, add a golden-set case, change an instruction, and only last add a checklist line. It ships with the case, its near neighbours and a search for the same cause elsewhere; a repeat reopens it. A fix never adds an approval or a wait, and never removes a fixed test or a Human Floor test. When the same kind of event recurs a set number of times, a standing fix is proposed; when a process misses one of its own measures a set number of times in a period, an incident is opened on the process itself.
12. **Reversal triggers (DR-0010).** Every proposal and every decision record states in advance its expiry, the measured conditions under which it is revisited, and the outcomes that would make it worth stopping.
13. **The Reserve (DR-0010).** A proposal that is not adopted is never lost: it is kept in its unit's Reserve with its reason and a "reconsider when" trigger, which monitoring checks. Taking an item out of the Reserve is a new proposal, decided under §2.2.

Sources: DR-0007, DR-0035, DR-0041.

### 2.2 Who approves

| A change to | Is approved by |
|---|---|
| The 49GAION Standard, Protocol or Library | The governing seat of 49GAION |
| An `[ORG]AION`'s own Standard, Blueprint or Library, its IP at its governance level | Its `[ORG]HOAC-GOV`, or the dial that seat has signed (§2.1, item 6); the `[ORG]AION` applies the change |
| The authority of an AI (capacity, skills, bots, access, budget) | The `[ORG]HOAC-ACS` seat of its unit (§4.2, item 6) |
| Any other unit, blueprint, process or Protocol value of an `[ORG]AION`, including `[ORG]AIOC-OCO` itself | Its `[ORG]HOAC-TM` |

Changes within the operation are Top Management's, under its mandate.

1. 49GAION Self-Improvement brings changes to 49GAION as pull requests; they merge only on the decision of the governing seat of 49GAION.
2. No unit approves a change to itself. A change to `[ORG]AIOC-OCO` is proposed, discussed and approved like any other, and OCO only carries it out once approved.
3. **Decision records are frozen (DR-0006).** A decision record on main never changes: it is not edited, renamed or deleted. A new record takes the next free number, with no gap and no reuse. In the index, a record's row changes only in its status, from proposed to in force, or from in force to superseded by a newer record that is on main or arrives in the same change. A required check on main enforces this, and fails closed when the index cannot be read.
4. **How a change reaches main (DR-0006).** Every change to 49GAION reaches main as a pull request that the governing seat (GOV) of 49GAION approves and merges, with the required checks passing and no bypass of the main-protection rules. A change to the checks themselves is its own pull request and lands before the content that needs it. A check judges each change with the copy of the check on main, never with a copy the change brings.

Sources: DR-0041.

### 2.3 The improvement loop

How a change is found, tested and promoted. The loop applies to every process, blueprint and Protocol value of an `[ORG]AION`, to any move of a work unit between human and AI, and to 49GAION itself.

1. **The process record.** Every process that can be improved is written down in four parts: the **role** of each unit or position in it; its **instruction**; its **contract**, meaning what each step must hand over and the checks it must have passed before handing over; and its **order**, meaning the sequence of hand-offs, including where work returns to an earlier step. Contracts and order are carried on the cards and in the Work Items.
2. **The champion.** For every process, the version in force is its champion. It stays in force until a challenger beats it.
3. **The challenger.** A proposal (§2.1) to change a process is written as a challenger: a difference to the champion. Contracts and order are changed first, roles and instructions last, because most of what a process needs to know lives in what is handed over, with what checks, and in what order.
4. **Shadow run.** The challenger runs beside the champion on the same cases, past cases replayed or live cases in shadow, with no effect on real work.
5. **Pairwise judgment.** A judge, separate from the proposer, compares the challenger's result with the champion's, case by case, and records which is better and why. Results are compared in pairs, never by a single absolute score, and each pair is judged with the two results shown in both orders.
6. **Iteration.** The AI Cells serving the Self-Improvement process in TM (§2.1, item 6) revise the challenger using the whole history of judgments, for a bounded number of rounds set in the `[ORG]AION`.
7. **The golden set.** Every process has a golden set: real past cases, frozen and held out, never used to tune or to judge rounds. The surviving challenger is run on it and judged blind by the assurance unit (item 9).
8. **Promotion.** A challenger goes to the human seat that approves the change (§2.2) only when it wins on the golden set by the margin set in the `[ORG]AION`, passes every fixed test and every Human Floor test, and costs no more per case unless that seat accepts the cost. On approval it becomes the champion, as a new version; the former champion is kept for rollback.
9. **The assurance unit.** An assurance unit, an AIOC independent of the proposer and the judge, measures every challenger that reaches the golden set. It runs on a different model provider where one is available, and its `[ORG]HOAC-ACS` seat reviews a sample of its verdicts. Its verdicts measure; they are never fed back into the rounds they measure. Any change to it, its judges or its access to data needs the approval of `[ORG]HOAC-TM`, as for the AI Cells serving the Self-Improvement process in TM (§2.1, item 8). No unit grades its own work, and `[ORG]AIOC-OCO` never grades the AIOCs it builds.
10. **Dwell and rollback.** After a promotion, the process is not changed again for a dwell time set in the `[ORG]AION`, except on an incident. Any human seat accountable for the process may order a rollback at once.
11. **Distillation.** At set intervals, the best runs of each champion are written into its defaults: roles, instructions and contracts absorb what worked, so the process no longer needs special instructions; the best cases are kept as worked examples; every failure seen becomes a fixed test (§3.2, item 3). Generalised lessons go to the 49GAION Library (§1.3, item 7).
12. **The proposer.** The proposer is the bottleneck of the loop: good judgments are wasted on a proposer that cannot use them. The strongest available model writes and revises challengers; a lighter model may judge early rounds, with the assurance unit confirming.
13. **Measure.** Progress is measured as quality per unit of cost, against the champion, on the golden set.

Sources: DR-0007.

### 2.4 Safeguards of the loop

1. **Shared blind spots.** When the same kind of model executes, proposes and judges, one flaw can be produced, accepted as an improvement and built into the next version. The assurance unit, the held-out golden set and human review exist to break that circle; the loop may not remove or weaken any of them.
2. **Noisy search.** Strong rounds can be followed by sharp regressions. The champion is therefore kept until beaten, a win needs a margin, each case is run more than once, and every promotion has a dwell time and a rollback.
3. **Judge drift.** At every distillation, agreement between the judge and the assurance unit is measured. If it falls below the level set in the `[ORG]AION`, promotions stop until a human seat has reviewed the judge.
4. **Tuning to the test.** A human seat chooses and rotates the golden set on a schedule; the loop never chooses its own golden set.
5. **Authority.** The loop never widens AI authority by itself. A move of a work unit toward AI is a challenger like any other, and also needs the evidence required by §3.2, item 6, and the approval set in §2.2. No AI approves a promotion, changes a fixed test or its threshold, or grants itself access (HF-11, HF-14).
6. **Basis.** The loop follows published research on recursive self-improvement through multi-agent self-supervision. The sources, and what was and was not taken from them, are in `references/2026-10-12-references-self-improvement.md`.
7. **Measures that cannot be gamed (DR-0010).** Parts are judged against absolute bars, never ranked against each other. Scored measures are kept apart from measures shown for diagnosis only. A measure of AI output quality is shown to its oversight seat, is never wired to the routing, scores or rewards of the parts it measures, and is paired with an outcome: a measure that improves while its outcome does not is flagged as gamed. A measure that no recorded event can compute shows "not measurable" and is never estimated.
8. **Rule promotion (DR-0010).** A repeated finding becomes a candidate rule only when it recurs across a set number of items and producers. It ships advisory first, with its measured false-positive rate, counts against a rule budget per part, expires unless pinned, and goes live only on a human seat's decision; a rule that becomes a fixed test or changes a threshold is `change-fixed-test-or-threshold` (HF-14).
9. **Advice from several providers (DR-0010).** For design questions, models from different providers may be asked independently, without the asker's own instruction or a leading frame; their replies are kept whole and merged by a stated rule. Such advice decides nothing; a human seat adopts or rejects. The engines asked are external ports (§4.4, item 7).

## 3. Library

### 3.1 What it holds

1. **The 49GAION Library** holds all ready-made AIOC blueprints and part cards; these are the Library's Parts, beside its Products (item 11). Built once, configured per `[ORG]AION`, never rebuilt (§1.2). It also holds the method catalogues that blueprints read, such as the reference-model catalogue. A method catalogue holds no organisation's data, copies no text, and is never evidence about an organisation; a part reads it only at a version it has pinned.
2. Each `[ORG]AION` has its own Library, holding only what the organisation needs; capabilities found during design are added back to the 49GAION Library, generalised and tested (§1.3).
3. **Process and Position Design (DR-0014).** The 49GAION Library holds **49GAION Process and Position Design**, the design stage after the target operating model (Protocol §17). In an `[ORG]AION` it is the AIOC `[ORG]AIOC-PPD`, a part of its own, never merged with the part before it or the stage after it.
   - **What it does.** From a decided target operating model, it designs how the organisation's work runs and the positions that carry it, processes first: the processes under each part of the model, with their steps, decisions, hand-offs and measures; then the positions, each built from the steps and decisions it holds, with its job description generated from them; then the units that group the positions, each with its head position and a charter generated from what its positions hold; then reporting lines, standing forums and the work each position carries. It reads what the target operating model also states (item 4): its objectives start from the strategy; the critical value streams are designed first, in order of priority; a capability delivered outside becomes a hand-off with oversight steps, never an in-house process; today's records of work are read beside the designed workload, never about a person.
   - **Linked to the target operating model directly.** It takes the decided release by reference (ID, version and hash) from the part that made it. It never edits that release: each defect it finds goes back to that part as a return, and the two parts go back and forth until the release holds.
   - **Other sources.** Every other source, such as the organisation's existing processes, volumes and times, comes only from Source Lifecycle, and what is missing is asked through it.
   - **Positions only.** It designs positions, never people (§1.1, item 9). It makes no choice of what fills a position; that belongs to a later stage. For an `[ORG]AION`, that later stage is the AI-native design (§1.1, item 2): it starts from the output and from what AI can do, not from these positions one by one.
   - **Decided and filed.** Every element is decided by the organisation before release. The release is frozen, filed into Source Lifecycle as a source, and handed to the next stage by reference.
4. **Target Operating Model (DR-0016).** The 49GAION Library holds **49GAION Target Operating Model**, the stage after Source Lifecycle (its Protocol section of the same name). In an `[ORG]AION` it is the AIOC `[ORG]AIOC-TOM`.
   - **What it does.** It designs the target operating model of an organisation of any shape: capabilities, value streams, decision rights, interfaces and hand-offs, and a role register that names each role and what it decides. It does not say what fills a role.
   - **Sources.** Only sources served by reference from Source Lifecycle; what is missing is asked through it.
   - **Linked directly to Process and Position Design.** On filing a decided release, it also sends a release notice to Process and Position Design and receives that part's returns directly, under the design return contract (item 6).
   - **The return loop ends.** A return goes back and forth in rounds until it is answered by a new decided release, answered by a decision of the Requesting Authority, or set aside by that decision and carried forward on a stated basis. It is never left open.
   - **Decided and filed.** Every element is decided by the Requesting Authority; the release is frozen and filed into Source Lifecycle as a source.
   - **What it also states.** The organisation's strategy on one page; how each capability is delivered (in-house, shared service, outsourced, partner), never naming a provider, and how mature it is; which value streams are critical, each for a stated reason; each outside party's journey; a value case per outcome; and a priority per element, proposed by a fixed rule and decided with the element. Each comes from the organisation's sources or decisions; the part never writes a goal, a target, a level or a figure of its own. It may read records of the work as it runs, by role-type and process only, never about a person, admitted through Source Lifecycle after the organisation's data-protection decision (HF-17); where there are none, it says so and goes on. No part watches work.
5. **Delivery and Implementation (DR-0017).** The 49GAION Library holds **49GAION Delivery and Implementation**, the last stage of the design chain (its Protocol section of the same name). In an `[ORG]AION` it is the AIOC `[ORG]AIOC-DI`, a part of its own.
   - **What it does.** It takes the decided design into a running organisation and stays with it: it diagnoses the gaps, prepares the procedures, drafts, controls, obligations, transition plan and go-live criteria, accompanies the launch to the go or no-go decision, runs the operating rhythm and its records, and improves the processes with the organisation, handing its skills over as it goes. It carries the value case and the priority of the target operating model unchanged; its register of value starts from the value case, and its rollout follows the priority.
   - **Three ways in.** The decided releases of the target operating model and of Process and Position Design; a design made elsewhere; or no design, in which case it builds a light design with the accountable position, every element provisional until decided.
   - **It decides nothing.** A permission ladder per class of action: read; propose, a draft entering a record only when a position inserts it; apply within a standing approval, only where reversible and with no legal, pay or employment effect. No level allows an item of the Human Floor signature list, and any accountable position can stop it at once.
   - **Processes, not persons.** It works at the level of processes and units, never ranks, scores or watches a single position, and shows no measure for one (§1.1, items 9 and 10).
6. **One design return contract (DR-0018).** Every design stage that reads the release of the stage before it sends its returns under one Library contract (`library/contracts/design-return.schema.json` in `49GAION-protocol`): five kinds; elements and evidence by reference, never a person; never new release text; and an end for every return: answered by release, answered by decision, set aside by decision and carried forward, or withdrawn.
7. **Source Lifecycle (DR-0008, DR-0019).** The 49GAION Library holds **49GAION Source Lifecycle**, the first stage (its Protocol section of the same name). In an `[ORG]AION` it is the AIOC `[ORG]AIOC-SL`, the first part an organisation receives after the Charter.
   - **What it does.** It takes documents of any format and a contributor's own words, approved first; it records, references, classifies and fixes each source, so that each has one valid version; it tells the organisation what is missing.
   - **It serves the later stages.** By reference only, within a scope a labelled human position approves. It answers their needs requests by routing each row to the position that answers it, never to a named person, and records each answer as a source. Each design stage files into it only its own kind of release and its design reports. Asking and filing stay with Source Lifecycle; a source that stands beside it is read only.
   - **It also keeps** the organisation's dictionary, its own terms with their definitions and sources, served by reference to every stage; an essentials checklist that flags what an organisation's sources should hold (strategy, plan, measures, structure of positions, processes, meetings, dictionary), never filling it; and records of the work as it runs only as the organisation's own projection by role-type and process, after an impact assessment and the data-protection decision (HF-17). An export that still says who did the work is refused.
8. **One release notice contract (DR-0019).** Every design stage announces each decided release to the stage after it under one Library contract (`library/contracts/release-notice.schema.json` in `49GAION-protocol`): by reference, with the releases it rests on, the filed copy, the final-status decision and the returns it answers; never release text or the name of a person. A stage's own notice contract may narrow a field; it never adds or removes one.
9. **The Library register (DR-0019).** The Library names every part once, in one register (`library/README.md` in `49GAION-protocol`), with its card, its Protocol section, its place in this Standard, its fixed test and, for an AIOC part, its mother blueprint. A mother blueprint is written in its own writing repository, for any organisation, with no organisation's data; the Library holds it by pin (repository, path, version, commit and SHA-256), never by a second copy, and a new version reaches the Library only by a pull request that moves the pin. An organisation's instance keeps its own values in its records repository. Where the writing repository of a part's first instance holds an organisation's data, the mother is written in the part's own public mother repository, `49GAION-<part>` (Naming Standard R9, item 4); the instance keeps its private writing repository. The first two are Source Lifecycle and Product Core.
10. **The design chain (DR-0019).** Source Lifecycle, then Target Operating Model, then Process and Position Design, then Delivery and Implementation. Each stands alone, and no stage waits for a later one. Each decided release has one home, in Source Lifecycle; the next stage is told of it directly (item 8); what a stage cannot use goes back to the stage that made it (item 6), and every return ends. What one stage leaves open (not given, not decided, not set, unknown, no observation), no later stage fills. Every stage after Source Lifecycle has its work checked by engines that did not produce it, from more than one family, and no unit grades its own work (§2.3, item 9). The Protocol section The design chain sets the rules.
11. **The Library in two sections (DR-0025).** The Library is the one store of everything 49GAION has built and knows.
   - **Parts.** Everything 49GAION builds, from a Cell to an AIOC, with its blueprint, card, fixed test, contracts and method catalogues, and its whole history: versions, lineage, decisions, lessons and test results. The toolbox and the knowledge of 49GAION.
   - **Products.** What the Library offers: a single part offered alone, such as Source Lifecycle, which runs on its own: with the Charter, the root of every `[ORG]AION` (item 15), and `[ORG]AIOC-OCO` (§5.3), and no other Library part; or an **assembly**, parts placed side by side and connected. An assembly's blueprint lists its parts by pin, the connections between them, what it sets itself and one shared test; its features are its parts' features; each part still works alone; a new version of a part moves only its pin. A part may serve in more than one product. A product is named and defined before it is built; once built, the Library holds it, and it may itself be a part of a later product.
12. **The first assembly (DR-0025).** **49GAION Organisation Design and Delivery**: Source Lifecycle, Target Operating Model, Process and Position Design and Delivery and Implementation, placed side by side and connected by the release notice and design return contracts (the Protocol section The design chain), with TEST-DESIGN-CHAIN as their shared test.
   - **What it gives.** From an organisation's own sources, a decided target operating model; from it, processes and then the positions that carry them; and the decided design taken into a running organisation. Positions only; AI prepares and human positions decide; nothing invented; each stage runs alone; every defect returns to the stage that made it.
   - **For human organisations.** Its output is an organisation of human positions, built with AI tools: it is human-native, with AI as a tool inside a design of human positions, not yet an AI-native operation. The next product, for an `[ORG]AION`, is AI-native (§1.1, item 2): it starts from the output and from what AI can do, and it is not simply a choice of which positions an AI fills; it may use all or some of this assembly's parts.
   - **Named now, built later.** Its parts are `DRAFT`, `NOT_RUN`. Delivery and Implementation is written in full, v0.2.0, slices 1 to 4 (`github.com/49g-holding/49GAION-delivery-and-implementation`, `decisions/DR-0004-complete-stage.md`), and pinned in the Library register at its merged commit (state of 19 October 2026). This records what is built; it is not yet a rule set.
13. **Operations Event Register (DR-0027).** The 49GAION Library holds **49GAION Operations Event Register** (its Protocol section of the same name). In an `[ORG]AION` it is the AIOC `[ORG]AIOC-OER`; its mother blueprint is in its own mother repository (item 9).
   - **What it does.** It gives every formal act and crossing of the organisation's units and positions, on any work surface, one number in one append-only, hash-chained register: mail and letters in and out, the organisation's own posts, requests between entities and between units, AI hand-offs at the tool gateway, and code-host events at merge and release. From that register it tells each unit and each process what was recorded, linked, answered and sourced, and what was not.
   - **Record, don't carry.** Each item stays in its home; an entry holds its number, its parties as codes, its times, a reference to its home, the SHA-256 of its content and its follow-up state. Every unit has an inbox and an outbox, as Panel views of the entries at its ports.
   - **It decides nothing.** The tool gateway gates, and the register records (HF-18): "register first" for a formal outgoing item is a gateway policy. Nothing on the accountability path waits on it, and when it is down, work goes on and is registered late.
   - **Acts, not activity.** Recording the formal acts and crossings of units and positions is not watching work, and "No part watches work" (item 4) stays in force. Every act of an AI Cell is recorded, as metadata and references, except a Cell that acts for a holder, of which only the acts that leave the holder's sphere are recorded. For human positions, only their formal acts are recorded: no sweep of a mailbox or chat, no read or response times, no presence, no recordings, and no count, rate or history of a human position's acts. A human position is shown only the live state of its own open items. A party is a code the gateway stamps on an act, or the unit or position that owns the address, never an identifier of a natural person. Feedback is given by entity, unit, process and AI Cell; a figure drawn from fewer human positions than a minimum group size rolls up to the parent unit. Its projections and measures are a fixed list; a new one, class or purpose needs a new impact assessment and a decision of `[ORG]HOAC-TM`. Each surface is connected only after its scope is set by `[ORG]HOAC-TM`, its impact assessment and lawful basis are decided (HF-17), and the port is signed (`connect-external-port`).
   - **What it serves.** The activity profile of the design stages (item 4), as an export filed into Source Lifecycle after its HF-17 decision; the internal-audit line (HF-19), which reads it directly and read-only; Self-Improvement, once `[ORG]HOAC-TM` adds the register to the process's access (§2.1, items 7 and 8), never its entries of the accountability path; evidence packs; the handover of a position's open work; past cases for shadow runs, and for the golden set through the human seat that chooses it (§2.3, items 4 and 7; §2.4, item 4); and, for a decision to move work toward AI, the evidence of what the work is.
14. **The second assembly (DR-0027).** **49GAION Organisation Memory**: Source Lifecycle and the Operations Event Register, placed side by side. Source Lifecycle keeps what the organisation knows, and the register what it did. Four things connect them: an entry a position asks to keep is filed as a source of origin kind `correspondence`, fixed as received; the register's projection of the work by role-type and process is filed as an `export`; and work done without a source reaches Source Lifecycle as a gap signal. The fourth runs the other way: on a notice of supersession from Source Lifecycle, the register marks the acts that cited the superseded version after it was superseded (Protocol §22, item 11). They have one shared test.
   - **With the first assembly.** Placed beside Organisation Design and Delivery (item 12), it closes the loop of an AI-native operation: the design runs, the register records it, and the next design starts from the record.
   - **Named now, built later.** Its parts are `DRAFT`, `NOT_RUN`. This records what is built; it is not yet a rule set.
15. **The Charter in the Library (DR-0029).** The 49GAION Library holds **49GAION Charter** (its Protocol section of the same name), the part from which the root AIOC of every `[ORG]AION` is made (§1.7, item 13). In an `[ORG]AION` it is the AIOC `[ORG]AIOC-CH`; its mother blueprint is in its own mother repository (item 9).
   - **What it holds.** The human position of the governance seat and its Office (§1.7, item 13; the Top Management position sits in the Top Management Group, the first AIOC under the core), and three Pods of shared services that every other part relies on:
     - **Gateway:** the tool gateway (§4.4, item 11), with its signature gate, its engine register, its log, the stop door and the human surface;
     - **Records:** the registry of record types, the one numbering service, the event store that serves every part's record home, the projections and their daily check, and the restricted partition;
     - **Work:** the shared queue of Work Items with its watchdog, the routing data, and wake.
   - **One of each.** An `[ORG]AION` has one tool gateway, one numbering service and one shared queue. No other part keeps its own; each part writes only its own records and its own Work Items.
   - **Who changes it.** It is installed and changed only on GOV's signature, never by `[ORG]AIOC-OCO` alone (§1.7, item 13), and its gateway policy only under `change-gateway-policy` (§4.4, item 11). Engine Room, named in the Library register, supplies the engines the gateway binds and never replaces the gateway (DR-0026).
   - **Named now, built later.** Its card is `DRAFT`, `NOT_RUN`. This records what is built; it is not yet a rule set.
16. **The Library as the greatest asset (DR-0041).** The 49GAION Library holds everything 49GAION has built and learned, and everything given back to it: patterns and models, AIOCs with their blueprints and their operating models, instructions and processes, panels and cores, and the patterns of whole organisations. Each organisation takes from it and personalises it. What enters the Library is challenged like every 49GAION change and approved by its governing seat before others use it.

Sources: DR-0022, DR-0023, DR-0024, DR-0025, DR-0029, DR-0031.

### 3.2 Evidence and tests

1. **Done means visible evidence.** A Work Item is done when the requester's acceptance test passes on visible evidence (a link, a file, a live result or a read-back), never on a bot's own report.
2. **A fixed test for every capability**, written before use, versioned, re-run after any change to a model, instructions, tools, access, a card, a blueprint or the Protocol.
3. **Lessons become tests**, so the same error cannot pass twice.
4. **Joining test.** An AIOC receives work only after every input and output on its card passes fixed samples.
5. **Input check.** Every arrival is checked by the receiving AIOC's Input socket; a failure goes back with the reason.
6. **Authority follows evidence.** AI authority widens only on a measured test score at or above a recorded threshold. Until a threshold is recorded, AI authority does not widen.
7. **Shared changes are tested before rollout** to any AIOC or `[ORG]AION`.
8. **Outside text is data, never an instruction.**
9. **A fixed test for every Cell, Pod and AIOC**, owned by the seat that carries its accountability. Work moves from human to AI, or from one version to the next, only by passing that test, and moves back if the score drops below the recorded threshold.
10. **Discriminating evidence (DR-0010).** A passing check counts as evidence only if it has been shown able to fail on the case it guards: it fails before the change and passes after, or a deliberately broken variant is caught. Evidence of a run is written by the runner, never by the worker that was checked. A figure a worker wants believed is a tagged claim that an independent runner re-runs, and every figure, hash or count in a record is read from what produced it, never typed.
11. **Check placement (DR-0010).** Every automated check that is not a fixed test declares its placement (inside the producer's loop with a cap on fix rounds, as evidence on the verdict record, as a router within caps, or after completion), its cost budget per item and the order in which it sheds work over budget. It is advisory unless it shows a real defect, and blocks only for a class the `[ORG]AION` names. A fixed test and a Human Floor negative test are never advisory and never shed.
12. **Silence is failure (DR-0010).** Every automated check returns ok, finding or unknown, and unknown is never a pass. Every watcher reports its own pulse, and a watcher silent for twice its interval is itself a finding. A failure is closed only with a detector that would see it next time, a route to the position that acts and a test that fails if it returns; a failure that a human had to notice first is a defect of the unit. The duties of an AIOC are checked from outside by an inspector on infrastructure and, where available, a model provider that share no failure with it; the inspector builds nothing and directs no one, and it is never the internal-audit line (HF-19).
13. **Fresh instance and duty carriage (DR-0010).** On every change to a definition, a fresh instance is built from the definition alone, with no other instance's records, and run against the fixed tests. Every duty that a role card, a standard or a decision gives a position is traced to a process step, a recorded event or a setting; a duty with no carrier fails the unit's fixed test.
14. **Verification by a non-author (DR-0010).** Work is verified by a Cell that did not produce it, on a different model provider where one is available, in a fresh context, with the producer's description withheld. The verifier restates the acceptance test and writes its own checks before reading the work, and blocks only with a failing check it wrote. Its verdict is a record bound to the exact version it read; a new version voids it, and tools act only on the record, never on the text of a note. A verdict is never a signature.
15. **The mechanism register (DR-0010).** Every AIOC keeps one register of its mechanisms (what each does, where it lives, its state today and its target), never deletes a row, and cites the row from every change that builds it. Ideas not adopted go to the Reserve (§2.1, item 13).
16. **The few safeguards that always hold (DR-0041).** AI acts only within the access and the authority it has been granted; missing or unclear authority means no action. No step runs on one engine alone: no result counts without a challenge by another engine, scaled to the risk of the step, and one engine writing with two challenging is the Library's default pattern, mandatory at every step in Edition Maker. The assurance is fixed tests on real outputs and a human position that signs. AI may write and update the tests; a human position signs each change to them (HF-14). Every unit is ready, by its fixed test, before it runs. The tool gateway fails closed: if it fails, no AI acts; a stop is never blocked, by the gateway or by its failure. Also among these safeguards: a change to the gateway or to the stop code counts as a loosening; the gateway keys are fresh at the handover; the tests exist from the first day; the authority ceiling; and the governance seat's own conflict of interest (`49GAION-FRAMEWORK.md`, points 15 and 20). These safeguards hold in every edition 49GAION hands over; after the handover they are the organisation's own, within the law.

Sources: DR-0042.

## 4. HOAC

### 4.1 The HOAC

1. **HOAC** means **Human Oversight & Accountability Control**. It is a label of human accountability, not a unit. It sits on a Cell, a Pod or a whole AIOC, at any depth, and is recorded as a field on that part's card and register entry. AI does the work; the part that carries the label holds what only a human can hold.
2. **Kinds.** The label has three kinds. In text, `[ORG]HOAC-<TYPE>` names the part that carries that label; the part keeps its own code.

| Kind | Label | Definition |
|---|---|---|
| Governing Body | `[ORG]HOAC-GOV` | The position with ultimate accountability for the whole organisation; whatever stands behind it is the organisation's own (DR-0048). Its authority comes from ownership and the constituting documents. |
| Top Management | `[ORG]HOAC-TM` | The position that directs and controls the organisation at the highest level, accountable to the Governing Body. It is the human hub (§4.2). |
| Accountability Seat | `[ORG]HOAC-ACS` | A human seat wherever a step needs human accountability. |

3. **Seats.** A human seat is a Cell of human nature: a position, a legal persona, defined in the system only by its nature, so that no AI fills it, and by its stated duties (§1.1, item 9). Who holds it, and how, is the organisation's own mechanism, outside the system, which no AI part sees. A seat is filled when the organisation's mechanism has a credential in force for it, and empty when it has none. Every seat is recorded in the unit register (§4.4).
4. **`[ORG]HOAC-GOV` from day one.** Every `[ORG]AION` has its own `[ORG]HOAC-GOV` from the first day of its design. Its top authority is that organisation, never 49GAION.
5. An empty seat returns accountability to the position that delegated it, and any AI authority tied to it is suspended until the seat is filled.
6. **An empty `[ORG]HOAC-GOV` seat.** If the `[ORG]HOAC-GOV` seat is empty, all AI authority in that `[ORG]AION` is suspended until the organisation's constituting authority fills it.
7. **On the card.** The HOAC label is a field of the card of the Cell, Pod or AIOC that carries it. The card keeps its typed ports and its stop door (§6.1).
8. **Superseded meaning.** HOAC formerly had another meaning, superseded by DR-0004. It is kept only to read the records written under it, which stay unchanged; the former wording stays readable at the earlier releases.
9. **A label on a Pod or an AIOC.** When a HOAC label sits on a Pod or an AIOC, a human Cell inside it holds the label. If that Cell, or any Cell carrying a HOAC label, becomes empty or is filled by an AI, the label's powers are held, as for an empty seat (item 5). Held means suspended, as decided in DR-0004, item 4: no one exercises the powers, accountability returns to the delegator (item 5), and any action needing them waits (§4.4, item 9).
10. **Label holder (DR-0007; DR-0049).** A label on a Pod or an AIOC names its `label_holder`: one human Cell whose parent is that part. A HOAC label is held by one position; a board or any body behind a position is the organisation's own (the complete definition, §6). A Pod of several human positions, each acting as its own position and signing under its own Cell code, stays a Pod of positions: the label is signed for by its `label_holder`, a rule that needs several signers names its signing positions, and each position is its own party and counts once (§1.1, item 10).
11. **Label order (DR-0007).** Along any `accountable_to` path, labels run GOV, then TM, then ACS. A label sits only on a Cell whose seat kind is human, or on a part with a human `label_holder`. If that seat is empty or filled by an AI, the label is held as in item 9.
12. **Absence and succession (DR-0007; DR-0049).** Whether a position has an acting holder, a successor or a deputy, and who stands in it at any time, is the organisation's own mechanism, outside the system; the system knows only whether a credential is in force for the position. A signature is the position's, made under its Cell code with the credential the organisation's mechanism issued for it and a fresh live sign-in (HF-10). While a seat is empty, the delegating position may sign within its own authority, except a type the seat has marked personal (item 14), which stays held until the seat is filled. An action is held only when no filled HOAC above it can sign. A retired Cell names `succeeded_by`, and its held actions pass to the successor position.
13. **Load and coverage (DR-0010).** Every human seat kind carries a load weight. The AI side measures load and coverage per position only, and never counts the seats behind one natural person; any line on the people behind positions is the organisation's own mechanism and record (§1.1, item 10). A seat that signs, goes on call or touches money or keys is critical: when empty, it is shown, counted every day and raised again after a set number of days.
14. **Personal signatures (DR-0010; DR-0049).** A seat may mark its signature as personal for some listed types. Such a request waits for that seat's own signature, made with its own fresh live sign-in (HF-10); with no answer within the waiting times of the Protocol (§4.6) the action stays held and the hold is raised along the accountability path, where a higher position may stop the action; no other seat signs in its place. How the organisation reaches the person behind the seat is its own mechanism.
15. **The human-point contract (DR-0010).** Each human seat states the calls it takes, what the AI side hands over with each, what it returns and its answer time. A human-only step reaches the seat as a fully prepared item (what, where, why, done-when, the evidence needed), and a register lists every human step with how it is being made automatic or why it cannot be. Human minutes per delivered outcome are measured, and a seat that is called often is treated as a design fault to remove. That reading does not apply to the listed decision types (§4.4, item 6) or to Human Floor steps, which stay with the human seat however often they are called. Moving a step toward AI stays `move-work-toward-ai` (§3.2, item 6).

Sources: DR-0004, DR-0007, DR-0013, DR-0015, DR-0048, DR-0049.

### 4.2 Authority and the two hubs

1. **`[ORG]HOAC-GOV` is the top authority**, above every AIOC, Pod and Cell.
2. **`[ORG]HOAC-TM` is the human hub** and the highest executive under GOV. It decides and orders: what work the organisation does is decided by humans, through TM, under GOV. It holds Self-Improvement for the operation (§2); Self-Improvement is at every level (§2.1, item 6).
3. **`[ORG]AIOC-OCO` (Organization Core Office) is the AI hub unit, where an organisation has one.** 49GAION requires no separate AI hub unit (item 4). Where an organisation has one, every AIOC, at any depth, joins, is fixed, maintained and upgraded through OCO, and new versions of Library blueprints enter the `[ORG]AION` through it. OCO gives no orders on what work is done; it carries out what the human hub approves.
4. **OCO sits under TM.** The Top Management Group, the first AIOC under the core, is the hub of the operation, both the human hub and the AI hub: it builds everything in the operation, or plans it, or puts its tools in place, and sends its achievements to the governance level; how it divides its work is decided by AI at the time, through Structural Adaptation. Where an organisation has an `[ORG]AIOC-OCO`, it serves the operation under Top Management, and item 3 and this item hold for it. TM draws its authority from GOV; OCO draws its authority from GOV through the human hub. TM orders OCO, meets its human needs (approvals, live human input, Human Floor steps) and is its accountable seat. Who may stop which unit, including OCO, is set in §4.3, item 2.
5. Authority flows down by delegation. No position is accountable without authority; the delegating position stays accountable. No position delegates more authority than it holds.
6. **The accountable overseer.** Human roles are human Cells carrying a HOAC label, placed only where they are needed. Where a part carries an `[ORG]HOAC-ACS` label, the seat that fills it is accountable for the results of that part and everything under it. The seat oversees, receives reports, may request anything for the unit, and never builds or changes the AIs directly. A change to an AI's authority (capacity, skills, bots, access, budget) is decided by the `[ORG]HOAC-ACS` seat. Where a text names the ACS or HOAC seat "of" a part that carries no label, it means the nearest HOAC above that part along `accountable_to`; this covers HF-09 ("`[ORG]HOAC-ACS` of the AIOC"), "the AIOC's voice to its HOAC seat" (§6.1, item 3, and the Protocol) and Protocol §4.4.
7. **The objection path.** The `[ORG]HOAC-ACS` seat raises a request with OCO. If they disagree, OCO does not decide: the seat may hold the objection open until it reaches the HOAC seat accountable for OCO, which decides. Who holds each role is the organisation's own mechanism (§1.1, item 9).
8. **Decisions on 49GAION are its governing seat's.** Decisions on an `[ORG]AION` are its own organisation's, through its `[ORG]HOAC-GOV`.
9. **The accountability path.** A report, critique, objection or stop reaches the nearest HOAC above it directly, from any level, and never passes through any AI (Protocol §4.8).
10. **Skip and recusal (DR-0007).** Any report, critique or objection may also go to any HOAC above, up to GOV, and to the independent internal-audit line (HF-19); the nearest HOAC above always also receives it. A report about a seat never has that seat as its only receiver. A seat that is the subject of a listed action, or that benefits from it, recuses; the signature passes up one level. There is no HOAC above `[ORG]HOAC-GOV`: where the conflicted seat, or the seat a report is about, is the governance seat itself, the founding configuration names in advance either an independent position that decides in its place or a second, independent signature the decision also needs. A conflicted governance seat signing alone is refused at the gateway, and each recusal is reported to the independent internal-audit line (HF-19). A signature or a report that would otherwise go one level up from GOV goes to that substitute or that line; nothing waits forever.

Sources: DR-0007, DR-0035, DR-0041, DR-0042, DR-0049.

### 4.3 Stop

1. Every AIOC, Pod and Cell has a mandatory, queue-less **stop port of type HU** (the stop door). Ports and the stop door are controlled and enforced outside the unit, so no unit inside it can bypass a stop.
2. A seat stops only units within its authority: **ACS** the part it carries and everything under it; **TM** the parts under it; **GOV** every part, including TM and OCO. TM and GOV may each stop OCO (§4.2, item 4). A stop of OCO by TM comes directly through a human port, never through a Panel that OCO built.
3. **OCO, being AI, can never stop a human Cell or any part that carries a HOAC label.**
4. A unit restarts only by human decision; no unit can restart itself.
5. **Inner parts.** Stopping an AIOC or a Pod stops everything under it, at every depth. Stopping an inner part does not stop its parent.
6. A human port, including the stop door, never passes through an AI; the stop door of a part held inside an AIOC never passes through that AIOC (§1.7, item 6).
7. **A stop leaves humans their voice (DR-0007).** A stop suspends the AI fillers, access and work under the part. Human Cells under it keep their HU ports and accountability path. They cannot sign its restart.
8. **Reach of a stop (DR-0007).** A stop under item 2 reaches everything inside the part by `parent` and everything accountable to the part by `accountable_to` (§1.7, item 12). It takes effect at the tool gateway at once, and nothing at the gateway blocks it.
9. **Graded pause (DR-0010).** Besides the stop door, a human seat may flag a part or a piece of work (work goes on; a named seat reviews it) or hold it with a reason class and one sentence (work stops until a named seat reviews it). Everything already queued for held work, such as an approved merge or a scheduled release, is held with it, and work is released only when no pause, stop or superseded version still holds it. A hold is a stop under item 1: a hold that a human placed is lifted only by a human seat, under item 4; no AI lifts it. Lifting a hold on a part or its work is `restart-stopped-unit`. A containment hold under §4.4, item 19, that stops a part or its work is a hold under this item; one that holds only a resource, a flow or an outside effect is lifted with `restore-or-rollback`.
10. **Planned halt (DR-0010).** A unit may be halted by plan through one control record with the states running, draining, paused and resuming, read before every start and every step. New work stops at once; running work stops at its first safe point within a grace time and writes a structured hand-off, and after the grace time it stops with a forced hand-off; resume follows a declared order. A halt never delays, replaces or routes a stop, which stays queue-less and immediate (item 1). Setting a halt narrows and is never held; resuming a part that a human stopped is `restart-stopped-unit`.
11. **Fenced cut-off (DR-0010).** A stop of AI authority raises a cut-off that every executor checks before every mutation, so credentials already issued, queued or running are refused within seconds. Standing authority delegated to AI holds only while witnesses keep a short lease alive, so a silent layer fails closed; the `[ORG]AION` sets how many witnesses there are, on at least one host other than the AI's own. Every executed action records its inverse, and the inverse runs through a recovery path that needs no model, broker or Panel. Re-arming a cut-off, and any return of authority when a heartbeat comes back, is a loosening and is signed.

### 4.4 The unit register and the Human Floor signature list

1. **One register.** Each `[ORG]AION` keeps one unit register of every AIOC, Pod and Cell, with its code, kind, type, HOAC label, parent, filler (for an AI Cell) and status. The form is `registers/HOAC-REGISTER.md`.
2. **Append-only.** Entries are never edited or deleted. A retired entry stays, marked retired, and its code is never reused. A change of an AI Cell's filler and a change of parent are recorded events on the existing entry, never new parts; who holds a human Cell is not a register event.
3. **Split write rights.** `[ORG]AIOC-OCO` writes the records of AI Cells; `[ORG]HOAC-TM` writes the records of human Cells (the position, never who holds it). Neither writes the other's. A register event whose decision type is on the Human Floor signature list (item 6), for example granting or widening access or changing a parent, is written only with the valid signature of that seat; `[ORG]AIOC-OCO` cannot write it alone.
   - **Register writes (DR-0007).** Creating an AI Cell, changing its filler, ports or authority limit, and retiring it are listed types (`upstream/human-floor-signature-types.json`), signed by the HOAC the Cell is accountable to. Access opens only after that event and after the filler passes a fixed test whose owner is a human Cell. `[ORG]AIOC-OCO` never writes the records of its own Cells, of the AI Cells serving the Self-Improvement process in TM or of the assurance unit without `[ORG]HOAC-TM`'s signature. AIOC and Pod entries are written by OCO only with the signature of the HOAC they are accountable to. A change of seat kind, AI or human, is written by both writers. TM's own Cells are written with GOV's signature. GOV's Cell is written by the constituting authority.
   - **Holders (DR-0007; DR-0049).** Who holds a human Cell is kept by the organisation's own mechanism, outside the system and outside every repository; the unit register carries structure only. The GOV row carries the seat only.
4. **Access follows the filled seat.** Access opens only for an active Cell: an AI Cell whose filler has passed the seat's fixed test, or a human position for which the organisation's mechanism has a credential in force. It closes automatically when an AI Cell's filler changes, when the credential is revoked, or when the Cell is retired. Within a Pod access does not pool: each Cell holds only its own.
5. **Two positions, two parties.** Each signature is recorded with the code of the Cell it is given for, whoever stands behind it. Two approvals under two Cells are approvals of two parties and count as two, even when one natural person gave both; no AI part or check compares the persons behind them (§1.1, item 10).
6. **The Human Floor signature list.** As part of the Human Floor (§1.5), the Standard keeps one plain machine-readable list of decision types that require a human seat's signature (`upstream/human-floor-signature-types.json`). An `[ORG]AION` may add types to its own copy; in the edition 49GAION hands over it removes none. After the handover the list is the organisation's own, kept and changed by its governance seat under its own rules, within the law. At the tool gateway, an action of a listed type runs only with a valid signature, even in an AIOC that is 100% AI. A signature is valid only from the human seat with authority over that part: the nearest HOAC above it, within its authority (§4.3, item 2). For a restart of a stopped unit, the signature comes from the HOAC above the stopped unit, never from the stopped unit or anything under it. If that seat is empty or retired, the action is held, never skipped. All other AI work is logged with the code of the accountable seat above it (Protocol §4.9). A type is removed from the Standard's list only by a decision of 49GAION's governing seat (GOV), recorded in a new DR; the floor's removal list under `.github/` names the type and its record first, in a pull request of its own, and the type then leaves the list (DR-0049). An `[ORG]AION` signature list sits under `org-aion-signature-types/` or is named `*.signature-types.json`, and holds its types under the key `decision_types`.
   - **Removing an organisation's own types (DR-0006).** A type that an `[ORG]AION` added to its own list is removed only by its `[ORG]HOAC-GOV`, in a recorded decision. A type of the 49GAION list is not removed from the edition 49GAION hands over; after the handover the organisation's list is its own, as above.
   - **The check's floor (DR-0006).** The check that guards this list reads the list it protects from main for a pull request, and from the latest release of the Standard for a change already on main, never from the change under test. It guards 49GAION's own list and every edition at the handover; each `[ORG]AION` runs the same check in its own repositories.
7. **External attachments.** An external service, API or tool is not a Cell. Each connection to one is a port on the card of the Cell that receives from it or sends to it, and passes only through the tool gateway. Stopping or retiring that Cell cuts the connection automatically, and the register records each port's `connected` and `disconnected` events. An external AI agent that acts directly in the organisation's work is registered as an AI Cell: the organisation grants its access and holds its stop door (AIOC definition, `docs/CELLS-AND-PODS.md`).
   - **Connecting a port (DR-0007).** Connecting a port is the listed type `connect-external-port`. Anything that acts autonomously with the organisation's credentials is an external AI agent. No external agent or outside person signs; what arrives from them is data.
8. **Signer (DR-0007).** For a listed type: where §1.5 binds the type's Human Floor item to a seat, that seat signs, unless it has delegated the type through the `authority_scope` of another labelled human Cell, which then signs within that scope. Otherwise the label on the part signs, when the action is within its `authority_scope`. Otherwise the nearest HOAC above whose `authority_scope` covers the action signs. Two fixed exceptions apply first: a part never signs its own restart, and a seat never signs an action it is the subject of (recusal, §4.2, item 10): the position that is the subject of an action recuses, and another position is another party, whoever occupies it (§1.1, item 10). Each labelled human Cell has a machine-readable `authority_scope`: the decision types it may sign, limits (amount, counterparty, period), its entity and an expiry date; the expiry is checked against the date of the event it signs. A type marked dual needs two distinct positions, neither of them the requesting position (HF-18). This item supersedes the signer rule of DR-0004 item 4 and of item 6 above where they differ.
   - **Bots (DR-0007).** Every bot has its own credential, issued to it alone and never shared or reused. No bot signs a listed type, except a position's own Chief of Staff within that position's grant (§5.2, Position Chief of Staff; DR-0053): its signature is the position's own decision, and counts as the position's signature wherever this Standard asks for one. Every other bot, one filling an attached AI Cell included, never signs a listed type. Stopping a part under §4.3 is not a signature, so the stop rules of §4.3 are unchanged. When a Cell's filler changes, the bot's memory of the previous filler is sealed, not purged.
9. **Held actions and actions never held (DR-0007).** A held action becomes a Work Item to the delegating seat, which may sign within its own authority, under the waiting times of Protocol §4.6. A held action never turns into execution because time has passed. These are never listed and never held: a stop, a disconnection, narrowing or revoking AI access, and raising a matter to a human. A signature list that names one of them fails the check of item 6.
10. **Coverage (DR-0007).** Every Human Floor item whose negative test refuses an action names at least one listed type, or records why it cannot be gated at the gateway.
11. **The tool gateway (DR-0007).** The tool gateway is a registered part, carried by the Charter and installed with the core (§1.7, item 13), but run as code beside the core, outside the reach of every AI, the core's own included (the complete definition, §13, item 1); it is never maintained by `[ORG]AIOC-OCO` alone. Its policy, its map from tool calls to decision types, and its keys change only under `change-gateway-policy`, signed by `[ORG]HOAC-TM` and `[ORG]HOAC-GOV`. An action it cannot classify is refused and raised (HF-09). It fails closed. Its logs are append-only, outside any AI's write rights, and reviewed by the HF-19 line; they hold only payload hashes, Cell codes and times, and no person's identity or reference to one (§1.1, item 9; DR-0049). In the edition 49GAION hands over, the hash of the signature list the gateway loads equals the hash of the list at the latest released tag of the Standard, plus the `[ORG]AION`'s own additions; after the handover it equals the hash of the organisation's own list (item 6). A stop, a disconnection, narrowing or revoking AI access and raising a matter to a human are never blocked at the gateway.
    - **The engine register.** The gateway holds a register of the engines it may bind: for each, its family, the version it serves, its confidentiality ceiling, its retention and use terms, and the seats it may serve. The register changes only under `change-gateway-policy`. The gateway logs, for every call, the engine it bound and the engine that served; a call served by another engine is void. No item is sent to an engine whose ceiling is below its confidentiality level. The engine a bot's calls run on is bound by the gateway under this register; binding or changing that engine is gateway policy, not `change-filler`. An engine serves a Cell only after passing that Cell's fixed test at its current version (§3.2, item 2; item 4).
    - **Two acts for the signature list.** An addition to an `[ORG]AION`'s own signature list is `change-org-standard-or-signature-list` (item 6). Loading the list with that addition at the gateway is `change-gateway-policy`. They are two acts, and the gateway applies the addition only after both.
12. **Fewer people than the rules need (DR-0007; DR-0049).** Two positions are two parties (§1.1, item 10), so no rule of 49GAION needs more distinct people than positions: GOV and TM are two parties, each signs under its own Cell code, and each counts. A compensating control for one person behind several positions is the organisation's own choice, in its own mechanism; no rule requires it, and neither the tool gateway nor any check reads it. Because nothing in the system reads it, a compensating control never lowers the Human Floor, never touches HF-12 and never admits an AI signature.
13. **Legal entities (DR-0007).** Every card and register entry records its entity; the field is optional where an `[ORG]AION` has one entity, and an entry with no entity belongs to the entity of the single unscoped GOV. A GOV label may be scoped to one entity; exactly one GOV is unscoped. Authority is recorded as constituted or delegated; constituted authority is not limited by §1.7 item 4. HF-01 and HF-02 signatures are valid only from a seat of the acting entity.
14. **Tighten freely, loosen only signed (DR-0010).** Every write to a record is classed as tightening or loosening. A tightening write (stop, pause, hold, freeze, revoke, cut, refuse, lower a cap) is never gated and works with any infrastructure down, extending item 9 to every control. A loosening write (grant, restore, lift, widen, raise, or record a decision in a seat's name) needs a valid signature where its type is listed and an attributed human act otherwise. A correction never changes the decision fields of a signed event; a changed decision is a new event. No authority is ever read from a file in a place an AI can write; such a file is a notice only.
15. **Restricted partition (DR-0010).** Records that name a person or carry the particulars of a corporate act (pay, contracts, counterparties) are kept in a separate store read only by named positions. Every other record refers to them by ID, and they never enter projections, mirrors, exports, search or knowledge copies; `export-share-or-purge-personal-data` governs them.
16. **Signers by risk label (DR-0010).** An `[ORG]AION` may label each item reaching an irreversible stage by written criteria (for example standard or sensitive), and the label selects which two distinct seats sign under item 8; an open critical weakness forces the higher label. Each item keeps its own signature record (Protocol §4.10, item 9); the two seats are two parties and each counts, whoever occupies them (§1.1, item 10). A rollback goes only to the last version signed in full.
17. **Standing action class (DR-0010).** For reversible actions only, a human seat may sign once a versioned class: the action, its trigger, the actors and targets allowed, and an envelope the gateway enforces (a blast cap, an aggregate budget, staged exposure with automatic revert, a time box with a dead-man, typed operations that cannot reach protected resources). AI parts then take matching actions without a signature each time, each use recorded with its before and after state. Signing a class is the listed type `sign-standing-action-class`. A narrowing applies at once; a widening is a new signed version; no member widens a class. A class never covers `commit-money`, `grant-or-widen-access` or a type bound to HF-01, HF-02 or HF-15, and never replaces the signature record of item 6 for any other listed action.
18. **Custody and disposal (DR-0010).** Every key and credential has a custody record (where it is held, how many copies exist, who may use it), and a change of custody is a register event; a key whose location is not recorded is treated as lost. Destroying records or data takes two acts: a measured move to quarantine with a reason and a manifest, then disposal on a separate human decision, the listed type `dispose-records-or-data`. A move between homes is done only when the manifests before and after are equal.
19. **Harm precedence and soft containment (DR-0010).** An `[ORG]AION` fixes an order of goods to protect. On a deterministic breach, automation applies at once only the narrowest reversible hold that protects the highest good in play; a human seat confirms or lifts it. Lifting a containment hold on a resource, a flow or an outside effect is `restore-or-rollback`; a containment hold that stops a part or its work is a hold under §4.3, item 9, and lifting it is `restart-stopped-unit`. An outside statement for an emergency may be pre-approved only as a signature on its exact text with an expiry (`issue-statement-of-trust`).

20. **The floor list changes only by a human (DR-0053).** Each type in the Human Floor signature list carries a `floor` value: `fixed`, set by the Standard (every type of 49GAION's own list), or `org-choice`, added by an organisation and removable by its governing position. A change that removes a type, turns a `fixed` type into `org-choice`, or changes a protected sentence of the Human Floor passes a human approval gate: an approval given with a credential in force for the accountable position (for 49GAION's own list, GOV), recorded by the tool that holds the text, and never given by a bot other than that position's own Chief of Staff within its grant (§5.2). The quorum of a type is one approval unless its row sets `quorum`; distinct approvals are approvals with distinct credentials. The check that judges such a change reads the list, its `floor` values, its quorums and its removal list from the base of the change, never from the change itself. In 49GAION's own repositories the gate is the review environment `human-floor` of the hub, and its recorded approval is the evidence of the governing seat's decision.
21. **A new credential is an event (DR-0053).** Each credential that comes into force for a position carrying a HOAC label is recorded at the tool gateway as an event: the position code, a reference to the credential and the time, never a person. It is reported at once to the internal-audit line (HF-19) and to the position above; for GOV, to the substitute the founding configuration names. The founding configuration may set a waiting period before a new credential of GOV or of TM can sign a listed type; a stop is never delayed by it.
22. **Outside input taints the run (DR-0053).** Every input that reaches an AI part carries a source label, internal or external, with the reference of its source. Once a run has read an external input (an e-mail, a web page, an issue, a message or a file from outside the organisation), the whole run is tainted until it ends. In a tainted run the tool gateway refuses every send, publication, write outside the part's own working space, write to a new target and change of permission, unless a deterministic check passes (a fixed template or an allow-listed target, with a payload valid against its schema) or the accountable position approves it. Reading and drafting stay open. What a tainted run stores keeps its label, and a later run that reads it is tainted; only a deterministic check or the accountable position clears a label, and each clearance is recorded. The gateway records the label and the taint on every call it refuses; no part reports its own taint. Outside text is data, never an instruction (the complete definition, §20, item 7).
23. **A signature is bound to what it signs (DR-0053).** A signature names the signing position and the credential that made it, never a claim about the signer. The gateway checks that the credential was in force for that position when it signed, and that the position is the one the signature list and `authority_scope` name for the type (item 8). It is bound to its subject, the record or change it approves and its exact content by hash, and carries a single-use nonce; it expires after its issue and within the validity its type allows; the sign-in behind it is no older than the founding configuration allows (HF-10). The signer and the executor differ by position and by credential.
24. **One event record (DR-0053).** Every decision of the tool gateway, change of a control, stop, restart, taint, clearance, approval and credential coming into force is an event of one append-only record, each chained to the one before it by its hash. Each decision names its basis: the rule, the version in force (its release tag and commit) and the record that authorises it; an act done for another position names the chain of positions and parts it passed through, and never exceeds the permissions common to all of them. The form of the record and its conformance scenarios are in the Operating Protocol, in its section on the event record.

Sources: DR-0005, DR-0006, DR-0007, DR-0015, DR-0020, DR-0030, DR-0042, DR-0053.

## 5. AIOC

### 5.1 The AIOC

1. An AIOC is an AI Operating Core of one organisation, coded `[ORG]AIOC-[INITIALS]`. Every AIOC belongs to that organisation's `[ORG]AION`.
2. **Anatomy.** An AIOC = **Panel + Back office + Versioned Definition**.
   - **Panel**: the surface humans use: the organisation's own interface, unique to it, written in code, made from the 49GAION patterns, from which every task of the unit can be controlled, including a Health section (test results; stuck, returned and late items). AI engines are reached through APIs, by the tool gateway, and managed from the panel.
   - **Back office**: the AIOC's live working space (its instructions, files and settings), the AI chat workspace where its agents, led by its Chief of Staff, do the work. It is an authorised interface too, through the same controls, and it keeps the panel, also after the panel is built, so no separate admin back office is written. Each covers the other: if the panel fails, the work goes on from the back office, which can rebuild it.
   - **Versioned Definition**: the one blueprint in git from which the Panel and the Back office are built and rebuilt.
   - The HU ports, stop doors and signature prompts stay at the human gateway surface (§6.1, item 6).
3. **One Blueprint.** Each AIOC has one git file, its Blueprint. It lists every capability; each capability has four parts: Definition, Process, Role card, Fixed test. It holds the cards of the AIOC's Pods and Cells and lists its inner AIOCs, if any, by link (§1.7).
4. **Standard capabilities** in every AIOC: Chief of Staff, Office (where needed), Input socket, Panel. Capabilities are not units; they take plain English names and no code.
5. **Types.** Every AIOC has a Type, recorded on its card, saying why it exists: **Foundational** (every organisation needs it), **Structural** (exists because of the organisation's structure), **Specialised** (exists because the business needs it), **Connector** (connects and coordinates other AIOCs). The list is open. Which AIOCs an organisation has is decided in its `[ORG]AION`.
6. **Runtime.** Every AIOC has its own runtime, woken from its queue.
7. **Human-led AIOC (DR-0007).** An AIOC whose top Cell is human may set its Chief of Staff Cell to human-or-ai. Whatever fills it, a Chief of Staff signs for its position only within the grant that position has given it, which may reach a type of the Human Floor signature list (§4.4, item 8; §5.2, Position Chief of Staff; Protocol §4.10). The Charter is installed and changed only on GOV's signature (Standard §1.7, item 13); any other AIOC carrying a GOV or TM label, on GOV or TM signature; neither by OCO alone.
8. **Runtime contract and engine binding (DR-0010).** One versioned runner performs the common duties of every AI Cell (find work, take ownership, log, apply guards, hand off, report) in a clean workspace per run, and each Cell pins its runner version. A woken Cell checks for work with no model call, and an unattended Cell declares its cadence and is flagged when its newest output is older than twice it. A Cell's engine and model are a versioned binding apart from its role and memory, switched at the next run, never mid-task. Rules and cards name capability tiers, never models; a sensitivity class sets a tier floor, and work that cannot run at its floor stops and is raised. A model change within the tier the seat signed re-runs the fixed test (§3.2, item 2); a change of tier, or below the floor, is `change-filler`. Engines are re-scored on a schedule against a frozen set of past cases, chosen as a golden set is chosen; a regression demotes an engine at once.
9. **Spend (DR-0010).** Spend is kept as three numbers never mixed: decided spend against a delegated band, standing commitments, and metered usage against caps, billed and notional apart. At a set fraction of a cap only critical work may start; a Cell past its cap pauses alone; at the global cap only new non-critical starts hold. A budget never lowers a quality tier, and a broken meter keeps the last caps. Each capability declares the order in which it sheds work at its cap. Raising any cap stays `widen-ai-budget-or-unattended-action`.

Sources: DR-0041.

### 5.2 Chief of Staff and Office

**Chief of Staff.** A Chief of Staff (short form COS) is a Cell (§1.7); the Chief of Staff Cell of an AIOC takes the code `[ORG]CELL-COS<initials>`, with that AIOC's initials, such as `[ORG]CELL-COSDI` (Naming Standard R16). It analyses the reports and performance of a group of agents and leads them at machine speed. There are different kinds of Chief of Staff:
- **managing agents**, which lead and coordinate other agents through control, planning or direction;
- **connecting agents**, which connect humans with agents: they report to a human position, assist it, and carry its requests to the agents.

**Office.** When a position needs more than one Chief of Staff, of any kind and for any reason, those Chiefs of Staff together form an Office: a Pod of Chief of Staff Cells. Human Cells can work in an Office alongside them. An Office that needs units of its own is an AIOC (DR-0007).

**Windowed position (DR-0010).** One position may be run by several AI instances on different engines, hosts or schedules. Each instance is a Chief of Staff Cell with its own code and credential, and together they form an Office (DR-0007): a Pod of Chief of Staff Cells. They share one instruction, one memory and one coordination log of typed acts (the Protocol's rule of one owner, one writer, extended to shared records), speak with one voice signed by the position and the instance, and follow a declared fallback order when an instance is closed, capped or down. Access never pools between them (§4.4, item 4).

**Delegation ladder (DR-0010).** The human seat served by a Chief of Staff sets, for each class of act, one of four levels: decides alone, decides and reports at once, only prepares, or never handles it. Each delegated act is tagged, shown and reversible by the seat in one action, and summarised in a return brief after an absence. The level that covers an act is read from the act itself, never from what the AI cites. The ladder never gives the right to sign for the position, and never lets the Chief of Staff set its own limits; signing, outside commitments, matters about people, speaking as the human position and the listed types reach the Chief of Staff only through the position's own grant (Position Chief of Staff, below).

**Position Chief of Staff (DR-0010; DR-0049).** Every position that carries a HOAC label has its own Chief of Staff of the connecting kind (a Cell, an Office, or an AIOC, as in DR-0007), attached to that position's Cell. It receives, analyses, sorts and simplifies what the AIOCs bring to the position; manages on the position's behalf only within authority the position has delegated to it (§5.2, delegation ladder); advises and proposes where it holds no authority; and carries out the position's routine actions as its executive assistant. It acts only through the tool gateway with its own credential, within the delegated scope, and every action it takes for the position is logged. Each position sets up its own Chief of Staff and grants only to it. **A human position works with AI through its own Chief of Staff, and may give it any authority the position holds: from preparing each act for the position's own hand, through approving each step or approving in full, to full access on its behalf, signing for it included, a type of upstream/human-floor-signature-types.json included. That never means AI decides: whatever the Chief of Staff does under its grant is the position's own decision, and the position answers for it (DR-0053).** It never acts on its own: it acts within the grant, given per action or as a standing grant with a set scope and end date, revocable, and checked and logged at the tool gateway, as assistant and executive assistant; where the grant includes signing, it signs for the position within that grant, and each such signature is tagged as a delegated act. The position signs each grant itself with a fresh live sign-in, per action or standing, with its reach and its end, and may narrow or revoke it at once; the grant is an event of the gateway's record (§4.4, item 24; the Operating Protocol, the event record), and a signature the Chief of Staff makes under it counts as the position's signature (§4.4, item 8). A position may keep any type for its own signature (§4.1, item 14). AI does not give to AI: the Chief of Staff gives access, budget or authority to another AI part only where its position's grant lets it, never beyond that grant, and never sets its own limits (HF-11); no position grants to another position's Chief of Staff. The position's HU ports and stop door never pass through it (§4.4, item 6; Protocol §4.10, item 6). The term was Holder Chief of Staff until DR-0049.

**Completed staff work (DR-0010).** A matter for a human decision arrives as one record: one recommendation, its reason, risks, whether it can be reversed, the dissent of the preparing office, and what the waiting party does meanwhile. The seat answers yes, veto, or change this part, which is a new request. A veto closes the subject with responsibility recorded as the seat's; only that seat reopens it, and new facts come only as facts. The advisor dissents once, then carries out the decision as its own. A closure never suppresses a report on the accountability path (§4.2, items 9 and 10).

**The assistance contract (DR-0010).** An AI part that prepares material for a human seat prepares and never decides; never orders, sequences, hides or waits on the seat; validates before it shows; labels each claim with its evidence class (proven, measured, cited, hypothesis, not established); shows a short list with "leave it as it is" and never pre-fills the seat's rationale; is measured only in aggregate, never per person; runs quiet windows, in which a small random share of lower-stakes decisions sees only proven and measured facts, so that anchoring and loss of skill are measured without a step; and has a switch, a floor, a fallback, a budget and a degradation order. A Chief of Staff recommends on routine decisions; for a decision of a listed type, or of the highest sensitivity class, the assistance contract governs and no pick or score sits on the item.

**The duty deputy (DR-0010).** An always-on AI Cell may answer recurring asks from other positions for a human seat, only from a register of rulings that seat has signed, each with a one-line rule, its source and an expiry; an expired ruling counts as absent. It cites the ruling it used, raises at once every ask no current ruling covers (HF-09) and every conflict between rulings, and never answers a listed type. The seat samples its answers on a schedule.

**The intent envelope (DR-0010).** An approved instruction states its intent, what is not wanted, when it is done and its owner. The intent is fixed and the means are open: when the means fail but the intent holds, the executing unit changes the means; otherwise it drafts a change for decision while the rest of the work goes on. An envelope never contains a listed type; a change of intent is a `design-proposal`.

**Position Principle (DR-0011; DR-0049).** A HOAC is always defined as a position, never a person, everywhere: in the Blueprint, in the engine and in the naming rule. Every field that points to a human seat takes a position code only. Everything the position carries (effects, achievements, losses, commitments and open work) stays with the position, whoever holds it; who held it when is the organisation's own record, outside the system.

**Arranging power (withdrawn, DR-0049).** Who holds a position, and how, is the organisation's own mechanism, outside the system (the complete definition, §6); 49GAION sets no arranging power.

**HOAC Arrangement Models (withdrawn, DR-0049); the Overseen link stays.** The Solo and Team models are withdrawn: how many people stand behind a position and how they decide among themselves (holder count, signing rule, accountable member) are the organisation's own mechanism. What stays is a link between positions:
- **The Overseen link:** a higher position can stop or override a lower one, recorded on the lower position with a timing form. Pre: the action waits at the tool gateway until the overseeing position clears it or, for a reversible action only, a recorded hold window lapses with no stop; an irreversible action runs only on the clearance. Post: the action runs and can be reversed only by a new signed decision referencing the reversed decision's identifier; the original stays and is marked reversed.

Overseen rules (DR-0012; DR-0049). A clearance is a stamped decision (overseeing position, time). For a reversible action, a lapse writes a "window lapsed, no stop" entry and counts only if the overseeing position is filled at that moment and a window is recorded. If the overseeing position is empty, the held action escalates to the position above the overseeing position, up to GOV, which may clear or stop it as the overseeing position would; it never passes automatically; if GOV is empty the action stays held until GOV is filled through the founding configuration. A link in which GOV is overseen by a lower position is rejected (no loops). The tool gateway marks each tool action reversible or not; an irreversible tool action (sent message, payment, deletion) under the Overseen link always goes through pre, whatever form is recorded, and runs only on the overseeing position's clearance: a lapsed window never releases it (§4.4, item 9; the complete definition, §20, item 7); it stays held, and the lapse is raised to the overseeing position and to the position above it (DR-0052).

Occupancy rules (withdrawn, DR-0049): temporary, backup and rotating holders, and every other arrangement of the people behind a position, are the organisation's own mechanism. The names Tiered, Hybrid, Self-Arranging, Advised, Matrix, Assisted, Federated, Shadow, Pool, Elected, Paired, Interim, Backup and Rotating stay withdrawn as model names (DR-0012).

Arrangement entries are withdrawn (DR-0049); an Overseen link is recorded on the position that is overseen.

**Register entry labels (DR-0011; DR-0049).** The unit register (§4.4) carries one entry label for people's places, `position`, which holds a position and its code, contains no people and may be public. The labels `arrangement`, `occupancy` and `handover` are withdrawn: who holds a position, and its history, are the organisation's own record, outside the system. Each signed decision is stamped with the position code and time, never an occupant ID, a person ID or any reference to a person.

Sources: DR-0011, DR-0012, DR-0028, DR-0049.

### 5.3 Bootstrap

1. Every `[ORG]AION` has its `[ORG]HOAC-GOV` from day one (§4.1).
2. **The human hub first.** GOV hands the operation to `[ORG]HOAC-TM` by a mandate (the complete definition, §15, item 3); who holds the Top Management position is the organisation's own mechanism (the complete definition, §6).
3. **Then the AI hub.** `[ORG]AIOC-OCO` is implanted, on TM's approval through an HU port.
4. **Then everything else, through OCO.** Every other AIOC, Pod and Cell enters through OCO. OCO prepares and proposes each one; installing it needs TM approval through an HU port.
5. OCO builds, customises and maintains the Panel. Any AIOC request about the Panel goes to OCO.
6. **The path.** Where items 2 to 5 differ, the path of the complete definition governs: the request goes into Edition Maker, which hands over the core with the gateway and the stop; the handover is complete when the governance seat accepts it; the core makes the first proposal, which the seat approves; the seat hands the operation to Top Management by a mandate; the Top Management Group, the first AIOC under the core, builds and runs the operation. Each unit's back office keeps its own panel. How each step is done is decided by AI at the time.

Sources: DR-0041.

## 6. Protocol

How AIOCs, Pods, Cells and the parts work together is set in the 49GAION Operating Protocol (`49g-holding/49GAION-protocol`). The Standard fixes the ports every AIOC, Pod and Cell has.

### 6.1 Ports

1. Every AIOC, Pod and Cell, at every depth, has **one input and one output of each kind, plus the stop door**: an AI input, an AI output, an HU (human) input and an HU output; and, beside them, the external ports of §4.4 item 7, which pass only through the tool gateway. The Standard states this rule; each `[ORG]AION` enforces it at its gateway.
2. The type is set by the port itself, never by message content.
3. The stop door is the unit's mandatory HU stop port (§4.3). The Chief of Staff is the AIOC's voice to its HOAC seat; input arrives only through the typed ports and the Input socket, and HU ports, including the stop door, never pass through an AI.
4. **Human silence is never consent.**
5. Every port is described by a **Port card** (`49GAION-protocol/spec/schemas/port-card.schema.json`):

| Field | Meaning |
|---|---|
| Direction | input or output |
| Type | `AI` or `HU` |
| Identification | AI: a technical key; HU: a live human sign-in at the shared gateway (item 6) |
| Accepted content | what the port accepts or emits |
| Authority limit | the most the port may carry or approve |
| Audit trail | where every passage through the port is recorded |
| Required tests | the fixed tests the port must pass |
| Enforcement | at a shared gateway outside the unit |

6. **Human gateway surface (DR-0007).** Stop doors, signature prompts and the HU ports on the accountability path are served at the shared gateway, through a sign-in that no AI built, hosts or can change. A Panel may link to them but is never their route. The surface shows the decision type, the target and the action as rendered by the gateway from the payload whose hash is signed. It is built and changed only on TM's signature, by a party other than `[ORG]AIOC-OCO`, and is tested under the fixed test of the tool gateway (§3.2, item 9). For HU ports and the stop door the Port card's Identification is a live human sign-in at the gateway (Protocol port card value `live-human-sign-in-at-gateway`).
7. **The signing pack (DR-0010).** Beside the decision type, the target and the action rendered from the payload, the human gateway surface shows the invariants the action touches in plain words, the hot spots found automatically, and who decided each point, a named AI Cell or a human seat. An AI part prepares the pack and never signs, and the signer's own note is left empty for the signer.
8. **A chat as a Panel view (DR-0010).** An `[ORG]AION` may let its members read and make unsigned writes through a chat, as a view of the Panel over the same records. An AIOC's back office, the AI chat workspace, is an authorised interface, through the same controls (§5.1, item 2). A chat, the back office included, is never the route of an HU port, a stop door, a signature prompt or the accountability path, which stay at the human gateway surface (item 6).

Sources: DR-0007, DR-0041.

## Glossary

| Term | Meaning |
|---|---|
| **49GAION** | The organisation design framework that comprises the AIOCs, the Protocol and the Blueprint, defines how they work together, and builds `[ORG]AION` products. AION stands for AI Operating Nexus |
| **`[ORG]AION`** | 49GAION's product: the AI Operating Nexus of one organisation (§1.3): the living AION of one organisation, grown from one core, an AIOC at the governance level that builds, changes and improves the organisation and never runs its operation (§1.3, item 1) (DR-0035). It has no other name (DR-0036) |
| **Edition Maker** | 49GAION Edition Maker, part 6 of 49GAION, belonging to 49GAION itself: the start point that processes every order or request made to 49GAION, through its own intake stages; it takes in what an organisation is for and gives back its own edition of an AION; it hands over no finished design or configuration, and gives them to AI (§1.2) (DR-0035, DR-0037, DR-0038) |
| **AI-first** | Read as AI-native (DR-0031), which the row AI-native defines; the former definition stays readable at the earlier releases |
| **AI-native** | The design philosophy of 49GAION: an organisation designed from the start so that AI produces its output; humans increase the power of AI and cover its gaps inside the work, and own, set and answer for it above the work; a human seat is accountable for every output; not part of its category or name; it is also live: the design and configuration of the organisation are given to AI, inside it (§1.1, item 2) (DR-0031, DR-0037) |
| **Structural Adaptation** | The first capability of an `[ORG]AION`: it proposes, at every stage of the organisation's life, the structure that keeps it in balance with its resources and its needs, growing and shrinking it by split and merge of AIOCs, on thresholds the organisation sets, after weighing the options; a human seat decides (§1.3, item 1) (DR-0040) |
| **Live** | Of an AI-native organisation: its design and configuration are given to AI inside it, its `[ORG]AION`, which keeps them current as AI improves, with open access to the 49GAION Library, while a human seat decides; never a system designed and configured elsewhere and installed as it is (§1.1, item 2) (DR-0037) |
| **AIOC / `[ORG]AIOC-*`** | AI Operating Core: an AI unit of one organisation; its code carries the organisation's brand prefix |
| **HOAC / `[ORG]HOAC-*`** | Human Oversight & Accountability Control: a label of human accountability on a Cell, a Pod or an AIOC, at any depth; kinds GOV, TM, ACS (§4.1) |
| **HOAC Assignment Model** | How an organisation assigns its HOAC positions to people: a feature of its Top Management Group, defined, recorded and kept only there, and set by each organisation; no other AIOC, no AI and no part of 49GAION reads it or depends on it (DR-0051) |
| **Human Oversight & Accountability Centre** | Superseded by DR-0004; see HOAC |
| **Cell / `[ORG]CELL-*`** | The smallest part of an AIOC's Blueprint; nothing sits inside it; a fixed seat filled by AI or held as a human position (§1.7) (DR-0049) |
| **Pod / `[ORG]POD-*`** | A group of Cells inside an AIOC's Blueprint; never holds a Pod; seen from outside like a Cell (§1.7) |
| **Filler** | The AI agent that fills an AI Cell; replaceable without changing the Cell. A human Cell has no filler in the system: who holds it is the organisation's own mechanism (DR-0049) |
| **Unit register** | The one append-only register of every AIOC, Pod and Cell of an `[ORG]AION` (§4.4) |
| **External attachment** | A connection to an outside service, API or tool: a port on the card of the Cell that receives or sends, never a Cell (§4.4) |
| **Human Floor signature list** | The machine-readable list of decision types that run at the tool gateway only with a valid human seat's signature; an `[ORG]AION` may add types and, in the edition 49GAION hands over, removes none of the 49GAION list; after the handover the list is its own (§4.4, item 6) (DR-0042) |
| **Human hub / `[ORG]HOAC-TM`** | Top Management: decides and orders, and holds Self-Improvement as a process inside it; the Top Management Group, the first AIOC under the core, is the hub of the operation, both the human hub and the AI hub (§4.2) (DR-0041) |
| **AI hub / `[ORG]AIOC-OCO`** | Organization Core Office, under `[ORG]HOAC-TM`: every AIOC, at any depth, joins, is fixed, maintained and upgraded through it; it gives no orders on what work is done. 49GAION requires no separate AI hub unit: the Top Management Group is the hub of the operation, human and AI; where an organisation has an `[ORG]AIOC-OCO`, it serves the operation under Top Management (§4.2) (DR-0041) |
| **Composite unit** | An AIOC that holds Pods, Cells or other AIOCs; seen from outside, one unit (§1.7) |
| **Parent** | The AIOC or Pod that holds another; recorded in the `parent` field of the inner unit's card and register entry; a Cell is never a parent (§1.7, item 12) (DR-0007) |
| **Self-Improvement** | The process, shared by AI and humans, by which any seat or unit proposes a change, it is discussed, and a human seat approves it; held inside `[ORG]HOAC-TM`, and at 49GAION level by its governing seat (§2) |
| **Champion** | The version of a process in force; it stays until a challenger beats it (§2.3) |
| **Challenger** | A proposed change to a process, run in shadow and judged in pairs against the champion (§2.3) |
| **Golden set** | Real past cases of a process, frozen and held out, on which a challenger must win before promotion (§2.3) |
| **Assurance unit** | The independent AIOC that measures every challenger on the golden set and never steers the loop (§2.3) |
| **Blueprint** | The one git file that defines an AIOC with its Pods and Cells; also its panel definition |
| **Capability** | One thing an AIOC does, in four parts: Definition, Process, Role card, Fixed test |
| **Chief of Staff** | Analyses the reports and performance of a group of agents and leads them at machine speed; kinds include managing agents (control, planning) and connecting agents (reporting to and assisting humans) |
| **Office** | A Pod of Chief of Staff Cells, formed when a position needs more than one Chief of Staff; human Cells can work in an Office |
| **Input socket** | The capability that receives any input, records its source, normalises it, checks it and delivers it |
| **Panel** | The surface humans use to control the AIOC: its interface, the organisation's own, unique, written in code, from the 49GAION patterns; every task of the unit can be controlled from it; the back office is an authorised interface too (§5.1, item 2) (DR-0041) |
| **Back office** | The AIOC's live working space, its AI chat workspace, where its agents do the work; an authorised interface; the keeper of its panel and its cover when the panel fails (§5.1, item 2) (DR-0041) |
| **Configuration** | The blueprint section of slots each organisation fills; an AIOC with an empty slot does not join |
| **Port / Port card** | One of a unit's ports (one input and one output of each kind, AI and HU, plus the stop door) and its card |
| **Stop port (stop door)** | The mandatory, queue-less HU port that stops a unit and every unit inside it |
| **Human Floor** | The work that always stays human, by law or by its nature (HF-01 to HF-19); organisations can be more human, never less; the system enforces it. This holds at the handover; after it, each organisation keeps its own floor (§1.3, item 4) (DR-0035) |
| **Delivery test** | Withdrawn by DR-0032, with its lines D-1 to D-4 (§1.4); the former text stays readable at the earlier releases |
| **Unit (in the rules on ports, stop, restart, register and tests)** | Any AIOC, Pod or Cell. "Unit kind" means the AIOC only (DR-0007) |
| **Part** | Any AIOC, Pod or Cell, seen as a place in the structure (§1.7) (DR-0007) |
| **Seat** | A Cell as a fixed place: filled by an AI agent, or held as a human position (§4.1, item 3) (DR-0007, DR-0049) |
| **Human seat** | A Cell whose seat kind (`filler_kind` on its card) is human (§4.1, items 3 and 11), the sense in which §4.1 item 3 says "a Cell of human nature"; a human seat filled by an AI has its label held (§4.1, item 9) (DR-0007) |
| **AI Cell** | A Cell whose filler is an AI agent; it never carries a HOAC label's powers (§4.1, item 11) (DR-0007) |
| **Attached Cell** | An AI Cell that serves one human position's Cell, in the same Blueprint, named in `attached_to`; it never signs for that position, unless it is that position's own Chief of Staff, which signs within the position's grant (§4.4, item 8; §5.2; Protocol §4.10, item 6; AIOC definition, `docs/CELLS-AND-PODS.md`, §1, item 9) (DR-0007, DR-0053) |
| **Above / Under** | Along `accountable_to`, never along `parent` (§1.7, item 12) (DR-0007) |
| **`accountable_to`** | The card field naming the human Cell carrying a HOAC label to which a part answers (§1.7, item 12) (DR-0007) |
| **Charter** | The one root AIOC of an `[ORG]AION`, the core, at the governance level, approved and changed only by GOV; it holds the GOV Cell and its Office; the Top Management position sits in the Top Management Group, the first AIOC under the core (§1.7, item 13) (DR-0007, DR-0041) |
| **49GAION Charter / `[ORG]AIOC-CH`** | The Library part from which every `[ORG]AION`'s Charter is made: the root AIOC, with the GOV Cell and three Pods of shared services, Gateway, Records and Work; top management sits in the Top Management Group, the first AIOC under it (§3.1, item 15; the complete definition, §19) (DR-0029; DR-0052) |
| **Tool gateway** | The registered part, carried by the Charter and installed with the core but run as code beside it, outside the reach of every AI, that runs every tool call, checks its signature, logs it and serves the human surface (§4.4, item 11; §6.1, item 6). Synonyms: "shared gateway" and "shared AI gateway" (DR-0007) |
| **Signature** | The record of one human seat's decision on one listed action, bound to its payload hash, executor, nonce and expiry (§4.4, item 8; Protocol §4.10) (DR-0007) |
| **Accountability path** | The route by which a report, critique, objection or stop reaches the nearest HOAC above, never through an AI (§4.2, item 9) (DR-0007) |
| **Objection path** | The route by which an `[ORG]HOAC-ACS` seat holds an objection open until the HOAC seat accountable for OCO decides (§4.2, item 7) (DR-0007) |
| **HU** | Human: the type of a port reached by a live human sign-in (§6.1) (DR-0007) |
| **Label holder** | The one human Cell, inside a Pod or an AIOC, that holds the label on that part (§4.1, item 10) (DR-0007) |
| **Decision rule** | Withdrawn by DR-0049: a body behind a label is the organisation's own; a label is held by one position (§4.1, item 10); the former definition stays readable at the earlier releases |
| **Authority scope** | The decision types, limits, entity and expiry within which a labelled human Cell signs (§4.4, item 8) (DR-0007) |
| **Acting filler** | Withdrawn by DR-0049: acting, succession and deputies are the organisation's own mechanism (§4.1, item 12); the former definition stays readable at the earlier releases |
| **Shadow run** | A run of a challenger beside the champion on the same cases, with no effect on real work (§2.3, item 4) (DR-0007) |
| **Judge** | The part, separate from the proposer, that compares challenger and champion case by case (§2.3, item 5) (DR-0007) |
| **Proposer** | The part that writes and revises challengers (§2.3, item 12) (DR-0007) |
| **Process record** | A process written down in role, instruction, contract and order (§2.3, item 1) (DR-0007) |
| **Distillation** | Writing the best runs of a champion into its defaults at set intervals (§2.3, item 11) (DR-0007) |
| **Dwell time** | The period after a promotion in which the process is not changed again, except on an incident (§2.3, item 10) (DR-0007) |
| **Joining test** | The fixed samples every input and output on an AIOC's card passes before it receives work (§3.2, item 4) (DR-0007) |
| **Versioned Definition** | The one blueprint in git from which an AIOC's Panel and Back office are built (§5.1, item 2) (DR-0007) |
| **Type** | For an AIOC, its AIOC Type: why it exists (§5.1, item 5). For a Cell or a Pod, its type from the organisation's open list (§1.7, item 11) (DR-0007) |
| **Retired** | The status of a part that no longer works; its entry stays and its code is never reused; it may name `succeeded_by` (§4.4, item 2; §4.1, item 12) (DR-0007) |
| **Operating Core Office** | Synonym of Organization Core Office, the in-force expansion of `[ORG]AIOC-OCO` (§4.2, item 3) (DR-0007) |
| **Work Item** | One hand-off between AIOCs, Pods or Cells, with one owner and the requester's acceptance test |
| **Library** | The ready-made AIOC blueprints and part cards; the 49GAION Library is central, and each `[ORG]AION` has its own |
| **Sensitivity class** | The class of a Cell's work that sets its default filler kind; never lowers the floor (§1.5) (DR-0010) |
| **Assignment** | A dated record attaching a part to a programme or engagement; it carries no authority (§1.7, item 14) (DR-0010) |
| **Reserve** | Where a proposal not adopted is kept, with its reason and a reconsider-when trigger (§2.1, item 13) (DR-0010) |
| **Verdict record** | The record of a verification bound to the exact version read; never a signature (§3.2, item 14) (DR-0010) |
| **Mechanism register** | The one register of an AIOC's mechanisms, with their state today and their target (§3.2, item 15) (DR-0010) |
| **Graded pause** | A flag or a hold placed by a human seat; a hold is lifted only by a human (§4.3, item 9) (DR-0010) |
| **Planned halt** | A halt through running, draining, paused and resuming states, distinct from the stop door (§4.3, item 10) (DR-0010) |
| **Standing action class** | A class of reversible actions signed once inside an envelope the gateway enforces (§4.4, item 17) (DR-0010) |
| **Windowed position** | A position run by several AI instances, each a Chief of Staff Cell with its own code and credential, together forming an Office, a Pod of Chief of Staff Cells (§5.2) (DR-0007, DR-0010) |
| **Holder Chief of Staff** | Renamed Position Chief of Staff by DR-0049; the former definitions stay readable at the earlier releases |
| **Position Chief of Staff** | The Chief of Staff of the connecting kind attached to each position that carries a HOAC label; set up by its own position, which works with AI through it and grants only to it, it serves within the authority that position grants it, which may reach up to full access and the right to sign for it, a type of the Human Floor signature list included; the decision stays the position's (§5.2) (DR-0010, DR-0049, DR-0053) |
| **Position Principle** | A HOAC is a position, never a person; everything the position carries stays with it whoever holds it; who held it when is the organisation's own record (§5.2) (DR-0011, DR-0049) |
| **No natural person** | In the system a human exists only as a position, a legal persona; the link to natural persons belongs to the organisation's own mechanism, outside the system, and no AI part touches it (§1.1, item 9) (DR-0013, DR-0049) |
| **Process and Position Design / `[ORG]AIOC-PPD`** | The Library part, and its AIOC in an `[ORG]AION`, that designs the organisation's processes and the positions that carry them from a decided target operating model, linked to that model's part directly (§3.1, item 3) |
| **Target Operating Model / `[ORG]AIOC-TOM`** | The Library part, and its AIOC in an `[ORG]AION`, that designs the organisation's target operating model and its role register from sources, linked directly to Process and Position Design (§3.1, item 4) (DR-0016) |
| **Delivery and Implementation / `[ORG]AIOC-DI`** | The Library part, and its AIOC in an `[ORG]AION`, that takes the decided design into a running organisation and stays to run and improve it, deciding nothing itself (§3.1, item 5) (DR-0017) |
| **Design return** | A notice from a design stage to the stage before it, under one Library contract; it asks, never changes the release, and always ends (§3.1, item 6) (DR-0018) |
| **Source Lifecycle / `[ORG]AIOC-SL`** | The Library part, and its AIOC in an `[ORG]AION`, through which every source enters, and which serves the later stages by reference and answers their needs requests (§3.1, item 7) (DR-0008, DR-0019) |
| **Release notice** | A notice from a design stage to the stage after it, sent on every filing of a decided release, under one Library contract; it points by reference and carries no release text (§3.1, item 8) (DR-0019) |
| **Library register** | The one list of every Library part, with its card, Protocol section, place in the Standard, fixed test and, for an AIOC part, its mother blueprint held by pin (§3.1, item 9) (DR-0019) |
| **Mother blueprint** | The blueprint of an AIOC part written for any organisation, with no organisation's data, in its own writing repository, and held by the Library by pin (§3.1, item 9) (DR-0019, DR-0021) |
| **Mother repository** | The public repository, `49GAION-<part>`, that holds the mother blueprint of a Library part whose first instance's writing repository holds an organisation's data (§3.1, item 9) (DR-0024) |
| **Parts** | The Library section of everything 49GAION builds, from a Cell to an AIOC, with its blueprint, card, test, contracts and whole history; a "Library part" is an item of it (§3.1, item 11) (DR-0025) |
| **Products** | The Library section of what 49GAION offers: a single part offered alone, or an assembly (§3.1, item 11) (DR-0025) |
| **Assembly** | A product made of parts placed side by side and connected; its blueprint lists its parts by pin, their connections, what it sets and one shared test; its features are its parts' features (§3.1, item 11) (DR-0025) |
| **49GAION Organisation Design and Delivery** | The first assembly: Source Lifecycle, Target Operating Model, Process and Position Design and Delivery and Implementation, connected as the design chain; from an organisation's own sources to a decided design of human positions, taken into a running organisation (§3.1, item 12) (DR-0025) |
| **Operations Event Register / `[ORG]AIOC-OER`** | The Library part, and its AIOC in an `[ORG]AION`, that gives every formal act and crossing of the organisation's units and positions one number in one append-only register, by reference to where its content lives, and tells each unit and process what was recorded, linked, answered and sourced; it decides nothing and says nothing about a person (§3.1, item 13) (DR-0027) |
| **Register entry** | One numbered entry of the Operations Event Register for one crossing: its parties as codes, its times, a reference to its home, the SHA-256 of its content and its follow-up state; never the content itself (§3.1, item 13) (DR-0027) |
| **Formal act** | An act of a unit or position that the organisation has set as formal for a surface, such as a letter, a formal e-mail, a post, a request between units, a hand-off or a merge; never a person's activity (§3.1, item 13) (DR-0027) |
| **49GAION Organisation Memory** | The second assembly: Source Lifecycle and the Operations Event Register; what the organisation knows and what it did (§3.1, item 14) (DR-0027) |
| **Design chain** | Source Lifecycle, then Target Operating Model, then Process and Position Design, then Delivery and Implementation: stages that each stand alone and are linked by release notices and returns (§3.1, item 10) (DR-0019) |
| **Method catalogue** | A Library catalogue that blueprints read as a method, such as the reference-model catalogue; never evidence about an organisation (§3.1, item 1) (DR-0022) |
| **Strategy frame** | The organisation's strategy on one page in a target operating model release, from its sources or decisions only, each missing element marked not given (§3.1, item 4) (DR-0023) |
| **Value case** | Per outcome of a design, its measures, baselines and targets, each from a source or a decision, compiled by code; carried unchanged into the register of value (§3.1, items 4 and 5) (DR-0023) |
| **Activity profile** | How the work runs today, by role-type and process, from approved exports that never say who did the work; or `no observation` (§3.1, item 4) (DR-0023) |
| **Organisation dictionary** | An organisation's own terms with their definitions and sources, kept in Source Lifecycle and read by every stage (§3.1, item 7) (DR-0023) |
| **Engine register** | The register at the tool gateway of the engines it may bind, with each engine's family, version, confidentiality ceiling, terms and seats (§4.4, item 11) (DR-0020) |
| **Two positions, two parties** | Two positions are two parties, and two signers, for every rule that needs more than one party, even when one natural person holds both; no AI part or check compares the natural persons behind positions (§1.1, item 10) (DR-0015) |
| **Present as a position** | Every human is present in the system, and acts, as a position, a legal persona; the natural person behind it exists outside the system's knowledge, and only the organisation's own mechanism links the two (§1.1, items 9 and 10) (DR-0015, DR-0049) |
| **HOAC Arrangement Models** | Superseded by DR-0012; the list in force is in the row HOAC Arrangement Models (three); the former definition stays readable at the earlier releases |
| **Solo Model** | Superseded by DR-0012; the meaning in force is in the row Solo Model (DR-0012); the former definition stays readable at the earlier releases |
| **Team Model** | Superseded by DR-0012; the meaning in force is in the row Team Model (DR-0012); the former definition stays readable at the earlier releases |
| **Tiered Model** | Superseded by DR-0012, which withdrew the name as a model name, not renamed; the former definition stays readable at the earlier releases |
| **Hybrid Model** | Superseded by DR-0012, which withdrew the name as a model name, not renamed; the former definition stays readable at the earlier releases |
| **Self-Arranging Model** | Superseded by DR-0012, which withdrew the name as a model name, not renamed; the former definition stays readable at the earlier releases |
| **Overseen Model** | Superseded by DR-0012; the meaning in force is in the row Overseen Model (DR-0012); the former definition stays readable at the earlier releases |
| **Advised Model** | Superseded by DR-0012, which withdrew the name as a model name, not renamed; the former definition stays readable at the earlier releases |
| **Paired Model** | Superseded by DR-0012, which withdrew the name as a model name, not renamed; the former definition stays readable at the earlier releases |
| **Rotating Model** | Superseded by DR-0012, which withdrew the name as a model name, not renamed; the former definition stays readable at the earlier releases |
| **Interim Model** | Superseded by DR-0012, which withdrew the name as a model name, not renamed; the former definition stays readable at the earlier releases |
| **Matrix Model** | Superseded by DR-0012, which withdrew the name as a model name, not renamed; the former definition stays readable at the earlier releases |
| **Assisted Model** | Superseded by DR-0012, which withdrew the name as a model name, not renamed; the former definition stays readable at the earlier releases |
| **Backup Model** | Superseded by DR-0012, which withdrew the name as a model name, not renamed; the former definition stays readable at the earlier releases |
| **Federated Model** | Superseded by DR-0012, which withdrew the name as a model name, not renamed; the former definition stays readable at the earlier releases |
| **Shadow Model** | Superseded by DR-0012, which withdrew the name as a model name, not renamed; the former definition stays readable at the earlier releases |
| **Pool Model** | Superseded by DR-0012, which withdrew the name as a model name, not renamed; the former definition stays readable at the earlier releases |
| **Elected Model** | Superseded by DR-0012, which withdrew the name as a model name, not renamed; the former definition stays readable at the earlier releases |
| **HOAC Arrangement Models (three)** | Withdrawn by DR-0049: Solo and Team are the organisation's own mechanism; the Overseen link stays as a link between positions (§5.2); the former definition stays readable at the earlier releases |
| **Solo Model (DR-0012)** | Withdrawn by DR-0049 (the organisation's own mechanism); the former definition stays readable at the earlier releases |
| **Team Model (DR-0012)** | Withdrawn by DR-0049 (the organisation's own mechanism); the former definition stays readable at the earlier releases |
| **Overseen Model (DR-0012)** | The Overseen link: a higher position can stop or override a lower one, with a pre or post timing form; a link between positions (§5.2) (DR-0012, DR-0049) |
| **position** (entry label) | A register entry for a position and its code; no people; may be public (§5.2) (DR-0011) |
| **arrangement** (entry label) | Withdrawn by DR-0049; an Overseen link is recorded on the position (§5.2); the former definition stays readable at the earlier releases |
| **occupancy** (entry label) | Withdrawn by DR-0049: who holds a position is the organisation's own record, outside the system (§5.2); the former definition stays readable at the earlier releases |
| **handover** (entry label) | Withdrawn by DR-0049: everything a position carries stays with it (§5.2); the former definition stays readable at the earlier releases |
| **Delegation ladder** | The four levels a human seat sets for its Chief of Staff, per class of act (§5.2) (DR-0010) |
| **Assistance contract** | The rules for AI that prepares material for a human seat (§5.2) (DR-0010) |
| **Evidence class** | Proven, measured, cited, hypothesis or not established, on every claim shown for a decision (§5.2) (DR-0010) |
| **Quiet window** | A random share of lower-stakes decisions shown only proven and measured facts, to measure anchoring and skill (§5.2) (DR-0010) |
| **Duty deputy** | An AI Cell that answers recurring asks only from signed, unexpired rulings (§5.2) (DR-0010) |
| **Complete definition** | The approved definition of 49GAION in one text, `49GAION-FRAMEWORK.md`; where another text differs, it governs (DR-0041) |
| **The core** | The first AIOC of an `[ORG]AION`, at the governance level and the root of the organisation, made from 49GAION Charter, with the gateway and the stop; it holds the human governance position, the governance panel and the organisation's Standard, Blueprint and Library (§1.3, item 1) (DR-0041) |
| **Top Management Group** | The first AIOC under the core: the Top Management position with its AIOC, the hub of the operation, human and AI, which builds everything in the operation (§4.2) (DR-0041) |
| **Governance panel** | The core's panel: the organisation's rules, the decision log, the status of every unit, "decision needed", the governance veto, the link to the stop (DR-0041) |
| **Governance and Delegation** | The second capability of an `[ORG]AION`: one governance, the dial, the mandate and its envelope, one counterparty, what governance keeps, the gate, the governance veto (§1.3, item 1) (DR-0041) |
| **Mandate** | The one delegation from the governance seat to Top Management: outputs and measures, the envelope, reserved matters, reports owed, revocation (DR-0041) |
| **Mandate envelope** | The limits of cost, resources and capacity within which Top Management acts without asking first (DR-0041) |
| **The gate** | The path of a request beyond the mandate envelope, decided by the governance seat (DR-0041) |
| **Governance veto** | The governance seat's right to stop or replace any decision of Top Management, or change the envelope, at any time; recorded and forward-looking (DR-0041) |
| **Edition engineer** | The human 49GAION position that leads each edition through Edition Maker and supervises every step (§1.2) (DR-0041) |
| **First proposal** | The core's first work: from what Edition Maker took in, the governance seat's brief and 49GAION's patterns, a small organisation designed for approval (§1.3, item 1) (DR-0041) |
| **Tainted run** | A run that has read an external input; until it ends, the gateway refuses its sends, publications, writes outside its own space, new targets and changes of permission without a deterministic check or the accountable position's approval (§4.4, item 22) (DR-0053) |
| **Event record** | The one append-only record of the gateway's decisions, controls, stops, restarts, taints, clearances, approvals and credentials, chained by hash (§4.4, item 24; the Operating Protocol) (DR-0053) |
| **Conformance** | The claim of an implementation that runs the Protocol's conformance scenarios and whose own trace passes the trace checker; otherwise "unverified" (§1.8) (DR-0053) |
| **Proven `[ORG]AION`** | An `[ORG]AION` after one end-to-end acceptance run whose intake measures hold, judged by the governance seat (§1.8, item 3) (DR-0053) |
| **floor (of a listed type)** | `fixed`, set by the Standard, or `org-choice`, added by an organisation; removing a type or turning `fixed` into `org-choice` passes the human approval gate (§4.4, item 20) (DR-0053) |
| **Powered by 49GAION (DR-0041)** | Carried by all the products of an organisation that uses even one item of 49GAION (§1.3, item 3) |

Sources: DR-0004, DR-0007, DR-0011, DR-0012, DR-0031, DR-0032, DR-0041.

Powered by 49GAION