HASH: a knowledge graph platform that tries to build itself

What HASH is trying to be

HASH is an open source, multi-tenant platform for self-building knowledge graphs and simulation. The README describes it as a way to turn raw information into knowledge and process graphs, creating graph-backed world models that power process automation, optimization, decision making and AI.

The phrase the README leans on is self-building database: one that grows, structures and checks itself, integrating data in near realtime. Autonomous agents are deployed to grow, check and maintain it, collating and structuring information from the public internet and from connected private sources into a standardized semantic form.

That is a more ambitious claim than a graph database makes. A graph database stores what you put in it. This describes agents that go out, find things, propose structure, and have it checked, with non-technical users able to browse and manage both entities, which is the data, and types, which are the schemas.

The repository is a large monorepo. The root carries apps/, libs/, blocks/, infra/ and tests/, plus both a package.json with yarn workspaces and turbo and a Cargo.toml with a rust-toolchain.toml, so the stack is TypeScript on top of Rust.

Bitemporality is the actual differentiator

Among the features the README calls unique, one is concrete enough to evaluate: bitemporality. The README says HASH provides first-order support for recording and querying both when something happened and, separately, when it became known.

That distinction matters more than it sounds. Most systems store one timestamp and quietly conflate the two. If a contract was signed on Monday and entered into your database on Friday, a normal query asking what you knew on Wednesday returns nothing, while a query about what was true on Wednesday should return the contract. Audit, compliance, financial reconciliation and any after-the-fact analysis all hit this problem.

The README links bitemporality to process modelling, arguing it is central to modelling processes properly, which is consistent with the simulation side of the platform.

This is the feature to test first if you are evaluating HASH, because it is either a solved problem you have been working around, or a problem you do not have, and that answer will probably decide the adoption question.

Running it locally

The README gives two options, and recommends the hosted one: create an account on hash.ai, described as a quick start under five minutes, with a note that new accounts may be waitlisted and that there is a way to skip the queue once signed in.

Running it yourself is Option 2, and the prerequisites are specific: Git 2.17 or newer, Docker 20.10 or newer including Compose 2.17 and Buildx 0.10, and mise 2026.6.13 or newer, which installs and pins Node, Rust, protoc and the other required tool versions. The README asks for at least 8 GB of RAM given to Docker and roughly 15 GB of free disk for build artefacts, images and volumes.

Setup then goes clone, toolchain install, JavaScript dependencies:

git clone https://github.com/hashintel/hash.git && cd hash
mise trust && mise install
yarn install

A .env.local is needed at the root, and the README says real keys are only required for AI features, so dummy values such as OPENAI_API_KEY=dummy and ANTHROPIC_API_KEY=dummy work otherwise. The file is git-ignored and overrides .env and .env.development.

What comes up and how long it takes

Infrastructure is containerised and started with one command:

yarn compose up -d

The README says this runs the dev and observability profiles, bringing up Postgres, Redis, Kratos, Hydra, Temporal, Vault and MinIO, plus the Grafana stack on port 3001 and the Temporal UI on port 3100. The graph layer is deliberately not included and runs as part of the app.

Starting everything natively is then one command, and the README warns that the first cold build compiles the graph from Rust in 10 to 20 minutes:

yarn start

For hot reload the README splits it across two terminals, with yarn start:graph compiling and running the graph and yarn dev running the api and frontend. Dev mode seeds three users with the password password: alice@example.com and bob@example.com as regular users and admin@example.com as admin. Once the API logs localhost:5001, the app is at localhost:3000.

That is a heavy local setup. Seven backing services plus a Rust build is not something you spin up to try an idea, which is presumably why the README recommends the hosted option first.

Version numbers tell you where this is

The published packages are early. The three most recent releases, all published on 2026-08-26, are @hashintel/petrinaut@0.0.19, @hashintel/petrinaut-core@0.0.4 and @hashintel/ds-helpers@0.2.2. Those are 0.0.x numbers on the core pieces.

