Asking questions

You ask on the Ask page in the app, or through the API with a token. Either way the answer is scoped to you — assembled only from what your own principal is allowed to read, and shown with the sources it came from.

Asking

Ask is a conversation. Type a question and press Enter, or tap a suggestion. Use Shift+Enter for a new line. Ask a follow-up without repeating the subject: “Who was involved?”, “What changed?”, or “What’s the evidence for that?”

Each answer has its own receipts. Click a numbered reference in the answer or the sources button to open them beside the conversation. On a phone, sources open in a drawer. Expand a receipt to read its text, source and date. References point to the receipts for that particular answer, not the latest message.

When an original is available, Preview & provenance opens it inside the receipts panel without leaving your conversation. You can read the imported text, inspect What louvain learned, or open the provider's original. Escape returns from the preview to the receipt.

Finding a source

Open Search to find the emails, documents and messages behind louvain's memory. Search a phrase, choose an app, or expand Refine your search for type, author and date filters. Counts include only sources you can access. Cmd/Ctrl+K focuses the search field. People & topics and the optional map remain a click away.

Select a result to preview it. Source dates describe the imported version; the provider may have a newer copy. Old imports are labelled as recovered and missing metadata is shown explicitly. A Gmail link recovered from an old import opens in your active Gmail account; switch accounts in Gmail if needed.

Ask about this starts a conversation focused on that exact source version. Its follow-ups stay within that selection. Start a new conversation to search your whole accessible workspace. A source with no indexed passages or memories can still be read, but cannot be used for a source-focused conversation yet.

Preparing a brief

On Home, choose Gather context and describe what you need: a person, project, decision or conversation you want to prepare for. You can also gather a brief from a Search result set; its discovery filters carry over.

louvain suggests a starting selection from sources you can access. Open an original, remove anything irrelevant, or Find sources to add something missing. Searching again keeps your selected sources. You can choose up to ten; refreshing keeps those exact versions and checks that you can still open them.

Choose a short brief, conversation preparation or a timeline, then Write my brief. louvain writes into a private, saved conversation, using only that selection. Follow-up questions stay in the same scope. Click selected sources in the conversation header to revisit the context or build another brief with a changed selection. Each answer's receipts show which evidence it actually used—not every selected item.

Suggested context is not exhaustive or a claim that a source is relevant simply because it matched. Intent-ranking outages are labelled. If writing is interrupted, open the saved conversation to check what happened before asking again. Nothing is sent to another person.

Your conversations

Conversations are saved in your workspace account and appear in the sidebar and on Home. Reopening one does not generate or charge for another answer. You can rename or delete a conversation from its header, or start a new one to change context completely. Conversations are private to their creator; an admin role does not grant access to another person's threads. The administrative answer log records usage and outcomes, but not the text of private conversation questions.

Follow-ups use recent conversation context to understand your question, then retrieve fresh evidence under your current permissions. Earlier model answers are never used as source evidence. Understood as, inside About this answer, shows the standalone question used for retrieval. If a saved answer's sources are no longer accessible or have been deleted, that answer is hidden when the thread is loaded.

The optional map explorer in the header retains the spatial, single-question view. It is separate from your saved conversations.

Suggestions are composed from the entities and subjects you can see and your workspace's vocabulary — names only, never anything that was said — so they differ per person and are empty when nothing is readable yet.

The as of control sits in the composer. Set it and you get the answer as the company believed it on that date — as of the end of that day, in UTC, so two people in different countries asking "as of 9 August" get the same answer and see the same date written back — not today's answer with an old label on it. The date carries forward to follow-ups until you reset it. Changing it affects the next question only; saved answers keep their original dates.

A question can name a month instead of a date — "as of August, had we signed?" — and it is read as the END of that month, because someone naming a month is asking about the state after it happened. A named day is that day.

Some questions are about the clock, not about words. "What's new?", "what's the latest?", "anything changed?", "catch me up" — these name nothing for the search to match, so louvain does not try: it answers from the newest things you can read, newest first, as a short digest with dates rather than a single sentence. Attach a subject and it goes back to ranking on it: what's new with the Acme renewal searches for Acme and orders what it finds by when it was said. A question that merely contains the word "new" — "what did New Relic say" — is not one of these; the cue is the phrasing, not the word, so a name is never mistaken for a request for news.

Threads currently hold up to 100 questions. Follow-up interpretation uses a bounded window of the last eight completed turns, not unlimited conversational memory. If you return to an older detail, name it explicitly. Leaving the page does not cancel an answer already running; reopen the thread to see the result.

Through the API:

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

