Documents to evidence.Research to reviewable work.
AverQel is an open-source web and desktop workspace for private documents, retrieval-backed questions, and longer tool-assisted tasks. Documents Hub, Query, and DeepSpace have distinct workflows; configured models provide responses, while identity, tenant access, and tool policy stay in the application.
Public release v1.3.4
The current public GitHub release is v1.3.4, published from commit e3f7556. The release page lists Linux .deb and Windows .exe desktop packages; the product website currently advertises both web and desktop availability.
Published does not mean universal
AverQel has public web and desktop distribution paths. Self-hosting uses a separate manual Docker/VPS workflow and depends on configured services, secrets, providers, workers, backups, and staging checks.
Some capabilities remain gated
The repository marks Qel Connect as experimental beta. Browser research, sandboxing, schedules, push, email, and voice need their respective services and configuration; storage archive automation remains disabled until documented restore gates pass.
One task crosses several trust boundaries.
A document question or research task can touch source files, retrieval, a model provider, and external tools. Each part has its own permissions, state, and failure modes. The reviewer needs to see which source was retrieved, what context crossed a provider boundary, and whether an action waited for approval.
Keep evidence and authority separate.
Documents Hub owns source documents, Query performs scoped retrieval and returns source references, and DeepSpace manages persistent tasks and tool calls. The model can produce an answer or request a tool; authorization and execution policy are handled by the backend runtime.
The application and service boundaries.
Browser and desktop clients enter through the web/API boundary. Product workflows call tenant-scoped services and background workers; data stores, model providers, and optional external services remain separate components.
Request, work, and data planes
The same workspace is offered in a browser and an Electron desktop shell.
Browser workspace and API proxy.
Packaged client; release assets are published separately.
Authenticated routes establish user, tenant, and request context.
API routes and orchestration.
Identity, role, session, and capability checks.
Ownership filters apply to protected workflows and records.
Product areas keep source files, focused questions, and longer tasks in distinct workflows.
Upload, organization, extraction, and sharing.
Retrieval-first answers with source references.
Persistent conversations, runs, tools, and artifacts.
Approved MCP catalog, credentials, scopes, and action checks.
Durable data and queued work are separate from model output.
Relational records, chunks, and vector search.
Queues, coordination, and dedicated worker roles.
Private object storage and configured malware scanning.
Ingestion, DeepSpace, Library, datasets, MCP, and scheduled work.
Local inference or configured hosted providers for chat, embeddings, and optional reranking.
Reviewed remote servers and user or tenant credentials; connection and policy are required.
SearXNG and the isolated renderer are deployment services for supported web research paths.
Sandbox, SMTP, push, and voice features require their own configuration and service gates.
Two paths through the system.
The first path turns a source file into evidence used by Query. The second runs a longer DeepSpace task and puts tool policy between model output and external effects.
From an uploaded source to a cited answer
- 01Authenticated upload is scoped to the user and tenant.
- 02Format, archive, quota, and malware checks run before acceptance.
- 03Clean source bytes go to private object storage; a job is queued.
- 01Workers parse supported text and Office formats; OCR is available for supported image or scanned content.
- 02Extracted text is quality-checked, divided into chunks, and embedded by the configured embedding path.
- 03Tenant-linked document, chunk, and vector records are persisted for retrieval.
- 01Query authorization limits retrieval to accessible sources.
- 02Vector and keyword candidates are fused; a configured reranker may reorder them.
- 03The answer provider receives selected context; the response carries citation metadata and source snippets.
The model proposes; runtime policy decides
- 01User starts a conversation turn or queued task.
- 02Run state, ownership, selected documents, and relevant memory are loaded.
- 03The runtime records status and checkpoint data for the turn.
- 01Configured chat provider receives the prompt and selected context.
- 02It returns a user-facing answer or a structured request to call a tool.
- 03The model does not receive direct shell or unrestricted filesystem capability.
- 01Runtime checks the tool, caller, tenant, connector, and requested capability.
- 02Permitted read calls may proceed through a bounded broker.
- 03Side-effecting calls transition to an approval pause before execution.
A policy-allowed read tool runs through a native or connected-tool broker; its bounded result returns to the model turn.
A write or other external side effect pauses in an approval state. The user can review before the connector call continues.
Ordered activity events, run checkpoints, and approval decisions support inspection, cancellation, and resume paths; supported outputs can be stored as private artifacts.
Controls visible in the source.
The release source contains explicit authorization, scanner, connector-policy, run-state, and recovery code paths. Their effective protection still depends on the target deployment using the required settings and services.
Document upload checks authenticate the actor, apply tenant ownership, validate supported files and quotas, and call the configured malware scanner before bytes are stored.
The ingestion service persists job state and processes extraction, chunking, embeddings, and indexing through background worker paths.
Query retrieval carries tenant filters into vector and keyword candidate paths, then records reranking and citation metadata.
DeepSpace run state, ordered events, checkpoints, approval pauses, and user-owned resume paths are modeled outside the language model.
Connected tools pass through a catalog, credential, scope, and runtime policy boundary; side effects use an approval state.
Production Compose separates the API, frontend, database, queues, object store, scanner, and worker roles; the release workflow does not deploy VPS images automatically.
Evidence tied to a revision.
The chart counts test files in the v1.3.4 source tree. The executed results shown below are older local runs against v1.2.12 and are labeled as such.
Test files in the tagged source tree
What ran, and on which version.
Local pass totals below belong to the v1.2.12 checkout on 2026-09-03. They are not attributed to the later v1.3.4 release.
These are static file counts at commit e3f7556: 259 backend Python files named for pytest collection, 132 frontend .test.ts/.test.tsx files matched by the configured Vitest include pattern, and 12 separately tracked frontend Playwright specs. This audit did not execute those suites, so no v1.3.4 pass total is claimed.
A recorded full local pytest run completed with 806 passed and one dependency deprecation warning against the v1.2.12 source tree. It is retained as historical evidence only and is not presented as a test result for v1.3.4.
A recorded full frontend Vitest run completed with 80 files passed and 280 tests passed against the v1.2.12 source tree. It is separate from the later v1.3.4 source inventory and is not evidence that the current release passed the same run.
The v1.3.4 frontend tree contains 12 Playwright spec files under frontend/e2e. They are a static inventory only for this review; no browser run is claimed.
Capability is never authority.
Model output does not itself grant document access or connector authority. The application applies user and tenant checks, evaluates tool policy, and stores run and approval state. These controls reduce risk but do not guarantee that a deployment is secure without correct configuration and operation.
Public release; deployment-specific operation.
Source references at v1.3.4.
The links below are pinned to the release tag so reviewers can compare this description with the code and deployment map it describes.
Evidence checked against the public website and GitHub release on 2026-10-21. A later release may change the current version and source details.
AverQel combines source-document management, retrieval-backed questions, and persistent tool-assisted work with explicit data and action boundaries.