AAS Metamodel 3.2 (IDTA Release 26-01): What Changes for Digital Twin Teams in 2026

Read the release announcement and AAS metamodel 3.2 looks like a housekeeping release: two attributes, one enumeration value, one new annex. Read the official change notes and a different picture appears. The only change the specification itself flags as not backward compatible is not one of the three headline items — it is a quiet edit to Range. Meanwhile two brand-new constraints, a formalised idShort rule and a minor-version bump in every semantic identifier will each reject data that a 3.1 validator accepted yesterday. And the two new timestamps are not metadata garnish: an entire new family of API operations in IDTA-01002 v3.2 is built directly on top of them.

This post is the 3.1 → 3.2 diff that the release notes do not give you, plus a migration order that survives a mixed fleet.

What this covers: every change in the official change notes, why three of them break real consumers, what the EN 18223 annex actually does to your architecture, the honest state of BaSyx / AASX Package Explorer / aas-core tooling, and a ten-step migration sequence.

Context and Background

The Asset Administration Shell is standardised as IEC 63278 and elaborated in the IDTA specification series, where Part 1 (IDTA-01001) defines the metamodel, Part 2 (IDTA-01002) the API, Part 4 the security model and Part 5 the AASX package format. Version 3.0 was the line in the sand: it is the version the open-source ecosystem actually implemented, and it is the version most production deployments still run. Since then IDTA has shipped 3.1, three bugfix releases in the 3.1 line, and now 3.2 as part of Release 26-01 of the Specifications of the Asset Administration Shell, published in July 2026.

That cadence matters more than any individual change, because it has quietly created a version-skew problem. A typical industrial estate now contains a 3.0 package explorer, a 3.0-generation SDK inside a bespoke connector, a server built against 3.1, and a partner who has just upgraded to 3.2 because their customer asked for a digital product passport. These are all “AAS version 3” systems. They are not interchangeable.

The specification itself now acknowledges the risk. One of the change notes for 3.2 adds an explicit statement to the versioning section that bugfix releases are not necessarily backward compatible. That is an unusual thing for a standards body to write down, and it is the single most useful sentence in the release for anyone planning an upgrade. It means you cannot treat the third digit as a free upgrade, and it means “we’re on 3.1” is not a sufficient description of what your fleet runs.

Two things make 3.2 different in kind from 3.1. First, it is the release where the metamodel starts serving a regulatory consumer rather than only an engineering one: the new annex maps the AAS onto EN 18223, part of the CEN/CENELEC JTC24 digital product passport series. Second, it is the release where the metamodel and the API spec become tightly coupled — the API’s new change-tracking operations cannot exist without the metamodel’s new timestamps.

If you need the conceptual foundations first, our guide to AAS submodels and submodel templates covers the structure this post assumes you already know, and our comparison of AAS, DTDL and OPC UA information models explains why the AAS metamodel is shaped the way it is.

What actually changed in AAS metamodel 3.2

Direct answer: AAS metamodel 3.2 adds createdAt and updatedAt to AdministrativeInformation, adds the value Batch to the AssetKind enumeration, adds constraints AASd-137 and AASd-138, formalises a two-character minimum for idShort, removes the implicit-infinity rule from Range (the only change marked non-backward-compatible), and adds an annex mapping the AAS onto EN 18223 for digital product passports.

The official change notes split the release into major changes, minor changes and bugfixes, then give three tables: changes in the metamodel, new elements in the metamodel, and new or changed constraints. It is worth reading those tables rather than the prose, because the prose and the tables disagree about what is significant.

Figure 1: How each class of change in AAS metamodel 3.2 propagates into a different consumer layer.

Figure 1 groups the release into five change classes and traces each one to the layer of your stack that first notices it. The two new AdministrativeInformation attributes feed the API’s change-tracking and point-in-time-retrieval operations. The new AssetKind value hits application code with exhaustive branching and any user interface with a fixed option list. The new constraints hit validators. The Range edit hits anything that reads bounded values. The DPP annex hits the part of your architecture that talks to regulators rather than to machines. The point of the diagram is that no single team sees the whole release — which is precisely why version bumps like this one get mishandled.

