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.

Version

v1 · 2026-08-24 · History

Solution archetype #

1047

Problem family

Correctness, Conformance & Formal Validity Failure

Problem subfamily

Mapping, Rewrite & Structure Preservation

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.

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 model, rule, translation, allocation, interface, representation, or transformation pipeline is expected to preserve structure across changes of frame, label, orientation, scale, ordering, or representation, but the input and output spaces are not linked by an explicit equivariance contract. As a result, the system may treat equivalent transformed cases inconsistently, erase meaningful co-variation, encode arbitrary ordering or naming artifacts, or return outputs that cannot be compared across transformed contexts.

Applicability expression8 distinct conditions

Meaningful input transformationandCorresponding output transformationandCross-frame rule reuseandRepresentation-independent resultsandPreserved structural relationandTransformation-specific failuresandConvention-dependent outcomesandInvariant-variant confusion

Algebraic1∧2∧3∧4∧5∧6∧7∧8

groundedpartly groundedopen

8 conditions, all required.

8Required in every casenumbered 1–8

These hold no matter which pattern applies.

1

Meaningful input transformation · grounded

Inputs can be transformed by a meaningful operation such as rotation, translation, relabeling, permutation, coordinate-frame shift, schema rewrite, or role-preserving substitution. more

primeEquivariance— A map whose output transforms in step with transformations of its input.

and — also required

2

Corresponding output transformation · grounded

The output is expected to transform in a known corresponding way rather than stay identical or change arbitrarily. more

primeEquivariance— A map whose output transforms in step with transformations of its input.

and — also required

3

Cross-frame rule reuse · grounded

A model or rule is reused across reference frames, data orderings, label systems, geometric configurations, or equivalent cases. more

primeEquivariance— A map whose output transforms in step with transformations of its input.

and — also required

4

Representation-independent results · grounded

Users need confidence that arbitrary representation choices do not determine substantive results. more

primeEquivariance— A map whose output transforms in step with transformations of its input.

and — also required

5

Preserved structural relation · grounded

A downstream process depends on the output retaining the same structural relationship to the transformed input. more

primeEquivariance— A map whose output transforms in step with transformations of its input.

and — also required

6

Transformation-specific failures · grounded

Testing shows good average performance but unexplained failures under simple transformations that should be harmless or predictable. more

primeEquivariance— A map whose output transforms in step with transformations of its input.

and — also required

7

Convention-dependent outcomes · open

A governance or fairness problem appears because relabeling, row ordering, namespace choice, or coordinate convention changes outcomes. more

and — also required

8

Invariant-variant confusion · open

A domain requires both invariant and variant quantities, and the system currently confuses which is which. more

Coverage

6 of 8 conditions grounded · 2 open.

Read the methodology · Download the trigger-logic data

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

8 documented mechanisms across 4 implementation forms.

The grouping reflects forms represented among the mechanisms currently documented for this archetype; an absent form is not necessarily an impossible implementation.

Assessment, Review & Assurance · 2 mechanisms

• Commutative Diagram Review — Draws the two composition paths — transform-then-map and map-then-transform — as a diagram whose closure is the equivariance claim, surfaced before a line of code is written.
• Coordinate-Frame Consistency Check — Verifies that when the reference frame moves, geometric outputs transform by the same rigid motion — so a pose or velocity means the same thing in every frame.

Experiment, Test & Rehearsal · 4 mechanisms

• Data-Augmentation Equivariance Probe — Feeds randomly transformed inputs sampled across the valid transformation range and measures the statistical distribution of how far outputs drift from the correspondingly transformed baseline.
• Permutation Equivariance Audit — Checks that reordering or relabeling the input elements permutes the per-element outputs correspondingly while leaving genuinely order-independent results untouched.
• Schema and Label Relabeling Harness — Renames schemas, columns, and identifiers on the input and confirms every downstream output, log, and dashboard is rewritten by the same relabeling and otherwise unchanged.
• Transformation-Pair Test Suite — Turns the commutation claim into repeatable, executable tests that compare the output of a transformed input against the correspondingly transformed baseline output, case by case.

Record, Log & Register · 1 mechanism

• Symmetry Exception Register — Records the transformations where symmetry should deliberately break, with the boundary that triggers the exception, the reason, and the authority that approved it.

Representation, Specification & Plan · 1 mechanism

• Equivariance Tolerance Matrix — Tabulates, per transformation, the required exactness class and numeric tolerance so each symmetry gets a declared standard rather than an implicit one.

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 (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.

Editorial Notes

Problem Classification

Classification: Correctness, Conformance & Formal Validity Failure → Mapping, Rewrite & Structure Preservation

Problem kernel: transformations lack an equivariance contract across frames

Rationale: Earliest causal condition: A model, rule, translation, allocation, interface, representation, or transformation pipeline is expected to preserve structure across changes of frame, label, orientation, scale, ordering, or representation, but the input and output spaces are not linked by an explicit equivariance contract. As a result, the system may treat equivalent transformed cases inconsistently, erase meaningful co-variation, encode arbitrary

Independent corroboration: The earliest necessary condition in the frozen evidence is: A model, rule, translation, allocation, interface, representation, or transformation pipeline is expected to preserve structure across changes of frame, label, orientation, scale, ordering, or representation, but the input and output spaces are not linked by an explicit equivariance contract. That is a mapping rewrite and structure preservation problem because Translation, replacement, inversion, lowering, or transformation changes meaning, reachability, connectivity, correspondence, or invariants that were required to survive.

Review outcome: Independent reviewer agreement; high confidence.