Each chapter is collapsed — click a title (or a Contents entry) to open it. Sections with sub-topics expand the same way.

A plain-language, always-current summary of every active enrichment rule, written by the AI. It regenerates automatically whenever a rule changes.

This service automatically enriches products in Ergonode (the Product Information Management system). When a product is created or moved to status New, the service researches and fills in its missing attributes, sources and generates product images, scores everything for quality, and writes the accepted values back to Ergonode — turning a New product into{" "} Done (fully enriched) or Review (needs a human) with no manual data entry.

Every value it writes is backed by a source and a quality score, and the full reasoning is attached to the product as a downloadable ai-product-log CSV, so Operations can defend or correct any AI-generated value.

Connecting the real Ergonode and Google Vertex AI is a configuration step done in Admin Settings (see Connecting Ergonode & Vertex). Until then the pipeline calls fail loudly rather than using mock data, so you can always see exactly what is and isn’t working.

Each product moves through these Ergonode statuses:

The service polls Ergonode on a configurable interval (default 15 min). A product enters the pipeline whenever it is New, or whenever any AI-relevant attribute changes (a change to the log file or the status itself does not re-trigger it). Each product is{" "} claimed atomically, so it is processed exactly once even with several workers running.

For each claimed product the service runs these steps in order:

Requirement resolution — works out which attributes are Required / Optional / Skip from the product’s Template, Type and category (with per-category overrides).
Context loading — gathers existing attributes, the parent product’s binding attributes (for variants), any Content-Link assets, and the effective free-text category rules.
Per attribute: research → manipulation → scoring. The AI researches a value with a source, anchored on the product’s known identifiers (product name, brand, GTIN, MPN, article number) to lock onto the right product, then manipulation rules clean/format it and the Quality Score is computed. Research is restricted to the trusted-source whitelist; if the score stays below the threshold (0.8) it retries once, then logs it. When “AI fallback beyond trusted sources” is enabled (Enrichment Rules → Trusted Sources), the retry may also consult sources outside the whitelist — which score lower on source trust.
Strict identifiers — GTIN/MPN/SKU/Article Nr. are only accepted if they appear verbatim in a trusted source; a GTIN must also pass its checksum, or it is dropped.
Image pipeline — sources and generates images, normalises them and writes multilingual alt text (see below).
Product-level second pass — checks completeness, variant-group consistency (a variant’s binding attributes match its parent) and the aggregate score.
Push — writes accepted attributes + images back to Ergonode, uploads the ai-product-log CSV, and sets the status to Done or Review. On a passing product everything is pushed; on a failing product only attributes that scored ≥ 0.8 are pushed.

Transient AI/network errors retry with exponential backoff; a terminal Ergonode push failure alerts the IT Slack channel and routes the product to Review.

Every enriched attribute gets an Attribute Quality Score between 0 and 1. Business-Rule Compliance is a knock-out gate: if a value breaks a rule, BRC = 0 and the whole AQS becomes 0. Otherwise:

AQS = 0.35·TSQ + 0.35·FPV + 0.25·CSC + 0.05·VFQ

An attribute needs AQS ≥ 0.8 to be pushed. A product reaches Done only if every required attribute passes and the product-level checks hold.

For every product the service:

Sources candidate images from the trusted-source whitelist, and always generates additional ones via the image model (Nano Banana), seeded with the sourced references.
Normalises each product image: segmentation-based background removal (handles white-on-white), optical centring on a white canvas with the configured padding, then WebP encoding under a file-size guard.
Mood images use a separate canvas with a geometric-centre crop (no background removal).
Produces a configurable number of hero, additional and mood images, rejects images with forbidden overlays (price tags, logos…), and writes alt text in DE/EN/FR/IT for every accepted image.

All image rules (canvas sizes, counts, padding, file-size cap, naming pattern, forbidden overlays) are edited under Enrichment Rules → Manipulation Rules → Image specs and apply on the next product. To review what a product actually produced — every sourced and generated image, each marked background-segmented or not with a clean ✓/✗ — open the Gallery tab of its history modal (Monitoring → click the ⓘ on a product).

