Content Review Process

This process defines how PCA-governed content moves from a Creator's identified need to a recorded review outcome. It distinguishes a persisted Draft from an explicitly Submitted proposal and separates platform checks from community governance.

1. Purpose

The process exists to:

• let members address real information needs without creating avoidable duplicates;
• give proposals stable identifiers and traceable provenance;
• let Creators improve work before formal review;
• ensure domain experts assess semantics and dependency impact; and
• retain outcomes and superseded resources for long-term traceability.

2. Scope

The full Draft and review lifecycle applies to content authored through supported PCA Creator workflows, including:

• reference-data libraries, classes, and properties;
• CFIHOS+ equipment classes, tag classes, properties, picklists, units, and dimensions;
• IMF attribute, terminal, and block types; and
• engineering symbols.

Content published through PCA Host can instead remain governed by an external owner. It is then Externally Managed and does not enter this workflow. The two models must not be presented as equivalent.

3. Governing principles

1. Search before creation. Reuse suitable content and identify true replacements.
2. A Draft is visible work, not approved work. It can have an IRI and appear in search while still changing.
3. Submission is explicit. Passing save-time validation does not submit a Draft.
4. Roles and ownership are different. Creator enables authoring but does not grant authority over every collection.
5. A technical check is not a governance decision. Validation cannot determine industry relevance or semantic correctness by itself.
6. Review the current proposal and impact. A stale dependency set cannot support a safe decision.
7. Keep provenance and identifiers traceable. Rejected, Deprecated, and externally governed resources need an interpretable history.

4. Terms

Term	Meaning
Content	A resource managed or exposed by PCA.
Item	One governed resource, such as a class, property, type, or symbol.
Aggregate	Several resources reviewed as one proposal, such as a picklist and its values.
Collection	A library, ontology, taxonomy, or other grouping and governance boundary.
Package	Optional metadata used to group related content for review.
Draft	Persisted content that has not entered formal review.
Submission	The explicit action that moves a complete Draft to Submitted/Pending review.
Review outcome	An authorized decision to approve or reject.
Definition source	Evidence for a definition's wording or meaning.
Mapping	An asserted semantic relationship to another identifier.

5. Roles and responsibilities

Role or actor	Responsibilities
Visitor without a PCA role	May use Libraries and Search and read HTML content pages; must interpret status before reuse.
Reader	May use search and retrieval APIs and retrieve supported machine-readable representations; has no authoring or decision authority.
Creator	Performs due diligence, authors and updates supported Drafts, supplies complete evidence and justification, and submits when ready.
Reviewer	Assesses a submitted proposal and current dependencies, participates in the applicable domain process, and records an authorized outcome with justification.
Working group	Provides the joint-industry/domain process for proposals in its mandate.
Working group chair	Facilitates the process and makes the final decision if the group cannot agree, subject to the participation requirements below.
Collection or external owner	Defines scope, ownership, release, and maintenance rules for its collection.
PCA platform and operations	Enforce access and lifecycle checks, preserve traceability, facilitate review, and operate publication services.

Reviewer and Creator should be different people for a decision. For community content, at least one supporting reviewer should represent an organization other than the Creator's organization. If a chair decides because the group cannot agree, that cross-organization support is still required.

6. End-to-end lifecycle

6.1 Identify and prepare the need

The Creator:

1. identifies a concrete member or industry need;
2. searches PCA and relevant external sources for existing content;
3. confirms the target collection and authority to extend it;
4. decides whether the proposal is new or replaces one exact prior resource; and
5. prepares common and type-specific information.

Common information includes name, definition/description, target library where applicable, change justification, optional package, optional Replaces, related terms, definition sources, and external mappings. A library itself uses upper-ontology context rather than a target library.

Exit: continue only when no suitable reusable resource meets the need and ownership is clear.

6.2 Save as Draft

The Creator uses a supported interactive form or Creator API. The platform checks the request's required fields, identifiers, relationships, and domain constraints and detects applicable conflicts or duplicates. A successful create:

• assigns an IRI;
• persists the content as Draft;
• records Creator provenance and justification; and
• provides a resource link.

Draft can be searchable and visible. It has not entered the review queue and must not be described as approved, submitted, or private.

Save-time behavior can be specialized:

• an IMF qualifier selection can produce several candidate attribute Drafts; successful candidates remain even if another fails; and
• a CFIHOS+ picklist and its values are maintained as one aggregate.

Exit: a valid, addressable Draft exists, or the Creator corrects the validation/conflict response. Validation failure is not a Rejected review outcome.

6.3 Inspect and update the Draft

The Creator opens View draft, checks status and generated relationships, and uses Edit this resource for a supported type. Each update supplies a change justification. Only Draft content is editable through this flow.

