Evaluation Models

The Evaluation Models module is where you define how scoring works across your governance program. A risk matrix, a maturity model, a compliance posture scale, a control effectiveness rating, an impact ladder: each is one evaluation model, defined once, then reused everywhere your organization needs to assign a score.

Without this module, every assessment and every monitor would either reinvent its own labels or be forced into a one-size-fits-all rating that doesn’t match how your organization actually thinks. With it, you define low, medium, high once (or whatever scale you use), and Risks, Assessments, Controls, Monitors, and Indicators all draw from the same vocabulary.

When you would reach for this

You set up evaluation models when:

• A framework you operate under expects you to score against a specific scale (a 5-level maturity model, a 4×4 risk matrix, a stoplight compliance rating).
• Your organization has a standard rating vocabulary it wants every assessment to use consistently.
• You need to reconcile scores between two frameworks that use different vocabularies (one says “tier 1 / 2 / 3 / 4”, another says “low / medium / high”); evaluation model mappings bridge them.
• You want auditors to see exactly what scale a historical assessment was scored on, even years later, even if your current scale has changed.

You don’t reach for this when actually scoring a single record. That happens inside Assessments, Risks, Monitoring, or Indicators, each of which picks an evaluation model to score against. The Evaluation Models module is where the shape of the score itself lives.

What lives in an evaluation model

Four record types, building on each other:

1. Evaluation model is the top-level scoring concept (“Control maturity model”, “Inherent risk matrix”, “Compliance posture”). It has a name, a stable key, a kind, and an optional owner.
2. Model version is a specific revision of the model. Models evolve; a 2024 risk matrix and a 2026 risk matrix can both exist, each with its own scale values. Each version has its own lifecycle (draft, active, retired) and only one version is the active version at a time.
3. Model mappings translate one version of one model into another version of another model (or another version of the same model). When you migrate from an old maturity model to a new one, the mapping captures “Level 3 in the old model maps to Level 4 in the new model.” Mappings preserve historical comparability without re-scoring every old record.
4. Result projections are normalized projections of a framework-native score into your organization’s canonical vocabulary. When an external framework says “Tier 2” and your organization’s standard scale says “Medium”, the projection records both, side by side, so dashboards work on the canonical value while audits can verify against the framework-native value.

Model kinds

When you create an evaluation model, you mark it with a kind describing what it scores. Common kinds:

Kind is free text; use what fits your vocabulary.

A worked example: an insurance group standardizes its risk and maturity scoring

A multi-line insurance group has six business units that each developed their own way of scoring risks and control maturity over the years. Some use a 1-5 likelihood scale, some use a 4-tier ladder; some call high-severity findings “critical”, some call them “P1”. An auditor pointed out that aggregating across business units is unreliable because the scales don’t match. The group’s chief risk officer, Elena, decides to standardize through Evaluation Models.

Step 1: define the canonical risk matrix. Elena creates an evaluation model inherent-risk-matrix, kind likelihood × impact. She adds a version v1 and configures it as a 5×5 matrix: likelihood scale of very-low / low / medium / high / very-high, impact scale of the same, and a 25-cell matrix mapping each combination to a risk rating (low, medium, high, critical). She activates v1.

Step 2: define the canonical control maturity model. A second evaluation model control-maturity, kind maturity. Five levels: initial / repeatable / defined / managed / optimized, each with a numeric weight, a color for dashboards, and a one-sentence description of what it means.

Step 3: define the compliance posture model. A third model compliance-posture, kind compliance. Three tiers: non-compliant, partial, compliant, plus an unknown value for cases where no evidence has been reviewed yet.

Step 4: map the legacy scales. Two business units had their own 4-level maturity ladder. Elena creates a mapping from each legacy version to the new canonical control-maturity v1, so that previously-scored controls can be re-projected into the new scale without anyone re-scoring them.

Step 5: framework-native vs canonical for cross-framework reporting. One of the frameworks the group is certified against uses an alphabetic rating (A through D) for control effectiveness. The framework requires Elena to preserve the alphabetic rating on the certified record. So she creates a projection model that captures both: the framework-native letter and the canonical 5-level rating. Audit reviewers see both; cross-framework dashboards work on the canonical value.

Step 6: the rest of the system uses these models. When the risk team scores a new risk in Risks, they pick inherent-risk-matrix v1 from a dropdown. When the controls team scores a control assessment in Assessments, they pick control-maturity v1. Six months later, every assessment and every risk in the workspace uses the same vocabulary, and the auditor’s complaint is gone.

When the canonical maturity model needs to evolve (say, to add a sixth pioneering level), Elena creates control-maturity v2, maps v1 to v2, and activates v2. Historical records remain scored against v1; new work uses v2. The mapping makes them comparable.

What you’ll see in the product

Evaluation Models lives under Governance → Evaluation Models in the workspace.

The Evaluation Models list shows every model you’ve defined, with their current active version, their kind, and how many records reference them.

Inside a model, you see its versions, the active one highlighted. Versions are sorted by creation time; older versions stay readable for historical context.

Inside a version, you see the scales, tiers, weights, matrices, and formulas that define how the model scores. The version is intentionally a structured JSON-shaped surface; the in-product editor walks you through scale values, ordering, weights, and matrix cells.

Mappings are a separate tab showing all the mappings into or out of this model. You can navigate from one model’s mapping to the related model and back.

Every change is captured in the workspace Audit Log.

Active version

At any time, exactly one version of a model is active. When other modules ask “which version do I score against?”, they get the active one. Activating a new version is a deliberate, audited action; it does not retroactively re-score old records (those keep their original version reference for audit fidelity).

You can think of activation as “this is the current version for new work” rather than “this is the only version that exists.”

Framework-native vs canonical

When you adopt a framework, that framework probably has its own rating vocabulary. You have two choices:

• Use the framework-native vocabulary directly. Create an evaluation model that mirrors the framework’s scale. Pros: scoring matches the framework’s expectations exactly. Cons: cross-framework comparison is harder.
• Use a canonical vocabulary and map. Define your organization’s canonical scale, then create a mapping from the framework-native scale into the canonical one. Result projections capture both values so the framework-native record is preserved for the auditor while the canonical record drives dashboards.

Many organizations do both: framework-native models for compliance recordkeeping, canonical models for board reporting, mappings between them.

Common workflows

Defining a new evaluation model

1. Evaluation Models → New evaluation model. Name it, pick a kind.
2. Inside the model → New version. Add the scale values, weights, matrix cells (if applicable).
3. Mark the version as active once it’s reviewed.
4. Other modules can now score against it.

Evolving a model

1. Inside the model, create a new version.
2. Add or modify scale values, weights, matrix cells.
3. Create a mapping from the previous version to the new one.
4. Mark the new version as active.
5. New scoring uses the new version; old records remain on the old version.

Reconciling two frameworks

1. Create both framework-native models.
2. Create a canonical organization-level model.
3. Create mappings from each framework-native model to the canonical model.
4. Score new work in the framework-native model; the system creates a canonical projection automatically.
5. Cross-framework dashboards work on the canonical projection.

Related

• Assessments - assessments score against an evaluation model.
• Risks - risks are scored against likelihood and impact models.
• Monitoring - monitor results aggregate against an evaluation model.
• Indicators - indicator measurements are interpreted against a model.
• Frameworks - frameworks may import their own native models.