The content of those notes tells you what kind of work is happening. Petrinaut-core 0.0.4 fixes stochastic transition firing statistics in the simulation engine: it now fires with the memoryless per-frame probability 1 - e^(-rate * dt), advances the RNG state on every evaluation instead of discarding non-firing draws, and computes the seeded linear congruential generator with exact integer arithmetic. Firing counts now match Poisson expectations, and identical seeds produce different sequences than earlier releases.

That is a serious correction of a simulation engine, and the last clause is the one to note for reproducibility: if you have recorded results under a seed, they will not reproduce after upgrading.

The last push to the repository was on 2026-09-15, so development is active. The maturity signal is in the version numbers, not the commit frequency.

Where the friction is

Three things will cost you time.

The first is the local environment. Eight gigabytes of RAM to Docker, fifteen gigabytes of disk, seven containerised services and a ten to twenty minute Rust compile is a real barrier to trying it, and it means evaluation goes through the hosted product for most people.

The second is conceptual load. World models, a type system that users manage, bitemporal queries and an agent layer that maintains the graph are four ideas at once. The README points to documentation for each, and a team adopting this should expect to spend time on the type system before it pays off, since the value of the graph depends on the quality of the types agents are asked to populate.

The third is licence. The repository reports NOASSERTION, meaning the detector could not map it to a standard licence, though a LICENSE.md exists at the root. For a platform you would build a business process on, read that file before depending on it.

There is also a waitlist on the hosted product, which the README acknowledges and offers a way around.

Neo4j as the alternative

The comparison most people will reach for is Neo4j, and the two are aimed at different layers.

Neo4j is a mature graph database. You model your graph, you load it, you query it with Cypher, and it is good at traversal at scale with a large ecosystem of tooling and drivers. What it does not give you is a type system that non-technical users manage, agents that populate and check the graph, bitemporal semantics as a first-class feature, or a simulation engine.

HASH is the layer above that, plus the layer that fills it. It is a platform where the schema, the ingestion and the verification are part of the product rather than your application code.

Choose Neo4j if you already know your data model and you want a fast, well-understood store to query. Choose HASH if your problem is that the graph is supposed to be assembled and maintained continuously from messy sources by agents, and if bitemporality is something you genuinely need. Given the version numbers, choosing HASH today means accepting early-stage software.

Licence and contribution

As noted, the licence is reported as NOASSERTION with a LICENSE.md present, so the terms need to be read from that file rather than assumed. This is a description of what the repository reports, not legal advice.

The engineering setup is thorough. The root carries a changeset workflow, lefthook for git hooks, a justfile, clippy and rustfmt configuration for the Rust side, sqlfluff for SQL, markdownlint for docs, and yarn workspaces with turbo on the JavaScript side. There are AGENTS.md and CLAUDE.md files, plus .cursor/ and .claude/ directories, so AI-assisted development is configured deliberately.

The repository also carries a CITATION.cff, which is unusual and indicates the project expects academic citation.

Contact and contribution routes go through the documentation and the repository, and the README links a development roadmap, use cases and careers pages, so this is a company-backed open source project rather than a community side project.

Editorial conclusion

Look at HASH if your problem is a knowledge graph that has to be assembled and maintained continuously from messy sources by agents, with types that non-technical users can manage and bitemporal queries over what happened versus what was known. Those are the parts a conventional graph database does not give you. Do not adopt it yet if you need stable software, since the core packages sit at 0.0.19 and 0.0.4, or if you expect to evaluate it on a laptop, because local setup asks for 8 GB of RAM given to Docker, about 15 GB of disk and a 10 to 20 minute Rust build on first start. Read LICENSE.md first, since the repository licence is reported as NOASSERTION. Start on hash.ai rather than locally, and if you run the simulation engine, note that petrinaut-core 0.0.4 changed seed behaviour, so results recorded under an earlier release will not reproduce.

Frequently asked questions

Official sources

1. hashintel/hash on GitHub
2. Issues
3. Project website
4. README
5. Releases