Follow-up to the generative-process instantiation work
(docs/design/generators_instantiation.md §9 Q6).
Context
Run management now discovers a generative process two ways:
- Namespace fast path —
_target_ starts with simplexity.generative_processes.
- Declaration — the config section sets
component: generative_process
Path 2 exists because a process vendored from generators lives in the consumer's namespace and cannot
be recognized from its import path. Path 1 was retained deliberately so that the 11 in-repo process
configs, and the 60+ open branches that touch them, needed no changes.
The follow-up
Under the accepted direction (simplexity becomes a runner; processes live in consumers), the
namespace path is transitional: eventually every process config declares itself and the prefix test
retires. Adding component: generative_process to the in-repo configs makes the intent uniform and
lets the prefix path eventually be deleted rather than carried indefinitely.
The configs:
tests/end_to_end/configs/generative_process/
mess3.yaml, rrxor.yaml, nonergodic_example.yaml,
unified_chain_example.yaml, unified_chain_3mess3_2tomq.yaml,
unified_independent_example.yaml, unified_independent_example_crazy.yaml,
unified_symmetric_example.yaml, unified_transition_coupled_example.yaml,
unified_transition_and_emission_coupled_example.yaml
Declaration is additive and already tested as harmless for simplexity targets
(test_declaring_a_simplexity_process_is_harmless), so this is a mechanical one-line-per-file change.
Why it was deferred
Purely churn against in-flight branches — several open branches carry process work
(adam/factor_tree, adam/hidden-factors, adam/producted-generator*, casper/*) and touching
every process config invites merge conflicts for no immediate functional gain. Better done once
those have landed, or deliberately timed.
Retiring the prefix path itself is a separate, later step and should not happen while any consumer
still relies on it.
Follow-up to the generative-process instantiation work
(
docs/design/generators_instantiation.md§9 Q6).Context
Run management now discovers a generative process two ways:
_target_starts withsimplexity.generative_processes.component: generative_processPath 2 exists because a process vendored from generators lives in the consumer's namespace and cannot
be recognized from its import path. Path 1 was retained deliberately so that the 11 in-repo process
configs, and the 60+ open branches that touch them, needed no changes.
The follow-up
Under the accepted direction (simplexity becomes a runner; processes live in consumers), the
namespace path is transitional: eventually every process config declares itself and the prefix test
retires. Adding
component: generative_processto the in-repo configs makes the intent uniform andlets the prefix path eventually be deleted rather than carried indefinitely.
The configs:
Declaration is additive and already tested as harmless for simplexity targets
(
test_declaring_a_simplexity_process_is_harmless), so this is a mechanical one-line-per-file change.Why it was deferred
Purely churn against in-flight branches — several open branches carry process work
(
adam/factor_tree,adam/hidden-factors,adam/producted-generator*,casper/*) and touchingevery process config invites merge conflicts for no immediate functional gain. Better done once
those have landed, or deliberately timed.
Retiring the prefix path itself is a separate, later step and should not happen while any consumer
still relies on it.