The three headline changes, in the specification’s own words

The release body names three changes explicitly: changed attributes for creation and update date in AdministrativeInformation; a new value in the AssetKind enumeration, Batch, to support digital product passports; and a new annex section on metamodel and payload mapping for implementing the DPP based on EN 18223.

The change-notes tables sharpen this. AdministrativeInformation/createdAt is listed as a new element with the rationale “to enable performant querying of new objects”. AdministrativeInformation/updatedAt is listed with the rationale “to enable DPP methods”. Both carry the data type DateTimeUtc, and both take semantic identifiers under the https://admin-shell.io/aas/3/2/AdministrativeInformation/ namespace. AssetKind/Batch is listed as a new enumeration value “to support DPP applications”. Neither is marked non-backward-compatible in the table.

That last point deserves scrutiny, because “backward compatible” in a metamodel table means something narrower than most engineers assume. It means a 3.1 document remains a valid 3.2 document. It says nothing about whether a 3.1 consumer survives a 3.2 document. Adding an enumeration value is forward-breaking, not backward-breaking, and the table is only tracking one of those directions.

The changes the headlines omit

Read past the three named items and the release gets more interesting.

Range loses two conditions: “If the min value is missing, the value is assumed to be negative infinite” and “If the max value is missing, the value is assumed to be positive infinite.” The change-notes table flags this in its Nc column — explicitly not backward compatible — with a note that Range is a submodel element in the “experimental” state, so non-backward-compatible changes are permitted, and a second note pointing out that data types such as float already carry infinity in their value range and should be used when infinity is actually needed.

The practical effect is a semantic silent-change, which is the worst kind. A 3.1 document with a Range that omits max meant “unbounded above”. The same bytes under 3.2 mean “max is absent”, full stop. Any rule engine, alarm threshold or acceptance check that relied on the implicit-infinity reading now computes a different answer from identical data, with no parse error to warn you.

Two new constraints arrive. AASd-137 says that for external references, the value of any Key/type contained in the reference shall not be one of the AasReferables. AASd-138 says a SubmodelElementList within a submodel of kind Template, or as part of an OperationVariable, shall have exactly one element. Both are marked (x) in the change notes, meaning the specification considers them to have been implicitly contained before and therefore formally backward compatible.

Treat that classification as a statement about intent, not about your fleet. A constraint that was implicit was, by definition, not enforced by most validators. The moment your validator learns AASd-137 and AASd-138, files that have been sitting in your package store for two years can start failing. “Formally backward compatible” and “will not break your CI pipeline” are different claims.

The same pattern repeats with AASd-002. Its description now states that idShort shall consist of at least two characters, matching what the regular expression always required. Nothing changed in the regex. What changed is that implementers who read the prose rather than the pattern — and tools that hand-rolled the check — now have to agree with it. Single-character idShort values are a common artefact of hand-authored test data and of importers that derive short names from column headers.

The semantic-identifier namespace moves with the minor version

Every metamodel element carries a semantic identifier that embeds the minor version: https://admin-shell.io/aas/3/2/AdministrativeInformation/createdAt, https://admin-shell.io/aas/3/2/AssetKind, https://admin-shell.io/aas/3/2/SubmodelElement. Under 3.1 the same elements lived under .../aas/3/1/....

This is why 3.2 is more disruptive than the change count suggests. Any system that pattern-matches on metamodel semantic IDs — mapping layers, RDF pipelines, rule engines keyed on semanticId strings, RAG corpora built over NodeSet-style exports — has hard-coded a minor version somewhere. The specification acknowledges the problem in this release by rewriting constraint AASd-116 to use https://admin-shell.io/aas/3/x/AssetInformation/globalAssetId, where x is the minor version of the specification in use, and the change note says the description was “made more generic to avoid frequent updates”.

That is a good fix for the specification text. It is not a fix for your code. If your matcher does a string equality check against a 3/1 URL, a 3.2 payload simply will not match, and the failure mode is usually a silently empty result rather than an exception.

Everything else in the release, briefly

