Content Review Process

How PCA members propose, review, and approve community content

A PDF-version of this page is available for download here: PCA Content Review Process Documentation (PDF)

1. Purpose

The purpose of this document is to give stakeholders of POSC Caesar Association (PCA) a clear and practical overview of how community-driven content is proposed, reviewed, and approved in our platform to ensure sufficient quality and shared industry agreement.

After reading this document, a reader should understand:

• When and how new content can be proposed
• Who is involved at each step
• What is required to move content forward
• What approval or rejection means in practice

2. Scope

The scope of this document is the process that applies to content created by PCA members using PCA's web interface or API. This includes content that extends or builds on existing PCA or third-party standards. Please note that the document primarily describes the review process for open community collections in PCA. How this relates to company collections is described in chapter 8.

This document does not describe:

• Technical data models or ontology design
• Internal platform implementation details
• Formal ISO Maintenance Agency-related processes

3. Introduction

PCA's mission of connecting information across systems, companies and industries requires balancing speed and control.

In practice, this means:

• PCA members can experiment with and use new content immediately
• Industry-level approval adds trust, not permission

Content is never deleted from the platform as a direct result of a review. Rejection does not mean "wrong" - it means "not suitable for shared industry use at this time". This ensures transparency, learning, and traceability over time.

The following sections first explain the overall flow of content through PCA, before describing roles, responsibilities, and the detailed review process step by step.

4. How content moves through PCA

The following diagram illustrates how content moves through our platform in clearly defined steps:

Let's see how this work in practice, from a high-level perspective:

1. A PCA Member identifies a need for new or updated content
2. The member submits it through PCA's services
3. PCA performs automatic quality checks
4. A cross-company (or industry) working group reviews the submitted content
5. The content is either approved or rejected
6. Approved content becomes industry-anchored reference data

While this section provides a simplified overview, sections 6-7 describe roles, responsibilities, and each step of the process in detail.

5. Key terms used in this document

From section 6 and onwards, the documentation goes more into the details. This section gives an overview of the terminology principle and key terms used in these sections. We have intentionally not included this at the start of the document, so readers only wishing a high-level can stick to exactly that.

5.1 Terminology principle

This document uses stable nouns to describe what kind of content is managed in the PCA platform, and verbs to describe what happens to that content.

• "An item is an individual piece of content (e.g. a definition, class, instance)."
• "A collection is a grouping of items managed as a unit."

Items and collections move through the same review lifecycle and may be submitted, reviewed, approved, or rejected. These verbs describe actions and states, not different types of objects:

• An approved item and a rejected item are the same item with different review outcomes.
• The same applies to collections.

At a high level, this document uses "content" as a general term. When precision is required, content is described as either an item or a collection.

5.2 Glossary

Term	Description
Content	Any information managed in the PCA platform and subject to the review process.
Item	An individual piece of content (e.g. a definition, class, or instance). An item may be submitted, reviewed, approved, or rejected.
Collection	A grouping of items managed as a unit. A collection follows the same review lifecycle as an item.
Private collection	A grouping of items managed as a unit under the control of a specific member organization. A private collection follows the same review lifecycle as a collection by default, but may be altered to accommodate a member organizations internal governance needs.
Package	A capability allowing users to group the content they submitt for the review process.
Submission	The act of submitting content (an item or collection) to the PCA platform.
Review outcome	The decision to approve or reject content.

6. Roles and Responsibilities

The following table provides an overview of the roles we make use of in our review process description, and the corresponding responsibilities each of these have.

Role	Description
PCA Platform	The PCA Enterprise Reference Data Service (both platform and operational team) being used by the PCA member organizations. Responsibilities: 1. Ensure that submitted content (items and collections) meets minimum quality requirements for use, management, and review 2. Facilitate the review process
Creator	A user from a PCA member organization, that needs to extend the PCA content to fulfill a need the member organization has. Responsibilities: 1. Ensuring sufficient due diligence* is conducted internally in the member organization before submission 2. Collect and provide all information required to submit content
Reviewer	A Subject Matter Expert (SME) from a PCA member organization that has been appointed by the member organization to represent it and take part of reviewing submitted content for a given domain. Responsibilities: 1. Take part in reviewing submitted content for the domain it represents on behalf of the member organization
Working group	A group of reviewers, representing PCA member organizations, that work together to review submitted content for a given domain. Responsibilities: 1. Process submitted content for the given domain 2. Approve or reject submitted content with corresponding justification
Working group chair	A reviewer appointed by PCA to lead a working group, ensuring coordination and facilitation of the group. Responsibilities: 1. Setup and facilitate recurring meeting places for the working group 2. Point of escalation from the working group to PCA 3. Make the final decision for content being reviewed if the working group is unable to come to an agreement

*As "sufficient due diligence" is subjective, PCA cannot enforce this, but rather require confirmation that the user has done this according to internal requirements in the member organization.

7. Review process

