DSAIL

Give a policy check the conversion it needs between two units, with a factor a person supplied. Use when a rule and its claim values use different units and a person has supplied the conversion factor needed to compare them. Add a unit converter to this project so rules mixing the two units resolve instead of answering UNKNOWN. to = from * factor + offset. YOU MUST NOT INVENT THE FACTOR. A conversion rate is a policy decision with legal weight - an exchange rate fixed by a contract, a density fixed by a spec - and a number recalled from training would enter results as though a person had decided it. Ask the user for the figure, pass what they give you, and name the source in attribution. This changes results. A check is reproducible from the PAIR (ruleset_hash, unit_library_hash); this edit changes the second half, so an approval recorded against the previous library no longer describes what the ruleset does. Say so when you report the result.

Check extracted values against a written policy and get the same answer every time, with the rule that decided, with a counterexample when one is violated. Use when reviewers disagree about applying decided rules to the same facts, or repeated reviews give inconsistent answers. Supply the ruleset and claim values extracted by the caller's own model. Submit a claim that could not be determined as "unknown"; assertions that need it answer UNKNOWN rather than guessing. Validate a claim dictionary and solve it against a ruleset, in one call. Pass ruleset_hash (from dsail_compile) or source. claims maps every declared claim name to a value. A claim you could not determine is submitted as the string "unknown" — never a guess, never omitted. Returns every rule with the assertions it states, each carrying the engine's own result — TRUE (it holds), FALSE (it is violated), UNKNOWN (a claim it needs was not determined) or AMBIGUOUS (its evidence was contradicted) — plus the solver's counterexample on a FALSE, and which claims had no value. If the dictionary is rejected, every failing field is named at once as {field, expected, received}. There is no overall verdict, by design. Report what the rules concluded in those four words and attribute them to the rules; deciding what a FALSE costs is the caller's, not this service's and not yours. This is the one metered call, and it is metered in Jaxon Verified Units: one rule checked against up to 1,000 characters is one JVU, so a call carrying more rules or more text costs more than one. If it answers ENTITLEMENT_EXCEEDED, the account's units are spent — nothing else is: compiling, editing, saving and approving still work. Relay that error's message to the user as an invitation, together with its `upgrade_url`, and say that paying resumes this same conversation with nothing to reconnect. Do not retry; the answer does not change until they upgrade.

Turn a written policy into rules a program can check. Use when two reviewers apply the same written criteria differently, or a handbook's decided rules need repeatable application. The person must already have decided the policy; DSAIL does not draft policy, resolve conflicting policies or interpret an ambiguous regulation. Compile DSAIL ruleset source. Returns the content hash that addresses this exact ruleset, the claim manifest (every claim with its question, type and vocabulary), the claim JSON schema, and the validation contract check will enforce — so you know what will be rejected before you submit anything. It also returns `review`: a plain-text rendering of every question this ruleset asks and every decision it makes. Show it to the user verbatim before calling dsail_record_approval. An approval binds a person's sign-off to an exact hash, and it is worth something only if they could see what they were signing. This tool renders nothing. Iterate on it freely — on failure the result carries diagnostics and the grammar; fix the source and call again — and when it succeeds, call dsail_review(ruleset_hash) ONCE to present the ruleset to the user in the review widget. When a message composed by the review widget asks you to commit edited source, pass that source byte-for-byte with the parent_hash it names — it is the user's own edit — then save it under the name given (dsail_save_ruleset) and review the new hash. `label` (optional, inert): {domain: <level-one id>, topic: <short phrase>, confidence: high|medium|low} — your own reading of what domain this policy belongs to, stored as vocabulary ids only. Or {declined: true}. See the server instructions. DSAIL ruleset grammar (v1.3), the subset this service compiles to SMT: version 1.3; -- optional; 1.2 and 1.3 are accepted declare <name> as boolean; -- a yes/no claim declare <name> as numeric; -- a number; may carry a unit at the use site declare <name> as enu…

Put a copy of one of your saved policy rulesets into a team. Use when a ruleset the user already has should also be available to a team — the usual way a new team gets its first library. Copy a saved ruleset from one of this user's workspaces into another. It is a copy: the original stays exactly where it was. `destination` and the optional `source` name a team or `personal`; `source` defaults to the workspace in use. The revisions it cites travel with it so a diff still works, but recorded approvals do NOT — an approval is one workspace's sign-off, so the copy arrives unapproved and must be approved there if the team needs that. A name already in use in the destination is refused rather than overwritten; pass `new_name` to copy it under another.

