Generated banner for WARM
Generated logo for WARM

WARM

Memory serverOfficial Writerslogic project

Created by Writerslogic

Published in writerslogic/warm. Publisher page

27 GitHub stars

What it is

WritersLogic Adaptive Retention & Memory (WARM): local document search (BM25 + embedding cosine) and vector-symbolic associative memory.
— the description by Writerslogic

AutoGineer overview, from the brain’s own files

WARM (WritersLogic Adaptive Retention & Memory) is a local-first memory engine designed to provide AI agents and applications with persistent storage and retrieval. It combines traditional document search—using stemmed BM25 and vector-based cosine similarity—with a vector-symbolic layer for associative memory and multi-hop queries. The system is built in Rust and can be deployed as an embedded library, an HTTP server, or an MCP server, allowing it to integrate with various agent hosts and development environments. It emphasizes local control, offering optional encryption and provenance features while avoiding external service calls or telemetry.

How it works

Memory model: Hybrid

AutoGineer overview, from the brain’s own files

The system stores text, vectors, and facts in a local directory. It uses a hybrid approach where document search combines chunking and BM25 with vector embeddings. The vector-symbolic layer utilizes sparse hypervectors to support associative memory, triples, and multi-hop queries. It provides an API for memory management including remember, recall, and forget operations, with support for source provenance and atomic storage updates.

Folders
FolderRoleFiles
.githubagent-config37
assetsattachments10
docsdocs1850
examplesexamples47
scriptsscripts77
srcsource-code327
teststests362
benchesfolder7
benchmarksfolder2898
bindingsfolder273
deployfolder18
figuresfolder6
fuzzfolder54
integrationsfolder225
interopfolder3
notebooksfolder3
npmfolder1
proptest-regressionsfolder1
schemasfolder9

The agent reads

Requirements

Runtimes: Node.js, Python >=3.9, Rust

Databases: SQLite

API keys (by name): WARM_API_KEY

Works with: Gemini CLI

Set it up

  1. This brain runs code automatically: 1 hook (claude-code), 1 script. Review benchmarks/results/sbg_positions_development/setup.sh, integrations/editors/claude-code/plugin/hooks/hooks.json before opening the folder in Claude Code. No step below turns a hook on for you.

    • benchmarks/results/sbg_positions_development/setup.sh: sh benchmarks/results/sbg_positions_development/setup.sh
    • integrations/editors/claude-code/plugin/hooks/hooks.json: node
  2. Not scanned by AutoGineerThe author’s README also describes installing it from a clone of its repository. Read its install section: AutoGineer did not scan that path. https://github.com/writerslogic/warm/blob/e176d5572dd86bf2233bcb120e3a485dc109ea3a/README.md#get-started
  3. Not scanned by AutoGineerThe author’s README also describes installing it as the npm package writerslogic-warm. Read its install section: AutoGineer did not scan that path. https://github.com/writerslogic/warm/blob/e176d5572dd86bf2233bcb120e3a485dc109ea3a/README.md#get-started
  4. Created by Writerslogic. Published in writerslogic/warm. Licence: Apache License 2.0.

Usage

AutoGineer overview, from the brain’s own files

  • Integrating memory into an AI agent via the MCP server.
  • Building local-first applications that require embedded search and storage.
  • Providing a multi-tenant memory service via the HTTP server.
  • Using the Rust library for in-process memory management.
“Remember that the project deadline is Friday.”
The agent stores the fact with associated metadata, making it available for future retrieval.
“Recall information about the project deadline.”
The agent retrieves the stored fact using hybrid search and provides the information with source provenance.

Documentation by Writerslogic

<img src="https://raw.githubusercontent.com/writerslogic/warm/main/assets/crystal-halo/crystal-detailed-static.png" alt="WARM logo" width="96" align="left">

WARM

Local memory for AI agents and applications.

WARM (WritersLogic Adaptive Retention & Memory) gives agents persistent memory, full-text and vector search, and source provenance in one embeddable Rust engine. Use it inside your application, through HTTP, or from an MCP client, with storage on infrastructure you control.