This section describes the detailed review process that applies to submitted content. Where greater precision is required, content is described as either an item or a collection. Regardless of type, the same lifecycle applies: content is submitted, checked for quality, reviewed by a working group, and either approved or rejected.

7.1 Submission

Purpose: Enable a PCA member to create new content for itself and/or the industry.

Roles involved: Creator, PCA Platform

Description:

1. The creator identifies a need for new content1. It conducts internal due diligence with the goal of: (a) ensuring the need isn't already met somehow, and (b) the content will be supported by its organization.
2. The creator prepares all information required to submit the needed type of content (e.g. a CFIHOS extension, an IMF Type, a digital engineering symbol). Information required to submit all types of content include:
   Name (required)2: The name of the item.
   Package name (optional): Used to group items for review.
   Replaces (optional): Specifies IRI for existing version.
   Ontology (required)3: Specifies the collection to put it in.
   Description (required): A description of the item.
   Justification (required): An explanation of why the item is needed.
3. The creator submits the content to the PCA Platform. If automatic QA is successful, the creator receives a confirmation of submission with a link to the IRI of the newly created content. If unsuccessful, the creator receives a message stating this with a corresponding explanation of the failure.

Exit criteria:

• Proceed to next step: Creator provides all information required to submit the content to the PCA Platform.
• Abort: Creator concludes that need is already fulfilled.

1 New version of existing content is also defined as new content.
2 Automatically generated for IMF Attributes and therefore not visible in the user interface.
3 Not applicable for ontologies themselves, which instead have an optional field for "upper ontologies".

7.2 Automatic QA

Purpose: To ensure user-generated content has a level of quality sufficient to (1) be hosted on and offered through the PCA Platform, and (2) facilitate the review process.

Roles involved: Creator, PCA Platform

Description:

1. The PCA Platform receives the submitted content from the creator, and checks that the necessary information is provided for the specific type of content the creator is proposing to create. A check is also done to ensure the proposed content is not identical to any existing content.
2. If any of the checks fail, the proposed content is rejected, and the creator is informed. In the event of duplication, a link to the existing content is also provided.
3. If all checks pass, then
   a. The content is created, assigned a unique IRI and its status set to "Submitted".
   b. The creator is informed of the creation with a link to the IRI
   c. The newly created content becomes available in the dashboard for reviewers.

Exit criteria:

• Proceed to next step: Information quality and duplication checks have passed successfully
• Return to previous step: If any check fails

7.3 Community review

Purpose: Ensure industry-anchored and relevant quality content through a joint-industry quality assurance process.

Roles involved: PCA Platform, Reviewer, Working Group, Working Group Chair

Description:

1. The submitted content is made available in the interface for reviewers. The Working Group in charge of the relevant domain brings the content up for review as part of their recurring meeting place.
2. The Working Group works through the submitted content to ensure that it
   a. Answers to an actual industry need
   b. Is understandable and semantically correct for the domain
   c. Has a sufficient level of quality to be useful for PCA members
3. The Working Group decides whether to approve or reject. As part of making this decision, the Working Group must ensure that
   a. At least one reviewer originating from another organization than the creator agrees with the proposed decision
   b. The Working Group has analyzed and is aware of the impact of their decision on other content.4
4. If the Working Group cannot agree on a decision for the submitted content, the Working Group Chair has the mandate to make the final decision. However, an agreement from at least one reviewer originating from another organization than the creator, must still support the decision. The Working Group Chair itself may fulfill this requirement.
5. Once a decision is made, the Working Group provides its justification and a confirmation of the resulting impact on dependencies, and records the review outcome for the content in the PCA Platform.

Exit criteria:

• Approval:
  o The Working Group agrees on a review outcome
  o A reviewer originating from another organization than the creator has taken part in the review and agrees on the review outcome
  o The working group does not agree on an outcome and the working chair makes a decision to approve.
  o A reviewer originating from another organization than the creator supports the decision made by the working group chair.
• Rejection:
  o The Working Group agrees on a review outcome
  o A reviewer originating from another organization than the creator has taken part in the review and agrees on the review outcome
  o The working group does not agree on an outcome and the working group chair makes a decision to reject.
  o A reviewer originating from another organization than the creator supports the decision made by the working group chair

7.4 Publication

Purpose: To ensure that the review outcomes of Working Groups are reflected in the PCA Platform and that necessary traceability information is stored.

Roles involved: PCA Platform

Description:

1. The PCA Platform ensures that the requirements for an approval or rejection are fulfilled (i.e. Reviewer has confirmed the impact of its action, and a justification of the conclusion)
2. The PCA Platform marks the content as approved or rejected, and stores metadata about the action (e.g. user identity, date, justification).5

4 A reviewer is presented with a list of dependencies when starting a rejection or approval action in the PCA Platform, that shows whether the action will result in rejection or approval of something else, and if so, the list of those proposals.
5 Future extensions to the platform will trigger a notification to the Creator to notify it of the outcome of the proposal.

