Moorwell
Pages
Home How it works Evidence Safety About
Look
Open Moorwell

Moorwell keeps the rest of a student's life within reach.

It is not therapy and it does not want to be. It is the thing that makes the next hour survivable, so the lecture, the message and the walk outside stay possible.

Who Moorwell is for and what ships today, then where it goes next and what is still undecided. Everything in the second half is in the future tense and says so.

Who it is for

  • Students

    Between lectures and deadlines, at the hour when nothing is open and nobody is awake.

  • People waiting

    On a waiting list, with nothing in the meantime.

  • People who will not talk yet

    For whom a screen is the first place a sentence can be said out loud. There is no account and no email to give, so opening Moorwell commits a person to nothing and identifies them to nobody.

Designed around students in India. Any adult can use it.

Writing for one reader is what makes the writing worth reading. A bank thin enough to offend nobody is the failure this was built against, so it is written for someone between lectures and deadlines — and the first four services in the bundled crisis directory are Indian for the same reason.

A deadline is one of the ten situations it knows. Money, health, family and relationships are in there too. If you are waiting months for an appointment, or you have never said any of this out loud, it works the same way. Nothing asks what you do.

Moorwell reads English.

What the evidence about that population actually is Close

Thin, and the register says so in the same type size as everything else. For the population this app was built for, the literature located is descriptive — it measures how common something is, not whether anything helps. That row carries the only unverifiable verdict on the whole register.

The one outcome trial the search did locate in this population was delivered by a person, in Hindi, against a printed booklet. The project's own rule for that research pass says no row in it may be described to a reviewer as evidence for an unguided app, and this sentence is that rule being kept. Both rows are on the evidence page.

Built for the way people actually use these apps

The category is opened rarely and briefly. Moorwell is designed to pay off on the first visit rather than the thirtieth.

  • 1 visit is enough to be worth it A check-in and one small thing, complete in about a minute.
  • 3.3% 30-day retention across the category Measured across 93 apps — Baumel et al. 2019, JMIR 21(9):e14567. The number every other app fights with a streak; we designed around it instead.
  • 0 habits required Nothing here breaks if you come back in three weeks.

Everything you use today runs on your own phone

The whole product available today runs on the device, on written content and rules. Everything more capable is numbered above it, gated behind evidence and consent, and shipped only when it can be reviewed. The number is a promise about sequence: capability never arrives before the ability to check it.

The deterministic core is the content bank, the trigger rules, the mapping from how a day is going to what comes back, the crisis pathway and the failsafes. It is free, works with the network off, needs no account and no permission, and it alone is sufficient to ship. Everything else can be taken away without the app stopping.

A psychologist has read it, and the wording changed where she asked for it. The packet she read is built from the shipped content — 2,227 entries across 232 groups, every one gated and traceable — so what she ruled on is what the app says.

Deterministic rules over a hand-written content bank.

Nothing the app can say is generated. Every sentence was typed by a person, sits in a file, carries an identifier, and can be read before it is ever shown to anybody. That is what makes a review possible at all, and no model-generated product can offer it.

docs/Execution Levels.md — Level 0, the engine

A hundred per cent consistent is not a hundred per cent accurate.

Hold the seed and the same input always produces the same reviewed response; a reviewer can audit the rule table; every rule is testable end to end. That is the whole of the claim. It is not a claim that keyword rules catch every disclosure — they demonstrably do not, and treating recall as solved is how a safety feature ends up under-built.

The engine varies on purpose. Consistency here means pinnable, not invariant

The recall gap is covered by escalating, never by loosening.

Widening the risk triggers with ordinary distress vocabulary would make “I failed my midterm” — the most common thing this app will ever be told — answer with a crisis number, which makes the app unusable and teaches a student to stop being honest with it. So the rule table stays narrow and the layer above it may only raise a level, never lower one.

Safety, and the invariant that enforces it

The two small models that ship may rank and classify. They may not write.

Level 0.5 is two models bundled inside the app, on the device, with no network and nothing to consent to. One ranks which already-reviewed line fits best; the other reads an emotion and may abstain. Neither may generate a word, and as currently built neither may touch a risk level.

docs/Execution Levels.md — permissions per level

Two heavier paths exist in the codebase and neither is switched on.

A larger on-device model and an online one were both built far enough to be measured, and both are withheld at build. No reader can turn either on. What would have to be true for them to ship is further down this page.

