Intent opens a possibility space. Fruth records candidates and uses relevance and validated promotion to determine which work is owed. Its interpretive inference layer can infer meaning from evidence and propose interpretations, work and reviews; runtime contracts, validation and evidence govern accepted transitions.

Model inference generates token continuations; Fruth derives required work, permitted state transitions and fulfillment from the request, validated contracts and recorded evidence.

Recorded frames and artifact evidence support inspection and continuation of work. Mutable work, frozen frames and append-only successors remain distinct. Durable means supported persistence and continuation of recorded state; it does not mean infallible conclusions or guaranteed survival of every in-flight operation.

Status: Fruth 0.1.9 — experimental, usable, and still evolving within the 0.x series.

Conceived, designed, created, built, and developed by @fl0ri0.

Independent project. Fruth is built and maintained by one person, not a company, research lab, or funded team. It is human-led and AI-enhanced — a vibe-coded project in the literal, accountable sense. Product direction and release decisions remain human; AI tools helped explore, implement, test, and document the system. The project began with ideas developed over time before taking shape in early terminal scripts. It grew from a prototype whose small changes were still copied by hand into the current runtime substrate. Previously released as Ollmo, it continues as Fruth. This release does not imply institutional backing, a formal security audit, or a support organization.

Fruth combines a local browser interface and control plane with local model backends, interpretive inference routing, durable response frames, history, and materialized artifacts. Its core loop is:

Intent -> possibility space -> relevance -> promoted contracts -> runtime work -> review -> frozen state

A response is a frozen truthful moment of work: what was requested, what became owed work, what runtime evidence exists, what remains pending or blocked, and which outputs or artifacts can be referenced later.

Fruth uses a consistent vocabulary to connect intent, execution, evidence, and durable state. These terms give developers and AI coding agents shared reference points across code, tests, and documentation. When reviewing the architecture, consider whether each term captures a useful distinction and is applied consistently—not only whether it is immediately familiar.

Run ./fruth self-attack for adversarial conformance across discovered interpretive inference and runtime control profiles. It writes a human-readable report and JSON results; see self-attack conformance for coverage, live execution, budgets and regression replay.

The October 31 validation status records the bounded property-based investigation, responsibility refactoring, process and PDF corrections, and their source-bound checks. Release validation records exact dependencies and source identities. Earlier local, AFM and PCC campaigns and reference workflows retain their original execution dates and scope.

Five reference workflows preserve exact prompts, completed frames, monitor records and verified saved artifacts. The image-review and saved-file examples are from October 29; the other three are from October 27. See the report for historical results and the distinction between checked runtime contracts and model-answer accuracy.

If you use Fruth, its software design, or its evaluation artifacts in research or a published system, cite the software using CITATION.cff. Identify the exact version and commit or local snapshot used. Reference runs preserve their exact recorded execution identities and artifact evidence.

The intent-preserving block-resolution principle means that a block is not permission to rewrite the request. Its solution is its own verified resolution, handled gently through the substrate: keep intent anchored, keep the obligation visible, record the runtime evidence, choose the right-sized state transition, and freeze truthful state rather than the desired story. See Principle 10.

Within one canonical response, Fruth can route different promoted branches independently to compatible model instances and capabilities, materialize their distinct outputs through Late Fill, and bind each evidenced result back into the same response state. This is capability- and availability-dependent; it does not imply that every response uses more than one instance.

For research collaboration, replications, talks, panels, or work around Fruth, use the public contact methods on @fl0ri0's GitHub profile, with no guaranteed response time. The source is provided for inspection, use, research, and independent forks. The maintainer is open to collaboration and is still learning the issue, pull-request, and review process. Please bring clear explanations and patience; responses, reviews, merges, and ongoing support cannot be guaranteed. See CONTRIBUTING.md for participation guidance.

The primary tested environment is a recent macOS release on Apple Silicon with Python 3.11 or newer. Local capabilities require their corresponding Ollama, MLX, llama.cpp, or Apple Foundation Models backend and model. Windows, Linux, Intel Mac, remote hosting, and multi-user operation are outside the 0.1.9 support promise.

Extract the source archive, enter its directory (fruth-0.1.9 for the release, or fruth-main for the current repository ZIP), and run:

./fruth start

The executable launcher creates .venv and installs requirements.txt on first start. The selected python3 must be Python 3.11 or newer linked to OpenSSL 1.1.1 or newer; Apple's older Python/LibreSSL is unsuitable. Choose a suitable installed interpreter on PATH before first start, for example with Homebrew Python 3.11: PATH="$(brew --prefix python@3.11)/libexec/bin:$PATH" ./fruth start. Internet access is normally required for the initial dependency installation. Backend runtimes, model weights, Apple Intelligence availability and installed PCC Shortcuts are separate prerequisites for their respective capabilities. Backend runtimes and model weights are not bundled. For Apple PCC, choose Set up on its Models card or select PCC in the startup list. Fruth opens the bundled shortcuts on the Mac; review and click Add Shortcut, then start PCC. Manual import is also available in the PCC setup guide. Both signed shortcut exports and assisted setup are included in the source tarball.

