After finding an old decision

Suppose we take over Harbor and need to know which service currently sends its transactional email. The fixture contains an early choice, an explicit reversal and a separate project’s decision. Every record below is fictional, written by BitShovel.

For the English question about Harbor’s current email provider and the reason, the first two results came from the old August 1 session. The September 4 session first appeared at rank 6; with the Chinese wording, at rank 5. Reading only the first result would miss the reversal.

In this trial, recall returned ranked passages and links to their context. Scores rank results; they are not probabilities that a decision is current. We used get on seven sources covering old and new email choices, cache settings, login sessions and a timeout, recovering each complete fixture answer.

• Check identity first: similar names or the same provider do not establish the same project or use.
• Read dates and explicit reversals: identify which earlier choice a replacement or withdrawal changes.
• Expand the context for reasons, conditions and exceptions. Raw sessions can contain speculation, model answers and pasted output from an earlier search.
• If a conflict remains unresolved, check later records or the current project before acting on it.

The fixture has 14 sessions and 28 messages. We fixed four answerable questions and one absent-fact question before retrieval, asking each in English and Chinese. We retained the default top eight results, then inspected source context.

All eight answerable queries included the full current decision somewhere in the returned output. This describes a small, deliberately constructed fixture, not real-project accuracy. Superseded cache and login records also remained among the results.

No input states Harbor’s annual marketing budget. Both budget queries still returned eight passages, without a budget answer. The retrieval list itself did not establish that the requested fact was absent.

Separately, we downloaded a pinned huggingface/funes-memory snapshot and asked about four design choices: append-only storage, inference backends, text-first indexing and retaining raw passages. Each question was asked in English and Chinese. These are real public development records, separate from the synthetic fixture.

The backend question led to useful reasons in both languages. For Chinese, expanding the third result revealed the explanation about native inference and build maintenance. English context for text-first indexing explained the per-turn budget and explicit target; Chinese results concentrated more on interface and documentation edits.

For append-only storage and raw passages, English results supplied partial context, while the Chinese top eight did not directly explain the requested rationale. Without a complete answer set for the corpus, this does not show the reasons are absent or establish a language benchmark.

In separate diagnostics, disabling time decay left the old email choice first and did not supply the missing direct explanations for the three selected Chinese questions. We also explored one rephrasing, retaining the original results throughout.

We ran the official arm64 funes 1.3.0 binary on an 8 GB Apple Silicon Mac, checking release, model and corpus revisions and hashes. The binary, two models with tokenizers and public sample total about 1.50 GB. Interrupted transfers required repair; setup time is not reported as a standard installation benchmark.

With models cached, queries took about 1.8–2.2 seconds on the fixture and 5.1–6.6 seconds on the public sample. Peak resident memory reached about 1.84 GB. Each question had one initial run. These observations exclude reading, verification and rework, and do not establish human time saved.

Compare your existing search too. Literal Mailgun search in the same fixture’s answers found three records: Harbor’s old and new choices and Cedar’s choice. Postmark matched only the new decision. This assumes you already know the exact term. We did not time human searches and have no evidence to recommend replacing the existing method wholesale.

Trufflehog was not installed. Indexing reported secret redaction disabled and still completed for the synthetic input; completion therefore does not establish redaction. We did not test personal sessions, publishing a memory or a coding agent sending retrieved text to a hosted model.

If you often recover decisions across sessions, known records provide a useful first check of retrieval and context. In a real project, compare with your existing search method and check whether the agent handles later changes correctly. This trial covers the retrieval step only.

The download contains 14 fictional sessions, bilingual questions, our original fixture results and a runner. It needs no personal chat history and includes neither binary nor models. Use Python 3 and the official funes 1.3.0 executable, then follow the README. Initial model downloads total about 1.26 GB.

The runner indexes only the bundled fixture into a new directory for each run, asks ten questions and opens the old and new email context. You can read the included results before deciding whether to run it.

• funes 1.3.0 ↗Official releaseObtain the binary for your system and verify the release checksum.
• README · 1.3.0 ↗Pinned versionMaintainer documentation for commands, models and integrations.
• funes-memory ↗Public development recordsThe corpus revision used in this trial; earlier claims still require evaluation.