svelte-kit-vice/docs/theming/channels.md

---
title: The channels as one system — synthesis
type: notes
audience: human + agent
authority: E3 — the capstone tying the per-channel RFCs to the book's thesis
status: current
source: migrated from src/uix/eidos/CHANNELS_SYNTHESIS.md (2026-07-02, docs-book F7.3)
---

# The channels as one system — synthesis ("Diseñando lo que ocurre")

> The **capstone** of the per-channel RFCs. The thesis of the book *Diseñando
> lo que ocurre*: an interaction **is not** color, or movement, or sound — it
> is **one perceptual occurrence spread across N channels**, under the
> **two-moment** model. This ties together [`rfc-color-engine`](../rfcs/rfc-color-engine.md) ·
> [`rfc-typography`](../rfcs/rfc-typography.md) · [`rfc-depth`](../rfcs/rfc-depth.md) ·
> [`rfc-shape`](../rfcs/rfc-shape.md) ·
> [`rfc-structure`](../rfcs/rfc-structure.md). Live demo: **`/temas/orquesta`** (the mixer).

## 1. Two moments, joined by a token: sema emits, eidos reads

An occurrence flows through **two moments**, connected by the **token**:

- **Sema's moment (emission)** — sema evaluates the occurrence and **emits**
  it. Sound + haptics it **executes right there** (runtime channels); for the
  visual, it **stamps it as tokens** `data-event-*` (family · intent ·
  phase). Sema **knows no DOM/CSS**.
- **Eidos's moment (materialization)** — eidos **reads** those tokens
  (+ `data-state`) and **materializes** them in CSS (the visual channel). It
  is the **sole visual owner**.

The **token is the contract**: sema writes, eidos reads — which is why the
layers decouple (sema DOM-agnostic, eidos free of semantic logic).

Over that producer → consumer axis runs the **temporal** axis (motion F1) —
*which* token:

| Token | Nature | Who writes it | Eidos reads it as |
|---|---|---|---|
| `data-state` | persistent — what the element **is** | soma / morfo | `presets` |
| `data-event-*` | transient — what **occurs** (during the `hold`) | sema (emits) | `signatures` |

`sequence` (`pre` / `coincident` / `post`) orders the two.

## 2. Expression channels (the book) vs sema channels (runtime)

The book has **8 expression channels** (perceptual dimensions). The framework
implements them with sema's **runtime channels**, which are **4** — and here
is the key that avoids the classic confusion:

