Quickstart — hosted

This is the path where someone else runs the infrastructure and you use louvain as a product. You need a browser, an account on the deployment, and — for the last step — a source worth remembering.

If you are standing up your own instance instead, go to Quickstart — self-hosted.

What you will have at the end

A workspace with at least one connected source, teammates who each get their own permission-scoped view, and answers that cite the message they came from.

Open the deployment's URL. There are two doors:

/login — email and password, or a single sign-on button if the operator configured an OIDC provider. The button's wording is set by the deployment, so it will say something like "Sign in with Okta" rather than "SSO".
/signup — creating a brand new workspace. This is often closed. See the next section for why.

If your company has claimed and verified its email domain and turned on required SSO, password login is refused for addresses in that domain. That is deliberate: if a password still worked, deprovisioning at your identity provider would not actually remove access.

A louvain deployment is multi-tenant. Every org is fenced from every other in SQL, before any visibility rule runs — but the fence is about data, not about who gets to be a tenant. With open signup, anyone who learns the hostname can create an org inside your deployment, and every event they ingest costs the operator real model spend.

So LOUVAIN_SIGNUP=invite-only is the default in the shipped production configuration, and the boot-time configuration checks deliberately do not force it either way. Whether a deployment is open is a judgement about who it is for, not a value that can be validated, so it is set to the safe answer and changed on purpose.

What this means for you:

On an invite-only deployment, /signup renders "Invitation required" and nothing else. You need a link from an existing admin.
The invite link creates your account and adds you to the workspace in one step. There is no separate "register, then request access" dance.

3. Create or join a workspace

Joining with an invite

Open the link you were sent. Before asking you for anything, the page names the workspace and the role you were invited as, so you can tell a legitimate invite from a link someone forwarded you by mistake.

No account yet — set a display name and a password (minimum 12 characters), and you are in.
Account already exists — the same link adds your existing account to the new workspace. An invite can never re-key an account that already exists; otherwise inviting a known address would be account takeover.

Invite links expire (a week, by default) and an admin can revoke one before it is used.

Creating a workspace

Only possible where signups are open. You provide your name, work email, password, a workspace name, and a workspace URL slug.

The slug is worth ten seconds of thought. It identifies your tenant in every org-fenced query and in permission subjects, so it is fixed at creation — the Settings page shows it read-only afterwards. default is reserved.

Whoever signs up becomes the workspace owner. That role is set at signup and cannot be handed out by invitation.

More than one workspace

One account can belong to several. Settings → Workspace lists them, switches between them, and — where signups are open — creates another. Each one gives you a separate principal, so what you can see in one says nothing about the other.

4. Invite your teammates

Members → Invite people. Pick admin or member.

Two things to get right:

Invite people at the email address their source accounts use. When someone joins, louvain links the source identities it has already seen for that org whose email matches theirs, then rebuilds their readable set. Invite p.raman@ when Slack knows them as priya@ and they will join to an empty view — technically correct, and not what anyone wanted.

Roles gate administration, never visibility. An admin can connect sources, invite people and read the audit log. An admin cannot see a message from a private channel they are not in, and neither can the owner. There is no role in the system that widens what a principal can read.

If the deployment has no mail transport configured, the invite dialog hands you a link to send yourself rather than silently failing. Treat it as a credential — anyone holding it can join as the role you chose.

5. Connect a first source

Connections → Add connection. The list you see is whatever the deployment has registered; each type carries its own setup instructions in the form, so there is no separate integration guide to go and find.

The three built-in shapes:

Slack — a live feed. Messages and channel-membership changes stream in as they happen, which is what keeps permissions current rather than a day stale. You will paste a bot token and an app-level token. Public channels are joined automatically; for a private channel you must invite the bot to it explicitly, because nothing else would be a permission you actually granted.
Slack export import — a one-shot import of an unzipped Slack corporate export, including private channels and their membership. Full history, on the same authenticated ingest path as the live feed. Use the same workspace label as the live connection so history and live traffic land in one graph.
HTTP inbound — a credential and a permission boundary with no runner, for any internal tool that can make an HTTP request. Creating it issues an ingest token, shown once; only its hash is stored. If you lose it, rotate it rather than hunting for it. Rotating stops the previous token immediately.

Credentials are sealed before they touch disk, and each connection gets its own revocable ingest token. Connection status is shown plainly: Starting, Error with the last error text and when it is retried next, or Paused. Not running is displayed as not running, and errored is retried until it is paused.

6. Ask your first question

Ask. Type a question in ordinary language, or tap one of the suggestions under the box. They are composed from the entities you can see and your workspace's own vocabulary — so the first question is never a guess, and a colleague with different access sees different chips.

The as of date control is a real point-in-time query, not a filter on timestamps: it answers with what was believed on that date, following supersession.

7. What "good" looks like

On the answer. A badge naming the plan that ran — direct lookup, aggregate count, point-in-time query, timeline, provenance trace, hybrid retrieval — the principal you are asking as, and a Receipts list underneath. Every claim shows the room it came from and the words that were actually said.

Below the answer, one of two lines:

"Assembled from N claims you can see. No language model wrote this sentence" — the deterministic planner answered. Counts were counted.
"Written by a model from N sources you can see" — the planner could not route the question, so a reader composed from retrieved evidence. Every figure, date and name in it was checked against those sources afterwards, sentence by sentence; a sentence with anything unsupported is struck rather than shown, and an answer with nothing left is refused.

A refusal is a result. "Nothing you can see supports an answer to that" is the system working. If the facts exist in a room you are not in, louvain will not hint that they exist — a correct refusal and a genuine absence look identical from outside, and anything else leaks the shape of what is being hidden.

A degraded-retrieval warning is not a refusal. If part of the search did not run, the answer says so and names what was affected. That means possibly incomplete, not nothing exists. Ask again.

On the Overview page. The top row is coverage and posture: claims extracted (with the memories and passages in your view — a corpus the vocabulary has no words for lands there, not in claims), freshness (the last event, and how many arrived in the last fortnight), permission posture, and "Visible to you" across the rooms you can read. The row below is operations: live connections reading all healthy, dead letters at zero, and — for admins — today's extraction calls. If "Awaiting extraction" appears, the queue is draining behind you; if permission posture reads "in flight", permission changes have not reached the authorization store yet and reads fail closed until they do. Admins also get "Answers, last 7 days": refusal and degraded rates, latency and feedback for what the workspace has been asked.

The real test. Have a colleague in a different set of channels ask the same question. Different — correct — answers, from the same deployment, on the same day, is the property everything else here exists to support. Admins get a related view under Access insights, which flags where what the company knows and who can know it have drifted apart.

One thing to check early. The Knowledge page shows the vocabulary this workspace understands: the domain templates that decide which predicates extraction can write, which ones supersede, and how questions route. If your business talks about things the selected domains have no word for, the answers will be thinner than they need to be.

8. Let your AI ask too

Settings → API tokens mints a bearer token that carries exactly your access — not more, and not an admin's. It is shown once and stored hashed; revoking it takes effect immediately.

LOUVAIN_URL=https://your-deployment.example.com/api
LOUVAIN_TOKEN=louvain_your_token_here

curl -s -X POST https://<deployment>/api/v1/answer \
  -H "authorization: Bearer $LOUVAIN_TOKEN" \
  -H 'content-type: application/json' \
  -d '{"question":"how many deals are in negotiation?"}'

The same token drives the MCP server, so an agent in your editor asks as you and gets refused where you would be.

Connectors — what each source type needs, and how to push from a system that has no connector yet.
Asking — how a question becomes a plan, what the receipts mean, and how to read a refusal.