When AI adds to your taxonomy, product catalog or permissions model, Evoduce checks every change against your rules and proves it fits before it ships. If it doesn't, you get the exact rule it breaks and why, so the AI can fix it. Every answer is a proof, not another model's opinion.
Evoducepip install evoducenpm install evoduceExact reasons returned so the AI can fix it.
Language models are good at proposing structure and bad at keeping it consistent. Evoduce sits between them and your data and checks every write before it's accepted.
Bring Jev, an open decision model or your own LLM. Evoduce calls a configured model when rules can't settle a decision.
A simple HTTP API. Each request carries your rules with it, so there's nothing to set up or sync on our side.
Your categories, rules and existing terms, written down once as plain JSON. That's the contract every change is checked against.
Must-have rules are checked by formal proof, so a pass is a guarantee. Nice-to-have rules carry weights, and an optimizer picks the best set of changes that still fits.
Four tools on one engine. Use one on its own, or chain them so your AI suggests, gets checked, fixes what failed, and only then commits.
Is this change safe? A yes or no against your must-have rules, with the exact conflict when it's no.
/v1/verifyMust-have rules still decide; nice-to-haves add a score and list what the change misses.
/v1/verify/gradedWhen suggestions compete, keep the most valuable set that still fits every rule.
/v1/optimizeAdd an approved change and get the updated model back. Re-check the whole thing at any time.
/v1/accept · /prove · /auditAI will keep getting better at suggesting changes. What it can't do is vouch for them. These are the properties a check needs, whichever model wrote the change.
A pass means every rule holds, every time. The answer is a formal proof, not a model grading its own work.
Every rejection names the rule it breaks and shows the conflict, which is exactly what your AI needs to fix it.
Must-haves block a change; nice-to-haves only score it. When suggestions compete, the best set that fits wins.
Claude, an open-source model or your own fine-tune. Evoduce checks the change, not who wrote it.
Your categories, rules and existing terms as JSON, or build them in the visual editor. Store it wherever you like.
A pass means it's safe to accept. A rejection tells you which rule it breaks and why.
Hand the reason back to your AI to fix, then accept the passing version and get the updated model back.
curl https://$EVODUCE_HOST/v1/verify \ -H "Authorization: Bearer $EVODUCE_KEY" \ -H "Content-Type: application/json" \ -d '{ "vocabulary": '"$(cat vocab.json)"', "proposal": { "name": "sliding_on", "duration": "temporary", "type": "contact", "symmetric": true } }'
# pip install evoduce from evoduce import Client nse = Client() # reads EVODUCE_API_KEY r = nse.verify(vocab, "sliding_on", duration="temporary", type="contact") if r.sat: vocab = nse.accept(vocab, "sliding_on", ...).vocabulary else: retry_with(r.violated_rules, r.counterexample)
// npm install evoduce import { Client } from "evoduce"; const nse = new Client({ apiKey: process.env.EVODUCE_API_KEY }); const r = await nse.verify(vocab, { name: "sliding_on", duration: "temporary", type: "contact", }); if (!r.sat) console.log(r.violated_rules, r.counterexample);
Use your verified terms as typed Choice options. Evoduce checks your rules first, asks a decision model only when needed, and learns repeatable decisions from confident answers.
Name the allowed terms and the structural rules they must follow. New terms enter only after verification.
NS VocabularyPredicate names become Choice options. Jev or a configured open model can answer the same question shape.
state + questions → choiceConfident answers teach decision rules. When facts force one answer, the solver returns it without another model call.
facts → rules → answerEach template is a real vocabulary from the evaluator's examples. Open one in the playground, break it, then fix it.
Scopes as access level × resource × boundary. Catches a scope the model proposes twice or leaves unclassified.
Relations with direction, temporality and domain. Asymmetric relations must declare their inverse.
Valence × arousal × intensity. Every new emotion has to land on all three axes.
Contact, proximity and containment over time. Shows symmetric relations and inverse pairs.
A soft "prefer reviewed" rule that scores items without blocking them. Try the Graded button.
The requests from Jev's docs, verbatim, answered here. Choose what answers them: a model, your rules, or both.
Open the examples →Design categories, rules and terms in the visual editor. It checks everything as you type and exports the JSON.
Open the editor →This is the live API, no key required, rate-limited per IP. Edit the vocabulary or the proposal, then choose an operation.
// choose an operation
Your first verified extension takes about a minute.
Get a free API key →