Digital Twin Consortium Capabilities Periodic Table: Maturity and Platform Mapping

Most digital twin projects do not fail because the chosen platform was bad. They fail because nobody wrote down what the twin had to be able to do before the platform was chosen. A vendor demo shows a 3D model, a dashboard and a machine learning widget, and the buyer discovers six months later that device management, ontology governance and a model repository were never in scope. The Digital Twin Consortium capabilities periodic table (CPT) exists to fix that ordering problem: it is a catalogue of what a digital twin system can be asked to do, deliberately separated from how any product does it.

That matters in 2026 because the tooling landscape is crowded with overlapping claims. Cloud twin services, industrial data platforms, simulation suites, Asset Administration Shell servers and W3C Web of Things stacks all describe themselves as “digital twin platforms” while covering very different slices of the problem. A neutral capability vocabulary is the only sane way to compare them.

This article walks through the CPT as published by the Digital Twin Consortium (DTC), explains its place in the wider Composability Framework, shows how maturity and fidelity fit in, maps the capabilities onto ISO 23247, Azure’s DTDL, the Asset Administration Shell and W3C WoT, and ends with an honest critique of where the model is vague.

What this covers: the structure and numbers of the CPT, the Composability Framework workflow, a capability-to-standard mapping table, a worked requirements exercise, and the gotchas that bite when you operationalise it.

Context and Background

The DTC is an industry consortium hosted under the Object Management Group (OMG) umbrella. On 3 December 2020 it published a definition that has since become the most-quoted vendor-neutral one: a digital twin is a virtual representation of real-world entities and processes, synchronized at a specified frequency and fidelity. The accompanying text adds several constraints worth keeping in mind. Twins are driven by outcomes, tailored to specific use cases, built on data, and deployed within IT and OT systems. The virtual representation is a set of correlated digital models plus supporting data such as metadata and reference data. Synchronization can happen by observation (sensors, scans, imaging), by intervention (actuators, robots), or both, and humans are often still in the loop. Crucially, fidelity only needs to suit the intended use case, but it must be validated to be trusted.

Two phrases in that definition drive everything in the CPT: “specified frequency and fidelity” and “use case”. The consortium did not define a twin by its technology (a graph, a 3D model, a simulation). It defined it by obligations. The CPT is the obvious follow-on: if a twin is defined by obligations, list the obligations.

The standards landscape the CPT sits beside is already well populated. ISO 23247 gives a framework for digital twins in manufacturing; our walk-through of the ISO 23247-5 digital thread reference architecture covers its newer part, and ISO 23247-6 on twin composition covers how twins are combined. The Industrial Digital Twin Association (IDTA) maintains the Asset Administration Shell, which we unpack in our AAS reference architecture post. Microsoft’s DTDL is compared against both in AAS vs DTDL vs OPC UA information models. For a one-page orientation across all of them, see digital twin standards: ISO 23247, ISO/IEC 30173 and the DTC.

What none of those documents does is answer the question a program sponsor actually asks: “Which of these 60-odd things do we need for this use case, and in what order?” That is the gap the CPT occupies. It is published by the DTC at digitaltwinconsortium.org together with a toolkit (user guide, worksheet, and a version conversion table), and it is authored by practitioners rather than a formal standards body. That distinction matters later when we discuss rigour.

A brief provenance note. The version described on the DTC site is 1.1, announced as a refinement of the original 1.0 release, with authors credited as Sean Whiteley (AxoMem) and Pieter van Schalkwyk (XMPRO). The DTC page describes it as an “architecture and technology agnostic requirements definition framework.” The consortium has also previewed a version 2 aimed at better AI interoperability, geospatial and spatial computing coverage, more guidance on aligning fidelity with use cases, and a stronger focus on user experience. I could not find a dated V2 publication while researching this post, so treat anything V2 as unconfirmed and check the DTC site before relying on it.

The Capabilities Periodic Table and the Composability Framework

The CPT is a requirements catalogue that groups digital twin capabilities into six categories: Data Services, Integration, Intelligence, User Experience, Management and Trustworthiness. Each capability has a two-letter category prefix and a two-letter code, such as DS.IR for the Digital Twin Instance Repository. A team selects the capabilities its use case needs, then maps them to a platform stack and only then to products.

Figure 1: The Composability Framework workflow. The CPT sits between the use case and the platform stack, and vendor selection comes last.

