This page is machine-translated from French. Read the French original.

Design principles

Five biases explain most of WivenLLM's choices. Understanding them helps to understand why the application behaves the way it does.

1. Local by default, cloud by choice

No API key is required during installation. WivenLLM starts with:

• A integrated embeddings engine which runs on the machine; ;
• a local vector base stored in a folder within the installation; ;
• a local database for spaces, conversations and settings.

The language model is the only element to choose, and it too can be local. Therefore, an installation can work without any outgoing connection.

Connecting to a cloud provider remains possible, and it's sometimes the right choice—for quality, speed, or a one-off need. But it's a explicit decision, taken by an administrator, not a default state.

Practical consequence: the screen Réglages → Confidentialité summarizes at any time which components are local and which are outside the scope.

2. No component is mandatory

The language model, the embedding engine, and the vector database are three interchangeable components. WivenLLM communicates with each through a common interface: adding a provider does not change the rest of the application.

This is what allows us to:

• start locally, then move to a more powerful model without reindexing your spaces (as long as the embeddings engine does not change); ;
• use a different model per workspace — a fast model for routine questions, a heavier model for analysis; ;
• replace the local vector database with an enterprise database when the volume justifies it.

→ Supported providers

3. An answer must be verifiable

Each answer built from your documents displays the extracts from sources which were used to produce it: name of the document and exact passage.

This principle is also found elsewhere:

• THE event log retains the structuring actions of the instance; ;
• The conversation history can be viewed and exported by an administrator; ;
• When an agent uses a tool, the conversation shows it.

The goal is not to make the model infallible, but to make its work inspectable.

4. Control is the administrator's responsibility, not the user's.

The decisions that commit the organization — which supplier, which agent skills, which content rules, who accesses what — are grouped in the administration and invisible to users.

These users have a deliberately simple interface: workspaces, conversations, documents. They can adjust settings that concern them (appearance, language, their own memories) without being able to modify the instance's configuration.

→ Users and roles

5. We start small

The application is usable from onboarding, with a workspace and a document. Advanced features—agents, flows, scheduled tasks, model router, web widget, API—are disabled or empty by default and are activated when needed.

This principle explains why some functions are invisible until they are activated: Réglages → Fonctions bêta, Réglages → Agents, Réglages → Tâches planifiées.

What these principles mean for you