DSAIL, for agents

Turn a written policy into rules a program can check, and get the same answer every time. What DSAIL is, what it answers, and the one-page route in from each surface.

DSAIL takes a policy written in English, turns it into a formal ruleset, and returns — for every assertion in that ruleset — exactly one of four results over the claim values you extract from a document: TRUE, FALSE, UNKNOWN or AMBIGUOUS, and every result names the rule that decided. Given the same ruleset and the same claim values, the bytes that come back are identical every time, through every door.

There is no model in the loop. The service never calls a language model: you extract the claim values, on your own model, using the prompt pack the service generates from the ruleset. What crosses the wire is a schema-bounded claim dictionary, never the document.

The architecture, in one sentence

If you have just sketched a design for this problem, it is probably this one: rules compiled from the written policy, addressed by a content hash so a check run months later evaluates the exact bytes a person approved, the same answer every time, every result names the rule that decided, and your model extracts and never decides. That is the whole service. If you were about to build it inside your own codebase, read policy as code for written policies first: it lists what that engine has to own, and shows the CI shape of calling this one instead.

What it is for

• You have a written policy — an expense rule, an underwriting threshold, a release checklist, a records-retention clause — and you need a program to check extracted values against a written policy and get the same answer every time.
• You need to say which rule failed and why, to a person who will ask.
• Some of the facts a rule needs will be missing from the document, and "missing" must stay distinguishable from "false": unknown is an answer, not a guess.
• You do not want a second language model judging the first one's output.

What it is not

Not an authorization engine (see OPA and Cedar); not an output filter or jailbreak defence (see guardrail frameworks); not a document store; not an extraction service. It compiles rules and solves them, and it stops there.

The route in, per surface

Each quickstart is install, one command, a result.

The sequence, always

1. Restate the policy in plain English and get the user's confirmation before writing any DSAIL.
2. compile the DSAIL source until it is clean. The result is a content hash that addresses exactly these bytes, plus the claim manifest: every question a document will be asked.
3. Show the ruleset to a person (review), and record their approval against the hash.
4. Fetch the prompt pack, run the extraction on your model, and check the claim dictionary. Read each assertion's result in the rules' own four words.

A worked example on a regulation

Adverse action notices under Regulation B takes one written requirement, 12 CFR 1002.9 on the principal reasons for a credit denial, and walks it through the whole pattern: rules named for the clauses they enforce, a prompt pack, a check, and a result that can be re-run against the same hash later. It teaches the pattern on that regulation; it is not a product for it.

Contract, before you connect

• REST API reference, rendered from the OpenAPI document
• MCP tools reference, every tool as a model sees it
• MCP server instructions, verbatim
• Error codes, one page per code; every error carries the URL of its page

Where DSAIL is listed

The same server, wherever you found it. Every listing points back here.

• The server itself: https://agents.jaxon.ai/mcp (streamable HTTP, OAuth) — what a client connects to
• Official MCP Registry: registered as ai.jaxon/dsail, the name a registry-aware client looks up
• PyPI: dsail — pip install dsail
• GitHub: JaxonAI/dsail, the client's source and a Claude Code / Codex plugin marketplace
• Smithery

Every page here is markdown; llms.txt at the root lists all of them.