One rule, every variant, reused.

A product configurator that generates thousands of valid codes from a few dozen database rows, reads any code back, and hands its catalog to the next system. Client anonymized.

The problem

One product line has thousands of variants: size, housing, ring, LED module, colour temperature, control gear, sensor, emergency pack. Every combination is a real, orderable product with its own article number. The naive build, one database row per finished product, doubles every time you add an option, drifts out of sync, and still cannot turn a pasted code back into a configuration.

The design: a grammar, not a table

The article number is a positional grammar. Each segment is resolved from a catalog row, so the code space is the product of the axes, computed on demand. There is no variant table.

Add one option and the whole space grows, with no migration and no table to rot.

And it runs in reverse

Paste any article number and the same grammar decodes it: product line, size, and every component, straight from the code. Generation and lookup are one rule read two ways.

Why it compounds

The catalog and codes are exposed as an API. That API became the product source of truth for a second system I built, the tender matcher, which reads it to match public-procurement notices to products.

Honest scope: the configurator is live; the article-number grammar and the reverse lookup are shipped and shown above. The catalog API is real and consumed by the tender matcher. Code counts are the encoding space per line, from the catalog's own axes.