System · Build & Ship
Your agent is about torefund the same order twice.This says no first.
An LLM produces the next likely token, not the next permitted action. It will happily propose a second refund on a settled order, a payout aimed at your own support rep, or an order status of “probably shipped” — all of it fluent, well-formed, and wrong. This System checks every proposed action against rules you wrote, before any of them execute.
Deterministic and offline. No API key, no network calls, no data leaves your machine.
Grades proposed actions against your rules — never people.
Instant download. Python engine, workbook, two playbooks, worked sample.
01
What it checks
Four rule constructs, each a standard way of saying something that must always or never be true.
functional
At most one object per subject for this predicate. One refund per order. Borrowed from owl:FunctionalProperty.
disjoint
Two classes no single party may hold at once. Nobody is both Customer and SupportRep. Borrowed from owl:disjointWith.
range
The object of a predicate must be of a declared class. A payout may only be directed to a Buyer. Borrowed from rdfs:range.
one_of
The object must come from a closed list. Order status is paid, shipped, or refunded and nothing else. Borrowed from owl:oneOf.
You supply two files: the actions your agent proposes, and the facts your systems already assert. The second file is the one that earns its keep. Most contradictions are invisible in a single row — an action can look perfectly clean on its own and still contradict what is already on record.
02
Try the check
Turn the ledger off and two contradictions vanish, because the rows alone were never the problem.
Batch verdict
CONTRADICTIONS FOUND
3 admissible · 1 review · 4 inadmissible, of 8. Admissible share 38% — context only, it decides nothing. Fix first: A-1002.
A-1001 · refund
ADMISSIBLE
order-5120 —refundsOrder→ usd-84.00 · actor party-41
A-1002 · refund
INADMISSIBLE
order-4471 —refundsOrder→ usd-120.00 · actor party-41
[BLOCKING] R1 functional order-4471 already has 1 'refundsOrder' assertion(s); this predicate permits at most oneRule pack marked this review; promoted to blocking — a contradiction cannot be a warning.
A-1003 · payout
INADMISSIBLE
order-5120 —paysTo→ party-88 · actor party-41
[BLOCKING] R3 range 'paysTo' has range Buyer but the object party-88 is of class SupportRep
A-1004 · payout
ADMISSIBLE
order-5121 —paysTo→ party-41 · actor party-41
A-1005 · status_write
REVIEW
order-5120 —hasStatus→ probably shipped · actor party-12
[REVIEW] R4 one_of 'probably shipped' is not in the closed set {paid, shipped, refunded}
A-1006 · grant
INADMISSIBLE
order-5122 —grantsAccessTo→ party-88 · actor party-88
[BLOCKING] R2 disjoint party-88 is asserted as both Customer and SupportRep; these classes are disjoint
A-1007 · status_write
ADMISSIBLE
order-5121 —hasStatus→ shipped · actor party-12
A-1008 · refund
INADMISSIBLE
order-5120 —refundsOrder→ usd-30.00 · actor party-41
[BLOCKING] R1 functional order-5120 already has 1 'refundsOrder' assertion(s); this predicate permits at most oneRule pack marked this review; promoted to blocking — a contradiction cannot be a warning.
Same arithmetic as the shipped engine and workbook. It grades proposed actions against rules you wrote, never people, and executes nothing.
03
What the engine prints
This is the shipped engine’s complete output on the shipped sample, run exactly as you would run it.
AGENT ACTION ADMISSIBILITY ENGINE
==========================================================================
A-1001 refund ADMISSIBLE
order-5120 --refundsOrder--> usd-84.00 actor party-41
no rule violated
A-1002 refund INADMISSIBLE
order-4471 --refundsOrder--> usd-120.00 actor party-41
[BLOCKING] R1 functional: order-4471 already has 1 'refundsOrder' assertion(s); this predicate permits at most one
rule pack marked this 'review'; promoted to blocking (a contradiction cannot be a warning)
A-1003 payout INADMISSIBLE
order-5120 --paysTo--> party-88 actor party-41
[BLOCKING] R3 range: 'paysTo' has range Buyer but the object party-88 is of class SupportRep
A-1004 payout ADMISSIBLE
order-5121 --paysTo--> party-41 actor party-41
no rule violated
A-1005 status_write REVIEW
order-5120 --hasStatus--> probably shipped actor party-12
[REVIEW] R4 one_of: 'probably shipped' is not in the closed set {paid, shipped, refunded}
A-1006 grant INADMISSIBLE
order-5122 --grantsAccessTo--> party-88 actor party-88
[BLOCKING] R2 disjoint: party-88 is asserted as both Customer and SupportRep; these classes are disjoint
A-1007 status_write ADMISSIBLE
order-5121 --hasStatus--> shipped actor party-12
no rule violated
A-1008 refund INADMISSIBLE
order-5120 --refundsOrder--> usd-30.00 actor party-41
[BLOCKING] R1 functional: order-5120 already has 1 'refundsOrder' assertion(s); this predicate permits at most one
rule pack marked this 'review'; promoted to blocking (a contradiction cannot be a warning)
--------------------------------------------------------------------------
BATCH VERDICT: CONTRADICTIONS FOUND
3 admissible / 1 review / 4 inadmissible (of 8)
admissible share 38% -- context only, it decides nothing
fix first: A-1002
Grades proposed actions against rules you wrote. Not legal advice.Note A-1002 and A-1008. The rule pack that ships marks the functional rule as “review”, and the engine promotes it back to blocking anyway, then says so. That is the one setting in this product you cannot configure away: functional and disjoint assert that something can never be true, so a rule pack is not allowed to soften them into a warning. Every other severity is yours.
04
What is inside
Six files, all of them yours to edit, none of them requiring an account.
Rule-pack engine
Zero-dependency Python. Runs offline, reads your CSVs, prints per-action verdicts and a batch rollup. No network calls anywhere.
Editable rule pack
A small JSON file holding your four constructs. Change a predicate, a class pair, a required range, or a closed list without touching code.
Workbook that reproduces it
Five tabs — Start Here, Rule Pack, Known Facts, Action Check, Dashboard — with 119 live formulas and no macros. Opens in Excel, Google Sheets, or Numbers.
Rule-Writing Playbook
How to turn the nouns and verbs your business already uses into the four constructs, and which rules are worth writing first.
Contradiction Runbook
What to do with each verdict: which contradictions mean fix the data, which mean fix the rule, and which mean the agent should never have been given the tool.
Worked 8-action sample
Every construct fires at least once, with two release twins that show exactly what clears a verdict.
05
Who it is for, and what it will not do
It is for the person who owns the agent’s write path and has to answer for what it did.
Built for
- Teams wiring an agent to a tool that writes: refunds, payouts, status changes, entitlements.
- Operators who already had one bad automated write and want a check that is not a prompt.
- Anyone whose approval queue has grown until nobody reads it, and who needs the queue to be short and correct instead.
It will not
- Connect to your agent, your database, or any API. It reads two files and prints verdicts.
- Execute, block, reverse, or retry anything. Wiring a verdict into your approval path is your build.
- Invent rules for you. It checks the rules you wrote and nothing else, which is why it can never be confidently wrong about your domain.
- Guarantee that a clean batch is safe. It proves no rule in your pack was broken, not that your pack is complete.
This System grades proposed actions against rules you write. It is a working aid, not legal, compliance, or security advice, and it is not a certification. It never scores, ranks, or assesses people, and it must not be used for hiring, tenant, credit, or performance decisions. You remain responsible for what your agent is permitted to do.
06
What sits either side of it
Three neighbours that answer a different question about the same agent.
AI Agent Go-Live Readiness Gate
$79
Grades whether the agent should be live at all. This grades what it is about to do once it is.
Document Field Validator
$79
Validates extracted records against a rule pack. Same discipline, one layer earlier, on documents rather than actions.
Agent Reliability Harness
$149
Evaluates finished trajectories in CI. This checks proposed actions before they execute.
07
Questions people actually ask
Short answers first, with the caveat after it rather than in front of it.
It checks proposed agent actions against four rule constructs before any of them execute: functional (at most one object per subject, so one refund per order), disjoint (two classes no party may hold at once, so nobody is both Customer and SupportRep), range (the object of a predicate must be of a declared class, so a payout only goes to a Buyer), and one_of (the object must come from a closed list, so order status is paid, shipped or refunded and nothing else). Each action returns ADMISSIBLE, REVIEW or INADMISSIBLE.
Because a contradiction cannot be scored. An action that violates a rule saying 'at most one' is not 90% admissible - it is simply not permitted. The verdicts are categorical for that reason. The workbook does show an admissible share on the Dashboard, but it is labelled context only, it decides nothing, and the shipped sample proves it: the same batch reads CONTRADICTIONS FOUND at 38% admissible and would still read it at 99%.
For two of the four constructs, yes. For functional and disjoint, no - and this is the one thing in the product you cannot configure away. Those two constructs assert that something can never be true, not that it is unusual, so if your rule pack marks either as review the engine promotes it back to blocking and prints the promotion on the affected row. The shipped sample ships with the functional rule set to review precisely to demonstrate this: action A-1002 still reads INADMISSIBLE.
No. It is deterministic and offline. You paste the actions your agent proposes and the facts your systems already assert, and it returns verdicts. It executes nothing, reverses nothing, connects to nothing, and has no network access at all. Wiring the verdict into your own approval path is your build; this product is the check, not the enforcement point.
Because most contradictions are invisible in a single row. The shipped sample makes this concrete: action A-1006 asserts on its own row only that the actor is a Customer, which breaks nothing. The ledger separately records that the same party is a SupportRep. Only the union of the two reveals that a disjointness rule has been violated. Run the same action against an empty ledger and it reads ADMISSIBLE.
No. It grades proposed actions against rules you wrote. Parties appear in the data as subjects and objects of assertions, never as things being rated, ranked or assessed, and there is no score attached to any person anywhere in the engine or the workbook. It is not for hiring, tenant, credit or performance decisions, and it is not legal advice.
A second refund is not a low score. It is a contradiction.
Write the rules once. Check every proposed action against them before any of them run. Deterministic, offline, and honest about what it does not know.
This System grades proposed actions against rules you write. It is a working aid, not legal, compliance, or security advice, and it never scores or ranks people.
Sold by RedHub AI LLC · Secured by Stripe · redhub.ai