The remaining change notes are smaller but not all cosmetic. The Value-Only JSON Schema gains referredSemanticId on the Reference data type. A new explanatory section covers Value-Only for operations. Constraint AASd-129 gains an exception for submodel elements that are part of an OperationVariable. A minimum recursion depth of 32 for container elements is now stated as something implementations should support, with a note that certification should therefore test at most 32 recursion cases. Operations in a submodel with kind=Instance are now handled identically to operations in submodel templates. The description of the ContentType data type was trimmed of MIME-type explanation, the definition of “capability” changed, and the terms submodel and submodel element were renamed to Submodel and SubmodelElement throughout for conformance with IEC 63278-1 — which reformulated a number of constraints as a side effect.

Three bugfixes correct semantic identifiers that were wrong in 3.1: AasNonContainerSubmodelElements/Blob, Extension/name and HasSemantics/supplementalSemanticId. If you built anything against those IDs in the 3.1 line, the correct value has changed underneath you — which is exactly the scenario the new “bugfix releases are not necessarily backward compatible” note exists to warn about.

The three changes that actually bite

Three of these changes have a blast radius wider than their line count. They are worth working through individually, because each one fails in a different way and needs a different countermeasure.

AssetKind gaining Batch breaks consumers, not producers

AssetKind was a small closed enumeration. Small closed enumerations invite exhaustive handling — a switch with no default, a match the compiler checks for completeness, a JSON Schema enum array, a dropdown with a fixed option list. All four are good engineering practice against a stable enumeration. All four are now liabilities.

Figure 2: Four common ways of handling AssetKind, and what each does when the new Batch value arrives.

Figure 2 traces the same incoming payload through four consumer styles. A compiler-checked exhaustive match throws at parse time; so does a schema enum validation at the ingress boundary. Both fail loudly, which is the good outcome — you get a stack trace with the offending value in it, and the fix is localised to one branch. A default branch that falls through to Instance, and a user interface dropdown that silently drops an unrecognised value on save, both fail quietly. Those are the expensive ones, because the corruption is written back to the store and only surfaces later, in a different system, as a wrong answer.

The wrong answer here is specific and consequential. The DPP annex in IDTA-01001 publishes a mapping table from the EN 18223 granularity field to AssetKind: Item maps to Instance, Model maps to Type, and Batch maps to Batch. The table also notes that Role and NotApplicable have no ESPR equivalent — Role is recorded as having no equivalent, and NotApplicable as not foreseen. So a consumer that swallows Batch into Instance does not produce a crash; it produces a digital product passport that claims item-level granularity for a batch-level product. That is a compliance defect wearing the costume of a working system.

There is a second-order effect worth planning for. AssetKind is frequently used as a filter key in registry queries and discovery services — “give me all type-level shells for this product family”. A new value expands the domain of that filter. Queries written as an inclusion list keep working and silently exclude batches; queries written as an exclusion list start including them. Neither is wrong in general; both are wrong for somebody.

The countermeasure is not “add a case for Batch”. It is to stop treating AssetKind as closed. Parse it into a type with an explicit unknown arm, log the raw string when you hit that arm, and make the unknown arm refuse to write back rather than defaulting. That posture survives the next enumeration value too, and the IDTA specification tree already shows a v3.3 in progress.

The timestamps change what “unchanged” means

createdAt and updatedAt look like audit fields. They are not, or rather they are not only that, because IDTA-01002 v3.2 builds real API surface on them.

The API change notes are explicit: new experimental operations GetAllAssetAdministrationShellsRecentChanges, GetAllSubmodelsRecentChanges and GetAllConceptDescriptionsRecentChanges “rely on the createdAt and updatedAt attributes of AdministrativeInformation introduced in V3.2 of the metamodel”. The same release adds input parameters to GetAllAssetAdministrationShells, GetAllSubmodels and GetAllConceptDescriptions, and adds filtering for recently changed objects to GetAllAssetAdministrationShellDescriptors and GetAllSubmodelDescriptors. It also adds two point-in-time operations, GetAssetAdministrationShellVersionByIdAndDate and GetSubmodelVersionByIdAndDate.

