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 note you write is filed under it. An instance that holds other accounts as well, such as an agent that works for you, keeps each one's data apart; Accounts covers looking into one.

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 change signs every browser out, the one making the change included. 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, which is what separates it from a password change. 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.

AccountsThe owner decides which account may look into which

Settings › Accounts is where the instance's owner opens one account to another. A row names the account that looks and the account it looks into, and is either Read-only or Read and write. A grant runs one way. Taking it back takes effect on the viewer's next page. Right-clicking a row switches its mode or takes it back.

A person and an agent that works for them need no row: they read and write each other's LifeOps from the moment the agent's account is made, and the page lists that pair as Linked agent, which it cannot change.

Read-only is held by the server, not by the screen. Every change into a read-only account is refused with one sentence, on every page and in a connected Claude alike, so a control that still shows on a read-only page refuses when pressed. A write into an account held for writing is marked as the visitor's, never as the account's own.

Every visit is logged: who looked into which account, read-only or not, through which app, and from when to when. The owner sees every account's visits on the same page; anyone else sees who looked into theirs. The log outlives a grant taken back and an account retired.

Whoever runs your LifeOps can manage the same grants against the backend directly; the owner's guide lists the routes in The backend.

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.