Image: CI Image: MSRV 1.89 Image: OpenSSF Scorecard Image: OpenSSF Best Practices Image: License: Apache-2.0 Image: WARM MCP server: quality and maintenance score on Glama

Website · Docs · Get started · Standards and provenance · Evaluation · Capabilities · Limits · Contribute

<br clear="left">

What it is

WARM is a Rust library that stores text, vectors and facts in a directory on your machine and finds them again. It ships with optional Node.js, C, WASM and UniFFI bindings, an HTTP server with portable JavaScript and Python clients, and an MCP server. The embedded engine makes no service calls or telemetry requests. HTTP clients connect to the server you configure; model stages are opt-in.

CapabilityWhat you get
Document searchChunking, stemmed BM25 over blocked postings, Boolean and phrase queries, hybrid fusion with embeddings you supply, metadata filters, byte offsets
Vector indexGraph index with a memory-mapped vertex file, an updatable delta for inserts and deletes, optional query-aware routing trained on sample queries
Memory APIremember, recall, forget and explain with time validity and supersession; conversation memory with source provenance
StorageAtomic replace and delete, crash-safe journal and checkpoints, verified compaction, one writer per store
SecurityOptional AES-256-GCM storage encryption with documented coverage and limits, signed audit log, COSE/SCITT provenance
Vector-symbolic layerSparse hypervectors with bind, bundle and permute, triples with multi-hop queries, Hopfield cleanup

Who it's for

You are buildingWhat you get
An agent or assistant that needs memoryA memory API with forgetting that removes facts from the store, and an MCP server for editors and agent hosts
A local-first or offline appEmbedded search and storage in one directory, with no server process and optional encryption
A service that needs vector or text searchwarm-server over HTTP with tenants and scoped keys, or the library in-process

Get started

For an editor or agent host, start with the MCP integration. For an application, choose the Rust library or HTTP server below. WARM runs locally or on your own infrastructure; this repository does not provide a managed cloud service.

To try the offline memory demo from source:

git clone https://github.com/writerslogic/warm
cd warm
cargo run --release --example demo-offline-agent

<details open> <summary><strong>Rust</strong></summary>

From your own Rust project, add the current Apache-2.0 source. The crate is warm-rust; the library is imported as writerslogic_warm. The MSRV is Rust 1.89; local-models and --all-features need Rust 1.94 or newer.

cargo add warm-rust

The historical v0.6.1 source remains AGPL-3.0-or-later; it is available from that Git tag, not as a warm-rust 0.6.1 release on crates.io.

use writerslogic_warm::{DocumentInput, WarmCore, SearchOptions};

let dir = tempfile::tempdir()?;
let warm = WarmCore::new(4096, Some(dir.path().display().to_string()), None)?;
warm.memorize_document(DocumentInput {
    id: "backups".into(),
    text: "Restore deleted documents from verified backups.".into(),
    source_uri: Some("operations.md".into()),
    version: Some("1".into()),
    metadata: Some(serde_json::json!({ "project": "alpha" })),
    chunk_words: None, overlap_words: None, store_text: None, embeddings: None, title_weight: None,
})?;
let hits = warm.search_documents("restore backups", &SearchOptions::default())?;
println!("{} {:?}", hits[0].document_id, hits[0].source_uri);

Rust API change in 0.6.6 (0.6.5 returns these values directly): WarmCore::query, query_batch, and analyze_components return Result. Handle the result with ? or an explicit error branch; deferred-encoding failures no longer become successful partial query results. get_document, list_documents, get_document_info, and list_document_info also return Result; retained-text and checkpoint decoding failures propagate instead of panicking, and reads no longer hydrate the entire checkpoint or hold store locks during text I/O.

</details>

<details> <summary><strong>JavaScript and TypeScript: portable client</strong></summary>

warm-sdk 0.2.1 is the portable HTTP client for a separately running warm-server. It has no native binaries or runtime dependencies and uses standard Fetch and Web Streams APIs (Node 18 or newer). Installing or importing it does not load the embedded engine or download models. For a published release, install the client in your application:

npm install [email protected]

Check the available npm versions. To build the client from this checkout:

