Capability Model Change Submission

Prepared by: Ben Wortley For: Nick (UN-GGCE), as input to the Robustness Testing Procedure discussion Purpose: Propose (A) a standing process for evolving the State of Geodesy capability model over time, including a semantic (not lexical) matching step — (B) three capability additions and one genuinely open question this process produced while reviewing how ROBUSTNESS_TESTING_PROCEDURE_v1.6's Functions relate to the existing 58-capability set, (C) a scoring-unit clarification for Governance and Strategy capabilities, and (D) the same reconciliation finding applied to WP9's target-state "Components" rollup — offered as the first real test case of that process, not a one-off request.

---

A. A standing process for capability model changes

The State of Geodesy capability model is a published, versioned artifact (data/shacl/ggsc-capability-maturity.databook.md, currently v1.4.0). It has never had a formal change process — additions and corrections so far have happened as one-off score revisions against the published report. That's been adequate for correcting scores; it isn't adequate for adding or restructuring capabilities, which is a different kind of change and needs a different kind of scrutiny.

Trigger. A capability gap is most reliably surfaced exactly where WP4 of the Robustness Testing Procedure already requires it: mapping applicable capabilities to a real function (Section 10, WP4) or scoring a function's required capabilities (WP5). When a TPWG can point to a real, specific production step that no existing capability covers, that's a submission, not a workaround — the current draft's habit of naming an informal capability in a worked example ("combination processing," Section 10.2) rather than raising the gap is exactly what this process should replace.

The matching step has to be semantic, not lexical, before "no match" is a real finding. Checking a function against the capability label list (what this document did initially) only proves a word isn't there — it doesn't prove the concept isn't covered. The correct sequence, and this is standard BIZBOK practice (capability-to-value-stream mapping, capability-to-organisation mapping — cross-mapping matrices between the core blueprints, not something invented for this engagement):

1. The TPWG describes the function in enough plain-language detail to be checked — what it does, what triggers it, what it produces — not just a name.
2. That description is compared against the full evidence summary / definition of every candidate capability, not the label alone, including capabilities in domains that wouldn't be an obvious first guess.
3. The function is cross-checked against the Organisation/Facility-type model (Primitive 5) at the same time, so "who/where does this" and "what competency does this need" are confirmed together, not just the latter.
4. One function may genuinely require two or more capabilities, and that's the expected outcome, not a sign something's wrong — Nick's own document already states this ("several capabilities may be required by one function"), it just hasn't been applied rigorously in practice (see B.1 below, where doing this properly changed the finding).
5. Only once steps 1–3 find no semantic match — not just no label match — is a capability genuinely missing. Where a partial match exists but the existing capability's definition is too coarse to surface a specific, critical sub-risk, the right fix may be deepening that capability's evidence summary rather than adding a new one — a fifth submission type, alongside addition/merge/split, worth naming explicitly below.

Submission content, per proposed change:

• Proposed capability name and one-line definition.
• Proposed domain and subdomain placement (one of the 6 existing domains, or a case for a new one).
• Evidence: which products/functions actually require it, and why none of the 58 existing capabilities cover it — checked against the full label list, not assumed.
• Type: addition, merge of existing capabilities, split of an existing one that's covering more than one real competency, or definition deepening — an existing capability semantically covers the function, but its evidence summary is too generic to surface a specific, critical sub-risk the assessment needs to test.
• Where relevant, draft PPTD (People/Process/Technology/Data) level 1–5 definitions, in the style of Annex A.2's existing table, so the capability is usable for scoring immediately if ratified.

Review and ratification. Mirrors the TPWG ratification pattern already in the Robustness Testing Procedure rather than inventing a new governance layer: the TPWG(s) for the affected product(s) review and either ratify, reject, or request revision, with written sign-off — the same discipline already applied to required maturity and criticality. Cross-product changes (like most of the additions below, several of which touch three or more products) should get sign-off from each affected TPWG, not just one.

