EPCIS 2.0 Implementation: RFP, 90-Day PoC and Acceptance Testing

An EPCIS 2.0 implementation succeeds when factories, warehouses and partners exchange the same meaning for each event—not merely when an API responds. This guide turns event contracts, disclosure boundaries, RFP, a 90-day PoC and acceptance evidence into a practical procurement method.

Executive answer: procure a shareable event contract, not an “EPCIS box”

EPCIS is a GS1 standard that enables disparate applications to create and share visibility-event data within and across enterprises. It is not an ERP replacement, a product that automatically repairs poor master data, a blockchain requirement or a legal data-sharing agreement. A sound procurement therefore buys five connected capabilities:

Identify products, lots, serials, logistics units, assets, locations and parties consistently.
Record operational facts with agreed event types, vocabularies and required data elements.
Transform confirmed data from MES, WMS, ERP, scanners, RFID and condition-monitoring systems into those events.
Share only authorised data under partner, purpose, retention and correction rules.
Prove capture, query, exception handling, reconciliation and auditability through executable acceptance tests.

GS1’s official calendar lists the GS1 Industry & Standards Event 2026 as a virtual event on 21–24 September 2026. No primary source reviewed for this article says that an EPCIS update will be announced there, so the event is only a timely reason to review readiness. The verified standard fact is that EPCIS 2.0.1 was published on 1 July 2025 and is shown as the latest release in the GS1 archive at the time of research.

Existing DPP articles address product-passport obligations and product-facing data delivery. This guide stays upstream: event contracts, capture/query interfaces, partner-specific disclosure boundaries and executable acceptance evidence. EPCIS is not a DPP-only platform; it can provide the same traceability facts to recall, quality, logistics, customer-explanation and passport use cases.

This order exposes failures that a polished demonstration may hide: two companies using the same code with different meaning, an HTTP 202 response without final event storage, or one customer being able to infer another customer’s records.

What GS1 EPCIS 2.0 actually standardises

The GS1 traceability framework is built on Identify, Capture and Share. The GS1 Global Traceability Standard describes operational occurrences such as receiving, packing, shipping and processing as Critical Tracking Events (CTEs), and the information that describes them as Key Data Elements (KDEs). EPCIS supplies the common event language and interfaces for sharing those facts.

Review events through what, when, where, why and how

Rather than starting with a field catalogue, review every candidate event with business questions:

Dimension	Business question	Typical data
What	What object was observed, moved, transformed or associated?	GTIN plus lot, serial, SSCC, asset ID
When	When did it happen and when was it recorded?	eventTime, recordTime, time-zone offset
Where	At which read point and business location?	readPoint, bizLocation, GLN
Why	In which business step and resulting state?	bizStep, disposition, transaction references
How	Under what measured condition or method?	sensorElement, values, units, device references

“Who” is handled through source/destination parties, location ownership and the identity used for access. Not every optional field belongs in every event. The team should define KDEs per CTE and decide whether missing or invalid data is rejected, quarantined or held for correction.

Select among five event types by business fact

The EPCIS 2.0 standard and schemas include ObjectEvent, AggregationEvent, TransactionEvent, TransformationEvent and AssociationEvent.

Event type	Business fact represented	Manufacturing or logistics example	Common misuse
ObjectEvent	Objects were observed at a point in time	Finished lots scanned at a dispatch gate	Forcing parent-child or input-output facts into an observation
AggregationEvent	Children were added to or removed from a parent	Cases packed onto or removed from an SSCC pallet	Treating a temporary packing hierarchy as a permanent bill of materials
TransactionEvent	Objects were associated with a business transaction	Shipped items linked to a purchase order or despatch advice	Using it as a substitute for the physical event
TransformationEvent	Inputs were consumed or used to produce outputs	Ingredient lots transformed into a mixed-product lot	Using it for simple movement between locations
AssociationEvent	Objects were associated with a parent, location or asset	A component installed in equipment; an asset assigned to a location	Failing to distinguish it from packing aggregation

FIG2 compares these five classes in five independent panels with no implied order. An RFP based only on older “four-event” summaries can omit AssociationEvent and create a proprietary workaround.

EPCIS 2.0 Implementation: RFP, 90-Day PoC and Acceptance Testing - figure 2

