README.md

---
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.).