> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rkat.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Binary installation

> Verify and install a Meerkat Recall release archive, then configure its model-backed demo.

Download native releases for Linux x86-64 and macOS ARM64 from
[the canonical Meerkat Recall repository](https://github.com/lukacf/meerkat-recall/releases).
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](/recall/operations/deployment#release-binaries) for the promotion process
and build provenance requirements.

## Choose the matching artifact

| Target | Archive name |
| - | - |
| Linux x86-64 | `meerkat-recall-VERSION-x86_64-unknown-linux-gnu.tar.gz` |
| macOS ARM64 (Apple Silicon) | `meerkat-recall-VERSION-aarch64-apple-darwin.tar.gz` |

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`:

```bash theme={null}
python3 scripts/release/artifact.py install \
  --archive meerkat-recall-VERSION-TARGET.tar.gz \
  --sha256 TRUSTED_ARCHIVE_SHA256 \
  --destination /absolute/releases/recall-VERSION-DIGEST
```

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:

```bash theme={null}
archive=meerkat-recall-VERSION-x86_64-unknown-linux-gnu.tar.gz
# Use aarch64-apple-darwin on Apple Silicon.
expected_sha256="$(awk -v name="$archive" '$2 == name { print $1 }' checksums.sha256)"
test "${#expected_sha256}" -eq 64
python3 scripts/release/artifact.py install \
  --archive "$archive" --sha256 "$expected_sha256" \
  --destination /absolute/releases/recall-VERSION-DIGEST
```

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](/recall/operations/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.

```bash theme={null}
meerkat-recall demo-wiki --processing-config /private/demo-processing.json
```

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](/recall/quickstart#try-the-demo-first). That build
leaves the article wiki empty and does not validate the distributed binary's
model path. For durable data, continue with
[persistent deployment](/recall/operations/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:

```bash theme={null}
# Replace this with the absolute skills path in your retained bundle.
export PIPELINE_SKILLS_DIR="/absolute/path/to/extracted-recall/skills"
```

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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.