OpenEPCIS

OpenEPCIS is a GS1-conformant supply-chain data platform. It exposes a GS1 Digital Link Resolver, hosts GS1 Web Vocabulary masterdata, and lets that masterdata be driven by EPCIS Events.

Three pillars, one platform:

Editions

OpenEPCIS ships in two layers:

• Open source (github.com/openepcis) — the standards-conformant building blocks. Maven BOM, EPCIS models, format converters, validators, identifier translator (EPC URN ↔ Digital Link), barcode renderer, event hash generator, test data generator. Anyone can build on these. (The GS1 Conformant Resolver itself is business-only — there is no open-source resolver today.)
• Business edition (GitLab) — the multi-tenant runtime that productionises the OSS stack: OpenSearch-backed event store with native Document-Level Security, Keycloak-based identity (OIDC + API-key), GS1 Germany Activate Plus / GEPIR integration, Azure/AWS storage backends, AI assistant, Terraform/Ansible deployment. Thirteen Quarkus container images assembled from openepcis-build/.

What sets OpenEPCIS apart

1. Tenant isolation by design — not by application-layer filters

Most multi-tenant systems rewrite every database query to inject a tenant filter. OpenEPCIS doesn't. The application forwards the authenticated user's identity into the OpenSearch transport layer, and the OpenSearch Security plugin's native Document-Level Security (DLS) enforces isolation at the data layer. If the application code is wrong, the data layer is still right. See Architecture → DLS.

2. Live subscriptions without polling

EPCIS streaming subscriptions are matched the moment an event is indexed, in the same engine that holds the events. Matches are delivered via webhook or WebSocket immediately. Scheduled (cron-based) subscriptions sit alongside streaming for clients that want polling semantics — nightly digests, periodic compliance pulls — and clients opt into them explicitly. See Modules → EPCIS Events.

3. A real participant in the GS1 trust graph

Full "Verified by GS1" integration with GS1 Germany services — and it goes both ways. Inbound, the platform verifies GTIN / GLN identifiers against GS1 DE's registry (Activate Plus / GEPIR) and enriches the local record with authoritative attributes. Outbound, the brand owner's masterdata held in the deployment is published back through GS1 DE and propagates up to the GS1 Global Office resolver — the customer's deployment is the source-of-truth, and the global GS1 network reflects what's in it. A real node in the GS1 trust graph.

4. GS1 conformance, with a self-describing deployment

A deployment is discoverable by other systems out of the box — it publishes the self-describing document the GS1 Conformant Resolver standard expects, so the GS1 Global Office resolver and partner registries can find and validate it automatically rather than being hand-configured (the URL is /.well-known/gs1resolver). A dozen GS1-standard link types — gs1:pip, gs1:productSustainabilityInfo, gs1:recallStatus, gs1:certificationInfo, gs1:productImage, gs1:safetyInfo, gs1:instructions, gs1:serviceInfo, gs1:nutritionalInfo and more — are auto-derived from the masterdata's referenced files when a product, organisation or place is saved. Identifiers at rest are GS1 Digital Link, not EPC URN. See Modules → Resolver.

5. Wallet-agnostic Verifiable Credentials

Keycloak sits at the core of every business deployment, and Keycloak's native OID4VCI (OpenID for Verifiable Credential Issuance), OID4VP (Presentation) and SIOPv2 support turns each tenant realm into a Verifiable Credential Issuer in its own right. Credentials come out as sd-jwt-vc (selective disclosure first), jwt_vc_json, ldp_vc or ISO mDoc — the holder picks the format their wallet understands. Because the surface is open OpenID Foundation protocol rather than a proprietary wallet stack, the same issuer interoperates with every OID4VC-compliant wallet already in production or in pilot — EU Digital Identity Wallet, Catena-X Managed Identity Wallet, enterprise wallets, mobile holder apps, sector-specific wallets. We didn't pick a wallet camp; we picked the protocol. The Keycloak / OID4VC layer ships today; named EPCIS / DPP credential schemas and the capture-to-issuance pipeline land next on the roadmap, with UNTP Digital Conformity Credential compatibility as a first-class target.

Developer summary

How the modules layer

flowchart TD
    bom["<b>openepcis-bom</b><br/><i>Maven version anchor</i>"]
    models["<b>shared core libs</b><br/>models<br/>epcis-constants<br/>commons"]
    fmt["<b>format &amp; validation</b><br/>document-converter<br/>validation-service<br/>event-hash-generator<br/>dl-translator"]
    biz["<b>business service libs</b><br/>capture · query<br/>subscription · repository<br/>storage · OpenTelemetry"]
    dist["<b>quarkus-dist profiles</b><br/>13 Quarkus assemblies<br/>in openepcis-build/"]
    img["<b>container images</b><br/>registry.company-group.com"]
    bom --> models --> fmt --> biz --> dist --> img

The Maven BOM is the only version that matters; everything else inherits.

How OSS feeds the business edition

openepcis-build/ is the assembly point. It consumes the OSS modules in two ways:

1. As Maven dependencies for the libraries (models, BOM, document-converter, dl-translator, event-hash-generator, epcis-constants, test-resources, S3 utils).
2. As git submodules for the modules that need source-level integration (resolver, REST/SOAP Quarkus apps document-converter-sax, keycloak-api-key).

Business-only modules live under openepcis-build/modules/openepcis-core/ and are bundled by Quarkus profiles in quarkus-dist/ into the deployable containers. The same set of OSS jars sits underneath every business container; the business modules add the multi-tenant runtime, storage backends, and operational concerns.

The GS1 conformance loop (today and tomorrow)

flowchart TD
    ev["<b>EPCIS Event</b><br/><i>Digital Link form</i>"]
    repo["<b>Repository</b><br/><i>OpenSearch</i><br/>hash-deduplicated<br/>tenant-scoped"]
    qs["<b>Query · Subscriptions</b><br/><i>percolator-driven</i>"]
    mdT["<b>Masterdata sync (today)</b><br/>explicit POST<br/>/organizations<br/>/products · /places"]
    mdR["<b>Roadmap</b><br/>event-driven promotion<br/>(EPCIS → resolver)"]
    linksets["<b>Resolver linksets</b><br/>auto-populated:<br/>gs1:pip · gs1:masterData · …"]
    ev -->|"/capture"| repo
    repo --> qs
    repo --> mdT
    mdT --> linksets
    mdR -.->|"roadmap"| linksets

    classDef roadmap stroke-dasharray:4 3,fill:#fef3f2,stroke:#d92d20
    class mdR roadmap

The plumbing for event-driven masterdata sync is present in the resolver (MasterDataDomainEvent, MasterDataSyncEventExecutor); what is not yet wired is the bridge from /capture into that domain bus. It's a named milestone — see Roadmap.

Where to read next

• Architecture — auth, DLS, the reactive pipeline, the GS1 conformance contract. Cite-heavy.
• Feature matrix — every capability × edition, with the module that provides it.
• Roadmap — Now, Next, Later.
• Module groups: Resolver · Masterdata · EPCIS Events · Formats · Integration · Testdata · Platform.