What you configure yourself in a finished system

Uploading a file is the entire integration. Search behaviour is tuned with a slider and the bot is rewritten in a text field — both take effect immediately.

• Drag-and-drop upload — PDF, TXT and MD up to 20 MB. Processing runs on its own: text extraction, removal of headers and footers, splitting by parts and articles, embedding computation, storage. The operator only watches the status.
• Failures are explained — a failed document shows the reason, not just a red label. Reindexing is one click, with no need to upload the file again.
• Fifteen search parameters — number of passages in context, similarity threshold, model temperature, passage size. The admin itself distinguishes what takes effect immediately from what needs a reindex, and warns about the latter.
• Prompts in a text field — how the bot speaks, what it may do and how it cites sources. The card is locked against typos, and the system names the instructions you must not delete, because doing so would switch off lead capture or weaken protection against injected instructions.
• Return to the shipped wording in one click — for every prompt and for the whole parameter set.

When the configuration goes stale, the system flags the documents that need reindexing. Nobody has to remember what changed when.

Before the client asks, you ask — and see exactly what the bot would answer from.

• Any query returns the passages that would go into the model context — before the customer sees them.
• Similarity score as a percentage on every passage. You can tell a confident hit from a stretched one.
• The exact location of the hit: file, page and path within the document — part › article › paragraph. The full passage text expands when the wording needs checking.

A disputed answer is settled in a minute: either the data is wrong or the setting is, and it is visible. Without such a tool all that remains is guessing — and that is the difference between a system and a demo.

Every query leaves a record. The application collects the rating itself, not a survey six months later.

• A record on every query with latency and cost.
• Thumbs up and down inside the chat are stored as scores; the admin turns them into satisfaction as a ratio and a percentage.
• Automated evaluation over test sets — a drop in answer quality shows up as a number, not as a complaint.
• The state of the knowledge base at a glance: counts of documents, passages and indexed pages, a breakdown of statuses, and a chart showing which source dominates the base by weight.

A document is either public or restricted to labels. Search filters in the database, not in the answer.

• Document labels (Legal department or Internal methodology, for instance) are created and renamed in the admin; each shows how many documents are attached, so it is clear what deleting one would disconnect.
• A user never receives a label directly — always through a job role. Removing the role removes access at once and without exceptions.
• Job roles are named the way the organisation names them — "Head of accounting", not a technical identifier. Adding a label to a role opens the content to everyone holding it.
• Admins create accounts but never see passwords — the application generates the password, shows it exactly once and keeps only a hash. The first sign-in forces a change.
• Permissions are read on every request, not from the session cookie. Revoking rights takes effect immediately, not after sign-out, and the check holds on each server operation separately.

Sign-in with a corporate account over OIDC is in place, including mapping directory groups onto job roles. It has not yet been proven against a real corporate directory — connecting it is a matter of configuration, not development.

A GDPR request needs neither an e-mail to the vendor nor a database intervention.

• Retention periods separately for leads and feedback, 1 to 120 months, with an automatic daily cleanup.
• Locating a data subject by e-mail or phone number — regardless of letter case and number format.
• JSON export for the right of access and portability (Art. 15 and 20), and permanent erasure on request (Art. 17) including attached ratings.
• An audit history of actions holding a hash of the subject instead of their contact details — the register must not become another database of personal data.
• A legal basis on every record, stored at the moment of collection — provable even after the configuration later changes.

The public privacy policy reads the retention periods from the configuration instead of restating them. Changing a period in the admin therefore cannot turn the published document into a falsehood.

Sales reads what the person wanted — not the raw query.

• A contact with context: name, e-mail or phone, plus an automatic summary of the conversation.
• Two kinds of record: product interest, which the bot recognises from the nature of the query, and a contact left after a negative rating.
• A new → taken → closed workflow with the name of the person handling it. Leads are never deleted, only closed — the history stays provable.
• Deduplication by contact — a second query from the same person extends the existing record instead of creating a duplicate.
• Contact capture can be switched off — it makes no sense in an internal deployment.