---
title: "Feature Matrix"
description: "OpenEPCIS capabilities by edition, aligned to the relevant GS1 standards."
canonical_url: "https://openepcis.io/docs/platform-overview/feature-matrix"
last_updated: "2026-07-02T20:31:21.740Z"
---

Legend: `✓` = available · `✓ (basic)` = available with limitations; see notes · `✓ (variant)` = available in a build variant · `partial` = building blocks present, not fully wired end-to-end · `roadmap` = planned, not yet started · `—` = not in this edition.

Capabilities are grouped by the seven module families the platform is organised around — Resolver, Masterdata, EPCIS Events, Formats & Validation, Integration, Access Control, Testdata, Platform. The deeper stories (multi-tenant isolation at the data layer, live subscriptions, the SAX converter) live on the [Architecture](/docs/platform-overview/architecture) and module-group pages.

## GS1 Conformant Resolver

The full GS1 Conformant Resolver ships in the business edition. The OSS rows below are the building blocks for working with GS1 identifiers — URN ↔ Digital Link translation, barcode rendering, identifier validation.

<table>
<thead>
  <tr>
    <th>
      Capability
    </th>
    
    <th>
      OSS
    </th>
    
    <th>
      Business
    </th>
    
    <th>
      Notes
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      GS1 Conformant Resolver (multi-tenant, REST)
    </td>
    
    <td>
      <span className="fm-no">
        —
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      One deployment serves many brand owners; partners and consumers integrate using standard GS1 link types, no bespoke clients.
    </td>
  </tr>
  
  <tr>
    <td>
      Self-describing deployment
    </td>
    
    <td>
      <span className="fm-no">
        —
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      Implements the GS1 Conformant Resolver discovery contract — downstream registries (the GS1 Global Office resolver, partner systems) find the deployment and read what it offers automatically, no hand-configuration needed. Served at <code>
        /.well-known/gs1resolver
      </code>
      
      .
    </td>
  </tr>
  
  <tr>
    <td>
      A dozen GS1 link types auto-derived from masterdata
    </td>
    
    <td>
      <span className="fm-no">
        —
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      Save a product once and the resolver derives the standard link relations (<code>
        gs1:pip
      </code>
      
      , <code>
        gs1:productImage
      </code>
      
      , <code>
        gs1:certificationInfo
      </code>
      
      , <code>
        gs1:productSustainabilityInfo
      </code>
      
      , <code>
        gs1:safetyInfo
      </code>
      
      , <code>
        gs1:instructions
      </code>
      
      , <code>
        gs1:nutritionalInfo
      </code>
      
      , <code>
        gs1:recallStatus
      </code>
      
      , <code>
        gs1:serviceInfo
      </code>
      
      , <code>
        gs1:audioFile
      </code>
      
      , <code>
        gs1:relatedVideo
      </code>
      
      ). No manual linkset POST per product.
    </td>
  </tr>
  
  <tr>
    <td>
      Bulk CSV / JSON-LD linkset import
    </td>
    
    <td>
      <span className="fm-no">
        —
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      First-time onboarding path — tens of thousands of products in a single call.
    </td>
  </tr>
  
  <tr>
    <td>
      Tenant-scoped masterdata cache
    </td>
    
    <td>
      <span className="fm-no">
        —
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      Keeps resolution fast under multi-tenant load; each customer's hot path stays in cache without crossing tenants.
    </td>
  </tr>
  
  <tr>
    <td>
      Linkset change audit
    </td>
    
    <td>
      <span className="fm-no">
        —
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      Who changed which linkset, when — what regulated brand owners need to satisfy due-diligence and traceability reviews.
    </td>
  </tr>
  
  <tr>
    <td>
      EPC URN ↔ Digital Link translation
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      For interop with legacy systems still emitting <code>
        urn:epc:id:…
      </code>
      
      ; same library powers URN-on-demand at query time.
    </td>
  </tr>
  
  <tr>
    <td>
      QR / Data Matrix / GS1-128 barcode generation
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      One Digital Link URI rendered into any GS1-conformant barcode — pick by use case (QR for consumer scans, DataMatrix for small parts, GS1-128 for cartons).
    </td>
  </tr>
</tbody>
</table>

## GS1 Web Vocabulary & Masterdata