Versioning. Each ratified change bumps the capability model's version and is logged with rationale — same discipline as this document's own Annex B changelog, and the same pattern already used in the capability maturity DataBook's own version history.

Cadence. No need for a standing committee: submissions can happen whenever WP4/WP5 surfaces one, batched for ratification at natural checkpoints — WP1 kickoff (to clear any backlog before elicitation starts) and the existing annual capability maturity validation cycle (Section 23 of the Robustness Testing Procedure already sets this cadence for scores; extending it to cover structural changes is a small addition, not a new mechanism).

---

B. One open question and three proposed additions

The first two candidates were surfaced by checking Nick's illustrative Function verbs (observe, transmit, archive, analyse, combine, validate, disseminate — Section 2.4) against the full, current 58-capability label list. Five of the seven verbs map cleanly onto existing capabilities. Two didn't lexically match — but applying the semantic-matching step from Section A to those two produced different outcomes for each, which is exactly why that step matters: B.1 turned out to be a genuine open question, not a clean gap, once checked against full capability definitions rather than labels. B.2 held up. B.3 was surfaced separately, from direct engagement experience, and is evidenced differently. B.4 was surfaced from reconciling WP9's "Components" rollup against the real model (Section D) and is independently corroborated by a named, sourced High-risk finding already in this engagement's own published ITRF annex. B.2, B.3 and B.4 all held up under the same semantic re-check applied to B.1 below.

An independent pass reconciling this engagement's workflow taxonomy against the real capability model (outputs/project/ggsc_concept_taxonomy.md) landed on the same two lexical gaps (B.1, B.2) without being told about them in advance — useful corroboration that both were worth investigating, though it doesn't settle B.1's open question either, since that pass was also lexical.

B.1 Combination Processing — open question, not a settled gap

Status: requires TPWG judgement, not ready to submit as an addition. The semantic-matching step in Section A changes this finding. Geodetic Data Products' own label explicitly reads "Geodetic Data Products (EOP Clocks Orbits Station Positions Gravity Models)" — it names the exact product outputs that combination produces. Reference Frames' evidence summary discusses "accurate reference frame computations," which for ITRF specifically is the combination step. Read semantically rather than lexically, both existing capabilities plausibly already intend to cover combination as part of producing those named products. The original finding — confirmed by grep, zero matches for "combin" across all 58 labels and subdomains — only proved the word wasn't there, not that the concept wasn't.

What's still true, regardless of how this resolves: Nick's own worked example (Section 10.2) already names "combination processing" as if it were a distinct, separately-scored capability (People 3 / Process 4 / Technology 3 / Data 4 for the IERS EOC combination function) — so something about combination isn't currently well represented, whichever way this resolves. It's the specific step behind the P2 single-point-of-failure finding the EOP worked example returns to repeatedly (Section 13.4), and the same combination-centre pattern recurs for ITRF and ICRF.

The real issue may be definition depth, not absence. Geodetic Data Products and Reference Frames's current evidence summaries don't call out the specific, critical sub-risk that matters for robustness testing — a single institution, a proprietary undocumented software toolchain, no succession plan — even if the capabilities themselves are broad enough to nominally cover the combination step. Two ways this could resolve, both legitimate outcomes of the process in Section A, and the choice is a TPWG call, not something this submission should pre-decide:

1. Definition deepening — expand Geodetic Data Products' (and Reference Frames') evidence summary to explicitly name the combination sub-step and its single-point-of-failure risk, scored as part of the existing capability.
2. Split — if the TPWG's detailed function description (per Section A step 1) shows combination is a distinct enough competency (different people, different software, different institution than the rest of what Geodetic Data Products covers) to warrant its own capability and its own score, separate from the broader product-packaging competency.

