Cross Axis Product Space Design¶
Define independent axes, list each axis's allowed choices, form the cross-product, and govern which cells are valid, covered, sampled, or deliberately excluded.
Essence¶
Cross-Axis Product Space Design is the solution pattern for making a combination space explicit. Instead of relying on a handful of familiar examples, it asks: what are the independent axes, what values can each axis take, and what cells are created when one value from every axis is chosen?
The archetype is useful when a team needs to govern configurations, scenarios, policy cases, experiments, tests, support commitments, or design alternatives. Its value is not merely that it creates a big table. Its value is that the table becomes accountable: some cells are feasible, some are invalid, some are covered, some are sampled, some are high-risk, and some are deliberately out of scope.
Compression statement¶
Cross-Axis Product Space Design applies when a system must reason over all combinations made by selecting one value from each independent dimension. The intervention names the axes, specifies each axis's value set, forms the Cartesian product, gives each cell an identity, separates mathematically possible cells from feasible cells, tracks coverage or selection across the grid, and controls changes so new axes, removed levels, infeasible combinations, and sampled subsets do not create accidental blind spots.
Canonical formula: For axes A1, A2, ..., An with allowed value sets V1, V2, ..., Vn, construct P = V1 × V2 × ... × Vn; each cell p in P is an ordered tuple (v1, v2, ..., vn) with exactly one value from each axis.
When This Archetype Applies¶
Partial catalog groundingSome structural conditions are represented by existing abstractions, but no sufficient condition set is fully represented.
Diagnostic problem
A design, test, scenario, policy, configuration, or analysis space is governed through examples, anecdotes, or partial lists rather than through the full combination structure implied by its independent dimensions. As a result, important cells are never considered, impossible cells are treated as valid, coverage is overstated, interactions are missed, and later changes add or remove whole regions of possibility without review.
Applicability expression6 distinct conditions
groundedpartly groundedopen
6 conditions, all required.
6Required in every casenumbered 1–6
These hold no matter which pattern applies.
Multi-axis decision space · grounded · any one of 2
A decision space has multiple dimensions and each instance must choose one value on each dimension.
A design, test, scenario, policy, configuration, or analysis space is governed through examples, anecdotes, or partial lists rather than through the full combination structure implied by its independent dimensions. The narrower requirement in this condition set is: A decision space has multiple dimensions and each instance must choose one value on each dimension.
primeCartesian Product— All combinations of independent dimensions, one choice per axis.
primeFactorial Design— Multiple variables tested together.
Factorial configuration set · grounded
A full factorial design, scenario cube, option matrix, configuration catalog, or combinatorial test plan is being created or maintained.
A design, test, scenario, policy, configuration, or analysis space is governed through examples, anecdotes, or partial lists rather than through the full combination structure implied by its independent dimensions. The narrower requirement in this condition set is: A full factorial design, scenario cube, option matrix, configuration catalog, or combinatorial test plan is being created or maintained.
primeFactorial Design— Multiple variables tested together.
Cell-based coverage claims · open
Coverage claims depend on cells that were generated from axis choices rather than on a simple one-dimensional list.
As a result, important cells are never considered, impossible cells are treated as valid, coverage is overstated, interactions are missed, and later changes add or remove whole regions of possibility without review. The narrower requirement in this condition set is: Coverage claims depend on cells that were generated from axis choices rather than on a simple one-dimensional list.
Explicit invalid combinations · open
Some combinations are infeasible, unsafe, legally disallowed, semantically invalid, or redundant and must be filtered explicitly.
This is a load-bearing situation condition in the diagnostic expression. The condition is: Some combinations are infeasible, unsafe, legally disallowed, semantically invalid, or redundant and must be filtered explicitly. If it does not hold, this particular condition set is incomplete.
Oversized product space · open
The product space is too large to exhaustively test or implement, so the reduction, sampling, or prioritization rule must be visible.
A design, test, scenario, policy, configuration, or analysis space is governed through examples, anecdotes, or partial lists rather than through the full combination structure implied by its independent dimensions. The narrower requirement in this condition set is: The product space is too large to exhaustively test or implement, so the reduction, sampling, or prioritization rule must be visible.
Multiplicative axis expansion · grounded · any one of 2
Adding one new axis or level multiplies the space and can invalidate prior coverage, capacity, or risk assumptions.
The same structure that prevents blind spots can create combinatorial overload unless the design distinguishes independent axes, valid levels, infeasible cells, sampling rules, and coverage obligations. The narrower requirement in this condition set is: Adding one new axis or level multiplies the space and can invalidate prior coverage, capacity, or risk assumptions.
primeCartesian Product— All combinations of independent dimensions, one choice per axis.
primeFactorial Design— Multiple variables tested together.
Other requirements and context (1)
Why these sit outside the expression
Goal — a goal states an intended outcome or evaluation criterion, not a pre-existing situation that independently summons the archetype.
GoalA team needs to know whether all configurations, scenarios, customer segments, factor combinations, permission bundles, or test conditions have been considered.
A design, test, scenario, policy, configuration, or analysis space is governed through examples, anecdotes, or partial lists rather than through the full combination structure implied by its independent dimensions. In this archetype, the relevant goal is: A team needs to know whether all configurations, scenarios, customer segments, factor combinations, permission bundles, or test conditions have been considered. It supplies a criterion for evaluating what the intervention should accomplish or preserve.
Coverage
3 of 6 conditions grounded · 3 open.
Key components¶
| Component | Description |
|---|---|
| Axis Set Definition ↗ | The first structural move is to name the axes. An axis is a dimension of variation such as device type, legal region, account tier, treatment dose, demand regime, permission role, or future context. A weak product space often begins with weak axes: categories are mixed, hidden assumptions are left out, or one axis contains several dimensions at once. |
| Level Set Per Axis ↗ | Every axis needs a value set. It is not enough to say “region” or “user type”; the model must say which regions and which user types count. The granularity matters. Coarse levels make the product manageable but may hide edge cases. Fine-grained levels increase visibility but multiply the space. |
| Combination Enumerator and Cell Identity Rule ↗ | The product space must be generated, at least symbolically. Each cell should have a stable identity, such as a tuple, row key, scenario ID, test case ID, or configuration ID. Without cell identity, teams cannot tell whether a case was covered, excluded, changed, or duplicated. |
| Feasibility Filter ↗ | The mathematical product may include cells that should not exist operationally. Some are impossible, unsafe, illegal, unsupported, redundant, or semantically invalid. A feasibility filter distinguishes the raw generated product from the admissible subset without erasing the reasons for exclusion. |
| Coverage Accounting Grid ↗ | Coverage accounting says what has actually been tested, implemented, documented, sampled, reviewed, supported, or evidenced. This is the component that turns a Cartesian product from a conceptual map into a governance instrument. |
| Combinatorial Blowup Guard ↗ | Every new axis or level multiplies the space. A blowup guard recalculates scope, cost, and risk before a team claims that old coverage still holds. It also signals when exhaustive enumeration must give way to pairwise coverage, representative sampling, equivalence classes, or risk-weighted prioritization. |
Common mechanisms¶
A morphological box is useful during design because it helps teams list dimensions and values, then recombine them. A full factorial matrix is useful when the product is small or assurance requirements are high. A configuration matrix is useful for product, service, software, or permission systems where many generated cells must be filtered into supported and unsupported cases. A scenario cube is useful for planning under multiple uncertainty axes.
For large spaces, a pairwise covering array or combinatorial test coverage grid can make coverage tractable, but these mechanisms must not be confused with exhaustive coverage. A product-space generator script can help volatile spaces stay current, while an invalid-combination rule sheet preserves why cells are excluded.
Parameter dimensions¶
The main parameters are the number of axes, the number of levels per axis, the degree of axis independence, the size of the raw product, the size of the feasible subset, the cost of missed cells, the volatility of axes and levels, the acceptable reduction rule, and the evidence required to claim coverage.
Invariants to preserve¶
The central invariant is one-value-per-axis cell construction. Each cell in the product must be interpretable as a tuple made from declared axes. The second invariant is boundary visibility: excluded axes and filtered cells must remain visible enough for review. The third invariant is coverage honesty: a sampled or pairwise subset must not be relabeled as complete coverage.
Neighbor distinctions¶
This archetype borders Multi-Dimensional Solution Space Exploration, but it is more operational. Exploration broadens candidate dimensions; Cross-Axis Product Space Design builds and governs the product of those dimensions. It borders Interaction Effect Mapping, but interaction mapping studies how combined factors affect outcomes, while this archetype defines the combination surface. It borders Composability Testing and Validation, but composability testing asks whether parts work together; this archetype supplies the combination grid and coverage model that such testing may use.
It also borders Discrete Commitment Optimization. Optimization chooses among feasible alternatives under constraints; product-space design makes the alternatives and constraints visible before, during, or after optimization.
Failure modes¶
The most common failure mode is phantom coverage: every axis has been seen somewhere, so the team claims the product has been covered. Another failure mode is invalid cell erasure, where impossible or prohibited combinations are deleted without explanation. A third is combinatorial explosion, where the grid grows faster than the organization can test, govern, or communicate. A fourth is false independence, where the axes are conditional or path-dependent but are forced into a Cartesian product anyway.
Examples¶
In software testing, browser × operating system × locale × account tier × feature flag defines a test product space. In product configuration, size × material × color × voltage × region defines a possible SKU surface, later filtered to supported combinations. In policy design, eligibility class × income band × region × documentation state × renewal status reveals edge cases that a one-axis policy review would miss.
Non-examples¶
A flat list of tasks is not this archetype. A workflow state machine is not this archetype when path order matters more than independent choices. A clustering model is not this archetype because clusters are discovered from data rather than constructed by crossing declared axes. A brainstorming worksheet is not this archetype unless it includes product construction, feasibility, coverage, and change control.
Common Mechanisms¶
9 catalogued mechanisms: 8 documented across 5 implementation forms; 1 awaits an authored page and reviewed form classification.
The grouping reflects forms represented among the mechanisms currently documented for this archetype; an absent form is not necessarily an impossible implementation.
Analysis, Modeling & Optimization · 2 mechanisms
- Pairwise Covering Array — Reduces large products while preserving coverage of every pair of axis levels.
- Product Space Generator Script — Automatically generates cell tuples, keys, and counts from declared axes and levels.
Interface, Display & Cue · 1 mechanism
- Coverage Heatmap — Visualizes cell coverage, sampling density, risk, or implementation status across selected axes.
Monitoring, Sensing & Alerting · 1 mechanism
- Combinatorial Test Coverage Grid — Tracks which cells or cell classes have been tested and where blind spots remain.
Representation, Specification & Plan · 3 mechanisms
- Configuration Matrix — Lists supported and unsupported combinations of features, platforms, permissions, versions, or environments.
- Full Factorial Matrix — Enumerates all factor-level combinations for small experimental or testing spaces.
- Scenario Cube — Represents combinations of future drivers, contexts, or assumptions across multiple scenario axes.
Rule, Policy & Commitment · 1 mechanism
- Invalid Combination Rule Sheet — Records constraints that filter infeasible, illegal, unsafe, semantically invalid, or unsupported cells.
Not Yet Form-Classified · 1 mechanism
- Morphological Box — Uses rows or columns of dimensions and values to generate cross-axis option combinations.
Related Abstractions¶
Abstractions this archetype builds on — directly (a source ingredient) or as a related pattern. Links follow the typed catalog namespace.
Built directly on (6)
- Cartesian Product: All combinations of independent dimensions, one choice per axis.
- Constraint: Limits possibilities to guide outcomes.
- Degrees of Freedom: Independent parameters.
- Dimension: Degrees of freedom in a system.
- Factorial Design: Multiple variables tested together.
- Set and Membership: Groups and categorizes elements.
Also references 18 related abstractions
- Basis: A minimal independent generating set — the smallest collection from which every element of a space can be produced, with no member derivable from the others.
- Boundedness: Values remain within limits.
- Closure: Ensures operations remain within a set.
- Clustering: Partitioning a population into groups by within-group similarity in a chosen feature space without predefined labels, so the labels are an output rather than an input.
- Compatibility: The relational condition under which two or more entities can coexist or compose without breakage, interference, or contradiction.
- Composition: Arranges components into a cohesive whole.
- Curse Of Dimensionality: Volume, sparsity, and distance intuitions degrade so fast with added dimensions that low-dimensional methods break down qualitatively, not just quantitatively.
- Experimental Design: Structuring an investigation through deliberate intervention, controlled assignment, and measurement so that causation can be distinguished from mere correlation and confounding.
- Function (Mapping): Relates inputs to outputs.
- Interoperability: Systems function together.
Variants¶
Narrower or domain-specific specializations that share this archetype's core structure. Recognized variants are established; candidate variants are provisional.
Full Factorial Enumeration · mechanism family variant · recognized
Enumerates every factor-level combination in a bounded experimental, testing, or design space.
- Distinct from parent: A stricter variant focused on exhaustive factor-level enumeration.
- Use when: The product is small enough to enumerate fully; High assurance or causal interaction review requires every cell to be visible.
- Typical domains: experimental design, software testing, quality assurance
- Common mechanisms: full factorial matrix, product space generator script
Constrained Configuration Catalog · domain variant · recognized
Constructs the full configuration product and then publishes only valid, supported, or allowed combinations.
- Distinct from parent: A catalog-oriented variant focused on the boundary between possible and supported cells.
- Use when: Products, permissions, environments, or service bundles have many possible combinations; Unsupported or illegal combinations must be visible to designers but hidden or blocked for users.
- Typical domains: product configuration, permissions management, service design
- Common mechanisms: configuration matrix, invalid combination rule sheet
Scenario Cube Construction · domain variant · recognized
Crosses named uncertainty or context axes to produce a scenario surface for planning and stress testing.
- Distinct from parent: A planning-oriented variant focused on futures, assumptions, and stress cases.
- Use when: Future conditions or external contexts vary along multiple declared axes; Planners need representative scenarios drawn from an explicit larger product.
- Typical domains: strategic planning, risk analysis, resilience planning
- Common mechanisms: scenario cube, coverage heatmap
Near names: Cartesian Product Space Design, Product-Space Enumeration, Combination Grid Design, Configuration Space Cataloging, Scenario Cube Design, Full Factorial Grid.
Editorial Notes¶
Problem Classification¶
Classification: Correctness, Conformance & Formal Validity Failure → Coverage, Partition & Set Accounting
Problem kernel: independent dimensions are not crossed into a complete case space
Rationale: Examples and partial lists omit combinations implied by the product structure, leaving tests and policy cells uncovered.
Independent corroboration: The earliest necessary condition in the frozen evidence is: A design, test, scenario, policy, configuration, or analysis space is governed through examples, anecdotes, or partial lists rather than through the full combination structure implied by its independent dimensions. That is a coverage partition and set accounting problem because A declared possibility or membership space has gaps, overlaps, missing combinations, collisions, unreachable targets, or unreliable accounting of covered and uncovered regions.
Review outcome: Independent reviewer agreement; high confidence.