curl -X POST "$LOUVAIN_URL/v1/answer" \
  -H "Authorization: Bearer $LOUVAIN_TOKEN" \
  -H "content-type: application/json" \
  -d '{"question": "What stage is Acme Corp at?"}'

asOf is accepted as an ISO timestamp in the same body.

Phrasing that routes well

Questions are matched against your organization's ontology — the predicate vocabulary shown on the Knowledge page. You do not need to know predicate names, but a few shapes are recognised directly and answered without a model:

An enum value identifies its own field, so "in negotiation" or "a sev1" routes correctly even when you never name the field it belongs to.

Anything that does not match one of those shapes still gets answered — it falls through to retrieval across all three memory tiers (typed claims, open-vocabulary observations, and verbatim passages), and a model composes the answer from what came back.

What an answer contains

The response is not just prose. Every answer carries:

• answer — the sentence, and value where the question has a single direct value (a lookup or a count).
• citedAnswer — optional display prose retaining the reader's citation markers, remapped to the returned evidence array. answer and value remain plain text. Citation positions are not a separate semantic correctness score.
• plan — how the question was interpreted: lookup, point_in_time, count, list, timeline, provenance, or search. The app shows this as a badge above the answer.
• via — which path produced it. plan means the API assembled it from database rows and no language model wrote the sentence; the app labels it Model-free. reader means a model composed it from retrieved evidence, and every figure in it was then checked against that evidence; the app labels it Verified.
• claims — the receipts. Each one shows its predicate, its subject, the rooms it was said in, who said it, the quoted words, when it was recorded and when it became true. Corroboration counts are computed from the attestations you can see, so the same claim can read "2× corroborated" for one person and uncorroborated for another. Superseded claims are struck through — but only when you can also see the claim that replaced them.
• evidence — for reader-composed answers, the passages and observations the answer rests on, with their container and date, and spans: the character offsets of the sentences the answer actually rests on. A passage is up to 900 characters — an order confirmation, a thread, a newsletter with three motorcycles at the bottom — so a citation that hands you the whole chunk is a filing cabinet, not a receipt. The app marks those sentences and leaves the rest of the row readable, because the point is to show you where in the source the answer is, not to hide the source. The spans are computed by the same verification that decided the answer could stand, over rows the answer already cited; they never add a row and never widen what was checked. A sentence that rests on nothing in particular gets no span and its row is shown whole. The typed tier has always had this in a stronger form — every claim carries the quote it was extracted from. An inferred statement may rest on a row the answer itself never cited (below); those rows are appended here and the app marks them inference premise, because "sources for this answer" is a narrower claim than "sources that were read".
• found — on a REFUSAL, what the sources do establish, when they do not establish what was asked. Each finding is one sentence, the evidence numbers behind it, and how far the sources go: confirmed (they state it happened), agreed (both sides said yes — one named terms and the other accepted, which is a completed agreement and still not the thing being done), discussed (offered, quoted or haggled over, with no acceptance recorded) or proposed (one side stated an intention, with nothing back). That distinction is usually the whole answer — a purchase that completed and one that was haggled over look identical to a search and are not the same fact. Findings are verified against the same evidence as an answer, so a refusal cannot invent its own consolation prize; an unverifiable one is dropped rather than shown. They never change answer, value or refused.
• inferred — what the sources suggest and do not state, when an answer or a refusal leaves the question open. One sentence, the evidence it rests on, and likely or possible. It sees the whole retrieved page rather than only what the answer cited: an inference is a JOIN between two facts, and an answer often rests on one, so the premises it needs are frequently rows the answer had no use for. It is the only thing in the response that is not verified as true: every figure, date and name in it is checked against the sources exactly as an answer's are, so it cannot invent one — but the connection it draws is new, and may be wrong. "You agreed a price for an Aeron and then bought a headrest that fits it, so you likely went ahead" is the shape. It is never stored, never retrievable, and never evidence for a later question; ask again tomorrow and it is drawn again, or not, from the records as they stand. Render it as what it is.
• asOf and principal — the belief date, and the identity the answer was scoped to. The app shows both on every answer.
• answerId — the answer's row in the workspace's answers log. The thumbs under an answer post to it (POST /v1/answers/:id/feedback); one vote per person per answer, and a thumbs-down can carry a one-line note.

A claim marked unconfirmed, said as a possibility was hedged at the source. Speculation is stored, and it is never allowed to displace something that was asserted outright.

Why it refuses

A refusal here is a deliberate output, not an error path. Four separate mechanisms can produce one, and they mean different things.

Every figure is checked against its source

