Skip to main content
Download native releases for Linux x86-64 and macOS ARM64 from the canonical Meerkat Recall repository. Recall 0.9.1 uses Meerkat 0.9.0. Use each archive with its matching release record. Existing 0.1.0 archives retain their original dependencies and receipts. See release binaries for the promotion process and build provenance requirements.

​
Choose the matching artifact

Recall 0.9.1 passed archive verification, isolated installation, --version and a local-model inference case on macOS 26.5.2 (Apple Silicon): one document, two semantic queries and stored finite, nonzero 384-dimensional vectors. The release qualification record identifies the model and native build source. Older macOS versions were not exercised. The executable’s macOS 11.0 load command alone does not establish the minimum supported OS for its statically linked runtime. Check each release’s actual host and dynamic-library results before treating another OS version as supported. No Windows, Linux ARM64, or Intel macOS binary is specified by this release matrix. Obtain the archive and checksums.sha256 from the selected canonical release and keep them in the same directory. Use the checksum and source identity recorded for that release; a checksum bundled with an untrusted download does not establish its origin. The meerkat-recall-native/v1 manifest records the exact source commit/tree, SHA256 of git archive --format=tar HEAD, Cargo.lock and executable digests, build profile/features/compiler, and every bundled file. The third-party tree includes the exact patched PDF parser and SurrealKV source and notices. An external trusted archive SHA256 authenticates the manifest itself. For a complete offline install using Python 3.12+, use the matching trusted source’s scripts/release/artifact.py:
The installer verifies all contents before publishing a new directory. It refuses an existing destination and does not start a service or replace a running executable. Retain the complete version directory for skills, licenses and provenance. Read the selected archive digest from the trusted manifest:
Choose a new absolute destination and retain its complete tree. Add that version directory to your PATH, or use its absolute meerkat-recall path. Set PIPELINE_SKILLS_DIR to its installed skills directory. Installation does not start a service, initialize storage, provide credentials or approve model use. Continue with service setup for those steps.

​
Archive layout and provenance

Archives have a flat layout: meerkat-recall, the elephant compatibility symlink, licenses, provenance.json, artifact.py, service/, third-party/, docs/ and skills/. Keep these together. Model weights and provider credentials are separate. The source release also retains the patched dependency sources. The native build commit and release source can differ. The archive’s embedded provenance.json retains its actual build source. For the 0.9.1 macOS archive, the separate release provenance asset records actual_build_source, release_source and source_mapping; metadata_derivation identifies the metadata-only archive change and preserved executable. These records do not claim a rebuild at the release commit. Use each archive with its matching release provenance and checksum. --version alone does not identify an exact build.

​
Run the model-backed demo

The default-feature executable includes Meerkat extraction. demo-wiki asks models to plan articles, write them, and verify their statements before it starts serving the demo. It needs provider credentials and model access; provider calls can incur charges. No database service is required. The demo uses the explicitly named default space inside its isolated memory store. Copy service/demo-wiki-processing.example.json from the native archive (or deploy/native/demo-wiki-processing.example.json in a source checkout) and replace the account, model and immutable model-version placeholders with your approved values. It uses the same SpaceProcessingConfig contract as the service: wiki_planner, wiki_writer and wiki_verifier each need an unrevoked binding. A separate verifier may use a separate profile and connection. Other provider connections remain available through that shared contract. credential_ref names an environment variable, never a key value. Configure that variable through your normal secret configuration before running. The example uses RECALL_DEMO_PROVIDER_KEY; it does not infer authorization from conventional ambient API keys or select a default model. Supplying the file approves those operations only in the isolated demo store. It does not modify a running service.
Add --port 3100 if port 3000 is occupied. When startup finishes, inspect the printed article-generation results and the context projection, compilation receipt, and source evidence at the printed loopback URLs. Do not count missing credentials, failed model calls, or blocked articles as successful semantic generation. The demo uses an isolated in-memory store; Ctrl-C stops it and discards the demo data. For a credential-free projection demo, use the separate no-default-features source build. That build leaves the article wiki empty and does not validate the distributed binary’s model path. For durable data, continue with persistent deployment and its readiness and authentication checks.

​
Retain skills for persistent extraction

Keep the entire bundled skills/ tree in the extracted directory after installing the executable. Persistent extraction needs these guidance files. Set PIPELINE_SKILLS_DIR to that tree’s absolute path in the environment of the server or standalone worker that performs extraction:
For a service, configure the same value in its service environment. For a container, mount the retained skills tree and use its absolute container path. If an older or private archive lacks skills/, obtain the matching skills tree from its source before enabling persistent extraction. Do not rely on a developer checkout, the process working directory, or a path embedded during compilation being available on an installed machine. A missing skills file only produces a warning and processing continues without that guidance, so startup success alone does not verify the configuration. This setting concerns persistent pipeline extraction. It does not replace the provider credentials required by the model-backed demo above.