UN-GGCE Portal

Appearance

UN-GGCE Global Geodesy Supply Chain (GGSC) ​

Business Architecture Metamodel & Concept Taxonomy ​

Standard Alignment: BIZBOK® Guide (Business Architecture Guild) & W3C Holonic Architecture
Context: UN-GGCE Workstream 2 (Supply Chain Robustness) & Workstream 1 (International Governance)
Target Audience: Technical Product Working Groups (TPWGs), Geodetic Scientists, and Governance Authors

0. Business Architecture, Starting From Product ​

Business architecture describes an enterprise — here, the Global Geodesy Supply Chain — in terms stable enough to support decisions about risk, strategy and investment, independent of who currently does the work or what tools they use today. It starts from Product: the thing the global community actually receives (EOP, ITRF, ICRF, Satellite Orbits, Global Gravity Field). Everything else in this taxonomy exists to answer one question about that Product — is it robust, and if not, what closes the gap — so Product belongs at the centre of the model, not appended after the tools used to assess it.

Four elements do that assessing, each a different lens on the same Product:

(This is the classic BIZBOK wheel — Business Architecture Knowledge base domains arranged radially around the enterprise — drawn as an actual radial layout rather than a plain-text cross. Product sits at the centre; everything else is a spoke that exists to describe or deliver it.)

ElementAnswersRole in this taxonomy
ProductWhat does the global community actually receive?The thing being assessed — Primitive 1, the hub the other four orbit, not a fifth tool alongside them.
CapabilitiesWhat can the supply chain do?The unit of maturity scoring — generic, reusable across products (Primitive 3).
Value Stream Mapping (product workflows)How do those capabilities compose, in sequence, to deliver a product?What "Functions" were reaching for — the five geodetic product workflows (Primitive 2).
Information FlowsWhat is actually exchanged, and under what obligation?Carries agreements and disclosure requirements as flow-level metadata, not a separate governance apparatus (Primitive 4).
Organisational StructureWho or what physically performs a capability, and where?Observing stations, data centres, analysis and combination centres, coordinating services (Primitive 5).

Every question this engagement asks reduces to these four lenses on the Product, checked against each other: robustness is capability maturity tested against the value stream; risk is a disruption traced through organisational and information dependencies; investment priority is a gap in one of the four, correctly attributed to the right one rather than invented as a new category.

