Symmetry Commuting Transformation Design¶

Design a mapping so meaningful transformations of the input are mirrored by corresponding transformations of the output rather than erased, amplified, or changed inconsistently.

Essence¶

Design a mapping so meaningful transformations of the input are mirrored by corresponding transformations of the output rather than erased, amplified, or changed inconsistently.

This archetype is useful whenever a system should not merely be stable under a transformation, but should move in the right corresponding way. The core question is: if we transform the input first, then apply the map, do we get the same result as applying the map first and transforming the output afterward?

Compression statement¶

Symmetry-Commuting Transformation Design is the solution pattern for systems whose mapping from input to output should respect a transformation structure. It names the allowed input transformations, defines the corresponding output transformations, aligns representations on both sides, distinguishes invariant quantities from co-varying quantities, and validates the commutation relation so transforming first and mapping second agrees with mapping first and transforming second.

Canonical formula: for allowed transformation g: F(g_input(x)) ≈ g_output(F(x)); define g_input, g_output, tolerance, and exception rule before relying on F.

Structural pattern¶

The pattern has three anchors. First, define the transformation that can be applied to inputs. Second, define the matching transformation that should apply to outputs. Third, validate the commutation contract between the two paths. Without all three, a system can accidentally depend on arbitrary representation choices such as row order, coordinate frame, labels, schema names, or orientation.

The canonical form is:

F(g_input(x)) ≈ g_output(F(x))

The approximation mark is intentional. Some domains require exact equality; others require a tolerance, statistical confidence interval, or procedural audit standard.

Key components¶

Component	Description
Transformation Scope ↗	The transformation scope names the operations the mapping must respect. These may be formal transformations such as rotation or permutation, operational changes such as schema renaming, or governance-relevant relabelings such as anonymous applicant identifiers. The scope should also say what is out of bounds.
Input-Output Action Pair ↗	Equivariance requires a pair. It is not enough to say that the input is rotated, reordered, or relabeled; the output must have a corresponding action. If the output space lacks that action, the equivariance claim is not yet meaningful.
Commutation Contract ↗	The commutation contract turns the intuition into a testable requirement. It states how close the two paths must be, what evidence will count, and who can approve exceptions.
Invariant-Variant Split ↗	A common failure is confusing equivariance with invariance. Some output features should remain fixed under a transformation; others should transform. The invariant-variant split identifies which is which.
Symmetry-Break Exception Rule ↗	Not every apparent symmetry should be preserved. A transformation may reveal a meaningful difference, a legal constraint, a safety boundary, or a change in authority. Those cases should be handled as explicit exceptions rather than silent failures.

Common mechanisms¶

A commutative diagram review is a lightweight way to expose the claim. A transformation-pair test suite turns the claim into repeatable evidence. Coordinate-frame checks, permutation audits, data-augmentation probes, and schema relabeling harnesses instantiate the pattern in more specific domains. Where exceptions matter, a symmetry exception register preserves the reasons for breaking the default equivariance relation.

Parameter dimensions¶

Important dimensions include the transformation family, output action, exactness tolerance, representation alignment, downstream consumer semantics, and exception authority. The archetype becomes more demanding when transformations are continuous, high-dimensional, legally sensitive, safety-critical, or only approximately measurable.

Neighbor distinctions¶

This archetype is distinct from scale-invariant design because the correct output often changes. It is distinct from symmetry-based fairness because it is not only about treating equivalent cases alike; it is about preserving a transformation relation between input and output spaces. It is distinct from symmetry breaking because it preserves the relation by default and only breaks it under an explicit exception. It is distinct from Hamiltonian canonical transformation work because that accepted archetype is a specialized physics/dynamics pattern, while this draft covers the cross-domain map-commutation pattern.

Examples¶

In computer vision, a rotated image should yield a rotated segmentation mask.
In robotics, a pose or force output should transform consistently when the reference frame changes.
In graph modeling, relabeling nodes should relabel node-level outputs rather than changing the substance of the result.
In governance, anonymous ID changes should not alter substantive allocation except through corresponding relabeling.
In data engineering, schema rewrites should produce correspondingly rewritten outputs and logs.