| Sema channel (runtime) | Covers (the book's expression) | Who materializes it |
|---|---|---|
| **visual** (sema projects `data-event-*`) | movement · presence · depth · shape · color | **eidos** — CSS over `data-event-*` + `data-state` |
| **sound** | sound | sema (`chans/sound`) |
| **haptic** | haptics | sema (`chans/haptic`) |
| **announce** | — (accessible substitute, not a book channel) | sema (`chans/announce`) |

`announce` joined on 2026-07-04 as a built-in opt-in channel: it is the
accessible counterpart the book demands when a modality is unavailable
(`BK-SIGNAL-A11Y`), not a ninth perceptual dimension. `visual`, `sound` and
`haptic` are the three that express; `announce` is the one that substitutes.

> **Don't get confused**: **motion · depth · shape · color are NOT "eidos
> channels"** — they are sema's **`visual` channel**, which sema projects and
> **eidos materializes**. Eidos is the visual channel's *materializer*, not
> the owner of channels of its own. The eidos RFCs (`COLOR/DEPTH/SHAPE_ENGINE`)
> describe *how* eidos materializes each visual facet — not independent
> channels.

Plus **space** ([`rfc-structure.md`](../rfcs/rfc-structure.md)) — **structural,
not expressive**: it doesn't "occur", it is the stage (state-only).

## 3. The layer chain (each with its role)

An occurrence **crosses the layers** — it is not "all sema", and eidos is not
a shim:

1. **morfo** — **declares** the event and its semantics (family · intent ·
   verb). The contract / DNA; pure TypeScript, no runtime.
2. **soma** — **fires** it (`runtime.trigger`): the sequence `prewrite →
   sema.emit → handler →` state attrs. It writes `data-state` (the
   state-moment).
3. **sema** — **emits** it: dispatches the signal to its channels —
   **executes** `sound` + `haptic`; **projects** the visual channel by
   stamping `data-event-*`. It knows no DOM/CSS.
4. **eidos** — **materializes** it: reads `data-state` (`presets`) +
   `data-event-*` (`signatures`) and renders them with its **token engines**
   (color · motion · depth · shape · space — the RFCs). It is the **complete
   visual system** and the sole owner of the visual.

> Eidos does **not "make sema visible"**: sema contributes the **what**
> (family / semantic intent), eidos contributes the **how** (the visual
> vocabulary and its materialization). Co-layers, not one subordinate.

(The full canonical narrative lives in `CLAUDE.md` → "Sema: open channel
registry".)

## 4. The composition — one event, N channels

The **signature** (`BUILTIN_SIGNATURES` + `BUILTIN_KEYFRAMES`) is
**cross-modal**: a single keyframe carries several modalities. A real example
(`press-squeeze`, family `contact`):

```
contact · press  →  scale 0.96 (motion)
                 +  box-shadow → flat (depth recede)
                 +  --shape-smoothing 2→3 (shape: the corner firms up)
                 +  tick (sema sound)
                 +  vibration (sema haptic)
```

One `engine.emit(...)` stamps `data-event-*` (the **visual** channel reacts —
eidos materializes it as color/motion/depth/shape) **and** fires sound +
haptic — from the **same** event. There are no systems coordinating by hand;
there is one occurrence expressing itself through sema's channels.

## 5. Runtime builders — the sextet (an open cage)

Every axis retunable at runtime, same pattern (seed → managed block), opt-in
over the authored scale:

`applyColorScheme` · `applyTypeScale` · `applyDepth` · `applyShape` ·
`applySpacing` · `applyGradients`

And the **capstone composing them**: **`applyTheme(seed)`** — a single seed
(`{ color?, type?, depth?, shape?, space?, gradient? }`) composes the six
axes in **one managed write** (vs six loose `apply*`), **atomically**: the
axes you pass are applied, the ones you omit revert to the authored
foundation. `clearTheme()` reverts everything. For surgical per-axis tweaks,
the individual `apply*` remain. No reference system gathers the six
perceptual axes under a single runtime theme builder.

## 5b. How each channel is AUTHORED — and the asymmetry that is left

The sextet above retunes the **visual** channel at runtime. Sound and haptic
have no equivalent, and after the 2026-08-06 rework that gap is worth naming
precisely, because the reason it existed is gone.

| Channel | Where a component AUTHORS it | Where a THEME retunes it |
| --- | --- | --- |
| visual — color · motion · depth · shape · space | eidos recipes, reacting in CSS to `data-event-*` | `applyTheme(seed)` + the six `apply*` (runtime, atomic) |
| **sound** | **names one entry of `SOUNDS`** (`src/uix/sema/sound-names.ts`) — a word, never a parameter | **nothing** — see below |
| **haptic** | a categorical `kind` (`tick` / `tap` / `pulse` / …) | **nothing** |

**What the sound rework did NOT change.** Nothing in eidos. The visual channel
is projected by stamping `data-event-*`, and that path was untouched: no
recipe, no token, no selector moved. Eidos does not know sound exists and did
not need to. The rework changed WHERE the sound is authored (a catalogue
instead of 71 pack files) and WHEN it is applied (before the intent instead of
after it) — both entirely inside sema.

**What it did change, and it is the useful part.** Until then, "theming the
sound" was not a coherent idea: 214 cascade rules authored 33 hand-written
signatures across 71 files, and there was no object to retune. Today there
is exactly one — sixteen names in one const — so a `sound` axis in `ThemeSeed`
would be the same shape as the other six, and a brand could ship its own
`soft` the way it ships its own colour ramp.

**The measured surface today, for anyone who tries.** Three doors, none of
which reaches the catalogue:

- `overrides.runtime` — path-based mutations of `SEMA_MAP`, so it reaches
  family bases and intent deltas but **not** the catalogue, which is a module
  const outside the map. It also swallows path typos in silence (audit S-09).
- `overrides.cascade` — app-level rules; the type stays open on purpose so an
  app CAN author a raw signature. But it is per-selector, not a theme: you
  restyle one occurrence, not the word `soft` everywhere.
- `masterGain` via `createActiveUix` — **discarded in silence** (audit S-05 /
  S-32): the engine filters the key before the channel is built.

So: **a product can silence sound, and can override one occurrence, but cannot
re-voice the system.** That is a real gap, it is now cheap to close, and it is
not closed — recorded here rather than left as folklore.

## 6. Position vs the references

No reference system gathers the channels under **one semantic model**.
Material has shape morph + motion (ad-hoc, without integrated
sound/haptics); Apple, continuity + materials (platform-bound); everyone,
color. **UIX gathers them** — the visual channel (sema → eidos) + sound +
haptic (sema) — over the two-moment model, fired from one event, with
runtime builders and an open registry. That is the framework, not the sum of
its parts.

## 7. Demo

`/temas/orquesta` — the mixer: press a control and mute each facet to hear
its part. The **visual channel's** 4 facets materialize with eidos tokens
(toggleable so each can be muted one by one); **sound + haptic** are fired by
the real sema engine (`EngineSemantic.emit`, filtered channels). One event,
sema's channels.