Galileo v1.0: An Open Framework for Product Records
Galileo v1.0 provides specifications and reference code for product records. Understand the release, its scope and what adoption still requires.
Galileo v1.0 provides open specifications and reference code for recording information about physical products. It gives implementers a starting point for product identity and traceability; it does not certify the authenticity of every object or the legal compliance of a deployment.
Updated 12 September 2026: the formal v1.0.0 release was published on 5 May 2026. This page retains its original February publication date and distinguishes that earlier announcement from the dated release.
What an implementer can use
A product record brings together claims such as who made an item, which identifier refers to it and what happened during its life. Shared specifications help different systems exchange those claims without inventing a new format for each partner.
The v1.0 release notes describe the released package. Start there when selecting a version, then follow the protocol documentation for its interfaces and examples. A reference implementation shows one way to apply a specification; a business still needs to configure, secure and operate its own service.
For example, consider a fictional repair shop receiving a watch with a manufacturer record. A shared identifier can help the shop attach its service record to the right product. The shop must still examine the watch and describe the work accurately. A digital signature can help identify the record's issuer and detect changes to signed data, but it cannot establish that the physical watch has never been substituted.
Where the regulatory boundary lies
A Digital Product Passport, or DPP, makes specified product information accessible through a data carrier such as a QR code. The EU framework develops through requirements for particular product groups. The European Commission's guidance for economic operators does not set a universal 2027 deadline for every luxury product.
Choose the relevant product category before treating a format or feature as a compliance requirement. Data protection also depends on the information collected, access permissions, retention and actual operation. An open protocol cannot settle those choices on its own.
What to establish before adoption
Begin with one record that another organisation needs to read. Agree who can issue and correct it, how the recipient checks its status and what happens if the service becomes unavailable. Then test that exchange with the chosen implementation.
The governance documents describe a proposed structure as well as participation arrangements. They should not be read as proof that every planned committee seat is occupied. Likewise, dates in an earlier roadmap describe intentions at the time; use a dated release to establish what became available.
These distinctions make the framework easier to evaluate: the released material is inspectable, while a proposed integration or future capability remains something to demonstrate.
Frequently asked questions
Does adopting Galileo make a product legally compliant?
No. A technical framework does not determine which laws apply to a product or prove that an implementation meets them. Identify the applicable requirements and verify the deployed system against those requirements.
Read the v1.0.0 release and the documentation, then identify the smallest product-record exchange your team needs to prove.