Skip to main content
The documentation describes the current contract, and api.aethis.ai serves engine 0.59.3 — the build that contract describes. Everything on these pages is live; nothing on them is waiting on a deploy. Every response carries engine_version. Check it to see which build served you:

What changed at 0.49.1

Earlier revisions of this page listed contract rows that the deployed engine did not yet serve. All of them now do. Each row below was re-verified against api.aethis.ai on 2026-07-28:

What to guard for anyway

Nothing here is version-gated any more, but two habits stay worth keeping:
  • Check field_errors yourself rather than relying on the engine to force undetermined for you — good practice regardless of which build answers.
  • Treat source_references as optional. null and [] both mean “this criterion carries no verified reference”, never “verification failed”.
If a call ever returns an engine_version below 0.49.1, you are talking to a different deployment — check the host before debugging the contract.

Coordinated release candidate: frozen rulebook members

Core candidate e71e758 adds an additive release object for a composed rulebook decision. It is not a deployed capability claim: do not send release_id to api.aethis.ai or rely on this response shape until the production OpenAPI and an observed production response confirm it. When deployed, a caller will be able to pin a composed decision with release_id. The response will retain the selected release_id, its existing content_identity, and a members mapping. Each member records the resolved section, ruleset identity, version identity and content digest used for that release. This is stronger than retaining a composition hash or member IDs alone: it makes a replay auditable against the exact member bytes.
Treat this as the coordinated OpenAPI candidate shape. The deployment gate is the live OpenAPI plus a pinned decision/replay observation; a merged core pull request alone is not evidence that public production serves it.