Build on published meaning

The World Skills Protocol is intended for systems that need to exchange or interpret professional skills information across organisational and technical boundaries.

It can support applications such as:

• —professional passports;
• —skills registries;
• —certification systems;
• —learning and assessment platforms;
• —recruitment tools;
• —workforce systems;
• —trusted evidence services;
• —interoperability layers;
• —AI agents that consume structured professional information.

These systems do not need to share the same internal architecture.

They need to preserve the same published meaning.

The protocol provides the common concepts, identifiers and relationships required to make that possible.

The protocol begins with its Records.

Records define the concepts, rules and relationships that constitute the World Skills Protocol.

They are the normative source against which implementations are interpreted.

A developer should therefore never derive protocol meaning solely from:

• —a user interface;
• —an example payload;
• —a database schema;
• —an SDK;
• —a graph projection;
• —or the behaviour of another implementation.

Those resources may make the protocol easier to use, but they do not replace the Records that establish its meaning.

When an implementation and a Record appear to disagree, the Record remains authoritative.

Names are useful for people.

Identifiers are necessary for systems.

The World Skills Protocol distinguishes the meaning of a published object from the address used to discover one of its representations.

A human-readable title may change.

A storage location may change.

A domain name may change.

A representation may be replaced.

The identity of the published definition must remain stable.

Developers should therefore use the canonical identifiers established by the protocol when storing, referencing or exchanging protocol objects.

Display labels may assist human readers, but they must not become substitutes for canonical identity.

Canonical identifiers do not require implementations to know where an object is currently stored.

Identity resolution belongs to the reading layer.

When a system receives a canonical identifier, it should use the protocol's published resolution and discovery mechanisms to locate the current representation associated with that identity.

This separation protects implementations from changes in:

• —infrastructure;
• —publication location;
• —file organisation;
• —hosting;
• —or canonical representation.

Applications can therefore continue to reference the same published identity even when the way it is read evolves.

The identifier remains stable.

The reading mechanism resolves the current representation.

A canonical representation is the protocol-approved expression of a published definition at a particular documentary state.

It is not the definition's identity.

Several representations may exist across time while preserving the same logical definition.

Developers must therefore avoid treating a file path, document URL, database row or serialized payload as though it were the identity of the object itself.

This distinction allows the protocol to evolve without breaking every implementation that references it.

The logical definition answers:

What is this published object?

The canonical representation answers:

How is that object expressed in this publication state?

The discovery address answers:

Where can the current representation be read?

These three questions must remain separate.

A published fact is not silently rewritten.

When the protocol needs to express a new relationship, status or representation, it proceeds by addition.

This means implementations should preserve the historical facts they have consumed rather than replacing them as though the previous publication had never existed.

New information may:

• —supersede an earlier representation;
• —identify a successor;
• —establish a reidentification;
• —publish a new version;
• —or change the derived reading of an object.

It must not erase the fact that the earlier publication occurred.

This enables auditability and historical reconstruction across the protocol.

The protocol distinguishes two forms of continuity.

Succession

Succession applies when the semantics have changed sufficiently for the new definition to constitute a distinct normative object.

The newer object follows the earlier one, but it does not claim to be the same definition.

Reidentification

Reidentification applies when the semantics remain unchanged but the published identity or canonical representation must be corrected or replaced.

The new publication preserves the normative properties of the definition being reidentified.

These relationships must not be treated as interchangeable.

Succession expresses semantic evolution.

Reidentification expresses continuity of meaning across a corrected identity or representation.

Applications that expose history should preserve this distinction.

The protocol publishes concepts.

Implementations store occurrences of those concepts.

For example, the protocol may publish that a Framework can be reidentified.

An implementation may store the particular fact that one Framework was reidentified as another.

The first is a protocol rule.

The second is an operational occurrence.

Developers should not insert implementation-specific occurrences into the normative corpus or its conceptual projection.

Conversely, they should not treat the Knowledge Graph as though it were an operational database.

This separation keeps the protocol universal while allowing implementations to store the facts relevant to their own users and systems.

The canonical registry exposes the predicates, identifiers and controlled relationships recognised by the protocol.

Developers should use the canonical predicate identifiers exactly as published.

A locally convenient synonym is not an equivalent protocol identifier.

Changing:

reidentified_as

into a different spelling, casing or verbal form may create a relationship that appears understandable to a person but is not recognisable to conforming software.

Canonical identifiers must therefore be reused without translation inside machine-readable protocol data.

Human-facing interfaces may provide explanatory labels alongside them.

The Knowledge Graph is a generated projection of the concepts and relationships published by the corpus.

It can help developers:

• —discover related concepts;
• —understand dependencies;
• —navigate Records;
• —inspect published relationships;
• —and provide structured context to software agents.

It must not be used as an independent normative source.

The graph does not contain database instances.

It does not infer relationships from implementation data.

It does not publish facts absent from the Records.

Every graph projection corresponds to a particular documentary state of the corpus.

Developers should therefore retain the identity or fingerprint of the projection they rely upon when reproducibility matters.

The protocol distinguishes three independent forms of versioning.

Documentary versioning

Documentary versioning tracks changes to a Record as a published document.

It identifies the state of that Record within the corpus.

Normative versioning

Normative versioning tracks changes to the meaning, obligations or logical definition established by the protocol.

A documentary revision does not necessarily change normative meaning.

