Give people a document they can read and a version they can refer to. Runtime integration can come later.
The public registry and onboarding below are in development. The current workspace supports private managed policies and hosted checks.
Design time · planned
Choose the source you have. Each path leads to review before publication.
01 · In development
Your terms already have a public page.
Review the captured text and section references. Confirm the capture is complete before accepting a candidate.
A URL is a source, not permission to publish. You will confirm your authority to share the approved document.
Continue to document review02 · In development
You have terms as text or Markdown.
Review the readable document alongside the proposed structured sections. Accept or edit changes explicitly.
The original wording remains available for comparison. Extracted structure is a candidate until you accept it.
Continue to document review03 · In development
You already have a supported Antaeus policy.
Validate the file against the released contract, inspect its rules and provide the human document separately when needed.
An executable policy alone does not become a human TOS. A rules-only upload stays rules-only until a document is supplied.
Continue to document review04 · In development
You do not have terms yet.
Answer a guided questionnaire, then edit and approve a proposed draft. Unanswered questions and placeholders stay visible.
Guided drafting is in development and is not legal advice. It does not establish that a document is suitable for your business or jurisdiction.
Continue to document reviewSaving, generating and publishing are distinct actions. You can publish a document without executable rules.
Step 1
Read the exact wording. Inspect suggested sections and any proposed YAML/JSON policy; changes are not adopted automatically.
Step 2
Inspect the eleven-topic checklist. Add missing wording, mark a topic not applicable with context, or acknowledge an advisory omission. This is a review aid, not a compliance score.
Step 3
A verified human owner confirms the public text, rights to publish, visibility and change summary. A saved draft or generated candidate is not a publication.
Step 4
The planned registry gives the document an entry ID and each release its own ID and version number. Publishing a document does not require a key or a check.
Advisory checklist omissions may be acknowledged knowingly. Invalid files, required technical metadata and unresolved placeholders must be corrected. Model suggestions never grant approval or establish legal completeness.
Read a fictional document exampleVersioning · planned
A release ID identifies one immutable snapshot. An entry ID plus a positive integer version selects that same release. Neither selector means “latest”.
A current link follows the publisher’s chosen release when resolved. A reader already displaying a version stays pinned until an explicit refresh.
Current private-policy reference guideExisting private policy versions use a separate string field. The proposed integer registry version does not change that contract.
entry_demo_directoryrel_demo_directory_1Publishing version 2 would give it a new release ID. Version 1 keeps its identity; changing the current pointer is a separate, explicit choice.
Runtime · optional
A published document is not automatically executable. Rules cover a bounded subset of the document, reviewed and qualified for a defined input scope.
The terms have an approved publication. No semantic check is enabled and no key is needed to read the public document.
Review each proposed rule against document sections. Define input facts and frozen expected cases. Candidate rules cannot enable public checks by themselves.
Only a qualified eligible release accepts a check. Select its exact identity and inspect the result; your application owns authorization and enforcement.
Example Directory
impersonationdenywhen: The submission presents itself as another product or organization.
unsupported-claimsreviewwhen: The submission makes a guarantee it does not support.
Most of a terms document is not executable. Only clauses that need a judgment about a submission become candidate rules, and a person reviews and tests each one first.
| Outcome | Meaning |
|---|---|
| ✓ Allow | The input fits the selected executable rules. It does not establish compliance with the whole document. |
| ! Review | The selected rules or uncertain evidence call for human review. |
| × Deny | The input conflicts with a selected executable rule. |
| ? Failure | Evaluation could not produce a policy judgment. Do not treat this as an allow. |
Hosted direct checks and MCP are available today. Registry-linked readiness, release selection and the document workflow shown here are in development.
The planned registry API supports two explicit requests, each selecting an eligible release. Pin both versions and hold the input, scope and evaluator profile constant.
Each request has its own stable idempotency key, limits and settlement. Retry its original body and key. If either result is missing or unresolved, the comparison is incomplete.
A comparison does not choose a winner, change the current release or enforce a result. No automatic A/B traffic allocation is implied.
The idea: replay the same submissions against both pinned eligible versions and inspect the cases that moved before making version 2 current or enabling enforcement. A comparison covers the cases you replay; it does not predict future submissions. Line widths are schematic.
Explore private managed policies now, or run the independent engine locally.