OpenHeart compresses a program graph and projects it into 19 diagrams

A 7-tuple graph replaces pointer heavy AST nodes

The argument OpenHeart makes about other static analysis tools is about memory and latency rather than coverage. Code Property Graphs and lowered compiler IR are described as pointer heavy, and the claim is that chasing pointers through them isolates analysis from a live developer workflow. The replacement is a Succinct Compositional Program Graph written as a formal 7-tuple, where the graph is composed from Succinct Balanced Parentheses trees, Compressed Sparse Row control flow graphs, Static Single Assignment data flow representations and Reduced Ordered Binary Decision Diagram path summaries. The stated results are up to 128 times memory compression and constant time bidirectional traceability between source positions and diagram elements. Those numbers are the project's own claims rather than independently verified results, and the practical reason to care is architectural. Balanced parentheses bitstrings with rank and select indexes replace tree nodes, and the whole representation is meant to be memory mapped rather than heap allocated.

Ten phases turn tokens into the graph

The pipeline is laid out as ten named phases, each with a file extension for the artifact it writes, and the first five are spelled out in full. Phase 1 is lexical ingestion and a token corpus written to a .tca file. Phase 2 reduces to a balanced parentheses AST in a .bpa file. Phase 3 builds the symbol table and hierarchy into a .sta file. Phase 4 produces the CSR control flow graph and the dominator tree as a .cfa file. Phase 5 handles SSA conversion, the control dependence graph and an IFDS solver, writing a .ssa file. The second row of five covers inter-procedural work, the traceability index, ROBDD path summaries, the UML semantic mapping and the final assembly of the SCPG. Every one of the ten is marked as completed in the diagram, and the artifact extension per phase is the useful part, because it means intermediate state is inspectable on disk rather than trapped in memory.

Nineteen projections come out of one graph

One graph feeds nineteen views, split into three families. Seven are structural UML: class, package, component, composite structure, object, deployment and profile. Seven are behavioural: sequence, state machine, activity, use case, communication, interaction overview and timing. Five are compiler pipeline views rather than UML at all, namely the control flow graph, data flow graph, control dependence graph, call graph and the ROBDD saturation view with exact path counting. Each projection names the engine that produces it, and most of them use the same hierarchical engine, with dedicated engines for the class tree, sequence traces, use cases and timing waveforms. The call graph view is where the ambition shows, since it claims class hierarchy analysis for virtual method dispatch plus recursion strongly connected components. A reader should note the asymmetry: producing a class diagram and producing a call graph are very different amounts of work, and the list gives no indication of which projections are complete.

token_id anchors tie a diagram element back to a line

The traceability mechanism is a monotonic 32-bit token_id that links raw source positions to IR graph nodes and to derived UML elements. This is the feature that decides whether static analysis is usable inside an editor, because a diagram you cannot tie back to code is a picture rather than an analysis. The traceability index is its own phase in the pipeline, which suggests the mapping is maintained as data rather than reconstructed on demand. The other structural guarantee is the manifest. A centralized manifest.json controls categories, diagrams, sixteen relationship terminologies and twenty four classifier node schemas with, in the project's phrase, zero hardcoding. That is a good design for a tool whose output shape needs to change, since adding a node type becomes a data change, but it also means the manifest is a second source of truth that has to stay in sync with the Rust code that consumes it.

The Rust crate is a working skeleton

The crate is small, and the Cargo.toml makes that plain. It declares version 0.1.0 on the 2021 edition, and its dependencies are tree-sitter with the Java and JavaScript grammars, sha2, memmap2, thiserror, serde and serde_json, with tempfile for development. The crate description is narrower than the README: a high performance lexical ingestion and token corpus pipeline for cardiac and code processing. The build profile is tuned in a visible way, with opt-level = 2 and overflow-checks = false under profile.dev, which tells you the development build is already optimised for speed, at the cost of turning off the overflow checks that catch arithmetic mistakes during development. The other top level files describe how the project is driven rather than what it contains: a Makefile with named targets, run.sh and run.bat launchers, a Dockerfile, a ruthless_config.json with a companion ruthless_verify.py script, sample_codebase/, and three example trees under examples/ including big_project_src and huge_enterprise_src.

Building and running the studio

The Makefile is the entry point for everything, and the targets are ordinary cargo wrappers. The default target runs check and then test, and the individual targets cover a debug build, a release build, compilation checking, testing, formatting and documentation:

## Check compilation
check:
	cargo check --all-targets

## Run unit and integration tests
test:
	cargo test --all-targets -- --nocapture

Running the studio is a script rather than a cargo command, with the run target launching run.sh and the server and serve targets calling a restart script on port 8080. The container image does the same thing with more detail. It builds the binary in a rust:1.80-slim stage, then moves to a debian:bookworm-slim runtime that installs git and ca-certificates for dynamic repository cloning, copies the compiled binary into /usr/local/bin, copies the web/ assets, and sets the environment defaults for the port and host before starting the server:

# Set environment defaults
ENV PORT=8080
ENV HOST=0.0.0.0

EXPOSE 8080

# Run OpenHeart server
CMD ["openheart", "serve", "--port", "8080"]

The web studio is also published on GitHub Pages, and the README describes it as ingesting a GitHub repository entirely in the browser, with client side cloning and AST parsing and no backend.

Environment knobs and the gap between the claims and the crate

Runtime configuration lives in a .env.example with a handful of switches, and they are the knobs to know before running the pipeline. Logging is set through RUST_LOG at info, generated .tca artifacts go to ./target/artifacts, memory is capped at 2048 megabytes, worker threads are auto detected when the count is zero, and invariant assertions are enabled with OPENHEART_STRICT_INVARIANTS. Turning those assertions off is the fastest way to see a phase that is skipping its checks. The gap between the advertised capability and the published crate is the honest caveat: the crate ships tree-sitter grammars for Java and JavaScript only, while the multi-language validation claim names Java, Kotlin, Python, Rust, TypeScript and C++, and the version is 0.1.0. The repository publishes no GitHub releases, though the last push was on 2026-10-17, so the project is moving faster than its release cadence.

Editorial conclusion

OpenHeart fits a reader who wants to see what a real program-analysis pipeline looks like, since the phase names, artifact extensions and diagram projections are unusually well laid out for a documentation-driven project, and the web studio on GitHub Pages lets you try the ingest path without installing anything. It does not fit a team that needs a library dependency today, because the published crate version is 0.1.0 and Cargo.toml pulls in only the Java and JavaScript tree-sitter grammars while the multi-language validation claim covers six languages. Before adopting it, run make check and make test to see which of the ten phases actually execute, confirm the tree-sitter grammar set covers the languages you need, and read the ruthless_verify.py script in the repository root, since the numerical claims in the README are produced by that harness rather than by the test suite.

Frequently asked questions

Official sources

1. AhmadHassan-BTed/OpenHeart on GitHub
2. Issues
3. License: MIT
4. Project website
5. README