LOGUS: a business rules engine that proves, not guesses

A sales rep asks the company’s AI assistant: “The client has paid, but the acceptance certificate isn’t signed yet. Can we ship?” The assistant answers politely and with confidence: “Yes, shipping is allowed when the order is fully prepaid.” It sounds reasonable. The trouble is that your rule is different: no shipping without a signed certificate, no exceptions. The assistant didn’t lie on purpose. It did what language models always do and guessed a plausible answer.

Guessing is fine when you’re chatting about the weather. It isn’t fine for business rules. Shipping, discounts, safety clearances, contract approvals are all places where a mistake costs money, penalties, and customer trust. That’s why PRANUS includes LOGUS, a business rules engine that doesn’t guess at logic. It computes it, and it tells you honestly how certain it is.

Logic should be computed, not guessed

The principle behind LOGUS is simple: a language model never “walks through the rules in its head.” When the question is whether you can ship, it goes to LOGUS, which runs it against your company’s written rules. The answer doesn’t come back as “I think so.” It comes back as a result, with the path it took and a confidence level.

AI is still useful here, in its proper place. It helps turn an everyday sentence into a rule, build a model from a plain-language description, and explain the result in human terms. But the result itself comes from computation that gives the same answer every time for the same inputs.

How LOGUS checks business rules

A model from a description

You don’t need to draw flowcharts. Describe the task and provide the data: “Shipping is allowed if the certificate is signed and the client has no overdue balance above the limit. Key accounts have a higher limit.” LOGUS builds the process model itself, writes test scenarios from your description, runs them, fixes whatever fails, and gives you a link to the finished model.

If you later need to change one condition, the AI assistant edits just that part instead of rebuilding everything. What’s been verified stays verified.

A process you can run

A LOGUS model isn’t a diagram. It’s a working process with an input form and clearly labeled fields. You enter the details of a specific situation, and the model steps through to an outcome, “allowed” or “not allowed,” with the reason. The path it took is highlighted, so you can see exactly which condition decided the result.

Threshold testing

Rule errors tend to hide at the edges. “Discount on orders of 100 units or more.” So is there a discount at exactly 100? At 99.5? LOGUS automatically tests values around every threshold: just below, exactly at, just above. If a rule behaves differently from what your description says, you find out before a customer does.

Proof or counterexample

The most powerful thing LOGUS does is answer questions about every possible case at once, not just one. “Is it true that shipping without a signed certificate is impossible for any input?” There are two possible answers:

proven: the rule holds for every possible value;
counterexample: here is a specific situation where the rule breaks.

A counterexample isn’t a failure. It’s a find. Far better to discover a gap in your rules during a check than through a customer complaint.

“Why not?”

Once you have many rules, they start to collide. An employee tries to place an order and the system says no. Why? LOGUS names the smallest set of rules that conflict: “the minimum batch rule and the stock level rule can’t both be satisfied for this item.” Not “configuration error,” but specific rules your team can actually discuss.

Honest confidence levels

Many systems sound equally confident whether or not they checked their answer. LOGUS attaches a confidence level to every result, and it never inflates it.

Level	What it really means
Proven	The rule was checked for every possible value, by a solver or by exhaustive enumeration
Computed twice	The result was computed in two passes over the model. Sturdier than one run, but not an independent check
Computed	Calculated for the specific inputs you provided
Estimated	No full check was done, for example because there are too many inputs. Treat this answer as unverified
Mismatch	Different checking methods disagreed, which means there’s an error in the model or the data

“Proven” appears only after a complete check. We deliberately don’t label something proven when the check was partial. Confidence without grounds is exactly what LOGUS exists to prevent. The same honesty sits behind AI that answers only from documents, which we cover in AI that says “I don’t know”.

Where a company needs provable logic

LOGUS isn’t needed everywhere there are arrows on a diagram. It earns its keep where three things are true at once:

people create the connections by hand, not a program following a rule;
an error has silent consequences: not an error message, but emptiness, a freeze, or waiting forever;
the answer has to make sense to a human: not “invalid graph,” but “machine repair is waiting on purchasing, purchasing is waiting on approval, approval is waiting on machine repair.”

Silent errors nobody sees

These are typical examples. They turn up in any system where people set up rules and connections:

A document stuck forever. A contract goes out for approval, but the approver list is empty. There’s nobody to vote, so the document sits “in approval” forever, with no error, no email, and no deadline.
A task that vanished from view. Someone nested a task inside its own subtask. It’s still in the database, but it no longer shows up in any list.
A loop in the org structure. A department was accidentally set to report to its own sub-team. Permissions and approvals start going in circles.
A dependency loop. Task A waits on B, B waits on C, and C waits on A. Nobody’s at fault, but nothing moves.

The fix is a division of labor. A hard block like “you can’t close this loop” lives inside the service itself, so saving work never depends on anything external. Analyzing what has already piled up is LOGUS’s job: it sees the whole picture and names the problem in plain words.

Constraints that currently live in people’s heads

The second use is for rules of the form “what’s allowed and why not.” Every company has them, but they’re rarely written down:

“this department can’t report to that one”;
“no manager has more than eight direct reports”;
“these two roles can’t be held by the same person”;
“these two people can’t be on site at the same time”;
“every shift needs at least one certified employee”;
“supplier payments only with a signed certificate.”

Once they’re written in LOGUS, rules like these are checked automatically. The TEAMUS org chart is already checked this way for reporting loops. HR sees a line saying “there’s a loop in the structure” and how to break it, not a canvas full of diagrams.

LOGUS inside other services

LOGUS is a shared engine for the whole platform, not a separate app you have to open.

TEAMUS checks the org structure for loops and staffing rule violations.
TASKUS runs logic right on the task canvas, so you can draw a process model next to your tasks and run it.
OPTIMUS uses LOGUS in its product configurator to determine which options are compatible and why a given combination is impossible. More in How we built OPTIMUS ERP.
AI agents ask LOGUS instead of reasoning in their heads. When a customer asks a support agent “Can I return this after 20 days?”, the agent doesn’t guess. It runs the return policy.
Notes and Assistentus: a model can live inside a note, and the assistant can run it.

Every run is logged, so you can go back and see what inputs and which version of the rules produced an answer. Rules are versioned, and each company’s data is kept separate.

Where to start

You don’t need to move every company rule into LOGUS at once. Start where mistakes cost the most:

Write down three rules that must never be broken. Usually they involve money, shipping, and access.
Describe them in plain language, the way you’d explain them to a new hire.
Hand them to LOGUS. It builds the model, tests the thresholds, and tells you whether each rule is proven or has a counterexample.
Connect them to your agents, so your AI employees answer from these rules instead of guessing.

The agent that runs your PRANUS implementation helps capture your first rules. It asks how things work at your company and turns the answers into rules you can verify.

AI can get the tone of a letter wrong, or pick the wrong word. But where your business rules are concerned, it shouldn’t be wrong. Want to see LOGUS check one of your own rules? Book a demo. Bring a rule, and we’ll try to find a counterexample together.