Path B: Flow-First — Port Music Continuous Flow Architecture

Path B: Flow-First — Port Music Continuous Flow Architecture

## Thesis
Port `continuous_flow_generator.py` directly. Replace the 12x32 music grid with inscription state vectors. The velocity field learns how conversation states evolve, and distillation gives real-time 1-step prediction.

Architecture

# Adapted from continuous_flow_generator.py
State:
  - general branch: x_t ∈ R^16 (10 sigil logits + 5 behavior + opacity)
  - speech branch: x_t ∈ R^23 (10 sigil logits + 5 behavior + opacity + 7 tone)
Conditioning: c ∈ R^768 (conversation context from RAG++ or turn embeddings)
Time: t ∈ [0, 1] (interpolation between current and next state)

Velocity field: v_theta(x_t, t, c)
  - Input: concat(x_t, t_embed, c) = state_dim + 64 + 768
  - Architecture: 4 transformer blocks (256D, 4 heads)
  - Output: dx/dt ∈ R^state_dim

Training: Flow matching loss
  x_t = (1-t) * x_0 + t * x_1 + sigma * noise
  Loss = MSE(v_theta(x_t, t, c), x_1 - x_0)

Inference: Euler ODE
  x_1 = x_0 + v_theta(x_0, 0, c)  # 1-step after distillation

## Data
Same KARL transitions as Path A, but formatted as `(x_0, x_1, c)` triples where `x_0` and `x_1`
use the canonical 16D or 23D state contract.

## Strengths
- Generative: can sample multiple possible futures by varying noise
- Uncertainty quantification: multi-step ODE gives smoother predictions than 1-step
- Directly reuses proven architecture from music stack
- Distillation to 1-step is already implemented in `flow_map_distiller.py`

## Weaknesses
- Overkill for a 16D/23D state space (flow matching shines in higher-dimensional spaces)
- Needs more data than Path A (flow models are data-hungry)
- Training is GPU-bound, can't run on CPU
- The time axis semantics change: music flow goes noise→clean, conversation flow goes state→next_state

## Key Risk
The flow matching formulation assumes interpolation between source and target. In music, source=noise, target=clean pattern. In conversation, source=current state, target=next state. These are NOT the same. May need to reformulate as a conditional flow: "given state_t, what is the velocity toward state_t+1?" rather than "denoise from noise to state."