<table>
<thead>
  <tr>
    <th>
      Capability
    </th>
    
    <th>
      OSS
    </th>
    
    <th>
      Business
    </th>
    
    <th>
      Notes
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      GS1 Web Vocabulary data model (libraries)
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      Java types for the GS1 Web Vocabulary — useful when building integrations or generating documents outside the platform.
    </td>
  </tr>
  
  <tr>
    <td>
      Masterdata REST API (<code>
        /organizations
      </code>
      
      , <code>
        /products
      </code>
      
      , <code>
        /places
      </code>
      
      )
    </td>
    
    <td>
      <span className="fm-no">
        —
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      Platform discipline: masterdata lives on the resolver, never embedded inside EPCIS events. One source of truth, no duplication, no contradictory copies.
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Full "Verified by GS1" integration with GS1 Germany services
      </strong>
    </td>
    
    <td>
      <span className="fm-no">
        —
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      Bidirectional. Inbound: verifies a GTIN or GLN against GS1 Germany's registry (Activate Plus / GEPIR) and enriches the local record with authoritative party / product attributes. Outbound: publishes the brand owner's masterdata back into the GS1 network — the deployment acts as source-of-truth and the records propagate up to the GS1 Global Office resolver. A real node in the GS1 trust graph.
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Event → Resolver masterdata promotion
      </strong>
    </td>
    
    <td>
      <span className="fm-no">
        —
      </span>
    </td>
    
    <td>
      <span className="fm-partial">
        partial
      </span>
    </td>
    
    <td>
      The internal masterdata bus exists; what's missing is the bridge from <code>
        /capture
      </code>
      
       into it. Once landed, an EPCIS event will register new masterdata implicitly — closing the "events drive masterdata" loop.
    </td>
  </tr>
</tbody>
</table>

## EPCIS Events: Capture · Query · Subscriptions

<table>
<thead>
  <tr>
    <th>
      Capability
    </th>
    
    <th>
      OSS
    </th>
    
    <th>
      Business
    </th>
    
    <th>
      Notes
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      EPCIS 2.0 REST <code>
        /capture
      </code>
    </td>
    
    <td>
      <span className="fm-no">
        —
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      Single endpoint for any volume — documents are validated, hashed, deduplicated and stored in one pipeline.
    </td>
  </tr>
  
  <tr>
    <td>
      EPCIS 2.0 REST <code>
        /query
      </code>
      
       (Named Queries)
    </td>
    
    <td>
      <span className="fm-no">
        —
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      Filter by EPC, biz-step, location, time window; queries can be stored, named, and re-run by partners without re-sending the criteria each time.
    </td>
  </tr>
  
  <tr>
    <td>
      EPCIS 2.0 SOAP binding
    </td>
    
    <td>
      <span className="fm-no">
        —
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      For partners still on the EPCIS 1.x message bus — same backend, different envelope.
    </td>
  </tr>
  
  <tr>
    <td>
      Hash-based event deduplication
    </td>
    
    <td>
      <span className="fm-basic">
        ✓ lib
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      Resending the same event produces the same ID. Capture is idempotent — safe to retry after a network hiccup without doubling up the event store.
    </td>
  </tr>
  
  <tr>
    <td>
      Streaming subscriptions (live, no polling)
    </td>
    
    <td>
      <span className="fm-no">
        —
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      a match fires the moment an event is indexed. No poll interval, no missed window, no "did I get that one yet?" debate.
    </td>
  </tr>
  
  <tr>
    <td>
      Scheduled subscriptions
    </td>
    
    <td>
      <span className="fm-no">
        —
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      Cron-style delivery for partners that prefer batch-style — nightly digests, periodic compliance pulls.
    </td>
  </tr>
  
  <tr>
    <td>
      WebSocket delivery
    </td>
    
    <td>
      <span className="fm-no">
        —
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      Push channel for browsers and lightweight clients.
    </td>
  </tr>
  
  <tr>
    <td>
      Webhook delivery
    </td>
    
    <td>
      <span className="fm-no">
        —
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      Standard HTTP POST to any partner endpoint.
    </td>
  </tr>
  
  <tr>
    <td>
      Digital Link canonical form at rest, URN on demand
    </td>
    
    <td>
      <span className="fm-no">
        —
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      Stored once in Digital Link form. Clients still on EPC URN form get it rendered on demand — no double storage, no drift between formats.
    </td>
  </tr>
  
  <tr>
    <td>
      Reliable paginated queries that survive reconnects
    </td>
    
    <td>
      <span className="fm-no">
        —
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      A six-month export can disconnect and resume on the same scroll cursor — important for regulators and big partners pulling long histories.
    </td>
  </tr>
  
  <tr>
    <td>
      OpenSearch backend
    </td>
    
    <td>
      <span className="fm-no">
        —
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      Primary store — open source, scales horizontally, supports the percolator queries the live subscriptions ride on.
    </td>
  </tr>
  
  <tr>
    <td>
      Elasticsearch backend (variant)
    </td>
    
    <td>
      <span className="fm-no">
        —
      </span>
    </td>
    
    <td>
      <span className="fm-variant">
        ✓ variant
      </span>
    </td>
    
    <td>
      For deployments where the customer's existing observability or compliance posture already standardises on Elasticsearch.
    </td>
  </tr>
  
  <tr>
    <td>
      High-volume capture variant
    </td>
    
    <td>
      <span className="fm-no">
        —
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      Headless capture pipeline for environments where events arrive over Kafka rather than HTTP — the REST front-end is replaced by a stream consumer.
    </td>
  </tr>