Non-examples¶

A raw equality check under a transformation is not equivariance when the output should move. A policy that intentionally treats transformed cases differently because the transformation changes legal or ethical relevance is an exception, not a failure of the archetype. A domain-specific canonical transformation in Hamiltonian mechanics should usually remain under its accepted specialized archetype unless the general input-output transformation contract is the actual object of design.

Quality note¶

The draft is merge-sensitive with invariance, symmetry, and canonical-transformation neighbors, but the disposition check found no accepted archetype that directly covers equivariance as a general solution pattern. The target prime is included in identity.source_primes, and no uncontrolled proposed primes are introduced.

Common Mechanisms¶

Commutative Diagram Review
Coordinate-Frame Consistency Check
Data-Augmentation Equivariance Probe
Equivariance Tolerance Matrix
Permutation Equivariance Audit
Schema and Label Relabeling Harness
Symmetry Exception Register
Transformation-Pair Test Suite

Abstractions this archetype builds on — directly (a source ingredient) or as a related pattern. Links follow the typed catalog namespace.

Built directly on (5)

Equivariance: A map whose output transforms in step with transformations of its input.
Function (Mapping): Relates inputs to outputs.
Invariance: Properties unchanged under transformation.
Symmetry: Invariance under transformation.
Transformation: A rule-governed mapping that restructures an input into a different output, holding certain invariants fixed while altering others.

Also references 17 related abstractions

Asymmetry: Directed imbalance in a relation whose two sides are not interchangeable under swap.
Closure: Ensures operations remain within a set.
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.
Correlation: Systematic co-variation between variables, distinct from causation.
Correspondence Principle: New theories match old limits.
Data Integrity: Accuracy and consistency preserved.
Equivalence Relation: Groups elements into equivalence classes.
Form and Content: The relationship between a work's structure and its substance.
Frame of Reference: Observational perspective.

▸ Show 7 more

Variants¶

Narrower or domain-specific specializations that share this archetype's core structure. Recognized variants are established; candidate variants are provisional.

Coordinate-Frame Equivariance · domain variant · recognized

A mapping preserves the relationship between physical or geometric inputs and outputs when the reference frame changes.

Distinct from parent: It is a geometric or physical subtype of the broader transformation-consistent mapping pattern.
Use when: Outputs such as vectors, positions, forces, orientations, or spatial fields must transform correctly under a coordinate change; A model, simulation, sensor pipeline, or control rule is used across multiple frames of reference.
Typical domains: physics, robotics automation, geospatial analysis, computer vision
Common mechanisms: coordinate frame consistency check, commutative diagram review

Permutation-Equivariant Allocation · governance variant · candidate

An allocation, ranking, or assignment procedure changes only by the corresponding relabeling when equivalent actors, items, or options are relabeled.

Distinct from parent: It focuses on relabeling and permutation rather than all possible transformations.
Use when: The system should not depend on arbitrary names, row ordering, namespace order, or data ingestion order; Fairness or procedural consistency requires relabeled equivalent cases to produce relabeled equivalent outputs.
Typical domains: software computing, law governance, operations research, public administration policy
Common mechanisms: permutation equivariance audit, schema label relabeling harness

Learned-Model Equivariance · implementation variant · recognized

A learned or statistical model is designed or tested so transformed inputs yield correspondingly transformed outputs.

Distinct from parent: It is a machine-learning and statistical-modeling implementation context, not the general archetype itself.
Use when: A model is expected to generalize across rotations, translations, relabelings, augmentations, or coordinate changes; Data augmentation should produce structured output change rather than merely more training examples.
Typical domains: machine learning, computer vision, scientific modeling
Common mechanisms: data augmentation equivariance probe, transformation pair test suite

Near names: Covariance Under a Group, Structure-Preserving Transformation, Commuting with Symmetry, Transformation-Consistent Mapping, Equivariant Mapping Design.