Figure 1 shows the workflow as the DTC describes it. A Quality magazine article by DTC contributors on the Composability Framework lays out three components: a Business Maturity Model, the Capabilities Periodic Table, and the Platform Stack Architectural Framework. The suggested sequence is to start with a specific use case and the purpose the twin must serve, identify data and capability requirements with the CPT, map those to the Platform Stack, and select technology and vendors only after those steps. The article states plainly that technology and vendor selection can be done once the earlier steps are complete, and says the workflow spans the full twin lifecycle: planning, deployment, operation, maintenance and decommissioning.

Six categories, 61 elements

The same article counts 61 elements across the six categories. My own count of the capability list on the DTC’s published page agrees: 16 in Data Services, 6 in Integration, 15 in Intelligence, 12 in User Experience, 4 in Management and 8 in Trustworthiness, which sums to 61. The page itself has small inconsistencies (for example the Privacy and Responsibility entries both appear with the code TW.PR, and some index codes differ from section codes), so treat the codes below as the intent rather than a controlled identifier set.

Figure 2: The six CPT categories and the number of capabilities in each, counted from the DTC’s published capability list.

The distribution already says something. Data Services is the largest category by a wide margin, which reflects a real engineering truth: most of the cost and risk in a twin lives in acquiring, shaping, storing and governing data, not in the visualisation layer. Management has only four elements, which is arguably too few for a category that covers device lifecycle, system monitoring, logging and data governance.

What each category actually contains

Data Services (DS) covers the data pipeline and stores: acquisition and ingestion (DS.AI), streaming (DS.ST), transformation and wrangling (DS.TR), contextualization (DS.CX), batch processing (DS.BP), real-time processing (DS.RT), publish/subscribe push (DS.AS), aggregation (DS.AG), synthetic data generation (DS.SG), ontology management (DS.ON), the twin model repository (DS.RP), the twin instance repository (DS.IR), domain-specific data management for geospatial, temporal and image data (DS.DS), tiered storage and archive (DS.SA), the simulation model repository (DS.SR) and the AI model repository (DS.AR).

Notice the split between DS.RP and DS.IR. The model repository holds definitions, structures and integrity rules; the instance repository holds the state of individual twins that conform to those models. That is the same class/instance distinction you see in DTDL interfaces versus twins and in AAS types versus instances, and it is one of the cleanest ideas in the whole table.

Integration (IR) has six elements: enterprise systems such as ERP, EAM, CRM and CMMS (IR.ET), engineering systems such as CAD, CAM, BIM and historians (IR.EG), OT and IoT systems including SCADA (IR.IO), other digital twins (IR.DT), collaboration platforms (IR.CL) and API services (IR.AS). IR.DT is the quiet important one. It is where federation and composition live, and it is the hook that connects the CPT to ISO 23247-6.

Intelligence (IC) is the most heterogeneous category with 15 capabilities: search (IC.SR), command and control (IC.CC), orchestration (IC.OS), alerts and notification (IC.AL), reporting (IC.RP), analysis and analytics (IC.AA), prediction (IC.PR), artificial intelligence (IC.AI), federated learning (IC.FL), simulation (IC.SM), mathematical analytics for engineering calculations (IC.MA), prescriptive recommendations (IC.PS), business rules (IC.BR), distributed ledger and smart contracts (IC.DL) and composition (IC.CS).

User Experience (UX) has 12: basic and advanced visualization, real-time monitoring, entity relationship visualization, extended reality, dashboards, continuous intelligence, business intelligence, business process management and workflow, game engine visualization, 3D rendering from point clouds, and gamification.

Management (MG) has device management (MG.DM), system monitoring and alerting (MG.SM), logging (MG.EL) and data governance (MG.DG).

Trustworthiness (TW) has eight: device security, security, privacy, safety, reliability, resilience, responsibility and data encryption. The DTC defines trustworthiness as the degree of confidence one has that the system performs as expected. Responsibility was added in version 1.1 and covers ethics, ESG criteria, AI explainability and fairness.

What changed from 1.0 to 1.1

The DTC’s announcement lists the changes: Responsibility and Search were added, augmented and virtual reality were consolidated into extended reality, temporal data stores were moved under domain-specific data management, and sequential numbering gave way to the structured category abbreviations used above. A conversion table maps 1.0 identifiers to 1.1. If you inherit a worksheet from 2022 or 2023, run it through that table before comparing it to anything current. The announcement does not give a release date in the text I retrieved, so I will not assert one.