Govern CBV and extensions separately

The Core Business Vocabulary (CBV) supplies shared values for business steps, dispositions and other event concepts. Local codes are not automatically wrong, but their ownership and mapping must be explicit. If one partner interprets shipping as despatch confirmation and another as loading started, identical strings will not produce an interoperable trace.

Register every extension with its namespace, data type, unit, required conditions, owner and version. Also specify what a receiver does with an unknown extension. Silently ignoring it can conceal a critical condition, while rejecting every unfamiliar field can stop partner onboarding. Use a risk-based allow, quarantine or accept-with-warning policy.

Put the traceability data-sharing scope on one page

Before a PoC begins, reduce the project to five to ten trace questions. Examples are: “Which finished products used input lot X?”, “Which cases were inside pallet Y delivered to this customer?”, and “Which lots were exposed during a temperature-excursion window?” Derive CTEs, KDEs and identity granularity from those questions.

State what is in and out

List product family, factory, line, warehouse, partners, time period, identity level, source systems and exceptions. “Traceability for the Thailand factory” is too broad. A testable boundary is: product family P on line 2 at factory A, from material receipt through customer-warehouse receipt, at lot and logistics-unit level, using MES/WMS/TMS data, with one supplier and one logistics partner.

For a broader starting architecture, see Traceability Systems for Thailand Manufacturing. If the capture technology remains undecided, Barcode, QR or RFID for Traceability helps align read conditions with event granularity before connector work begins.

Separate internal data from shared data

The GS1 Global Traceability Standard recognises that traceability data has different sensitivities. Production recipes, cost and detailed personnel information normally need not cross a company boundary. Product/lot identity, shipment/receipt and a quality status needed for impact analysis may be shareable for a defined purpose.

Data class	Examples	Default treatment	RFP decision
Required shared data	Identity, shipment/receipt, packing hierarchy	Disclose to agreed parties	Mandatory fields, SLA, retention
Conditional shared data	Temperature, certificate reference, quality result	Limit by use, contract and lot	Masking, consent, expiry
Internal only	Recipe, cost, detailed process parameters	Do not disclose by default	Whether a derived status is enough
Security audit	User identity, query, export, permission change	Keep in protected audit storage	Access, retention, alerting

Without this classification, technical teams tend to send what they can collect while commercial and legal teams block all production data. The PoC then ends with harmless dummy data and proves nothing about operation.

A reference architecture centred on the EPCIS REST API

Divide responsibility into five layers:

Operational sources: receive confirmed business facts from MES, WMS, ERP, scanners, RFID readers, inspection and condition systems; do not assume direct PLC connectivity is necessary.
Event generation: map local identities to governed identifiers, and normalise time, units, CBV terms and event types.
Validation and quarantine: check JSON Schema, business rules, duplicates, references and allowed vocabulary; isolate invalid events.
EPCIS repository: provide capture, query, event and discovery capabilities while governing retention, correction and audit.
Sharing gateway: enforce partner, purpose, product and time-based authorisation, rate limits, masking and audit.

EPCIS 2.0 Implementation: RFP, 90-Day PoC and Acceptance Testing - figure 1

Go beyond “developer-friendly JSON and REST”

GS1’s EPCIS overview says EPCIS/CBV 2.0 adds JSON/JSON-LD, REST capture and query, sensor data, certification details and GS1 Digital Link URI syntax. The official artefact page publishes OpenAPI, JSON Schema, SHACL, XML XSD and ontologies. An RFP should ask which exact artefacts were used for validation, how JSON-LD context is controlled, supported content types, pagination, time zones, units and extension governance.

GS1 Digital Link provides a consistent Web URI representation for GS1 identification keys. It is not an EPCIS repository. Treat identifier representation, link resolution, event storage and access control as separate responsibilities. A consumer scanning a QR code must not automatically gain unrestricted access to internal events.

HTTP 202 does not mean “stored and ready”

The official EPCIS 2.0.1 OpenAPI describes /capture as an asynchronous endpoint for one or more events. A syntactically accepted request can return HTTP 202 with the capture-job location, but successful receipt does not guarantee final storage. Acceptance testing must therefore:

