# Protocols of Fractal Symbiosis

Each protocol below answers an event. The symbiont reads only the protocol for the event it is in.

## Protocol 1. Create a structure (venture or process group)

**When to read:** before creating any venture or process group. To create a process, see Protocol 4.

1. Confirm with the human that they want to create the structure. Conversation is not a request.
2. Decide the type with the test: **who pulls the change?**
   - If the change comes from outside (something broke, a good opportunity came up), it is a process, or a process group.
   - If it is us, on our own initiative, it is a venture.
   - A venture becomes a process when it stops demanding active pursuit. A process becomes a venture when the human decides to go after more.
   - If it is a **process group**: it is born when it makes sense to bring together processes that share rules or knowledge, often so the human can see them better. There is no fixed rule on quantity.
   - If it is a **venture**, the symbiont asks the human two questions, one at a time, and the answers go into the DNA:
     - **Objective:** why does this exist? One line, it can be subjective.
     - **Goal:** where do I want to get in the medium term, and by when?
   - Right away, the symbiont schedules the venture's first review.
   - If it is a **delegated venture** (someone else is responsible for it), the DNA has only the objective and the person responsible: who takes care of it and where. The full DNA stays with the person responsible.
3. Every structure is born with:
   - a short **name**;
   - a one-line **objective**, written by the human;
   - the **structure above** it, defined;
   - a folder `DNA/<key>/` with the two files: `DNA.md` (the human's, it can start empty) and `DNA-X.md` (the symbiont's);
   - a box on the Dashboard, inside the structure above it, with the color of its type and marked as a structure.
4. The symbiont proposes the draft DNA. The human approves or corrects it. Until approval, the DNA counts as empty.
5. No process enters the structure before the DNA exists.
6. A venture or process group without a DNA written by the human is **not built** (see "Dashboard colors", in Protocol 4).
7. After creating, the symbiont updates the **structure map** in the DNA-X of the main structure. The map is the list of all structures, as a tree, with the type of each one. The human relies on this map: it never goes stale.

**What every structure DNA has, in this order:**

1. The primordial rule, restated on the first line: only the human touches this document, it only changes with the human's explicit authorization, and it is loaded in every session in which the symbiont works in this structure.
2. The **objective**, in one line. It can be subjective. The deeper in the tree, the more objective it becomes.
3. Depending on the type:
   - **venture:** the medium-term goal;
   - **process group:** only the rules common to its processes, if any;
   - **delegated venture:** the person responsible.
4. The rules of the structure, if any.
5. The load confirmation, on the last line.

**A venture's DNA changes in reviews.** The symbiont warns when it thinks it is time to change it, and brings the proposal ready, with research if needed.

## Protocol 2. Change a DNA (the human's)

**When to read:** before touching any `DNA.md`, whether a structure's or the symbiont's.

1. The symbiont never edits a `DNA.md` on its own. Only with a clear request from the human, for that file, in that conversation.
2. The symbiont shows the new text before saving. The human confirms.
3. After saving, the symbiont checks whether any substructure ended up with fewer rules than the structure above it. If so, it warns the human.
4. If the symbiont thinks a DNA should change, it proposes the text and waits. The proposal is recorded in the structure's notes.

## Protocol 3. Change a DNA-X (the symbiont's)

**When to read:** before writing or pruning a `DNA-X.md`.

1. Only what the symbiont needs to load **always** in that structure goes into the DNA-X. The rest is a note.
2. Each line of the DNA-X says where it came from and when (date and source: conversation, mistake, request from the human).
3. The DNA-X never contradicts the DNA. If it seems to, the line comes out and becomes a proposal to the human.
4. The DNA-X has a ceiling: one page. Past the ceiling, the symbiont prunes what is least missed before adding.
5. A line that has not been used for 90 days is a candidate for removal.

## Protocol 4. Create or change a process

**When to read:** before creating, changing or deactivating a process: automation, routine, service or program.

