Skip to main content
Authoring is invite-only private beta. Everything on this page needs an Aethis API key with authoring scopes, plus your own model-provider key for the generation steps. Request access, or start on the open evaluate tier with your first decision — no key required. The two tiers are set out on Capabilities and access.
In this tutorial, you will create a tiny ruleset from source files, review the fields and tests, add guidance, generate rules, publish, and run a decision. Expected time: 15 minutes. Generation usually takes 1-3 minutes for a small example. More complex policies can take longer.

What you will see

By the end, you will have seen the full authoring loop:
  • A real project directory with sources/, tests/, and guidance/
  • Claude Code using Aethis MCP to create and generate a ruleset
  • Field discovery before generation, with a human review checkpoint
  • Test cases drafted by Claude and reviewed by you
  • Guidance hints stored as files and sent to the API
  • A generate/test loop until all tests pass
  • A published ruleset that returns deterministic decisions
You can paste rules into the conversation, drop files into sources/, or ask Claude Code to fetch source material from the web and save it there. This tutorial uses two small local files so every step is easy to inspect.
If Claude fetches source material from the web, review the saved files before authoring. Web pages can contain summaries, navigation text, or stale content. The rules should compile from the source text you approve.

Before you start

You need:
  • aethis-cli installed
  • Aethis MCP installed in Claude Code
  • An Aethis API key with authoring access
Install MCP if you have not already:
Restart Claude Code after installing MCP.

1. Create the project directory

Use the CLI to create a file-based authoring project:
The CLI creates this structure:
The directories matter:
  • sources/ contains the rules or policy text
  • tests/scenarios.yaml contains expected decisions
  • guidance/hints.yaml contains subject-matter guidance for generation
  • .aethis/ stores local tool state such as project IDs

2. Add two source files

Create sources/age-rule.md:
Create sources/school-type-rule.md:
This shows the normal workflow: source material lives in files. Claude Code can read those files and call MCP tools from the conversation.

3. Add initial guidance

Open guidance/hints.yaml and replace the placeholder with:
Guidance hints are not a substitute for source text. Use them to clarify field names, scope, vocabulary, and known authoring conventions.

4. Ask Claude Code to inspect the project

In Claude Code, ask:
Claude should identify two expected fields: If Claude proposes different names or extra fields, correct them before generation.

5. Review the tests

Ask Claude to write the tests into tests/scenarios.yaml. The reviewed file should look like this:
These tests cover the lower boundary, upper boundary, below-boundary case, above-boundary case, and both excluded school types.
Tests are your review surface. Passing tests mean the generated rules match the reviewed test suite. They do not prove your source material is complete.

6. Create the MCP project and discover fields

After you approve the tests, ask Claude:
Claude should call MCP tools in this order:
Review the discovered fields against the expected fields:
If discovery adds unrelated fields such as household income or benefits, tell Claude to add guidance narrowing the scope and run field discovery again.

7. Generate and test

When the field discovery looks right, ask:
Claude should call:
For this tutorial, the expected result is:
The generated criteria should be equivalent to:
If a test fails, keep the feedback specific:

8. Publish

Only publish after the test gate is green:
Claude should call:
Publishing runs the tests again as a server-side gate. If the tests do not pass, publishing is blocked unless you explicitly force it.
If generation times out in the client, it may still finish server-side. Ask Claude to check the project status or run the tests again before assuming generation failed.

9. Run two decisions

Ask Claude:
Claude should call:
Expected decision:
Then ask for a failing case:
Expected decision: not_eligible, with school_type_check not satisfied.

10. Export guidance back to files

During a conversation, Claude may add guidance directly through MCP. Export active guidance back into the project so it remains reviewable and version-controlled:
You can also import local guidance into the API:
This is deliberate, not automatic. Treat guidance/hints.yaml as the human-reviewed record of the SME guidance that shaped generation.

The pattern

For a first authoring session, keep the loop this small:
1

Put source text in files

Start with one small section. Do not begin with a whole Act, handbook, or policy manual.
2

Review fields and tests

Let Claude draft them, but approve them yourself. Boundary tests matter more than volume.
3

Review guidance

Keep guidance specific and scoped. Export MCP-added guidance back to guidance/hints.yaml before review.
4

Generate, publish, decide

Publish only after the test gate is green, then call aethis_decide against the published ruleset.
Once this flow is comfortable, move to Author a rule from legislation for section discovery, field vocabulary, and multi-section composition.