The instance

Whose it isSettings names the person it belongs to

Settings › Account opens with Signed in as, a name and an email address. That is the account the data belongs to: every entry, task and document in this deployment is filed under it, and there is no second one to switch to.

The name and address come from the backend, not from the browser. If they look wrong, the account was set up with the wrong details, and fixing them is a backend act: ask whoever runs your LifeOps to correct them, in plain words. The owner's guide's What to say section shows how such asks work.

Signing inOne password guards the whole app

The web app asks for a username and password before it shows anything. It's one credential for the whole instance, and it exists to keep a stranger who finds the address out of the journal.

A fresh deployment has no login at all: the first person to reach the login page sets the username and password right there, and the app refuses any second attempt to set one. Changing a password you know is yours to do in Settings › Account. The Change password row opens a form that asks for the current password, then the new one twice, and it states the shortest password it will accept. A password you have forgotten is the one case for the operator: whoever runs your LifeOps sets a new login against the backend directly, and the owner's guide covers that side under Your login.

Signing out is at the bottom of Settings › Account. It clears this browser's session only. The app stays reachable, and anyone with the password can sign back in.

Which backendSettings names the backend this app talks to, and moves it

Settings › Backend shows the address the web app is reading and writing through. Every screen in this app is a view of that one backend, so the address is the answer to "whose data am I looking at".

Moving to a different backend takes two things, the address and a token for it. Both are checked against that backend before anything is stored, so an address that does not answer, or a token it refuses, changes nothing. The move takes effect on the next page you open, with no redeploy and no operator. Coming back is the same act with the old address and token, and while a move is in force the page also offers to drop it and fall back to this deployment's own setting.

A move is held in two places. One is in force immediately and lasts as long as the running app; the other is the deployment's own setting, which is what a fresh container boots with. The page tells you which halves landed, and when only the first did it names the backend the next deploy would go back to. A deploy that quietly moved you back is the worst version of this feature, and that warning is what the page exists to give you.

The token is written to the server and never shown again. What the page reads back is the host, never the credential.

A second personGive them their own instance, not an account here

There is no way to add a second person to an instance, and that's a design decision rather than a missing feature. Two people in one journal would put a "whose is this?" question on every screen: the areas, the day, the tasks, the AI's filing.

So a second person gets their own deployment, with their own data, their own password and their own AI switch, sharing nothing with yours. Whoever runs your LifeOps sets the second one up, the same way yours was.