Why a periodic table and not a taxonomy

The periodic-table metaphor is about grouping by shared characteristics so that gaps are visible at a glance. The practical benefit is a workshop artefact: a one-page grid that a facilitator can colour in. Business stakeholders highlight what the use case needs; architects highlight what existing systems already provide; the uncoloured intersection is the gap list. That is a genuinely useful move, because it forces the conversation to be about capabilities already owned versus capabilities to be bought or built.

The metaphor also oversells. Real periodic tables derive their structure from atomic number and electron configuration, so position carries predictive information. The CPT’s layout carries no equivalent. It is a well-organised checklist, which is valuable enough, but you should not expect adjacency to imply dependency.

Maturity, Fidelity and Trust: The Parts That Are Not in the Grid

The grid tells you what a twin could do. It says nothing about how well it does it, which is where maturity and fidelity come in. These are separate ideas that people routinely merge, and the Composability Framework keeps them in different places.

Business maturity versus technical fidelity

The Business Maturity Model, the first of the framework’s three components, is an organisational assessment. According to the Quality magazine article, it assesses an organisation’s ability to implement and leverage digital twins effectively, has multiple maturity levels, and evaluates digital infrastructure, data management practices and workforce skills. I have deliberately not listed level names: the sources I could retrieve did not enumerate them, and inventing a five-step ladder would be exactly the kind of tidy fabrication that makes maturity models unreliable. Check the DTC toolkit for the authoritative level definitions.

Fidelity is a property of a specific twin, not an organisation. The DTC definition says fidelity must suit the use case and must be validated to be trusted. A thermal twin of a battery pack used for charge scheduling needs different fidelity from the same pack in a safety certification study. The V2 preview promises more guidance on aligning fidelity with use cases, which tells you the current table leaves that mapping largely to the reader.

For validating that fidelity claim, the relevant discipline is verification and validation. Our post on digital twin verification and validation under ASME V&V 40 explains how credibility evidence is tied to model risk. The CPT offers no equivalent evidence framework, and I would argue it should not try; it should point at one.

Trustworthiness is a capability class, not a feature

Putting Security, Privacy, Safety, Reliability, Resilience and Responsibility into the same grid as Dashboards and Gamification is an interesting editorial choice. It declares that trust properties are requirements to be selected and budgeted, exactly like a visualisation layer. In practice these capabilities are cross-cutting: Reliability cannot be bolted onto DS.IR separately from IR.IO, because a stale or wrong signal from the shop floor breaks the whole chain. The article’s own phrasing ties twin reliability to how well the virtual model represents its physical counterpart, and it cites the National Academies idea that uncertainty quantification measures the quality of a prediction.

A useful working rule: every capability you select from the other five categories should have at least one trust capability attached to it in your worksheet. A command-and-control capability (IC.CC) without Safety (TW.SF) and Security (TW.SC) next to it is not a requirement, it is a hazard.

Using the CPT as a maturity probe

Although the CPT is not itself a maturity scale, it is a practical probe for one. Take the 61 elements and, for each one your use case needs, record three states: not present, present manually, present as a governed service. The ratio of governed services to needed capabilities is a crude but honest indicator of twin maturity. I label this an illustrative heuristic of mine, not a DTC metric; its value is that it is auditable and cannot be inflated by adding visualisations.

Mapping the CPT to Real Standards and Platforms

The DTC does not publish a normative mapping from CPT elements to ISO 23247, DTDL, AAS or WoT, and I did not find one. What follows is my own analytical mapping, built from the public definitions of each technology. Treat it as a starting hypothesis for a workshop, not an endorsement by any standards body or vendor.

Figure 3: An analytical digital twin platform mapping. Solid coverage means the standard defines the capability’s information or interface; the absence of an arrow means the capability is left to the implementer.

What each standard actually standardises

It helps to be precise about scope before mapping, because the four technologies sit at different levels.

ISO 23247 is a framework for digital twins of observable manufacturing elements. Its reference architecture, as I read the standard, organises functional entities into domains: user, core, data collection and device control, and the observable manufacturing element itself, with a cross-system layer. It is an architecture and vocabulary, not a data format. The newer parts add the digital thread and composition, covered in our posts linked above.

