> ## 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. # When to use Aethis > Good fit domains, DSL capabilities, known limits, and workarounds. ## 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 | | 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 | 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. *** ## 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](https://aethis.ai/developer-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 | For the anonymous curl entry point, see [Try it](/getting-started/try-it). For agents, see [Onboarding](/agents/onboarding). *** ## 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 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