Skip to main content
A capability is something this SDK build can do. In v1 that set is fixed: control-point reads and target registration.
The SDK capabilities namespace (get, list, invoke) was removed in v1 (ADR-0010). conformance/surface/control-points.surface.json asserts the client must not expose capabilities. Do not sniff versions or call capabilities.get(). See Migrate 2.1 to 2.3.

​
Why this page still exists

Language surfaces no longer diverge on the v1 path. All seven SDKs expose the same nine control-point methods and registerTarget. You do not need a discovery matrix to know whether registration exists. capabilities.features.flags remains true at the conformance / envelope boundary. Removing the OpenFeature dependency did not rename that pin. The product noun is still control point.

​
What v1 does not expose

Do not document console guardrail connectors, soak checks, or thresholds on this site. The SDK does not evaluate them.

​
UnsupportedCapability

The 15-kind error taxonomy still includes UnsupportedCapability (Errors). In v1 you see it when a custom adapter lacks registerTarget, or when InMemoryAdapter is asked to register a target. You do not see it from a guardrails stub — that stub is gone, so the import fails at build time.
Last modified on September 11, 2026