When a model composes the answer, its output is diffed against the evidence it was given. Numbers carrying a unit, currency, decimal or separator ($410k, 12.4%, 4,200), full dates, month-and-year claims, and any proper noun that was not already in your question all have to appear in the source text or in the source's own timestamp. The check is literal, with two tolerances that are not fabrication: accents are folded ("chateau" is supported by "château"), and a name is supported by its stem ("Minnesotans" by "Minnesota", "Arthurian" by "Arthur"), never by fewer than five characters of it.

An answer that opens by saying the evidence does not contain what was asked ("No deal value for Zengate appears in the evidence…") is a refusal written as prose, and is returned as one — refused: true, refusalReason: "insufficient", no value — so a caller checking the structured fields gets the signal rather than a sentence to parse. An answer that gives the value and then notes a gap is an answer.

The check is applied sentence by sentence. A sentence containing something the evidence does not support is struck from the answer; the sentences that verify stand. A sentence that lists things loses only the unsupported items — "associated with Acme Corp, Zenith Analytics and Bangkok Airways" with the airline in no source becomes "associated with Acme Corp and Zenith Analytics", never the whole sentence gone, unless the unsupported thing is the sentence's own subject or verb. An answer with nothing verifiable left is refused. Nothing is ever shipped with a hedge or marked low confidence: what you read has passed the check, and the response says how many sentences did not (trimmedSentences).

The trade is worth stating plainly: a bare integer under 100 with no unit attached (a day of the month, a list position, a citation marker) is not treated as a factual claim, because checking those refused far more correct answers than it caught wrong ones.

The reader is also forbidden from doing arithmetic. It may not sum, convert, round or reformat. If a total is not stated somewhere, it does not get invented.

A deterministic answer still has to earn it

Even when a question routes to a plan and the plan returns a value, that value is checked against the retrieved evidence before it is returned. A value lifted from a bad extraction — a margin percentage mis-filed as a deal value, say — would otherwise be served confidently, with a citation. If nothing corroborates it, the plan's answer becomes a candidate rather than an answer, and the reader gets its turn.

The exception is a count. Counts are computed in SQL over the rows you are permitted to see. The number is correct by construction and appears in no message anywhere, so demanding that it prove itself against source text would be incoherent. Counts from the count plan are authoritative.

The reverse also holds: a count is never estimated from retrieved results. Retrieval returns a ranked, capped set, so counting it counts what was retrieved rather than what exists. Where a count cannot be computed properly, you get a refusal instead of a plausible integer.

Nothing you can see supports an answer

Nothing visible matches.

or, for a routed question:

No visible deal.stage claim for Acme Corp.
(Either it isn't known, or you don't have access to where it was said.)

Those two possibilities are deliberately indistinguishable. Separating them would confirm that something exists in a room you are not in, which is itself the leak.

Part of the search did not run

If a retrieval step failed, the answer carries retrievalDegraded and the app marks the answer Incomplete, naming the affected step. This is not a statement that nothing exists — it is the system telling you it could not look everywhere. Ask again.