POST a controlled EPCISDocument.
Validate the 202 response and Location.
Poll the capture job to completion.
Inspect success, errors and rollback/proceed behaviour.
Query the expected stored records.
Reconcile source, repository and partner-received counts.

An “API availability” KPI alone is insufficient. Measure receipt, validation, persistence, query visibility and partner visibility as separate stages.

Twelve requirement groups for an EPCIS RFP

Build the RFP as a comparable evidence request, not a yes/no feature checklist.

Requirement group	Buyer question	Evidence required
1. Standard version	Which EPCIS/CBV versions and compatibility ranges are supported?	Version discovery and conformance results
2. Events	How are all five event types and actions handled?	Payloads and query results
3. Identity	What rules govern GTIN, GLN, SSCC, lot and serial?	ID mapping and collision checks
4. Vocabulary	How are CBV and extensions governed?	Vocabulary register and change process
5. Capture	How do retry, ordering, duplicates and partial errors behave?	Fault-injection demonstration
6. Query	What query, pagination and time-range performance is supported?	Logs on a defined dataset
7. Sensor data	How are units, calibration references, missing data and aggregation handled?	Representative sample events
8. Security	How do identity, authorisation, tenant isolation, encryption and audit work?	Negative access tests and architecture
9. Data sovereignty	Where is data held and how is deletion/export controlled?	Contract terms and export demonstration
10. Operations	What monitoring, backup, RTO/RPO and incident notification exist?	Runbook and recovery-test record
11. Change	How are schema, vocabulary and partner changes governed?	Versioning and impact analysis
12. Acceptance	What will PoC, FAT and SAT prove?	Test cases, evidence format and owners

Questions that reveal lock-in

After a vendor says “EPCIS compliant,” ask whether all events and master data can be exported in standard form, whether an independent client can use the standard REST interface, whether core use cases work without proprietary event classes, and whether the customer owns extension vocabularies and contexts. Contractually define the format, timing and fee for exporting events, master data, vocabularies, audit logs and certificate attachments when the service ends.

“Has login” is not an access-control test

Test authorisation by partner, role, product, site, event type, time range and purpose. When a user from Company A guesses a Company B lot identifier, the response must not leak the existence of records. Audit administrator activity, query conditions, exports, permission changes and failed authentication. Set clock synchronisation and audit retention requirements.

Support for sensor data or certification details does not mean every partner may see them. Keep high-resolution raw data internally when appropriate and share only an excursion result or certificate reference required by the agreed traceability question.

A 90-day PoC: MAP, BUILD, TEST, ACCEPT

The following timeline is a TOMAS TECH planning example, not a duration specified by GS1. With one product family, two or three partners and five to ten trace questions, it can produce evidence for an investment decision.

EPCIS 2.0 Implementation: RFP, 90-Day PoC and Acceptance Testing - figure 3

Days 1–15: MAP

Name the sponsor, data owners, operational owner and partner contacts.
Freeze trace questions, CTEs, KDEs, identity scope and success measures.
Inventory IDs, clocks, state codes and correction paths in MES/WMS/ERP.
Classify internal-only, conditional and required shared data.
Manually map 20–50 representative records and review semantic conflicts.

The exit deliverables are a signable event contract, data dictionary, responsibility matrix and identified test-lot set—not a conceptual slide deck alone.

Days 16–45: BUILD

Implement one capture path and one query path.
Add business validation for identities, CBV, time, units and relationships in addition to schema validation.
Build retry queues, dead-letter handling, duplicate decisions and capture-job reconciliation.
Enable partner-specific authorisation and audit logs.
Preserve conforming samples, boundary cases and deliberately invalid payloads as test assets.

Do not connect every production machine. Generate the first events from systems that already hold confirmed business steps, then add edge capture only where the trace question requires it.

Days 46–75: TEST

Happy path: trace receiving, transformation, packing, shipping and receipt end to end.
Data errors: inject missing KDEs, invalid IDs, unknown vocabulary, future time and unit mismatch.
Operational errors: test network interruption, duplicate delivery, out-of-order events, partial failure and restart.
Access: test a different partner, expired token, excessive date range and bulk export.
Performance: measure p50/p95 and failure rate at agreed volume, concurrency and query shape.
Reconciliation: compare source, completed capture, query and partner-received counts.

