Data handling

Exactly what the DSAIL hosted service stores, what it never does with it, what it must never be sent, and how the one derived field — a category label from a published vocabulary — is kept from ever pointing back at anyone's policy.

Version 2026-09-14. Draft pending review by outside counsel. Issued by Jaxon, Inc. as the technical statement behind the hosted-service terms and privacy notice, which sit under Jaxon's Terms and Conditions and Privacy Policy. Written for two readers, a procurement reviewer and a model. No marketing.

What we store

Not stored: your e-mail address, your name, your picture, your client address, your card, your billing address. The address is used once at sign-in to work out which organization you belong to and then discarded; if it is at a public mailbox provider, what is recorded is an irreversible digest of it rather than the address or its domain.

What we do not do with it

• We do not read ruleset source for any purpose other than compiling it on your request. There is no search over it, no indexing, no sampling, no training, no analysis of content. The terms grant Jaxon a licence to store and process it solely to provide the service, plus the aggregate-statistics right described below, and nothing else.
• We do not run a language model, on any tier, for any purpose, at this version of the service.
• We do not record claim values, claim names, or what any assertion concluded. A check leaves no record of the values judged.
• We do not log policy text or claim values at any log level.
• Nothing on this documentation site is derived from any customer's ruleset, claims or usage. The examples are a demo expense policy and invented values.

What you must not send, and what we are not

The service is built to hold policy rules, not the material a policy governs. It holds no FedRAMP authorization, no DoD provisional authorization, no CJIS agreement, no HIPAA business associate agreement and no PCI attestation; it runs in a commercial AWS region in the United States, operated by Jaxon personnel who are not screened for clearance. A Jaxon administrator with access to the host could, in principle, read stored source bytes; the terms bind them not to, and no procedure Jaxon operates does.

So a ruleset must never carry classified information, Controlled Unclassified Information, ITAR- or EAR-controlled technical data, Criminal Justice Information, protected health information, cardholder data, or personal data beyond the approver names and notes an approval record needs. DSAIL source is authored from a policy and can carry policy language verbatim in rule names, string literals, comments and notes — write it so that it does not. The published vocabulary's security_classification domain is a category for policies about controlled information; the controlled information itself does not belong on this service. Jaxon does not screen for it and has no obligation to treat what you submit as controlled.

Results are conclusions, not determinations

Every result is what the rules concluded about the claim values you supplied, per assertion, in the engine's four words — TRUE, FALSE, UNKNOWN, AMBIGUOUS — each naming the assertion that decided it. The service publishes no overall verdict and makes no compliance or legal determination. Whether the claim values faithfully describe a document is your extraction's responsibility and sits outside the formal guarantee: the service never sees the document, and cannot know whether a value is true of it. UNKNOWN is a legitimate result meaning a needed claim was not determined, not a failure and not a pass.

The one derived field, and how it is kept honest

The single fact the service derives about a ruleset is an application-domain label: which of fourteen broad domains the policy belongs to (level one), and optionally a narrower topic (level two).

• Your model produces it, not ours. The host model reading your policy passes label: {domain, topic, confidence} beside the compile or save. The service never reads the policy to check or improve the label.
• It is stored and emitted as ids, never as text. Level one is a closed list. The level-two topic string your model sent is matched against the published vocabulary and then discarded; on a match the term's id is stored, on no match the ruleset keeps level one only. The string is written to no ruleset record and cannot reach the usage stream — the function that writes events has no parameter for it.
• A term enters the vocabulary only by promotion. An unmatched topic goes to a counter. When at least K distinct external accounts have independently proposed the same normalised term, it is promoted and published with its provenance recorded as promoted; Jaxon's own accounts never count. Proposals that do not reach K within the proposal TTL are deleted, not flagged. K is at least 5, currently 5; the current K and TTL are published live on the vocabulary page; lowering K below 5 is a version change to the terms, with notice.
• It is refusable and inert. Pass label: {declined: true} to decline; omit it to leave the ruleset unlabeled; an operator can turn labeling off for an account. No label is ever read to gate, route or alter any behaviour.

Aggregate figures

Jaxon computes, internally and in aggregate, what share of rulesets fall in each domain and topic, and how features such as the unit library, revisions and approvals are adopted. The terms grant that right expressly and subject to the rules below, which a reviewer can check rather than take on trust:

• Separate credentials, separate reach. The analysis runs from a dedicated AWS role that can read the usage-event log group and nothing else. It cannot reach the host, the store volume, the backups, the proposal counter or the object store; the operations runbook demonstrates each refusal rather than asserting it, after every change to the deployment.
• No join path to content. The events the analysis reads carry vocabulary ids and a content hash. The role that reads them cannot dereference a hash to bytes, because the bytes are on a volume it cannot reach.
• Minimum cell size. A category represented by fewer than N distinct external accounts does not appear in any figure that leaves the analysis boundary — level-two terms included, on top of the promotion gate. N is at least 5, currently 5, and K is required to be at least N at deployment time, so no published term can describe fewer accounts than a report is allowed to show. N is printed on every report; lowering it below 5 is a version change to the terms.
• Every figure names its vocabulary version and its relabeled fraction. When the vocabulary changes, historical labels are remapped from their ids where the mapping is decidable and re-proposed by the owner's model otherwise, so a figure states how much of the population it covers under the version it names. Comparison over time is exact at level one and approximate at level two, and that is an accepted property of the design.
• The internal dashboard is inside the boundary. It is not subject to suppression, and it is never the source for a figure that leaves Jaxon.

Retention and deletion

Rulesets, approvals and unit libraries: until you ask for deletion, or thirty days after an account ends other than for your breach. Deletion removes the objects and their metadata rows from the live store at once. Backups: daily for 35 days, weekly for 120, monthly for 400, in-region and cross-region alike; a deleted object persists in those copies until they age out and is not restored selectively. Usage events and CDN access logs: 400 days.

Security incidents

On confirming an incident affecting stored content or an account, Jaxon notifies the affected customers without undue delay and within 72 hours, stating what was affected. The tables above bound what that can be.

Who can reach what

Related: Terms of service, Privacy, Published vocabulary.