DTDL (Digital Twins Definition Language) is a JSON-LD based modelling language. In DTDL an Interface declares Telemetry, Properties, Commands, Relationships and Components. Azure Digital Twins consumes DTDL models and builds a graph of twin instances with relationships, queries and event routing. For a walk-through, see our DTDL v3 and Azure Digital Twins tutorial.

The Asset Administration Shell (AAS) from the IDTA is a metamodel for the digital representation of an asset, built from submodels whose semantics reference external dictionaries, plus APIs for interacting with shells and submodels. Our posts on AAS submodels and the BaSyx tutorial cover the practical side.

W3C Web of Things describes things through a Thing Description exposing properties, actions and events, with protocol bindings, which is a uniform interface description rather than a twin model. See our WoT reference architecture post.

The mapping table

CPT element	ISO 23247	DTDL / Azure Digital Twins	AAS	W3C WoT
DS.RP model repository	Implied in core entity services	Model repository with versioned Interfaces	AAS types and submodel templates	Thing Models
DS.IR instance repository	Core domain twin state	Twin graph instances	AAS instances and submodel elements	Not defined; Thing Description is an interface, not state
DS.ON ontology management	Vocabulary, not a store	JSON-LD context, semantics via model design	Semantic IDs to external dictionaries	JSON-LD context and vocabularies
DS.CX contextualization	Data collection and device control plus core	Relationships and components	Submodel semantics	Annotations in TD
IR.IO OT/IoT integration	Data collection and device control domain	Ingestion routed from IoT services (implementation specific)	Not a transport; AAS describes, gateways connect	Protocol bindings (HTTP, MQTT, CoAP and others)
IR.DT twin-to-twin	Composition in Part 6	Relationships across twins	Relationships between shells	Links between Things
IR.AS API services	User domain interfaces	Management and query APIs	Standardised AAS API	Properties, actions, events as interface
IC.CC command and control	Device control	Commands on Interfaces	Operations in submodels	Actions
IC.CS composition	Part 6 composition	Components and relationships	Composite structures via relationships	Composition patterns in architecture
MG.DM device management	Device control	Via IoT hub service, not DTDL	Out of scope	Out of scope
TW.SC security	Cross-system concerns	Platform identity and access control	Security guidance and access rules	Security schemes in TD
IC.SM simulation, IC.AI, IC.PR	Application services	Left to external services	Referenced via submodels	Out of scope
UX.* visualization	User domain	Separate tooling, for example 3D scene tooling	Out of scope	Out of scope

Two rows in the table deserve a flag. The ISO 23247 cells are my interpretation of the standard’s functional view rather than a published crosswalk, and the “Azure” cells assume Azure Digital Twins specifically; a different platform consuming DTDL would differ.

What the mapping reveals

The pattern is clear when you read the columns. No single standard covers more than a fraction of the grid. DTDL and AAS are strong on DS.RP and DS.IR, the model and instance repositories. WoT is strong on IR.AS and IR.IO as an interface description. ISO 23247 offers the architectural frame but leaves implementation open. And the large, expensive parts of the CPT, namely Intelligence, UX, Management and most of Trustworthiness, are almost entirely uncovered by any information-model standard.

That is not a flaw in the standards; they were never meant to be platforms. It is, however, the strongest argument for a capability catalogue: it makes visible how much of your twin lives in no standard at all and must be bought, built, or integrated. A procurement team reading “supports DTDL” or “AAS compliant” on a datasheet learns about perhaps six to ten CPT elements out of 61.

Platform categories against the CPT

Rather than rating named products, which would require verified, current feature claims I cannot make for every vendor, consider the typical platform archetypes and the CPT regions they tend to cover.

Platform archetype	Typically strong	Typically thin or absent
Cloud twin graph service	DS.RP, DS.IR, IR.DT, IR.AS, event routing	Simulation, MG.DM beyond IoT hub, UX beyond basic
Industrial data platform / DataOps	DS.AI, DS.ST, DS.TR, DS.CX, IR.IO, IR.EG	Twin model semantics, composition, prescriptive logic
Simulation suite	IC.SM, IC.MA, DS.SR, UX.AV	Streaming ingestion, IR.ET, governance
AAS server stack	DS.RP, DS.IR for asset metadata, IR.AS	Streaming, analytics, UX
PLM / engineering platform	IR.EG, DS.RP lineage, DS.SR	Real-time processing, OT integration
Game engine / spatial layer	UX.GE, UX.3R, UX.XR, UX.AV	Everything on the data side

