The applicable rule sets the required level
ESPR Article 9(2)(d) assigns the model, batch or item level and its definitions to the relevant delegated act. EN 18219’s public scope accommodates all three levels. That technical flexibility does not make the required level an unrestricted business choice.
Battery passports illustrate why the distinction matters: Article 77 combines information about a battery model with information specific to the individual battery. A shared technical document can therefore support model information without replacing the individual object’s record. Assess the applicable category instead of transferring this arrangement automatically to every product.
Source: Regulation (EU) 2024/1781: Articles 9–11 and 41Source: Regulation (EU) 2023/1542: Articles 13 and 77Source: BSI: BS EN 18219:2026, publication status and public scope
Use three operational questions to understand the distinction
For planning, a model describes a defined configuration shared by multiple units. Ask which characteristics must remain the same. A marketing family may be too broad when material or hardware variants have different evidence.
A batch describes an explainable group. Ask why the units belong together and which evidence covers them. A delivery note is not automatically a production batch: shipments can mix lots, while one lot can span several deliveries.
An item follows one physical unit. Ask how the unit and its events remain distinguishable throughout the lifecycle. A serial-number column alone does not prevent mistaken scans, duplicate allocation or events assigned to the wrong unit. These working explanations do not replace legal definitions.
Assign the scope of each value, not only the passport
Create an evidence map before importing a large catalogue. For each proposed value, identify the source, its covered product configuration or group and the reason for applying it to a particular record. Keep a blank or unresolved scope visible instead of copying a plausible answer to every child item.
For example, a reviewed assembly manual may describe a model, a material certificate may cover a particular supplied lot and an inspection result may belong to one unit. Those relationships can coexist in a maintained record. The task is to preserve what each source supports, not to duplicate every document thousands of times or to erase meaningful variation.
- Model: which configuration and revision does the source cover?
- Batch: what starts or ends membership in the group?
- Item: how is a specific event tied to the correct physical unit?
- Exception: who decides when a source cannot be inherited?
Define what changes identity and what changes information
List representative events with production, quality and service teams: correcting a typo, changing a component, splitting a lot, relabelling a package, replacing a damaged label and refurbishing an item. Decide which events update information and which require a new object relationship or a separate legal assessment.
Retain the history needed to understand previously supplied products. A revised model document should not silently rewrite an earlier item’s evidence without a review of applicability. Where a batch is split, keep enough relationship information to establish which resulting deliveries are supported by the original evidence. Avoid prescribing one universal identity rule for every lifecycle event.
Test one model, two groups and a few real units
As an engineering pilot, choose a small case with deliberate variation: one model, two distinguishable groups and several units. Add a shared document, a group-specific document and an item-specific observation. Check whether a reviewer can explain why each value appears on each record.
Change one source and trace which records need review. Test duplicate and unknown identifiers, a reprinted carrier and a mistaken group assignment. Record intended and actual behaviour; identical demonstration data will miss these problems.
Make granularity part of the preparation decision
In Passvanta, begin with a clearly identified product and source documents whose scope is understood. Review the configured record and identifier before generating a carrier. Use supplier requests to resolve ambiguous product, lot or variant coverage rather than making a reviewer infer it from a filename.
Keep the required legal level, the chosen data relationships, responsible owner and remaining uncertainties in your implementation decision. Verify supported workflows in the actual project before scaling. A category selection or successful readiness check does not independently prove that every required model, batch or item relationship has been implemented correctly.