@sentropic/engram weekly downloads statistics

engram

Engram is a new product: an agent memory substrate, rebuilt and repositioned from a knowledge-graph tool. It inherits concepts from the earlier graphify project (@sentropic/graphify) but is not a continuation of it — names, CLI, env vars, state dirs, schemas, and positioning have changed (see Migration below). Heritage: Engram descends from graphify; for the prior line, see the archived @sentropic/graphify README and its CHANGELOG. New work targets engram only.

Engram turns a corpus into a reconciled, ontology-typed knowledge graph. Most knowledge isn't documentary — it doesn't live as one fact in one file. It's entities and relations scattered across sources: the same person under three names in twenty-five books, a component named one way in a CSV registry and another way in a manual, a case that only makes sense once its evidence, motive, and method are linked. Prose and docs flatten that structure; a knowledge graph keeps it. Engram extracts canonical entities and typed relations, deduplicates and reconciles them across sources under a configurable ontology, and gives you back a queryable graph your assistant — or you, from the terminal — can reason over.

The flagship corpus: 1,193 canonical entities across 19 ontology types (Work, Saga, Case, Character, Evidence, Motive, ForensicMethod, DisguisePersona, Alias…) reconciled from 25 public-domain mystery works, clustered into 99 communities — here with the entity panel open on Sherlock Holmes. Explore the live studio → https://mystery-saga.sent-tech.ca/studio/

Why a knowledge graph, not more prose

Four things a graph gives you that documents can't:

• Queryable structure — ask engram query "what connects Irene Adler to the Bohemia case?" and get a path through typed nodes and edges, not a wall of search hits to re-read.
• Entity reconciliation — "Holmes", "Mr. Sherlock Holmes", and a disguised persona collapse into one canonical entity with aliases and evidence refs, instead of staying three scattered mentions.
• Cross-source linking — a character appearing in several works, an author and their translator, a registry row and the extracted mention that matches it: edges across sources are first-class, with provenance.
• Ontology-typed nodes — every node carries a type from a profile you control (Character, Case, Evidence, …), each type can pin a visual_encoding (shape + color), and relations are validated against allowed endpoints — so the graph stays a model, not a hairball.

From code graphs to ontology graphs

Engram started life as a code knowledge graph: parse a repo, extract classes/functions/calls, cluster, report. No ontology, no entity management. The current product line keeps that (see Code knowledge graphs) but generalizes it:

	Initial approach (code graph)	Now (ontology-driven entity graph)
Node types	Fixed (class, function, concept)	Configurable ontology profile per project
Same thing, many names	Stays duplicated	Canonical entities + reconciliation with a reviewable patch lifecycle
Sources	A codebase	Any corpus: books, manuals, registries (CSV/JSON/YAML), papers, images, transcripts
Rendering	One default style	Per-type visual_encoding (shape, color) carried by the profile
Review	Read the report	Reconciliation studio + audit trail of every accept/reject decision

Proof: the graph pays for itself

A token benchmark prints after every run. Once built, each query reads the compact graph instead of re-reading raw files:

Corpus	Files	Tokens per query vs raw	Worked example
Karpathy repos + 5 papers + 4 images	52	~71.5× fewer	worked/karpathy-repos/
Engram source + Transformer paper	4	~5.4× fewer	worked/mixed-corpus/
httpx (synthetic Python library)	6	~1×	worked/httpx/

A tiny corpus already fits in context, so there's little to compress — the value there is structural clarity, not token savings. Each worked/ folder ships the raw inputs and the actual output so you can reproduce the numbers. Token figures are estimates unless backed by real model calls.

Global governance contract

Sentropic, h2a, Engram and Design System share a federated governance contract. Each consequential act has one accountable owner under an explicit mandate; each repository retains its code, release and data authorities.

Engram owns the knowledge and ontology frame: canonical agent memory D3, filtered projection D10, live development knowledge, governed ontology profiles and central time references D1=C. It declares the required storage surface and consumes Sentropic’s neutral storage interface. Its accountable capabilities are C05 agent memory, C06 live development knowledge, C07 architecture and ontologies, and C14 operational learning and time references. Principal clauses: C-01, C-02, C-05, C-06, C-12, C-13, C-14 and C-16.…