{#- Copyright 2024-2026 WritersLogic Contributors SPDX-License-Identifier: Apache-2.0 The landing page. Every runtime, feature and number comes from config.extra.hms, which scripts/docs_site.py builds from docs/_data/site.yml and benchmarks/results/. -#} {% extends "main.html" %} {% set hms = config.extra.hms %} {% block site_nav %}{% endblock %} {% block container %}

{{ hms.license }} · {{ hms.crate_version and ('v' ~ hms.crate_version) or 'open source' }} · runs on your machine

{{ hms.tagline }}

{{ hms.lede }}

Get started What “holographic” means GitHub
    {% for rt in hms.runtimes %}
  • {{ rt.name }}{% if rt.status == 'preview' %} preview{% endif %}
    • {% endfor %}

What are you building?

Choose a path, run an example, then inspect the evidence it returns.

Memory for an editor

Connect an MCP host to a local store. Remember, recall and inspect memories across sessions.

Search inside an app

Choose Rust, Node or a Python HTTP client, with clear package and storage boundaries.

Evaluate your results

Check known answers, inspect source passages and compare retrieval on your own questions.

Already installing? Troubleshoot setup and retrieval.

Install, ingest, search

The code below is read from the quickstart examples that CI runs on every pull request.

{% set rts = hms.runtimes | selectattr("status", "equalto", "available") | list %}
{% for rt in rts %}{% endfor %}
{% for rt in rts %}{% endfor %}
{% for rt in rts %}
{{ rt.install_html }} {{ rt.code_html }}

{{ rt.note }}

{% endfor %}

Full quickstart with the SQLite comparison and encryption →

Measured, and traceable

Both results are read from committed files under benchmarks/results/ each time the site is built.

{{ hms.headline.title }} {{ '%.3f' | format(hms.headline.value) }} {{ hms.headline.metric_label }}, HMS hybrid search
{{ hms.headline.svg }}

{{ hms.headline.context }} {{ hms.headline.caveat }}

Source: {{ hms.headline.file }}{% if hms.headline.machine %} · {{ hms.headline.machine }}{% endif %} · benchmark page

{{ hms.chart.title }} Queries per second at fixed recall, one thread
{{ hms.chart.svg }}
    {% for line in hms.chart.summary %}
  • {{ line }}
    • {% endfor %}

Source: {{ hms.chart.file }} · {{ hms.chart.machine }} · load gate met by {{ hms.chart.gate_met }} of {{ hms.chart.gate_total }} configurations (limit {{ hms.chart.max_load }}), so throughput is indicative · benchmark page

One engine, two layers

Document search is a conventional hybrid retriever. The vector-symbolic layer is the associative memory. Both sit on one crash-safe store. Module map →

{% include "partials/architecture.html" %}

Why holographic

A hologram stores the whole picture in every fragment. A hypervector memory does the same: many facts are superposed into one long vector, no single bit holds any one fact, and damage is spread thinly over all of them.

  1. Bind a key to a value with XOR. The result looks like neither, and binding again with the key gives the value back.
  2. Bundle many bound pairs by majority vote into one vector that stays a little similar to each of them.
  3. Resonate: unbind with a key and compare against known values. The right one stands out from the noise, even after you corrupt the memory.

The demo uses dense binary vectors so the algebra is easy to see. The engine uses sparse binary vectors, and its document search does not rank with hypervectors; the concepts page says exactly which parts do.

{% include "partials/demo.html" %}

{{ hms.comparison.title }}

{# Comparison slot: docs/_data/comparison.json, written by the benchmark generator, replaces the derived table. #}
{% for col in hms.comparison.columns %}{% endfor %} {% for row in hms.comparison.rows %} {% for v in row['values'] %}{% endfor %} {% endfor %}
System{{ col }}
{{ row.system }}{{ v }}

{{ hms.comparison.note }} {% if hms.comparison.source %}Source: {{ hms.comparison.source }}.{% endif %}

What is in the box

{% for f in hms.features %}

{{ f.title }}

{{ f.body }}

 {% endfor %}
{{ page.content }}
{% endblock %}