</tbody>
</table>

## Formats, Validation & Identity

<table>
<thead>
  <tr>
    <th>
      Capability
    </th>
    
    <th>
      OSS
    </th>
    
    <th>
      Business
    </th>
    
    <th>
      Notes
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      XML ↔ JSON-LD conversion
    </td>
    
    <td>
      <span className="fm-basic">
        ✓ basic
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      OSS: XSLT, load-then-transform — fine for the common cases (single events, small batches, plain shapes). Business: SAX-streaming — multi-gigabyte exports, deep extension trees, complex sensor payloads, mixed-format batches.
    </td>
  </tr>
  
  <tr>
    <td>
      EPCIS 1.2 ↔ 2.0 XML migration
    </td>
    
    <td>
      <span className="fm-basic">
        ✓ basic
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      OSS: the XSLT converter handles straightforward migrations. The Business edition adds the SAX converter — the production-grade path used to migrate live 1.2 corpora to 2.0.
    </td>
  </tr>
  
  <tr>
    <td>
      EPCIS document validation
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      Catches malformed events at the boundary so they never land in the event store. Cheaper than discovering the problem six months later in a query result.
    </td>
  </tr>
  
  <tr>
    <td>
      Custom-extension validation across the event
    </td>
    
    <td>
      <span className="fm-no">
        —
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      For organisations with proprietary fields that need to coexist with the GS1 vocabulary — extensions are validated at every nesting level of the document.
    </td>
  </tr>
  
  <tr>
    <td>
      Sensor element validation
    </td>
    
    <td>
      <span className="fm-no">
        —
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      Makes sensor payloads structurally trustworthy — units, value types, device IDs all checked at capture time.
    </td>
  </tr>
  
  <tr>
    <td>
      Pre-canonical event hash (idempotent event IDs)
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      The hash is computed against a normalised representation of the event — whitespace, attribute order, JSON key order don't affect the ID. Re-sends and round-trips through different serialisers produce the same event ID.
    </td>
  </tr>
  
  <tr>
    <td>
      Web UI for format conversion
    </td>
    
    <td>
      <span className="fm-no">
        —
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      Browser-based for non-technical users — drag in an XML or JSON-LD file, get the other format back. Same engine as the API.
    </td>
  </tr>
  
  <tr>
    <td>
      Hash generator as a service
    </td>
    
    <td>
      <span className="fm-no">
        —
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      REST endpoint for partners who want canonical event IDs without running the converter locally.
    </td>
  </tr>
</tbody>
</table>

## Integration & Gateways

<table>
<thead>
  <tr>
    <th>
      Capability
    </th>
    
    <th>
      OSS
    </th>
    
    <th>
      Business
    </th>
    
    <th>
      Notes
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      S3-compatible storage
    </td>
    
    <td>
      <span className="fm-basic">
        ✓ lib
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      Any object store that speaks the S3 API — AWS S3, on-prem implementations, S3-compatible appliances.
    </td>
  </tr>
  
  <tr>
    <td>
      Azure Blob storage
    </td>
    
    <td>
      <span className="fm-no">
        —
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      First-class option for Azure-native deployments — no S3 gateway in front.
    </td>
  </tr>
  
  <tr>
    <td>
      File upload / download service
    </td>
    
    <td>
      <span className="fm-no">
        —
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      REST endpoint for bulk inputs and outputs that are too large to fit comfortably inside JSON payloads.
    </td>
  </tr>
  
  <tr>
    <td>
      AI assistant (Ollama-backed)
    </td>
    
    <td>
      <span className="fm-no">
        —
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      Ask "show me last week's events for GTIN X" in plain English; the assistant classifies the intent (EPCIS query, identifier resolve, vocabulary lookup) and returns a translated EPCIS query plus the answer. Local LLM by default — no third-party API dependency.
    </td>
  </tr>