npm ci --prefix bindings/js/warm-sdk
npm run build --prefix bindings/js/warm-sdk

In your application, install that directory with npm install /absolute/path/to/warm/bindings/js/warm-sdk.

Start the server in a separate terminal:

cargo build --release --features server --bin warm-server
WARM_API_KEY=change-me target/release/warm-server --input-dim 384
import { WarmClient } from 'warm-sdk'

const warm = new WarmClient({
  url: process.env.WARM_URL ?? 'http://127.0.0.1:8080',
  apiKey: process.env.WARM_API_KEY, tenantId: 'demo',
})
await warm.memory.remember('Restore deleted documents from verified backups.', {
  id: 'backups', metadata: { project: 'alpha' },
})
const hits = await warm.memory.recall('restore backups', { filter: { project: 'alpha' } })
console.log(hits[0]?.text)

Set WARM_API_KEY to the server's key before running the client. This memory example uses lexical retrieval and needs no embedding model. A runnable source example also checks retrieval and deletion in an isolated namespace:

WARM_URL=http://127.0.0.1:8080 WARM_API_KEY=change-me \
  node examples/quickstart/js-client/quickstart.mjs

See the client API and release availability. Browser deployments must permit the application's origin at the HTTP service boundary.

</details>

<details> <summary><strong>Node.js: optional embedded engine</strong></summary>

writerslogic-warm embeds the Rust engine in Node. For a published engine release, install it explicitly with npm's optional dependencies enabled:

npm install [email protected]

Check the available npm versions. To build from the cloned repository, with Rust installed:

npm ci --omit=optional
npm run build

The portable client and embedded engine are separate packages with different APIs. listDocuments supports scoped pruning. See the integration guide for source provenance, namespace isolation, dry runs and deletion limits.

const { WarmMemorySystem } = require('writerslogic-warm')
const { DocumentMemory } = require('writerslogic-warm/semantic')

async function main() {
  const dir = require('node:fs').mkdtempSync(require('node:path').join(require('node:os').tmpdir(), 'warm-readme-'))
  const memory = new DocumentMemory(new WarmMemorySystem(4096, dir))
  await memory.memorize({
    id: 'backups', text: 'Restore deleted documents from verified backups.',
    sourceUri: 'operations.md', version: '1', metadata: { project: 'alpha' },
  })
  const [hit] = await memory.search('restore backups', { filter: { project: 'alpha' } })
  console.log(hit.documentId, hit.sourceUri, hit.text)
  await memory.flush()
}
main().catch(error => { console.error(error); process.exit(1) })

</details>

<details> <summary><strong>Server and Python</strong></summary>

The Python package warm-sdk is an HTTP client for warm-server, which stores vectors you supply. (warm-python, imported as writerslogic_warm, provides native vector indexes and phase vectors, but no document search.)

cargo build --release --features server --bin warm-server
WARM_API_KEY=change-me target/release/warm-server --input-dim 384 &
uv pip install warm-sdk
from writerslogic_warm_sdk import WarmClient

client = WarmClient(url="http://127.0.0.1:8080", api_key="change-me", tenant_id="demo")
client.add_documents([{"id": "a", "vector": [0.1] * 384, "text": "hello", "metadata": {}}])
print(client.query([0.1] * 384, top_k=1)["matches"][0]["id"])

Endpoints, flags, tenants and limits are in the server docs. A runnable Python quickstart with a toy embedder is in examples/quickstart/python.

</details>

<details> <summary><strong>MCP</strong></summary>

warm-mcp serves a store to any Model Context Protocol client over stdio or HTTP:

npx -y writerslogic-warm-mcp                                # stdio; downloads a verified binary on first run
npx -y writerslogic-warm-mcp --transport http               # http://127.0.0.1:8765/mcp

The MCP package is a separate launcher. To build the server from source:

cargo build --release --features mcp,security --bin warm-mcp   # add local-models for semantic recall
./target/release/warm-mcp                                       # stdio
./target/release/warm-mcp --transport http                      # http://127.0.0.1:8765/mcp

Client setup, data directory and the one-writer rule: MCP integration.

