Model, batch and item data explained

Full video transcript

What is the difference between model, batch, and item data in a digital product passport? Model data describes shared product specifications. Batch data describes a defined production group. Item data follows one individually identified product. Used together, these levels help you put each fact in the right context without repeating every detail for every unit.

Imagine a jacket called the North jacket. Its model record holds the design and shared care guidance. Production batch A was made using one fabric lot. Batch B used a different lot. Jacket number one hundred and four belongs to batch A. These example references let us follow shared information, production evidence, and one jacket's history.

Begin at the model level. Ask which information is genuinely shared by the products covered by this model and version. A design specification or care instruction may belong here. Check whether size, colour, or another variant changes the answer. A shared field is useful only when it applies to the products that use it.

At the batch level, connect information to the production group it actually describes. A fabric declaration or test result may support one run, but not another. Keep the reference, source, and scope with the record. A shipment is a logistics group; it is not automatically a production batch, and it may contain products from several batches.

At the item level, record what happens to one identified jacket. Suppose jacket one hundred and four has its zip repaired. That event belongs to this jacket's history. It should not make every jacket in batch A look repaired. The item can still refer to relevant shared model information and the evidence for its production batch.

Keep identity and information separate. An item identifier tells you which jacket you are looking at. It does not mean every fact must be stored separately for that jacket. A useful view can combine the applicable model version, batch records, and item events. Keep the relationships clear so the combined information can be explained.

Changes need context too. If the care guidance changes, record the version and determine which products the change applies to. If only batch B used a different fabric, do not quietly replace batch A's history. A later repair should add to the item's record. Review what changed, when it applied, and why.

Supplier tiers answer a different question: who contributes the information? Model, batch, and item describe what the information applies to. A direct supplier and an upstream fabric producer can contribute evidence at different levels. In OriginSpan, model, batch, and item records can stay connected while source and revision history are preserved.

For your first product family, map three facts: one shared specification, one batch-specific record, and one item event. Can you identify the source, the applicable products, and the relevant version for each? The right identification level depends on your workflow and applicable requirements. Book an OriginSpan demonstration using the link below to explore this with your own product example.