Scoring reference

The weighted rollup, the order constraints are applied in, the Validated Coverage Score and the prioritisation arithmetic.

Rollup

domain_score   = Σ(sub_weight × sub_score) / Σ(sub_weight)     over in-scope sub-capabilities
overall_score  = Σ(domain_weight × domain_score) / Σ(domain_weight)

Sub-capabilities marked not applicable are excluded from both numerator and denominator. Scoping something out neither helps nor harms the score — it removes it.

Order of operations

The order is causal, not arbitrary: strategy directs telemetry, telemetry carries detection, and validation proves it. Each constraint caps the thing that depends on it, so they are applied in that sequence.

C3 at sub-capability level — a score of 4 or 5 with no named evidence becomes 3.
Compute raw domain scores.
C4 — cap DC and DE at max(TI, TM) + 1.
C2 — cap DE at adjusted DC + 1.
C1 — cap every other domain at adjusted AV + 1.
Compute the overall score from adjusted domain scores.
Report the unadjusted score, the adjusted score, and every adjustment.

Every constraint is a ceiling: it may lower a domain score and may never raise one. C2 in particular is measured against the already-adjusted DC, not the raw figure — against the raw figure it could restore a score C4 had just removed.

The constraints

ID	Name	Rule	Why
C1	Validation ceiling	No domain > AV + 1	An untested capability is an assumed capability. The one-level margin acknowledges a capability can be well-built before it is validated — but only just.
C2	Visibility ceiling	DE ≤ adjusted DC + 1	Detection logic cannot outperform its inputs.
C3	Evidence rule	4 or 5 without a named artefact → 3	In any process where an unevidenced claim scores the same as an evidenced one, assertion drives out evidence.
C4	Intent ceiling	DC and DE ≤ max(TI, TM) + 1	Sensors and content without architectural intent produce noise, not defence. Collecting more and writing more cannot substitute for knowing who you are defending against and how they would move.
C5	Inherited intent ceiling	TI.2 ≤ 2 where the adversary set was accepted from the suggested threat profile unmodified	TI.2 asks who you are defending against and how you know. If the tool answered it, you inherited the answer rather than producing it. A model that supplies its own input and then scores you on it is grading its own homework.

strict: false disables all of them. Use it only to see the raw self-assessment; never report a non-strict score externally.

What C5 changes in practice

C5 is the only constraint that reads provenance rather than scores. It is applied at sub-capability level, to TI.2 alone, because how the actor list was produced says nothing about the rest of an organisation's intelligence capability — capping the whole TI domain would punish capabilities the provenance is silent on.

Three values are recognised:

`actor_provenance`	Meaning	C5
`suggested`	Accepted from the suggested threat profile, unmodified	TI.2 capped at 2
`reviewed`	Suggested, then added to, removed from, or reasoned about	Not applied
`declared`	Chosen without using the suggestion	Not applied

The ceiling lifts on any engagement with the list: adding an adversary the suggestion missed, removing one that does not apply, or recording why one was accepted. All three are threat intelligence work. The constraint exists so that not doing that work cannot look identical to doing it.

What C4 changes in practice

An organisation with strong telemetry and a large rule estate, but no threat intelligence input and no attack-path modelling, is the case C4 exists for. With TI and TM at 0, both DC and DE are held at 1 however much has been spent on them. It is usually the single most uncomfortable number in an assessment, and the most useful.

Bands

Score	Band	In practice
0.00–0.99	L0 Absent	A build project, not an improvement project
1.00–1.99	L1 Ad hoc	Capability lives in individuals; it will not survive their departure
2.00–2.99	L2 Repeatable	The most populated band, and where spending most often outruns capability
3.00–3.99	L3 Threat-Informed	A credible target for most organisations
4.00–4.99	L4 Measured & Validated	Realistic only with a standing validation function
5.00	L5 Adaptive	Rare. Treat with scepticism unless the evidence is exceptional

Validated Coverage Score

VCS = Σ(status) / (3 × count(in-scope techniques))

Status	Meaning	Requires
0	No telemetry	The activity generates no record you collect
1	Telemetry only	Data exists and is queryable; nothing alerts
2	Detection logic exists	A rule or analytic is deployed and healthy, but unproven
3	Validated by emulation	Behaviour executed, detection observed to fire, within the recency window

Always report the in-scope count beside the score. Status 3 expires — a result older than your defined review window drops to 2.

Report alongside the domain scores, never instead of them.

Prioritisation

impact = (domain_weight / 100) × (sub_weight / 100) × gap_to_target × 1000

Mechanical by design: it prevents the roadmap being driven by whoever argued hardest. It produces the counter-intuitive but usually correct result that a two-level gap in a heavily weighted sub-capability outranks a four-level gap in a light one.

The ranking is a starting point, not an instruction. Dependencies matter — improving DE before fixing DC wastes effort, which is why C2 exists. Read the constraint log alongside the roadmap.

Setting targets

Set targets per domain, not globally. Defensible target for a well-resourced enterprise: 3.5–4.0 overall, with AV at 4.0+ so it stops being the binding constraint. For a smaller organisation, 2.5–3.0 over an honest, narrow in-scope set is a stronger position than 3.5 over a scope chosen to flatter.

Level 5 is not a target for most organisations. Treating it as one produces theatre.