@@ -16,10 +16,10 @@ Project spaces, and anywhere someone is representing the project.
 
 ## Reporting
 
-Email **security@scriptkittyos.com**: the same address, because there is one maintainer and a
-second address would be theatre. Reports are read by that maintainer. If your report concerns
-the maintainer, say so in the subject; there is no independent body today, and pretending
-otherwise would be worse than admitting it.
+Email **security@scriptkittyos.com**: one address, because a second one nobody reads would be
+theatre. Reports are read by the maintainers named in `MAINTAINERS.md`. If your report concerns
+one of them, say so in the subject and it will be handled by the others. If it concerns all of
+them, there is no independent body today, and saying so is better than implying one exists.
 
 ## Enforcement
 
 
@@ -1,7 +1,7 @@
 <!-- SPDX-License-Identifier: Apache-2.0 -->
 # Contributing
 
-Trinity is pre-alpha with one maintainer. The most useful contributions right now are bug
+Trinity is pre-alpha, with the maintainers named in `MAINTAINERS.md`. The most useful contributions right now are bug
 reports against a tagged release, corrections to the documents, and review of the engineering
 records behind a change. If you want to take on a larger piece of work, open an issue describing
 it first, so two people do not build the same thing.
 
@@ -3,9 +3,26 @@
 
 ## Today
 
-**One maintainer**, named in `MAINTAINERS.md`, who is also the author and the sole reviewer.
-Every change is gated on that person's review. This is stated rather than dressed up: the
-review queue is the project's real critical path.
+**Three maintainers**, named in `MAINTAINERS.md`. Any of them may review a change, merge it, tag it
+and cut a release. Every change still lands through a pull request against a protected branch with
+the full gate green, which is the rule that has not changed and is not going to.
+
+This is stated rather than dressed up. The project went from one maintainer to three on 2026-09-23,
+and names in a file are not the same thing as people who have carried the work. What is true today
+is that the project no longer stops if any one person does. What is not yet true is that any of
+them could pick up any part of it cold: every commit in the tree to date has one author.
+`docs/06-risk-register.md` R22 tracks that difference and states what would close it.
+
+## Continuity
+
+If any one maintainer becomes unavailable, for any reason, the others hold the access needed to
+keep the project running: each can create and close issues, accept proposed changes, and publish a
+release. Nothing in the ordinary workflow requires a specific individual.
+
+The exceptions are named here rather than left to be discovered. Administration of the GitHub
+organisation, the domain, and the security mailbox rest with the author. Restoring those to a
+surviving maintainer is a legal and administrative matter, not a technical one, and it is the first
+thing a reader evaluating this project's continuity should ask about.
 
 ## Decisions
 
 
@@ -1,12 +1,21 @@
 <!-- SPDX-License-Identifier: Apache-2.0 -->
 # Maintainers
 
