Projects and conversations

A project is a collaborative workspace that groups related conversations and shared context. A project belongs to a tenant.

A conversation is a persisted multi-turn dialogue between a user and an AI model, accessed through the Chat view. A conversation belongs to one user and may optionally be attached to a project — when it is, it inherits the project's knowledge, access tier, and file space, and stays private to its owner unless the owner shares it into the project feed. A conversation that is not attached to a project is private to its owner and owns its own file space.

Components

A project contains:

Members — the users who can read and contribute to the project. Each member has a role: owner, editor, or viewer.
Knowledge — documents and free-text notes attached to the project. The chat engine injects the combined knowledge text into requests made within the project context.
Conversations — chat conversations attached to the project. Each stays private to its owner; the Conversations tab shows only your own, and other members see a conversation only after its owner shares it into the project feed.
Access tier — the policy that governs which models the project may use and how personal data is handled (see below).
Instructions — the instruction prompt applied to new conversations created within the project.

Access tier

Every project carries a permission_tier that determines which models its conversations may use and whether PII protection is forced. The tier replaces the older notion of a per-project default gateway determining the provider; routing is no longer driven by a stored gateway. There are three tiers:

Tier (`permission_tier`)	Policy
User configurable (`user_configurable`, default)	All models are available. Each conversation chooses PII protection per chat. This is the behaviour-preserving default — existing and new projects start here.
PII protection required (`pii_mandatory`)	All models are available, but PII masking is mandatory within the project: no client setting can turn it off, and a request the gateway cannot mask is refused rather than sent. See What the mandate guarantees.
Local only (`local_only`)	Only local Myra models are available. Cloud models, web search, and external tools are disabled, and data never leaves Myra infrastructure.

What the PII mandate guarantees

Under PII protection required, every request that would leave Myra for a third-party model resolves to exactly one of three outcomes:

the gateway has a request-phase PII detector → the request is masked before it is sent;
the gateway has none → the request is refused before dispatch, with "This project requires PII protection, but the selected gateway has no PII filter configured." Nothing is sent;
the gateway routes to a local Myra model first and that model fails over to an external provider mid-request → the failover leg is sent unmasked and is recorded in the request log as an unmasked egress under mandate. This is a deliberate, accepted exception (a local-first pick is not blocked just because a fallback exists); use Local only if no external failover is acceptable.

The mandate also covers the background calls the chat makes on a conversation's behalf, which carry the same conversation text. Follow-up suggestions run on the conversation's own served model, so they are masked or refused exactly like a turn (when they are refused, no suggestions are shown). The auto-generated title prefers a local Myra model that may run on the conversation's gateway for your workspace, so it normally never leaves Myra and the mandate is moot for it. When no local model may run there (all disabled, none offered under the gateway's provider restriction, or none within the plan), the title runs on the conversation's own served model instead — and then the mandate is enforced on it exactly like a turn.

The tier names the enforced policy invariant, not a UI label, so it is stable across interface renames. The server derives a read-only permission view from the tier (allows_cloud, pii_mandatory, user_configurable) that the chat UI renders to mirror enforcement — for example, hiding cloud models in a Local only project. Enforcement is server-side: the gateway rejects a non-local model in a Local only project regardless of what the client sends.

Roles

Role	Read	Manage knowledge	Manage members	Delete project
Owner	yes	yes	yes	yes
Editor	yes	yes	no	no
Viewer	yes	no	no	no

A viewer is read-only: it can read the project, its conversations, and its knowledge, but cannot write anything. Managing members — adding, changing a role, or removing a member — requires the owner role; an editor cannot. Only an owner can delete the project.

Instead of inviting members individually, an owner can share the project with the whole organization in one step, which gives every user in the organization access without adding them to the member list. This does not require an administrator role — owning the project is enough — but an administrator can disable org-wide sharing for the organization, which also withdraws access from projects already shared that way. See Managing projects.

Knowledge injection

The project's knowledge is composed into the system prompt on every request made within the project context — not injected once when the conversation is created. The gateway concatenates the knowledge entries in full and rebuilds the system prompt each turn, so newly added knowledge takes effect on the next message. Knowledge entries can be plain text or extracted from uploaded files (PDF, DOCX, ODT, plain text, spreadsheets, and structured .xml/.json). (The roughly 30-file cap that applies elsewhere is the per-conversation list of generated files, not project knowledge.)

Knowledge files can be grouped into folders. A folder is derived from the leading path of a file name rather than stored as a separate object, so a folder exists only while it holds at least one file. Folders organize the file list; they do not change which files a conversation draws on.

A project can also attach a connected source synced from a connector such as Confluence. A connected source is normally readable only by the person who created the sync. A tenant admin can share a source org-wide, which makes every synced page readable and citable by every user who can open the project. This is deliberate administrative curation — it exposes the synced pages tenant-wide regardless of the restrictions those pages carry in the source system — and it depends on the tenant-level setting that allows org-wide sharing.

