LumenNexus — Privacy Notice

Draft, 14 September 2026. Not yet reviewed by qualified counsel; not to be relied on until it is. Same structure as HelpingNeighbor's notice, written for what this product actually does.

Effective: [date on publication] · Operator: [legal entity], trading as LumenNexus, lumennexus.ai · Contact: privacy@lumennexus.ai

The short version

LumenNexus is a data-governance control plane. Organisations ("workspaces") put data products in it so that who may read what is decided in the database, every decision is written down, and what left the boundary can be shown. Two things follow, and the rest of this notice is detail on them:

**For data inside a workspace, the workspace is the controller and we are the processor.** We process it on the workspace owner's instructions under the Data Processing Agreement. We do not read it, sell it, train a model on it, or use it for anything but running the service.
For the account you sign in with, we are the controller of a small amount of information — your email address, a password hash, when you signed in, and what you did in the workspace. That is described here.

We do not sell personal data. We do not use it for advertising. There are no third-party trackers on the site.

1. Who we are

[Legal entity], operating LumenNexus at lumennexus.ai. Hosted in the European Union (Hetzner Online GmbH, Germany/Finland). One operator; the contact address above reaches a person.

2. Information we collect

2.1 Information you provide

Account: email address and a password. The password is stored only as a salted PBKDF2-SHA256 hash; we cannot read it.
Workspace membership: which workspaces you belong to, your role, clearance and residency grant — set by whoever invited you.
What you do in a workspace: every governed action (loading a product, approving a change, signing a record, inviting somebody) is written to that workspace's tamper-evident audit trail with your email address as the actor. This is the product working as described; see §5.
Sign-in codes: when the second sign-in step is on, a six-digit code is sent to your email address. It is stored as a salted hash for ten minutes and then removed.
Billing (when connected): if a workspace owner subscribes, the payment is taken by Stripe. We receive a customer id, the subscription status and the plan. We never receive or store card numbers.
Support: anything you send to the addresses above.

2.2 Information collected automatically

Sign-in attempts: a hash of the email address tried and the network address it came from, kept for 24 hours to refuse repeated wrong passwords. Not the password.
Server logs: the request path, status and timing, and the network address as forwarded by our edge, kept for 90 days for security and incident investigation.
Model usage: when the assistant answers a question or indexes a document, we record that a model call happened, which model, and how many tokens — never the question or the answer.
Cookies: one session cookie (HttpOnly, Secure, SameSite=Lax, 14 days). No analytics or advertising cookies.

2.3 Information from third parties

From Stripe, if a workspace subscribes: subscription events.
From whoever invited you: your email address and the role, clearance and residency they set.

3. How we use it

Purpose	Data	Basis (GDPR)
Running your account and the workspaces you belong to	Account, membership	Contract
Keeping the audit trail every workspace is sold on	Actions, actor email	Contract; the workspace's legitimate interest
Refusing repeated wrong passwords	Sign-in attempts	Legitimate interest (security)
The second sign-in step	Email, code hash	Contract; legitimate interest (security)
Investigating incidents	Server logs	Legitimate interest (security)
Billing	Stripe customer id, plan	Contract
Answering you	Support messages	Legitimate interest

4. The assistant and your data

The assistant (Candela) answers from documents and products inside your workspace, filtered by your clearance before anything is retrieved, and cites what it used. Depending on how the workspace is configured, the model call goes either to inference the operator runs on private infrastructure or to an endpoint the workspace's owner has chosen; a workspace can set a no-egress policy that refuses any public endpoint. We do not use workspace content to train any model. We keep counts of model calls, not their content (§2.2).

4.1 If your workspace switches personalization on

Off by default, and never offered at all to a workspace with a no-egress policy. An owner or admin decides it for the workspace; you can refuse it for yourself, and your refusal wins.

When it is on, a service called Fast-Back (listed in §6) remembers how you like to be helped. It knows you by an opaque id for you-in-this-workspace — not your name, address or role — and holds the preferences you state.

If the workspace also switches on the separate remembering conversations setting, your own questions may be stored there as well, after addresses, telephone numbers, national and health identifiers, payment cards, dates of birth, and this workspace's own product, column and people names are removed. The assistant's answers are never sent — they quote your documents, so not one of them leaves, whatever the settings say. You are shown exactly what would be stored before it is stored, and the page What we remember about you lets you read, correct, export or erase all of it at any time. Erasing your account erases this too.

5. What we do NOT do

Sell or rent personal data, or share it for advertising.
Read the contents of a workspace except as needed to run the service, and then only under the DPA.
Send marketing email. The only email we send is a sign-in code, and — if a workspace owner chooses — a notice about an incident affecting them.
Delete your name from history. When an account is erased (§7) the person is pseudonymised and the events stay, because a governance record whose actors vanish is no longer a record. See adr/0016.

6. Service providers (sub-processors)

The current list, with what each receives, is kept at SUB-PROCESSORS.md and changes are notified to workspace owners at least 14 days before they take effect.

7. Your rights

Whatever jurisdiction you are in, you can:

See everything the platform holds about you: GET /api/me/export from your account, or ask us. The export reports counts of governed content, not the content — that belongs to the workspace.
Correct your email address (ask us).
Erase your account: POST /api/me/erase or ask us. Erasure pseudonymises: your email and name are replaced by a stable pseudonym, your sessions end, and the audit entries you made remain under the pseudonym. An erasure is itself recorded.
Object or restrict — write to us; we will answer within 30 days.
Complain to your supervisory authority. In the EU, that is the authority of the member state you live in.

For data inside a workspace, exercise these rights with the workspace owner (the controller); we will help them answer within the time the DPA sets. Residents of California and other US states with privacy statutes have the rights those statutes give; we do not sell or share personal information as those statutes define it.

8. Retention

Data	Kept
Account and memberships	Until you erase the account or the last workspace closes
Audit trail	For the life of the workspace, and afterwards under its own retention rules; never edited
Sessions	14 days, or until you sign out
Sign-in attempts	24 hours
Sign-in codes	10 minutes
Server logs	90 days
Database backups	14 days
Model usage counts	For the life of the workspace

9. Security

Isolation between workspaces is enforced in the database engine, not in application code; every table holding workspace data carries a row-level security policy and a test that it is forced. Passwords are hashed; sessions are opaque tokens hashed at rest; the audit trail is hash-chained and verified; the site is served over TLS with HSTS. What is in place, what is partial and what is not yet built is published honestly in our SOC 2 control mapping, and the security posture page inside every workspace says which of its answers are measured, declared, or unknown. Report a vulnerability to the address in /.well-known/security.txt.

10. Children

The service is for organisations and is not directed at anyone under 16. We do not knowingly hold a child's account; tell us and it will be erased.

11. Changes

We will post changes here with a new effective date and, for anything material, tell workspace owners at least 14 days before. Continued use after the effective date is acceptance of the change.