Product Space Generator Script¶
Software or tool — instantiates Cross-Axis Product Space Design
Automatically generates cell tuples, keys, and counts from declared axes and levels.
A Product Space Generator Script is executable code that takes a declaration of axes and their levels and mechanically emits the product: the tuples, a stable key for each cell, and the running count of how large the space is. Its defining idea is that the enumeration is derived, not maintained — the axis declaration is the single source of truth, and the grid is regenerated from it on demand rather than edited by hand. That is what makes it the right mechanism for volatile spaces: when someone adds a browser, drops a locale, or bumps a version, the product does not go stale, because it was never a hand-kept artifact in the first place — you change the declaration and re-run. Unlike a static matrix, its output is always as current as its inputs, and its whole job is to keep the machinery of enumeration and identity honest as the axes churn.
Example¶
A widely-used open-source Python library must be tested across a matrix that changes almost every month. The axes live in a config file: Python version (3.9, 3.10, 3.11, 3.12), operating system (Linux, macOS, Windows), and a key dependency's version (NumPy 1.x, NumPy 2.x). A generator script reads that file and emits the CI test matrix — 4 × 3 × 2 = 24 job entries, each with a deterministic key like py3.11-macos-numpy2 that names the job, tags its logs, and lets a flaky-test dashboard reference the exact cell.
The value shows when the world moves. Python 3.13 ships; a maintainer adds one line to the axis declaration; the next run regenerates 30 job entries with stable keys, and the three new cells appear automatically in the CI dashboard. No one hand-edited a workflow file, so no cell was forgotten and no duplicate crept in. When NumPy 1.x is finally dropped, one deletion removes six cells cleanly. The count is printed on every run, so a maintainer who casually proposes adding an ARM axis sees immediately that it would take the matrix from 30 jobs to 60 — a cost visible before the commit rather than discovered in a billing surprise.
How it works¶
- Read the declaration. Axes and their level sets live in a single machine-readable source; the script treats that file as canonical and derives everything else from it.
- Emit the product with keys. It computes the Cartesian product and assigns each cell a deterministic, human-legible key, so the same cell always gets the same identity across runs.
- Print the count. Every run reports the current cell total, making the size — and any growth — an explicit, reviewable number.
- Regenerate on change. Because the output is a pure function of the declaration, an axis or level edit is applied by re-running, not by hand-patching the grid, which is what keeps a volatile space from drifting.
Tuning parameters¶
- Key scheme — how cell identities are formatted (positional tuple, hashed slug, human-readable string). Readable keys aid debugging; hashed keys stay stable under reordering but read as noise.
- Output format — what the script emits (a CI matrix, a CSV, database rows, JSON); fixes which downstream systems can consume the product directly.
- Determinism / ordering — whether cell order and keys are stable across runs, which decides whether diffs between two generations are meaningful.
- Change-diff verbosity — whether a re-run reports added / removed cells versus just the new full set; diffs make an axis change auditable.
- Filter hook — whether the generator applies an external feasibility rule set as it emits, or emits the raw product for a separate filter to screen.
When it helps, and when it misleads¶
Its strength is currency and discipline together: a volatile product stays correct because it is regenerated from a single declaration, cell identities stay stable and collision-free because a machine assigns them, and the size of the space is surfaced as a number on every run so growth cannot sneak in unpriced. Making the axis declaration the single source of truth[n1] is exactly what stops the drift and duplication that plague hand-maintained matrices.
Its failure mode is that automation multiplies whatever it is given: a mistaken level or a conflated axis in the declaration is faithfully exploded across the entire product, and the script's confident output lends false authority to a space that was wrong at the root. It also generates the raw product — including infeasible cells — so a team that treats the generator's output as the admissible space skips the feasibility step entirely and tests configurations that cannot exist. The classic misuse is exactly that: reading "generated" as "valid." The guarding discipline is to review the declaration as carefully as code, always pass the generated product through a feasibility filter before treating any cell as real, and watch the printed count as the early warning it is.
How it implements the components¶
combination_enumerator— it computes the Cartesian product mechanically, emitting one tuple per cell straight from the declared axes and levels.cell_identity_rule— it assigns each cell a deterministic, stable key, so the same combination is identifiable and de-duplicated across every regeneration.axis_change_control— because the product is derived from a single declaration, adding or removing an axis or level regenerates the space cleanly and reports the change, keeping volatile spaces current.
It does not decide which generated cells are feasible or record why any are excluded (feasibility_filter, invalid_combination_exception_register — that is Invalid Combination Rule Sheet), it does not reduce the product to a covering subset (sampling_or_reduction_rule — that is Pairwise Covering Array), and it does not track which cells were tested (coverage_accounting_grid — that is Combinatorial Test Coverage Grid). It generates and re-generates the raw product; those siblings screen, reduce, and account for it.
Related¶
- Instantiates: Cross-Axis Product Space Design — it is the automation that keeps a volatile product space enumerated, identified, and current under change.
- Sibling mechanisms: Combinatorial Test Coverage Grid · Configuration Matrix · Full Factorial Matrix · Invalid Combination Rule Sheet · Pairwise Covering Array · Scenario Cube · Coverage Heatmap
Editorial Notes¶
Form Classification¶
Form family: Analysis, Modeling & Optimization
Rationale: The mechanism computes the Cartesian product, deterministic keys, and cell count as a pure function of declared axes and levels.
Nearest alternative: Control, Automation & Runtime — It runs automatically on change, but it produces a formal generated result rather than actuating an operational target.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Product Space Generator Script is most plausibly rooted in the computer_science tradition because its characteristic form depends on algorithms, data structures, formal interfaces, and software-system practice. The assignment tracks that formative lineage, not the many settings in which the mechanism can now be applied.
Related originating lineages:
- Mathematics — The mathematics tradition materially shaped Product Space Generator Script through its own practice of formal definition, proof, mapping, and quantitative structure.
Review resolution: Both blind reviewers agree that computer science is the primary origin. Explicit reconciliation resolves origin mode disagreement, encyclopedia synthesis disagreement. Formative alternate lineages are retained as mathematics; later breadth of use is recorded separately as domain_reach=multi_domain, while origin_mode=cross_disciplinary_synthesis describes the relationship among origin lineages.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] Single source of truth — the design principle that any given fact should be represented in exactly one authoritative place, from which all other representations are derived. A generator script applies it to a product space: the axis declaration is the one canonical statement of the space, and the grid, keys, and count are all derived from it rather than maintained in parallel, which is what prevents the drift and duplication of hand-kept matrices. ↩