Capability Status

Technical reference. This page is for integrations, advanced configuration, or platform operations. For portal tasks, start with the user guide.

Orqestra exposes a runtime capability registry so operators, developers, and docs can distinguish implemented surfaces from partial or planned surfaces. Use this guide when you need to answer: “Can I rely on this feature today, and which interfaces expose it?”

The registry is intentionally read-only. It describes product maturity; it does not enable or disable a capability by itself. Feature-gated capabilities also include enabled and gate_key fields so user interfaces can label gated surfaces correctly. SCIM and notifications are not env-gated: they are per-tenant settings (Administer › Access & org › Tenant settings, or orqestractl namespace settings), so their registry entries carry no gate_key.

Maturity States

Capability Areas

Query The Registry

API

# List every capability
curl http://localhost:8000/v1/capabilities
 
# Filter by area or state
curl "http://localhost:8000/v1/capabilities?area=recovery"
curl "http://localhost:8000/v1/capabilities?state=implemented"
 
# Inspect one capability
curl http://localhost:8000/v1/capabilities/execution-rerun
 
# Aggregate count by state
curl http://localhost:8000/v1/capabilities/summary

Capability metadata requires authentication, but it is not workspace-scoped. That is deliberate: capability maturity is platform metadata, not tenant data.

CLI

orqestractl capability list
orqestractl capability list --area recovery
orqestractl capability list --state implemented
orqestractl capability get secret-resolution
orqestractl capability summary

Python SDK

from orqestra_sdk import OrqestraClient
 
async with OrqestraClient("http://localhost:8000") as client:
    all_caps = await client.capabilities.list()
    recovery_caps = await client.capabilities.list(area="recovery")
    secret_resolution = await client.capabilities.get("secret-resolution")
    summary = await client.capabilities.summary()

Current Implemented Capabilities

The current registry classifies these capabilities as implemented.

Reading enabled And limitations

Most implemented capabilities return enabled: true. Gated capabilities include extra fields:

{
  "slug": "evaluation-llm-judge",
  "state": "implemented",
  "enabled": false,
  "gate_key": "evaluation-llm-judge"
}

Treat state and enabled separately:

• state says how mature the platform implementation is.
• enabled says whether the feature is active in this deployment.
• limitations says what a user or operator must still account for.

The evaluation-assistant-candidates entry also publishes typed generation_limits from the same server constants that enforce requests:

{
  "supported_asset_kinds": ["prompt_template"],
  "max_generated_specs_per_request": 5,
  "max_brief_chars": 4000,
  "max_session_candidates": 50
}

Operator Workflow

1. Run orqestractl capability summary during environment review.
2. Run orqestractl capability list --state partial and --state planned to identify unavailable product claims before onboarding a team.
3. For any gated capability, inspect enabled and gate_key.
4. Link the capability to its guide and scenario before promising it in a rollout plan.
5. Record explicit deferrals when a workflow depends on a partial or planned capability.

Documentation Rule

When a capability changes state, update all affected surfaces in the same work:

• capability registry entry
• user guide page
• API, SDK, CLI, or portal guide sections as applicable
• scenarios that rely on the capability
• changelog entry when the change is user-visible