Good fit
Aethis works well when all of the following are true:- Binary decisions — eligible, not eligible, or undetermined. No scoring, no weighting.
- Criteria are written down — in legislation, policy, guidance, or a contract. The engine needs source text to generate rules from.
- Rules change deliberately — re-authoring is fast, but it’s a deliberate step. Not suitable for rules that change daily.
- Auditability matters — every decision must trace to a source clause.
Good domains
Insurance underwriting · Loan pre-qualification · Benefits entitlement · Grant eligibility · HR policy · Trade compliance · Medical device clearance · Regulatory permittingCold-start checklist
Before starting with a new domain:- Can you write 10 test cases with clear expected outcomes before authoring begins?
- Can a domain expert state the eligibility criteria in plain English, without hedging?
- Are the criteria in an authoritative source (legislation, policy, contract)?
Aethis vs alternatives
| Aethis | Static rules engine | Decision tree | LLM-only | Spreadsheet | |
|---|---|---|---|---|---|
| Deterministic | ✅ | ✅ | ✅ | ❌ | ✅ |
| Audit trail | ✅ | ✅ | Partial | ❌ | Partial |
| Authoring effort | Low (LLM-assisted) | High (manual) | High (manual) | None | Medium |
| Handles legislation | ✅ | Requires manual encoding | Requires manual encoding | ✅ | Partial |
| Guided eligibility flow | ✅ (shortest path) | ❌ | Fixed path only | Partial (non-deterministic) | ❌ |
| Source-cited explanations | ✅ | Manual | ❌ | ❌ | ❌ |
| Regulated use | ✅ | ✅ | ✅ | ❌ | ❌ |
| Speed | <5ms | <1ms | <1ms | 1–5s | N/A |
Access matrix
Most evaluation is anonymous. Authoring and private-tenant operations are gated. Use this matrix to choose the right entry point before starting.| Capability | Needs account? | Needs API key? | Status |
|---|---|---|---|
Evaluate a public ruleset (/decide against aethis/*) | No | No | GA |
Inspect a public ruleset (/schema, /explain) | No | No | GA |
MCP decision tools (aethis_decide, aethis_schema, aethis_explain, aethis_next_question) | No | No | GA |
Browse the public ruleset catalogue (aethis_discover_rulesets) | No | No | GA |
Compose / decide via a public Rulebook (rulebook_id) | Yes | Yes | GA |
| Evaluate a private ruleset | Yes | Yes | GA |
| Author rulesets (create projects, generate, publish) | Yes | Yes | Private beta — request access |
| Author tools also need an LLM key | — | Anthropic key per request | Generation tools (aethis_generate_and_test, aethis_refine) |
| Self-host the engine | — | — | Not offered; managed only |
What you can express
Field types
| Type | Description |
|---|---|
Bool | True / false |
Int | Whole numbers — use for money (pence), percentages, counts |
Enum | Fixed set of named values |
Date | Stored as integer ordinal (date.toordinal()); ruleset evaluations also accept ISO "YYYY-MM-DD" strings |
Duration | Integer number of days |
String | Free text — equality checks only; prefer Enum for known value sets |
Operators
| Category | Operators |
|---|---|
| Logic | AND OR NOT IMPLIES |
| Comparison | = ≠ < ≤ > ≥ |
| Membership | IN — field IN [v1, v2, …] |
| Arithmetic | + − × for Int fields |
| Aggregation | min(a, b, ...) max(a, b, ...) — 2+ Int args |
| Date helpers | days_between(date_a, date_b) → Int |
Known limits and workarounds
No field division
No field division
You cannot divide one runtime field by another.Workaround: Restructure the threshold. Instead of
annual_income / 52 ≤ weekly_cap, use annual_income ≤ weekly_cap × 52. The constant weekly_cap × 52 folds at authoring time.No weighted scoring
No weighted scoring
Rules produce one of three outcomes:
eligible, not_eligible, or undetermined. No probabilistic scores or risk bands.Workaround: Split scoring into discrete eligibility tiers, each as a separate section. Compose at rulebook level.No list-valued fields
No list-valued fields
Fields must be scalar. You cannot pass a list of residence periods and ask the engine to sum them.Workaround: Pre-aggregate before passing in. Convert a list of residence durations to a total
Int field, or a list of qualifying benefits to individual Bool fields.Maximum three outcome tiers
Maximum three outcome tiers
The engine supports up to three distinct outcomes per decision. Multi-tier benefit schedules with more than three levels require splitting into separate rulesets.
Not the right tool for
- Content recommendations or search ranking
- Probabilistic risk scoring
- Decisions where “close enough” is acceptable
- Domains where the criteria cannot be written down as explicit conditions — if a domain expert cannot state the rules without hedging, the engine cannot encode them