Before 3.2, incremental synchronisation against an AAS repository meant polling everything and diffing it yourself, or bolting a proprietary change feed onto the side. After 3.2, there is a standard way to ask “what moved since this timestamp”. That is a genuine capability upgrade, and it is the reason the timestamps are worth implementing even if you never touch a product passport.

The catch is that the capability is only as good as your write path. A RecentChanges query against a repository whose writers do not set updatedAt returns an empty page, not an error. A synchronisation job built on that query will report “nothing changed” forever, cheerfully, while data drifts.

The metamodel’s own explanatory text — new in 3.2 — is unusually direct about the semantics, and it is worth internalising before you wire anything up:

• createdAt is bound to the identity of the object itself, not to its individual version states. Version and revision may change repeatedly; createdAt stays fixed at the moment the object was first created.
• updatedAt tracks when relevant modifications occur, and can never precede createdAt.
• Note 5 states plainly that not every change to an object’s data will necessarily trigger a new release — an update of version or revision — or an update to the updatedAt timestamp. version, revision, createdAt and updatedAt “should be treated as business values, not technical system values”. Their purpose is to mark significant, business-relevant events.
• The same section notes that version and revision are stored as numerical integer types rather than strings, specifically so that sorting and logical comparison behave, and that templateId is so far applicable only to submodels.

That “business values, not technical system values” sentence is the one that will start arguments in your team, and it should. It means updatedAt is explicitly not a row-modified trigger. If your persistence layer stamps it on every write — including a no-op PUT, a cache-warming rewrite, or a bulk re-serialisation during a migration — you have populated a business field with technical noise. Downstream, a RecentChanges consumer will process a storm of pseudo-changes, and a DPP ReadDPPVersionByIdAndDate call will select a “version” that differs from its neighbour by nothing at all.

The inverse failure is just as real. If updatedAt only moves when a human clicks “publish”, then machine-driven telemetry updates never surface in change feeds, and a consumer that trusts the feed for freshness will serve stale values.

There is no universally correct answer here, which is exactly why it needs an explicit decision. The one thing you should not do is let the semantics emerge accidentally from whichever ORM hook happened to be convenient.

The same reasoning propagates into caching. Once a document carries an authoritative modification timestamp, the natural move is to derive HTTP ETag or Last-Modified values from it. That works — but only if updatedAt is a superset of every change a cache consumer cares about. Under the specification’s “business value” reading, it is deliberately not a superset. Deriving cache validators from updatedAt therefore serves stale content by design. Derive them from a technical revision counter you control, and keep updatedAt for the business question. Two clocks, two purposes, documented.

The DPP annex turns the shell into a regulatory artifact

The third headline change is a new annex, and annexes rarely feel urgent. This one is different, because it changes who your data model has to satisfy.

The annex opens by listing the eight standards developed to support digital product passport implementation, as published by IDTA: EN 18219 (unique identifiers), EN 18220 (data carriers), EN 18216 (data exchange protocols), EN 18222 (APIs for passport lifecycle management and searchability), EN 18223 (system interoperability), EN 18221 (data storage, archiving and data persistence), and two listed as not yet released at the time of writing — EN 18239 (access rights management, information system security and business confidentiality) and EN 18246 (data authentication, reliability and integrity). The IDTA-01001 annex maps EN 18223; the companion annex in IDTA-01002 maps EN 18222.

The single most important architectural statement in the annex is this: an Asset Administration Shell is not, by itself, a digital product passport. A passport can be derived from a shell, provided the shell carries both the submodels holding the regulation’s required data points and a DPP metadata submodel. IDTA recommends the predefined submodel template IDTA-02099-1, with idShort DppMetadata, derived from the Digital Nameplate template.

The structural tension the annex is resolving is worth stating plainly, because it explains several otherwise odd design choices. The AAS is modular — a container of independently identifiable, independently permissioned, independently reusable submodels. The JTC24 specification assumes a monolithic document. The annex’s answer is that the AAS assembles the monolith on demand: register submodels against a shell, then aggregate their payloads into the single JSON document the regulation expects. The annex is candid that a compliant passport must validate against more than one schema — the generic schema implied by EN 18223, the schema from the relevant vertical delegated act, and schemas from relevant horizontal regulations.

