The contract · Security

Access rules live in the code, not the interface.

Every line below describes how the system behaves today, stated specifically enough to be held to.

Patients start the connectionYou only ever read your own caseloadEncrypted in transit and at rest

The guarantees

Nine specifics, not nine adjectives.

Each one is a commitment you could put in a contract.

Who can get in

Access is enforced, not offered.What you can open is decided by the server on every request, never by what the interface shows. A manipulated request gets the same refusal as an honest one, and both paths are covered by tests.
If access is ever questioned, there is a record.Sign-ins, access changes and administrative actions are recorded as they happen, and the record outlives the account it refers to.
Encrypted in transit and at rest.Standard practice, stated so you do not have to ask.

Your patients' privacy

Your caseload is yours alone.Every read is tied to your identity at the source, not filtered in the page. No other practice can see who you treat, and no request can be crafted to widen the view.
Nobody can probe for who your patients are.A patient who is not yours answers exactly like a patient who does not exist. Guessing reveals nothing.
What patients keep private never reaches a screen.Nothing on the never-visible list is ever assembled for a dietitian view in the first place. It is not fetched and then hidden. It is out of scope.

If something ever goes wrong

A breach of Lemonmint would not hand over your password.Passwords are never stored in readable form, and the form they are stored in is deliberately expensive to attack.
The sign-in forms cannot be used to test who is a patient.Sign-in, password reset and account deletion answer identically for known and unknown addresses.
Nothing sensitive outstays its purpose.Verification codes and deletion links are erased once they are used or abandoned, rather than lingering in storage.

Ownership

The record belongs to your patient.

Access exists because your patient granted it, on terms they can end at any time.

We don't sell it.Not to advertisers, brokers, insurers, or employers. The privacy policy states this in those words, and no export or bulk-access path exists in the product.
The connection starts on their side.A patient types your 6-character code into their own app. No route lets a practice attach itself to a patient.
One dietitian at a time.A patient can be linked to one practice at a time, and the database refuses a second. Nobody can end up quietly shared between two.
They can disconnect without asking you.Disconnecting removes the link outright, and only the patient can do it. Every read stops returning their data the moment the link ends.
Meal recognition runs on one external provider.The provider receives the photo and the nutrition context needed to comment, never your patient's email address or account id. Details are in the privacy policy.

Who sees what

Your patient

Everything they log, in their own feed.
Nora's reply, under each meal.

A logged meal

Nora and Sage

The record they were handed: meals, weight, nutrition.
They write into the patient's feed, and nowhere else.

The Monday review

You

The last 30 days of the record, and the Monday review.
Your own session notes.

What never crosses

Nora's per-meal replies never reach your dashboard. The Monday review is what surfaces.
Your session notes never reach your patient, and never reach Nora or Sage.
Nothing you open writes into your patient's record. Your side reads it.

Read the privacy policy

The AI

It surfaces patterns. You make the call.

The same framing appears in our Terms. The sales copy and the contract read identically.

What it does

Reads each logged meal and estimates what was in it.
Writes your patient a weekly recap, the same one that reaches you.
Names patterns across a week: late dinners, missed days, weekend dips.
Answers your patient in their own feed, between your sessions.

What it doesn't

Diagnose, treat, or give medical advice. The instruction against it prefixes every single model call.
Write anything into your dashboard. No agent code path reaches the dietitian side at all.
Invent facts about your patient. It answers from the record it was handed, or not at all.
Decide what a pattern means. That was always a clinical question.

There is a test that tries to bait it.

One test scenario hides a medication-dosing question inside a meal entry. The check fails if the answer engages with it. A regression test, not a validation study.

What we are not claiming

That the models are clinically validated.
That a person reads their output before your patient does. Nobody does.
That we can quote you an accuracy figure.

Data minimisation

The safest record is the one we never hold.

Two lists: what the app never collects, and what never reaches your dashboard.

Never collected

Precise location or GPS.
Contacts or address book.
Photos beyond the ones your patient logs on purpose.
Microphone or audio.
Browsing activity from outside the app.

Never queried for your dashboard

Your caseload reads one field from the patient's account: their name.
Email, avatar and credentials appear in no dietitian response, on any endpoint.
The social feed and the agents' own posts are absent from every dietitian query.
Anything on the never-visible list. Out of scope in the data model, not stripped at the end.

Data we never hold is data we can never mishandle.

Partner with us

Give your patients a team between visits.

Tell us about your practice in one short form.

Request access

Set up by the team that builds Lemonmint. Replies within two business days.