Days 76–90: ACCEPT

Give every acceptance case an ID, owner, execution time, input, expected result, actual result and evidence link.
Classify gaps by severity, workaround, due date and retest rule.
Confirm production scope, next-wave scope and exclusions.
Hand over the runbook, access approvals, incident path, vocabulary change and partner-onboarding procedure.
Record a sponsor decision: Go, Conditional Go or No-Go.

Acceptance testing: convert claims into measurable pass criteria

The numbers below are illustrative contractual targets, not EPCIS requirements or industry benchmarks. Adjust them to risk and infrastructure, and always fix the denominator, test period, dataset and measurement point.

Measure	Example pass criterion	Measurement
Required-field completeness	At least 99.5%	Calculate by required KDE per CTE
Capture success	At least 99.0% after controlled retry	Count final job status, not HTTP receipt
Ledger reconciliation	100% for the test-lot population	Compare source, EPCIS and partner receipt
Query performance	p95 no more than 3 seconds on defined data	Repeat a fixed query suite
Access isolation	Zero unauthorised cross-partner disclosure	Negative tests plus audit review
Correction trace	Actor, reason and time for every correction	Verify link to the original fact
Recovery	Meet agreed RTO/RPO	Restore from backup in a witnessed test

Write an acceptance case that can only have one answer

“Users can search events” is not testable enough. Write: “A Company A user searches product P, date D1–D2 and bizStep=shipping; the API returns exactly the 15 events authorised for Company A, reveals no count or identifier from five Company B events, and records identity, filters, time and result count in the query audit log.”

Do the same for invalid data. State whether an unknown unit is rejected or quarantined, whether replaying the same event ID is idempotent or a conflict, and whether a historic correction creates a new event, supersedes data or fails.

Estimate volume and cost with explicit assumptions

Start from events and payloads, not only transactions. This example is an original estimate using assumptions, not a GS1 or market figure.

Assume 3 lines, 2 shifts, 600 lots per line per shift per month and 8 events per lot. The estimated volume is 3 × 2 × 600 × 8 = 28,800 events/month before packing hierarchy, retries, sensor records, retention and query load. If a sensor reading becomes an event every second, the volume changes radically. Compare storing business-relevant observations, aggregates and excursions in EPCIS while retaining high-frequency waveforms in a time-series platform and linking them by reference.

Compare cost in five buckets:

Initial: process design, identity clean-up, mapping, connectors, access control and testing.
Recurring: storage, API usage, monitoring, support, certificates and backups.
Change: new partners, products, sites, vocabulary versions and regression tests.
Exit: standard export, audit-log transfer, deletion evidence and migration assistance.
Internal: data ownership, operations, training, exception resolution and partner support.

The best lifecycle comparison is often “days, roles and tests needed to add one partner,” not the first-year licence alone.

Additional design conditions for Thailand and ASEAN

Localise labels, not machine-readable codes

User interfaces can show Thai, English, Japanese or Vietnamese labels, while event types, CBV URIs, identifiers and unit codes remain canonical. Separate the explanation from the code so translation does not split shipping into “loading started” at one site and “despatch completed” at another.

Preserve time and location semantics

Thailand uses UTC+7, while partners and cloud services may use other time zones. Preserve offsets in event time and monitor the difference between event and record time. Keep read point, warehouse, legal entity and business location distinct. When an offline device uploads later, retain occurrence time as well as record time.

Support unequal partner maturity without changing event meaning

Demanding the same API capability from every supplier can prevent adoption. Large partners may use REST; smaller partners may use a portal, managed file exchange or label scan. All entry channels should still pass through the same event contract and validation rules.

For food use cases, Food Factory Traceability in Thailand provides useful lot, material and recall context for a TransformationEvent scenario.

Common failure patterns and corrections

1. Selecting a product from an “EPCIS supported” label

Supported version, event types, REST endpoints, query, extensions and export scope vary. Exchange samples and run negative tests with official artefacts before commitment.

2. Hiding master-data conflict behind an API

If one site has three codes, a lot has inconsistent formats and timestamps lack offsets, conversion will preserve ambiguity. Assign identity ownership and mapping-change responsibility.

3. Starting with all sites and all partners