</tbody>
</table>

## Access Control (cross-cuts every business deployable)

<table>
<thead>
  <tr>
    <th>
      Capability
    </th>
    
    <th>
      OSS
    </th>
    
    <th>
      Business
    </th>
    
    <th>
      Notes
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      OIDC, session-cookie, and API-key authentication
    </td>
    
    <td>
      <span className="fm-no">
        —
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      Three credential shapes, one identity. Customers pick whichever fits their stack — OIDC for IdP-integrated systems, cookies for browser UIs, API keys for service-to-service traffic.
    </td>
  </tr>
  
  <tr>
    <td>
      Per-customer (tenant) isolation in Keycloak
    </td>
    
    <td>
      <span className="fm-no">
        —
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      Each customer gets their own realm — user accounts, groups, roles, and policies don't bleed across customers. Resolved automatically from the request's hostname.
    </td>
  </tr>
  
  <tr>
    <td>
      Data-layer tenant isolation (OpenSearch DLS)
    </td>
    
    <td>
      <span className="fm-no">
        —
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      the application doesn't rewrite queries to add a tenant filter. The data layer itself enforces isolation, so even if app code is wrong, customer data stays separated.
    </td>
  </tr>
  
  <tr>
    <td>
      Role-based access (<code>
        capture
      </code>
      
      , <code>
        query
      </code>
      
      )
    </td>
    
    <td>
      <span className="fm-no">
        —
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      Two roles ship out of the box — <code>
        capture
      </code>
      
       to write, <code>
        query
      </code>
      
       to read. Customers can layer their own granular permissions on top.
    </td>
  </tr>
  
  <tr>
    <td>
      Shareable read-only deep-links (capability tokens)
    </td>
    
    <td>
      <span className="fm-no">
        —
      </span>
    </td>
    
    <td>
      <span className="fm-partial">
        partial
      </span>
    </td>
    
    <td>
      Send a regulator a single URL for one specific batch — no full account access granted. Short-lived, scoped to one endpoint and one HTTP method.
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Wallet-agnostic Verifiable Credentials via OID4VC
      </strong>
    </td>
    
    <td>
      <span className="fm-no">
        —
      </span>
    </td>
    
    <td>
      <span className="fm-partial">
        partial
      </span>
    </td>
    
    <td>
      Each Keycloak realm is a Verifiable Credential Issuer through Keycloak's native OID4VCI / OID4VP / SIOPv2 implementation. Credentials in <code>
        sd-jwt-vc
      </code>
      
       (selective disclosure first), <code>
        jwt_vc_json
      </code>
      
      , <code>
        ldp_vc
      </code>
      
       and ISO mDoc — the holder picks the format. Interoperable with every OID4VC-compliant wallet already in production or in pilot (EU Digital Identity Wallet, Catena-X Managed Identity Wallet, enterprise business wallets, sector wallets). No wallet lock-in.
    </td>
  </tr>
  
  <tr>
    <td>
      Globally-scoped issuer trust list
    </td>
    
    <td>
      <span className="fm-no">
        —
      </span>
    </td>
    
    <td>
      <span className="fm-partial">
        partial
      </span>
    </td>
    
    <td>
      Verifiers need to know which issuers are trustworthy. OpenEPCIS expects to maintain an open, globally-scoped trust list — not EU-only or sector-only. The trust-list surface and population pipeline are the work in flight.
    </td>
  </tr>
  
  <tr>
    <td>
      EPCIS event → VC issuance pipeline
    </td>
    
    <td>
      <span className="fm-no">
        —
      </span>
    </td>
    
    <td>
      <span className="fm-partial">
        partial
      </span>
    </td>
    
    <td>
      The protocol layer (Keycloak OID4VCI / OID4VP) ships today. The named credential schemas (<code>
        EPCISCommissioningCredential
      </code>
      
      , <code>
        DPPBatteryPassportCredential
      </code>
      
      , <code>
        EUDRDueDiligenceCredential
      </code>
      
      , <code>
        UNTPDigitalConformityCredential
      </code>
      
      ) and the bridge from capture/save into VC issuance are the named <a href="/docs/platform-overview/roadmap">
        roadmap
      </a>
      
       item.
    </td>
  </tr>
  
  <tr>
    <td>
      UNTP Digital Conformity Credential compatibility
    </td>
    
    <td>
      <span className="fm-no">
        —
      </span>
    </td>
    
    <td>
      <span className="fm-partial">
        partial
      </span>
    </td>
    
    <td>
      UNTP DCC is exactly the kind of VC the OID4VCI layer issues. Schema and field mapping to be published alongside the named credential pipeline.
    </td>
  </tr>
  
  <tr>
    <td>
      Verifier reference UI / SDK
    </td>
    
    <td>
      <span className="fm-no">
        —
      </span>
    </td>
    
    <td>
      <span className="fm-partial">
        partial
      </span>
    </td>
    
    <td>
      The OID4VP verification endpoint is live; a reference verifier UI for partners (browser-side and integrator SDK) is in flight.
    </td>
  </tr>
  
  <tr>
    <td>
      Row-level scoping below tenant (GLN / EPC / biz-loc)
    </td>
    
    <td>
      <span className="fm-no">
        —
      </span>
    </td>
    
    <td>
      <span className="fm-roadmap">
        roadmap
      </span>
    </td>
    
    <td>
      Today access is binary per tenant. Adding GLN-, EPC-range-, or biz-location-bound visibility (so a user sees only "their" sites) builds on the same DLS mechanism.
    </td>
  </tr>