The serialisation mapping is where an existing AAS implementation gets a pleasant surprise and an unpleasant one. The pleasant surprise: what EN 18223 calls “compressed” — and makes mandatory — is what the AAS calls Value-Only, and the annex states that the Value-Only serialisation of the DppMetadata submodel corresponds directly to the DPP header fields in EN 18223 Table 1, with no additional header transformation needed for either representation. EN 18223’s optional “expanded” form maps onto the AAS “Normal” form.

The unpleasant one: “corresponds directly” applies to the header, not to the content. The annex documents concrete divergences for content submodels. Multi-language values differ structurally — the AAS serialises a MultiLanguageProperty as a named object containing per-language entries keyed by ISO 639-1 language code, while EN 18223 uses a list of objects each carrying explicit value and language members. Documents differ too: EN 18223’s RelatedResource carries resourceTitle and language alongside contentType and url, and the AAS File submodel element has no home for either, which is why the annex points at the Handover Documentation template (IDTA-02004) for anything richer. In the expanded form, attribute names differ across the board — idShort versus elementId, modelType versus objectType, semanticId versus dictionaryReference — semanticId is a Reference object in the AAS but a plain string in EN 18223, and the XSD type prefix is xs: in the AAS against xsd: in JTC24.

None of that is hard. All of it is a transformation layer that somebody has to own, test and version. Budget for it as a component, not as a serialiser flag. If you want the data-model side of this compared against the GS1 approach, we cover that separately in our digital product passport data model breakdown; the point here is narrower, namely what the 3.2 version bump obliges you to build.

How the timestamps and the DPP annex meet

The two changes are not independent, and the API annex makes the connection concrete.

Figure 3: The DPP composition read path, and where the new AAS metamodel 3.2 timestamp does the work.

Figure 3 walks the sequence the IDTA-01002 annex describes for resolving a scanned product identifier into a passport document. A client obtains a product identifier — typically from a data carrier such as a QR code — and calls ReadDPPByProductId. The DPP service invokes SearchAllAssetAdministrationShellIdsByAssetLink on the AAS Discovery Service, passing the product identifier as globalAssetId. Discovery returns candidate shell identifiers. The service then either fetches the shell descriptor from the registry to obtain endpoints, or goes directly to the repository. It retrieves the relevant submodels, serialises the DppMetadata submodel in Value-Only to form the header, serialises each content submodel in the requested representation keyed by its semanticId, and merges the result into one document.

The timestamp enters on the historical path. EN 18222 defines ReadDPPVersionByIdAndDate for retrieving the passport as it stood at a point in time. The annex specifies that an implementation shall, for each submodel, select the version whose updatedAt timestamp is less than or equal to the requested date — achievable via the date query parameter, which maps to the new GetAssetAdministrationShellVersionByIdAndDate and GetSubmodelVersionByIdAndDate operations.

That is a load-bearing dependency. Regulatory point-in-time reconstruction is implemented by selecting on a field that the metamodel describes as a business value, updated at the implementer’s discretion. Get the semantics wrong and the answer to “what did this passport say in March” is wrong — and it is wrong in a context where the archiving requirements of EN 18221 apply and, per the annex’s compliance section, implementations must maintain a complete audit trail.

The annex adds two further constraints that are easy to miss. Write operations should be atomic, rolling back all preceding changes if any step fails — which is a real demand when a single logical passport write fans out into one shell and several submodels across potentially separate repositories. And deletion is not simply a supported operation: applicable regulations may prohibit deleting a passport while the product is in use or within a retention period, and the annex states that implementations shall enforce those restrictions regardless of whether DeleteDPPById is exposed.

The toolchain reality check

A specification is only as migratable as the tools that implement it. Here is what the projects actually say today, checked against their own repositories rather than against roadmap posts.