Within a single conversation, a user can exclude individual knowledge files from that chat. The exclusion applies to the one conversation only and leaves the project and the files unchanged.

Reply language

An explicit instruction wins; the user's language is the fallback. If the project instructions, or the user's own profile instructions, explicitly name the language to answer in ("Always answer in English"), the model answers in that language — whatever language the user writes in. Without such an instruction the model answers in the language the user writes in, even inside a project whose instructions or knowledge-base files are written in another language: project instructions and file contents are context to draw on, not a directive to switch languages, so a project whose instructions are in German still gets English replies for a user who writes in English, and vice versa.

This is enforced in the system prompt at three places that state the same rule — the default prompt's language line, a reply-language anchor placed directly after the project instructions (so it qualifies them instead of contradicting them), and the per-request reply-language directive appended after the composed blocks — each leading with the precedence rule and falling back to the detected language.

The detected language is that of the user's own words in the latest message: text the user attached or pasted into the turn (a document, an image's extracted text, a data-file preview) is set aside before detection, so a German document with an English question ("Summarize this") is answered in English. A message that consists of an attachment only is judged as a whole (the document's language). Text typed between two attachments, or after a data-file preview, is inside the span that is set aside; such a message is then judged as a whole too (the in-app composer always places the typed text first, so this only concerns API clients that order the parts differently). Detection is precision-biased: an ambiguous message adds no directive at all rather than a wrong guess. The same detected language also steers web-search targeting (see Result language).

Knowledge search (hybrid retrieval)

Beyond reading a named file, the model can search across all of a project's documents at once with the built-in search_knowledge tool. This is offered automatically whenever the project (or a project-less conversation's own file space) has attached documents that have been indexed.

Retrieval is hybrid: it combines

a semantic leg (dense embeddings — matches meaning and paraphrase), and
a lexical leg (BM25 keyword search — matches exact tokens such as a section or paragraph number like § 12, a form ID like R0431, or a code),

fused so that a confident semantic match is never displaced while exact-token matches are still surfaced. German text is handled with proper case-folding and umlaut/eszett normalization (Müller ≡ Mueller ≡ MÜLLER, Straße ≡ Strasse), so keyword lookups work on administrative and legal documents.

Optionally, when a cross-encoder reranker is configured for the deployment, a final rerank stage re-scores the fused candidates for relevance to the exact query and keeps the most relevant few — a precision boost on large corpora. This stage is off by default, and if the reranker is unavailable it transparently falls back to the hybrid order, so retrieval never blanks or drops results because of a reranker outage.

Each returned passage carries a deterministic [file | page | section] citation, and those citations appear in the answer's Sources panel so a user can trace every claim to its exact page. Retrieval is strictly scoped to the requesting user's own project/conversation and tenant — a document from another project or tenant is never searched or returned. Only documents that have finished indexing are searched; a document still being processed can still be opened by name, and the tool says so rather than guessing when nothing relevant is found.

The same hybrid retrieval also applies when the model opens a single large named file: rather than truncating the document, the gateway narrows it to the passages most relevant to the current question — combining the semantic and BM25 legs exactly as search_knowledge does — while still falling back to serving the whole document whenever narrowing cannot be applied.

Two limits affect how precisely a document can be cited. A very long PDF can exceed the page limit for extraction; only the extracted pages are then searchable and citable, and the file preview says so. A document that has no page or section index is still searchable in full, but answers over it cannot cite a specific page — the knowledge list marks it accordingly.

Conversations

A conversation contains:

Messages — the ordered list of user and assistant turns.
Attachments — files uploaded by the user and referenced from one or more messages.
Memories — long-lived context entries that the chat engine may inject into future requests.
Feedback — an optional 1–5 rating (5 = best, 1 = worst) with a comment.
A share token — present only when the conversation is publicly shared.

Messages

A message has a role (user or assistant) and a body. User messages may carry attachment references. Assistant messages carry the model identifier of the model that produced them and the token counts reported by the upstream provider.

Attachments

Supported file types are images, PDF, DOCX, plain text, and spreadsheets. Attachments are stored in the database and referenced by attachment ID. The gateway extracts the textual content of an attachment and includes it in the request body sent to the upstream provider.

Memories

A memory is a piece of free text the user marks as long-lived context. The chat engine reads the user's memories on every request in the same project and prepends them to the system prompt.

Conversation file space

A conversation that is not attached to a project owns its own file space. Files that the model generates during the conversation are stored with the conversation rather than with a project. The generated files appear as artifact cards in the conversation and remain available for the lifetime of the conversation.

A conversation that is attached to a project shares the file space of the project instead.

A conversation can be made publicly readable via the Share action in the Chat view. Sharing produces a public token and exposes the conversation at /shared/<TOKEN>. The shared view is read-only and excludes attachments.