| --- |
| license: cc-by-2.5 |
| language: |
| - en |
| metrics: |
| - accuracy |
| new_version: GrokciAI/Quidoris_Engine |
| repository: https://github.com/Grokci/Quidoris_Engine/tree/main |
| tags: |
| - chemistry |
| - biology |
| - finance |
| - music |
| - art |
| - code |
| - climate |
| - medical |
| - agent |
| - text-generation-inference |
| - document-question-answering |
| pipeline_tag: reinforcement-learning |
| library_name: fastai |
| --- |
| # Infra / local-first implementation details |
| - sqlite |
| - fts5 |
| - streaming |
| - sse |
| - local-inference |
| - byok |
|
|
| # Intended ecosystem compatibility |
| - openai-compatible |
| - huggingface |
| - mistral |
| - llama |
|
|
| # Product-ish / devtool signals |
| - devtools |
| - productivity |
| - citations |
| - interpretability |
| --- |
|
|
| # Core Idea |
|
|
|
|
| **Core idea:** *Don’t stuff your library into the model. Let the model interact with the library.* |
|
|
| Relationship Learning Models promise the ability to have unlimited context windows by providing an environmment in which they can "scan" a document library and retrieve |
| information from this library be taking small snapshots of the information, and either answering the prompt provided it from these snapshots, or, additionally call small agents |
| to assist it in returing their reply to the user's prompt. This model type promises to reduce content rot to zero. |
|
|
| The Quidoris Engine is an RLM environment. It is a harness that lives independently from an RLM but RLM's can dock with the harness and use its powerful environment |
| to run an unlimited context window. Right now LLM's are limited to a few million token context windows. |
| RLM's, in concert with the Quidoris Engine, have unlimited contect windows. Think 1000 documents or 10000 document context windows. This is what the |
| Quidoris Engine does for all RLM's. |
|
|
|
|
|
|
| # Model Card for Model ID |
|
|
| Quidoris Engine (RLM Harness) |
|
|
| Quidoris Engine is a **local-first** inference harness inspired by *Recursive Language Models (RLMs)*: |
| it treats long prompts and large document libraries as an **external environment**, letting models **search, read, cite, and recurse**—instead of cramming everything |
| into a single context window. |
|
|
| It runs as a **local daemon** with an HTTP API (SSE-friendly) and ships with a lightweight local web UI. |
|
|
|
|
|
|
| ## Model Details |
|
|
| ### Model Description |
|
|
| A RLM inference harness to allow any user to utilize RLM's locally on their own machines. |
|
|
| ## What this is |
|
|
| - A **local daemon** (Bun) + **SQLite/FTS5** index for fast retrieval |
| - A **provider-agnostic** harness (BYOK): Local CLI / Hugging Face / OpenAI-compatible providers |
| - A **UI Launcher** that can auto-start the daemon (since browsers can’t spawn local processes) |
| - An “evidence-first” workflow: **citations** and **evidence spotlight** are first-class |
|
|
| --- |
|
|
| ## Why it exists |
|
|
| Large models struggle with: |
| - **Context window limits** |
| - **Hallucination risk** when they can’t reference exact evidence |
| - **Cost blowups** when prompts get huge |
|
|
| Quidoris Engine makes “long context” feel interactive: |
| - keep the **source material outside** the model |
| - allow **programmatic access** via search/read APIs |
| - produce answers with **traceable evidence** |
|
|
| --- |
|
|
| ## Features |
|
|
| ### Library + Index |
| - Local SQLite index (`rlm_index.sqlite`) |
| - FTS5 search (chunked content for recall + precise snippets) |
| - Incremental indexing (re-index only when files change) |
|
|
| ### RLM-friendly runtime |
| - Designed for “action → observe → recurse” loops |
| - Planned/compatible with async/batched `llm_query` patterns |
| - SSE endpoints for streaming runs/steps (where available) |
|
|
| ### Local web UI |
| - Glassy login/boot screen |
| - “Enter the Engine” auto-starts the daemon via the local launcher |
| - Workspace scaffold (`/app`) for Library / Runs / Evidence |
|
|
| --- |
|
|
| ## Install |
|
|
| ### Requirements |
| - **Bun** (recommended) |
| - SQLite (bundled via `bun:sqlite`) |
|
|
| Clone / download from Hugging Face or GitHub. |
|
|
| --- |
|
|
| ## Quickstart (local) |
|
|
| ### 1) Build UI |
| ```bash |
| cd ui |
| bun install |
| bun run build |
| |
| |
| |
| - **Developed by:** Ken Isaacson, Sr. "Grokci" |
| - **Funded by [optional]:** Quidoris Research Group" |
| - **Shared by [optional]:** Quidoris Research Group" |
| - **Model type:** Relationship Learning Model Harness - for use with Relationship Learning Models and Large Language Models |
| - **Language(s) (NLP):** BUN, Python, SQLite |
| - **License:** cc-by-2.5 |
| - |
| ### Model Sources [optional] |
| |
| <!-- Provide the basic links for the model. --> |
| |
| - **Repository:** [More Information Needed] |
| - **Paper [optional]:** [More Information Needed] |
| - **Demo [optional]:** [More Information Needed] |
| |
| **Quidoris Engine is not a trained model**, it’s a *local RLM harness/engine + daemon + UI*. |
| |
| |
| --- |
| |
| ## Uses |
| |
| Quidoris Engine is intended to be used as a **local-first inference harness** that enables RLM-style workflows: treating large prompts and document libraries as an **external environment** the model can interact with via actions (search/read/cite), rather than loading everything into the model context. |
| |
| Foreseeable users: |
| |
| * Individual developers running local tooling |
| * Researchers prototyping RLM-like inference loops |
| * Teams running BYOK workflows on laptops/workstations |
| * Contributors extending adapters, ingestion, or UI |
| |
| People potentially affected: |
| |
| * The user (and any collaborators) whose documents are indexed and queried |
| * Anyone whose content is included in the local library (e.g., shared docs) |
| * Any downstream consumers of generated outputs (reports, emails, code, decisions) |
| |
| ### Direct Use |
| |
| Direct use means running Quidoris Engine locally as shipped: |
| |
| * Start the **launcher + UI** locally |
| * Auto-start the **daemon** |
| * Index and manage a local document library |
| * Use the daemon API to: |
| |
| * search local docs (FTS5) |
| * read snippets/regions |
| * generate model outputs with evidence/citations (as those endpoints are implemented) |
| * Use the UI to: |
| |
| * sign in locally |
| * enter the workspace (“Engine”) |
| * (planned) upload/manage docs, tags/folders, run tasks, view evidence spotlight |
| |
| Typical scenarios: |
| |
| * “I have a large folder of PDFs + notes. Let the model answer questions with citations.” |
| * “I want a controllable long-context tool that’s provider-agnostic.” |
| * “I want an RLM-like loop where the model chooses actions (search/read/subcall) and I can inspect evidence.” |
| |
| ### Downstream Use [optional] |
| |
| Downstream use means embedding Quidoris Engine into a larger system (still local-first) or using it as a substrate for an RLM agent/controller: |
| |
| * Integrating Quidoris Engine into an internal toolchain via `/v1/*` API |
| * Building a custom “RLM controller” that: |
| |
| * decides actions (search/read/transform/query-submodel) |
| * calls Quidoris Engine as the environment layer |
| * streams steps via SSE to a UI or logger |
| * Extending adapters for model providers (HF inference, local CLI, OpenAI-compatible servers) |
| * Building domain-specific ingestion pipelines (PDF→text, audio→transcript, etc.) |
| |
| ### Out-of-Scope Use |
| |
| Quidoris Engine is **not** intended for: |
| |
| * Running as a public hosted multi-tenant SaaS (this repo is local-first by design) |
| * Handling regulated/high-stakes workflows without additional controls (health, legal, finance) |
| * Serving as a security boundary between untrusted users and private documents (local indexing implies access) |
| * “Guaranteed correctness” answers: it can improve evidence access, but models can still misinterpret |
| * Real-time collaborative editing or “Google Drive-like” shared document management |
| * Malware, phishing, or abusive content generation (the tool should not be used to facilitate harm) |
| |
| --- |
| |
| ## Bias, Risks, and Limitations |
| |
| Technical limitations: |
| |
| * Retrieval is only as good as: |
| |
| * ingestion quality (OCR, parsing errors) |
| * chunking strategy |
| * query formulation |
| * SQLite FTS5 is lexical (not semantic embeddings by default). It can miss paraphrases unless augmented. |
| * Evidence spotlight/citations reduce hallucinations but don’t eliminate: |
| |
| * incorrect reasoning |
| * cherry-picked evidence |
| * quoting irrelevant snippets |
| * Provider behavior differs: different LLMs can produce different answers to identical evidence. |
| |
| Sociotechnical / user risks: |
| |
| * Private data risk: users may index sensitive documents; local-first reduces exposure but doesn’t remove it. |
| * “Trust from polish” risk: a beautiful UI can cause over-trust in outputs. |
| * Misuse risk: tool can be used to summarize or extract sensitive data if the library contains it. |
| * Attribution risk: users may treat retrieved snippets as definitive without verifying full context. |
| |
| System limitations (current repo state): |
| |
| * Many `/v1/*` endpoints in the OpenAPI spec may still be stubs returning `501` until implemented. |
| * Current auth is local-oriented and not a full enterprise IAM solution. |
| * Uploading non-text media (images/audio/video) requires ingestion pipelines not yet included by default. |
| |
| ### Recommendations |
| |
| * Treat outputs as *drafts* unless validated, especially for high-stakes decisions. |
| * Always inspect: |
| |
| * which documents were retrieved |
| * which chunks were used |
| * whether the snippet context is sufficient |
| * Add guardrails for sensitive libraries: |
| |
| * separate profiles/databases for different projects |
| * explicit “do not index” directories |
| * local encryption at rest if required |
| * If you enable remote access, lock it down: |
| |
| * bind to localhost only (default) |
| * require auth |
| * avoid exposing ports publicly |
| * For better recall, consider augmenting FTS with semantic retrieval later (optional plugin). |
| |
| --- |
| |
| ## How to Get Started with the Model |
| |
| > Quidoris Engine is a tool (daemon + UI), not a trained model. |
| |
| ### Quickstart (local UI + auto-start daemon) |
| |
| ```bash |
| # Build the UI |
| cd ui |
| bun install |
| bun run build |
|
|
| # Start the launcher (serves UI + proxies API + can spawn the daemon) |
| cd .. |
| bun run ui:launch |
| ``` |
| |
| Open: |
| |
| * [http://127.0.0.1:5173](http://127.0.0.1:5173) |
| |
| Click **Enter the Engine**: |
| |
| * launcher starts the daemon if needed |
| * UI waits for `/v1/health`, performs login, routes to `/app` |
| |
| ### Daemon only (no UI) |
| |
| ```bash |
| bun run quidoris-engine.ts daemon --port 8787 |
| # then call: |
| # GET http://127.0.0.1:8787/v1/health |
| ``` |
| |
| --- |
| |
| ## Training Details |
| |
| > Not applicable. Quidoris Engine is not a trained model; it is a local-first harness for running inference workflows against user-provided documents and user-selected model providers. |
| |
| ### Training Data |
| |
| Not applicable. |
| |
| ### Training Procedure |
| |
| Not applicable. |
| |
| #### Preprocessing [optional] |
| |
| Not applicable (except local document ingestion/indexing, which is not training). |
| |
| #### Training Hyperparameters |
| |
| * **Training regime:** Not applicable. |
| |
| #### Speeds, Sizes, Times [optional] |
| |
| Not applicable for “training.” |
| (Performance notes that *are* relevant would be indexing speed, query latency, daemon startup time, etc., which depend heavily on machine and library size.) |
| |
| --- |
| |
| ## Evaluation |
| |
| Quidoris Engine itself is not evaluated like a model, but it can be evaluated as a *system* (retrieval quality, citation accuracy, latency). |
| |
| ### Testing Data, Factors & Metrics |
| |
| #### Testing Data |
| |
| Not applicable as a model card training set; for system evaluation you can use: |
| |
| * a curated local doc set with known answers |
| * “needle-in-haystack” tests (known facts buried in large libraries) |
| * long-context QA benchmarks adapted to tool-based retrieval (optional) |
| |
| #### Factors |
| |
| Suggested evaluation factors: |
| |
| * document types: markdown, txt, html, pdf→text, code, emails |
| * library size: 100 docs vs 10k docs |
| * chunk sizes: 8KB vs 32KB |
| * query styles: keyword vs natural language |
| * provider differences: local vs hosted LLMs |
| |
| #### Metrics |
| |
| Suggested metrics for system-level evaluation: |
| |
| * Retrieval: |
| |
| * recall@k (did the correct doc appear in top k?) |
| * snippet precision (did the snippet contain the needed evidence?) |
| * Evidence correctness: |
| |
| * citation validity (does cited text actually support the claim?) |
| * Latency: |
| |
| * search time |
| * end-to-end “question→answer” time |
| * Stability: |
| |
| * incremental indexing correctness |
| * reproducibility across runs |
| |
| ### Results |
| |
| Not yet reported in this repository. |
| |
| #### Summary |
| |
| Quidoris Engine is an infrastructure layer; evaluation is best done per deployment and provider choice. |
| |
| --- |
| |
| ## Model Examination [optional] |
| |
| Not applicable as a trained model. |
| However, Quidoris Engine supports *system examination*: |
| |
| * evidence spotlight (inspect chunks used) |
| * step traces (for RLM-like action/observation loops) |
| * logs of search/read actions |
| |
| --- |
| |
| ## Environmental Impact |
| |
| Not applicable as a trained model. |
| |
| For local usage: |
| |
| * emissions are dominated by whichever model provider you choose (local GPU, hosted inference, etc.) |
| * Quidoris Engine overhead is primarily: |
| |
| * SQLite indexing (CPU) |
| * serving UI + HTTP daemon (minimal) |
| |
| If you want, you can report: |
| |
| * indexing energy/time on a reference machine |
| * typical daemon runtime overhead |
| |
| --- |
| |
| ## Technical Specifications [optional] |
| |
| ### Model Architecture and Objective |
| |
| Quidoris Engine is not a model architecture. It is an **inference harness** + **local environment** that: |
| |
| * stores a document library externally (SQLite + FTS5) |
| * exposes tools (`search`, `read`) via HTTP |
| * supports an agent/controller loop (RLM-style) that can recurse and cite evidence |
| * uses SSE-friendly API patterns for streaming steps/results |
| |
| ### Compute Infrastructure |
| |
| Runs locally on user machines. |
| |
| #### Hardware |
| |
| Typical: |
| |
| * CPU laptop/workstation |
| * optional GPU if running local models (not required for the engine itself) |
| |
| #### Software |
| |
| * Bun runtime |
| * SQLite via `bun:sqlite` |
| * UI: Vite + React (local web app) |
| * API: local HTTP daemon + launcher proxy |
| |
| --- |
| |
| ## Citation [optional] |
| |
| |
| **BibTeX:** |
| |
| ```bibtex |
| @software{quidoris_engine_2026, |
| author = {Quidoris Research Group}, |
| title = {Quidoris Engine: Local-first RLM Harness}, |
| year = {2026}, |
| url = {https://huggingface.co/Quidoris/Quidoris_Engine |
| } |
| ``` |
| |
| **APA:** |
| Quidoris Research Group. (2026). *Quidoris Engine: Local-first RLM Harness* [Software]. Hugging Face. [https://huggingface.co/](https://huggingface.co/)<ORG>/<REPO> |
| |
| --- |
| |
| ## Glossary [optional] |
| |
| * **RLM (Recursive Language Model):** an inference strategy where the model treats long prompts as an external environment and recursively operates over parts of it via tools/actions. |
| * **FTS5:** SQLite Full-Text Search extension for fast lexical search with ranking/snippets. |
| * **BYOK:** Bring Your Own Key — you supply API credentials to providers; tool does not centrally store them. |
| * **Evidence spotlight:** UI pattern that opens the exact retrieved snippet(s) supporting a claim. |
| * **SSE:** Server-Sent Events — HTTP streaming alternative to WebSockets for one-way event streams. |
| |
| --- |
| |
| ## More Information [optional] |
| |
| * OpenAPI spec: `openapi/openapi.yaml` |
| * API quickstart: `docs/api.md` |
| * DB schema: `docs/db_schema.sql` |
| * Error schema: `docs/errors.md` |
| * Pagination: `docs/pagination.md` |
| * SSE notes: `docs/sse.md` |
|
|
| --- |
|
|
| ## Model Card Authors [optional] |
|
|
| * Quidoris Research Group |
|
|
| ## Model Card Contact |
|
|
| * Project contact: **Ken (@grokci)** |
|
|
| --- |
|
|
| If you want, I can also rewrite this in the “official HF style” with a tighter tone and a short “TL;DR” at the top, plus a more HF-native tag set (`tools`, `agent`, `retrieval-augmented-generation`, etc.). |
