cond_cat / cond_cont column layout is a fragile three-file handshake #37
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The
cond_cat/cond_contcolumn layout is defined ingiant/data/transforms.pytwice (build_cond_features~line 811,build_features~line 980) and consumed ingiant/model/encoders.py:12-31(
cat_col_layout), held together by parallel comments that say "the two sidesmust never drift apart". Add a third conditioning axis — a detector-region
embedding, a per-track generation/depth scalar, a process prior — and it's a
coordinated three-file edit where getting the order wrong produces silently
mis-indexed columns, not an exception.
Proposal: a
CondLayoutobject built once from the conditioning config,returning named slices (
layout.particle_phys,layout.material_topn_col, …)consumed by both the feature builders and
ConditionEncoder; then aCONDITIONING_AXIS_REGISTRYso a new axis registers(feature_columns, encoder_module)as a pair rather than being threaded by hand.This is what makes "very customizable conditioning" real rather than "three
customizable modes of two fixed axes".
Migrated from
issues.md(v0.3.0 branch review, 2026-08-13), Issue 12.