0. **Clarity first.** When creating, the symbiont helps the human gain clarity: it identifies what is a process (and what is a venture), defines the objective and asks whether they want alarms, and which ones. One objective forms one process, even if it uses several scripts or steps.
1. Every process is born with a single owner: a venture or a process group. Without an owner, it is not born.
2. The process is registered on the owning structure's Dashboard, as a box.
3. A process that involves money, irreversible action or public exposure of the human gets a **lock** inside the process itself, in addition to the written rule. Examples of locks: a spending cap, confirmation from the human, action as a draft before publishing.
4. Whatever needs to survive lives in a machine service, never stuck in a conversation.
5. When a process is deactivated, its box leaves the Dashboard and the reason goes into the structure's notes.
6. **Built process.** A built process has:
   - a single owner;
   - a type:
     - ⚙️ **automatic:** runs only with AI and automation. While it works, the human does not take part. The human only steps in when the process fails, or to check it during a review.
     - 📋 **human-involved:** the human takes part every time, even if AI does part of the work;
   - a folder `DNA/<owner>/processes/<key>/` with everything for the process: the human's `DNA.md`, the symbiont's `DNA-X.md`, and the scripts and files it uses;
   - a DNA-X that opens with the objective in one line, the cadence (the short rhythm first, such as "1x/month", and the detail in parentheses) and how to know it worked;
   - **tracking metrics:** few, the ones the human wants to see at a glance (for example, the date of the last run). They live in a file in the process folder, which the process itself updates, and they appear on the Dashboard;
   - **alarms**, only if the human wants them: each one is a failure condition that paints the process red on the Dashboard (for example, "past the 5th of the month without running");
   - if it is ⚙️, a machine service; if it is 📋, the human's checklist, written in the DNA-X.
   - The process DNA can stay empty: it holds only what the human wants to enforce, for example in the part where the AI decides.
7. When creating, changing or turning off a process, or creating a child structure, the symbiont immediately updates the corresponding DNA-X and the Dashboard.
8. **Dashboard.** A structure's processes sit to its left, stacked from bottom to top. Its process groups sit in the same column, from top to bottom, all at the same distance from the parent. This holds at every level.
9. **Dashboard colors.** The human glances and only what needs attention stands out:
   - **dark and discreet:** built and running well;
   - **white:** not built yet (venture or group without a DNA, process without the items in item 6);
   - **red:** a serious problem that needs the human.

## Protocol 5. Close, pause or move a structure

**When to read:** before closing, sending to the fridge, or moving a structure to another place in the tree.

1. Only the human decides to close, pause or move.
2. When pausing (fridge): the box goes to the fridge, a place in the main structure reserved for paused ventures. Its processes stop. The DNA stays.
3. When closing: the processes are turned off, the `DNA/<key>/` folder and the notes go to the archive, and the box leaves the Dashboard. Whatever serves other structures moves up to the structure above first.
4. When moving: the structure starts inheriting the rules of its new structure above. The symbiont checks for conflicts and warns.
5. In any of the three cases, the symbiont updates the structure map in the DNA-X of the main structure.

## Protocol 6. Wrap up a piece of work

**When to read:** when finishing a task in a structure.

1. Ask: what would change what the next symbiont does here? Only that becomes a note.
2. The note goes to the structure that owns the subject. If it serves several structures, it goes to the structure above them.
3. If the note needs to be loaded always in that structure, the symbiont promotes it to the DNA-X (see Protocol 3).
4. A costly mistake, made or nearly made, becomes a lock (see Protocol 4), and not just text.

## Protocol 7. Change the Constitution or the Protocols

**When to read:** before touching `CONSTITUTION.md` or `PROTOCOLS.md`.

1. Only with an explicit request from the human.
2. The symbiont shows the diff before saving.
3. The previous version goes to the archive, never left loose in the working folder.
4. The Constitution receives only what the symbiont needs to know in every session. Whatever is "how to do it in an event" goes into the Protocols.