Skip to main content

Your documents,
as a database.

Declare entities and edges over a document corpus, run extraction to populate them, then query the graph with SQL-like syntax. Every read is permission-bounded at execution and written to a hash-chained audit log.

studio / library
-- Join across a declared edge, filtered by role.
SELECT p.title, a.full_name, p._confidence
FROM library.Paper p
JOIN library.Author a VIA p.written_by
WHERE a.role = 'lead'
LIMIT 3;
3 rows96 ms
Sediment transport under tidal forcingR. Okonkwo
A revised estuary salinity modelM. Lindqvist
Seasonal turbidity in shallow baysR. Okonkwo

A PDF is not something you can reason about.
A clause inside it is.

1

Declare

Entities are the objects that matter. Edges are how they relate. Both are DDL.

CREATE ENTITY research.Paper (
  doi   TEXT KEY,
  title TEXT
) ROOT SINGULAR PER DOC;
2

Extract

Bind a corpus to the ontology and run it. Documents are read in place, with lineage kept.

BIND CORPUS library
  TO ONTOLOGY research;

RUN BINDING library.research;
3

Query

Traverse the edges you declared. Aggregate, search, join to external APIs.

SELECT a.full_name, COUNT(*) AS n
FROM library.Paper p
JOIN library.Author a
  VIA p.written_by
GROUP BY a.full_name;
Runtime

Self-hosted

A single Go binary against Postgres, pgvector and OpenSearch. Documents are read in place from the source system, never copied into a new store.

Schema

You define it

No fixed shape to bend to. CREATE ENTITY and CREATE EDGE declare what matters; extraction fills it, with lineage back to the source on every row.

Access

Fail-closed reads

Corpus grant, corpus membership and per-document ACL are AND-composed into the scan. An entity scan cannot be built without a document filter.

One endpoint. Every statement.

DDL, DCL, DML, SHOW, DESCRIBE, EXPLAIN and RUN BINDING all go through POST /api/v1/query.