> ## Documentation Index > Fetch the complete documentation index at: https://docs.lilfella.app/llms.txt > Use this file to discover all available pages before exploring further. # The harness, engine, and model > The three-part architecture behind Fella's model loop, local analytics, and evidence. > Fella separates model judgment from application control and data execution. ## Definition Fella has three cooperating parts: | Part | Responsibility | | ------- | --------------------------------------------------------------------------------------------- | | Model | Proposes tool calls and writes the response | | Harness | Builds context, exposes tools, runs the loop, records evidence, and finishes the answer | | Engine | Catalogs files and implements local SQL, document, Python, chart, and verification operations | The separation keeps providers replaceable and puts tool execution outside the model request. ## Architecture ```text filename="architecture overview" theme={null} question + context | v +-----+------+ +----------------+ | Harness |<----->| Model provider | +-----+------+ +----------------+ | tool calls v +-----+------+ +----------------+ | Registry |---->| Analytics | +-----+------+ | engine | | +-------+--------+ | | +--------> ToolOutput/results | v Evidence | v Verification ``` The model receives text context, tool schemas, and returned tool results. It does not receive a database handle or a general application API. The harness is the only path from model tool calls to the registered implementations. The registry turns a tool result into an evidence item; the analytics engine itself returns computation, not evidence. ## Flow 1. The engine scans an open folder and prepares a catalog and queryable tables. 2. The harness combines that schema with the question, conversation context, `fella.md`, and folder memory. 3. The selected model either answers or proposes one or more tool calls. 4. The harness executes registered calls and records their results as evidence. 5. The loop repeats until the model answers or a stop condition is reached. 6. Deterministic verification runs before the completed answer is emitted. Some warnings can also trigger an optional, tool-free model second opinion. ## Behavior The engine does not call an LLM and is exposed to analytics code through a narrow `AnalyticsSource` trait. The Svelte frontend is a client of the Rust/Tauri backend: it sends commands, streams events, and renders answers, evidence, tabs, and controls. The standard registry contains seven fixed built-in tools. There is no runtime connector or plugin expansion path in the personal release. ## The narrow engine seam The verifier does not receive the whole application state. It receives only the catalog and read-only SQL capability it needs: ```rust theme={null} pub trait AnalyticsSource { fn catalog(&self) -> Catalog; fn run_sql(&self, sql: &str) -> EngineResult; } ``` `EngineState` implements this trait by delegation. That keeps verification independent of Tauri commands, credentials, conversation state, and the model provider. See the [engine implementation](https://github.com/Avijit-Kumar-GIT/fella/blob/main/src-tauri/src/engine/analytics/mod.rs) and the [state adapter](https://github.com/Avijit-Kumar-GIT/fella/blob/main/src-tauri/src/engine/state.rs). ## Ownership map | Concern | Current owner | Boundary | | ------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------- | | Prompt, model turns, stopping, cancellation | [`agent.rs`](https://github.com/Avijit-Kumar-GIT/fella/blob/main/src-tauri/src/engine/agent.rs) | Does not implement SQL, parsing, or statistics | | Built-in and runtime tool dispatch | [`tools.rs`](https://github.com/Avijit-Kumar-GIT/fella/blob/main/src-tauri/src/engine/tools.rs) | Converts tool output into the shape the harness records | | Catalog and data access | [`analytics/data/`](https://github.com/Avijit-Kumar-GIT/fella/tree/main/src-tauri/src/engine/analytics/data) and `catalog.rs` | Does not call an LLM | | Evidence and streamed answer contract | [`evidence.rs`](https://github.com/Avijit-Kumar-GIT/fella/blob/main/src-tauri/src/engine/evidence.rs) | Serializes results for the Svelte client | | Post-answer checks | [`analytics/verify.rs`](https://github.com/Avijit-Kumar-GIT/fella/blob/main/src-tauri/src/engine/analytics/verify.rs) | Checks recorded work; does not prove intent | For the user-facing version of this flow, see [read the evidence](/developer-platform/using-fella/evidence). For provider and Python network boundaries, see [privacy and security](/developer-platform/using-fella/privacy). ## Limits * The model can still choose the wrong query or misread an ambiguous question. * Deterministic verification checks evidence consistency and known query patterns; it does not prove the user's intended meaning. * The SQL and document paths are bounded and read-only. `run_python` uses the same host-side data boundary from an embedded WASM guest; it has no filesystem, network, environment, or subprocess capability and is bounded by Wasmi resource limits. * A hosted model provider sees the prompt and tool results sent to it. The inert `/mcp` command makes no separate network request. ## Next steps See how context, tool calls, stopping, and verification fit together. See how files become local tables, documents, and evidence. Review the seven fixed built-ins and their execution boundaries. Review provider protocols, credentials, and network boundaries.