-| Name | Role | Scope |
-|---|---|---|
-| Ayla Croft | Maintainer, author | Everything |
+| Name | GitHub | Role | Scope |
+|---|---|---|---|
+| Ayla Croft | [@HackTuah](https://github.com/HackTuah) | Maintainer, author | Everything, including organisation administration |
+| Zach Mead | [@znmead](https://github.com/znmead) | Maintainer | Review, merge, tag and release |
+| Mike Hostetler | [@mikehostetler](https://github.com/mikehostetler) | Maintainer | Review, merge, tag and release |
 
-One maintainer today. `GOVERNANCE.md` records how that changes and what a second committer
-would have to do to become one. Stating it plainly is the point: a project with one maintainer
-and a governance file implying a committee is misrepresenting itself.
+Three maintainers as of 2026-09-23, up from one. Any of them can accept a proposed change, close
+an issue and cut a release; administration of the GitHub organisation rests with the author.
+Repository access for @mikehostetler was granted on 2026-09-23 and is pending acceptance at the
+time of writing, which is recorded rather than glossed because a maintainers file is the sort of
+document people check against the repository itself.
+
+That asymmetry is written down rather than smoothed over, because "three maintainers" and "three
+people who can do everything" are different claims and only the first is true. `GOVERNANCE.md`
+records what happens when any one of them is unavailable, and which parts of the project would
+still need the author specifically.
 
 Security reports go to **security@scriptkittyos.com**, not to an individual (`SECURITY.md`).
@@ -9,9 +9,10 @@ vulnerability.
 Include what you did, what happened, and what you expected. A proof of concept helps; a working
 exploit is not required and is not expected.
 
-**You will get an acknowledgement within 14 days**, and in practice sooner. Trinity has a single
-maintainer today (see `MAINTAINERS.md`), so that is the target the project holds itself to rather
-than a contractual commitment; if you have not heard back in 14 days, send the report again.
+**You will get an acknowledgement within 14 days**, and in practice sooner. Trinity is maintained
+by the people named in `MAINTAINERS.md` and has no paid security staff, so that is the target the
+project holds itself to rather than a contractual commitment; if you have not heard back in 14
+days, send the report again.
 
 We ask for coordinated disclosure: give the project a reasonable period to publish a fix before
 disclosing publicly, and we will credit you in the release notes unless you ask otherwise.
 
@@ -21,6 +21,7 @@
 | R20 | Foundation donation may require transferring assets or marks the project intends to keep | Med | Med | Proposal drafting (122) | Unverified: the requirement is asserted from an announcement, not from the charter text. Read the charter, then decide what is offered and what is retained. Legal review before any proposal leaves the tree | 122 |
 | R21 | The tree carries IP that is not this project's to publish | Med | High | Any design in Trinity that reproduces a third party's protected mechanism | Trinity's receipt and policy design is its own. Policy identifiers stay out of `signed_payload` until legal review clears them; 024's field set is reviewed before that slice starts | 024, 120, 122 |
 | R22 | Single maintainer; Growth needs two unaffiliated production users and commits from two orgs | High | Med | 6-month Sandbox checkpoint | Sandbox tolerates it; GOVERNANCE.md documents intent to grow; recruit co-maintainers via the Elixir community once public | 120, 122 |
+| R22 | Partly mitigated 2026-09-23: two further maintainers, Zach Mead and Mike Hostetler, joined with review, merge, tag and release rights (`MAINTAINERS.md`; `GOVERNANCE.md` "Continuity"). **What that closes is availability**, which is what the OpenSSF criterion `access_continuity` asks for: the project can accept a change and publish a release without any one person. **What it does not close is knowledge or independence.** Every commit in the tree to date has one author, so a "bus factor" of two or more in the sense the criteria mean it (the number who would have to disappear before the work stalls for lack of competent personnel) is being established rather than claimed, and the badge answer says so; and organisation administration, the domain and the security mailbox still rest with the author alone, which `GOVERNANCE.md` names as the first thing a reader should ask about. Lift condition, checkable by a stranger: reviews and merged changes from a maintainer other than the author in the git history, and the administrative access documented as recoverable. The row above stands as written | Med | Med | The lift condition above, unmet | GOVERNANCE.md "Continuity"; MAINTAINERS.md | 120, 122 |
 | R24 | A native NIF in the desktop bundle: `mdex_native` (the markdown renderer's Rust core, added at 013) is the first, and slice 001 proved the packaging chain with a pure-BEAM release | Med | Med | The `package` workflow fails on one of its three operating systems after 013, or 100's cross-target build finds no artifact for a target | `rustler_precompiled` ships artifacts for every target the chain builds for (013 NOTES.md, measured against the checksum file); the `package` run on 013's `mix.lock` change is the first proof on three runners; lift condition: that run green on all three, cited in 013's PROOF.md; a fallback is `MDEX_NATIVE_BUILD=1` with the pinned Rust toolchain already in the tree | 013, 100 |
 | R24 | Fired 2026-09-20, in slice 013: neither precompiled `mdex_native` artifact loads in Burrito's musl ERTS (both need glibc's `libgcc_s`; `_dl_find_object: symbol not found`). Lifted the same day by the owner's decision: the linux package builds the NIF from source for musl with Zig as the linker (`scripts/zig-cc-musl`, config/config.exs, `rustler` at build time), measured on a fresh install of the packaged binary rendering the real provider's answer; the `--smoke` path now prints `TRINITY_SMOKE_MARKDOWN=ok` and exits 3 otherwise, and the `package` workflow reads that line on every target, so a dead NIF cannot pass again. Residual: macOS and Windows use the precompiled artifact, and the `package` workflow has yet to run green there since the slice/011 tag (an older failure at "Serves HTTP 200", now diagnosed by the step's log). The row above stands as written | none | none | none | none | 013 |
 | R23 | EMA / ID-JAG is beta everywhere (vendors label it so); IETF draft still moving | Low (re-scoped 2026-09-22) | Med | Spec revision breaks the exchange at the external authorization server, which is where it happens: Trinity redeems no assertion since the owner's decision of 2026-09-22 (slice 062 NOTES) | The resource server validates whatever audience-bound token that server issues, so a draft revision is that server's upgrade, not Trinity's; the row stays until the deferral lifts | 062 |