These are generalisations about categories of product, labelled as such. Any real evaluation should score each candidate against your selected elements with evidence from documentation or a proof of concept.

A Worked Requirements Exercise: From Use Case to Gap List

Theory is cheap, so here is the CPT used the way it was designed. The scenario is hypothetical and every number in it is illustrative, not drawn from a real project: a plant with 40 packaging lines wants a twin that predicts unplanned stoppages on a filler-capper module and recommends maintenance windows.

Figure 4: A capability driven selection process. Required capabilities minus owned capabilities gives the gap list, and each gap gets a build, buy or defer decision.

Step 1: write the use case as an outcome

The DTC definition says twins are outcome driven, so the use case statement must be measurable. “Reduce unplanned stoppages on the filler-capper by an agreed percentage within two quarters, by predicting failures at least 24 hours ahead with an agreed precision floor.” The percentage and the horizon are placeholders; the point is that every selected capability must trace to this sentence.

Step 2: select capabilities

Walk the six categories and ask of each element, “does the outcome fail without this?” For the stoppage use case, a reasonable first pass looks like this.

Category	Selected elements	Why
Data Services	DS.AI, DS.ST, DS.TR, DS.CX, DS.RP, DS.IR, DS.SA, DS.AR	Ingest vibration and PLC signals, contextualise with asset hierarchy, keep model and instance stores, tier history, version the predictive model
Integration	IR.IO, IR.ET, IR.AS	Read PLCs, pull work orders from the maintenance system, expose results
Intelligence	IC.PR, IC.PS, IC.AL, IC.BR	Predict, recommend windows, alert, enforce maintenance rules
User Experience	UX.DB, UX.RM	Line dashboard and live monitoring
Management	MG.DM, MG.EL, MG.DG	Gateway lifecycle, audit trail, data ownership
Trustworthiness	TW.DS, TW.SC, TW.RL, TW.SF	Device identity, access control, signal reliability, safe interlock boundaries

That is 26 of 61 elements. Roughly 43 percent of the grid is relevant, and it took one workshop hour. Equally important is what was excluded: federated learning, distributed ledger, gamification, XR and game engine visualisation. Recording those exclusions with reasons is as valuable as the inclusions, because it stops scope creep when a vendor demo makes them look attractive.

Notice IC.CC is also excluded. The twin recommends windows; it does not command the line. The DTC’s own description limits command and control to IoT and non-plant controls, so including it here would have created a safety conversation nobody planned for.

Step 3: subtract what you already own

Suppose the plant already has a historian (covers DS.AI, DS.SA partly), a CMMS (IR.ET), and an identity provider (TW.SC partly). The gap list shrinks, but the word “partly” is where projects hide risk. The worksheet should record not just presence but the interface: a historian that stores data does not necessarily stream it (DS.ST), and a CMMS with a read-only report export is not an integration with write-back.

A minimal machine-readable form of that worksheet keeps the exercise honest and diffable. The structure below is my own convention, not a DTC format.

use_case: "Predict filler-capper stoppages 24h ahead"   # illustrative
cpt_version: "1.1"
capabilities:
  - id: DS.ST
    required: true
    owned: partial          # none | partial | governed
    evidence: "Historian stores 1 Hz data; no streaming API"
    decision: build         # build | buy | defer
    trust_attached: [TW.RL, TW.SC]
  - id: IC.PR
    required: true
    owned: none
    evidence: "No model repository or serving"
    decision: buy
    trust_attached: [TW.RL, TW.RS]
  - id: IC.CC
    required: false
    reason_excluded: "Advisory only; no actuation in scope"

import yaml, collections

doc = yaml.safe_load(open("cpt_worksheet.yaml"))
req = [c for c in doc["capabilities"] if c.get("required")]
score = {"none": 0, "partial": 0.5, "governed": 1}
coverage = sum(score[c["owned"]] for c in req) / len(req)
gaps = [c["id"] for c in req if c["owned"] != "governed"]
unprotected = [c["id"] for c in req if not c.get("trust_attached")]

print(f"coverage {coverage:.0%}, gaps {gaps}")
print("selected capabilities with no trust attached:", unprotected)

The script prints a coverage ratio, the gap list, and any selected capability with no trust capability attached. The 0, 0.5, 1 weights are arbitrary; their job is to make progress visible between workshops, not to be a metric you publish.

