OmniMino’s Logic layer operates through combinatorial growth. The process begins when profiles define grid cells (bays); polyomino coordination then specifies how these cells can combine into module forms. The result is a generative system that replaces “pre-drawn and frozen plans” with fixed rules and outcomes open to countless possibilities.
In OmniMino, the grid is not treated as an area matrix of “painted squares”; it is understood as a load-bearing system built around bays (grid cells) defined by profiles. The fundamental unit is not a square area, but a bay with defined dimensions and reference points. Polyomino coordination enables bays to combine through rule-based combinations and transform into different module and spatial configurations—this is why the system grows not additively, but combinatorially.
Squares stay constant; forms remain variable. Polyomino combinations generate module forms.
Polyomino coordination treats grid cells (bays) not as boxes added side by side at random, but as a legible structure woven through defined neighborhood and connection rules. Which cell connects to which, in which direction, and in what sequence is mathematically specified. The outcome is not the sum of individual parts; it is a rule-based spatial composition. This is why design in OmniMino is not about replicating a fixed form, but about generating countless distinct configurations from the same bay set and the same rules.
Rules stay fixed; forms multiply. Polyomino coordination turns bays into module forms.
Growth in OmniMino does not come from continuously adding new parts to the inventory; it comes from expanding the combinatorial space of the parts you already have. Just as Tetris generates countless placement scenarios from a limited “piece alphabet,” OmniMino’s standard bay set and fixed coordination rules multiply possibilities not linearly (1+1=2), but combinatorially. This mathematical richness is achieved not through more product variants, but through better-defined rules.
Module Alphabet: The shapes you see (T, L, U, O) are not a fixed product catalog; they are outcomes derived from bays through neighborhood/connection rules.
OmniMino does not offer a limited, “pick-and-build” module catalog; it offers an open-ended system with defined rules. Design in OmniMino is therefore not about choosing from pre-made forms, but about generating new configurations on the same bay set and the same coordination logic—and undoing them when needed. The system does not close after each build; it expands, evolves, and is reinterpreted.
Open-Ended: Instead of “finishing” a single form, OmniMino continuously expands its configuration space.
In OmniMino, modularity is governed by Relational Multi-Valent Modularity™ (RMVM): modules don’t carry meaning on their own; meaning emerges through neighborhood, adjacency, and connection relationships. The mechanical counterpart of RMVM™ is unpacked in the System Interface section through the MAIN Interface™.
A module alone is just a “part”; meaning emerges from neighborhoods.
OmniMino’s strength is that it does not require a new system as the scale grows. The same bay set and the same coordination rules that work for a small configuration (e.g., a cabin) also work for a much larger one (e.g., a campus). The only thing that changes is the number of relationships and the expanding configuration space. This is why OmniMino is not a single product class, but a generalizable system logic that can be carried consistently across application scales.
One Logic, Many Scales: The scale changes; the rule set doesn’t.
You’ve seen the system logic. Now see how it becomes a buildable structural order—frames, bays, and structural hierarchy.
Next: Structure →
