Compile source documents into deterministic eligibility rules. Decide in under 5ms, explain why, and guide users through the shortest path to a determination — no LLM at decision time.
Use this file to discover all available pages before exploring further.
Aethis turns legislation, policy, and contract clauses into formal constraint logic. At decision time there is no language model: every call is a deterministic, sub-5ms evaluation against pre-compiled rules, with a cryptographic input hash and a clause-level audit trail on every response.This page is built around three real, public rulesets you can hit right now without an API key.
That’s a live production call against the UK Free School Meals child-eligibility section. The inputs_hash is the canonical fingerprint of the input — same inputs, same hash, same decision, every time.
Public preview. The decision API runs always-warm in europe-west1. The engine evaluates each decision in under 5ms; observed end-to-end round-trip from Europe is ~100–150ms hot, dominated by network and request handling. Multi-region warm pools and a published latency SLA ship with general availability.
{ "slug": "aethis/uk-fsm/child-eligibility", "fields": [ { "field_id": "child.age", "field_type": "int", "description": "Child's age in whole years at the start of the relevant academic year (1 September)." }, { "field_id": "child.school_type", "field_type": "enum", "enum_values": ["state_funded", "independent", "home_educated"] } ]}
Every public ruleset exposes its full input contract this way. List every live ruleset:
The ruleset has 11 fields across 7 rule groups. The engine reasoned over all of them, found a constraint violation in the species check, and short-circuited — fields_provided: 1 because that’s all it needed. The failure_reasons list points at the exact compiled SMT condition that failed, which traces back to a specific clause in the source Spacecraft Crew Certification Act 2049.For natural-language reasoning, add "include_explanation": true instead of (or alongside) include_trace.
{ "decision": "undetermined", "fields_provided": 2, "missing_fields": [ "space.crew.flight_hours", "space.crew.has_pilot_license", "space.crew.has_gaa_exam", "space.crew.has_approved_provider_cert", "space.medical.cert_valid", "space.mission.type", "space.crew.has_radiation_cert", "space.vessel.propulsion_type", "space.crew.has_towel" ], "next_question": { "field_id": "space.mission.type", "question": "What is the mission type?", "weight": 1 }, "optimal_path": [ { "field_id": "space.mission.type", "question": "What is the mission type?" }, { "field_id": "space.crew.flight_hours", "question": "How many flight hours has the applicant accumulated?" }, { "field_id": "space.crew.has_pilot_license", "question": "Does the applicant hold a valid pilot licence?" }, { "field_id": "space.crew.has_gaa_exam", "question": "Has the applicant passed a GAA medical examination?" }, { "field_id": "space.medical.cert_valid", "question": "Is the medical certificate within 730 days of application?" }, { "field_id": "space.crew.has_radiation_cert", "question": "Does the applicant hold a radiation protection certificate?" }, { "field_id": "space.vessel.propulsion_type", "question": "What type of propulsion system does the vessel use?" }, { "field_id": "space.crew.has_towel", "question": "Does the applicant carry a towel?" } ]}
next_question is the single field most likely to collapse the remaining decision space. optimal_path is the full ordered shortlist. This is not a fixed decision tree — the engine evaluates all eligibility paths simultaneously and picks the field that, given what’s been answered, branches the fewest remaining possibilities. Build a wizard, a chatbot, or an intake form on top of this without writing routing logic.
A language model reads your source material once, at authoring time, and proposes constraint logic. That logic is compiled, versioned, and stored. At decision time the engine queries the compiled form — no model in the path, no temperature, no retrieval, no drift. The same inputs_hash always produces the same decision_id shape with the same outcome.
Rules compile from your source documents, not your tests. Tests validate the output. Better test coverage means faster convergence, not different rules.
Not an LLM wrapper. No language model runs at decision time. Decisions come from a constraint solver over pre-compiled rules.
Not retrieval / RAG. Source documents are compiled once into logical sections; decisions query the compiled form, not the documents.
Not a rules engine or decision tree. Rules come from your source text via a test-first authoring pipeline, not from handwritten if/else.
Not probabilistic. Identical inputs produce byte-identical outputs — no temperature, no sampling, no drift.
Not a legal chatbot.Aethis Legal is one application. The engine is domain-agnostic — see the spacecraft, construction, consumer-credit, and UK Free School Meals cases in aethis-examples.
Wire the engine into your coding agent in one command:
claude mcp add aethis -- npx -y aethis-mcp
Then ask in natural language: “Use Aethis to check whether a 10-year-old at a state-funded school qualifies for free school meals.” Your agent calls aethis_decide for you. See MCP server overview.
# Recommended — isolated, no venv juggling:uv tool install aethis-cli# Or: pipx install aethis-cli# Or in a venv: python -m venv .venv && source .venv/bin/activate && pip install aethis-cliaethis decide \ -b aethis/uk-fsm/child-eligibility \ -i '{"child.age": 10, "child.school_type": "state_funded"}'
Add --explain for the trace. Inspect a ruleset’s input fields with aethis fields -b <ruleset_id>. See CLI reference.
The Python SDK (pip install aethis-sdk) is also available; unlike the three options above it requires an API key, so it’s the right choice once you have authoring access or you’re shipping a server that calls authenticated endpoints.
Three steps: paste source text, write tests, iterate until they pass. The same authoring pipeline is exposed via MCP tools and the CLI.
1
Create a project, drop in source + tests
CLI
MCP prompt
aethis init income-thresholdcd income-threshold# Put source PDFs / text into sources/# Add test cases to tests/scenarios.yaml# Optional: hints in guidance/hints.yaml
See examples/spacecraft-crew-rules/ in aethis-cli for a complete project layout you can copy.
Use aethis_create_ruleset to start a project called"Income threshold check" with section_id income_eligibility,this source text: "An applicant qualifies if their annual netincome is below £30,000…", and two test cases:annual_income 25000 → eligible, 35000 → not_eligible.
2
Generate and test
CLI
MCP prompt
aethis generate --poll # 60–120s, uploads sources + triggers generationaethis test # runs your test cases against the new ruleset
Run aethis_generate_and_test on the project. If anything fails,use aethis_refine with guidance pointing at the specific clausethat was missed.
Any failure points at the clause that was missed so you can refine the source text, the test, or the guidance — not the generated rules. Rules compile from the source, not from the tests.