Products, versioning & assets

Products are the core entity in PIE. A product carries structured attributes (name, SKU, GTIN, category-specific fields), belongs to a category, links to reference entities, and can be localized, versioned, and published.

Categories and attributes

Every product belongs to a category that defines its attribute schema. A fresh producer organisation ships with a seeded "Food (built-in)" category so you can create a compliant food product immediately, plus example categories (fresh produce, processed food, beverages). Category attributes are stored as structured JSON, so different categories can carry very different fields without schema migrations.

Creating products

• Manually — fill in the attributes in the product editor. Set the target markets; the required locales follow from them.
• Via AI ingestion — upload a spec sheet or paste a URL and let the pipeline extract a draft, which you review before import. See the AI guide.

Products use a soft delete: a deleted product is marked with a timestamp and disappears from lists, but its history is retained.

Reference entities

Link reference entities — allergens, nutrients, certifications, and other shared or custom types — instead of duplicating that data on every product. Entity-sourced data feeds the GS1 Global Data Model projection, compliance evaluation, and Digital Product Passports, so linking entities once pays off across subsystems.

Versioning

Product edits are versioned automatically. Every update writes a snapshot of the previous state to the version history and bumps the product's version number, in a single transaction — so you always have a complete, auditable history and can see exactly what changed and when.

Localization

PIE stores one canonical set of attributes plus per-locale overrides. You edit a specific locale (for example de-DE, de-CH, fr-CH) and only the fields you translate are overridden; everything else falls back to canonical. Quality and compliance are scored per locale with fallback disabled, so a missing translation is scored as missing rather than silently passing. Enabled locales come from your organisation settings and your product's target markets.

Assets

Assets are managed library-first: an asset is linked to products through asset links, not owned by a single product, so the same image or document can back several products.

Uploads never pass through the API server. The flow is:

1. Request a presigned upload URL for the product.
2. Upload the binary directly to object storage using that URL.
3. Confirm the upload — the API then stores only the asset metadata (bucket, key, MIME type, size).

Renditions (thumbnails and other derived sizes) are generated automatically. When you view or download an asset, the URL is a short-lived presigned URL generated on demand — asset URLs are never stored or served directly.

Publishing

Publishing a product runs it through the gates your organisation has enabled — quality, compliance, GS1 readiness, and workflow approval. Once published, a product can be exposed to buyers through grants, syndicated to channels and portals, and published as a Digital Product Passport.