Architecture Overview¶

4. Architecture overview¶

4.1 Four phases¶

4.2 Semantic control plane¶

The semantic control plane owns artefacts that apply across many products:

• source-model extracts and transformation rules;
• GDSN and GPC ontology modules;
• code-list and datatype resources;
• generated SHACL profiles;
• candidate mapping outputs;
• SSSOM mapping sets and review status;
• compiled OWL and DL-safe rule modules;
• projection/export queries;
• conformance tests, release manifests and deprecation records.

Changes in the control plane require controlled release and regression testing before they affect product publication.

4.3 Product data plane¶

The product data plane processes product-specific facts:

• resolve GTIN and GPC Brick;
• retrieve authoritative source values;
• assemble the Product Holon;
• validate it against the released profiles;
• select an authorised publication profile;
• apply the released bridge package;
• generate the canonical native representation and approved web discovery projection;
• package the human-readable page, machine-readable scripts, authority metadata and conformance evidence as an HTML Semantic Proof;
• issue or link a Verifiable Product Statement and status record;
• publish, distribute or resolve the proof package and its related resources;
• record provenance, validation, credential and publication evidence.

4.4 Logical components¶

4.5 End-to-end information flow¶

1. A source-model release is ingested and transformed.
2. Diagnostics are reviewed; no malformed multiplicity or limit is silently guessed.
3. Separate GDSN and GPC ontology modules and SHACL resources are released.
4. Candidate semantic mappings are generated over the released models and target vocabularies.
5. Mapping stewards review candidates in SSSOM and approve, reject or qualify them.
6. A bridge package is compiled and tested.
7. A product’s authoritative record supplies its GTIN, Brick and populated facts.
8. The Product Holon construction service creates a bounded graph.
9. The validation service applies the relevant Brick and GDSN shapes.
10. An authorised publication profile selects facts and invokes the released bridge package.
11. The publication service produces the canonical GDSN/GPC-aligned representation and the schema.org/GS1 Web Vocabulary discovery projection.
12. The HTML Semantic Proof publisher binds the page, script identifiers, source authority and conformance resources into one release.
13. The credential issuer signs selected product statements or cryptographic digests of the related resources and publishes credential status.
14. The proof package is published through the appropriate B2B, feed, API or resolver channel.
15. Consumers retrieve only the representation and authority level appropriate to their role and apply their own reliance policy.

4.6 Roles and responsibilities¶

4.7 Trust and authority model¶

4.8 Authoritative, generated and compiled artefacts¶

The architecture distinguishes four release classes:

1. Authoritative source artefacts: GS1 source-model releases and authoritative product records.
2. Source-derived artefacts: TSV, OWL and SHACL generated from those sources.
3. Governed mapping artefacts: SSSOM mapping records approved through review.
4. Compiled and instance artefacts: bridge axioms, rules, queries, Product Holons, validation reports, publication views, HTML Semantic Proofs and Verifiable Product Statements.

A compiled artefact shall be reproducible from its source release, tool version and mapping-set version.

4.9 Architecture decisions summary¶

The detailed decision records are retained in the companion technical evidence pack. The current binding decisions are:

• maintain separate GDSN and GPC modules;
• separate semantic control-plane processing from per-product data-plane processing;
• treat mappings as governed data in SSSOM;
• compile only reviewed mappings;
• use direct equivalence only for same-meaning, same-shape correspondences;
• use DL-safe rules for conditional semantic derivations where appropriate;
• keep SPARQL outside the ontology as a projection/export mechanism or explicitly versioned transform;
• use generic PropertyValue projection for publishable unmapped facts;
• exclude non-public facts through an explicit allow-list;
• require deterministic engines for validation, inference and approved transformation;
• retain a GDSN/GPC-aligned canonical Product Holon and derive the Web Vocabulary/schema.org projection;
• use an HTML Semantic Proof as the Phase 4 inspectable publication package;
• use Verifiable Product Statements for authorship, integrity and current-status verification, while keeping factual reliance dependent on source authority and evidence.

Part I — Semantic foundation¶

The following section describes the semantic foundation used to construct and validate Product Holons.

Continue to Semantic Foundation for Phase 1.