</tbody>
</table>

## Testdata & Developer Tooling

<table>
<thead>
  <tr>
    <th>
      Capability
    </th>
    
    <th>
      OSS
    </th>
    
    <th>
      Business
    </th>
    
    <th>
      Notes
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      Test event generation (REST + UI + bulk)
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      Synthesise realistic supply chains end-to-end — single events for demos, programmatic feeds for integration tests, or millions of events for performance work.
    </td>
  </tr>
  
  <tr>
    <td>
      Re-capture / replay tool
    </td>
    
    <td>
      <span className="fm-no">
        —
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      Read events from one deployment, re-capture them into another (or the same one). Useful for environment cloning, regression scenarios, and reproducing production issues in a dev environment.
    </td>
  </tr>
  
  <tr>
    <td>
      Reference event collection (XML + JSON-LD)
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      Curated examples of every EPCIS 2.0 event shape, biz-step, and disposition — in both XML and JSON-LD. Used to test validators and onboard integrators.
    </td>
  </tr>
  
  <tr>
    <td>
      EPCIS REST conformance test suite
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      Point it at any EPCIS 2.0 endpoint — yours or anyone else's — and get a conformance report. The standards-compliance test set, open source; the Business edition extends it with platform-specific checks (multi-tenant DLS, capability tokens, the auto-derived linkset pipeline).
    </td>
  </tr>
  
  <tr>
    <td>
      Client SDK examples (multi-language)
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      Java, Python, Node.js, Go — example calls against <code>
        /capture
      </code>
      
       and <code>
        /query
      </code>
      
       to bootstrap an integration.
    </td>
  </tr>
</tbody>
</table>

## Platform & Operations

<table>
<thead>
  <tr>
    <th>
      Capability
    </th>
    
    <th>
      OSS
    </th>
    
    <th>
      Business
    </th>
    
    <th>
      Notes
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      Self-host on Kubernetes (Terraform / Helm)
    </td>
    
    <td>
      <span className="fm-no">
        —
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      Reference Terraform modules + Helm charts for production deployment — opinionated but not vendor-locked.
    </td>
  </tr>
  
  <tr>
    <td>
      Self-host on Docker Compose
    </td>
    
    <td>
      <span className="fm-no">
        —
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      Ansible-driven Docker Compose stack — the fast path for smaller deployments and local development.
    </td>
  </tr>
  
  <tr>
    <td>
      OpenTelemetry tracing
    </td>
    
    <td>
      <span className="fm-no">
        —
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
    
    <td>
      End-to-end traces across REST endpoints, capture pipeline, and storage — drop into whatever observability stack the customer already runs (Grafana, Jaeger, Honeycomb, …).
    </td>
  </tr>
</tbody>
</table>

---

> This matrix lists what's available today. The [roadmap](/docs/platform-overview/roadmap) lists the strategic next steps — Verifiable Credentials for EPCIS events, the event-to-resolver masterdata bridge, sub-tenant scoping, and a retrieval corpus for the AI assistant.