IO Domain Registry Schema

Machine-readable structure for the eight IO domains, their dimensions, and most importantly, how a dimension with no evidence is represented so that it cannot band, score, or contribute.

The registry is an IO product schema, not an industry framework. An IO domain is not a C2M2 domain and is not a NIST CSF Function. IO domains may organise evidence relevant to NIST CSF, C2M2 or ISO requirements, but they are not replacements for those structures and do not inherit their coverage.

Document v3.4 · Registry/model version v0.3. v0.3 renames the top-level classification from capability area to domain. That rename is a model change, not evidence of operational improvement, and any movement in a published figure across this boundary must be labelled as such.

Performance is not maturity

This registry produces domain performance scores from measured dimensions. It does not produce IO maturity levels. The maturity model is practice-based, all-or-nothing and reported as assured level, distribution and binding constraint. The performance score below is weighted because its dimensions share a declared scoring scale; maturity gates are never averaged.

Product surfaces must label the result domain performance score and, if bands are shown, domain performance band. The labels maturity score and maturity band are reserved and must not be used for this registry output. Movement in a domain performance score is never described as a change in maturity.

The eight IO domains

{
  "version": "0.3",
  "status": "pre-normative",
  "terminology": "domain",
  "domains": [
    { "domain_id": "human_risk",           "domain_name": "Human Risk" },
    { "domain_id": "threat_detection",     "domain_name": "Threat Detection" },
    { "domain_id": "ai_governance",        "domain_name": "AI Governance" },
    { "domain_id": "policy_governance",    "domain_name": "Policy & Governance" },
    { "domain_id": "resiliency",           "domain_name": "Resiliency" },
    { "domain_id": "assurance_compliance", "domain_name": "Assurance & Compliance" },
    { "domain_id": "third_party_risk",     "domain_name": "Third-Party Risk" },
    { "domain_id": "physical_security",    "domain_name": "Physical Security" }
  ]
}

Eight identifiers are defined above because eight are claimed. A registry that claims eight and defines seven is a defect, not a rounding.

Security Culture and Training & Awareness are not domains. They are dimension groups inside Human Risk, because they measure the same population through the same interventions and scoring them separately produced three numbers describing one thing.

The browser sensor is not a domain. It is platform infrastructure feeding other domains, and presenting it as a peer domain would double-count its evidence.

Terminology migration and backward compatibility

v0.3 canonical field language, to be used in all new records and public outputs:

Rules:

• v0.3 uses domain as the canonical term.
• Legacy area, area_id and capability_area fields may be read for backward compatibility. A reader must accept either spelling for the same record and resolve it to the canonical identifier.
• New records and public outputs use the canonical domain terminology.
• Stored data, existing URLs, screenshots and application references are not rewritten in place. Where a legacy field is retained on the wire, it is an alias, and the alias is declared in the payload:

{
  "version": "0.3",
  "compatibility": { "reads_legacy_fields": ["areas", "area_id", "capability_area"] }
}

• A terminology or schema-version change is a model change. It must never be reported as improvement, regression or operational movement.

Dimension shape

{
  "id": "speak_up_rate",
  "domain_id": "human_risk",
  "group": "culture_reported",
  "weight": 13,
  "numerator": "reported_suspicious",
  "denominator": "reported_suspicious + fell_for",
  "window_days": 90,
  "direction": "higher_is_better",
  "state": "measured",
  "value": 0.62,
  "source_coverage": 0.96,
  "record_completeness": 0.91,
  "confidence": "high",
  "model_version": "0.3"
}

Physical Security dimensions

These are the canonical Physical Security dimensions as used by the Atlas demonstration tenant. They are listed here so a second, conflicting taxonomy is not created elsewhere.

Physical Security results are reported as domain performance and verification outcomes. They are not a Physical Security maturity finding; see the maturity-model boundary documents.

The state field is the important one

"state": "measured" | "not_measured"

A dimension in state not_measured must:

• carry no value
• carry no band
• be excluded from the domain's weighted denominator entirely
• carry a reason

{
  "id": "third_party_offboarding_latency",
  "domain_id": "third_party_risk",
  "weight": 10,
  "state": "not_measured",
  "reason": "zero_denominator",
  "value": null,
  "band": null
}

Permitted reasons: zero_denominator · source_not_connected · window_incomplete · minimum_sample_not_met · source_impaired · not_computable_for_domain.

Why this field exists

A zero denominator is arithmetically undefined and will be coerced by any language that is not stopped from coercing it. Depending on the expression, it resolves to zero, to one, or to NaN, which means the same missing evidence can read as worst possible in one dimension and best possible in another, inside the same assessment.

During internal validation, that defect was found in this product. Correcting it moved domain performance scores in both directions, sometimes by more than twenty points, because dimensions with no evidence had been silently contributing. The largest single correction took a domain from mid-pack to the weakest in the tenant.

The schema therefore does not treat the absent state as a value to be handled. It treats it as a distinct state that the scoring path must branch on, and a dimension in that state never reaches the arithmetic.

Domain rollup

{
  "domain_id": "threat_detection",
  "domain_performance_score": 29,
  "domain_performance_band": "developing",
  "dimensions_measured": 7,
  "dimensions_not_measured": 2,
  "weight_measured": 78,
  "weight_total": 100,
  "model_version": "0.3"
}

Report dimensions_not_measured beside the score, always. A score of 29 computed across seven of nine dimensions is a different claim from a score of 29 computed across all nine, and a reader given only the number cannot tell which they are looking at.

Where weight_measured falls below a published floor, the domain returns no score at all and reports not yet assessable with the missing dimensions named.

The coverage floor must be stored in the registry version rather than supplied by the tenant. Until a floor is published, a score may be displayed only with its measured weight and an explicit pre-normative label.

Aggregation guardrails

• Every dimension records source coverage, record completeness, confidence and model version independently of its value.
• A high score with limited coverage is not promoted to a high-confidence finding.
• Dimensions may be aggregated only when their normalization and weights have a published rationale. Shared scale does not by itself establish comparability.
• The enterprise view reports the eight domain results as a profile, with domains_not_measured named. It does not average them into a single “security score,” and it never averages domain maturity levels.
• Changes caused by schema, weighting, terminology or threshold versions are labelled model changes, not operational improvement.

Industry relationship

NIST CSF 2.0 provides outcome vocabulary; C2M2 v2.1 provides maturity practices and institutionalisation concepts, including its own, separate notion of a C2M2 domain; ISO management-system standards provide governance context. The registry provides none of their formal results. Its job is to make IO's own measurement state explicit and reconstructable.