Skip to main content

Feature status

This page is the public source of truth for what EvalGate ships today. It describes release maturity, not aspirations. The current-behavior manuals explain how each surface behaves, fails, and exposes evidence.
EvalGate is currently offered as a controlled beta. A route, screen, or test by itself does not make a feature generally available. Features remain Beta or Experimental until their full acceptance evidence passes on the released commit.

Status definitions

Status is reviewed against the released commit. If documentation and runtime behavior disagree, treat the more restrictive behavior as authoritative and report the mismatch.

Current inventory

Current source identities: 3.7.4 application and 3.7.4 SDK. The latest complete released availability evidence remains anchored to merge commit 46d7fe6c58dadefa58fd5a5e2ac6edfa82ef6919 (PR #241) for 3.7.1: Required Test Lanes executed the Unit, DOM, API, DB, PostgreSQL, and E2E suites successfully, and the post-merge current-head evidence run accepted that exact release SHA and required-suite artifact. The coordinated SDK source release is governed separately by the sdk/v3.7.4 tag contract and its npm/PyPI trusted-publisher workflows; this source-version update does not claim newer production deployment evidence. Owners are accountable teams, not guarantees of support response time.

How to read client gaps

The released 3.7.1 application contract covers every reviewed public API operation and generates compile-checked TypeScript contract types. Exact-head release verification passed, but that does not imply a dedicated convenience method in the TypeScript SDK, Python SDK, or CLI. Missing high-level client workflows are stated explicitly; use the API reference when only the typed REST contract is available.

Maintenance policy

A status change requires all of the following in the same released commit:
  1. A supported UI or public API workflow with documented permissions and failure behavior.
  2. OpenAPI coverage for every public route and generated-client parity where promised.
  3. Tests at the appropriate unit, route, database, and end-to-end layers.
  4. Observable evidence semantics, incomplete-state behavior, and operator recovery guidance.
  5. An owner review of this inventory and the matching current-behavior manual.
Roadmap documents may explain direction, but they do not override this inventory.