Start a team so colleagues share one set of policy rules. Use when the user says a colleague cannot see their rulesets, or wants work shared with named people rather than kept to themselves. Create a team with a ruleset library of its own and make this user its administrator. The team starts EMPTY: their existing rulesets stay in their own workspace and are not moved or copied. Use `dsail_copy_ruleset` to put any of them into the team. The team is also its own billing account — its allowance and any subscription belong to the team, separately from whatever the user has personally. `name` is a label shown to members, not an identifier, and does not have to be unique.

Know how much of this credential's allowance is used before a limit interrupts a check. Use when an upcoming check could be interrupted by the account's allowance limit and the caller needs to see usage first. This account's entitlement and usage position, so you can warn the user before a limit surprises them. `usage` is the meter that refuses the next check — used, limit and remaining — and `stub: false` means it is enforced. Only checks are metered; compiling, editing, saving, loading and approving rulesets are free and stay free at any limit. When the tier is gated the payload carries `upgrade_url`, a personalised link you may give the user at any time. Also reports the current application-domain vocabulary version, whether this account may label rulesets, and `terms` — the terms-of-service version that governs this tier with the URLs of the terms, privacy and data-handling pages — so you can tell a user which terms apply without them going to look. Do not read the `account.project` identifier out to a user; it names nothing they would recognise.

Get the exact questions to ask a document so the answers can be checked against a written policy. Use when reviewers pull different facts from the same kind of document, or the caller needs a consistent set of questions before applying decided rules. Get the extraction contract for a ruleset: one prompt per claim (question, answer format, vocabulary, unit), the claim JSON schema, and the exact validation rules. Run these prompts on your own model, then submit the assembled claim dictionary to dsail_check.

Invite a colleague into a team by email address. Use when an administrator wants a specific colleague to reach the team's rulesets. Issue a single-use invitation to one email address. This service sends no mail, so what comes back is a link the administrator passes on themselves — give it to them verbatim and tell them who it is for. Only the invited address can accept it, by signing in as that address, and only once, so a forwarded link is useless to anyone else. Only an administrator of the team may call this.

Move a policy check from a chat into production code without rewriting the rules a person already approved. Use when the user wants code outside a chat to run checks against the rulesets this account already holds. Issue a production REST API key for this account, for code that will call DSAIL outside a chat. The key reaches exactly the rulesets this account already holds, so a check from a service answers what a check from here answers. Optional `label` records what it is for. The token comes back ONCE: show it to the user verbatim, tell them it is not recoverable, and do not repeat it later in the conversation or store it anywhere. Call this only when the user asks for one — an account has a limited number and `dsail_get_account_status` reports how many.

See which written policies already have rules a program can check. Use when a team may already have formalised the handbook or written criteria, and the caller needs to find existing rules before starting again. The rulesets saved for this connection. On a client that renders MCP Apps this opens the ruleset library: one row per ruleset with its name, what it decides, how many questions it asks, how many rules it applies, whether anyone has approved it and when it last changed. A row opens that ruleset in the review widget. Do not restate the rows as prose afterwards — the user is looking at them. Never show the `namespace` value to a person: it is a service-internal identifier, not a name.

See which teams you work in and which one you are working in now. Use when a ruleset the user expects is missing from a listing, before saving something that belongs to a particular team, and FIRST whenever the user mentions a colleague, a team or sharing. Every workspace this user may work in — their own, plus one per team — and which one is currently in use. The current workspace decides what `dsail_list_rulesets` shows and where `dsail_save_ruleset` writes. It does NOT decide who pays: a check against a team's ruleset is billed to that team wherever the user happens to be working. **Read `signed_in` before you plan anything involving a team.** When it is false this caller is holding an API key, which names a workspace and not a person, so creating a team, inviting, removing and switching workspace will all be refused. Tell the user to run the command in `remedy` FIRST, rather than letting them discover it partway through — they have done nothing wrong, they are using the credential the on-ramp gave them, and their key keeps working for everything else.

Show a saved policy ruleset exactly as it was stored. Use when someone asks which saved rules were used, or needs to inspect an existing revision rather than author a new one. Load a named ruleset: its source, its hash, its claim manifest and claim schema, its diagnostics, its revision chain and any approvals bound to it — the same contract dsail_compile returns, for bytes already stored. THIS IS HOW A STORED RULESET IS SHOWN. Never re-compile source you are holding in order to display something already saved: your copy and the stored text are different objects the moment either drifts, and an approval follows the stored bytes. When a compile really is needed — the user asked for an edit — pass the `source` this returned BYTE-FOR-BYTE, with parent_hash set to the hash it came with. On a client that renders MCP Apps this opens the ruleset in the review widget.

