Changelog · release discipline

Changes are communicated with versioned clarity.

Enterprises integrate primitives only when changes are predictable. This page explains versioning and compatibility expectations, plus product changes.

API docs Status Trust Center Demo

Policy

Stability through versioning

•Stable /v1 endpoints

•Breaking changes gated by version

•Semantics documented in API reference

Compatibility:
- /v1 contracts remain stable
- changes are additive when possible
- breaking changes require a new version

Release policy

Compatibility expectations

Written for enterprise engineering and security review teams.

Versioned API

Major behavioral changes require a versioned endpoint path (e.g., /v2).

Additive changes first

New fields are added without breaking existing clients wherever possible.

Explicit semantics

Decision values, enforcement rules, and replay constraints are documented in the API reference.

Migration guidance

When versions change, migration notes describe diffs and recommended rollout sequencing.

Changelog

Product updates

High-signal changes only—no noise.

v1.0.0 · Initial public release

Release

•Presence-bound challenge → UP+UV verify → receipt model

•Action-hash binding and non-replayable challenge semantics

•Portal billing + API keys + usage metering

•Optional portable proof export model for audit workflows

Enterprise change review

Enterprises can request change review expectations, environment separation guidance, and rollout sequencing via /enterprise.