Split out of the generative-process instantiation work (feat/generators-instantiation,
docs/design/generators_instantiation.md §9 Q1). This is the item that gates the deprecation
timeline, so it wants a decision before the rest of the migration proceeds.
The problem
Full deprecation of simplexity/generative_processes is gated on
generators reaching feature parity. For most of the gap that
framing works: log-space operations, framing-token augmentation and the framework bridges are all
plausible upstream additions.
mixed_state_presentation.py (576 lines) is the exception. It provides MixedStateTree,
MixedStateTreeGenerator and myopic-entropy computation — enumeration of the belief-state tree over
a process. That is analysis over a process, not an operation of one, and generators' SPEC.md
covers belief updates (§3.5) rather than tree enumeration. Nothing in the spec's operations (§2) or
its conformance vectors (§7) describes it.
So if it is not going upstream, "parity" is unreachable by definition and the gate never opens.
Why it matters concretely
It is load-bearing for the interpretability work: the mixed-state tree is what produces the
ground-truth belief geometry that activation_tracker compares activations against. Two
eden-experiments consumers import it directly:
fraxl-run/salvage-candidate/scratch/sweep.py (and sweep_ifs.py) — MixedStateTreeGeneratornonergodic-demo/nonergodic_entropy.py — mixed_state_presentation plus builder
These are also the only two of the four external consumers that a vendored process would not already
satisfy; the other two use generate_data_batch, which is process-agnostic and works on vendored
processes today.
Options
- Keep it in simplexity, in a stable home (e.g.
simplexity/analysis/), operating on
simplexity.run_management.protocols.LogSpaceGenerativeProcess rather than on the concrete
classes. Consistent with "simplexity becomes a runner and analysis toolkit, processes live in
consumers". Requires deciding that parity explicitly excludes analysis.
- Upstream it into generators. Keeps everything process-adjacent in one place, but expands
generators' scope beyond its spec and works against its "modules, not a package" minimalism —
tree enumeration is not a small self-contained module.
- Have each consumer vendor it. Most faithful to the copying model, worst for duplication: it
is large, subtle, and the two consumers that need it would diverge.
Option 1 is my lean, with the caveat that it makes "feature parity" mean "parity on process
operations", not "parity on everything currently in the package" — which is worth stating
explicitly wherever the gate is recorded.
It also needs the log-space protocol to be the analysis contract, which is why
LogSpaceGenerativeProcess exists separately: those two operations are exactly what this code
consumes and what the training path never touches.
Related
- Capability gaps tracked upstream: ealt/generators#9
docs/design/generators_instantiation.md §4.3 (the gap inventory) and §8 D2 (the parity gate)
Split out of the generative-process instantiation work (
feat/generators-instantiation,docs/design/generators_instantiation.md§9 Q1). This is the item that gates the deprecationtimeline, so it wants a decision before the rest of the migration proceeds.
The problem
Full deprecation of
simplexity/generative_processesis gated ongenerators reaching feature parity. For most of the gap that
framing works: log-space operations, framing-token augmentation and the framework bridges are all
plausible upstream additions.
mixed_state_presentation.py(576 lines) is the exception. It providesMixedStateTree,MixedStateTreeGeneratorand myopic-entropy computation — enumeration of the belief-state tree overa process. That is analysis over a process, not an operation of one, and generators'
SPEC.mdcovers belief updates (§3.5) rather than tree enumeration. Nothing in the spec's operations (§2) or
its conformance vectors (§7) describes it.
So if it is not going upstream, "parity" is unreachable by definition and the gate never opens.
Why it matters concretely
It is load-bearing for the interpretability work: the mixed-state tree is what produces the
ground-truth belief geometry that
activation_trackercompares activations against. Twoeden-experimentsconsumers import it directly:fraxl-run/salvage-candidate/scratch/sweep.py(andsweep_ifs.py) —MixedStateTreeGeneratornonergodic-demo/nonergodic_entropy.py—mixed_state_presentationplusbuilderThese are also the only two of the four external consumers that a vendored process would not already
satisfy; the other two use
generate_data_batch, which is process-agnostic and works on vendoredprocesses today.
Options
simplexity/analysis/), operating onsimplexity.run_management.protocols.LogSpaceGenerativeProcessrather than on the concreteclasses. Consistent with "simplexity becomes a runner and analysis toolkit, processes live in
consumers". Requires deciding that parity explicitly excludes analysis.
generators' scope beyond its spec and works against its "modules, not a package" minimalism —
tree enumeration is not a small self-contained module.
is large, subtle, and the two consumers that need it would diverge.
Option 1 is my lean, with the caveat that it makes "feature parity" mean "parity on process
operations", not "parity on everything currently in the package" — which is worth stating
explicitly wherever the gate is recorded.
It also needs the log-space protocol to be the analysis contract, which is why
LogSpaceGenerativeProcessexists separately: those two operations are exactly what this codeconsumes and what the training path never touches.
Related
docs/design/generators_instantiation.md§4.3 (the gap inventory) and §8 D2 (the parity gate)