For normalized content from multiple applications, see the organizational knowledge adapter.

</details>

The five-minute quickstart walks through ingest, search, a SQLite FTS5 comparison and encryption in Rust, Python and Node, and CI runs that code on every pull request. For a whole agent memory with no embeddings and no network, run cargo run --example demo-offline-agent.

<a id="headline-results"></a> <a id="where-its-behind"></a>

Evaluation

Recorded results and limitations cover memory quality, text retrieval and vector search. Each result retains its workload, hardware, model, source revision and known losses. The full comparison and reproduction protocol provide the evidence for evaluating WARM on your own workload.

What ships today

CapabilityStatusDocumented limit
Hybrid document search (BM25 + exact cosine, filters, byte offsets)ShipsExact scan of eligible chunks; benchmark your corpus before assuming capacity (guide)
Boolean lexical search (+required, -excluded, quoted phrases)ShipsFlat queries only, no nesting; an empty or only-excluded query matches nothing (design)
Atomic replace/delete, crash-safe journal, verified compaction, process lockShipsOne writer per store; compaction is not secure erasure
Vector index (qgraph vertex graph, memory-mapped)ShipsBuild time and serving RSS behind hnswlib on SIFT-1M (gaps)
Updatable vector index (durable delta for inserts and deletes)ShipsSingle writer; format in VECTOR-UPDATES.md
Query-aware graph routing (trained on sample queries)Ships (opt-in)Needs representative training queries; tested on VIBE llama and yi (report)
Memory API: remember, recall, forget, explainShipsForgetting removes a fact from the store; it does not cover what a model inferred (docs)
Conversation memory (conversation-memory)ShipsBounded context with exact source provenance; native recall not yet benchmarked on LongMemEval end to end
Meaning memory: triples, multi-hop, Hopfield cleanupShips (runtime opt-in)Tested on synthetic and 2,120-fact sets (research_bench_16384_256.json)
Union-bundle membership (experimental)ResearchAt D = 16,384: positive gap to N = 500 (4% false positives), tested to 2,500 (benchmark_scaling_results.json)
Sparse vector index (memorize_vector)ExperimentalNot competitive with HNSW (results)
Encrypted stores (security)ShipsAES-256-GCM, Argon2id; covers the log, index caches and the text segment. Metadata, file names and sizes are not encrypted
Signed audit log, credential-gated access, COSE/SCITT/C2PA (provenance)ShipsHost must authenticate DIDs; PoSME, RATS, did:web not implemented
On-device models (local-models: Qwen3 embed/rerank/LLM)ShipsLocal weights only; never downloads
warm-server HTTP API, multi-tenant (server)ShipsSingle node; TLS, per-tenant scoped keys (guide)
MCP server (mcp: warm-mcp, stdio and HTTP)ShipsEncryption needs security; semantic recall needs local-models
JavaScript/TypeScript client (warm-sdk 0.2.1)Source and release buildsPortable HTTP client; requires a separately running server
Embedded Node.js (writerslogic-warm 0.6.8)Source and release buildsEight optional native platform packages; separate from the client
C, Go, .NET, Java, Kotlin, Swift and WebAssembly bindingsSource availableRequire local builds; the language packages and native bundles are not yet published (runtime guides)
PythonHTTP client (warm-sdk); native vector indexes and phase vectors (warm-python)No in-process document search
Query-private search (private-search)ExperimentalFor searching an index someone else holds; hides the query vector from the scorer only (notes)

Optional engine capabilities use Cargo features or runtime configuration; Cargo features lists the build choices.

The compatibility policy defines API stability, deprecation windows and storage-format migration rules.

Architecture

