Skip to content

Metistry-Dev/metistry

Metistry

Conformance

Keep the database you already run, or build an AI-native proof ledger. Every answer comes with proof.

The hard part of putting AI on your data was never the AI. It is trusting what comes back.

You have a database that works. Now you want AI that can reason over it and give you answers you can stand behind. That is not a lot to ask. So why does every path to it force a trade you should never have to make?

Your database, with AI bolted on top?

  • A table knows what a value is, never whether it is legitimate. Once AI is reading and writing, a justified change and a confident mistake look identical, and your audit trail is logging you have to take on faith.
  • The schema lists columns, not what may follow from what. The model joins things it was never meant to connect and hands you a fluent wrong answer.

Blockchain?

  • No real privacy. Everything sits on a shared ledger. If your job is proving someone agreed to a specific use of something they own while keeping who they are private, a public chain is the wrong tool entirely.
  • To know what is true now, you replay history from the start. Hand that history to a model and you blow past its context limit, where it quietly drops what it cannot hold and invents the rest. Traversal from origin becomes hallucination.

A vector database?

  • Your data is copied into a second store that drifts from the source of truth the moment it lands, and now you run two systems instead of one.
  • It pulls what looks similar, not what actually follows. The model gets a pile of related-sounding text and builds a confident answer out of pieces that were never meant to go together.

Three different tools. The same hole underneath. Each one trades away privacy, or your source of truth, or any way to prove the answer is sound. See the full side-by-side comparison →

Metistry does not ask for these trade-offs.

Point Metistry at a database you already trust, or start a fresh one on it. Either way your data stays the source of truth, and every answer carries a proof of why it is what it is, checkable later without anyone having to take your word for it. Current state stands on its own. You never replay history to know the present, and private details never leave your control to be proven valid.

It is not enough to know what a system decided. You have to be able to prove why. Metistry calls that Proof of Change.

Quickstart

Install the CLI:

npm install -g @metistry/cli

Or the SDK:

pip install metistry
npm install @metistry/sdk

Get a key at dev.metistry.org, then:

metistry login
metistry connect "postgres://user:pass@host:5432/dbname"
metistry models add --tier 1 <compact-model>
metistry models add --tier 3 <reasoning-model>
metistry ask "which member accounts changed status last quarter, and on what evidence"

That is the whole loop. Connect, bring models, ask. Results arrive with proof attached.

How it works, without the math

Connect your database. Paste a standard Postgres connection string or your Supabase credentials. Metistry reads your existing schema and builds a reasoning topology over it. Your tables stay exactly as they are. Nothing is copied out unless you ask it to be.

Bring your own models. You assign a model to each tier you enable, from a compact, fast model for routine work to a larger model for deeper reasoning. Metistry sends each step to the tier that fits it, so you are not paying frontier prices for a trivial lookup. The models are yours and swappable. Nothing locks you to one provider.

Ask in SQL-compatible queries. If your team knows SQL, they already know how to query Metistry. The same query language reaches both your data and the proofs attached to it. Reporting tools and existing skills carry over. There is no second query paradigm to learn.

Get proof with every answer. Each result carries a Nexus Seal, a tamper-evident proof that the answer was reached from real evidence at a real moment in time. You can verify it later without trusting us and without replaying a long history. The current state stands on its own, with its proof attached to it.

Privacy by default. Identifying details stay in your environment. Metistry can confirm that a result is valid without ever receiving the underlying private values. You choose what is exposed and what is not.

Under the hood

Metistry is distinct from a database or a blockchain, while keeping bridges to both. Those bridges let you migrate existing data in and keep it in sync, so adopting Metistry never means abandoning what you already run. From there, the runtime engine takes full advantage of what is native to it: a relational context layer, agents that act within earned authority, and a verifiable proof on every change.

Three layers work as one. The Ledger records what changed and the proof it was legitimate. Lattice holds the relationships and context that make a record mean something, with schema that emerges through use rather than being imposed up front. Concordance coordinates the two, so reasoning and proof move together instead of living in separate systems.

The pieces a developer works with:

  • PROVES. The structure every Ledger entry follows: six elements capturing what changed, how we know it changed, and the proof binding them. Each entry is self-contained, which is why current state reads with a plain query and no replay.
  • MQL. One SQL-compatible language across your data, the context, and the proofs. Existing database skills transfer.
  • Governed Envoys. The agents that do the reasoning, each acting within scoped authority. The tier sets what an Envoy may do, capability and autonomy are configured separately, and autonomy is earned through demonstrated reliability.
  • Proof of Change. The proof on every result, written PoΔ. It establishes that real-world evidence converged to support a claim, and records how. Its artifact is the Nexus Seal, which binds a state change to the evidence behind it. A hash shows content was not altered. The Nexus Seal shows the evidence actually converged.

