Show HN: Cruxible – Terraform-like ontology config to governed state for agents(github.com)
github.com
Show HN: Cruxible – Terraform-like ontology config to governed state for agents
https://github.com/cruxible-ai/cruxible
3 comments
Hi HN I'm Rob, the author. I've been running Cruxible's own development off a Cruxible instance, which has really shaped how the interface evolved. I recently added a pre-push hook to make sure every agent reviewing the PR is a different model than the one that wrote it and always gets the exact context it needs from state.
Receipts have also been a life changer for my agents, being able to query state history makes it so the state timeline is instantly traversable, and LLMs are really good at using them now.
Happy to answer any questions :)
Receipts have also been a life changer for my agents, being able to query state history makes it so the state timeline is instantly traversable, and LLMs are really good at using them now.
Happy to answer any questions :)
1) Generic memory does not establish settled state, it returns context. Text-based memory can preserve and present information, but a claim added to context is reinterpreted by a probabilistic LLM every time it runs. I found myself constantly asking my agents to re-check the validity of what was in my markdown wikis, especially for knowledge that has a natural lifecycle. Additionally, there's no uniform way of establishing provenance or attribution for a claim in text - relying on git commit messages doesn't feel like a good standard.
2) An LLM can't do deterministic queries for relational information on its own, especially when relationships have to be constructed across a corpus. This really matters across sessions and for multi-agent workflows - even if one agent or session gets it right, if your organization's truth is not plainly and deterministically traversable, it creates a tower of Babel situation where each agent or session is operating from its own internal representation.
3) An LLM can't be trusted to enforce its own write-time boundary. A policy represented as text can only be interpreted by the model as context - better models have a better probability of following them, but an LLM by itself, no matter how good, can never guarantee that an invalid transition is refused, or that an author of a claim can't approve it when you want an independent review. For truth that matters, there has to be stricter write-time enforcement.
I built Cruxible to be that missing layer in agentic workflows. It's a governed state engine that agents and humans operate using a CLI or MCP server, bound by an ontology that is configured in YAML. Every write or mutation is attributed and receipted with full provenance, and governed claims can require evidence-backed proposal and review flows that cannot be skipped. Write policies and guards are enforced by a deterministic chokepoint outside the model.
- All state that can be built deterministically is built deterministically from your seeded data, which can be structured (CSVs) or unstructured (documents). When judgment is needed, Cruxible includes strict governance review queues with full attribution receipts for all changes or proposals. Only proposals that are approved get minted into state.
- Every query is deterministic and executes outside the LLM. Agents can traverse the graph directly or use configured named queries for recurring reads. Queries return receipts in structured JSON that detail the paths used to produce their answers.
- Enforcement runs in both directions: guards refuse invalid writes to state at the chokepoint, and gates hold outside actions (e.g. a merge or a deploy through CI) until state agrees.
- The state model is executable: you can read the state programmatically and do whatever logic you want with it. Downstream reads of settled state never have to re-parse source artifacts, although provenance ensures full auditability.
- Reads are reproducible: workflow plans, provider code, artifacts, and configuration are lock-pinned, and snapshots preserve exact state. Receipts always explain a write fully, so no more going through the git history of an md file.
- The YAML ontology can evolve like code to ensure that state is always representative.
Repo is here: https://github.com/cruxible-ai/cruxible or install with pip install cruxible
It's Apache-2.0, SQLite under the hood, and 100% local through a Python daemon. Full walkthroughs and guides for domains on the GitHub repo.
I'd really value feedback of any kind, even if it's just how you and/or your team are maintaining consistency about what's true for your agents to use. Contributions welcome!