Component	State today	What it means for a 3.2 migration
IDTA-01001 metamodel	v3.2 published as part of Release 26-01; a v3.3 already appears as “in progress” in the specification tree	The spec is ahead of the ecosystem. Plan for a moving target, not a destination.
IDTA-01002 API	v3.2 published, with RecentChanges, point-in-time retrieval, signing profiles, query filters and the EN 18222 DPP annex	The API changes are the reason to care about the metamodel changes.
Eclipse BaSyx Java Server SDK	Still on the 2.0.0-milestone pre-release line; the most recent milestone notes cover registry descriptor synchronisation and MQTT eventing, not metamodel v3.2	No released BaSyx build claims v3.2 metamodel support. Treat 3.2 fields as unsupported until a release note says otherwise.
Eclipse AASX Package Explorer	Development moved to eclipse-aaspe/package-explorer; the original admin-shell-io repository is archived. The README states current development “only supports AAS V3”	No stated v3.2 support. Also check that your team is not still running a build from the archived repository.
aas-core3.0 SDK family	The Python SDK README states it is “a software development kit to manipulate, verify and de/serialize Asset Administration Shells based on the version 3.0 of the meta-model”	The generated SDKs target 3.0. They have no createdAt, no updatedAt and no AssetKind.Batch. This is the biggest practical gap.

The aas-core row is the one that changes plans. These SDKs are generated by aas-core-codegen from a formalised meta-model, and the whole family — C#, Go, Java, TypeScript, Python — is pinned to the 3.0 meta-model by construction. They are widely embedded, precisely because generated code is reliable.

Do not guess what a 3.0-generation deserialiser does with a 3.2 document containing "createdAt" inside administration, or "assetKind": "Batch". Generated deserialisers vary in how strictly they treat unknown keys and unknown enumeration literals, and the answer determines whether your integration silently drops regulatory metadata or rejects the payload outright. Write the test, in your language, against your pinned version, before you write the migration plan. Two documents and one test run will tell you which failure mode you own.

The same discipline applies to the schema artifacts. The 3.2 release ships JSON, XML and RDF schema files alongside the normative sources. Point your validator at the 3.2 schemas in a non-blocking mode first and count the failures across your existing corpus. The failure count from AASd-002, AASd-137 and AASd-138 against real production data is the actual size of your migration — and it is knowable today, before you change a single line of application code.

A migration order that survives a mixed fleet

The instinct with a metamodel bump is to upgrade the server first, because that is where the version number lives. That is the wrong order. A server that emits 3.2 documents into a fleet of 3.0 and 3.1 readers has converted a planned migration into an unplanned incident.

Figure 4: A migration order for AAS metamodel 3.2 that keeps readers ahead of writers at every step.

Figure 4 sequences the work so that every step makes consumers more tolerant before it makes producers more expressive. The governing rule is simple: readers before writers, validators before both.

Start by pinning an explicit schema version per store, per repository and per integration — written down, not inferred. Most fleets discover at this step that they do not actually know what version several components speak, and that discovery alone is worth the exercise.

Upgrade validators next, in report-only mode. This is where AASd-137, AASd-138 and the idShort minimum surface, and it is far better to see them as a CI report than as a production rejection. Scan the whole corpus, not a sample; constraint violations cluster around whichever importer or hand-authored template produced them, so a sample either misses them entirely or wildly overstates them.

Fix what the scan finds — short idShort values, external references that use referable key types, template-scope SubmodelElementLists with the wrong cardinality — and separately audit every Range that omits a bound. For each one, decide whether the intent was genuinely unbounded, in which case the value should move to a data type that carries infinity, or whether a bound was simply never filled in.

Then make consumers Batch-aware, everywhere, before anything emits Batch. That means application switches, schema enumerations, registry filters and user-interface option lists — and it means auditing the filter semantics, not just adding a case.

Only now touch the write path. Decide and document what updatedAt means in your system, implement it, and backfill existing objects. Backfill deserves a moment of thought: setting updatedAt to the migration timestamp for every object makes the entire fleet look like it changed at once, which will stampede any consumer you later point at RecentChanges. Prefer backfilling from whatever technical modification record you already hold, and where you have nothing, consider leaving the field absent rather than asserting a false business event.

With the write path trustworthy, enable RecentChanges consumers, add the DppMetadata submodel where passports are actually required, and only at the end flip readers to the 3.2 namespace.