flowchart TB
  subgraph bindings["Bindings and servers"]
    rust["Rust crate"]
    node["Node: writerslogic-warm (napi)"]
    ffi["C, WASM, UniFFI"]
    clients["JavaScript and Python: warm-sdk"]
    server["warm-server (HTTP)"]
    mcp["warm-mcp (stdio, HTTP)"]
  end
  subgraph engine["Engine API"]
    core["WarmCore: documents, vectors, facts, mutation gate"]
    prov["Security and provenance: signed audit log, COSE/SCITT"]
  end
  subgraph indexes["Indexes and memory"]
    text["Text index: blocked postings, BM25, Boolean and phrase"]
    vector["Vector index (qgraph): vertex file, updatable delta, query-aware projection"]
    memory["Memory API: remember, recall, forget, conversation memory"]
    vsa["Vector-symbolic layer: bind, bundle, Hopfield cleanup"]
  end
  subgraph storage["Storage"]
    journal["Journal and checkpoints"]
    segments["Append-only segments (CRC32, LZ4)"]
    mapped["Memory-mapped files"]
    crypto["AES-256-GCM encryption (optional)"]
  end
  clients --> server
  rust --> core
  node --> core
  ffi --> core
  server --> core
  mcp --> core
  core --> text
  core --> vector
  core --> memory
  core --> vsa
  core --> prov
  memory --> text
  text --> journal
  vector --> journal
  memory --> journal
  journal --> segments
  segments --> mapped
  segments --> crypto

Module map: docs/ARCHITECTURE.md.

