Computed key results

A computed Key Result connects an OKR metric directly to your live landscape data. Instead of a team member entering a number every week, a scheduled sweep reads the metric from the architecture model and records it as a check-in automatically. The result is an objective that reflects reality rather than whatever someone remembered to type.

Choosing a metric

Dependra ships 104 built-in metrics across 15 groups. When adding a Key Result, select Computed as the drive mode and browse the metric catalog.

Health & availability

Live signals from your component health pipeline. Useful for reliability objectives.

• Landscape health score, capability availability %, MTTR, uptime %, downtime hours

Incidents & SLA

Derived from the incident tracking model.

• Incident frequency, mean time to resolve, SLA breach count, SLA compliance rate, penalty exposure (currency), P1 incident count

Blast radius & resilience

Structural properties of the dependency graph.

• Single point of failure count, maximum chain depth, redundancy coverage %, resilience score

Risk

Scores from the latest resilience scan.

• Aggregate risk score, high/critical risk count, unmitigated risk count

Actor & revenue impact

Business impact values aggregated across capabilities and segments.

• Revenue at risk (currency), revenue lost to incidents (currency)

Technology & tech radar

Technology governance metrics.

• EOL technology count, tech debt ratio, tech standardization ratio, radar alignment, Eliminate-ring count, spend on Eliminate technologies

Portfolio TIME

Distribution of applications across the Gartner TIME quadrants.

• Classification coverage, Tolerate/Invest/Migrate/Eliminate counts, migration completion, apps retired in period

Lifecycle roadmap

Lifecycle state metrics.

• Components past end-of-life, approaching end-of-life, lifecycle coverage, planned retirements, on-track retirement rate

Data lineage & GDPR

Data governance derived from the dataset and dependency model.

• PII dataset count, cross-boundary data flow count, GDPR scope exposure, data classification coverage, lineage coverage

Documentation quality

Coverage metrics from the documentation model.

• Documentation coverage, README coverage, missing description count, component completeness score

Security & compliance

Security properties of the architecture.

• Authentication gap count, encryption gap count, internet-facing unencrypted component count, ownership gaps, tag coverage

Architecture & dependencies

Structural health of the dependency graph.

• Circular dependency count, coupling score, orphaned component count, API coverage, cross-zone dependencies

Cost & IT spend

Financial model aggregates.

• Total IT spend, cost per capability, cost per actor, cost delta over period

Process & governance

Process model metrics.

• Process documentation coverage, process maturity score, approval completion, ownership coverage

OKR rollup

Aggregates across the OKR model itself — useful for programme-level objectives rolling up child key results.

• Child KR rollups (average/sum/min/max, threshold count), check-in freshness, at-risk KR count, objective achievement rate, alignment coverage

Baseline locking

When you create a computed KR, Dependra locks the baseline at the metric’s current value as the KR’s start value. This matters for relative goals:

• A KR targeting “−20% relative to start” uses the value at creation time as the denominator — not some future recalculated baseline.
• Carrying a KR forward into a new cycle re-locks the baseline at the current value at carry-forward time.

Do not create a computed KR before your landscape data is reasonably representative. If you are mid-migration and half your components are not yet modelled, the baseline will be artificially low (or high) and the goal will not reflect the actual work.

Goal expressions

Because the progress formula is (current − start) / (target − start), you express goals as target values rather than percentages:

A KR goes above 100% if the metric overshoots the target in the right direction. It goes negative if the metric moves the wrong way.

Refresh cadence

The sweep runs hourly by default. This means:

• A freshly created computed KR may show no current value until the first sweep completes — up to one hour after creation.
• Check-ins recorded by the sweep appear in the KR’s history alongside any manual overrides.
• The sweep does not overwrite a manual check-in entered after the last sweep; manual entries and sweep entries coexist in history.

The sweep frequency is a platform-level setting, not configurable per KR. If you need sub-hourly precision, use the API push or Jira modes instead.

When to prefer computed vs manual

Prefer computed when:

• The metric exists in your landscape model already (health, incident, blast-radius, GDPR scope, cost).
• The team does not have a reliable weekly habit of entering numbers.
• The metric changes frequently enough that weekly manual check-ins would miss meaningful movement.
• You want an audit trail that cannot be gamed — the sweep is sourced from the architecture model, not a typed number.

Prefer manual when:

• The metric comes from a system outside Dependra (e.g., a customer satisfaction score, a survey result, a sales figure).
• The metric requires human judgement to assess (e.g., “team morale” or “stakeholder alignment”).
• The data is available only quarterly or on-demand — a weekly cadence with manual entries is more honest than a computed metric that changes every hour and creates noise.
• You are in early landscape setup and your model is not yet representative.

Prefer Jira when the metric is an issue count, story point sum, or custom numeric field from a Jira project. See Jira Key Results.

Prefer API push when the metric comes from an external system you control (Datadog, Salesforce, a CI pipeline, a custom report). See Push Key Result Values via API.