Composition Table¶

Lookup table — instantiates Composable Relation Modeling

Tabulates every valid composite of a small set of arrows in a grid, making composition, identity, and closure readable at a glance.

Version: v1 · 2026-08-24 · History
Mechanism #: 1670
Type: Lookup Table
Form family: Representation, Specification & Plan
Solution family: Representation & Modeling
Problem family: Representation, Classification & Model Misfit
Problem subfamily: Relation, Interaction & Multicausal Structure
Origin domain: Mathematics
Instantiates: Composable Relation Modeling

A Composition Table is a grid whose cell at row f, column g names the composite g ∘ f — the single arrow you get by doing f then g. Its defining move is exhaustive enumeration: rather than reasoning about composition case by case, it lists every composable pair and the arrow each pair collapses to, so that composition becomes a lookup instead of a derivation. The table only admits a pair into a cell when the types line up (the target of the first arrow equals the source of the second); a blank cell is a genuine claim that no composite exists. Read down the identity row or column and you see which arrow leaves everything unchanged; scan the body and you see at a glance whether the set is closed — whether composing any two members ever escapes the set. The table asserts no route-equalities and proves no laws; it is a static registry of "what do these two make."

Example¶

A geometry class is studying the symmetries of a square: the eight rigid motions that map the square onto itself — the identity e, rotations by 90°, 180°, 270° (r, r², r³), and four reflections (h, v, d, d'). Students keep getting confused about what happens when you "flip then turn." The teacher builds a Composition Table: an 8×8 grid, rows and columns labeled by the eight motions, each cell filled with the single motion equivalent to doing the row's motion then the column's.

The typing rule here is trivial but real — every motion starts and ends at "the square," so every pair composes; there are no blank cells, which is itself the readable fact that this set is closed. The identity baseline is the e row and column, which reproduce whatever they meet, so students can verify at a glance that e truly does nothing. Filling the grid, a student discovers that reflection-then-reflection always lands on a rotation (h then v gives r²), never on another reflection — a pattern invisible in prose but obvious once the 64 cells are laid out. The finished table is the object the class then reasons from: every later question about these motions is answered by pointing at a cell.

How it works¶

List the arrows on both axes. Rows are the "first" arrow, columns the "second"; the cell holds their composite. Fix and state the convention (first-then-second) once, because the opposite convention transposes the table.
Admit a pair only if the types match. Fill cell (f, g) only when target(f) = source(g). Where they do not, the cell stays blank — a claim that the composite is undefined, not merely unknown.
Name each composite as an existing arrow. The point of the table is that composites collapse back onto members of the set; if a cell needs a name not already on the axes, the set is not closed and the table has just discovered a missing arrow.
Include the identity row/column. The identity arrow's row and column must reproduce their partner exactly; if they do not, either the identity or an arrow is mislabeled.

Tuning parameters¶

Composition convention — first-then-second vs. the reverse (function-composition order). Harmless if fixed and stated; a silent switch transposes every reading.
Closure handling — what to do when a composite has no name yet: leave blank, add the new arrow, or flag it. Adding arrows grows the table toward closure; flagging keeps it honest about gaps.
Table size / grain — how many arrows go on the axes. A small set is fully enumerable and instantly readable; past a few dozen, the grid stops fitting a page and a rule-based description beats a table.
Cell content — the composite's name only, or annotated with its type or a note. Richer cells document more but clutter the scan for closure.

When it helps, and when it misleads¶

Its strength is that it makes composition concrete and total: closure, identity behavior, and the presence or absence of each composite are all visible in one artifact, and a blank cell is an explicit statement rather than an oversight. For a small arrow set it is the most direct realization of the composition rule the archetype needs.^[n1]

Its failure mode is scale and false closure. The table's size grows with the square of the arrow count, so it collapses into unreadability well before large models; worse, a table filled in by wishful thinking can look closed while hiding a pair whose real composite escapes the set. The classic misuse is trusting a hand-filled grid without checking that each named composite genuinely equals the row-then-column arrow — an unverified table launders assumptions into apparent fact. The guarding discipline is to keep the arrow set small enough to enumerate honestly, to treat every blank as a checked claim, and to hand the verification of the laws the table exhibits to a dedicated test suite rather than eyeballing the grid.

How it implements the components¶

composition_rule — its core: each cell states the single arrow that a given ordered pair composes to.
source_target_typing_rule — the admission rule for cells; a pair is tabulated only when the first arrow's target equals the second's source, and blanks record type-incompatibility.
identity_arrow_baseline — the identity row and column, which must reproduce their partner and thereby exhibit the no-change arrow.

It does not prove that composition is associative or that the identity law holds for all cases (associativity_invariant — that is Identity and Associativity Test Suite), and it makes no claim that two different routes are equal (path_equivalence_claim — that is Commutative Path-Equivalence Diagram); the table only records single-step composites.

Instantiates: Composable Relation Modeling — the Composition Table is the archetype's registry of composites.
Consumes: Source/Target Type Check supplies the typing that decides which cells are admissible; Object–Arrow Diagram supplies the arrows on the axes.
Sibling mechanisms: Object–Arrow Diagram · Commutative Path-Equivalence Diagram · Identity and Associativity Test Suite · Source/Target Type Check · Interface-Contract Category Map · Functorial Transfer Probe · Structure-Preservation Checklist · Categorical Refactoring Workflow

Editorial Notes¶

Form Classification¶

Form family: Representation, Specification & Plan

Rationale: Tabulates every valid composite of a small set of arrows in a grid, making composition, identity, and closure readable at a glance, making its operative form a non-executable information artifact that externalizes static or prospective structure.

Independent corroboration: The frozen evidence defines Composition Table as 'Tabulates every valid composite of a small set of arrows in a grid, making composition, identity, and closure readable at a glance', so its operative form is Representation, Specification & Plan.

Review outcome: Independent reviewer agreement; high confidence.

Origin Attribution¶

Primary origin: Mathematics

Origin pattern: Single lineage

Present-day reach: Specialized

Rationale: Abstract algebra cohered Cayley-style tables that exhaustively enumerate binary composition, identity, closure, and type-incompatible pairs.