One shared truth for
humans and AI agents.

Cruxible is a governed state engine — an ontology-backed alternative to general-purpose agent memory for claims that must be settled, enforced, and auditable. We call it hard state.

open source · Apache 2.0 · MCP built in

Declare. Govern. Ask.

This is what using it looks like: one governed edge, end to end. Declared in YAML, refused on direct write, minted in review, then traversed with a receipt.

config.yamlsupply-chain
entity_types:
Supplier:
properties: { supplier_id: …, name: … }
Incident:
properties: { incident_id: …, title: … }
relationships:
# hard fact: ingested, written directly
- name: supplier_supplies_component
from: Supplier
to: Component
# judgment call: proposal is the only door
- name: incident_impacts_supplier
from: Incident
to: Supplier
write_policy: proposal_only
named_queries:
components_exposed_by_incident:
mode: traversal
entry_point: Incident
returns: Component
traversal:
- relationship: incident_impacts_supplier
- relationship: supplier_supplies_component

The full walkthrough, in the README →

The full loop.

Those three beats sit in a longer arc — and there is no LLM inside the engine. Judgment enters only where you saw it (modeling, proposals, review); everything the engine itself does is deterministic, works with any agent or harness, and lands in a SQLite file you own.

01

Model the domain

Start from a ready-made domain kit, or hand your agent the authoring skills and review the YAML ontology it drafts.

02

Pin the sources

The exports, tables, and documents your truth comes from register as content-hashed artifacts that claims cite into.

03

Ingest the hard facts

Deterministic workflows match source rows into typed entities and edges, previewed before they commit.

04

Propose the judgment calls

Governed claim types refuse direct writes and enter as proposals, each carrying the evidence that matched it.

05

Review and mint

A human, or an agent under trust rules you declared, approves or rejects; everything ungoverned is live on write.

06

Ask, and act on the answer

Agents work through MCP or the CLI, under scoped credentials; queries return receipts, guards refuse rule-breaking writes, gates hold outside actions until state agrees.

Run this loop as real commands — quickstart →

An LLM can interpret a policy.
Cruxible enforces it.

However good the model gets, following a rule stays a matter of probability — and a probability is not a promise. Keeping the policy in memory doesn't change that; remembered text is still interpreted. A rule declared in Cruxible isn't followed, it runs: every write, every writer, no exceptions. That is what guards and gates are for: keeping the shared state a truth layer the rest of your stack can trust.

Guards face inward.

Guards protect the write boundary of accepted state: a claim enters or changes it only when the declared conditions hold — the actor is authorized, the transition is legal, the evidence dereferences, frozen fields stay frozen.

enforced at the single write chokepoint

Gates face outward.

An action outside Cruxible checks state before it proceeds: a deploy holds while critical exposures are open, a filing step waits for the citation check, a merge waits for its approved review. Cruxible's own repo gate refused our release push — we fixed the state, not the hook.

wired where the action lives: a CI job, a protocol, a git hook

Any domain you can type.

Kits are installable domains: the ontology, the governance, and the queries ship together. One command in, your agents work a governed model instead of a blank graph.

Incident blast radius over a governed BOM

Map suppliers, components, and recursive BOMs once. When an incident lands, blast radius is a traversal, not a research project. Feeds can only propose impacts, never write them.

kits/supply-chain-blast-radius
kits/supply-chain-blast-radiussession
$ cruxible init --kit supply-chain-blast-radius
# 9 entity types · 30 named queries · 13 workflows, armed
# which suppliers are hit by open incidents?
$ cruxible query run open_incident_impacts
9 result(s), 1 step(s) executed.
results:
- edge:
relationship_type: incident_impacts_supplier
from_id: INC-TW-RAIL-2026-07
to_id: SUP-FORMOSA-PRECISION
# … 8 more
Receipt: RCP-8827f1a6d40b
# accepted impacts only — pending proposals stay in review

Browse all seven kits →

One truth, many writers.

Cruxible is built for many writers out of the box. Each writer holds its own minted credential at one of four cumulative permission tiers; give each agent the least tier that does its job. And everything they write is watchable in the open-source inspection console: the state graph, review queues, workflow traces, receipts.

read_onlygoverned_writegraph_writeadmin

Minted identity

Every writer, human or agent, acts under its own credential; every write is attributed to the actor that made it.

Roles separable by receipt

A guard can require that the creator of a record is never its approver, anchored on the creation receipt rather than anything a writer can forge.

One accepted state

Humans and agents sit in the same loops under the same rules, and every reader, whatever the agent, model, or session, computes the same answer.

Model the domain.
Don't engineer the context.

We spent fifty years keeping the facts that matter in systems with schemas, constraints, and transactions, then handed agents piles of markdown. With Cruxible, the durable slice of what's true becomes typed, governed state: accepted at a point in time, changed only through explicit lifecycle, read back with a receipt.

Markdown · RAG · vector memory
Cruxible
A claim is prose; nothing refuses one without a source
Evidence-gated writes refuse references that don’t verify against content-hashed sources
Links live in prose, re-inferred on every read
Typed edges, traversed multi-hop, with visibility rules at every hop
No record of which answer was settled on
One accepted state; the same query returns the same answer for every agent
No record of when a source was captured
Sources are dated and hashed; staleness is queryable
A better model reads the pile better
It can’t read what was never written; the record and its derivations don’t move when you swap models

Start from what you already have.

Bootstrap by pointing your agent at your domain's own data — the skills below take it from raw exports to reviewed state. If the knowledge lives in a wiki, wiki-to-state turns an Obsidian vault or a team wiki into a typed, governed world. After that, nobody "maintains the model" — the patch your agent verifies, the supplier impact it accepts, the treatment it flags all land in the graph through the same chokepoint. State compounds as the exhaust of normal work.

Start local. Scale when ready.

Cruxible runs on your machine — the full engine, nothing held back. When your team outgrows a single daemon, Cruxible Cloud adds managed, isolated deployments you don't have to run.

Cruxible

Open source

Cruxible Cloud

Scale with your team

Typed state, workflows, receipts
Governed proposal & review flow
Agent identity & permission tiers
MCP + CLI + HTTP API
RunsYour machine, your dataManaged, isolated deployments
Team onboarding & access
Managed backups & upgrades
PriceFree, Apache 2.0Coming soon
View on GitHubJoin the waitlist

Give your agents something
worth trusting.

pip install cruxible and model your first domain today, or join the Cruxible Cloud waitlist for managed, isolated deployments.