AAS Studio (operated by Miguel Reis Repo, hereafter "the operator") self-attests conformance with the following standards and regulations as of 2026-08-10. Each line carries a citation pointing at the human-readable evidence on the operator's public website. No claim below is third-party attested unless explicitly stated. Procurement teams requiring formal attestation should contact the operator at miguel.reis@aas-studio.eu.
1. AAS metamodel
AAS V3.1 metamodel — output of https://aas-studio.eu/api/v1/extract conforms to IDTA AAS V3.1 (idShort first-letter rule, AssetInformation.globalAssetId as simple string, key elements with type+value as child elements, embeddedDataSpecifications instead of dataSpecifications).
AASX package format — round-trip with AASX Package Explorer verified for all four shipped submodel templates.
1a. IDTA AAS specification — part-by-part (V3.1)
Part 1 — Metamodel (IDTA-01001, v3.1.2): conformant. Exported environments validate against the official AAS 3.1 XSD plus an AASd-* constraint gate, and against the official IDTA aas-test-engines in CI. Full SubmodelElement coverage incl. Operation input/output/inoutput variables and relationship elements; Referable/Identifiable attributes (displayName, description, administration, supplementalSemanticIds, extensions) emitted in schema order; idShort matches the official pattern exactly.
Part 2 — API (IDTA-01002, v3.1.2): substantial. Repository read profiles (SSP-002) served at /api/v3 with base64url identifiers and cursor paging, plus serialization modifiers $value / $metadata / $reference / $path and the level / extent query parameters. Write profiles (SSP-001) are now served: AAS create/replace/delete (POST/PUT/DELETE /shells) and submodel-element create/replace/delete, under an optimistic-lock + the Part 4 write gate. Discovery (/lookup/shells, assetId→aasId) and Registry register/unregister (/shell-descriptors, synthesized self-descriptors merged with a registered-descriptor store) round out the node; outbound registration to a remote Part 2 registry is also supported. An AASX File Server serves each stored model as a downloadable Part-5 .aasx and accepts uploads stored verbatim — GET /packages (descriptors, filterable by aasId; uploaded + synthesized), GET /packages/{packageId} (download — uploaded byte-for-byte, synthesized as a JSON spec part), and POST / PUT / DELETE /packages (upload / replace / delete, size-capped + Part-4 gated). Standalone-submodel CRUD is now served too — POST /submodels (create-only) and PUT / DELETE /submodels/{id} (optimistic-locked), for submodels not bound to a shell.
Verifiable Credentials & EUDI seam: implemented. The tenant ES256 signing key doubles as a W3C Verifiable Credential issuer — GET /v1/extractions/{id}/credential mints a VCDM 2.0 JWT-VC binding the product identifier + a canonical content hash, and POST /v1/credentials/verify verifies it (key resolved by kid, alg pinned to ES256, alg-confusion rejected). ?format=sd-jwt issues an SD-JWT-VC (selective disclosure: confidential claims become salted _sd digests the holder can withhold), and a public JWKS at /v1/credentials/jwks.json lets a regulator/wallet verify offline with no API key (private key material never served). EUDI trust-list binding + OID4VP presentation remain external follow-ups.
Part 3a — Data Specification IEC 61360 (IDTA-01003-a, v3.1.1): conformant. The full DataSpecificationIec61360 field set (preferredName, shortName, unit, unitId, sourceOfDefinition, symbol, dataType, definition, valueFormat, valueList, value, levelType) is written in schema order and read back losslessly; the data-specification template reference uses the conformant DataSpecificationIec61360 identifier.
Part 4 — Security / Access Rule Model (IDTA-01004, v3.0.2): partial. An attribute-based Access Rule Model + pure evaluation engine (deny-by-default, deny-overrides), with persisted per-tenant custom ALLOW/DENY rules layered on a role-derived baseline (the four app roles map onto rules). Deny-by-default is enforced on the write surface — the v3 submodel-element writes, the session-auth model PUT/DELETE, and shell/descriptor writes — via a single shared guard that resolves the caller's real role and denies unknown roles. The v3.0.2 logical FORMULA is implemented: a rule may carry a boolean condition (and / or / not / eq / ne / in / exists) over subject, object and environment attributes, evaluated on top of the subject/object match, so the engine is genuine ABAC (e.g. "role=recycler OR environment.tier=verified"), fail-safe on a corrupt condition, and backward-compatible. Honest boundaries vs v3.0.2: there is still no canonical text/BNF serialization (the FORMULA lives in the engine + the JSON storage shape, which is an app-defined RC01-flavoured shape, not the spec grammar); FORMULA comparators are string-only (numeric/temporal $lt/$gt pending); and DB-level row-level security remains deferred (ADR 005). DPP read disclosure now flows through the same engine: the four-tier cumulative lattice (public / business / verified / authority) is expressed as FORMULA rules over the requester's tier and the submodel's classification, evaluated deny-by-default, so writes and DPP reads share ONE authorization engine (proven by an exhaustive 16-pair parity test; fail-closed to public-only on any engine error). The raw v3 repository GET surface remains tenant/ownership-scoped rather than rule-evaluated.
Part 5 — Package File Format AASX (IDTA-01005, v3.1): conformant. OPC layout per spec — aasx/_rels/aasx-origin.rels linking the aas-spec part, supplemental files (thumbnail, attachments) wired via aas-suppl relationships, XML or JSON environment — and import follows the relationship chain rather than guessing by filename.
2. IDTA submodel templates
IDTA-02006 — Digital Nameplate: 12 elements per template, all carrying ECLASS IRDIs.
IDTA-02023 — Carbon Footprint: 4/4 elements carry ECLASS IRDIs.
IDTA-02004 — Handover Documentation: 4/4 elements carry ECLASS IRDIs; source PDFs bundled in AASX zip as File submodelElements.
3. IEC 63278 alignment
IEC 63278-1 (AAS metamodel): satisfied transitively via IDTA AAS V3.1.
IEC 63278-2 (Information modelling): ECLASS IRDIs on properties, IDTA URIs on submodels.
IEC 63278-3 (Integration patterns): AASX file export, REST API at /api/v1/* with Bearer auth + OpenAPI 3.0, Eclipse BaSyx integration guide.
4. EU regulatory mappings
EU Reg. 2023/1542 — Battery Regulation: seven-part IDTA-02035 Battery Passport with the published submodel IRIs + SAMM/ECLASS leaf ids. EU 2023/1542 Annex XIII fields beyond the published 1.0.x SAMM aspects (UN 38.3 structured test, GHS classification, per-CRM content, hazardous substances, recycled content, raw-material sourcing, due diligence) are carried as explicitly-marked urn:aas-studio:ext:eu2023-1542:… extensions — never as fabricated SAMM ids. PerformanceClass is a closed A–G enum. SDK predicate isBatteryAas().
EU Reg. 2023/1230 — Machinery Regulation: technical documentation template, applies from 2027-01-14 (the regulation defaults the instructions for use and the EU declaration of conformity to digital format; it does not mandate a digital technical file, which stays with the manufacturer under Annex IV), SDK predicate isMachineryAas().
Regulatory completeness gate: a presence check for a regulation’s MANDATORY fields (Battery Annex XIII, ESPR minimum), separate from the AAS XSD/AASd-* metamodel validator — a file can be AAS-valid yet regulation-incomplete, and both are reported. The app-built Battery + DPP passports pass their profiles in CI.
CATENA-X CX-0127 (Part Instance) — SerialPart aspect: SerialPart / PCF (CX-0136) / BOM (CX-0125) aspect templates at serial_part:3.0.0 (form + output now version-consistent), with BPN (BPNL/BPNS/BPNA) format validation. Dataspace participation (EDC catalog / contract / transfer) is a documented seam that fails explicitly until the tenant is onboarded — a registered BPN + identity wallet + hosted connector are not code artifacts. SDK predicate isCatenaXAas().
Scope note. The family is eight standards, not the six often quoted as a range. Six — EN 18216, 18219, 18220, 18221, 18222 and 18223:2026 — were cited in the Official Journal by Implementing Decision (EU) 2026/1736 and therefore carry presumption of conformity. EN 18239 (access management and security) and EN 18246 (authentication, reliability and integrity) are not yet published; formal voting closed 16 July 2026. EN 18246 is the one closest to this product’s verifiability work, and it confers nothing yet.
The claims below describe implemented capabilities read against the normative texts, which became free to read once the OJ citation made them harmonised. Formal clause-by-clause conformance is still not asserted, and nothing here is certification: no certification scheme for these standards exists to be certified against.
What reading them changed. EN 18223 does not reference the Asset Administration Shell normatively anywhere — its clause 2 lists exactly three normative references (ISO 8601-1, EN 18219, EN 18221). Across all six harmonised standards the AAS appears once, in an informativeannex of EN 18216, under “this list is not exhaustive”. The AAS is this product’s engine and remains so; it is not a regulatory credential, and we do not present it as one.
EN 18219 — Unique identifiers: GS1 GTIN URN + GS1 Digital Link (AIs 01/8003/8004 with 21/10 qualifiers), GS1 mod-10 check-digit validation, and an indexed, immutable persistent identifier. Non-GS1 URN/IRI scheme validation (pending normative mapping).
EN 18220 — Data carriers: QR encodes a canonical GS1 Digital Link URI (id.gs1.org/01/…) resolvable by GS1 or this app. Data Matrix / RFID / NFC (pending normative mapping).
EN 18216 — Data exchange protocols: both DPP ports (/api/v1/dpp/resolve and the GS1 Digital Link resolver) negotiate Accept identically — JSON, JSON-LD, AAS XML, and HTML redirect — via one shared, q-value-aware negotiator. Clause 5 is normative and makes JSON and HTML both mandatory, with XML and JSON-LD permitted by negotiation; clause 4 requires HTTP/2 as the minimum version and TLS 1.2 as the minimum, forbidding TLS 1.0/1.1 and all SSL. HTML is served by redirect to the human-readable viewer; its conformance with the EN 301549 accessibility requirements clause 5 also demands is not yet assessed.
EN 18222 — APIs (lifecycle + searchability): append-only lifecycle log (immutable by construction) with EPCIS 2.0 JSON-LD export, registry pointer publish/lookup/revoke, and a tier-aware, cursor-paginated discovery API (/api/v1/dpp/search). Live EU Commission registry integration (pending external API).
EN 18223 — System interoperability: AAS 3.1 (XML+JSON), EPCIS 2.0 JSON-LD, GS1 Digital Link and IEC 61360 ConceptDescriptions emitted on DPP exports; DPP payloads available as application/ld+json with an @context. An RFC 9264 link set is served at /api/v1/dpp/registry/linkset?uid=… as application/linkset+json — corrected 2 Aug 2026, when it was found that no route served one at all and the shape produced was not RFC 9264 either. The standard’s common information model is the CEN’s own UML, whose DigitalProductPassport root class maps field-for-field onto the IDTA-02099-1 DppMetadata submodel; that submodel is implemented and is the adapter between the two worlds.
EN 18221 — Storage / archiving / persistence: a passport under a configurable retention hold survives the economic operator — owner/org deletion tombstones + detaches it rather than erasing it; a waste lifecycle event starts the retention clock from end-of-life; and a SHA-256-sealed, integrity-verifiable archive bundle (/api/v1/dpp/archive) provides long-term persistence. Corrected 2 Aug 2026: this previously read “retention duration pending normative mapping”. The text has now been read, and EN 18221 specifies no retention period at all — the duration comes from the product-specific delegated act, not from the standard. EN 18221 is also the only one of the six to claim ESPR Article 10(4), and it expressly disclaims “the existence of the backup as such”; EN 18219 marks 10(4) Not Applicable. Durability guarantees remain ours to make, not inherited from any harmonised standard.
5. Audit trail / cryptographic evidence
SHA-256 source anchor: every AI-extracted AAS embeds the SHA-256 hash of the source PDF.
Engineer certification: name + initials + UTC timestamp embedded in submodel descriptions; audit-replay re-renders the certify-time Review pane without new LLM calls.
Multi-source provenance: per-field consensus block records source URLs/files + authority weights + values; disagreements flagged for review.
6. Out-of-scope / planned attestations
IDTA Certified status: not yet pursued. Tracked for Q3 2026 once 3+ enterprise leads request it explicitly.
SOC 2 / FedRAMP attestation: not yet pursued. Self-hosted Docker deployment available today for data-residency-constrained customers.
Use your browser's Print → Save as PDF to generate a PDF of this page. Back to /conformance