Configuration Matrix¶
Artifact — instantiates Cross-Axis Product Space Design
Lists supported and unsupported combinations of features, platforms, permissions, versions, or environments.
A Configuration Matrix is the published artifact that draws the line between the combinations an organization stands behind and everything else. Its defining idea is the supported envelope: rather than enumerating every mathematically possible cell, it declares a bounded region of combinations that are documented, warranted, and maintained, and it names each supported configuration so it can be referenced, sold, or promised. It collapses the sprawl of raw variation into a compact table of representative rows — "any 5.x release on a 64-bit kernel," not one row per patch level. It is a commitment document first and a combinatorial one second: the matrix is what a customer, an auditor, or a support engineer points to when asking "is this setup something you support?"
Example¶
An enterprise database vendor ships PostgreSQL-based software and must tell customers exactly what it will support in production. The axes are operating system (RHEL, Ubuntu LTS, Windows Server), CPU architecture (x86-64, ARM64), and major product version (12, 13, 14). The raw product is small, but the vendor does not treat all of it as promised ground. The configuration matrix declares the envelope: RHEL and Ubuntu on x86-64 across all three versions are Supported; ARM64 is Supported only on version 14; Windows Server is Community / best-effort, explicitly not warranted for production.
Each supported combination gets a stable identity — a compatibility ID the support desk can cite on a ticket — and the table collapses noise into classes: "RHEL 8 and 9" is one row, not two, because the software behaves identically across them. The result is a one-page commitment a salesperson can hand to a prospect and an engineer can enforce at install time. When a customer running ARM64 on version 13 files a bug, the matrix settles the conversation in seconds: that cell is outside the envelope, and the reason is on the page.
How it works¶
- Declare the envelope, don't enumerate the universe. The matrix states which region of the product is inside the support boundary and which is deliberately outside — supported, deprecated, best-effort, unsupported — rather than listing every possible cell.
- Give each supported cell an identity. A stable key (compatibility ID, SKU, config code) lets a supported combination be cited, ticketed, and versioned without ambiguity.
- Collapse to representative rows. Configurations that behave identically are merged into one class, so the table stays legible and a whole range can be supported by a single documented row.
- Keep the line visible. Unsupported and deprecated regions stay on the artifact — greyed, footnoted — so the boundary is a stated choice, not an omission.
Tuning parameters¶
- Support tiers — how many gradations the table carries (a binary supported/unsupported, or supported / deprecated / best-effort / unsupported). More tiers communicate nuance but complicate the promise.
- Collapse aggressiveness — how wide a range each representative row spans. Coarse rows keep the matrix small but risk warranting a config that quietly differs; fine rows are precise but sprawl.
- Identity scheme — whether cells are keyed by version tuple, marketing SKU, or internal config hash; the choice fixes how downstream systems reference the envelope.
- Boundary rationale depth — how much why travels with each unsupported region, from a bare "not supported" to a linked reason. More rationale ages better; less is cheaper to publish.
- Revision cadence — how often the envelope is re-cut as versions ship and platforms retire; slow cadence lets the promise drift from reality.
When it helps, and when it misleads¶
Its strength is that it converts an implicit, negotiated web of "well, it depends" into a single legible commitment: sales knows what to promise, support knows what to defend, and customers know what they are buying. By collapsing equivalent configurations it keeps that promise small enough to maintain, and by keeping the unsupported region visible it makes scope a decision rather than an accident.
Its failure mode is the widening gap between the promised envelope and the tested reality — a matrix that keeps adding supported cells without retiring old ones drifts into dependency hell[n1], warranting combinations no one has actually exercised in months. The classic misuse is reading the matrix as evidence of testing: a green "Supported" cell is a commitment, not a passing test run, and the two diverge silently unless something ties them together. The guarding discipline is to bound the envelope to what can genuinely be maintained, retire cells as aggressively as you add them, and keep an explicit link from each supported class to the evidence that it still works.
How it implements the components¶
product_boundary_statement— it draws the supported/unsupported line: the artifact is the statement of which region of the product the organization commits to.cell_identity_rule— each supported configuration carries a stable key so it can be cited on a ticket, invoice, or install check.equivalence_class_collapse_rule— identically-behaving configurations are merged into one representative row, keeping the promised envelope compact.
It does not enumerate every combination of the product (combination_enumerator, level_set_per_axis — that is Full Factorial Matrix, its nearest twin, which keeps all cells present whether supported or not), nor does it hold the exclusion rules and their reasons (feasibility_filter, invalid_combination_exception_register — that is Invalid Combination Rule Sheet). The configuration matrix shows the bounded result; those siblings enumerate and justify.
Related¶
- Instantiates: Cross-Axis Product Space Design — it is the artifact that publishes the governed product as a supported envelope.
- Consumes: Invalid Combination Rule Sheet supplies the exclusion reasons that decide which cells fall outside the boundary.
- Sibling mechanisms: Combinatorial Test Coverage Grid · Full Factorial Matrix · Invalid Combination Rule Sheet · Pairwise Covering Array · Product Space Generator Script · Scenario Cube · Coverage Heatmap
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: Lists supported and unsupported combinations of features, platforms, permissions, versions, or environments, making its operative form a non-executable information artifact that externalizes static or prospective structure.
Independent corroboration: The frozen evidence defines Configuration Matrix as 'Lists supported and unsupported combinations of features, platforms, permissions, versions, or environments', so its operative form is Representation, Specification & Plan.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Software release engineering established supported-combination matrices for versions, platforms, features, permissions, and environments.
Related originating lineages:
- Engineering & Design — Product configuration management independently tracks validated combinations and incompatibilities.
Review resolution: Both reviewers agree on computer_science as primary. Reading the source mechanism confirms that its defining operation belongs to that lineage; the final record retains engineering_design only where it materially formed the mechanism and keeps present-day application breadth separate from provenance.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] Dependency hell — the well-known state in which a system's supported combinations of versions and platforms grow so tangled and interdependent that no configuration can be changed or promised with confidence. A configuration matrix is a defense against it only if the envelope is actively pruned; left to accrete, the matrix becomes a catalogue of promises no longer backed by testing. ↩