Governance
Project Kensora is going open source with closed gates. The code will be open to read, run, fork, and improve. The decisions about what ships to people, especially people in distress, are not crowd-sourced. This page says exactly where the line is.
The short version
One maintainer merges
The project lead, who is the founder, personally reviews and merges every change and triggers every release. There is no committer group with merge rights.
Safety gates cannot be cleared by contributors
Changes that touch crisis surfaces or claims-bearing text require Kensora's internal safety and claims review. Contributors, including automated review sessions, can raise these reviews; they can never clear them. That asymmetry is deliberate and permanent.
These are the project's internal review seats, run with AI assistance under the project lead's authority; they are not an external clinician's or attorney's sign-off, and Kensora does not represent them as such.
The name is not open
The code is planned to publish under AGPLv3. The Kensora™ name, mark, and logo are not part of that grant; KENSORA is the subject of a pending United States trademark application. Forks use their own name and their own branding, and saying truthfully that your project is a fork of Kensora is always welcome. The license page covers this in full.
The locked tier
Two kinds of content are locked no matter who proposes a change.
Crisis surfaces
Crisis copy in every language, the crisis-language word lists (the wording that causes Kensora to show support resources), helpline numbers along with the record of where each one came from, and the safety-plan and crisis-flow code.
Claims-bearing strings
Any user-facing text that states what Kensora does. The project's claims policy allows mechanism language, wording that describes how the software works, such as helping you see shifts from your own baseline. It forbids wording that promises a health outcome or says the software acts on a medical or mental-health condition, because no such claim has substantiation behind it.
When the first public repository goes live (the Android repository publishes first), the locked paths will be enumerated in a machine-readable file in the tree, and the repository's automated checks will flag any change that touches one. Everything outside the locked tier flows through normal code review.
How locked content changes
A change inside the locked tier follows one path, in order:
- A contributor proposes the change, as an issue or a pull request.
- The change goes through Kensora's internal safety and claims review, the seat or seats depending on what it touches.
- A maintainer lands the change.
- The project lead ships it.
Native-speaker review is mandatory for crisis language in any locale before that locale ships. This path is slower than normal review, and that is deliberate.
Decision records
Load-bearing decisions are recorded as architecture decision records: short files that say what was decided, when, and why. A published subset will ship with the repository. If a decision seems arbitrary, the record usually says why it is not. A proposal that contradicts an accepted decision needs to argue with the record, not around it.
Roles: the planned trust ladder
The roles below are a proposal. They are not yet in force, and this page will be updated if and when they are adopted.
| Role | What it means | How it happens |
|---|---|---|
| Contributor | Anyone with an accepted contribution. | A signed contributor agreement plus a first accepted contribution. |
| Reviewed contributor | A track record of accepted work in an area. | The maintainer's judgment, recorded. |
| Locale steward | A standing point of contact for a language and region: triages that locale's translations, watches whether its helpline information is still current, and coordinates native review. | Named by the maintainer after sustained reviewed work; sign-offs are recorded. |
No role, at any rung, will ever clear a safety gate or merge.
Continuity
Today this project has a bus factor of one. One person merges, ships, and holds the keys. That is by design at this stage, and it is stated here plainly rather than papered over.
The license and the planned contributor agreement will be structured so that the code, once published, remains usable by everyone even if the project ever stops.
Changing governance
Changes to governance will be proposed as issues, decided by the project lead, and recorded as a decision record.