Step 4: map the gaps to the stack, then to products

Only now does the Platform Stack come into play. Each gap is assigned to a layer, and candidate products are scored against the specific elements. The DTC article notes the Platform Stack defines layers forming a full-stack platform but the retrieved text does not name them, so consult the DTC’s published stack description for the canonical layer list. In practice, teams usually reduce this to four questions per gap: can an existing service be extended, does a standard-based component exist, is a managed service acceptable under data residency rules, and who operates it afterward.

The ordering is the lesson. Had the team started with a vendor, DS.CX (contextualisation of PLC tags with asset hierarchy) would likely have surfaced in month five as “we need a data engineer for two quarters”. Starting from the grid, it surfaces in the first workshop.

Trade-offs, Gotchas, and What Goes Wrong

The CPT is useful, but it has real limits. Here is where I have seen, or would expect, trouble.

The model is vague where it matters most

Definitions vary in precision. The DTC page gives short definitions, but some entries have blank “what it means” or “examples” sections in the published text I retrieved (Monitoring and Alerting, Logging, Security, Privacy, Safety, Reliability, Resilience, Business Rules and Data Encryption). A requirements catalogue whose Safety entry is empty is a prompt to think, not a specification.

Boundaries overlap. Dashboards (UX.DB), Business Intelligence (UX.BI), Continuous Intelligence (UX.CI), Real-time Monitoring (UX.RM) and Data Analysis and Analytics (IC.AA) all describe ways of turning data into human insight. Real-time Processing (DS.RT) and Data Streaming (DS.ST) overlap similarly. Two teams will score the same system differently. The fix is to write a one-line local definition per selected element and keep it in the worksheet.

Different abstraction levels share one grid. Data Encryption is a mechanism; Responsibility is a governance posture covering ethics, ESG, explainability and fairness; Gamification is a UX technique. They carry equal visual weight but wildly different effort. Counting elements as if each were the same size, as in my coverage script above, distorts priorities, which is why weights per element are worth adding.

Category assignment is debatable. Search appears as IC.SR in the Intelligence category, though the 1.1 announcement describes it as helping twins navigate and manage complex datasets, which reads like data services. Federated Learning and Distributed Ledger sit in Intelligence, yet they are architectural choices that reshape the Data Services and Trustworthiness stories.

The absence of dependency structure

The periodic table layout implies relationships it does not encode. There is no statement that Ontology Management (DS.ON) is a prerequisite for meaningful Contextualization (DS.CX), or that Federated Learning (IC.FL) depends on Device Management (MG.DM) and strong Device Security (TW.DS). Architects have to supply that dependency graph themselves. A flat checklist invites teams to buy “everything in the Intelligence row” without noticing the data foundations beneath it.

Missing quantitative hooks

The CPT says nothing about latency, throughput, availability targets, retention, or fidelity thresholds. “Real-time” is not a number. The DTC definition insists on a “specified frequency”, but the table does not carry a field for it. In my experience the first place a twin project loses credibility is when a stakeholder hears “real-time” and assumes sub-second while the architecture delivers one-minute batches. Add a numeric target column to your own worksheet for every data and intelligence element.

Maturity is easy to misuse

Maturity models invite scoring theatre. Three failure patterns recur: levels are self-assessed without evidence; the target level is chosen because a competitor claims it; and the goal becomes the next level rather than the outcome. If the organisational maturity score rises while stoppages do not fall, the model is measuring the wrong thing. Tie every maturity step to an outcome metric from the original use case.

Standards coverage is not platform coverage

A frequent procurement error is to treat “supports AAS” or “DTDL compatible” as capability coverage. As the mapping showed, those labels address the model and interface layer, a small part of the grid. The reverse also happens: a capable platform with a proprietary model format may satisfy forty CPT elements today but make DT-to-DT integration (IR.DT) painful tomorrow. Interoperability claims should be tested with an actual exchange of a model or an instance, not a datasheet.

Version drift

The grid has already changed once (1.0 to 1.1), with identifiers renumbered into the category-prefixed scheme, and a V2 is in preparation. Worksheets that cite codes without a version number become unreadable. The cpt_version field in the sample YAML exists for exactly this reason.

It is a requirements tool, not a design

