GS1 EPCIS Apparel Traceability: Events and Schema

A carton leaves a garment factory with twenty shirts. Two shirts were removed before the truck left. The warehouse system still shows twenty. The buyer scans the carton and receives the wrong list.

The barcode was readable. The message arrived. The failure was in the meaning of the data. A traceability system needs to record the change in the carton, not just its latest scan.

GS1 EPCIS gives trading partners a common way to share such events. GS1 US describes its role in sharing product movement and status across the supply chain. It is distinct from the business documents exchanged through EDI. GS1 US apparel guidance

This guide explains how an apparel team can design that event record. The examples are hypothetical. Short labels such as Shirt01 and CartonA make them easy to follow. These labels are not production GS1 identifiers or ready-to-submit EPCIS data.

Start with the question the record must answer

Choose a small use case before selecting fields. For a carton handover, the key question may be: which garments were in this carton when it left the factory?

That question needs more than a shipment number. It needs a link between each garment and its carton. It also needs the changes to that link over time. A single current packing list cannot explain all past states.

A material trace may ask a different question: which garment lot used this fabric lot? That requires an input-to-output link. Copying the packing design into that process would confuse containment with production.

Write the question in plain language. Then state the physical action that creates evidence for the answer. Name the person or system that knows it happened. A dock scan cannot prove which fabric lot entered a cutting lay unless that earlier link exists.

Define what remains outside the first release. A carton project need not solve fibre origin, all factory processes, returns, and end-of-life tracking at once. It should, however, keep identifiers that later work can use.

For the wider factory evidence context, see ApparelDiary's buyer audit and traceability guide. The purpose here is the event data exchanged by software.

Separate the item, the container, and the event

Three identities often get mixed together.

The item identity describes the object. The container identity describes the carton or other handling unit. The event identity describes one record of what happened. An event ID is not a replacement for a garment ID.

A product type is also different from one physical piece. A style, colour, and size may describe many identical shirts. A serial identity can distinguish one shirt from another. Decide which level the process can truly support.

GS1's ObjectEvent model allows instance identities and class-level quantities. A project can therefore describe named objects or quantities within a class. The choice affects the questions it can answer. GS1 ObjectEvent model

For example, twenty blue medium shirts is a quantity statement. A list of twenty unique shirt identities is an item statement. The first does not prove which individual shirt was shipped.

Use the level that matches the evidence. Do not invent serial detail from a total count. If the source only knows the lot and count, preserve that limit in the shared record.

Keep a master-data link for names people can read. A long product identifier may be correct but hard to use at a packing table. The operator still needs the right style, colour, and size on screen.

Match the event type to the physical action

EPCIS has event types with distinct meanings. Three are especially useful for the example in this guide.

Physical action	Event type to consider	Main relationship
Observe shirts at a process step	ObjectEvent	Objects and their business context
Pack shirts into a carton	AggregationEvent	Parent carton and child objects
Use materials to make an output	TransformationEvent	Inputs and outputs

An AggregationEvent describes a strong physical grouping. The parent and children are expected to be together until they are separated. Two cartons on the same order are not necessarily such a group. They could travel in different trucks. GS1 AggregationEvent model

A TransformationEvent links inputs that are consumed with outputs that are produced. It can use instance or class-level data. It can also link several events in one longer transformation. GS1 TransformationEvent model

These are data choices, not automatic evidence. A system can create a valid transformation record from a wrong fabric issue. The message format does not repair the source error.

Review each proposed event with a process owner. Ask what actually happened, which objects took part, and what the reader may infer. If the answer is uncertain, refine the capture step before adding more fields.

Understand the action within an aggregation

The action field has a specific role in an AggregationEvent. ADD links the listed children to the parent. DELETE separates children from it. OBSERVE records an observation without creating or removing that link.

An observation may be incomplete. A reader could see only some children. Missing children in that observation do not, by themselves, prove removal. The standard also allows a DELETE with no child lists to mean that all children were separated. That special case needs care in a user interface. EPCIS standard, AggregationEvent

