Frequently asked questions

There are two interfaces. (1) A REST API that takes JSON and returns JSON, published with an OpenAPI document you can generate a client from in Java, .NET, Go or Node, alongside an installable Python client. (2) An MCP server, so any agent framework that can make a tool call can call it, with your own model doing the extraction from a prompt pack DSAIL generates.

A claims-only call, structured values with no document, is fast enough to sit inside a live workflow; a call that includes extraction is dominated by your model rather than by us. Checks hold no state between calls, so when one decision needs several of them they run concurrently. See the REST API reference, the MCP tools reference, and the quickstarts on the developers page.

The platform is API first. Every function behind DSAIL and the results views, including authoring, versioning, publishing, runs, verdicts, exceptions and dispositions, is available through the API, so you build the authoring and exception-review experience inside your own interface against the same calls our screens use. The DSAIL ruleset studio stays available for your implementation teams where a separate authoring surface is useful. We do not ship our screens as embeddable components.

If you would rather not build those screens yourself, we can build them for you as a services engagement: authoring, exception-review and disposition screens, built in your front-end framework, styled to your design system, and calling the DSAIL API the same way your own code would. You own the code we deliver, and your team can maintain and extend it without us, or we can continue maintaining it under a support agreement.

In a VPC or on-premises deployment, no. Documents, extracted values, rulesets, results, logs and telemetry are stored and processed inside your perimeter, and usage telemetry is recorded locally rather than sent to us. Model calls go only to the endpoint you configure, whether that is a model you host yourself or a provider you contract with directly.

Jaxon does not use your data, your rulesets, your verdicts or your telemetry to train or improve its products, and will agree to that in the contract. If you ask us for help, a Jaxon engineer works under a support role you enable inside your deployment, read-only by default, with every login and action recorded in an audit log you can see. The data handling and security documentation covers the detail.

A better model reads the document better. It still cannot show that its answer satisfies your policy, and that is what the ruleset does. The rules sit outside the model, so a new release changes how the claims get read, not what counts as compliant.

Model traffic goes through a proxy you configure, which holds your credentials, enforces an allowlist and pins the model version, and every run records the configuration it ran under. Rather than certifying a list of models, we give you a regression dataset: documents paired with the claim values and verdicts they should produce. When a provider ships a new version, or retires the one you are on, you rerun that dataset under the replacement and promote it when it agrees.

One deployment serves many through namespaces. Each namespace holds its own rulesets, versions, claims, verdict records, audit trail and administrator roles mapped from your identity provider, and nothing in one namespace can read another's data. Where a client requires it, the record store can be partitioned per namespace under separate keys.

Shared base rules are published once and each namespace composes its own layer on top, so a revision to the base recompiles every composition without touching anyone's local rules, and a conflict surfaces as a diagnostic rather than a silent override. Usage is metered per namespace, so per-team or per-client reporting comes from the same records.

You could. The question is what you would be taking on to maintain. A verification engine needs its own rule language and a compiler for it, versioning strict enough that a check rerun a year later evaluates the exact rules someone approved, arithmetic that understands units, a check that catches two rules contradicting each other before they ship, and a signed record behind every verdict.

Writing the first version of that is not the hard part. The hard part is (1) keeping it from drifting into a second, inconsistent reading of the same policy as your product changes around it, and (2) still being able to defend it to a regulator five years from now. A policy-reading agent or an explainability layer does not cover this, because neither one returns a proof against the rules your client approved. If you are weighing the build, bring us the workflow you would build it for.