Limits

  • Not anonymous. Hypervector sketches and term counts are not encryption; anyone with a store can encode candidate text and compare. storeText: false keeps term counts, IDs and embeddings, so it is not a privacy control.

  • Document search is conventional. It does not use the hypervectors; the holographic parts are the algebra and the meaning memory.

  • One writer per store. A second writing process fails at open with a lock error.

  • Capacity numbers are points, not guarantees, and are stated only over the tested range (capacity).

  • Benchmark results are single machines. Conditions are in each results file; the single-core ann-benchmarks run and the VIBE high-recall points are losses (see Where it's behind).

  • Masking is obfuscation. Client-side vector masking preserves every pairwise similarity.

  • A store is a directory and WarmCore::new(.., None, ..) uses the current directory.

Full statement: docs/PRIVACY.md. Report vulnerabilities privately via SECURITY.md.

Contributing

CONTRIBUTING.md: setup, the checks CI runs, DCO sign-off (git commit -s, no CLA). Start with a good first issue or Discussions. See the Code of Conduct. Benchmark changes regenerate the results file they touch; the README cites files, not remembered figures.

License

Apache-2.0. See LICENSE. Use, modify and embed it in open-source or proprietary software, including network services, with no copyleft obligation. The historical v0.6.1 source remains available under its AGPL-3.0-or-later license.

docs/DETERMINISTIC-RESONATOR.md

Deterministic quantized-phase resonator for VSA factorization

What this is. A validation, not a discovery. It pairs two published mechanisms — the quantized-phase FHRR substrate (qFHRR) and the Frady/Kent resonator network — and measures the effect of phase quantization on factorization accuracy. The reported experiments found overlapping accuracy distributions down to 4 bits/dimension over the tested range. The substrate stores integer phases; factorization uses floating point inner products, superpositions, and phase recovery. It is not integer-only.

This document reports numbers produced by a run in this repository (resonator-factorize, 24 seeds). It does not restate figures from memory; every number below carries its seed count and standard deviation.

Claim

A resonator network run at finite phase resolution N (the qFHRR bundle-recover quantization) matches the float FHRR resonator's factorization capacity — the size of the search space F^k it can decode — across F from within capacity to past the knee in the experiments below. Down to N = 16 (4-bit phase) the curves overlap within ±1σ at every F tested. Overlapping standard deviations do not establish statistical equivalence or guarantee the same accuracy on other codebooks, dimensions, or query distributions.

The contribution is the combination plus this measurement: qFHRR (arXiv 2604.25939) explicitly does not do resonators or factorization; Frady/Kent resonator networks are float. These measurements support using quantized phases for these factorization workloads; they do not establish a universal capacity guarantee.

Method

src/bin/research/resonator-factorize.rs. D = 1024, k = 3 factors (search space F^3; two factors is trivially within capacity and measures nothing — see "Why three factors" below).

  • Each factor axis has a codebook of F random phase vectors. Phases are drawn in Z_N (quantized, qFHRR) or continuous (N = 0, the float FHRR baseline).

  • A composite is the bind (phase-add) of one true entry per axis: c = x_a ⊙ y_b ⊙ z_c.

  • The resonator maintains a superposition estimate per factor, initialized to the snapped sum of that factor's codebook. Each iteration, for each factor: unbind the other factors' current estimates, project (similarity-weighted) onto the factor's codebook, and snap each dimension back to a unit phasor quantized to N levels (the qFHRR recover step). Early-stop when the argmax per factor is stable for 3 iterations; cap 40 iterations.

  • Readout: argmax similarity per factor. Success = all three factors correct.

  • Metric: factorization accuracy, mean ± std over 24 seeds × 32 trials per cell. Chance = 1 / F^3.

Why three factors. With two factors the task is 100% everywhere in the tested range — an answer by construction, not a capacity measurement. Three factors is the honest Frady/Kent benchmark: accuracy falls as F^3 crosses the substrate's capacity.

Cheapest disconfirming test first. F = 16 at N = 256: if the resonator did not recover all three factors near-perfectly at this within-capacity size, the dynamics or the quantized substrate would be broken. It scores 98±2% — the setup is sound before sweeping the knee.

Results

3-factor factorization accuracy, mean ± std over 24 seeds × 32 trials, D = 1024, 40 iterations. float = continuous phase (FHRR baseline); N = 256 = 8-bit phase; N = 16 = 4-bit phase. Run in this loop, 2026-07-07.

F (search space F³)chance (1/F³)floatN = 256 (8-bit)N = 16 (4-bit)
16 (4 096)0.024%99±298±298±3
24 (13 824)0.0072%89±587±789±6
32 (32 768)0.0031%77±577±977±8
40 (64 000)0.0016%69±965±767±8
48 (110 592)0.0009%59±859±956±9

The capacity knee sits at F ≈ 24–32 (search space ~14k–33k ≈ D^1.5 = 32k for D = 1024), matching Frady/Kent theory — evidence the setup is validated, not rigged. Float, 8-bit, and 4-bit phase overlap within ±1σ at every F; the largest gap (F = 40, 69 vs 65) is under 1σ, and the deviations are non-monotonic in N — noise, not a quantization trend. Every cell is orders of magnitude above the 1/F³ chance floor even past the knee.

Validation hardening (wider seeds, phase-bit and dimension sweeps)

To tighten confidence in the headline, src/bin/research/resonator-sweep.rs extends the same fixed design (identical dynamics, verified below) along two controlling parameters: phase resolution across float/8/6/4/3/2 bits (N ∈ {0,256,64,16,8,4}) and dimension D ∈ {512, 1024, 2048}, at 30 seeds × 32 trials. This adds no new mechanism — it sweeps parameters of the §20 experiment to see how far "quantization is free" holds.

Integrity check (the run reproduces §20 exactly). The sweep first re-runs the frozen configuration — D = 1024, 24 seeds, N ∈ {0, 256, 16} — and reproduces the Results table above cell-for-cell (99±2 / 98±2 / 98±3 at F = 16 … 59±8 / 59±9 / 56±9 at F = 48). The reimplemented dynamics are therefore faithful, so the extended numbers below are trustworthy.

Phase-bit robustness at D = 1024 (30 seeds). float / 8-bit / 6-bit / 4-bit / 3-bit / 2-bit:

Ffloat8-bit6-bit4-bit3-bit2-bit
1698±398±298±398±398±395±4
2489±587±789±590±687±680±7
3276±678±978±778±775±872±9
4069±865±866±867±863±761±9
4858±858±958±856±956±951±10

Float through 4-bit overlaps within ±1σ at every F — the §20 "4-bit is free" claim survives the wider seed set. 3-bit also tracks float within noise. 2-bit (N = 4) is the first resolution with a consistent deficit, largest near the knee (F = 24: 80±7 vs 89±5, ≈1.5σ). So "free" holds down to ~3–4 bits/dimension and begins to cost at 2 bits — the headline is confirmed, and its lower boundary is now measured, not assumed.

Dimension robustness (30 seeds). The free-quantization pattern holds at every D; absolute capacity scales with D as Frady/Kent predict (~D^1.5), so the knee moves right with larger D, but the quantized columns track float within ±1σ at each D (down to 3-bit). Selected float / 4-bit / 2-bit cells:

DF=16 (fl/4b/2b)F=32 (fl/4b/2b)F=48 (fl/4b/2b)
51289±5 / 90±7 / 81±858±8 / 60±8 / 54±835±8 / 35±7 / 37±8
102498±3 / 98±3 / 95±476±6 / 78±7 / 72±958±8 / 56±9 / 51±10
2048100±1 / 100±0 / 99±293±4 / 91±6 / 83±676±8 / 75±5 / 64±12

Every cell above sits orders of magnitude over the 1/F³ chance floor (< 0.03%). Reproduce with cargo run --release --bin resonator-sweep (std-only, deterministic; seeds 0..24 for the repro block, 0..30 for the sweep).

Head-to-head vs float incumbent (§29, pre-registered, confirmed on unseen seeds)

Pre-registered in PREREGISTRATION-binding-readout.md §29 as a footprint comparison against the SOTA float Frady/Kent resonator, with a kill that could fire. Evidence is a fresh seed block (100..130), unseen at design time (resonator-sweep 100); the built-in REPRO CHECK still reproduced the §20 table, confirming the code path.

Kill did not fire. At the reference D=1024, 4-bit (N=16) equals or exceeds float at every F within ±1σ: 97/90/78/70/60 vs float 97/88/77/67/58 (F=16..48). It holds at D=512 and D=2048, and 3-bit (N=8) also tracks float; only 2-bit (N=4) shows the small knee deficit. Thus 4 bits/dim is a tested phase resolution with overlapping factorization accuracy in these experiments (3-bit also overlaps).

Representation budget: a phase from N = 16 can be encoded in 4 bits, compared with a 32- or 64-bit continuous phase angle. The historical accuracy experiment did not measure the library's allocated memory. PhaseHVec stores every phase in a u16, even at N = 16; the default PhaseResonator caches two f64 values per codebook coordinate (16 bytes). Its footprint was never 4 bits/dimension.

The optional packed index described below now implements 4-, 8-, or 16-bit codebook storage. Its shared phasor table, initial estimates, and query workspace must also be counted. Packing is a memory/throughput tradeoff, not a tradeoff-free reduction of all resonator state.

Library implementation and packed codebooks

PhaseResonator::new and with_config retain expanded codebooks. Construction precomputes the initial estimates and a bounded phasor lookup table when useful; queries reuse their working buffers and retain the final argmax instead of recomputing it. The arithmetic order and stopping rule remain unchanged.

PhaseResonator::with_packed_codebooks(&codebooks, config) chooses an alternative resident representation:

Phase resolutionCodebook payload per coordinateShared lookup table
2..=164 bits (two coordinates per byte)16 * N bytes
17..=2568 bits16 * N bytes
257..=6553616 bits16 * N bytes

Both backends also retain 16 * factors * D bytes of floating initial estimates, plus vector metadata. Queries keep floating estimates and temporary buffers. PhaseHVec's public representation remains u16. At large N and small codebooks, the packed backend's table can outweigh its payload savings; choose the backend using total index memory and query latency for the intended workload.

The immutable baseline, exact differential tests, allocation accounting, and timing harness are in benchmarks/results/holography_resonator_v1. The baseline comparisons include multiple seeds through the capacity knee, corrupted queries, packing boundaries, ties, and iteration limits. They establish output parity for those cases on the tested platform, rather than a new factorization algorithm or a larger capacity. Empty factor axes and dimension/resolution mismatches now fail at the API boundary; zero factors still return an empty result.

Interpretation and honest scope

The reported experiments support quantized phase storage for resonator factorization down to N = 16 in the tested workloads. The query still uses floating point arithmetic, and bitwise equality across platforms or math libraries is not promised.

Scope this claim does not exceed:

  • Single clean composite. This is the standard Frady/Kent benchmark: one bound product, no bundle. Factoring a fact out of a superposition of many stored facts is a separate regime where quantization noise can compound with bundle interference; it is not measured here (see §21 in PREREGISTRATION-binding-readout.md, which is underpowered and not shipped).

  • Float readout arithmetic. The isolated variable is the phase resolution N of the stored/snapped state. The resonator's inner products are computed in float here; a fully fixed-point resonator would be a separate implementation requiring its own capacity and numerical validation. Integer substrate tests do not validate that unimplemented algorithm.

  • Capacity is per-composite factorization, not superposition storage. This does not change WARM's bundle-capacity story (sharding); it is about decoding a single bound tuple.

Reproduction

cargo run --release --bin resonator-factorize

The bin is self-contained (std only; it reimplements the phase dynamics), so no cargo features are needed. Deterministic: seeds 0..24 are fixed in the binary, so the table above reproduces exactly. The library-level capability is exercised by:

cargo test --lib phase_resonator
cargo test --test phase_resonator_regression
cargo test --doc phase_resonator   # runs the PhaseResonator doctest

Public API: writerslogic_warm::core::PhaseResonator (reusable index over fixed codebooks) and writerslogic_warm::core::phase_resonator_factorize (one-shot), over the writerslogic_warm::core::PhaseHVec substrate.

References

  • qFHRR — quantized-phase Fourier Holographic Reduced Representations. arXiv 2604.25939 (Apr 2026). The discrete-phase substrate: integer bind/unbind/similarity/ bundle via modular arithmetic and LUTs, ~lossless vs complex FHRR at K ≥ 16. Provides the deterministic substrate; does not address resonators or factorization.

  • Frady, Kent, Olshausen, Sommer (2020) — "Resonator Networks, 1: An Efficient Solution for Factoring High-Dimensional, Distributed Representations of Data Structures." Neural Computation 32(12):2311–2331 (companion part 2 by Kent et al., same issue). The resonator dynamics (superposition estimates, alternating unbind + cleanup) and the ~D^1.5 capacity scaling this run reproduces. These networks are float. See docs/PREREGISTRATION-binding-readout.md §20 for the full citation chain as the project maintains it.

The citable entry is the intersection these two lines leave open: the SOTA factorization method run on the deterministic quantized substrate, measured to cost nothing in capacity.

512 files · 481 not served here

Advantages

  • Supports local-first operation with no external service calls or telemetry. evidence: README.md
  • Provides a memory API that allows for explicit fact removal via a forget operation. evidence: README.md

Limitations

Security

Risk level: Medium risk

This brain runs

Install scripts (1)

  • benchmarks/results/sbg_positions_development/setup.sh: sh benchmarks/results/sbg_positions_development/setup.sh

MCP servers (3)

  • integrations/editors/claude-code/plugin/.mcp.json (writerslogic-warm): npx -y writerslogic-warm-mcp
  • integrations/editors/claude-desktop/claude_desktop_config.json (writerslogic-warm): npx -y writerslogic-warm-mcp
  • integrations/editors/gemini-cli/gemini-extension.json (writerslogic-warm): npx -y writerslogic-warm-mcp

Hooks (1)

  • integrations/editors/claude-code/plugin/hooks/hooks.json (SessionStart): node
  • Medium risk: runs-mcp-server-unpinned-runner (integrations/editors/claude-code/plugin/.mcp.json)
  • Medium risk: runs-mcp-server-unpinned-runner (integrations/editors/claude-desktop/claude_desktop_config.json)
  • Medium risk: runs-mcp-server-unpinned-runner (integrations/editors/gemini-cli/gemini-extension.json)
  • Low risk: scripts-present (benchmarks/results/sbg_positions_development/setup.sh)

Attribution and licence

Created by
Writerslogic
Declared authors
  • WritersLogic, Inc. (declared in package.json)
  • WritersLogic, Inc. (declared in pyproject.toml)
  • WritersLogic Contributors (declared in CITATION.cff)
Publisher
Writerslogic (Official Writerslogic project)
Source
writerslogic/warm · commit e176d55
Licence
Apache License 2.0 (files served here)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Writerslogic.

Install from source

481 of its files are not served here, so there is no ZIP. writerslogic/warm at e176d55