Do not map every database delete button to that action. Removing a bad row from a work screen is not necessarily unpacking a carton. The application needs to know the business meaning.

For the same reason, shipping a carton is not evidence that its shirts were destroyed. Event type, action, and business step must be read together. A generic status label such as Done cannot replace that meaning.

Put the physical result beside each proposed action in the design notes. For example: remove Shirt19 from CartonA, but keep Shirt19 as an existing shirt. This makes a mistaken lifecycle mapping easier to spot.

Work through a packing and repacking example

Assume a factory uses item identities for twenty shirts. All are one approved style, colour, and size. It creates CartonA and packs Shirt01 through Shirt20.

The packing event adds those twenty children to CartonA. Before dispatch, a packer removes Shirt19 and Shirt20 for a label check. The team then places both in CartonB.

The intended history is:

Sequence	Physical action	Event meaning	Resulting count
1	Pack twenty shirts into A	Add twenty children to A	A contains 20
2	Remove Shirt19 and Shirt20	Delete those two links from A	A contains 18
3	Pack those shirts into B	Add two children to B	B contains 2
4	Dispatch both cartons	Record the shipping step	A: 18 shirts; B: 2 shirts

The count check is simple.

Remaining in A = Initially packed − Removed

Remaining in A = 20 − 2 = 18 shirts

Total in A and B = 18 + 2 = 20 shirts

The total is unchanged. The location of two shirts within the packing structure has changed.

A system that records only steps 1 and 3 may show Shirt19 and Shirt20 in both cartons. A total-only report could then claim twenty-two packed shirts. The problem is duplicate membership, not two new physical pieces.

Test membership by identity. For this simple design, a shirt should not be in two active cartons at the same time. Treat a conflict as an exception for review. Do not silently choose whichever message arrived last.

That check is a rule for this packing process. It should not be presented as a universal rule for every possible EPCIS relationship.

Model a pallet without counting shirts twice

Now place CartonA and CartonB on PalletP. This creates another level in the packing structure.

The pallet has two direct children: the cartons. It does not need a second independent claim that all twenty shirts are also direct children. The consumer can follow the known carton links where the agreed design supports that inference.

Keep the unit at each level clear. Two cartons plus twenty shirts is not twenty-two garments. One pallet plus two cartons is not three shipments.

The reporting model should answer each count at its own level:

Question	Unit	Expected answer in this example
How many pallets moved?	Pallets	1
How many cartons were on P?	Cartons	2
How many shirts were within those cartons?	Shirts	20

Write separate checks for each answer. This prevents a common error when a generic event table contains all object types.

Also test the history after one carton leaves the pallet. A current pallet query and a shipment-time query may return different members. Both can be correct if they use the right time.

Give business steps and conditions clear meanings

An event type alone does not explain the work. The business step supplies process context. The disposition describes the object's business condition.

GS1's Core Business Vocabulary defines shared terms such as packing, shipping, receiving, and unpacking. It also distinguishes receiving from arriving and accepting. A project should use the terms according to their definitions, rather than treating them as interchangeable screen labels. Core Business Vocabulary

Create a mapping from local work to the agreed terms. Ask what triggers each step. A truck reaching the gate may be arrival. Taking goods into the receiver's inventory involves a different decision.

Do not use a quality condition as a location. Held for review is not a warehouse name. Likewise, Dock3 is not a business disposition.

Consider the two removed shirts. Their removal changes carton membership. A separate quality event may record why they were held. Packing them into B does not, on its own, prove that a quality hold was released.

The trace view should show both facts without forcing one to stand in for the other. That is valuable when a buyer asks why a unit moved but remained unavailable for sale.

Distinguish where an event happened from where goods remain

The read point identifies the event's capture location. The business location gives the place where the goods may be found until a later event says otherwise. Those fields have different roles in the EPCIS data model. EPCIS event fields