For engineering symbols, valid path geometry, required metadata, a target symbol library, and a center of rotation are needed before saving. Connection points are optional. For picklists, values are edited through the parent aggregate.

Exit: the Creator either continues iterating or confirms that the complete Draft is ready for formal review.

6.4 Submit for review

Submission is a separate confirmed action. The platform rechecks the lifecycle and relevant constraints, then changes Draft to Submitted. The interface can display this as Pending review.

If an editor has unsaved changes, the application saves them before requesting the transition. If save succeeds but submission fails, the Draft remains addressable and must not be recreated blindly.

After submission:

• Creator editing is locked;
• the proposal is available to the Reviewer workflow; and
• a picklist is represented by its parent aggregate rather than by separate value submissions.

There is no documented Creator withdrawal transition from Submitted back to Draft. An exception must be coordinated operationally with PCA.

Exit: the current proposal is Submitted/Pending review, or the user resolves a stated validation, access, aggregate, or conflict error.

6.5 Review the proposal and dependencies

The responsible Reviewer or working group:

1. opens the submitted item, package, or aggregate;
2. inspects identity, definition, provenance, target, justification, relationships, sources, mappings, and any replacement;
3. evaluates industry need, semantic correctness, clarity, and fitness for shared use;
4. inspects approval or rejection dependencies and aggregate members;
5. follows the applicable working-group or collection decision process; and
6. prepares an approval or rejection justification and acknowledges impact.

The platform binds the decision to a non-empty, unique review-item set and its latest updates. If an item, dependency, or aggregate member changed while the review was open, the platform rejects the stale action with 409 Conflict. The Reviewer must reload and assess the current proposal; repeating the old request is not sufficient.

6.6 Record and publish the outcome

Once the governance requirements are met, an authorized Reviewer records:

• Approved when the proposal is accepted; or
• Rejected when it is not accepted in its current form or purpose.

The platform stores the status and decision traceability. Approval is not merely a successful validation. Rejection is an outcome, not a transport or schema error.

7. Replacement and deprecation

Use Replaces only when a new resource is an actual version of one exact existing resource. The prior IRI remains available for traceability and can be marked Deprecated.

The current authoring behavior can apply that deprecation when the replacement relationship is created or updated, before the new Draft receives an Approved outcome. This makes Replaces a consequential field. Creators must verify it before saving, and Reviewers must inspect both sides of the relationship and its downstream impact.

Do not reuse the old IRI for a changed meaning and do not use replacement merely to link related concepts.

8. Definition sources and external mappings

A source supports the definition. A mapping asserts a semantic relation. Reviewers must check source version, target identifier and entity type, and whether exact match or broader match is defensible.

Supported authoring controls include PCA and several standards/catalogues, including ETIM 10.0 and UNSPSC 26.0801. Catalogue validation reduces input errors but does not replace domain assessment or grant rights to redistribute external content.

9. Externally Managed content

ExternallyManaged identifies content for which another authority retains governance. The platform can also show Externally managed when PCA lifecycle provenance is absent. Such content:

• can be searchable and reusable under the owner's terms;
• does not pass through Draft, Submitted, Approved, or Rejected in this process;
• cannot be edited or submitted through the Creator Draft workflow; and
• must identify enough owner, version, source, and release context for users to assess it.

Externally Managed is not a PCA approval outcome. Any issue or change request follows the external owner's process unless a separate PCA arrangement says otherwise.

10. Interactive authoring and PCA Host

Interactive Creator workflows are appropriate for supported resource types that PCA's review lifecycle will govern. PCA Host is appropriate when an organization already maintains an ontology, standard, reference dataset, or other RDF collection and needs a publication service.

A host onboarding agreement must state:

• authoritative owner and governance model;
• publication rights and license;
• namespace and identifier policy;
• authoritative source and release/version convention;
• dependencies and validation requirements;
• update, correction, rollback, and incident process; and
• whether the hosted content is PCA-governed or Externally Managed.

Host upload and operations are handled through the agreement between PCA and the content owner rather than a self-service API.

11. Collections, access, and confidentiality

A collection is a governance and grouping boundary; a role is an access capability. Creator access must not be interpreted as permission to write to every collection.

Draft content can be visible, and the documented role model does not by itself promise collection-specific private storage. Do not put confidential content into a Creator workflow unless PCA has explicitly confirmed the collection's access policy and tested it for the intended environment.

Versioned collections can identify an immutable release, while an unversioned collection can continue to grow. Where publication tooling still needs operational assistance, record the manual step and responsible owner instead of implying a self-service feature.

For a concise explanation of each lifecycle state and transition, continue to Review statuses and outcomes.