Board

Board

Status: Draft — may change (2026-10-19)

Where it sits: beside the tiers, not inside one. The folder was policy/ until 2026-10-17, renamed so that "policy" names the Kernel's object only. It is meant to be the one place the Charter points to for who decides, and it may not loosen the Kernel.

The archived public RFCs are a list of ideas, not decisions. Every rule below is a proposal. Each rule names its source. "Owner decision" means one of the later owner decisions listed in Sources.

1. Purpose and scope

1. This file holds the board and review terms moved out of the Charter. The Charter should not set reviewer count or composition, nor name the board; it should point here. Source: owner decision (pending Charter correction, not applied).
2. It says who sits on the board, who validates, who can veto or answer back, and how board authority meets the Kernel's "who may do what" rule.
3. It decides for TeamCLI only. A team that uses TeamCLI answers to its own owner or board. Source: Charter Part 3 ("Who decides, and how").
4. Reviewer count and lab or model mix are out of scope here. They belong in Review-terms (draft-2, updated 2026-10-19, a proposal like this page). Source: hierarchy proposal 2026-10-15.
5. Reviewers work in seats, opened for the rounds and removed after, never in runs started outside a team. Source: archived board setting.

2. Board membership

1. The owner gives missions and keeps the long-term goals. The owner does not decide every step. Source: owner decision.
2. The first assistant, the architect and the entity orchestrator (roles) reach consensus on decisions within a mission and report those decisions to the owner. Source: owner decision.
3. For each kind of decision, the rule says who decides: one voice; several asked and one decides; a number must agree; or all must. Source: RFC 006 c1.
4. Where no rule is set for a kind of decision, one voice decides: the one who holds the right to that act, except where another RFC of this series asks for more. Source: RFC 006 c1.
5. The one who decides is not counted among the voices asked. Source: RFC 006 c3 (related; kept because it bounds membership).
6. Being on the board grants no capability. See section 5. Source: Kernel §3, §9.
7. A member's vote is not lent to whoever drafted the text. Source: the Charter, Part 3, and the archived board setting.

3. Validation

1. Every kind of decision has a written rule that names who decides and by which means. Means listed: a fact (a thing tried, a test, a measurement); a trial of two ways; a vote, each voice once; one voice that hears the others and decides; a rule already written; review in rounds; or the owner. A project may define its own means. Source: RFC 006 c1.
2. The rule names the means before the work is opened, with what the means is to show and what it cannot settle. Source: RFC 006 c1.
3. The rule is set by whoever holds the right to set it, never by the one whose work is decided on. Source: RFC 006 c1.
4. A means gives a decision its ground. Whoever holds the right still takes the decision. A run that passes is a check, not an acceptance. Source: RFC 006 c1.
5. No means takes a decision with less than the Kernel (formerly RFC 001) requires for a power given, or less than Quality requires for what is checked before it lands, or less than Memory requires for an entry a team remembers. Source: RFC 006 c1.
6. A rule may name a floor: the least number of voices that makes a decision valid. Below the floor there is no decision, however many said yes. Source: RFC 006 c6. The number itself is not set here (see section 1.4).
7. Where only one lab, or one model, is available, the decision says so. Source: RFC 006 c6 (says "one lab"; "one model" follows the owner decisions relayed for this draft (below, §8; see §7.4)).
8. An independent reviewer is not the authoring model. Using several models or labs is a convention, not a rule of the Charter. Source: owner decision.
9. The author of a change never gates or merges it. Source: Kernel §5 (separation of duties, tool-fixed).
10. These are validated before they land, whatever else is set: a grant, an agreement, the creating of a team; what is published, deployed, deleted, spent, sent outside, or written where others will read it; what a person will run by hand; and any change to this policy. Source: RFC 005 c3.
11. Other work may land when its automatic checks pass and be read afterwards; what is found then is held like any other finding. Where the line sits beyond the list in 3.10 is set by whoever holds the right to set it. Source: RFC 005 c3.
12. Work whose kind cannot be told is treated as "validate before". Source: RFC 005 c3.

4. Veto and retort

1. A single voice blocks a decision only where the rule for that kind says "all must agree". Otherwise no voice holds a veto. Source: RFC 006 c1 (who: one / one after asking / a number / all).
2. A voice below the floor, or a voice that is not independent, does not block and does not pass a decision. It is heard and recorded. Source: RFC 006 c3, c6.
3. A "no" from a reviewer is answered in writing in that round's decision record. A point the board decides against the reviewers is recorded as such, with both positions, in the text itself where it matters. Source: archived board setting, not c1/c3/c6.
4. No reviewer holds a veto by repeating a point. Source: archived board setting; RFC 006 c7.
5. The owner can always revoke a power or stop a team. This is not a vote; it is a Kernel act that commits unconditionally. Source: Kernel §5, §9 (stop, machine-wide stop, revoke).
6. Whether the owner holds a veto over a consensus of the three roles is not settled. See Open questions.

5. Relation to the Kernel's "who may do what" rule

The Kernel's wording (Kernel §9, "leads — the authority root, and who may do what"): "The address is not an authorization: who may do an operation is the table below, and nothing is inferred from leads being the address." And: "Each operation MUST have exactly one authorizing principal (whose signature the ledger records as signer); the executing actor is recorded separately and authorizes nothing. The one exception is a two-granter change: it records a primary signer plus one co-authorization — two signatures over the same canonical proposal (§10) — rather than a single principal." §3: "A capability grants nothing by name alone." §16: "only a capability grants".

