Skip to main content

​
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 permitting

​
Cold-start checklist

Before starting with a new domain:
  1. Can you write 10 test cases with clear expected outcomes before authoring begins?
  2. Can a domain expert state the eligibility criteria in plain English, without hedging?
  3. Are the criteria in an authoritative source (legislation, policy, contract)?
If any answer is uncertain, the bottleneck is criteria definition — that has to be solved before rules can be authored.

​
Aethis vs alternatives

Use a static rules engine when you can afford the high manual authoring effort and do not need rules compiled from source documents. Use a decision tree when the branching logic is simple and fixed — but note that decision trees follow a single path and cannot optimise the question order across interacting requirements. Use an LLM-only approach when auditability and determinism don’t matter. Use a spreadsheet for small, stable, manually-maintained rule sets.

​
Access matrix

Most evaluation is anonymous. Authoring and private-tenant operations are gated. Use this matrix to choose the right entry point before starting. For the anonymous curl entry point, see Try it. For agents, see Onboarding.

​
What you can express

​
Field types

​
Operators

​
Known limits and workarounds

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.
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.
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.
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