Serialisation.

Pharmaceutical serialisation connects the physical package to a unique digital identity and keeps the events that identity experiences through packaging and distribution. It governs each identity from serial provisioning through commissioning, aggregation, exchange and verification, and an order closes only when the physical, serial and event records reconcile.

Seal connects the packaging order, product and market data, serial-number source, line setup, commissioning, aggregation, labels, rejects, rework, reconciliation, warehouse state, data exchange, verification, investigation and batch release. Specialist line controllers and enterprise or national repositories can remain authoritative at their own layers.

1Give every layer an explicit owner.

Packaging equipment applies and inspects codes. Site systems coordinate orders and lines. Enterprise repositories manage serial pools and cross-site events. Trading-partner or regulatory networks exchange the required transaction data, and ERP and WMS manage commercial and warehouse activity.

The architecture works when ownership is explicit. Seal can run GMP packaging execution and its evidence, connect serial events to batches and quality decisions, and integrate with specialist serialisation layers without creating a second, hidden serial ledger.

1.1Why teams choose Seal for serialisation

Serialisation is usually added as its own stack beside the packaging batch record: line systems, a site server and an enterprise repository, each able to report success while the physical units, labels and exchanged events disagree. Serial events are connected to the packaging order, the batch and its quality decisions, and the order closes only when the reconciliations agree. A recall trace then shows missing and unacknowledged states rather than treating them as unaffected.

2Make five reconciliations agree before the order closes.

At order close, the site should be able to reconcile:

• physical good units, rejects, samples, retained units, rework, destruction and work in progress;
• serials requested, allocated, commissioned, decommissioned, returned unused and unresolved;
• labels or printed carriers issued, applied, rejected, sampled, returned and destroyed;
• child identities observed inside every aggregate, and the state of each parent; and
• events accepted by the site, enterprise, trading partner and any applicable external repository.

The totals need not be identical, because each counts a different object, but their governed relationships must explain every difference. Seal keeps the reconciliation formulas, source snapshots, tolerances, reviewer and exception outcome rather than reducing closure to a single green indicator. A packaging order cannot close with unexplained commissioned identities or physical units.

3Resolve each code from effective master data and a governed serial.

The effective configuration resolves the product identifier, market, packaging hierarchy, lot and expiry format, serial rules, data carrier, label template, language, artwork, aggregation and reporting destination. A market or artwork change identifies the open orders, line configurations, label stock, serial pools, interfaces and released inventory it affects before use. Historical units keep the master data active when they were commissioned.

A serial moves through a configured lifecycle: provided, assigned, commissioned, packed, aggregated, shipped, verified, returned, decommissioned or destroyed. Seal keeps the authoritative serial source, request and response identity, pool, site allocation, timestamps and the reason for each transition. Duplicate, unavailable or conflicting serials block normal packaging, and unused and consumed quantities reconcile after the order.

4Bind the line to the order before commissioning.

The packaging order identifies product, batch, market, quantity, line, packaging levels, label version, serial pool, printers, vision systems and aggregation stations. Pre-start checks confirm line clearance, equipment state, interfaces, users, materials and approved configuration. Challenge tests show that printers, cameras, reject stations and data paths behave as expected for the active order; failed setup evidence stays visible and prevents a normal start.

Artwork, variable fields, serial data, lot, expiry, barcode and human-readable content resolve from the approved configuration.¹ Reprints and manual labels keep their reason, prior output, authorisation and physical disposition, and the system distinguishes a replaced label from a second commissioned package.

Commissioning creates saleable identity. The line controller may generate the detailed print and inspection events while Seal keeps the order context and reconciled serial state: serial, product identifier, lot, expiry, packaging level, line and time. Unreadable, duplicate or mismatched codes enter reject or exception workflows. A successful camera inspection does not, by itself, prove that the unit entered the accepted population; reject confirmation and reconciliation complete that evidence.

5Keep the physical hierarchy and every reject in the record.

Parent-child events connect unit to bundle, case and pallet. Repacking, partial cases, deaggregation and pallet rebuilds add to the event history instead of rewriting the hierarchy. A decommissioned or suspect child cannot remain silently inside a saleable parent, and warehouse scans record whether contents were observed or inferred.

Every damaged package, unreadable code, quality sample, setup unit and reworked package affects quantity or serial reconciliation. Rework follows approved deaggregation, decommission, relabel or recommission steps, and the original serial events remain in history.

6Exchange events without letting states drift.

Serialised exchange commonly uses GS1 identifiers and EPCIS event structures, but implementation profiles and market requirements vary. FDA’s Drug Supply Chain Security Act resources describe an interoperable electronic tracing and verification framework for certain prescription drugs in the United States;² other markets use different identifiers, repositories and reporting rules, so the operating model stays market-specific.

Seal maps each business event with its what, when, where, why and disposition, and records message identity, payload version, acknowledgement, rejection, retry and correction. A technically delivered message can still be business-invalid. Reconciliation compares serial population, business step, hierarchy and acknowledgement across the line controller, site, enterprise repository, WMS and partner; one successful send does not make those states equal. Monitoring separates transport, schema, master-data and business-rule failures, because each needs a different response.

Warehouse receipt, pick, ship, transfer, return and quarantine events reference actual serials or verified aggregates. A shipment checks lot, expiry, serial status, destination eligibility, aggregation integrity, transaction-data readiness and quality state before release.

7Treat verification, suspect product and recall as decisions.

A verification request records identifier, serial, lot, expiry, requester, time, response and outcome. A match does not automatically make a returned product saleable; custody, condition, transaction history and quality status also count. Suspect, duplicate, decommissioned or inconsistent identities trigger containment, and the investigation brings together serial events, aggregation, shipments, packaging order, batch and label evidence. Correcting an event never erases the original exchange.

A batch, component, packaging or serial concern can define a recall population.³⁴ Seal traces from the source issue to packaging orders, serials, aggregates, shipments, customers and remaining inventory. Serial-level precision can narrow the action only when genealogy and event completeness support it. Unknown, missing and unacknowledged states stay visible, so incomplete data is not mistaken for unaffected product.

8Prove one order from provisioning to destination.

Run one commercial packaging order through master-data resolution, serial request, line setup, commissioning, rejects, aggregation, rework, reconciliation, warehouse handling, event exchange, shipment, acknowledgement, verification, return and recall trace.

Test the failures as well as the path: a serial-request outage, a duplicate serial, a camera failure, a reject-bin discrepancy, an aggregation mismatch, a partner rejection and a late acknowledgement. Retrying a message must not commission twice or create contradictory hierarchies, and recovery must prove the whole affected interval rather than assume restored connectivity means complete data. The system is credible when digital serial state matches the physical population and every exception has an accountable recovery path.