A word on mixed-fleet validation, because this is where most teams improvise badly. Do not build one validator that tries to be version-agnostic. Build a validator per version and route documents to it based on a declared version, defaulting to the strictest version you support when the declaration is missing. Version-agnostic validators degrade toward validating nothing, because every version-specific rule becomes a special case that someone eventually disables to unblock a build. Three strict validators and a router is less code than one permissive validator with a decade of exceptions in it, and it gives you something a single validator never can: an honest per-version conformance report for your fleet.

Trade-offs, gotchas, and what goes wrong

The “backward compatible” label measures the wrong direction. The change-notes tables track whether old documents remain valid under the new specification. Almost every real incident during a metamodel upgrade runs the other way: a new document meeting an old consumer. Read the tables, then re-read them asking the forward question.

Constraints marked (x) are the most dangerous kind. AASd-137 and AASd-138 are classified as formalisations of rules that were already implicit, which is why they are considered backward compatible. But implicit rules are unenforced rules, and unenforced rules are violated. The (x) marker tells you the specification did not change its intent; it tells you nothing about whether your data complied.

updatedAt will be implemented as a database trigger, and it should not be. This is the single most likely defect in the whole migration, because stamping a modification timestamp on write is such an obvious, natural, well-understood thing to do. The specification explicitly frames these as business values marking significant, business-relevant events. The gap between those two readings is invisible until a change feed floods or a point-in-time passport query returns a version nobody recognises.

Semantic-ID matching is where version skew hides. A string comparison against .../aas/3/1/... does not throw when it meets a 3/2 payload. It returns nothing. Grep your codebase for admin-shell.io/aas/3/ and look at every hit; if any of them is an equality check against a fixed minor version, that is a latent outage.

Enumeration handling is not a one-time fix. AssetKind gained a value in 3.2 and the specification tree already shows v3.3 in progress. If your response to Batch is to add one case, you will do this again. Design for the unknown arm once.

The DPP annex is a recommendation, not the only path. The annex is explicit that it describes a single recommended approach to harmonise implementations, and that other methods may exist. It is a strong recommendation and interoperability argues for following it — but it is not a claim that alternatives are non-conformant, and vendors will sometimes present it as one.

The generated-SDK gap is structural, not temporal. The aas-core family is pinned to the 3.0 meta-model by generation, so this is not a matter of waiting for a patch release; it needs a regenerated family from an updated meta-model. Plan for the possibility that your SDK stays on 3.0 for a while, and decide now whether your 3.2 fields live inside the SDK’s object model or alongside it.

Atomicity across repositories is your problem. The DPP write path decomposes one document into a shell plus several submodels, and the annex says those writes should be atomic with rollback on failure. If your shells and submodels live in different repositories, no part of the AAS specification provides that transaction for you.

Practical recommendations

Treat this as a data-quality project with a version number attached rather than as a version upgrade. The specification changes are small; the state of your existing corpus is the variable, and it is measurable today.

Run the 3.2 schemas over everything you hold, in report-only mode, before you plan anything. The count of AASd-002, AASd-137 and AASd-138 violations is your real scope. Then decide the updatedAt question deliberately, write it down where the next engineer will find it, and keep a separate technical revision counter for caching and replication so the business field is never asked to do a technical job.

Upgrade in the order readers, validators, writers. Make every consumer tolerant of an unknown AssetKind before any producer emits Batch. And verify tool support from release notes and READMEs rather than from roadmap decks — at the time of writing, none of the three major open-source components announces metamodel v3.2 support.

A checklist to work through:

• [ ] Inventory every component and record the exact AAS version it reads and writes.
• [ ] Run 3.2 JSON, XML and RDF schemas over the full corpus in report-only mode; count violations by constraint.
• [ ] Grep for hard-coded admin-shell.io/aas/3/1/ and 3/0/ semantic identifiers; replace equality checks with minor-version-tolerant matching.
• [ ] Audit every Range that omits min or max and decide bound-or-infinity per instance.
• [ ] Add an explicit unknown arm to every AssetKind parse; make it log and refuse to write back.
• [ ] Review registry and discovery filters that key on AssetKind for inclusion versus exclusion semantics.
• [ ] Decide and document the updatedAt trigger policy; separate it from cache validators.
• [ ] Plan the updatedAt backfill so it does not present the whole fleet as changing at one instant.
• [ ] Test your pinned SDK against a 3.2 document containing createdAt and AssetKind: Batch; record whether it drops or rejects.
• [ ] Stand up one strict validator per version plus a router, rather than one permissive validator.