MECE governs how the capability set itself is evaluated and extended. Every proposed capability-model change — addition, split, merge, or definition deepening (outputs/capability_model_change_submission.md, Section A) — is ultimately a MECE test: collectively exhaustive (does a real function go uncovered — the test that found the Real-Time Monitoring and Stakeholder Disclosure gaps) and mutually exclusive (do two things in the model describe the same competency under different names — the test that found Functions largely redundant with Capabilities, and WP9's Components redundant with Organisations plus Capabilities). A change that isn't clearly one or the other isn't ready to submit — see the semantic-matching process in that document for how the test is actually run, function by function.

1. Purpose & Architectural Alignment ​

This taxonomy establishes a single, unambiguous conceptual model for the Global Geodesy Supply Chain (GGSC).

It resolves the cognitive friction in previous drafts by strictly aligning with BIZBOK® principles:

  1. Eliminating the ambiguous "Critical Functions" tier by integrating them directly as Level 2/3 Geodetic Capabilities, reconciled against the real, published State of Geodesy 2026 capability model (data/shacl/ggsc-capability-maturity.databook.md) rather than inventing a parallel one — see Section 2's Status column.
  2. Untangling "Product Components" by classifying them as Information Artifacts (data contracts passed between stages).
  3. Establishing a clean, 5-primitive metamodel that speaks the natural language of geodetic scientists while maintaining enterprise-grade architectural rigor.

2. The 5 Core Architectural Primitives ​

Primitive 1: Geodetic Product (The Value Proposition) ​

  • Definition: A formal, standardized scientific or operational output delivered to global users, Member States, space agencies, and downstream industry.
  • The 5 Core Products:
    1. Earth Orientation Parameters (EOP): Celestial/terrestrial pole coordinates, UT1-UTC, length-of-day.
    2. International Terrestrial Reference Frame (ITRF): Standardized 3D coordinate system and velocity field.
    3. International Celestial Reference Frame (ICRF): Astrometric coordinates of extragalactic radio sources (quasars).
    4. Satellite Orbits & Clocks: Precision ephemerides and clock states (GNSS, LEO, altimetry).
    5. Global Gravity Field Models: Static/temporal gravitational potential coefficients (geoid, mass transport).

Primitive 2: Value Stream / Workflow (The "How" Sequence) ​

  • Definition: The end-to-end sequence of stages triggered by physical observation and culminating in product delivery.
  • Standard Value Stream Stages:
    1. Stage 1 — Primary Observation Acquisition: Photons/signals received at sensors (VLBI, SLR, GNSS, DORIS).
    2. Stage 2 — Ingest & Pre-Processing: Data formatting, fringe-fitting, phase unwrapping, quality filtering.
    3. Stage 3 — Technique Analysis Center (AC) Reduction: Single-technique parameter estimation and normal equation formation.
    4. Stage 4 — Multi-Technique Combination: Inter-technique stacking, frame tie resolution, and constraint harmonization.
    5. Stage 5 — Product Synthesis & Quality Assurance: Quality validation, anomaly rejection, metadata tagging.
    6. Stage 6 — Dissemination & Archival: Public API, FAIR repository distribution, mirror replication.

Primitive 3: Capabilities (The "What" Abilities) ​

  • Definition: The fundamental technical, scientific, and organizational abilities required to execute the value stream. Agnostic of who does it or what software is used.
  • Structure:
Level 1: Capability Domain (the real, published 6 State of Geodesy 2026 domains)
  └── Level 2: Capability (the real, scored 58 — not a new layer)
        └── Level 3: Illustrative operation or, where marked PROPOSED,
              a candidate sub-capability not yet in the model

Reconciliation note: Level 3 below is illustrative detail under each existing Level 2 capability, not a new scored layer — it replaces "Critical Functions" as a plain-language way to talk through a workflow step without creating a competing taxonomy. Where no existing capability covers a real production step, that's marked PROPOSED and tracks the change process in outputs/capability_model_change_submission.md, not invented here. Domain names below are the real, published State of Geodesy 2026 domain names — not renamed for readability — so this table stays queryable against data/shacl/ggsc-capability-maturity.databook.md directly.

Taxonomy Breakdown: ​

Level 1 DomainLevel 2 CapabilityStatusLevel 3 — Illustrative Operations
Asset and Infrastructure ManagementNetwork OperationsExistingVLBI Antenna Pointing & Tracking · SLR Laser Ranging & Epoch Timing · GNSS Multi-Constellation Reception · Space-Tie Vector Measurement
Asset and Infrastructure ManagementEquipment Calibration and MaintenanceExistingFrequency Standard (Maser) Synchronisation · Atmospheric Sensor Calibration
Asset and Infrastructure ManagementLocal Tie / Local Tie Processing and AnalysisExistingLocal Tie Metrology
Asset and Infrastructure ManagementSystem Testing and ValidationExistingPeriodic system/instrument validation (not continuous — see Monitoring below)
Asset and Infrastructure ManagementReal-Time Network/Observatory MonitoringPROPOSED — submission B.2Real-Time Latency Monitoring · Anomaly & Outage Detection
Data ManagementVLBI/GNSS/SLR/DORIS/Gravity Data Processing and AnalysisExisting (per technique)VLBI Baseband Data Correlation · VLBI Fringe-Fitting & Delay Extraction · GNSS Carrier-Phase Disambiguation
Data ManagementData Sharing / Data Quality ManagementExistingFAIR Data Packaging & Verification (moved here from "Operational Performance Assurance" in the prior draft — this is a QA/sharing activity, not real-time monitoring)
Data Products and SoftwareReference Frames / Geodetic Data ProductsExistingSatellite Orbit Integration & Propagation · Station Coordinate Inversion · EOP Tidal & Sub-Daily Modeling · Spherical Harmonic Gravity Solution
Data Products and SoftwareCombination ProcessingOPEN QUESTION — submission B.1, corrected 16 Sep 2026 (was shown as PROPOSED like B.2, which overstated it — checked semantically, Geodetic Data Products/Reference Frames may already cover this, so B.1 is a genuinely unresolved question between deepening an existing definition and splitting a new capability, not a settled request)Multi-Center Solution Stacking · Inter-Technique Geodetic Tie Reconciliation · Reference Frame Datum Alignment
Engagement and CollaborationStakeholder Identification and AnalysisExisting—
Engagement and CollaborationStakeholder Communication and EngagementExisting—
Engagement and CollaborationStakeholder Disclosure and Public ReportingPROPOSED — submission B.3Technical incident/performance report submission by contributing Member States and agencies to the relevant coordinating service
Engagement and CollaborationOutreach and Public Awareness · Partnership and Collaboration · Standards Development and Promotion · Curriculum Development and Educational Program DeliveryExistingNot elaborated to Level 3 here — not central to product workflow mapping
Governance and StrategyMandate · Legal Framework · Policy Formulation · Strategic Planning · Vision and Strategy · Budgeting · Cost Management · Funding and Investment · Regulatory Compliance · Performance ManagementExistingScored per organisation/provider, not per product-function — see capability_model_change_submission.md Section C. Listed here for domain completeness, not elaborated to Level 3.
Innovation and DevelopmentResearch and Development Planning/Execution/Prototyping · Innovation Project Management · Innovation Strategy Development · Technology Assessment · Technology Scouting · Technology Integration · Knowledge ManagementExistingNot elaborated to Level 3 here — touched lightly per function (e.g. does this function rely on R&D-sourced tooling), not a primary workflow axis

Primitive 4: Information Artifacts (The Data Contracts) ​

  • Definition: The structured data payloads exchanged between nodes along the value stream. (Replaces the ambiguous term "Product Components").
Lifecycle StageInformation ArtifactStandard Formats / Syntax
Raw AcquisitionRaw Observational DataMark 6, VDIF, raw GNSS binary
Pre-ProcessedStandardized Observation LogsRINEX 3/4, CRD (SLR), vgosDB (VLBI)
Intermediate AnalysisUncombined Solutions & Normal EquationsSINEX (Solution Independent Exchange)
Combination OutputIntegrated Multi-Technique SolutionCombined SINEX, EOP Daily/Weekly Tables
Final DeliveryPublished Ephemerides & ModelsSP3 (Orbits), CLK (Clocks), ITRF Solution, ICGEM (Gravity)

Terminology correction, 22 Sep 2026: the Raw Acquisition row previously read "Raw Observational Baseband." Corrected to the technique-neutral "Raw Observational Data" — "Baseband" is a real, precise term (the recorded raw voltage signal after down-conversion from RF to near-zero frequency, before correlation), but it is VLBI-specific vocabulary; GNSS, SLR, and DORIS raw data are never called "baseband" in their own communities. "Baseband" remains correct wherever a document is specifically describing the VLBI signal-recording step (e.g. Mark 6/VDIF recording, correlation) — it should not be used as the generic cross-technique artifact name.

Primitive 5: Organizations & Operational Roles ​

  • Definition: The institutional entities that own, operate, or govern capabilities.
  • Standardized Typology:
    • Observing Stations / Networks: Physical sensor hosts (NASA, BKG, Geoscience Australia, Hartebeesthoek, etc.).
    • Data Centers: Ingest and distribution hubs (CDDIS, BKG Data Center, EDC).
    • Correlation Centers: Massive compute nodes for VLBI (Haystack, Bonn, Washington, Shanghai).
    • Analysis Centers (ACs): Independent institutes computing uncombined solutions.
    • Combination Centers (CCs): Lead institutes harmonizing AC outputs into single products.
    • Coordinating Services & Governing Bodies: IAG Services (IGS, IVS, ILRS, IDS, IERS), GGOS, UN-GGCE.

3. The Robustness Evaluation Metamodel ​

Robustness is measured by evaluating how Capabilities (Primitive 3) perform across Value Streams (Primitive 2) under stress:

$$\text{Product Robustness} = f\Big(\text{Capability Maturity Floor} ;\cap; \text{Architectural Redundancy} ;\cap; \text{Disruption Resistance}\Big)$$

Not binary. A prior draft of this diagram showed [ROBUST] / [NOT YET] only. That drops a deliberate safeguard from the Robustness Testing Procedure (Section 13.3): missing evidence must never be presented as, or silently collapse into, a pass or a fail — it gets its own outcome, Not Yet Robust — Evidence Gap, so a gap in the record is never mistaken for a gap in the supply chain. Corrected here to match.

Deterministic Floor Rules: ​

  1. No Single Point of Failure (SPOF): If any critical Level 2 capability at a function relies on a single institution or software code base, with no demonstrated (not merely claimed) alternative, the product cannot be ROBUST.
  2. Minimum Maturity Floor ($M_{\text{req}}$): If an essential capability operates below its elicited threshold (e.g. Process at Level 1 "Ad-hoc" when Level 4 "Managed" is required — corrected 16 Sep 2026; the real level table at Annex A.2 has "Ad-hoc" at Level 1, not Level 2), the gap ($\Delta$) triggers NOT YET ROBUST.
  3. Disruption Survivability: If a simulated loss of a major jurisdiction halts product delivery for $> \text{Max Allowed Downtime}$, the product is NOT YET ROBUST.
  4. Missing evidence is not a pass. If any of the above cannot be evaluated because the underlying capture is incomplete, the product is NOT YET ROBUST — EVIDENCE GAP on that point, not defaulted to the lowest-risk or highest-risk value either way.

4. Jargon Translation Matrix (For Document Authors) ​

Old Document JargonClean Metamodel TermReason for Change
Critical FunctionLevel 2 Capability, with Level 3 as illustrative detail"Function" created an unnecessary third layer running in parallel to the real 58-capability model. Correlation, Stacking, and Orbit Fitting are detail under existing capabilities, not a competing taxonomy — the three gaps this reconciliation actually found (Combination Processing, Real-Time Monitoring, Stakeholder Disclosure and Public Reporting) are tracked as proposed additions, not assumed.
Product ComponentInformation ArtifactSeparates the final Product from intermediate data contracts (SINEX, RINEX, raw observational data).
Workflow / Supply ChainValue StreamAligns with standard enterprise value delivery syntax (Trigger $\rightarrow$ Value Realization).

Correction, 16 Sep 2026: this table previously listed Instrument C1–C6 / A1–A10 as jargon to translate into "Data Capture / Assessment Canvas." That was wrong — C1–C6 (capture instruments) and A1–A10 (assessment instruments) are ROBUSTNESS_TESTING_PROCEDURE_v1.6's own real, current, authoritative instrument names (Sections 17–18), not bureaucratic acronyms invented elsewhere. outputs/project/eop_worked_example_v2.md uses them directly and by name throughout. Removed rather than relabelled — there is no cleaner term to translate them into, because they're already the clean term.

5. Guidance for TPWG Facilitation ​

This isn't a separate facilitation method — ROBUSTNESS_TESTING_PROCEDURE_v1.6 already has a fully specified one (Section 6): Track A (continuous, semi-structured system mapping — the C2 function record, C6 governance basis) for building shared understanding, and Track B (structured Delphi-style elicitation on C4 — Round 0 orientation, Round 1 anonymous written responses, synthesis, Round 2 facilitated workshop, TPWG Chair sign-off) for converging on defensible numbers. Continuity and recovery thresholds use the further bottom-up method at Section 6.3: establish the observed baseline, ask the narrower "how much worse than today would be unacceptable" question, stress-test against a disruption scenario, then ratify. outputs/project/eop_worked_example_v2.md shows this mechanism actually applied to EOP, work package by work package. This section is just the plain-language entry point into that real method, not an alternative to it.

When consulting geodesists and observatory directors:

  1. Do not ask: "What is the maturity of your governance instruments?"
  2. Do ask (these map onto C2's real field list — Section 9.1 of the Procedure):
    • "What are the sequential steps in your workflow from photon capture to published table?" — populates C2's function list, F1...Fn.
    • "What specialized capabilities (correlation, stacking, modeling) are needed at each step?" — feeds WP4's capability mapping (C3).
    • "If your primary analysis center or correlation facility is knocked offline tomorrow, who takes over, and does the backup pipeline work automatically?" — the alternative, common-dependency and recovery-arrangement fields on C2, and the independence test WP6 later runs.
    • "Is your function nominally shared across more than one country or institution — and if so, which specific piece of it would actually stop if just one of them withdrew?" — C2's own instruction to name the jurisdiction of the operationally critical sub-function separately, not the nominal one. This is the question that would have caught EOP's real USNO/SYRTE split from the start, instead of it surfacing later as a correction (see the worked example's WP3).