Event Sourcing for Physical Products: Architecture Guide

event sourcing physical products is an event-driven approach to physical product data: instead of storing state, you record every event that changes a product's status, location, or condition. The Thing Event System (TES), built by Pentatonic, provides the event-sourced infrastructure to make this practical at any scale — one API, one data model, compliance data as a byproduct.

According to Gartner, by 2028, 33% of enterprise software applications will include agentic AI, up from less than 1% in 2024.

2026-03-30

A circular economy decouples economic activity from the consumption of finite resources. It is a resilient system that is good for business, people, and the environment.

Ellen MacArthur Foundation

The TES Data Model

TES models every physical product as an append-only event log. There are three core types:

// A Thing is any physical object you want to track
interface Thing {
  id: string;           // UUID, stable for the product's lifetime
  sku: string;          // Your product identifier
  gtin?: string;        // Optional: GTIN / barcode
  metadata: Record<string, unknown>;
  createdAt: string;    // ISO 8601
}

// A ThingEvent records something that happened to a Thing
interface ThingEvent {
  id: string;
  thingId: string;
  type: ThingEventType; // see below
  actor: string;        // who or what triggered the event
  payload: Record<string, unknown>;
  occurredAt: string;
}

// Core event types — extend with custom types for your domain
type ThingEventType =
  | "manufactured"
  | "shipped"
  | "sold"
  | "returned"
  | "graded"
  | "relisted"
  | "refurbished"
  | "recycled"
  | "passport_issued";  // triggers EU DPP generation

Because the log is append-only, you always have a complete audit trail. Rolling back a return, disputing a grade, or generating a Digital Product Passport is a read operation on the event log — not a destructive update.

Getting Started

Step 1: Understand event sourcing for physical objects

In TES, a product's current state (location, condition, owner) is derived from its event log — not stored directly. This means you never lose historical data, can reconstruct state at any point in time, and compliance data is a natural byproduct.

// Derive current condition from event log
const history = await tes.things.history(thingId);
const lastGradeEvent = [...history]
  .reverse()
  .find(e => e.type === "graded");
const currentCondition = lastGradeEvent?.payload?.grade ?? "ungraded";

Step 2: Model your domain events

Map your existing operations to TES event types. Most brands start with four events: sold, returned, graded, and relisted. Add custom event types as you scale.

// Register a custom event type for your domain
await tes.eventTypes.register({
  name: "repair_completed",
  schema: {
    repairType: "string",
    technician: "string",
    partsReplaced: "string[]"
  }
});

Step 3: Issue a Digital Product Passport

Emit a passport_issued event to trigger EU Digital Product Passport generation. TES assembles the passport from the product's event history automatically — no separate data pipeline required.

await tes.events.emit({
  thingId: thing.id,
  type: "passport_issued",
  actor: "compliance-system",
  payload: { regulation: "EU_DPP_2027", issuedBy: "your-brand.com" }
});

// Retrieve the passport
const passport = await tes.passports.get(thing.id);
console.log(passport.url); // https://passport.thingeventsystem.ai/...

According to European Commission, ESPR Regulation 2024/1781, eU Digital Product Passport requirements take effect for batteries in 2027, textiles and electronics by 2030 under the ESPR regulation.

Next Steps

TES is available now. The fastest path forward:

Install: npm install @pentatonic/tes
Get an API key: Book a Demo — Pentatonic will provision your account and walk through your integration.
Track your first product: Three function calls. Under ten minutes.

Full API reference and docs at thingeventsystem.ai.

Why TES Instead of Building It Yourself

TES is not a generic event bus. It is purpose-built for physical product lifecycle tracking, which means the hard parts are already solved:

Concern	Custom build	TES
Data model	Design and version your own event schema	Battle-tested Thing + ThingEvent model, stable versioning
API surface	Design, build, auth, document, maintain	Single REST + SDK API, OpenAPI spec included
Compliance outputs	Write formatters per regulation, update when specs change	EU DPP, EPR reports generated from event log automatically
Audit trail	Append-only log requires careful schema discipline	Enforced by design — the log is immutable
Build vs. buy decision	6-12 months to build equivalent infrastructure	10 minutes to first tracked product
Integrations	Build per-platform connectors	Shopify, Salesforce, SAP connectors included

The single-API design is a deliberate choice. Every system that touches a physical product — returns portal, warehouse WMS, resale storefront, compliance reporting — uses the same TES endpoint. No fan-out integration problem.

FREQUENTLY ASKED QUESTIONS

Why use event sourcing for physical products instead of a database record?

A mutable database record stores current state and discards history. For physical products — especially under EU DPP and EPR regulations — you need the complete history. Event sourcing stores every state change, so current state and full history are both always available.

How does TES handle schema evolution as product categories change?

TES separates the core event schema (stable, versioned) from event payload (flexible, schema-registered). When you introduce a new product category, register a custom event type with its schema. Existing events are unaffected.

What npm package do I use to integrate with TES?

Install @pentatonic/tes from npm: npm install @pentatonic/tes. Initialize with your API key and start emitting product lifecycle events immediately.

How do I comply with the EU Digital Product Passport using TES?

Emit a passport_issued event against any tracked product. TES assembles the EU DPP from the product's event history and returns a hosted passport URL. No separate compliance pipeline is needed — compliance data is a byproduct of tracking operations you should already be running.

What data model does TES use for product lifecycle tracking?

TES uses an event-sourced model. A Thing represents a physical object identified by a stable UUID. ThingEvents record state changes — manufacture, sale, return, grade, resale, recycle. Current state is derived by replaying the event log, which means the full history is always queryable and nothing is ever overwritten.