Edits are batched: a floating Save N changes button appears at the bottom-right whenever you have unsaved changes across a page, and nothing is persisted until you click it.

The sidebar collapses to an icon rail via the hamburger at its base (hover an icon for its label). Every change is versioned and audited, and takes effect on the next product processed — no redeploy.

Access to the backoffice is governed by a single Users & Roles directory (Admin Settings → Users & Roles). Each person signs in with one of the methods below, and the roles on their account decide which sections they can open.

_{Username & password — a local user whose password an admin has set signs in with their e-mail and password.
Sign in with Google — when Google OAuth is configured (Admin Settings → Credentials → Google Auth), a user whose e-mail is listed in the directory can sign in with their Google account, no password needed.
Developer login — a bootstrap escape-hatch that grants Superadmin without a password. Disable it in production with ALLOW_DEV_LOGIN=false.

The directory is the allow-list for both methods. While it is empty, any Google account may sign in (with
the Monitoring role) and the developer login works — so you are never locked out during setup. Add
the first user and the allow-list takes effect.} _{In Users & Roles an admin adds a user (e-mail + name), ticks one or more roles, and optionally
sets a password — leave it blank for a Google-only user, or to keep an existing password unchanged.
A local + password or Google-only badge shows how each user signs in, and
deleting a user removes their access. Because this screen can grant any role and set passwords, it is
Superadmin-only.}

_{In Admin Settings → Credentials → Ergonode: enter the base URL, the content language (e.g. en_GB or de_CH) and a GraphQL API key with write access (created in Ergonode under System Settings → API keys). Click Test connection. The integration is GraphQL-only (POST /api/graphql/ with an X-API-KEY header) — there is no username/password. Products are matched by SKU and attributes by their code. The API key is write-only: it is stored for the service to use and never shown again.
Ergonode data operations live under Services → Attributes: the attribute overview (every Ergonode attribute, each with an In research toggle), Import / sync attributes (Ergonode is the single source of truth — new attributes are added, existing ones keep their config, and attributes no longer in Ergonode are removed) and Pull categories & overwrite (imports the category tree into Enrichment Rules → Per-Category Rules, overwriting the local tree and dropping rules whose category no longer exists).} _{In Admin Settings → Credentials → Vertex AI: set the GCP project id, then a model and (optionally) a region per pipeline step — useful when a model is only served in some regions. The service-account key is uploaded here (write-only) or mounted at secrets/vertex-sa.json; the page shows whether it is present and valid. Use Run smoke test to confirm every step works against the live project.
Until both are configured, the pipeline calls fail loudly with a clear message — there are no mock fallbacks — so you always see exactly what works and what doesn’t.}

On the Services page each pipeline service (Ingestion, Research, Manipulation, Scoring, Image Sourcing, Image Creation, Push) is a row you switch active/passive and schedule — always-on or a weekly time window — from its ⋯ menu. A passive service becomes a no-op and is logged, useful for staged rollout or a quick rollback. The same page has a Process runners table to start and stop the two background processes — the Worker (consumes the queue and enriches products) and the Poller (auto-discovers New products on the configured interval) — each with a live CLI log. How many products the Worker enriches in parallel is set by Concurrent products under Admin Settings → Runtime.

Every AI call records its cost. A per-product ceiling stops enriching a product once it gets too expensive; a daily ceiling trips the kill-switch, which halts all new AI work (products already in flight finish). Pause or resume everything from the Services page, or reset the kill-switch from the Dashboard. The Dashboard also shows the average cost per product; you can reset it — together with the queue and processing log — under Admin Settings → Actions. Every action is audited.

For every processed product, a CSV is attached to the product in Ergonode with one row per attribute and per image, sorted by quality (lowest first). Reviewers download it to see exactly why each value was accepted or rejected. Columns:

row_type · attribute_name/image_position · candidate_value/image_filename · aqs · brc · tsq · fpv · csc · vfq · source_url · source_excerpt · model_id · prompt_version · manipulation_rule_version · alt_text_de/en/fr/it · rejection_reason · timestamp

{title}

{title}