In the app these are one of exactly five states, never stacked: Model-free (a plan assembled rows), Verified (a model wrote it, every figure checked), Refused ("looked at N sources, none literally supports an answer" — with the reason in the API's own words: the sources bear on the subject but none states the value, date or name asked for; the model drafted names or figures no source contains and they were struck; the subject is named in nothing you can read — and the sources it considered), Nothing visible, and Incomplete.

When you think an answer is missing

Work through these in order before treating it as a bug.

1. Read the refusal. "Nothing visible matches" is different from an answer carrying a retrievalDegraded warning, and different again from an answer whose receipts are present but thin.
2. Consider that it is working. If the fact lives in a channel, document or thread you cannot open in the source system, you are not meant to see it here either. A colleague who does have that access will get the answer from the same deployment on the same day. That is the product behaving correctly, not a gap.
3. Check your identity is linked. Your readable set is built from the source identities that resolve to your principal, matched by verified email. If your account email does not match your address in the connected source, your readable set will be smaller than your real access. Your principal is shown under Settings → Account.
4. Check the source is connected and caught up. The Connections page shows what is wired up and when it last delivered; Activity shows how far behind the queue is. Knowledge that has not been ingested yet cannot be recalled.
5. Try the question a different way. Name the entity exactly as your sources spell it, or ask for the history (Walk me through …), which returns everything visible about one thing rather than one field of it.
6. Check the date. With as of set, you are looking at an older belief. Claims that stopped being true — a champion who left, a contract that ended — are correctly absent from today's answer.

If none of that explains it, an admin can check Knowledge for extraction health and review the queue failures, where a message that errored during processing is listed with its reason.

Watching an answer being made

Ask streams, and the panel that slides in beside the map narrates what actually happened, in the order it happened:

1. Searching everything you can read — the question has left.
2. Looking at <entity>, Starting from N entities, Walking N connections — what the ask path did while it searched: the entity the question is about, the entities the graph walk seeded from, the edges it followed. Each is also a move on the map (below). Every name here is one you could have been shown: a seed survives only where you can read an edge on it, so the trace can never answer "does this company hold a node called X" for an X you have no access to. Existence is visibility.
3. N sources you can read — the moment retrieval finishes. Those rows are already permission-checked and final, so they are listed immediately, numbered and tagged with their tier, while the answer is still being written. If a retrieval step failed, a row says which one.
4. Asked for more — “…” or Read behind N summaries — when the reader asked for a wider window: its own search and how many rows that added, or the verbatim rows behind a summary. A count answered from a page it asked for is written as "at least N in the sources read", because a page holds what fitted, not what exists. A search the reader asks for must come from your question: the evidence it reads is other people's email and chat, any of which can contain a sentence addressed to the reader, and a search whose words appear nowhere in the question is dropped rather than run. It could never have crossed the fence — a search widens what the reader sees, never what you may see — but it could have assembled an answer out of documents your question never went near, and cited it properly.
5. Checking an answer against those sources — a composed answer is verified figure by figure; a routed one still has to be corroborated by the same evidence.
6. The outcome — one of the five below, never two of them stacked.

Each row carries the time this page waited for it. Nothing in that list is modelled or estimated: every line is an event the browser observed or a field the response carried (plan.kind, via, refused, retrievalDegraded). There are no confidence percentages here, because the API does not produce one and a plausible number would be worse than no number. (API: POST /v1/answer/stream.)

The map under the answer

Before you ask anything the map is a backdrop: it is held at full strength and taken OUT OF FOCUS behind the question, and it takes no pointer input at all — no hover, no click, no pan, no zoom. A tooltip surfacing under the hero, or a scroll gesture dragging the thing you were reading over, is the map answering a question nobody asked. Out of focus rather than faded, because a map at a third of its strength is a grey haze: what makes it worth having behind you — where the mass is, which kinds are where, the light off a dense core — is exactly what fading takes away. Only the anchors are named there; the rest of the names arrive when the map is yours to work.

Asking one hands the map over. It comes to full strength and shows the work as the work happens: the camera zooms to the entity the question is about, the entities the graph walk started from light up, the picture expands to the neighbours the walk reached, and then it settles on what the answer cites — one move per beat, in the order the API reported them, with the answer's own spotlight queued behind them rather than cut across. A question with no single entity skips the zoom; a routed answer with no walk shows one node. Nothing is staged for effect: a stage the API did not report is a move that does not happen. Then the entities the answer cites light up, the camera eases to them and stays there, and everything else you can read recedes behind them. That picture holds for as long as the answer is on screen — it is not a flash. Each source card can spotlight the entities that source names, and on a refusal the same thing happens for what it looked at, so "none of these supports an answer" comes with the shape of what was weighed.

The spotlight ends when you say so: Clear beside the question or Escape drops the answer, lets the map go, returns it to its default framing and puts the question back in the middle. Opening a node, or taking the camera by hand, also releases it — you are exploring now, and the answer's framing would only be in the way. If you would rather explore without asking anything, "explore the map instead" hands the canvas over the same way.

Click a node to read its dossier in the same panel, without leaving the page. Graph in the sidebar is the full exploratory map (search, kind and tier filters, the time scrubber); from there, "Ask about this" brings an entity back here with the question prefilled. The graph opened directly is a clean map at its default framing — a previous question never leaves it zoomed in.

The panel beside the map is yours to size: drag its left edge, and the width is remembered for next time.

The legend along the bottom is the three-tier story in one glance: a filled node is a typed claim, a ring is something that was said but has no word in your vocabulary yet, and a small ringed dot is a person. Bulk sources — an import bot or a document feed that touched most of the map — are captioned there rather than drawn, because a starburst hub is not a colleague.

The map opens at its default framing: everything you can read, centred, at the renderer's own scale. It arranges itself in front of you and then stays put — there is no zoom-to-fit as it arrives or as it settles, so nothing moves under you once it has stopped. The camera moves only when you ask it to: F fits the map to its box, a kind or tier filter reframes it, an answer's spotlight eases to what was cited and holds there, and Clear or Escape brings it back to the default. The map settles over a fixed number of animation frames rather than a clock, so a page opened in a background tab finishes arranging itself when the tab is next shown — it does not come back frozen mid-arrangement. It is drawn with WebGL; docs/design/graph-renderers.md in the repository is the record of how that was chosen, with the numbers.

Below 1024px the canvas collapses to a strip behind a toggle and the question, the answer and its sources stack in one column.