Tiers

Tiers run from 0 to 5. The tier sets what an Envoy may do and how much oversight comes with it. You assign a model that fits the work at each tier you enable, and autonomy is a separate dial, earned rather than unlocked by a bigger model.

Tier What the Envoy does Model that fits
0 Deterministic Rule-based operations, validation, full trace. No AI. none
1 Assisted Builds and interprets queries. You initiate and confirm. a compact, fast model
2 Consensus Several Envoys vote on low-stakes calls, then execute on agreement or escalate. fast models
3 Supervised Deeper reasoning with a mandatory trace and a human checkpoint. Bring your own model. a balanced or larger model
4 Adaptive Proactive action within pre-authorized bounds, reviewed periodically. balanced to deep
5 Strategic System and policy changes within governance bounds. your most capable model

Connect any AI client over MCP

Metistry ships an MCP server. Any MCP-compatible client or assistant can query your Metistry-connected data and receive the same proof-backed results. Point your assistant at the server and it reasons over your real data with receipts, not guesses.

SDK and CLI

The SDK (Python and TypeScript) and the CLI cover the full loop: connect a database, register models by tier, run queries, verify proofs, and expose an MCP endpoint. See /examples for runnable starting points in both languages.

Getting an API key

  1. Go to dev.metistry.org and create an account.
  2. Create a project. A project maps to one connected database.
  3. Generate an API key from the project dashboard.
  4. Set it as METISTRY_API_KEY in your environment, or run metistry login and paste it once.

Keys are scoped per project. You can rotate or revoke them from the dashboard at any time.

What Metistry is built for

Make an existing database AI-native, without a rebuild. You have a production Postgres or Supabase database. You want trustworthy AI reasoning over it for support, analytics, or internal tools, and you cannot afford a migration or a refactor that puts live data at risk. Connect Metistry, keep your schema, and get proof-backed answers over the data you already have. This is the case Metistry was made for, and the fastest way to feel what it does.

StoryFlow: provenance across a creative pipeline. Content moves through many hands and many tools before it ships. StoryFlow records every contribution along the way, so you can prove who created what, when, and under what permission. As AI-generated material spreads, defensible authorship stops being optional. Each contribution seals as it happens, and the chain holds up across platforms and over time.

Exchange Reserve: a community fund you can prove. Exchange Reserve runs a shared reserve on the LIFT framework. Every balance change carries proof that it was legitimate and followed the trust's rules. Members and auditors verify the reserve directly rather than taking a statement on faith. Balances are held and queryable now, not reconstructed by replaying a transaction log.

Guidean, also known as Command Legacy: accountable decisions under pressure. Guidean supports public-safety teams making consequential calls. Routine logging is deterministic and automatically traced. Pattern analysis across incidents is AI-assisted. Protocol changes require human approval and seal with a complete accountability chain. Any system that makes high-stakes recommendations and has to show its work later fits this shape.

Open by design, stewarded for generations

The specification and the developer tooling in this repository are open, released under the Apache License 2.0. You can read the spec, build against it, run the conformance suite, and verify proofs independently. The engine that runs the reasoning is offered as a hosted service — request access at dev.metistry.org.

The open work is held in stewardship through the Legacy Impact Futures Trust, so the standard belongs to the institutions and communities that build on it, not to any single company or person. Open where openness builds trust. Stewarded so it outlasts any one of us.

Repository layout

/spec          The open Metistry specification
/sdk           Python and TypeScript client libraries
/cli           The metistry command-line tool
/mcp           The MCP server
/conformance   The conformance suite. Run it to verify any implementation
/examples      Runnable examples, including the use cases above
/docs          Guides, concepts, and the quickstart in long form

Verify it yourself

Trust should not require taking our word for it. The /conformance suite checks that any implementation produces valid proofs and consistent results, and the verifier in /sdk lets you confirm a Nexus Seal on your own machine. If a result claims to follow from your data, you can check that claim without calling us. Pass the suite and you may call your implementation Metistry-conformant, with no gatekeeper and no fee. Because the suite is public, anyone can re-run it to check the claim.

License and contributing

The specification and tooling here are released under the Apache License 2.0, with copyright held by the Legacy Impact Futures Trust. Contributions are welcome under the same license. Each commit carries a sign-off (a Developer Certificate of Origin) so the provenance of the project stays as clean as the records it produces. See CONTRIBUTING for details.

"Metistry" and "Nexus Seal" are trademarks of Exchange Reserve PBLLC. The license covers the specification and the tooling, not the marks. See the Trademark and Conformance Policy for how to refer to Metistry and how to use the Metistry-conformant designation.

About

AI-Native Proof Registry

Resources

License

Code of conduct

Contributing

Security policy

Stars

Watchers

Forks

Releases

No releases published

Packages

 
 
 

Contributors