Wider scope creates more meetings and weaker evidence. Limit the trace questions, product, partners and steps; state the condition for expansion.

4. Calling a happy-path demonstration “acceptance”

Production includes missing data, duplicates, disorder, access mistakes and network loss. Include fault, recovery and non-disclosure tests.

5. Putting every sensor sample in EPCIS

The ability to represent sensor data is not an instruction to ingest every raw waveform. Separate trace-relevant observation and excursion from high-frequency engineering data.

6. Omitting operational change from the contract

Products, sites, vocabulary, partners, certificates and access rules change. Include request, compatibility window, regression test, notification and deprecation procedures.

Internal Go/No-Go checklist for EPCIS 2.0 implementation

Proceed to production RFP when evidence supports “yes” to all twelve points:

Five to ten trace questions are defined.
Products, lots, sites, partners and period are bounded.
CTEs, KDEs and selection among five event types are agreed.
Ownership of GTIN, GLN, SSCC, lot and serial mapping is clear.
A CBV and extension register exists.
Internal, conditional and required shared data are classified.
The design reconciles the final capture-job state.
Partner/product/site/time access can be negatively tested.
Correction, duplicate, order, retry and quarantine behaviour is defined.
Automated validation uses official artefacts.
A runbook and partner-onboarding process exist.
Acceptance denominators, dataset and evidence format are fixed.

FAQ: EPCIS 2.0, REST API and RFP

Is EPCIS 2.0 a database product?

No. EPCIS is a GS1 standard for visibility-event data and interfaces. It can be implemented in a commercial product, cloud service or custom system. Storage, identity, access, monitoring and operational quality still need evaluation.

What is the difference between EPCIS 2.0 and 2.0.1?

The official archive lists EPCIS 2.0.0 as published on 22 June 2022 and 2.0.1 on 1 July 2025. Procurement should request the exact EPCIS version, CBV version, artefacts and known limitations, rather than accepting “2.0 compatible.”

Does GS1 EPCIS automatically create end-to-end visibility?

It provides a common language. End-to-end visibility also requires governed identity, data quality at every party, a sharing agreement, access policy and partner onboarding. Prove one bounded trace question end to end first.

What is the most important EPCIS REST API PoC test?

Do not stop at HTTP 202. Reconcile the final capture-job result, query result, source ledger and partner receipt for the same controlled lot. Add a negative test proving that another partner’s data cannot be discovered.

Is JSON-LD mandatory?

Choose formats according to participating systems and the use case. What matters is consistent interpretation of context, identifiers, vocabulary, types and extensions, with validation using the applicable official schemas or SHACL. “Valid JSON” alone does not prove semantic conformity.

How much sensor data should be shared?

Only what the agreed trace decision requires. An excursion, measurement period, unit, sensor reference and calibration reference may be enough; high-frequency raw data can remain in an internal time-series system. Purpose and retention should drive the decision.

What should an EPCIS RFP compare besides price?

Compare exact versions, event semantics, standard export, partner-onboarding effort, authorisation granularity, exception handling, audit, recovery, change governance, exit rights and acceptance evidence.

Can a company go live in 90 days?

The 90-day plan here is for a bounded PoC that informs an investment decision, not an enterprise rollout promise. Production timing depends on master-data quality, partner count, sites, integration paths and contractual or regulatory requirements.

Summary: turn standards conformance into repeatable partner evidence

The value of EPCIS 2.0 implementation is not that events can be stored. It is that two organisations can retrieve the same business fact with the same meaning and use it for recall, quality, logistics and customer assurance. What/when/where/why/how, five event types, CBV, JSON/JSON-LD and REST are tools. Trace questions, disclosure boundaries, exception rules and acceptance evidence determine the outcome.

TOMAS TECH can help shape an event contract, EPCIS RFP, 90-day PoC and acceptance matrix even when the target product or first partner is still being selected. To define a small, defensible sharing boundary between a Thailand factory and overseas partners, use our contact page.

References

Note: the 90-day sequence, volume calculation, example acceptance thresholds and cost categories are TOMAS TECH planning examples under stated assumptions. They are not GS1 requirements or market averages. Contract targets must be adjusted to the process, risk, infrastructure and partner agreement.