Preparing for launch.

Roadmap to publication

Kensora's code is on its way from a private tree to a public repository. The gates between here and there are ordered, they are public, and none of them is skippable. This page is the whole path.

This page promises no dates, deliberately. Each gate is cleared when it is cleared, and the gates that protect safety take as long as they take. Honesty about that beats a schedule we would have to walk back.

Where things stand today

The Kensora app is live

The iOS app is on the App Store today. Publishing the code changes how the project is built, not whether the app exists.

The legal texts are underway

The license, the trademark policy, the governance document, the code of conduct, and the security policy are drafted and in review. The contributor agreement is still being written. None of them is executed or published yet, and until the final texts publish, no contribution can be accepted.

This site is live

kensora.dev exists so the plan is public before the code is. What you read here is the same plan the project works from.

The first public repository does not exist yet

There is no public Kensora repository today. When one appears, it will be because every gate below has cleared.

The review named above is Kensora's internal safety and claims review. 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 gates, in order

Five gates stand between today and the first public repository. They clear in this order, and the repository publishes only after the last of them.

The executed legal texts publish. Above all the contributor agreement: its final text must be public before any contribution is accepted, because that text, not a summary of it, is the agreement. The license, the trademark policy, the governance document, the code of conduct, and the security policy publish alongside it.
A clean export of the codebase is produced and scanned. A script builds a fresh-history export of the private tree, leaving out the third-party materials the project cannot license onward, and the exported tree says plainly what was left out and why. The export then passes automated secret scanning before anything else happens to it.
The publishable tree is swept for health language. Every file that will publish is checked for wording that could overstate what the software does for anyone's health, so the code reads the way the project's claims policy requires. Kensora is not a crisis service, and it does not detect or prevent any medical or mental-health condition or emergency. The published code has to say that as carefully as this site does.
Every dependency's license is audited. The audit walks the build graphs and confirms that the license posture holds for every library the apps ship, not only for the code the project wrote itself.
The repository rails go up. An automated check that every first-time contributor has signed the contributor agreement before a change can merge. Protections on the safety surfaces, so changes there require maintainer review. Issue forms that route reports to the right place. And a written protocol for responding when someone in a community space appears to be in distress. That protocol lands before any community space opens, not after.

Android first

The first public repository is planned to be kensorahq/kensora-android: the Kensora Android app together with the cross-platform behavior contracts that define how the apps must behave. iOS and the other trees follow later.

That order is honest and practical. The Android tree builds from a clean export, with anything the project cannot license onward left out and the tree stating plainly what was left out and why. The iOS tree depends on vendor hardware SDKs and on a licensed clinical instrument's text that the project does not hold the rights to publish, so an iOS export would ship with holes on day one. Starting where the export is cleanest means the first repository can be buildable and truthful about its own contents from the first commit.

A fresh-history export also means the public history starts clean. Nothing that was never meant to publish can ride along in an old commit, because there are no old commits.

What open will mean

On day one

Read the code, build it, and file issues through the forms. That is the whole surface at first, and it is already the part that matters most: the way Kensora stores, syncs, and protects information becomes something you can read for yourself.

Then

Pull requests open as the contributor agreement and the rails above come online. One thing to know before that day: a pull request publishes the name and email address in your git configuration, worldwide and permanently, so choose them deliberately. Pseudonyms are fine. The contributor agreement records your legal identity privately and is not published.

Later

A trust ladder comes later still, so that contributors who do sustained, careful work can earn wider responsibilities over time. Its details will publish in the project's governance materials before any of it applies to anyone. Nothing about it is live today.

Where the links will appear

The repository links will appear on the home page the day they go public. Until they do, any repository claiming to be Kensora's is not ours.