DSAIL

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. `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 `plans_url`, the address of a page describing the available plans. Also reports the current application-domain vocabulary version, whether this account may label rulesets, how many API keys it may still issue, and `terms` — the terms-of-service version that governs this tier with the URLs of the terms, privacy and data-handling pages. `account.project` is an internal identifier that names nothing a user would recognise. `account.organizations` lists the owner of the workspace currently in use (a team id while working in a team), not the teams the user belongs to; the workspace listing is where those are.

dsail_get_account_status

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. Adds a unit converter to this project so rules mixing the two units resolve instead of answering UNKNOWN. to = from * factor + offset. The factor is a policy decision with legal weight — an exchange rate fixed by a contract, a density fixed by a spec — and `attribution` records the person or document it came from, because a figure recalled from training would enter results as though a person had decided it. 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. The result says so.

dsail_add_unit_converter

Check extracted values against a written policy and get the same answer every time, with the rule that decided. Use when reviewers disagree about applying decided rules to the same facts, or repeated reviews give inconsistent answers. Takes the ruleset and claim values extracted by the caller's own model. Validates a claim dictionary and solves it against a ruleset, in one call. Takes `ruleset_hash` (a compiled ruleset's content hash) or `source`. `claims` maps every declared claim name to a value; a claim that could not be determined is the string "unknown", which the rules treat as a first-class answer rather than a guess. 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), with the assertion's name and source text, and which claims had no value. AMBIGUOUS is reserved: it needs several answers for one claim, and a claim dictionary holds one, so no check sent here returns it. A rejected dictionary names every failing field at once as {field, expected, received}. There is no overall verdict, by design: the four per-assertion words are the whole answer, and what a FALSE costs is a decision for whoever reads it. This is the one metered call. It counts against the account's allowance of Jaxon Verified Units: one rule checked against up to 1,000 characters is one JVU, so a call carrying more rules or more text counts as more than one. When the allowance is used it answers ENTITLEMENT_EXCEEDED, and everything except checking keeps working.

dsail_check

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 has already decided the policy; DSAIL formalises decisions, it does not draft policy, resolve conflicting policies or interpret an ambiguous regulation. Compiles 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 a check will enforce — so what will be rejected is known before anything is submitted. Also returns `review`: a plain-text rendering of every question this ruleset asks and every decision it makes. It is what a person signs when they approve the hash, so it is worth showing them before an approval is recorded. Renders nothing on its own, so iterating on it costs nothing. On failure the result carries diagnostics naming the offending line, plus the grammar below as `hint`. On success the hash is what the review widget, a check and an approval all address. `parent_hash` (optional) links this revision to the one it edits, so the review can show a diff; source relayed from the widget's own edit control arrives with the parent it names. `label` (optional, inert): {domain: <level-one id>, topic: <short phrase>, confidence: high|medium|low}, the caller's reading of what domain the policy belongs to, stored as vocabulary ids only; or {declined: true}. 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; units go on literals (below) declare <name> as enum ["a","b"]; -- ORDERED vocabulary (comparable with < >) declare <name> as enum {"a","b"}; -- UNORDERED vocabulary (== and != only) declare local <name> as boolean; -- rule-local; NOT a claim, never extracted assert <name> { <expr> }; -- the rule. Holds => compliant. assert <name> [pessimistic] { ... }; -- unknown-resolution policy: -- optimistic | pessimistic | neutral Enum members are double-quoted strings. Every statement ends with a semicolon. You do not write `let` bindings for claim values — this service injects them from the claim dictionary you submit to check. Literals: numbers 42 3.5 0.05 with a unit 3000 "mi" 25000 "USD" 0 "USD" -- a number followed by the unit as a QUOTED string. A bare -- unit word is a syntax error: 3000 mi fails to parse. booleans True False -- capitalised. Lowercase true and false are read as -- identifiers and fail as undefined variables. enum members "low" "high" -- double-quoted strings Expressions: comparison == != < <= > >= (thresholds are STRICT: > means strictly greater, NOT at-or-above. Write >= if you mean at-or-above. Equality is ==, not =.) arithmetic + - * / % LOGIC IS FUNCTION-STYLE, NOT INFIX. There is no `and`/`or`/`not` keyword: And(a, b, ...) Or(a, b, ...) Not(a) Xor(a, b) Implies(a, b) If(cond, a, b) conditional IF <cond> THEN <expr> [ELSE <expr>] END CASE <subject> OF "x": <expr>, "y": <expr>, DEFAULT: <expr> END quantifiers ForAll(x in s, p) Exists(x in s, p) AtLeast(n, x in s, p) AtMost(n, x in s, p) ExactlyOne(x in s, p) CountWhere(x in s, p) sets IsMember(v, s) IsSubset(a, b) Union(a, b) Intersect(a, b) Difference(a, b) What a check answers. Every assertion gets its own result, and that is the whole answer: TRUE the assertion holds FALSE the assertion is violated UNKNOWN a claim it needs was submitted as unknown, or is unconstrained AMBIGUOUS reserved. It means an assertion's evidence contradicted itself, which needs several answers for one claim. A claim dictionary holds exactly one value per claim, so no check submitted to this service produces it. Handle the word if you switch on results; there is no input that triggers it. There is no combined verdict, no severity and no ranking. What a violated assertion should cost — a refusal, a human review, a note in a file — is a decision for the system reading the result, and this service does not make it. Host annotations. These are ordinary DSAIL comments, invisible to the compiler, read by this service. Every one of them describes a CLAIM — what to ask for it and what a valid answer looks like. None of them decides an outcome: // @ask <claim> What is ...? -- the question shown to an extractor // @context <claim> <text> -- extra context for the extractor // @range <claim> 0..100 -- numeric bounds, enforced at check time // @unit <claim> USD -- expected unit for a numeric claim @effect, @effect-default and @consistency are NOT recognised. A ruleset carrying one does not compile. Rule descriptions. Directly above every assert, with no blank line between, write what the rule requires in plain words as an ordinary comment block (no @ tag). The review widget shows it as the rule's description and a person edits it there, so it must say what the assert beneath it actually checks. dsail_compile over MCP refuses an assert that has none, naming its line. Worked example: version 1.3; // @ask loanAmount What is the loan principal, in USD? // @unit loanAmount USD // @range loanAmount 0..100000000 declare loanAmount as numeric; // @ask hasAppraisal Does the file contain a completed appraisal? declare hasAppraisal as boolean; declare riskTier as enum ["low","medium","high"]; // No loan may exceed one million dollars. assert within_cap { loanAmount <= 1000000 "USD" }; // A loan over 500,000 USD needs an appraisal on file. assert large_but_documented { Or(loanAmount <= 500000 "USD", hasAppraisal) }; // A loan over 250,000 USD needs an appraisal on file. assert appraisal_when_large { IF loanAmount > 250000 "USD" THEN hasAppraisal ELSE True END }; // High-risk applicants are not permitted. assert tier_permitted { riskTier != "high" };

dsail_compile

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. Copies 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 stay behind — 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; `new_name` copies it under another.

dsail_copy_ruleset

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. Creates a team with a ruleset library of its own and makes this user its administrator. The team starts EMPTY: their existing rulesets stay in their own workspace and are not moved or copied; copying a ruleset is how work gets into it. A team has no allowance of its own: each member's checks in it count against that member's own account. `name` is a label shown to members, not an identifier, and does not have to be unique.

dsail_create_team

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. Returns the extraction contract for a compiled ruleset: one prompt per claim (question, answer format, vocabulary, unit), the claim JSON schema, and the exact validation rules a check enforces. The prompts are for the caller's own model to run; this service calls no model. The assembled claim dictionary is what a check takes.

dsail_get_prompt_pack

Invite a colleague into a team by email address. Use when an administrator wants a specific colleague to reach the team's rulesets. Issues 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. 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. Restricted to the team's administrators.

dsail_invite_to_team

Issues a REST API key for this account. The key authenticates calls to the DSAIL REST API, sent as the `x-jaxon-credential` header, and reaches the rulesets this account holds. Optional `label` records what the key is for. The token is returned once and cannot be recovered; the service keeps only a hash. An account has a limited number of keys.

dsail_issue_api_key

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. Only a member of the team may ask.

dsail_team_members