Module engine 

The two-loop session engine (the reference: The two loops).

• Patch loop (machine-paced, silent): fill a pool with vetted prior draws; once a posterior exists, refine — warm-start fugue-evo’s typed MH from the best pool members on the Boltzmann target π_β ∝ p_grammar · exp(β·E[u(x)]) and inject improved candidates. The refinement run is a short local MH walk from each seed (a dozen steps, final state kept), not a draw from π_β: it moves candidates uphill on that target, which is what the pool needs, but nothing here claims the pool is distributed as π_β.
• Taste loop (human-paced, persistent): feedback events append to the ObservationLog as raw φ; the posterior is re-fit from the log, standardizing at fit time.

Between them, acquisition: Engine::next_duel maximizes expected information about θ (BALD). See its docs for why the obvious alternative — dueling Thompson sampling — is the wrong objective for this product.

Locks (partial evolution): any set of trace addresses can be frozen during refinement. The MH kernel still proposes over all sites; a proposal that touches a locked address is rejected outside the kernel. Because the underlying kernel satisfies detailed balance on the full space, rejecting locked-coordinate moves yields a valid Metropolis-within-Gibbs sampler on the conditional posterior given the locked values — locking is exact, not a heuristic. That exactness depends on the rejection region being symmetric: Engine::violates_locks therefore checks births as well as deaths and edits. Wasted proposals are compensated by scaling step counts.

All UI modes are emitters into the same observation stream: the engine does not know which surface produced an event. Candidates carry stable ids — pool positions shift on eviction, ids never do.

Structs

BankEntry

One bank entry of a saved session (renders and features are re-derived on import — trees are the source of truth).

Candidate

A vetted pool member.

Contribution

One feature’s exact share of a candidate’s utility.

DuelChoice

A chosen duel, with the reasoning that produced it.

Engine

The session engine.

Explanation

Why the model scores one candidate the way it does.

ImplicitEvent

An implicit preference signal, logged but (for now) not modeled: promote events, hand-edit commits, per-patch play counts. Un-logged signal is gone forever; modeling can come later.

LineageEvent

One recorded evolution/edit step, for the lineage display.

Profile

A portable taste profile: the observation log plus the standardizer its φ vectors were standardized under. θ is only meaningful relative to its standardizer, so the two persist together.

SessionConfig

Engine configuration.

SessionState

A full saved session: everything needed to restore the app across a reload — the portable profile plus the bank and its history.

StyleShareRecord

What one posterior fit claimed for each style lens.

Enums

Acquisition

Which rule picks the next duel.

EditOutcome

What a hand edit’s commit reported about the edit against the original.

Origin

Where a candidate came from.

RefineKeep

Which state of a refinement walk becomes the injected child.

RenderPolicy

What the pool does with audition audio.

Functions

phi_names

The φ coordinate names, as owned strings (what the log records).

tilt_weights