Fruth startup initializes missing Research stores automatically and preserves existing candidates, reviews and Gold data. No separate Research startup command is needed. See the Research guide for candidate review, Gold curation and evidence retention.

./fruth start runs model selection and can create the environment itself. Press Enter at model selection to continue without starting a model. Startup starts the Flask webserver in the background, or reuses a verified webserver from this checkout on port 5011, and prints the dashboard URL. Verification checks the exact Python/script command, working directory, process birth identity and listener PID. Another service, another checkout, conflicting registry evidence or unavailable identity fails startup without a dashboard URL or a ready claim. A new launch must own the listener too; TCP occupancy alone is insufficient. This is process verification, not an HTTP/application health check. Use ./fruth status to inspect the stack and ./fruth restart to run stop followed by start. Refresh an open browser tab after restarting. Startup installs Python requirements only when it creates a new .venv. Before model discovery it checks that environment's own Python/TLS and uses pip's offline, non-installing checks for active direct requirements and transitive consistency. An unsuitable PATH Python does not block a valid existing .venv. Changed requirements remain usable when satisfied. Missing/broken interpreters, absent requirements.txt, incomplete installations and incompatible dependencies stop startup with repair guidance; startup never installs into, upgrades, deletes or rebuilds an existing environment. Keep model-backend environments separate; updating the main .venv does not update MLX, audio or native backend executables. Preserve your existing state/, artifacts/, Research data and settings; the release contains empty defaults for new installations, not a replacement for your saved data.

While Fruth is stopped, explicitly apply declared requirements to a valid existing environment (also after an interrupted first installation):

.venv/bin/python3 -m pip install -r requirements.txt .venv/bin/python3 -I -B scripts/bootstrap_preflight.py --venv .venv --requirements requirements.txt

Preflight requires pip >=22.2 for its supported install --dry-run CLI, paired with pip check. If pip is absent, repair it explicitly with .venv/bin/python3 -m ensurepip; if it is too old, explicitly install a supported pip with .venv/bin/python3 -m pip install 'pip>=22.2'. Startup does neither. Checks disable pip configuration, index access, caches and version lookups. The startup manifest supports one named distribution per line, optional version constraints and PEP 508 markers, blank lines and comments. URLs, local projects, archive paths, extras, includes, continuations and pip options are rejected before pip: dry runs of arbitrary projects can execute build hooks. These are metadata checks, not package import, native PDF, model or backend qualification.

For a missing/broken or incompatible interpreter, first restore its original base Python installation if possible. If replacement is necessary, stop Fruth, retain the old environment at a unique backup path, and create a new .venv explicitly with a suitable installed interpreter, for example:

Only when .venv.previous does not exist; keep it for recovery.

mv .venv .venv.previous "$(brew --prefix python@3.11)/bin/python3.11" -m venv .venv .venv/bin/python3 -m pip install -r requirements.txt .venv/bin/python3 -I -B scripts/bootstrap_preflight.py --venv .venv --requirements requirements.txt

Omit the move when .venv is absent. A moved venv is a backup, not a runnable environment: restore it to its original path with its matching base interpreter to roll back. Missing source files must be restored from the matching source archive. Start Fruth explicitly after the checks pass; preflight does not start it.

Existing JSON response histories require explicit migration before ordinary writes. Finish active work, stop all response writers, and verify a complete backup before running these commands from the updated checkout:

.venv/bin/python scripts/migrate_response_frame_index.py migrate --frames-dir state/response_frames --check-only .venv/bin/python scripts/migrate_response_frame_index.py migrate --frames-dir state/response_frames --writers-stopped .venv/bin/python scripts/migrate_response_frame_index.py check --frames-dir state/response_frames

Resume writers only after verification succeeds. Migration preserves the canonical Ledger, snapshots and evidence and selects one SQLite Index; retained JSON is inactive. Already migrated histories need no repeat migration. New installations initialize SQLite through the frame writer. The same tool provides explicit rebuild and current-history rollback operations; see the Response Frame contract.

Fruth's default backend ports are 11434 (Ollama), 11435–11500 (dedicated Ollama), 11501–11550 (MLX), 11551–11600 (llama.cpp), and 11601–11650 (Apple Foundation Models). The optional Apple PCC Shortcuts adapter uses 11651–11700. Apple AI supports local text and image analysis through the installed fm serve with the API model system; multiple instances appear separately in the existing UI. See the Apple AI Image Mode control for explicit OCR and barcode/QR recognition through the installed CLI tools, with verified tool-result receipts. See the Apple AI guide for