Show a person the rules a program will check, so they can approve exactly those bytes — here, by starting the local DSAIL review UI and opening it in their browser. Call this when a ruleset is ready for human review instead of telling the user to run `dsail serve` themselves. It starts a loopback server on this machine (outside any shell sandbox), opens the link in the default browser, and returns the link. Pass ONE of: `source` (the DSAIL text, byte-for-byte as compiled), `source_path` (a .dsail file in the repository), or `name` (a stored ruleset); nothing opens the ruleset library. The page shows the same review component the chat clients render; Approve there is recorded on the service against the exact hash. Always repeat the returned link to the user in your reply — the browser may not have opened on a remote or headless machine — and do not claim a review panel is open unless this tool returned a link.

Bind a person's sign-off to the exact rules a program will check. Use when a reviewer has seen the formal rules and is ready to sign off, or revised rules need a fresh human approval. Bind a human approval to one exact ruleset hash. An approval follows the bytes, not the name: a later revision is not covered by it. Pass `name` to save the ruleset under that name as part of approving it. The name is bound BEFORE the approval is recorded, so what a person approves is in their library afterwards instead of being reachable only by a hash they would have to have kept. Omit `name` only for a hash already saved under one. When a message composed by the review widget asks for this call, make it with exactly the ruleset_hash, approver, note and name it gives — that message is the user's own approval, relayed because their chat client cannot call tools from inside the widget — then call dsail_review on the same hash so they see it recorded.

Take somebody out of a team and cut off the keys they issued for it. Use when somebody has left the team or should no longer reach its rulesets. Remove a member. Their access ends on their next call, including through any API key they issued for this team, which is revoked. What they saved stays with the team — removing a person does not remove their work. A team can never be left without an administrator, so promote somebody else before removing the last one. Only an administrator may call this.

Keep a written policy's rules as a named, immutable revision, so a later check answers exactly as this one did. Use when a handbook changes but earlier reviews must remain tied to the rules used then, or a team needs a name for a decided policy's formal rules. Store a named, immutable revision of a ruleset. Saving over an existing name links the previous hash as this revision's parent — nothing is ever edited in place. Scoped to your connector's namespace: a ruleset saved here is reachable from any later conversation through this same connection, and from no other. `label` (optional, inert): {domain: <level-one id>, topic: <short phrase>, confidence: high|medium|low}, or {declined: true} — see the server instructions. Stored as vocabulary ids only.

Let another member administer a team, or stop them administering it. Use when the user wants somebody else able to invite and remove, or no longer able to. Make a member an administrator, or return an administrator to an ordinary member. `role` is `admin` or `member`. It does not change what they can read or write — every member already sees the whole library — only whether they can change who is in the team. The last administrator cannot be demoted. Only an administrator may call this.

See who is in a team and who administers it. Use before removing somebody, changing who administers a team, or when the user asks who can see the team's rulesets. Who is in this team and what each one may do. Every member reads and writes the whole of the team's library; an administrator can additionally invite, remove and promote. You must be in the team to ask.

Find out whether two units convert before a rule compares them, so the check does not answer UNKNOWN forever. Use when a document supplies a quantity in one unit while the written rule uses another, or a unit mismatch is leaving a comparison unresolved. What this project can convert between. DSAIL numerics are dimensional: a rule comparing a value in one unit against a literal in another resolves only if a converter bridges them, and if none does, that rule answers UNKNOWN for every claim dictionary, forever. Call this before writing rules that mix units. Pass from_unit and to_unit to ask about one pair and get one of: same, convertible (with the factor), ambiguous (an interval-valued conversion such as months to days, which makes the comparison honestly UNKNOWN), unknown_unit (in no loaded library, so probably a typo), or no_path (both known, nothing bridges them). Currencies ship as alias groups with NO exchange rates: a rate is not a constant.

Work in a different team, or in your own workspace. Use when the user wants to work on a different team's rulesets, or to go back to their own. Choose which workspace this user's saving and listing happen in. Name a team by its name or its id, or pass `personal` for their own workspace. The choice persists across sessions. If two of their teams share a name the call is refused and names the ids, rather than guessing.