Not sure if this is the correct coordinate (given github and all forum categories we have) but let me try here first:
Why is the conformance spec including archetype operations? I can understand opt operations, as we’ve included in the REST API as well, but I’m a bit confused about why uploading/querying archetypes would be necessary.
Can you point out a link of the specs?
Edit: Regarding coordinates, fastest would be to ask on slack, and overhere in case you want to “preserve” the conversation.
Thanks @sebastian.iancu please see the first table in section 6.2.1 here
I prefer here because I really don’t like Slack’s lack of memory 
I see now your question, but I don’t have an answer. We discussed several times about adding archetype management in REST API (besides templates) but we every time we concluded is not needed.
If is not supported by REST API, I have no clear answer how would that be tested (for conformance) - perhaps @pablo can give us some hints.
About CKM, that is a commercial tool, its API is proprietary (I guess). We could add support in openEHR REST API to manage also archetypes, if SEC has an agreement.
This is being redeveloped based (initially) on the EhrBase test framework, developed by Pablo, Wlad Wagner and Birger (and I’m sure others behind the scenes) - as we agreed in Berlin and on various calls.
I have been merging the relevant test doc and robot files into the spec, on this branch. Branches don’t show up on the specifications website right now, so you’ll need to clone, check out that branch and locally look at the openehr_platform_conformance.html file to see it properly. See under the directory openehr_platform_conformance for the source files.
I am revising the contents of the table @Seref referenced to just consist of whatever is in the EhrBase test cases. I have done a rough draft version of the Definitions and Ehr services. More links need to be added in, and maybe we’ll change the formatting, and we will probably add more tets cases from e.g. Better, DIPS, anyone who wants to donate. In the end, what will be in that schedule will be calls that can be tested through the REST API of a ‘reasonable’ (= a bit better than MVP) openEHR platform implem.
I’m working as fast as possible to facilitate this upgrade to that spec so that we have something reviewable by the SEC in the coming weeks. Feel free to provide feedback right now of course. But you need to be on that branch to do so.
Thanks for the clarifications, I’ll take a look at this again, via the specific branch.