Representation versioning

Representation versioning tracks changes to the form through which a published object is expressed or delivered.

A new serialization, file structure or publication format does not necessarily create a new normative object.

Developers should not collapse these layers into a single version number.

Doing so makes it impossible to distinguish a textual correction, a semantic amendment and a representation change.

Protocol status is derived from published facts.

It should not be treated as an isolated mutable field whose value can be changed without preserving the facts that justify it.

An implementation may cache a derived status for performance or presentation.

That cached value must remain reproducible from the underlying published facts.

The derivation should be deterministic.

The facts should remain traceable.

A stored label that cannot be justified from the publication history must not be treated as protocol truth.

Every protocol object consumed by an implementation should remain traceable to its published origin.

Depending on the use case, this may include:

• —the canonical identifier;
• —the establishing Record;
• —the documentary version;
• —the representation fingerprint;
• —the graph projection;
• —the date or state of resolution;
• —and the relationships used in interpretation.

Provenance is what allows a system to explain why it interpreted an object in a particular way.

Without provenance, two systems may display the same label while relying on different documentary states.

With provenance, the interpretation can be reconstructed and audited.

Where the protocol provides a canonical rule, conforming systems should produce the same result from the same published facts.

Resolution must not depend on undocumented assumptions.

Status derivation must not depend on hidden manual choices.

Canonical identifiers must not depend on display labels.

Graph relationships must not depend on private database content.

Deterministic behaviour allows independent implementations to reach compatible conclusions without sharing the same codebase.

This is one of the core conditions of interoperability.

A developer may encounter a relationship that appears obvious but is not published.

The implementation must not silently promote that interpretation into protocol meaning.

The correct response is to distinguish between:

• —what the protocol establishes;
• —what an implementation observes;
• —and what the developer infers.

Implementation-specific logic may exist where needed.

It must remain identifiable as implementation logic.

It must not be represented as though it were part of the World Skills Protocol until the appropriate rule has been published through the protocol's governance process.

Absence from the protocol is not permission to fabricate a normative answer.

The World Skills Protocol does not require every implementation to use the same technology.

One system may use relational storage.

Another may use a document store.

Another may consume static published artefacts.

Another may operate as an AI agent.

Their internal designs may differ substantially.

They remain interoperable when they preserve:

• —canonical identity;
• —published definitions;
• —normative relationships;
• —version distinctions;
• —provenance;
• —resolution behaviour;
• —and the separation between protocol concepts and implementation instances.

Conformance therefore concerns observable meaning, not internal resemblance.

A developer beginning an integration should proceed in the following order.

1. Identify the concepts in scope

Determine which protocol concepts the application needs to consume, publish or reference.

2. Read the establishing Records

Locate the Records that define those concepts and their normative relationships.

3. Retrieve canonical identifiers

Use the identifiers and predicate names published by the canonical registry.

4. Implement resolution

Resolve identifiers through the reading and discovery mechanisms rather than hard-coding current storage locations.

5. Preserve provenance

Record the documentary state and representation used by the application.

6. Separate protocol facts from local facts

Keep normative definitions distinct from implementation-specific instances and operational data.

7. Test deterministic behaviour

Verify that the same published facts produce the same resolution, derived status and relationship interpretation.

8. Monitor publication changes

When the corpus evolves, evaluate the relevant documentary, normative and representation changes independently.

This path enables an implementation to begin small while remaining compatible with the protocol's broader architecture.

The World Skills Protocol does not prescribe:

• —a user interface;
• —a database engine;
• —a hosting provider;
• —an authentication system;
• —a programming language;
• —a software framework;
• —a commercial model;
• —or a single application architecture.

It also does not require implementations to expose every concept in the protocol.

An implementation may support only the concepts relevant to its purpose.

What it must not do is alter the meaning of the concepts it claims to support.

Technical freedom is permitted.

Semantic divergence is not.

AI systems can use the protocol to access professional information with explicit structure and traceable origin.

They may use:

• —Records to retrieve normative meaning;
• —the Knowledge Graph to navigate concepts;
• —the canonical registry to recognise predicates;
• —and discovery mechanisms to resolve current representations and operational facts.

An AI agent must still distinguish retrieved facts from generated interpretations.

The presence of a concept in the graph does not prove that a particular person or organisation possesses it.

The existence of a relationship in the protocol does not prove that a corresponding operational occurrence exists.

Structured access improves reliability.

It does not eliminate the need for provenance and evidence.

The protocol evolves through its published governance mechanisms.

Developers should not assume that every documentary update creates a breaking change.

They should determine which layer changed.

A publication may involve:

• —an editorial correction;
• —a new documentary version;
• —a normative amendment;
• —a new canonical representation;
• —a reidentification;
• —a succession;
• —or a new graph projection.

Each has different consequences.

Applications should respond to the nature of the change rather than to the mere presence of a new version.

The World Skills Protocol gives developers a stable way to build with professional skills information without forcing every system into the same technical design.

Its central requirement is not technological uniformity.

It is fidelity to published meaning.

Use canonical identifiers.

Resolve identity through the reading layer.

Distinguish definitions from representations.

Separate concepts from instances.

Preserve provenance.

Derive status from facts.

And never introduce protocol semantics that the corpus has not published.

When these principles are respected, independent applications can exchange, interpret and verify professional information without surrendering traceability or control.