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.
Project vs ruleset — A project is an authoring session: source text, test cases, and guidance. A ruleset is a published, locked version of compiled rules from a project. One project can have many ruleset versions. Decision tools use ruleset IDs; authoring tools use project IDs.
The idea
A language model reads your source material — potentially multiple documents covering different aspects of the same legislation — and generates rules organized into logical sections. Those rules compile to formal constraint logic. After that, every decision is pure evaluation — deterministic, fast, and traceable to the source clause that produced it.What the engine delivers at runtime
Once a ruleset is published, the engine provides three capabilities — all without a language model in the path: Eligibility decisions. Pass input data, geteligible, not_eligible, or undetermined in under 5ms. Deterministic: same inputs, same answer, every time. At scale, thousands of evaluations per second.
Explanations with source citations. Every decision traces to the specific criteria and source clauses that produced it. The engine returns each criterion with a human-readable rule description and the regulation or policy section it was compiled from — not a probability distribution, but a complete audit trail.
Guided eligibility flow. Instead of requiring all fields upfront, the engine can guide a user through questions one at a time, identifying the minimum set needed to reach a decision. It evaluates all eligibility paths simultaneously — not a fixed decision tree — so it finds the shortest route through complex, interacting requirements. If a single field is disqualifying (species is Vogon), the engine stops immediately without asking further questions. If multiple routes to eligibility exist, it navigates the cheapest path first.
Gap detection. When no rule covers a particular combination of inputs, the engine returns undetermined rather than guessing. This surfaces missing coverage during authoring — rule authors can see exactly which input combinations fall outside the compiled rules.
Why not just use an LLM at decision time?
Language models are good at interpreting rules. They are not reliable at executing them consistently. The failure mode is silent: the model reads the policy, reasons through it, and returns a confident, well-structured answer — that is sometimes wrong, with no way to know when. The same question asked twice can produce different answers. The same question asked differently almost certainly will. In regulated domains — insurance underwriting, benefits entitlement, lending, compliance — this is not acceptable for three reasons:- Determinism: the same inputs must produce the same decision every time. An applicant who qualifies on Monday must qualify on Friday.
- Auditability: every decision must trace to a specific source clause. Not eligible because field X does not satisfy condition Y in section Z. A probability distribution over tokens is not an audit trail.
- Regulatory defensibility: in supervised sectors, AI decision systems must be explainable and reproducible. A stochastic model cannot meet this bar.
Do you need multi-section authoring?
Single section
One coherent set of criteria, one decision. Skip straight to Rule generation. No section discovery or field vocabulary phase needed.Example: income threshold check, age gate, single benefit route
Multiple sections
Multiple independent entitlements, or prerequisite gates shared across routes. Use the three-phase model below.Example: Free School Meals (A AND (B OR C)), UK citizenship (residence + language + good character)
The three-phase authoring model
Section discovery
An LLM reads the source legislation and proposes how to split it into independently testable sections. You review and confirm the boundaries. Each section becomes its own rule ruleset with its own source documents, test cases, and guidance.The Free School Meals example produces three sections — child eligibility gate, means-tested household criteria, and universal infant entitlement — each drawing from multiple source documents. The Free School Meals Regulations 2014 appears in all three sections but contributes different regulations to each.Section discovery →
Field vocabulary
For each section, the engine identifies input fields — names, types, constraints. You validate the vocabulary before writing test cases. If field names in tests don’t exactly match the engine’s discovered names, tests silently fail.Field vocabulary →
Rule generation (TDD)
The engine generates rules from your source text. Your test suite runs against them. Failures surface in the test output with a reference to the specific source clause that was missed. You add guidance pointing to that clause. The loop repeats until all tests pass. Then you publish.“Surface” means: the test runner shows you which criterion failed and quotes back the clause it couldn’t find in the compiled rules. Guidance is the feedback mechanism — natural language pointing to the missed text.Rule generation →
Who drives what
There is no required division of labour — a developer can author rules end-to-end without any domain specialist involved. In regulated contexts, the person who understands the legislation best will typically:- Provide or verify the source documents
- Write test cases with expected outcomes
- Review guidance hints for accuracy before the next generation run
undetermined and flags for human review rather than guessing.
Next
When to use Aethis
DSL capabilities, limits, and a fit checklist.
Choose your interface
MCP server, CLI, or REST API — which to use when.