A factory might capture a carton at Dock3 within WarehouseNorth. A user may need the specific dock to investigate a failed scan. Another user may need the warehouse to search for stock.

Define both locations in shared master data. Avoid sending the text North without a clear namespace or owner. The buyer may have a site with the same short name.

Test location changes with a real route through the pilot area. Compare the physical path with the displayed trace. If every event says HeadOffice because that was the software default, the file may look complete while its location data is useless.

Do not add false detail. If the capture system only knows the site, record that supported level. Improve the capture method before claiming a precise bay or dock.

Keep occurrence time separate from repository time

A scan can reach the server after the physical event. That delay must not rewrite history.

EPCIS distinguishes eventTime from recordTime. The first states when the capture application says the event occurred. The second is repository bookkeeping. The event also carries the applicable time-zone offset. GS1 event time fields

Suppose the packing change happened at 14:10 local time. The network was down. The record reached the repository at 14:25. Dispatch occurred at 14:20 and its message arrived promptly.

Sorting only by arrival time puts dispatch before the earlier packing change. The

trace would be misleading. Keep both times and show late records when they affect an earlier view.

The simple lag in this example is fifteen minutes. It is a transmission and recording delay, not fifteen minutes of extra physical packing work.

Clock quality still matters. An event-time field is an assertion, not proof that a device clock was correct. Keep a way to flag suspect times. Define how the partner handles events with equal times or uncertain order.

Record transformations at the level the process supports

For a fabric-to-garment trace, define the real production boundary. A cutting run, bundle, or finished lot may be the right output scope. The answer depends on what the factory can track.

Suppose a trial consumes 100 kg of fabric. It produces 180 cut sets and records 10 kg of scrap. A separate measurement shows 90 kg in the cut sets.

The mass check is:

Accounted mass = Cut-set mass + Scrap mass

Accounted mass = 90 kg + 10 kg = 100 kg

The average mass per set is:

Mean cut-set mass = 90 kg ÷ 180 sets = 0.5 kg per set

These are process checks for the example. EPCIS does not make kilograms and pieces equal by placing them in one event.

Keep the quantity units explicit. Also state whether weights were measured or estimated. If moisture, samples, or unrecorded loss affect the balance, name that limit. Do not force the output figure to match the input just to pass a report.

A TransformationEvent can link the inputs and outputs, but its relationship can be broader than one-to-one. If several fabric lots feed one run, do not claim a specific shirt came from only one lot unless the capture supports it. GS1 transformation relationships

Correct an error without hiding the original record

A real move and a correction are different things. Removing a shirt now is a new physical event. Discovering that yesterday's record was wrong needs a correction approach.

GS1's Workbench guidance explains that ordinary events can correct some errors. Other cases require an error declaration. The declaration preserves the prior fields, apart from the error declaration and record time, and marks the prior assertions as wrong. It can link to corrective events. GS1 correction guidance

Do not treat an error declaration as a free-form note with an old event ID. Follow the specified structure. A message that merely looks helpful to a person may not have the required meaning for a partner's software.

For the pilot, include two distinct cases. In one, Shirt20 was truly removed after packing. In the other, Shirt20 was never packed but was included by mistake. Ask the partner to explain the final history for each.

The correction workflow should retain the reason and who reviewed it. It should also identify downstream views that may have used the bad data. A corrected repository does not guarantee that every exported report has been rebuilt.

Validate both the file and the business story

GS1 provides artefacts for EPCIS, including JSON Schema, XML schemas, a JSON-LD context, and interface definitions. Select the files that match the format and version in the exchange agreement. EPCIS normative artefacts

A schema check can reject an invalid structure. It cannot prove that a shirt was inside a carton. Split testing into structural checks and business checks.

Use the packing example as a shared acceptance set:

Test	Expected business result
Initial pack	A has the agreed twenty shirt identities
Remove two	A has eighteen; the two shirts still exist
Repack two	B has those two; no duplicate carton membership
Repeat one message	No extra physical item is inferred
Deliver an old event late	Shipment-time history uses the physical sequence
Observe only part of a carton	Unseen children are not silently removed
Correct a false packing record	Original error and corrected meaning remain explainable

Record the exact input files and expected answers. Let both sides run the same set. A screenshot of a green upload message is too weak as the only result.

Also test one unknown product and one unknown location. The receiver should expose the gap clearly. A blank label must not make an unknown identity look like a known item.

A useful exchange agreement covers more than the endpoint address. It names the event types, identity schemes, required fields, units, and business-step meanings.

It should also state timing expectations. How soon should a shipping event arrive? How are late corrections communicated? What happens when a source is down?

Keep those expectations realistic. A partner that sends one file each evening cannot support a live dock decision. That is a service-design limit, not a flaw in EPCIS.

Set access by the business relationship. A buyer may need the history for its goods without receiving every unrelated customer order. Define the scope before exposing a broad query service.

Keep sensitive commercial detail out of the event unless it serves the agreed use case. A purchase price is not needed merely to explain carton membership. Traceability does not require all enterprise data to be shared.

Run a small physical pilot

Choose a manageable set of styles and one packing route. Include normal work and deliberate exceptions. Staff should know which records are test data.

Walk the cartons through the process. Remove a shirt, change a carton, hold a unit, and delay one message. Record the physical truth on a separate pilot sheet.

Then ask someone who did not watch the exercise to reconstruct the history from the software. Can they say where Shirt19 was at dispatch? Can they explain why a carton count changed?

Compare their answer with the pilot sheet. A plausible story is not enough. The identities, times, and quantities should match the known test case.

Review operator effort as well. If the required scan adds a step that staff routinely skip, the design needs attention. Clear prompts and useful feedback help create reliable evidence at its source.

Answer a buyer question from the saved history

Suppose the buyer asks whether Shirt19 travelled in CartonA. The answer depends on the time in the question. It was packed in A, removed before dispatch, and shipped in B. A simple Yes or No would lose part of that history.

Give the support team a trace view that shows those three steps. Include the physical event time and the time the system received the record. Link each step to the evidence used in the pilot.

Now suppose Shirt19 returns a week later. Its current location may be a returns area. That new fact should not overwrite the answer about the original shipment. Keep the history query separate from the current-state query.

Test both questions with the same sample: Where is it now, and which carton held it at dispatch? Ask a second person to check the answers. If both screens merely show the latest carton field, the design has lost the ability to explain the past.

Also show missing evidence. If the repacking event has not arrived, mark the gap for review. Do not fill it with a guessed carton based on the order number.

Common questions

Does EPCIS require RFID?

The event design should be based on the business evidence. GS1 Switzerland describes capture through devices such as RFID and barcode readers. The sharing standard is not a requirement to use one capture technology. GS1 Switzerland EPCIS overview

Can an event replace the product master?

No. The event says what happened. The product and location masters explain the identities used in that record. Plan both parts so a partner can interpret the trace.

Does a valid event prove origin or sustainability?

No. It records an assertion based on the capture process. The evidence behind an origin or sustainability claim needs its own checks. A well-formed file cannot create missing proof.

Should every garment be serialised?

Use the level required by the question and supported by the operation. Lot or class quantities may serve some needs. Individual histories need individual identities and reliable capture throughout the relevant steps.

Build a trace that another team can explain

A strong EPCIS design preserves the meaning of physical work. It distinguishes items from containers, events from objects, and packing from production. It also keeps late records and corrections understandable.

Start with one question and a small set of known objects. Prove the history through packing, repacking, shipment, and one error. Then extend the design with the same care.

The goal is a record that another team can use to reach the right conclusion. If two shirts leave a carton, the shared history should make that change clear.

Traceability events rest on reliable stock and shipment records, so see buyer audit preparation, material issue and return controls, cycle counting and the export packing list.