Scorecard use-cases

Scorecards help you track compliance, enforce standards, and maintain quality across your software catalog. This page demonstrates practical scorecard examples and automations that respond to scorecard rule result changes.

Most of the examples below are compliance patterns meant for humans to review on a dashboard. But a scorecard can just as easily act as a guardrail an agent checks before it's allowed to act - not a metric, but a pass/fail gate.

Ownership scorecard

The following example demonstrates an ownership scorecard.

It has one filter defined:

• Only evaluate entities that are related to production (indicated by checking that the is_production property is set to true).

It has two rules:

• Check that a defined on-call exists and that the number of open_incidents is lower than 5.
• Check if a team exists.

Ownership scorecard definition (click to expand)

{
  "identifier": "ownership",
  "title": "Ownership",
  "filter": {
      "combinator": "and",
      "conditions": [
        {
          "property": "is_production",
          "operator": "=",
          "value": true
        }
      ]
    },
  "rules": [
      {
        "title": "Has on call?",
        "identifier": "has_on_call",
        "level": "Gold",
        "query": {
          "combinator": "and",
          "conditions": [
            {
              "operator": "isNotEmpty",
              "property": "on_call"
            },
            {
              "operator": "<",
              "property": "open_incidents",
              "value": 5
            }
          ]
        }
      },
      {
        "title": "Has a team?",
        "identifier": "has_team",
        "level": "Silver",
        "query": {
          "combinator": "and",
          "conditions": [
            {
              "operator": "isNotEmpty",
              "relation": "team"
            }
          ]
        }
      }
  ],
  "levels": [
    {
      "color": "paleBlue",
      "title": "Basic"
    },
    {
      "color": "bronze",
      "title": "Bronze"
    },
    {
      "color": "silver",
      "title": "Silver"
    },
    {
      "color": "gold",
      "title": "Gold"
    }
  ]
}

---

Ensure relation existence

Say we have a service blueprint that has a relation to another blueprint named domain.
We can define a scorecard that checks that all of our services have a related domain. Services with empty domain relations will fail this check:

Ensure relation existence scorecard definition (click to expand)

{
  "identifier": "domain_definition",
  "title": "Domain definition",
  "rules": [
    {
      "identifier": "hasDomain",
      "title": "Has domain",
      "level": "Bronze",
      "query": {
        "combinator": "and",
        "conditions": [
          {
            "operator": "isNotEmpty",
            "relation": "domain"
          }
        ]
      }
    }
  ],
  "levels": [
    {
      "color": "paleBlue",
      "title": "Basic"
    },
    {
      "color": "bronze",
      "title": "Bronze"
    },
    {
      "color": "silver",
      "title": "Silver"
    },
    {
      "color": "gold",
      "title": "Gold"
    }
  ]
}

---

DORA metrics based on number of deployments

To assess the deployment frequency of a service, simply checking the deployment relation is not enough — we need to know the exact number of deployments. To achieve this, we can:

• Add an aggregation property to the service blueprint that counts the number of related deployment entities.
• Add a scorecard with a rule based on the new aggregation property:

DORA metrics scorecard definition (click to expand)

{
  "identifier": "dora_metrics",
  "title": "DORA Metrics",
  "rules": [
    {
      "identifier": "deployFreqBronze",
      "title": "Deployment frequency > 2",
      "level": "Bronze",
      "query": {
        "combinator": "and",
        "conditions": [
          {
            "operator": ">",
            "property": "deployment_frequency",
            "value": 3
          }
        ]
      }
    },
    {
      "identifier": "deployFreqSilver",
      "title": "Deployment frequency > 4",
      "level": "Silver",
      "query": {
        "combinator": "and",
        "conditions": [
          {
            "operator": ">",
            "property": "deployment_frequency",
            "value": 4
          }
        ]
      }
    }
  ],
  "levels": [
    {
      "color": "paleBlue",
      "title": "Basic"
    },
    {
      "color": "bronze",
      "title": "Bronze"
    },
    {
      "color": "silver",
      "title": "Silver"
    },
    {
      "color": "gold",
      "title": "Gold"
    }
  ]
}

---

Agent dispatch guardrail

Say we want an AI agent to only work on a service when its on-call owner is set and its test suite is passing reliably. We can define a scorecard where the only way to reach a passing level is by satisfying both conditions together:

Agent dispatch guardrail scorecard definition (click to expand)

{
  "identifier": "agent_dispatch_readiness",
  "title": "Agent dispatch readiness",
  "rules": [
    {
      "identifier": "safeForAgentDispatch",
      "title": "Safe for agent dispatch",
      "level": "Bronze",
      "query": {
        "combinator": "and",
        "conditions": [
          {
            "operator": "isNotEmpty",
            "property": "on_call"
          },
          {
            "operator": ">",
            "property": "test_pass_rate",
            "value": 95
          }
        ]
      }
    }
  ],
  "levels": [
    {
      "color": "paleBlue",
      "title": "Basic"
    },
    {
      "color": "bronze",
      "title": "Bronze"
    },
    {
      "color": "silver",
      "title": "Silver"
    },
    {
      "color": "gold",
      "title": "Gold"
    }
  ]
}

Unlike the previous examples, this scorecard isn't meant to be read from a dashboard - it's meant to be checked before an agent is dispatched.

Every entity exposes its scorecard results under a scorecards field, the same way it exposes its properties.
This way, a workflow that reacts to changes on the service (using an ENTITY_UPDATED trigger) can read that field straight off the updated entity.

Add a condition node that evaluates this expression, so the workflow only proceeds to the AI agent step when the guardrail passes:

Condition node configuration (click to expand)

{
  "identifier": "check-agent-dispatch-guardrail",
  "title": "Check agent dispatch guardrail",
  "config": {
    "type": "CONDITION",
    "options": [
      {
        "identifier": "safe",
        "title": "Safe for agent",
        "expression": ".outputs.trigger.diff.after.scorecards.agent_dispatch_readiness.level == \"Bronze\""
      }
    ]
  }
}

Then wire the node's safe option to the AI agent step, and use a fallback connection to route everything else - services that haven't met the guardrail - to a human instead:

Connections configuration (click to expand)

{
  "connections": [
    {
      "sourceIdentifier": "check-agent-dispatch-guardrail",
      "targetIdentifier": "dispatch-ai-agent",
      "sourceOptionIdentifier": "safe"
    },
    {
      "sourceIdentifier": "check-agent-dispatch-guardrail",
      "targetIdentifier": "notify-on-call-human",
      "fallback": true
    }
  ]
}

With this wiring, the AI agent node only ever runs on services that satisfy both conditions in the scorecard. Everything else - missing on-call, low test pass rate, or both - falls back to a human, instead of silently letting the agent proceed on a service that isn't ready for it.

---

For more advanced use cases that include extending the scorecard's data model, see the extend the default scorecards page, which shows how to extend the scorecard data model with additional properties to enable SLA tracking, due date management, and automated workflows that go beyond simple pass or fail compliance.