If you are standing up a server to test any of this, our BaSyx tutorial walks through a working environment you can point a 3.2 payload at.

Frequently Asked Questions

Is AAS metamodel 3.2 backward compatible with 3.1?

Mostly, in the direction the specification measures. The change-notes table marks exactly one metamodel change as not backward compatible: the removal of the implicit-infinity conditions from Range, which the specification permits because Range is in the experimental state. Everything else is classified as compatible or as formalising something already implicit. But that classification only asks whether 3.1 documents remain valid under 3.2. It does not ask whether 3.1 consumers survive 3.2 documents, and that is where upgrades actually break.

What does AssetKind Batch mean and why was it added?

Batch is a new value in the AssetKind enumeration, added to support digital product passport applications. It sits alongside Type, Instance, Role and NotApplicable, and represents an asset identified at batch granularity rather than as an individual item or a product type. The DPP annex maps EN 18223’s granularity field onto AssetKind directly: Item to Instance, Model to Type, Batch to Batch. Without it, batch-level passports had no faithful representation in the metamodel.

Do createdAt and updatedAt replace version and revision?

No. They answer different questions and the specification says so. version and revision describe release state and are stored as integers so they sort and compare correctly. createdAt is bound to the identity of the object and stays fixed at first creation regardless of how the version evolves. updatedAt marks when a relevant modification occurred and can never precede createdAt. The specification also notes that not every data change triggers a version bump or an updatedAt update — all four are business values, not technical system values.

Does Eclipse BaSyx support AAS metamodel 3.2 yet?

Not according to its own release notes. The BaSyx Java Server SDK is still publishing on the 2.0.0-milestone pre-release line, and the most recent milestone notes describe registry descriptor synchronisation and MQTT eventing changes rather than metamodel v3.2 support. The same caution applies to Eclipse AASX Package Explorer, whose README states that current development supports AAS V3 without claiming a minor version, and to the aas-core3.0 SDK family, whose documentation states it targets version 3.0 of the meta-model.

What is EN 18223 and how does it relate to the AAS?

EN 18223 is the system-interoperability standard in the CEN/CENELEC JTC24 digital product passport series, which IDTA lists alongside seven companions covering identifiers, data carriers, exchange protocols, APIs, storage and archiving, access rights and data authentication. The new annex in AAS metamodel 3.2 maps EN 18223’s requirements onto the AAS metamodel. The essential point is that an AAS is not itself a passport: it becomes one when it carries the required content submodels plus a DppMetadata submodel, from which a conformant document can be assembled.

Do I need to migrate to 3.2 right now?

Only if you need what it adds — digital product passport conformance, or standard change-tracking and point-in-time retrieval via the IDTA-01002 v3.2 operations that depend on the new timestamps. There is no deprecation of 3.1 driving urgency. What is worth doing immediately regardless is the diagnostic half: run the 3.2 schemas over your existing data in report-only mode and make your consumers tolerant of unknown AssetKind values. Both are cheap, both are useful on their own, and both are prerequisites whenever you do migrate.

Further Reading

• Asset Administration Shell submodels explained — the structural foundation this post assumes.
• AAS vs DTDL vs OPC UA information models — why the AAS metamodel is shaped the way it is.
• Digital product passport data models: GS1 and AAS compared — the data-model comparison this post deliberately skips.
• Asset Administration Shell with Eclipse BaSyx: a working tutorial — a server to point 3.2 payloads at.
• IDTA-01001 v3.2 Change Notes — the primary source for every change described above.
• IDTA-01001 v3.2 Digital Product Passport annex and the IDTA-01002 v3.2 DPP API annex — the EN 18223 and EN 18222 mappings.

By Riju — about