1. A board decision is not an authorization. An act still needs the capability or live lease the Kernel §9 table names, checked at the gate. Source: Kernel §9, §16; RFC 006 c1 ("whoever holds the right to the decision still takes it").
2. Board membership, a role name, or being the team's address confers no right. Source: Kernel §3, §9.
3. Granting is itself the approval. There is no separate owner approval step after a grant. Source: owner decision (active; the entry records the decision as not yet enforced).
4. Grants are per command, granular, and revocable. Source: owner decision; Kernel §7, §10 (revocation is a signed record; taking back stays taken).
5. An agent may never grant itself or widen its own grant. Source: owner decision; Kernel §3, §7.
6. Administrative capabilities (create, grant, agree, leads) are never leased. Only operational capabilities are leasable. Source: Kernel §7.
7. When the board decides to give a power, the grant is made by the owner or a grant holder, within the ceiling and deny (Kernel §8). Deny wins. Source: Kernel §8, §9.
8. The review mode (cross-lab or distinct-seat), minimums, maximums and exclusions are owner-only. This policy cannot change them. Source: Kernel §5, §9 (last row).

6. Changing this policy

1. Changing a rule, its number or its floor is an act of whoever holds the right to set it, never of the one whose work is decided on. Source: RFC 006 c1.
2. Each change is recorded with who and when. It applies only to decisions opened after it. Source: RFC 006 c1; RFC 005 c3 (moving the line does not change work already open).
3. Any change to this policy is validated before it lands. Source: RFC 005 c3.
4. Who holds the right to set this policy: the owner sets who sits on a board, what passes a decision, who can refuse, and whether the board may change that. Source: Charter Part 2, item 9.

7. Open questions

1. Board composition vs the archived setting. The archived setting and the accepted Charter (Part 3) name a two-member board (the owner and the main coordinator, the entity orchestrator); an RFC passes when both say yes. The owner decision describes the three roles (first assistant, architect, entity orchestrator) reaching consensus and reporting. Is the owner a voting member on each decision, only on some kinds, or none? Which kinds?
2. Owner veto. Archive silent. Does the owner keep a veto over a consensus of the three roles, beyond the Kernel's revoke and stop?
3. What "consensus" means for the three. All three, or a number? RFC 006 c1 allows either and leaves it to the rule. Not set.
4. Lab vs model. RFC 006 c3 counts independence by lab ("Voices from one lab are one voice"; "the lab that produced a thing never counts"). RFC 005 c2 and the board setting also say "lab". The owner decision says "not the authoring model" and makes multi-lab review a convention. Not resolved here. An owner decision and an owner decision record the earlier Charter panel and its acceptance, not this later proposal to replace the Charter's lab/count rules; they are historical precedents, not a decision on this question.
5. Reviewer floor. RFC 006 c6 allows a floor. The board setting and the accepted Charter set three reviewers from three labs; Kernel §11 (Review record) says "≥3 reviewers from ≥3 labs, none the author's". The owner's pending correction would remove the count from the Charter (not applied; §1.1, §7.6). Does a floor stay, and in which file?
6. Accepted texts still conflict. The Charter (Part 3) and Kernel §11 (Review record) still name the board and the reviewer count. The Charter correction and the Kernel rewording are not applied; the rewording was written against an earlier Kernel and its sentence is now §11. Its proposed file names are also stale: the board text is the Board page and the process text is the review process.
7. Grant vs agreement. An owner decision makes granting the approval. Kernel §10 keeps an agree capability, two-granter agreement and an agreement record. How they fit is open.
8. Who may set this policy. The Charter says the owner. May the three roles amend it by consensus, or only propose?
9. "Securely accessible place". The hierarchy proposal asks for "the one secure place for decision policy the charter points to", a pending Charter correction (§1.1). Who may write this file, how a change is signed, and whether it is mirrored in team configuration, are not set. The archive is silent.
10. Overlap with the archived setting (formerly the Charter's board companion). That draft copies the archived board setting. Does this file replace it?
11. Veto and retort sources. RFC 005 and 006 c1/c3/c6 say nothing explicit on veto or retort. Rules 4.3 and 4.4 come from the archived board setting and RFC 006 c7.
12. The read-at pin on a rule-and-source page. The page pins v0.5.0 (52db9b75) but carries no Today line the pin is read by. Should the build-facing rules (for example §5's grant rules) gain a Today line, or should the pin be dropped?

8. Sources

• RFC 006 Consensus, c1, c3, c6 (c7 cited once): RFC 006 Consensus
• RFC 005 Quality, c3 (c2 cited in open questions): RFC 005 Quality
• Archived board setting
• Kernel (accepted 2026-10-09): Kernel §3, §5, §7, §8, §9, §10, §16, §11 (Review record)
• Charter (accepted 2026-10-11): Charter Part 2, Part 3
• Hierarchy proposal (superseded)
• Historical Charter review precedents: an owner decision (private-reading permission and panel additions) and an owner decision (acceptance after the independent review). Both are active; neither settles the later proposals listed below.
• Owner decisions (as relayed for this draft, 2026-10-15): pending Charter corrections (no reviewer count or board names in the Charter; "not the authoring model"; multi-model review is convention); grants (an owner decision: granting is the approval; per command, granular, revocable; no self-grant or self-widening; team approve to go away); roles (owner gives missions and keeps long-term goals; the first assistant, the architect and the entity orchestrator reach consensus and report).