Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.aethis.ai/llms.txt

Use this file to discover all available pages before exploring further.

​
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 · Immigration 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

AethisStatic rules engineDecision treeLLM-onlySpreadsheet
Deterministic✅✅✅❌✅
Audit trail✅✅Partial❌Partial
Authoring effortLow (LLM-assisted)High (manual)High (manual)NoneMedium
Handles legislation✅Requires manual encodingRequires manual encoding✅Partial
Guided eligibility flow✅ (shortest path)❌Fixed path onlyPartial (non-deterministic)❌
Source-cited explanations✅Manual❌❌❌
Regulated use✅✅✅❌❌
Speed<5ms<1ms<1ms1–5sN/A
Use a static rules engine when you need sub-millisecond decisions at extreme volume and can afford high authoring effort. 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.

​
What you can express

​
Field types

TypeDescription
BoolTrue / false
IntWhole numbers — use for money (pence), percentages, counts
EnumFixed set of named values
DateStored as integer ordinal (date.toordinal())
DurationInteger number of days
StringFree text — equality checks only; prefer Enum for known value sets

​
Operators

CategoryOperators
LogicAND OR NOT IMPLIES
Comparison= ≠ < ≤ > ≥
MembershipIN — field IN [v1, v2, …]
Arithmetic+ − × for Int fields
Aggregationmin(a, b, ...) max(a, b, ...) — 2+ Int args
Date helpersdays_between(date_a, date_b) → Int

​
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