Map each designated core platform service to the DMA obligations that must be implemented, evidenced, reported, and kept under review.
Use the matrix to connect designation evidence, Articles 5, 6 and 7 obligation columns, product owners, Article 11 report annexes, and reopening gates.
Structured answer sets in this page tree.
Cited legal and guidance references.
This workflow builds a Digital Markets Act core platform service matrix from public designation and reporting materials. The output is one maintained row per designated CPS, with columns for Article 5, Article 6, Article 7, product ownership, source evidence, Article 11 reporting artifacts, and review gates.
The DMA matrix should begin with the core platform services listed in the Commission designation materials. Article 3 says the designation decision lists the relevant core platform services, and Article 3(10) ties the Articles 5, 6 and 7 compliance obligation to the listed CPS.
Create one row per listed CPS and record the gatekeeper, case identifier, Article 2 CPS category, product owner, legal owner, engineering owner, evidence owner, and Article 11 annex location. Do not merge separate CPS rows just because the same corporate group owns them.
The matrix should have obligation columns, not a generic compliance status column. Articles 5 and 6 each state that the gatekeeper must comply with the obligations in that Article with respect to each listed CPS, but the Article 11 template also expects a reasoned explanation where a specific obligation cannot by nature apply to the relevant CPS.
For every CPS row, mark each obligation as applicable, not applicable by nature, specification requested, implemented, blocked, or under remediation. Each status needs a source-linked reason and an evidence pointer.
An obligation cell is not complete because a policy says 'compliant'. The Article 11 template asks for a compliance statement plus an exhaustive explanation, supporting data, internal documents, implementation timing, product and geographic scope, technical changes, user-experience changes, remuneration and terms changes, consultations, testing, indicators, and relevant data.
Treat each Article 5, 6 or 7 cell as a mini evidence package. The evidence should let a reader reconstruct what changed, why the change addresses the obligation, which CPS it covers, and how effectiveness is monitored.
The matrix should reopen when the legal designation changes, when the product changes, or when evidence no longer proves effective compliance. Article 4 allows designation decisions to be reconsidered, amended or repealed, and the Commission gatekeeper page shows that CPS lists can change over time.
Review gates should be concrete enough for product and compliance teams to operate without waiting for an annual reporting cycle.
Sorena can help structure DMA CPS rows, obligation statuses, product-owner evidence, non-applicability reasons, and Article 11 annex material using the public sources cited here.
Ask source-linked questions about DMA CPS designations, Articles 5, 6 and 7 obligations, Article 11 report fields, and interoperability evidence.
Check whether each CPS row has designation evidence, product ownership, obligation status, Article 11 artifacts, and review gates.
"supporting data and internal documents"
"Meta was undesignated"
"structured timeline for handling interoperability requests"
"update that report and that non-confidential summary"