Draft definition, if resolved as a split: The capability to merge multiple independent technique or analysis-centre solutions into a single combined product (e.g., VLBI + GNSS + SLR solutions into one EOP series; multiple technique solutions into ITRF), including the combination algorithm, weighting/quality-control methodology, and the software and staff expertise to run it reproducibly. Kept here so the option is ready to use if that's the resolution — not a claim that it's the right one.

B.2 Real-Time Network/Observatory Monitoring

Evidence. P6 (Transparency, monitoring and performance assurance) requires "agreed performance and resilience indicators covering... observatory availability, data timeliness... service continuity" and explicitly wants "early sight of systemic risks well before they surface as product failures" (Section 3.6). Annex A.8's P6 floor check assumes "monitoring and performance-assurance capabilities wherever they sit in the capability set" — but checked against the actual 58, there's no match for "monitor" anywhere. The three closest existing capabilities were checked individually and don't cover it:

• Network Operations (Asset and Infrastructure Management) — evidence summary describes resourcing, infrastructure and governance of network operation generally, not continuous technical status monitoring.
• System Testing and Validation (Asset and Infrastructure Management, Calibration and Maintenance subdomain) — periodic testing/calibration, not continuous operational monitoring.
• Performance Management (Governance and Strategy) — organisational/strategic performance, not real-time technical monitoring. (Its current evidence-summary text in the DataBook also reads as a duplicate of Legal Framework's — separately worth a data-quality check, not part of this submission.)

This means P6's floor check currently has no single capability to test against for the thing it's actually asking about: can anyone see a problem happening in near-real-time. That's a structural gap in one of the six principles' testability, not just a missing label.

Proposed domain: Asset and Infrastructure Management, alongside Network Operations — it's the technical capability to observe system/station health continuously, distinct from operating the network (Network Operations) or periodically testing it (System Testing and Validation).

Draft definition: The capability to continuously observe the operational status of observation, data and processing infrastructure — station/system availability, data flow timeliness, anomaly and outage detection — with automated or near-real-time alerting sufficient to give early warning of degradation before it surfaces as a product-level failure.

B.3 Stakeholder Disclosure and Public Reporting

Proposed domain: Engagement and Collaboration, Stakeholder Management subdomain — alongside the two existing capabilities there, Stakeholder Identification and Analysis and Stakeholder Communication and Engagement.

Evidence. A number of Member States have not submitted their technical reports to IGS for satellite orbit products, making it difficult to establish where issues actually occurred when investigating performance problems. This is expert-judgement evidence from direct engagement experience on this assignment (per Section 5.4's evidence-status convention: attributed, dated, not yet independently documented elsewhere) rather than an externally sourced citation — worth a TPWG follow-up to confirm scope and specific instances before this goes further. It points at a real gap distinct from the two existing Stakeholder Management capabilities: Stakeholder Identification and Analysis and Stakeholder Communication and Engagement are both about the coordinating body's own outward engagement, not about compelling or receiving technical disclosure from contributing providers. It's also distinct from the proposed Real-Time Network/Observatory Monitoring capability (B.2) — that's continuous, automated technical status monitoring; this is retrospective, narrative incident/performance reporting, often the only way to establish root cause after the fact when automated monitoring wasn't watching the right thing or didn't exist for a given provider. Nick's own P6 (Transparency, monitoring and performance assurance) already gestures at this — "significant failures, systemic risks and corrective actions reported to the relevant governance body" — but nothing in the current 58 capabilities covers the specific competency of actually obtaining that disclosure from Member States and agencies who may have no obligation to provide it.

Draft definition: The capability to define, request, and obtain technical incident and performance disclosure from Member States and contributing agencies — and to make appropriate findings publicly available — sufficient to establish root cause after a service disruption or quality issue, including where the disclosing party has no pre-existing obligation to report.

B.4 Workforce Succession and Continuity Planning

Proposed domain: Asset and Infrastructure Management, alongside Equipment Calibration and Maintenance and Network Operations — or a case could be made for Governance and Strategy if it's scored per-organisation per Section C below; worth a TPWG call.

Evidence. Surfaced from the "Workforce/succession" line in Nick's own WP9 target-state architecture rollup (Robust_Global_Geodesy_Supply_Chain_Consultant_Methodology_and_Work_Plan_v1_2.docx), which has no corresponding capability anywhere in the 58 — confirmed by grep, zero matches for "succession" or "workforce" across all labels, subdomains and evidence summaries. This isn't a hypothetical gap: this engagement's own existing ITRF annex (outputs/itrf_workflow_description.md) already documents it as a named, sourced, High risk finding, independently of this submission:

• "The small, undocumented specialist teams maintaining key software packages violate the workforce resilience requirements of (Principle 5: Minimum Capability Maturity)" (line 143).
• "the teams maintaining these specialised software packages are typically small academic groups operating with limited succession planning, and in several cases the expertise is concentrated in a single institution or a small number of individuals" (line 137, on the four technique services' Analysis Centre software).
• On ITRF combination specifically: "CATREF, as a proprietary in-house software package, is not openly documented or maintained by an independent community, creating a succession risk that extends beyond personnel to the computational toolchain itself" (line 169).

The annex also flags that the closest existing capability, Training and Education, doesn't reliably cover this even where applied: "ITRF has no Training and Education row in any tier table currently, unlike ICRF and Gravity, which do" (line 243) — and Training and Education is about skill development/delivery, not about continuity when a specific irreplaceable expert or undocumented toolchain is lost, which is what Nick's own P5 text separately names: "sufficient skilled personnel and workforce resilience, including succession planning" (Section 3.5). This is a real, distinct competency, already causing a documented High-risk finding in this engagement's own published work, with no capability home.

Draft definition: The capability to identify single-person or single-team dependencies in critical roles and toolchains, and to maintain a credible, resourced plan — cross-training, documentation, institutional knowledge transfer — so the departure of key personnel does not constitute a supply chain disruption.

---

C. Scoring-unit clarification: Governance and Strategy capabilities need a different unit than technical capabilities

This isn't a capability addition — it's a fix to how WP4/WP5 should score capabilities that already exist, surfaced by a direct example: "Mandate" scored for UN-GGCE (its own authority to coordinate and assess the supply chain) and "Mandate" scored for IGS (its institutional authority to be the recognised provider of satellite orbit products) are not the same question, even though WP4 would currently score both under the identical capability label, per product-function.

Why this is safe for most capabilities and not for these. Technical/operational capabilities — Data Acquisition and Storage, Data Processing and Analysis, Data Quality Management — keep the same underlying meaning across products even though the concrete work differs (EOP bulletin comparison vs. GNSS SISRE validation is still "a documented, repeatable process for checking data meets standard before release"). Re-scoring these per product-function is the model working as designed: same meaning, different manifestation.

Governance and Strategy domain capabilities are different in kind: Mandate, Legal Framework, Policy Formulation, Strategic Planning, Vision and Strategy, Budgeting, Cost Management, Funding and Investment, Regulatory Compliance are properties an organisation holds, not properties a function holds. Scoring them per product-function either re-scores the same underlying legal/institutional fact multiple times (once for each product an organisation like IGS or IERS touches), or silently conflates genuinely different referents under one label — exactly what this whole methodology is otherwise careful to prevent. The same likely applies to most of Engagement and Collaboration (Partnership and Collaboration, Standards Development and Promotion).

Why this isn't a new problem, and isn't caused by collapsing Functions into Capabilities. It predates that question entirely. The published State of Geodesy 2026 baseline scored all 58 capabilities once, holistically, for the whole supply chain — not per product. WP4/WP5 already ask TPWGs to re-score every applicable capability per function regardless of whether Functions survive as a separate concept, so this needs fixing either way.

Proposed fix — no new mechanism required. Nick's own C6 "Governance basis record" is already scoped correctly for the product-specific question: per-function, evidence-based (binding obligation / formal commitment / informal practice / no basis), not a PPTD score. That's the right instrument for "does this specific function have adequate authority behind it." The capability-level scores for Governance and Strategy (and likely most of Engagement and Collaboration) should be pulled back to organisation-level instead — scored once per provider (IGS, IERS, IVS, ILRS, IDS, UN-GGCE itself), referenced by every function that provider performs, rather than re-elicited per product. WP4's activity list should say this explicitly, capability domain by domain, rather than applying one scoring unit uniformly across all six domains.

---

D. WP9's "Components" rollup is a third, unreconciled taxonomy — not a new problem, the same one at a different layer

The Robustness Testing Procedure's WP9 target-state architecture step (A9, Section 15.2) consolidates five products' findings using an 11-category "Component" list carried over from the earlier work plan (Robust_Global_Geodesy_Supply_Chain_Consultant_Methodology_and_Work_Plan_v1_2.docx): Observation infrastructure, Data centres, Analysis centres, Combination centres, Software/processing, Data replication/access, Governance, Workforce/succession, Funding/sustainability, Monitoring/assurance, Recovery/failover.

This list doesn't reconcile with either of the two primitives it should be built from — it's a blend of both, unlabelled. Checked entry by entry:

Component entry	Actually maps to
Observation infrastructure	Organisations & Roles primitive (Observing Stations/Networks) — not a capability
Data centres	Organisations & Roles primitive (Data Centers)
Analysis centres	Organisations & Roles primitive (Analysis Centers)
Combination centres	Organisations & Roles primitive (Combination Centers) — the capability behind it is B.1, currently an open question (see B.1: definition-deepening vs. split), not yet a settled addition
Software/processing	Existing capability — Geodetic Software and Tools
Data replication/access	Existing capabilities — Data Sharing, Data Lifecycle Management, Data Distribution
Governance	Existing domain — Governance and Strategy (see Section C on scoring unit)
Funding/sustainability	Existing capabilities — Funding and Investment, Budgeting, Cost Management
Monitoring/assurance	Proposed B.2, plus existing Performance Management
Recovery/failover	Existing capability — Disaster Recovery and Supply Chain Continuity (near-exact name match)
Workforce/succession	No existing capability — proposed B.4

Four of the eleven entries are the Organisations & Roles primitive under different labels; six map onto existing or proposed capabilities; only Workforce/succession was a genuine gap, and it's now covered by B.4. None of this needed a third vocabulary — WP9 was re-deriving categories that already exist elsewhere in the method.

Proposed fix. Replace the 11-category Component list with two rollups, each reusing a primitive that already exists rather than inventing a third: one by Organisation/facility type (Observing Stations, Data Centers, Analysis Centers, Combination Centers, Coordinating Services), one by Capability domain (the real 6, or Level 2 within them). This still does WP9's actual job — consolidating five product-level findings into one target-state picture for the roadmap — without a separate taxonomy to keep reconciled against the other two. It also means Recovery/failover and the proposed capabilities above (B.2, B.4, and B.1 once resolved) get exactly one home each, not a WP9-specific label sitting alongside a differently-named capability doing the same work.

This is the same finding as Sections B and the taxonomy reconciliation, one layer later: a structure introduced for a real, legitimate purpose (here, cross-product consolidation) that wasn't checked against what already exists before being built.

---

What this submission does not do

It doesn't propose any merges. I don't have solid evidence for a specific merge candidate yet — surfacing genuine overlap (rather than just apparent overlap, the way Functions and Capabilities looked similar without actually being redundant, the way most of the WP9 Components turned out to be the Organisations primitive relabelled rather than real capability gaps, and the way B.1 turned out to be an open question rather than a clean gap once checked semantically) needs the same evidence discipline as the additions above, and forcing one now would undercut the credibility of the three settled findings and the one honestly-flagged open question. Merge candidates should come through the same process as they're found, not be invented to fill out this submission.