Governance KPIs

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

Governance KPIs are five platform-health metrics that measure how effectively your organization is adopting and operating governed AI workloads. They are computed continuously from existing execution, evaluation, release, and evidence data — no separate instrumentation required.

What Are Governance KPIs

Each KPI answers a specific operational question about the health of your AI governance posture. Together they give platform operators an at-a-glance view of adoption speed, audit readiness, release quality, deployment stability, and incident response time.

KPIs are available through four interfaces:

• Portal dashboard — Overview › KPIs (/overview?tab=kpis) with color-coded status cards
• REST API — GET /v1/metrics/kpis
• Python SDK — client.metrics.get_kpis()
• CLI — orqestractl metrics kpis

All KPIs support a configurable time window (7, 30, or 90 days) and an optional per-workload filter.

The 5 KPIs

Time to First Governed Workflow

What it measures: The average number of days between when a workload is created and when it first executes under a policy-governed context (i.e., with an active policy bundle attached and at least one governed execution recorded).

Why it matters: A long time-to-first-governed-workflow indicates that teams are creating workloads but not completing the governance onboarding steps — policy attachment, release gating, and activation. It is the primary adoption-speed signal.

Target: ≤ 7 days

A value above 7 days typically points to friction in the policy attachment or release workflow. Review whether teams have access to the right policy bundles, and whether template-based onboarding is available for common workload patterns.

Evidence Completeness

What it measures: The percentage of executions that have both a policy decision record and at least one associated evidence artifact (e.g., a policy decision log, an evaluation result, or an audit trail entry).

Why it matters: Evidence completeness is the primary audit-readiness signal. Regulators and auditors require that every consequential AI decision be traceable. Gaps indicate executions that ran outside governance coverage — either missing policy attachment or evidence collection failures.

Target: ≥ 90%

A value below 90% should trigger an investigation into which workloads or execution paths are missing evidence. Use the Evidence Graph to identify incomplete chains.

Release Gate Pass Rate

What it measures: The percentage of evaluation suites that pass on the first attempt, across all releases within the selected window.

Why it matters: A high first-attempt pass rate indicates that workload authors are submitting well-prepared releases with flows and prompts that already meet evaluation thresholds. A low rate indicates rework cycles, which slow delivery and may signal model or prompt quality issues.

Target: ≥ 80%

If the pass rate falls below 80%, examine which suites are failing most often and whether the configured thresholds are appropriately calibrated. See Evaluation Gates for gate configuration options.

Rollback Frequency

What it measures: The percentage of releases that were activated (reached active state) and subsequently rolled back within the selected window.

Why it matters: Rollback frequency is the primary deployment stability signal. Frequent rollbacks indicate that releases are passing evaluation and approval but failing in production — pointing to distribution shift, environment differences, or insufficient evaluation coverage.

Target: ≤ 10%

A rate above 10% warrants a review of whether evaluation suites adequately reflect production traffic patterns. See Safe Rollout for canary and progressive rollout options that reduce rollback risk.

Median Rollback Response Time

What it measures: The median time in seconds between when a rollback is triggered and when the rollback completes (the release returns to a non-active state and traffic is re-routed).

Why it matters: Fast rollback response time limits the blast radius of a bad deployment. This KPI measures operational readiness — whether automated rollback is configured, whether operators are monitoring alerts, and whether the rollback path is free of manual bottlenecks.

Target: ≤ 1800 seconds (30 minutes)

A median above 30 minutes indicates that rollbacks are predominantly manual or that automation is not configured. Enable automated rollback triggers in the Safe Rollout configuration to improve this metric.

Portal Dashboard

The governance KPI dashboard is the Overview › KPIs (/overview?tab=kpis) tab. It displays five KPI cards, each showing the current value, its color-coded status, and a sparkline for the selected time window.

Color coding:

Controls:

• Window selector — Switch between 7-day, 30-day, and 90-day views. The selected window applies to all five KPI cards simultaneously.
• Workload filter — Optionally scope all KPIs to a single workload (workload_id) to investigate a specific application’s governance health.

Clicking any KPI card opens a detail panel with a time-series chart and a breakdown by workload, showing which applications are driving the metric in either direction.

Threshold Reference

The table below defines the green, yellow, and red thresholds for each KPI.

API

Fetch all five KPIs in a single request:

curl "http://localhost:8000/v1/metrics/kpis?window_days=30&workload_id=wl-abc123"

Response (200 OK):

{
  "window_days": 30,
  "workload_id": null,
  "computed_at": "2026-04-11T09:00:00Z",
  "kpis": {
    "time_to_first_governed_workflow_days": 4.2,
    "evidence_completeness": 0.931,
    "release_gate_pass_rate": 0.764,
    "rollback_frequency": 0.083,
    "median_rollback_response_seconds": 940
  }
}

kpis is a flat dict[str, float | None]. Values are null when there is insufficient data in the requested window (for example, no activations for rollback_frequency). The portal applies the threshold table above to colour-code each KPI — the API returns raw values only.

SDK

from orqestra_sdk import OrqestraClient
 
async with OrqestraClient("http://localhost:8000") as client:
    # Fetch all KPIs for the past 30 days (all workloads)
    kpis = await client.metrics.get_kpis(window_days=30)
 
    # Fetch KPIs scoped to a specific workload
    kpis = await client.metrics.get_kpis(window_days=7, workload_id="wl-abc123")
 
    # kpis["kpis"] is a plain dict[str, float | None]
    print(kpis["kpis"]["evidence_completeness"])          # 0.931
    print(kpis["kpis"]["release_gate_pass_rate"])         # 0.764
    print(kpis["kpis"]["median_rollback_response_seconds"])  # 940

Method signature:

client.metrics.get_kpis(
    window_days: int = 30,       # 7, 30, or 90
    workload_id: str | None = None,   # Filter to a single workload
) -> dict  # See GovernanceKpisResponse schema above

CLI

# Fetch all KPIs for the past 30 days
orqestractl metrics kpis
 
# Use a custom time window
orqestractl metrics kpis --window 7
 
# Scope to a specific workload
orqestractl metrics kpis --window 90 --workload wl-abc123

Flags:

Sample output:

Governance KPIs  (window: 30d, scope: all workloads)
─────────────────────────────────────────────────────────────────
  time_to_first_governed_workflow_days    4.2     target ≤ 7 days
  evidence_completeness                   0.931   target ≥ 0.90
  release_gate_pass_rate                  0.764   target ≥ 0.80
  rollback_frequency                      0.083   target ≤ 0.10
  median_rollback_response_seconds        940     target ≤ 1800
─────────────────────────────────────────────────────────────────
Computed at: 2026-04-11T09:00:00Z

Related

• Evidence Graph — Trace evidence chains for individual executions.
• Evaluation Gates — Configure pass-rate thresholds and gate positions.
• Safe Rollout — Canary rollout and automated rollback configuration.
• Policies — Policy bundles and how they govern workloads.
• Observability & Cost — Execution-level metrics and cost tracking.