# Core concepts Tell a model, a batch and an item apart, then choose the level your passport applies to before ordering a single label. Source: https://docs.sealtrust.io/en/notions/ --- By the end of this page, you will know how to name the six objects SealTrust handles and, above all, how to choose the level your digital passport applies to. That choice decides your labeling budget. Getting it backwards multiplies it by a hundred or a thousand. ## The six objects at a glance | Object | What it is | How many there are | | --- | --- | --- | | Model | The record of a commercial reference, shared by all its units. | One per reference in the catalog. | | Batch | A manufacturing run of a model: a date, a site, a country. | One per run produced. | | Item | A physical unit, the one that ships to a customer. | One per piece manufactured. | | Passport | The regulatory document that a scan makes readable. | One per model, or one per item. | | Certificate | A numbered piece of authenticity, attached to one unit. | Zero, one or several per item. | | Seal | The physical carrier that bears the identifier: QR, NFC chip, or both. | One per item. | A seventh word comes up everywhere: **product**. In the console, under "Catalog", the menu is called "Products" and it lists units. A product is therefore an item. The two neighboring menus are called "Product models" and "Production batches". ## The model A model carries everything that is true for every unit of the reference. The console form offers the fields below. Only two are required, the others stay empty until you fill them in. | Model field | Required | | --- | --- | | Name | Yes | | SKU, your internal reference | Yes | | GTIN, the retail barcode | No | | Description | No | | Category | No | | Main image | No | | CE marking | No | | Declaration of conformity number | No | | Declaration of conformity link | No | | EU type-examination certificate | No | | Customs code | No | | Customs description | No | | Weight in grams | No | | Volume in cubic centimeters | No | | Repair instructions | No | | Maintenance instructions | No | | Safety instructions | No | | User manual | No | | Spare parts page | No | | Disassembly instructions | No | The last six rows expect a web address. The model also carries a default warranty, which you set from its record once the model is created. There you enter a duration in months, terms, and you decide whether the warranty transfers to the next owner. Two identifiers name a model. The **SKU** is your internal reference: it is unique on your side, and two models of your brand cannot share it. The **GTIN** is the retail barcode. Enter it exactly as printed, on 8, 12, 13 or 14 digits. SealTrust brings it back to the canonical 14-digit form by adding zeros on the left: `3701234567890` becomes `03701234567890`. The GTIN is optional, and it becomes necessary as soon as you want a GS1 Digital Link. ## The batch A batch ties a model to a manufacturing run. It carries a code that is unique on your side, a production date, a manufacturing site, a two-letter country of origin, a planned quantity, and the identification method chosen for the run. The batch is also the unit of anchoring on the chain. SealTrust alone triggers that anchoring: an anchoring request coming from a brand account is refused. Anchoring is in no way automatic, and most batches are never anchored. When SealTrust anchors a batch, it computes a single hash that summarizes all its items, writes that one hash on Base L2 (chain_id 8453), and keeps, for each item, what it takes to prove that the item does belong to that anchored batch. A single write on the chain covers the whole run, up to 10,000 anchorable items. A run that exceeds that count is refused for anchoring, and it must be split before being anchored. You read the result in the console. > [!ATTENTION] Two meanings of the word "batch" > The production batch described here is an object in your catalog. In the partner API, the > word "batch" also names a grouped submission. A call to `POST /partner/mint/batch` accepts > up to 500 rows, queues a job and answers with a job identifier. You then query > `GET /partner/mint/batch/status/{job_id}` to learn the state of that job. That grouped > submission creates units, all identified by `qr`. It creates no production batch, and it > ties the units neither to a model nor to a production batch: its row carries no field for > that. You make those links from the console. ## The item An item is a physical piece. It is the object a customer holds in their hand. Every item receives, at creation, a public 12-character serial number drawn at random. The alphabet excludes the letters I, L, O and U, so that a human can copy the number off a label without confusing a 1 with an I, or a 0 with an O. The draw is random and not sequential: nobody can deduce your production volumes by looking at two numbers, and guessing a valid number stays out of reach, the space counting more than a billion billion values. That number is the unique product identifier within the meaning of standard EN 18219. It resolves at the address `https://sealtrust.io/p/{serial}`, where `{serial}` is the number itself. An item withdrawn from circulation keeps its address. A code printed on a withdrawn piece is still on that piece, in someone's hands, and scanning it must not answer "unknown". Standard EN 18219 requires this in paragraph 4.2.2, and SealTrust then redirects the scan to the passport of the piece. ## The passport, and the level it applies to This is the decision with the heaviest consequences in your whole project. Read this section in full. ### Three levels are allowed The European ecodesign regulation (EU) 2024/1781, in force since July 18, 2024, establishes the digital product passport. It is a framework regulation: it switches the passport on product group by product group, each following its own delegated act. Its recital 33 states that the passport may apply to the **model**, to the **batch** or to the **item**. In other words, the regulation does not ask you to number every unit. It asks you to attach the passport at the level that makes sense for your product. > [!DANGER] The mistake that multiplies the bill > Believing that one passport per unit is required is the most expensive mistake on this > subject. Serializing means a unique identifier, a unique label and a unique data row per > piece. On a reference sold in a hundred thousand units, that means a hundred thousand > passports where a single one is enough. Check the delegated act for your product group > before deciding. ### What SealTrust attaches today SealTrust attaches a passport to a model, or to an item. Those are the only two levels served. You attach the **reference passport** to a model and to no unit. All the units of the model then serve the same document. This is the level for any product where numbering every piece brings neither meaning nor savings. You attach the **unit passport** to an item. It carries data specific to that piece: a battery identifier, a state of health, a declaration tied to the serial number. SealTrust never serves a unit passport for another unit of the same model. When a scan lands on a unit, SealTrust first looks for the passport of that unit. If it has none, SealTrust serves the reference passport of its model. That fallback does not survive the publication of a unit passport, so read the callout below before choosing your level. > [!DANGER] Publishing a unit passport switches off the model's reference passport > As soon as the unit belongs to a model, SealTrust also ties the new passport version to > that model. Publishing a passport on a single unit therefore unpublishes the reference > passport of the model, and the passports of all the other units of that model. Those > passports go back to visibility reserved to your brand, and the `/01/{gtin}` address of > that model stops serving a passport. The fallback described in the previous paragraph > disappears for the whole range, in a single move. So choose the model level or the item > level for a given reference, and hold to that choice. > [Digital Product Passport](/en/passeport-dpp/) details what happens at publication. The production batch is not a passport level at SealTrust. The regulation allows that level. SealTrust does not serve it today: a passport is tied to a model or to an item, never to a batch code. If your regulation imposes the batch level on you, publish a reference passport on the model and talk to the team before committing. The production batch remains the object that describes the run and that carries the anchoring. ### What the scanned link decides The address carried by the code determines the level served. | Link | What it names | Where it leads | | --- | --- | --- | | `/p/{serial}` | One unit. | Its product page, and its passport from that page. | | `/01/{gtin}/21/{serial}` | One unit, written as a GS1 Digital Link. | The same page as the previous row. | | `/01/{gtin}` | A commercial reference, with no serial number. | The reference passport of the model. | The first two rows lead a person to the product page, which answers the question the scan asks: what it is, whether it is genuine, where the proofs are. The passport is reachable from that page. A machine that wants the passport directly appends `?linkType=dpp` to the address and gets it without going through the page. The third row is the one that matters to you if you do not serialize. A GTIN alone is enough to serve a reference passport. It requires neither a serial number, nor a unique label, nor a data row per piece. ### The one exception to know The batteries regulation (EU) 2023/1542 requires a unique identifier per battery, and therefore one passport per unit. The deadline is firm and written into the regulation itself: February 18, 2027. That requirement does not cover every battery. It targets electric vehicle batteries, industrial batteries above 2 kWh and light means of transport batteries, electric bikes and scooters. Portable batteries and starter batteries are outside the scope of the passport. > [!INFO] Remember the rule > Per unit only when the regulation for your product requires it, or when your business model > depends on it, for example for resale and a transferable warranty. Everywhere else, the > model level is the right one. ### Versions and sealing A passport moves forward in numbered versions. Publishing a version **seals** it: it stops being editable. You publish a correction as the next version, which is what the regulation expects. Publishing the next version unpublishes the previous one. SealTrust then stops serving it to visitors and switches it to visibility reserved to your brand. It stays sealed, its hash stays chained to the next one, and if SealTrust has anchored that passport, the anchoring dates that hash. A consumer who wrote the hash down can therefore prove what they read, even if the page no longer shows it. Every sealed version is chained to the previous one by a hash. Rewriting a version detaches all those published after it, and that shows from the outside. A passport has a visibility: public, reserved to the owner of the unit, or reserved to your brand. To an anonymous visitor, SealTrust serves only a version that is public and published. ## The certificate A certificate is a piece of authenticity attached to ONE unit. It carries a unique number and an issue date. The console does not allow setting an expiration date at issue. SealTrust does not create a certificate automatically when you create an item. You issue it from the console, one at a time or in batches of 100 at most. The certificate quota of your plan applies to the **valid** certificates you hold at that instant. The counter does not add up past issues. A revoked or expired certificate drops out of the count, and revoking a certificate frees a slot. You will find the figures in [Plans and limits](/en/offres-et-limites/). Issuing a second certificate on the same unit does not cancel the first. Both stay active, and the public page shows the most recent of the active certificates. To withdraw a certificate, revoke it. A certificate has three states: | State | What it means | | --- | --- | | Active | Issued, with no expiration date, or with a date still to come. | | Revoked | Deliberately withdrawn. | | Expired | Its expiration date has passed. | SealTrust computes the expired state at read time, from the expiration date. Since no issue from the console writes an expiration date, no certificate you issue today reaches that state. Revocation wins over expiration: a withdrawn certificate is still shown as revoked once its date has passed, because withdrawal is a deliberate act and it must not soften into a mere lapse. The passport and the certificate answer two different questions. The passport says what the product is and how it was made. The certificate says that this precise unit was issued by you. ## The seal The seal is the physical carrier that bears the identifier on the object. You identify an item in one of three possible ways: | Mode | Carrier | | --- | --- | | `qr` | A QR code alone. | | `nfc` | An NFC chip alone. | | `nfc+qr` | Both on the same object. | The `nfc` and `nfc+qr` modes require a plan that includes NFC. The four plans in the catalog include it. If your account carries an off-catalog plan limited to QR, SealTrust refuses the request with the code `AUTH_METHOD_NOT_ALLOWED`. QR alone is a full-fledged mode. It carries the same identifier, serves the same passport and costs a print. Choose the chip when the physical authenticity of the object is at stake: a QR can be photographed and copied, whereas a chip produces a different cryptographic proof at every read, and an old read replayed later is refused. Some chips additionally carry a tab seal. The chip then reports the state of its seal at every read. Four answers exist: never opened, opened, opened then refastened, and function never switched on. Only "never opened" counts as an intact seal. "Opened then refastened" describes a tab reopened then put back in place, and it counts as opened. A chip without that function reports nothing, and that silence is never an accusation of counterfeiting. Switching the seal on is permanent on the chip and cannot be undone. You decide on it at the moment you start the encoding of the run. > [!INFO] Two uses of the word "seal" > On this page, the seal is the physical carrier. The verb "to seal" is also used to describe > what happens to a passport version when you publish it. The two notions have no technical > link. ## How it all fits together A model describes a reference. A batch describes a run of that model. An item is a piece of that run. The seal carries the identifier of the item on the object. You attach the passport to the model, or to the item. You attach the certificate to the item. Three questions are enough to decide your implementation. 1. **Does the regulation for my product group impose the unit level?** If yes, a unit passport. If no, move on to the next question. 2. **Do I need to track a specific piece after the sale**, for a transferable warranty, resale or returns? If yes, one item and one seal per piece remain useful, even with a shared reference passport. 3. **Otherwise**, publish a reference passport on the model, print the `/01/{gtin}` link and stop there. What comes next: [Physical identification](/en/identification-physique/) details the choice between QR and NFC, and [Digital Product Passport](/en/passeport-dpp/) shows how to build and publish a passport.