Memory Genome Engine v0.1.3

Explicit memory versioning and cleanup

v0.1.3 adds an explicit append-and-supersede workflow and safe physical cleanup for durable facts and decisions.

• mge supersede <cell-id> <replacement> appends a replacement without rewriting sealed pages.
• MGE records a typed old-to-new relation; default recall returns the current version.
• mge compact is a non-mutating dry run that reports reclaimable memory.
• mge compact --apply physically removes confirmed superseded, deprecated, and rejected cells.
• --archive <path> can preserve a complete binary pre-prune store before deletion.
• Temporary cells are only pruned when an explicit --temporary-older-than-days policy is supplied.
• Compaction is available through CLI, TUI, mge_compact, Python, and TypeScript.

Safety and compatibility

• Untyped or ambiguous superseded cells are retained unless a valid replacement relation exists.
• Compaction uses a recoverable transaction and deep-validates the rebuilt store before committing it.
• Encrypted stores and optional archives remain encrypted; a wrong key is rejected.
• Integration schema is now version 6; JSON-RPC protocol version is unchanged.
• Existing manifests remain readable through backward-compatible defaults.
• Binary page format, page codec, MarkerGenome, recall modes, CandidatePageIndex API, and the hot -> checkpoint -> seal -> recall lifecycle are unchanged.
• MGE does not infer semantic contradictions automatically. The caller decides when one memory supersedes another.
• Physical pruning is not guaranteed secure erasure on SSDs, snapshots, backups, or copied stores.

Measured evidence

A deliberately garbage-heavy local fixture with 100 sealed cells, including 50 confirmed obsolete versions, measured:

Metric	Before	After
Store size	385,732 B	6,956 B
Cells	100	50
Pages	3	1

That fixture reclaimed 98.2%; it demonstrates physical removal and is not a universal storage ratio. All 50 retained current cells remained recallable and deep validation passed.

A/B synthetic checks against the prior v0.1.3 source showed ordinary Exact focused/broad recall within about 3% run variance, with no systematic recall regression.

Verification

• 219 workspace Rust tests and 24 development eval tests passed locally.
• Strict Clippy, rustdoc warnings, Rust 1.95 MSRV, and package-version synchronization passed.
• GitHub CI passed on Ubuntu, Windows, and macOS.
• Release archives were built for Linux x86-64, Windows x86-64, macOS x86-64, and macOS Apple Silicon.
• Archive installers passed in GitHub Actions on Ubuntu, Windows, and macOS.
• All four downloaded archives matched SHA256SUMS; the Windows archive reported mge 0.1.3 and exposed the new compaction command.

Install

Download the archive for your platform and verify it with SHA256SUMS, or use the checksum-verifying release installers documented in Quickstart.

Full changelog: v0.1.2...v0.1.3

Contact

For commercial integration, support, collaboration, and partnership inquiries:

   

Memory Genome Engine v0.1.2

Memory Genome Engine v0.1.2 strengthens retrieval quality, failure recovery, and agent-facing recall controls while keeping the existing binary store format and hot -> checkpoint -> seal -> recall lifecycle.

Highlights

• Added global lexical rank fusion for more accurate sealed-memory ordering.
• Enforced recall output budgets consistently across focused, broad, and full-scope workflows.
• Added the optional min_score recall floor to CLI, MCP, Python, and TypeScript integrations. Defaults remain unchanged.
• Added rollback for incomplete seal transactions so failed sealing does not leave partially committed catalog/index state.
• Exposed derived lexical-index diagnostics for validation and performance investigation.
• Clarified one-command setup for Codex, Claude Code, Cursor, and generic MCP hosts.
• Raised the additive integration schema contract to version 4.

Compatibility

• No storage migration is required from v0.1.1.
• Existing recall behavior is preserved unless min_score is explicitly provided.
• Product archives contain only mge, mge-mcp-server, licenses, and user documentation. Development benchmark binaries are not distributed.

Verification

• 203 workspace tests and 20 retrieval-evaluation tests passed.
• Strict clippy, rustfmt, rustdoc, and Rust 1.95 MSRV checks passed.
• Windows and Linux release archives were installed and exercised through plain/encrypted recall, checkpoint, seal, deep validation, wrong-key rejection, and MCP workflows.
• macOS Intel and Apple Silicon archives were built and installer-smoked on GitHub-hosted macOS runners; local interactive macOS verification remains community feedback work.
• All attached archives are covered by SHA256SUMS.

Retrieval evidence

On the repository's deterministic evaluation corpus:

• hot focused hit/recall: 0.994 / 0.994
• repeated sealed focused hit/recall: 1.000 / 1.000
• repeated sealed broad hit/recall: 1.000 / 1.000

These numbers describe the included workload, not universal quality or a cross-project comparison.

Full changelog: v0.1.1...v0.1.2

Contact

For commercial integration, support, collaboration, and partnership inquiries:

   

Memory Genome Engine v0.1.1

Memory Genome Engine v0.1.1 is a release-hardening update for local agent integration and verified distribution.