lib/data/remote/feature_flags.dart — kWithheldAtBuild

Where it starts, and where it goes

  1. Today — written and ruled

    A written bank, a rules planner, and two small on-device models that only ever choose between written lines.

  2. Next — better choosing

    The same bank, chosen from more precisely, still on the device, still reviewable line by line.

  3. Later — earned capability

    Anything more is gated behind evidence, consent, and a way to review it before it speaks.

It measures what a person actually receives, not what the code could produce.

Three capabilities the app appears to have were measured against our own corpus and found to reach almost nobody — one of them has never fired at all, and the others are absent for most people most of the time. All three are written down, on the How it works page. Most systems cannot answer that question about themselves.

Four directions, and which of them are decided

All of them in the future tense. Each says up front whether it is intended or still under examination.

Intended

A model fine-tuned for this app

Not a general assistant asked to be supportive. A small model trained on what this product actually does, so that what it is good at — and what it refuses — would be built into the model rather than asked of it in a prompt.

This is what would make running on your own device a claim about quality as well as about privacy. A smaller model that is right about one thing beats a larger one that is approximately right about everything, and it is the only version of “more capable” that would not cost you your privacy.

Under examination

Vendor models, as future scope

One possible route to a product that adapts to the person rather than serving everyone the same bank. It is a direction we are examining, not a plan with a date.

It also pulls against the architecture, which is the second tension below. We would rather name it than have you find it for us.

Intended

A wider door, and the same thing behind it

Today's build answers one population properly: Indian students under academic pressure. That was a choice for depth, not a ceiling. The mechanisms underneath it were never about exams.

A person lying awake before a shift, a parent whose week has no gap in it, someone whose worry has no deadline attached to it at all — each would be reached by the same rules and a different bank, written for them and reviewed like the first.

Intended

A version that fits the person, not the category

Reaching more people is arithmetic. Personalisation is what would stop each of them being served the average of everyone else.

We are aiming at an app that learns the shape of one week — when the evenings go wrong, what has actually helped before, which words someone uses for it — and changes what it offers accordingly. It does not do this today, and the How it works page says so in those words.

The two hard problems

Named plainly, because an assessor should not have to find them.

  • Doing more on the device

    Capability without upload is an engineering constraint, not a preference. It is the harder path, and it is the one that keeps the promise.

  • Knowing it works

    Nobody has a cheap answer for measuring benefit without surveilling the person. We would rather claim nothing than claim it badly.

Capability arrives after the ability to check it

It exists in the repository, switched off. It measured well enough to be tempting and not well enough to be reviewable, and shipping it would have meant saying something to a person at their worst that nobody had read first. It stays off until that changes. This is what the numbering is for.

This is the strongest evidence we can give that the restraint we claim everywhere else is real, and most products would have deleted it.

What was built
A heavier on-device path, about 398 MB of download, and an online path beyond it. Both exist in the codebase and both were taken far enough to be measured.
What shipped
Neither. Both are switched off in the app we ship. You cannot turn either on, and we do not describe either as available or as coming.
The lighter path that does ship is the better product today.
Why not ship it anyway
Because the measurement did not justify the cost to the person carrying it. 398 MB is too heavy to earn its place on a student's phone, and the online path needs tuning before it deserves anyone's words.
The bar
They would ship when there are better measurements and enough optimisation to make them worth their place. That is a bar, not a date, and it has not been met.
Most products would have shipped it and called it AI.

We write it down for the same reason the failed replications are on the evidence page: a project that only publishes the decisions that flattered it has not published anything you can use.

Asking what is held about you

For asking what is held about you, and for having it deleted. It is not a support line and not a crisis service — neither of the routes below needs it, and neither is behind a form.

Placeholder — this address does not receive mail: contact-address-not-set@example.invalid

It is built to fail rather than to look plausible. example.invalid is reserved by RFC 2606 and can never be registered, so mail sent there is refused at once instead of disappearing into a mailbox nobody opens. It is not a link, for the same reason. The real address is owed and has not been decided; until it lands, the two app stores' requirement for a reachable privacy contact is not met by this page. Saying so here is cheaper than finding it out from a review rejection.

When it exists it will answer three things: a data request (what is held about you, which is short because there is no account to look you up by), a deletion (deletion, not deactivation — though Settings → “Erase everything on this device” and uninstalling both already do it without asking anyone), and a problem with the app. Corrections are written into the changelog rather than quietly patched.

Read on