Why I Built Antaeus
Some product rules depend on meaning: “no counterfeit goods,” “flag harassment,” “review medical claims.” I built Antaeus to give those judgments an explicit policy, an inspectable decision, and a testable path into an application.
A marketplace might prohibit counterfeit goods. A content workflow might flag medical claims. These rules depend on meaning, and the input rarely arrives in a neat shape that an if statement can settle. A language model can help judge the input. The problem starts when the same prompt also owns the policy, the verdict, and the explanation.
A prompt is an awkward place to keep a policy
If the instruction is buried inside a prompt, a policy edit looks like a wording change. It becomes hard to answer basic questions: which rule matched, which version was in force, and what should happen when the model cannot decide? Those are application questions. They need explicit answers.
Antaeus makes the policy a named, versioned artifact. A rule has a plain-language condition and a fixed outcome. The policy can be checked into Git, reviewed, tested, and identified by a digest in every decision.
Ask the model a smaller question
The evaluator receives the input and rule conditions. Its job is to report whether each condition applies. It does not choose the business outcome. Antaeus attaches the outcomes declared in the policy and reduces the matched rules deterministically.
For a marketplace, the condition might be “the listing offers counterfeit goods.” The application’s chosen outcome is deny. The evaluator judges the former; the policy engine owns the latter. A matched deny rule takes precedence.
Uncertainty needs a place to go
The result is a typed Decision: allow, review, deny, or failure. Completed uncertainty routes to review. A timeout, refusal, malformed response, or execution error is a failure. Those cases should not silently become permission to proceed.
The decision records the policy digest, evaluator information, and attempts. An application can inspect what happened and choose how to route a review or recover from a failure.
Make the rule change reviewable
The other half is regression testing. Named input cases and expected outcomes let a team ask what a policy edit changes before shipping it. A deterministic fixture evaluator runs those checks offline without credentials. Model-backed checks are a separate question: a passing fixture test verifies the policy mechanics, not a model’s judgment accuracy.
A small engine, with explicit limits
Antaeus is a local-first Go engine and CLI, with no required account, service, or database. Evaluators sit behind an interface, while retries, deadlines, and fallbacks live in an evaluator profile.
It is early, pre-v1 software. The model-backed evaluators are experimental and have not yet been measured for accuracy. A deterministic reducer makes the handling of model judgments inspectable; it does not make those judgments infallible. Ordinary authorization checks and rules that can be expressed reliably in code should stay in code.
The useful boundary is the one I wanted to build: a model can help interpret meaning, while the application keeps ownership of its policy and outcomes.
Explore Antaeus on GitHub · Run the offline quickstart · Project website