Finally, the CPT deliberately says nothing about how components connect. Two teams can select identical elements and design opposite architectures, one federated with edge twins, the other a central cloud graph. That is by design, and it is why the framework pairs the table with a Platform Stack. If your organisation stops at the grid, you have a shopping list, not an architecture.

Practical Recommendations

Use the CPT as a structured conversation, not a compliance target. Start every twin initiative with the outcome statement, then run a time-boxed workshop with business, operations, IT and security in the same room, and walk all six categories. Record inclusions, exclusions and the reason for each. Attach at least one Trustworthiness element to every selected capability. Add numeric targets wherever the grid says “real-time”, “near real-time” or “low latency”.

Treat standards as constraints on the Data Services and Integration rows, not as a proxy for the whole. If you intend to exchange assets across organisations, favour AAS or an equally open information model for DS.RP and DS.IR. If you are in a Microsoft-centred environment, DTDL with a graph service is a natural fit for the same elements. If you need uniform device interaction across protocols, WoT Thing Descriptions are a good IR.AS and IR.IO building block. Whichever you pick, record the CPT element it serves.

Pair the CPT with a validation approach. For any prediction or simulation element (IC.PR, IC.SM, IC.AI), define the credibility evidence the use case demands before you build, using a risk-informed method such as the one covered in our ASME V&V 40 post.

[ ] Write the outcome statement with a measurable target and a date.
[ ] Record CPT version (1.1 at time of writing) in every worksheet.
[ ] List selected and excluded elements, each with a one-line local definition.
[ ] Attach Trustworthiness elements to every selected capability.
[ ] Add numeric targets (frequency, latency, retention, accuracy) per data and intelligence element.
[ ] Score owned capabilities as none, partial or governed, with evidence.
[ ] Draw the dependency graph the CPT does not give you.
[ ] Map gaps to platform layers before shortlisting vendors.
[ ] Test interoperability claims with a real model exchange.
[ ] Review the worksheet at every phase gate, and check the DTC site for a V2 release.

Frequently Asked Questions

What is the Digital Twin Consortium capabilities periodic table?

It is a technology-agnostic catalogue, published by the Digital Twin Consortium, of the capabilities a digital twin system may need. Version 1.1 organises 61 elements into six categories: Data Services, Integration, Intelligence, User Experience, Management and Trustworthiness. Its purpose is to let teams define requirements from the use case before choosing technology or vendors. It is part of the DTC Composability Framework, alongside a Business Maturity Model and a Platform Stack Architectural Framework.

How many capabilities are in the CPT and what changed in version 1.1?

The DTC’s Composability Framework material cites 61 elements in six categories, and a count of the published capability list agrees. Version 1.1 added Responsibility (ethics, ESG, explainability, fairness) and Search, merged augmented and virtual reality into Extended Reality, moved temporal data stores under Domain Specific Data Management, and replaced sequential numbering with category-prefixed codes. A conversion table maps version 1.0 identifiers to 1.1 for existing worksheets.

Is the CPT a standard like ISO 23247?

No. ISO 23247 is a formal international standard with a defined development and balloting process, whereas the CPT is a consortium-authored framework published by the DTC. It does not specify data formats, interfaces or conformance tests. The two are complementary: ISO 23247 provides an architectural framework for manufacturing twins, while the CPT helps decide which capabilities a given project needs. Neither replaces information models such as AAS or DTDL.

How does the CPT relate to DTDL, AAS and W3C WoT?

They address different layers. DTDL and AAS are information models for describing twins and assets, mostly serving the model and instance repository capabilities (DS.RP, DS.IR). WoT Thing Descriptions describe how to interact with devices and services, serving integration and API capabilities. The DTC does not publish a normative crosswalk, so any mapping, including the one in this article, is an analytical interpretation to be validated in your own context.

Does the CPT include a maturity model?

Not inside the table itself. The Composability Framework includes a separate Business Maturity Model that assesses an organisation’s ability to implement and use digital twins, covering digital infrastructure, data management practices and workforce skills across several maturity levels. The CPT supplies the capability vocabulary, while fidelity is treated as a per-use-case property that must be validated. A coverage ratio per use case is a practical, auditable complement.

What is on the roadmap for version 2?

The DTC has previewed goals of better interoperability and AI enhancements, stronger coverage of geospatial and spatial computing, more guidance on aligning fidelity with use cases, and a focus on user experience and faster development. I found no dated V2 release or final element list while researching, so treat those as announced intentions rather than published content, and check the DTC site for current status.