Highlights

• Added default store/passphrase context to mge-mcp-server, while preserving per-call overrides.
• Added mge setup codex, mge setup claude-code, mge setup cursor, and mge setup generic-mcp with dry-run, conflict detection, rollback commands, and MCP smoke verification.
• Added checksum-verifying GitHub Release installers for PowerShell and POSIX systems. They install only mge and mge-mcp-server without admin/root access.
• Added Windows, Linux, and macOS installer gates to the release workflow.
• Improved the two-session local memory demo and public onboarding.
• Extended the development-only eval harness with lexical, paraphrase, hard-negative, and mixed profiles plus MRR@K/nDCG@K.
• Fixed Python 0.1.1 wheel metadata for current setuptools/PEP 639 behavior.

No runtime storage layout, binary format, MarkerGenome model, encryption format, or recall mode semantics changed in this release.

Verification

• 197 Rust workspace tests passed.
• Strict workspace clippy and rustdoc warnings passed.
• Rust 1.95 MSRV check passed.
• Hosted Windows, Ubuntu, and macOS CI passed.
• Release archives were built for Windows x86-64, Linux x86-64, macOS Apple Silicon, and macOS Intel.
• Installer smoke passed on hosted Windows, Ubuntu, and macOS.
• Downloaded final Windows/Linux archives were checksum-verified, installed, and executed as mge 0.1.1.

Known limitations

• Payload encryption does not hide the marker dictionary, candidate indexes, catalog summaries, access patterns, Markdown exports, or unlocked process memory.
• Recall ranks candidates but does not currently expose a universal semantic abstention threshold; callers should treat returned memory as context, not a verified answer.
• Python and TypeScript SDKs remain thin local CLI wrappers and are not published to package registries.
• macOS is covered by hosted CI/release jobs; no physical macOS machine was available for manual interactive TUI verification.

Verify the selected archive against SHA256SUMS before extraction.

Full changelog: v0.1.0...v0.1.1

Contact

For commercial integration, support, collaboration, and partnership inquiries:

   

Memory Genome Engine v0.1.0

Memory Genome Engine v0.1.0

Memory Genome Engine is a local-first structured memory engine for AI agents. This first public release provides a Rust core, binary runtime storage, a terminal product surface, a versioned stdio MCP adapter, and thin Python and TypeScript SDKs.

Highlights

• remember -> L1 Hot RAM + durable hot log -> checkpoint/seal -> sealed pages -> recall -> ContextPacket
• Structured MarkerGenome metadata with focused, broad, and full-scope recall
• RAM-first hot recall, immutable sealed pages, metadata pruning, and exact or optional Binary Fuse candidate indexes
• Balanced, fast, and safe durability modes with snapshot/replay recovery and single-writer store locking
• Optional authenticated encryption for hot records, snapshots, and sealed page payloads
• mge CLI, interactive TUI/setup flow, diagnostics, validation, index rebuild, and Markdown migration/export
• Standard MCP stdio lifecycle plus stable versioned tool schemas
• Thin local Python and TypeScript wrappers over the Rust CLI

Packages

• mge-windows-x86_64.zip
• mge-linux-x86_64.tar.gz
• mge-macos-x86_64.tar.gz
• mge-macos-aarch64.tar.gz
• SHA256SUMS

Each archive contains only the mge and mge-mcp-server product binaries, license/notice files, and canonical user documentation. Development benchmark binaries are intentionally excluded.

Verification

• Rust 1.95 MSRV check
• Workspace formatting, tests, strict Clippy, and rustdoc warnings
• Windows, Ubuntu, and macOS hosted CI product smokes
• Downloaded Windows and Linux archive checksum, plain/encrypted lifecycle, and MCP smokes
• cargo audit: no known vulnerabilities in 179 scanned production dependencies

The published engineering baseline on an Intel Core i7-9750H / Windows 10 x64 reports Focused Hit@5 and Recall@5 of 1.00, hot focused recall averaging 0.49 ms, repeated sealed focused recall averaging 0.28 ms, and cold store open plus focused recall averaging 2.39 ms. These are deterministic synthetic measurements, not competitor claims or end-to-end LLM answer benchmarks. See docs/RELEASE.md for the method and limitations.

Security and limitations

• Encrypted stores protect memory payloads at rest; marker dictionary, indexes, catalog summaries, file sizes, access patterns, process memory, ContextPacket output, and explicit Markdown exports remain plaintext by design.
• Passphrases are supplied through environment variables and remain session-scoped; there is no OS keychain integration yet.
• macOS x86_64 and arm64 archives are built and smoke-tested on GitHub-hosted macOS runners. Physical install verification on a user-owned Mac remains tracked in issue #2.
• Archives are not code-signed or notarized, and package-manager publication is not part of v0.1.0.
• The marker-based engine does not require a vector database. Embeddings are intentionally not part of this baseline.

Store formats remain compatible with the earlier preview; no migration is required for stores created by the current v0.1 implementation.

Contact

For commercial integration, support, collaboration, and partnership inquiries: