Five biases explain most of WivenLLM's choices. Understanding them helps.
\nto understand why the application behaves the way it does.<\/p>\n
No API key is required during installation. WivenLLM starts with:<\/p>\n
The language model is the only element to choose, and it too can be Connecting to a cloud provider remains possible, and sometimes it's the right choice \u2014 for Practical consequence:<\/strong> the screen The language model, the embeddings engine, and the vector database are three This is what allows us to:<\/p>\n \u2192 Supported providers<\/a><\/p>\n Each answer built from your documents displays the excerpts This principle is also found elsewhere:<\/p>\n The goal is not to make the model infallible, but to make its work Decisions that commit the organization \u2014 which supplier, which skills These have a deliberately simple interface: workspaces, \u2192 Users and roles<\/a><\/p>\n The application is usable from onboarding, with a workspace and a This principle explains why certain functions are invisible as long as they
\nlocal. An installation can therefore operate without any outgoing connection<\/strong>.<\/p>\n
\nquality, speed, or a one-off need. But it's a decision
\nexplicit<\/strong>, taken by an administrator, not a default state.<\/p>\nSettings \u2192 Privacy<\/code> summarizes everything
\nat what point which components are local and which are outside the scope.<\/p>\n
\n2. No component is mandatory<\/h2>\n
\nInterchangeable building blocks. WivenLLM communicates with each one through an interface
\nCommon: adding a supplier does not change anything else in the application.<\/p>\n\n
\n spaces (as long as the embeddings engine does not change); ;<\/li>\n
\n common questions, a heavier model for analysis; ;<\/li>\n
\n The volume justifies it.<\/li>\n<\/ul>\n
\n3. An answer must be verifiable<\/h2>\n
\nsources<\/strong> which were used to produce it: name of the document and exact passage.<\/p>\n\n
\n administrator; ;<\/li>\n
\ninspectable<\/strong>.<\/p>\n
\n4. Control is the administrator's responsibility, not the user's.<\/h2>\n
\nagent, what content rules, who accesses what \u2014 are grouped in
\nadministration and invisible to users.<\/p>\n
\nConversations, documents. They can settle what concerns them.
\n(appearance, language, their own memories) without being able to change the
\ninstance configuration.<\/p>\n
\n5. We start small<\/h2>\n
\ndocument. Advanced functions \u2014 agents, flows, scheduled tasks, router
\nTemplates, web widgets, APIs \u2014 are disabled or empty by default and are enabled
\nwhen the need arises.<\/p>\n
\nhave not been activated: Settings \u2192 Beta features<\/code>, Settings \u2192 Agents<\/code>,
\nSettings \u2192 Scheduled Tasks<\/code>.<\/p>\n
\nWhat these principles mean for you<\/h2>\n