Exit criteria:

• Successful publication:
  o The Working Group has acknowledged the impact of its action
  o The Working Group has provided a justification for its action
• Aborted publication:
  o The Working Group has not acknowledged the impact of its action
  o The Working Group has not provided a justification for its action

8. Review process for private collections

Private collections follow the same content submission and review lifecycle as community collections, but with the difference described below:

• The Creator and Reviewer may originate from the same organization, but should still be different users/people
• The duplication check will be conducted against community collections and the organizations other private collections

9. Deep dives on platform concepts

This section provides more detailed information about the concepts referenced in the review process description. It is not necessary to read through these to understand the review process itself, but it will help create a more thorough understanding for those interested.

9.1 Standards vs. content

PCA provides both international and/or industry standards as well as user generated content:

• The standards can be governed both by PCA and by other organizations
• User generated content is managed by PCA and its member community

Standards managed by other organizations are marked as "Externally managed", while user generated content has statuses corresponding to the process described in this document.

9.2 Interactive services vs. PCA Host

A user can create and publish content on PCA's platform in two ways:

• Propose content through interactive services (user interface and API)
• Publish premade content through PCA Host

PCA Host is meant to cover specialized cases where our interactive services do not directly cover the users need. This ranges from e.g. a standards organization wanting to publish and make its standard available through PCA, to an enterprise wanting to share its corporate standard/domain model, and more.

The process described in this document does not always apply to content published and managed through PCA Host. All content created through our interactive services are subject to the process described here.

9.3 Collections

Our user interface makes use of "collection" as a collective noun to describe several concepts such as taxonomies, ontologies, instances and more. This is done to simplify usage for non-technical experts of the service. Nonetheless, the same review process applies to all of these.

9.4 Versioned vs. Unversioned collections

Versioning is an important capability of PCA's platform and applies at all levels of content. At the item level (e.g. a specific definition, class, instance), versioning is handled using "replaces"-relationships. This means that the item's information describes whether it replaces something else, and if so, with a link to what it replaces. Using this, we also derive what an item is replaced by, so you can also navigate forward in the versions. Important to note: If an item is replaced by a new version, the replaced version remains available.

Our collections work in a similar way, but have an added layer of complexity, since they serve two similar but distinct purposes:

• Versioned collection: Provide an immutable collection of specific versions of specific items (e.g. specific version of standard)
• Unversioned collection: Provide a growing group of items that may be used across versioned collections

For the sake of clarify, let's look at an example:

An enterprise want to make use of CFIHOS RDL 2.0 but need to extend it to cover all it's needs, so it chooses to make use of PCA's platform and services. When creating the CFIHOS extensions, the enterprise needs a working area to put them. For this, they create an unversioned collection. At some point, the enterprise will have its current needs reflected but also know that further needs will emerge in the future. It therefore need to create an immutable reference to the extensions it knows applies at this point. To do this, the enterprise creates a versioned collection that points to specific items in the unversioned collection. The enterprise can now point to the versioned collection when stating its requirements to someone, while safely expanding the unversioned collection without impacting the versioned one.

Note: Currently our service supports this versioning scheme partly. We support both concepts described, but partly through manual work. The need for manual work will be removed as part of our 2026 releases.

9.5 Community vs. company collections

While PCA promotes open community content by default, we recognize that some circumstances may require stricter access and/or edit policies. Currently, all our content is readable in a browser, while we restrict:

• Consumption through our API (e.g. other content types than HTML)
• Submission of content
• Approval/rejection of submitted content

It is already possible for a PCA member to create its own collections in the platform with the above authorization mechanisms available. Users from other PCA members are trusted not to submit any proposals to other PCA members collections. Failure to meet this requirement will result in penalties, including loss of access.

As part of our 2026 releases, we will expand this offering so a PCA member can create a private collection and only make it available for read and edit by its own employees or accredited users.

10. Lifting proposals to standard organizations

PCA has a long history of facilitating review and additions to international standards such as ISO 15926. With our new platform this will continue but in a different manner . The motivations behind this are continued support for our members need for standardization, but in a more dynamic, cost-efficient and scalable manner.

PCA has diversified it's portfolio in recent years, adding more standards and types of content. While previously having dealt primarily with ISO, we now consider the processes of more than one global standardization body. Our long-term ambition is to provide support for any standardization organization directly within the PCA Platform.

Common for all of these is that we must efficiently identify and manage the submitted content that our members wish to be part of the next version of a given standard. To determine whether submitted content should be forwarded to the standards owner the following requirements apply:

• The content must be part of a community collection
• The content must be approved by the appropriate Working Group
• The Working Group must support and/or recommend forwarding the content for standardization

If content is lifted and included in the next release of the corresponding standard, PCA will include a link between the addition in the version to the origin content in PCA once it is made available on the PCA Platform.