HoLo-FuSe — class-conditional diffusion on the 0-parameter HSL byte substrate (minimal-scale baseline, honest results)

Following up on the HoLo line (byte-LM, speech): HoLo-FuSe tests whether the same frozen HSL
substrate can serve as the conditioning door of an image-generation carrier. Same method as the
other rooms: take a verified baseline, swap exactly one door for HSL, measure against controls.

Honest framing first. This was trained on a single free Colab T4 (~35M U-Net, 16k steps/arm,
128px). It is a minimum-scale baseline run — the point is proof of operation, not visual
quality. Please read the samples with that in mind; compute, not the method, is the main
quality ceiling here.

What HSL is, and which lens this room uses

HSL is a frozen, deterministic 27-D feature frame over bytes (value geometry + cross-byte flow +
boundary + Fourier + phase; a 4.6 KB LUT, 0 learned parameters). Per the family rule —
fixed substrate where possible, explicit lens where necessary — the only lens this room needs is
a label→condition readout:

label bytes -> frozen 27-D HSL frame (0 params) -> small learned readout (2-layer MLP) -> condition embedding -> added to the DDPM timestep embedding

No spatial lens: the conv U-Net carrier already owns spatial structure. The substrate stays frozen;
the readout is the only trained conditioning component, and it is budget-matched to the control.

Setup and the two controls

Class-conditional DDPM (cosine schedule T=250, multi-level U-Net + self-attention, EMA,
classifier-free guidance with cond-drop 0.15). Data: AFHQ animal faces at 128px, Cat 5153 / Dog
4739 (CC BY-NC 4.0 — so weights and samples are non-commercial). Three arms, same seed,
same data, same architecture surface, same budget
, compared at step 14000:

arm conditioning result (qualitative, seed-matched)
none unconditional baseline readable cat+dog faces, classes mixed
learned same-budget nn.Embedding control “Cat”→cats, “Dog”→dogs
hsl frozen HSL 27-D (0 learned params) + readout “Cat”→cats, “Dog”→dogs

Two observations from the seed-matched bench (image attached; positions share the same initial
noise):

  1. Conditioning works. Flipping the label on the same noise morphs the same composition
    between species.
  2. hsl ≈ learned. The frozen 0-parameter substrate steers class about as well as the learned
    embedding control. We claim comparable, not better — single seed set, qualitative
    inspection, no blind/multi-seed evaluation yet.

Known limits (stated, not hidden)

  • A background color tint appears in all three arms. A sampling sweep (CFG 1.3–2.0 ×
    dynamic-threshold 0.99/0.995, seed-matched) left it unchanged — it is an under-training
    artifact
    of a ~35M model at 14k steps, not a sampling or substrate problem. It also does not
    affect the arm comparison, since all arms share it.
  • Single seed set; 2 classes; small model. This bounds every claim above.

What’s next

The plan is to focus on quality of this one model (longer training, color balance, multi-seed
evaluation) rather than adding more models. That said, the compute budget is what it is — a free
T4 and a 4 GB laptop GPU — so please keep expectations modest. If the substrate claim survives
better-trained carriers, that is the result we are after; prettier cats are a bonus.

Code, training harness, bench scripts, and the POC record:
https://github.com/Woojiggun/HoLo-FuSe
Live demo (ZeroGPU, generates in seconds; checkpoints are linked from the repo):

Hi. For now, I tried a few lightweight checks. If the focus is HSL specificity, maybe something along these lines:


My read is that the current result already supports a useful, deliberately narrow claim:

The frozen HSL path can carry a usable global Cat/Dog condition into this DDPM carrier.

The same-noise Cat↔Dog changes, the unconditional control, and the learned-label control make that a reasonable proof-of-operation result. I also think the wording in the post — comparable, not better, single training seed, qualitative, two classes — is the right level of caution.

The next question is slightly different:

Did this work because the code was specifically HSL, or because the learned readout and U-Net only needed two stable, distinct class codes?

For that question, my default next step would be a same-shape fixed-random codebook arm, before spending the available compute on a much longer quality run.

A clean comparison would look roughly like this:

fixed HSL codebook    ┐
fixed random codebook ├─> identical 216→128→128 readout
learned codebook      ┘        ↓
                         identical U-Net condition surface

For the fixed-random arm, I would keep the real Cat/Dog supervision unchanged and randomize only the two frozen code vectors. Matching the width and approximate norm/scale of the HSL codes would remove easy numerical confounds. If compute allows, using more than one random codebook seed would also help distinguish a general result from an unusually convenient or inconvenient pair of random vectors.

This is not the same thing as training on random labels. The labels remain correct; only the frozen class codebook changes.

Given the stated free-T4 / small-GPU budget, I would probably prioritize:

  1. A short fixed-random arm
  2. Two or three training seeds rather than one very long seed
  3. A small class-consistency evaluation using a fixed sampling-noise bank
  4. Only then, longer training or heavier distribution metrics

The highest-value first number may be simpler than FID: for each initial noise, generate both Cat- and Dog-conditioned outputs and report how often an independent Cat/Dog classifier recognizes both requested classes. I would include per-class accuracy and the confusion matrix, not only one overall percentage.

That would test the exact behavior illustrated by the current grids: whether changing only the condition reliably changes the requested class.

A useful interpretation table might be:

Result Conservative reading
HSL ≈ fixed random, and both condition correctly The experiment supports a general frozen-code conditioning door; HSL-specific benefit is not yet identified in this setup
HSL learns earlier or is more stable across training seeds Preliminary evidence for an optimization or inductive-bias benefit in this setup
HSL wins only for one training seed or one random codebook More replication is needed before attributing the difference to the substrate
All conditional arms are unstable Carrier training or evaluation variance is probably the immediate bottleneck
HSL and random are similar at convergence, but HSL reaches useful class consistency earlier The most interesting claim may be sample/compute efficiency rather than final quality
Why I think the fixed-random arm is the most informative next control

There are several questions that are easy to merge together but are better kept separate.

1. Does the conditioning path function?

The current result gives evidence for this.

The published pipeline is:

label bytes
→ frozen HSL features
→ learned readout
→ 128-D condition
→ addition to the timestep embedding
→ U-Net

The forum post, repository, and model card all frame this as a minimum-scale conditioning-door test, rather than a competitive image-generation result.

2. Is an HSL code necessary in this two-class setup?

That is not yet identified.

With two labels, the system only observes two frozen input points. A learned nonlinear readout has considerable freedom to map those two points to useful condition vectors. An unrelated pair of stable vectors may therefore work similarly.

This is conceptually related to the general warning from probing research that a capable readout can sometimes learn the task itself, rather than merely reveal useful structure already present in its input. The setting is different, but control tasks for probes provide a useful methodological analogy: compare against a control representation that preserves easy surface properties while removing the structure under test.

Fixed class codewords also have a long history in classification, for example error-correcting output codes. That does not prove anything about this DDPM, but it is another reason not to assume that a fixed code must have a human-interpretable geometry before a learned network can use it.

3. Does HSL provide an optimization benefit?

This remains possible even if fixed random codes eventually work.

The useful comparison may be:

  • steps required to reach a chosen Cat/Dog consistency threshold;
  • variance across training seeds;
  • loss or consistency at early checkpoints;
  • robustness at reduced data or model capacity.

If HSL has a useful prior structure, it may show up in the learning curve rather than in one final qualitative grid.

4. Does HSL geometry matter beyond two labels?

Two labels are a particularly weak test of internal geometry because the model mainly needs to separate two points.

A stronger future geometry test would involve more classes or known relations among classes. That is probably not the first thing to spend a free-T4 budget on, but it matters for the eventual claim boundary.

A few inference-only sanity checks I tried on the released checkpoints

These were small checks on the published checkpoints, not replacement training experiments.

Post-hoc code reparameterization

I replaced the two frozen HSL input vectors with an unrelated pair of fixed 216-D random vectors and analytically refit only the first affine readout layer so that the two original first-layer targets were preserved.

The random pair was quite different from the HSL pair:

  • HSL Cat/Dog input cosine: about 0.73
  • random Cat/Dog input cosine: about 0.06

After refitting the first affine layer:

  • final condition maximum absolute difference: about 1.9e-8
  • U-Net noise-prediction maximum difference: about 9.5e-7
  • deterministic DDIM tensor maximum difference: about 2.5e-5
  • rendered 8-bit images differed by at most one intensity level in a very small number of channels

I would interpret this narrowly:

For the released two-label checkpoint, the learned function is not unique to the original HSL coordinate system.

This is a constructive identifiability check, not evidence that a random codebook would train equally well from scratch. The latter still requires the actual fixed-random training arm.

More generally, learned representations often have coordinate-system non-identifiability; linear identifiability of learned representations is relevant background, although it is not a direct analysis of HoLo-FuSe.

Condition timing

I also compared the released HSL and learned-label checkpoints under the same 16-step deterministic DDIM setup.

Across a few sampling seeds, both checkpoints showed a similar pattern:

  • Cat/Dog prediction contrast was weak at the first high-noise step;
  • it rose quickly during the early denoising region;
  • switching Cat↔Dog after roughly the first 20–30% of updates often failed to change the final species;
  • enabling the class condition only in the early part of sampling was much more influential than enabling it only late;
  • interpolation between the final Cat and Dog condition vectors produced a similar nonlinear transition in both arms.

The detailed curves from the two independently trained checkpoints were strongly correlated, but I would not use their absolute magnitudes as a performance comparison because the U-Nets were trained separately.

My narrow reading is:

The released HSL arm behaves much like a usable global class-conditioning channel, including when the condition acts during denoising.

That supports the proof-of-operation claim. It does not isolate HSL-specific geometry.

These timing observations also apply only to the tested respaced DDIM sampler. DDIM uses the same training procedure as DDPM but a different sampling process, so I would not transfer an exact “class locks in at step X” statement to the ancestral comparison bench.

A compact evaluation ladder that fits the compute budget

Level 1: fixed qualitative bank

Use a predeclared set of sampling seeds and show all of them, or at least state how the displayed subset was selected.

For every seed, keep:

  • initial noise;
  • Cat output;
  • Dog output;
  • arm;
  • checkpoint step;
  • sampler and sampler settings.

This prevents accidental cherry-picking and makes later checkpoints directly comparable.

Level 2: paired class consistency

For each initial noise, generate both requested classes.

A simple paired success definition is:

classifier(Cat-conditioned image) = Cat
and
classifier(Dog-conditioned image) = Dog

Report:

  • paired success rate;
  • Cat accuracy;
  • Dog accuracy;
  • confusion matrix;
  • number of generated pairs;
  • results per training seed.

The classifier should be validated on held-out real images. Its real-data performance should be reported so readers know whether it is a useful evaluator.

This score measures condition adherence, not perceptual quality.

The broader literature also distinguishes condition consistency from generic image quality. See Evaluation Metrics for Conditional Image Generation and ImagenHub, which separates semantic consistency from perceptual quality.

Level 3: training-seed robustness

Sampling-seed replication is useful, but it does not measure training variance.

Even two or three short training seeds can reveal:

  • whether arm rankings reverse;
  • whether conditioning sometimes fails to emerge;
  • whether one codebook has much larger variance;
  • whether a promising difference is larger than ordinary run-to-run noise.

With a limited budget, I would rather see three shorter, transparently bounded runs than one long run whose apparent advantage might be seed-specific.

Level 4: distribution metrics

If there is enough generation budget, KID or precision/recall can add distributional information.

However:

  • FID has finite-sample bias that depends on the generator, so using the same sample count for all arms does not remove every bias.
  • KID uses an MMD-based estimator and is a reasonable small-sample candidate, but “unbiased estimator” does not mean “low variance with very few samples.” Subset settings and variability should be retained.
  • Precision and recall for distributions can help separate sample fidelity from coverage, but the result still depends on the feature representation and implementation.
  • Classification Accuracy Score asks whether a classifier trained on generated images transfers to real images. It is useful, but heavier and somewhat different from the immediate question of whether the requested class condition is followed.

I would therefore put class consistency and training-seed replication before FID/KID in this particular PoC.

Important interpretation and reproducibility traps

These are mostly ways a reasonable experiment can be accidentally described more strongly than it supports.

Fixed random codes are not random labels

A fixed-random code control should preserve the correct Cat/Dog target.

Cat → fixed random vector A
Dog → fixed random vector B

Randomly assigning incorrect labels to individual training images is a different experiment involving corrupted supervision and possible memorization. It would not answer the HSL-specificity question cleanly.

One random codebook is only one draw

If fixed random performs much better or worse, the result may partly reflect that particular vector pair.

A practical compromise is:

  • one primary random codebook for the full comparison;
  • two or three extra codebook seeds for shorter confirmation runs.

Norm matching is useful, but geometry matching answers a different question

Matching approximate vector norm and scale removes a simple conditioning-amplitude confound.

By contrast, making a random pair with exactly the same Gram matrix as the HSL pair produces a rotated/reflected version of the same two-point geometry. With a learned first linear layer, that is mostly a coordinate-system control, not a test of whether HSL geometry is special.

For the primary null arm, I would use an unrelated fixed codebook with comparable scale.

“Same seed” is not automatically a fully paired training trajectory

The current harness usefully resets the seed for each arm, and the carrier initialization can therefore be closely matched. However, the condition modules have different shapes and consume different amounts of randomness during initialization. Subsequent minibatch choices, flips, timesteps, noise tensors, and condition-drop masks can then diverge even though the original global seed was the same.

For a stricter paired bench, possible options are:

  • separate generators for model initialization, data selection, augmentation, timestep selection, diffusion noise, and condition dropout;
  • or precompute and save the batch/noise/timestep schedules.

The PyTorch reproducibility guide also notes that complete reproducibility is not guaranteed across releases, platforms, and devices, and documents worker seeding and deterministic-operation trade-offs.

I would describe the current result as seed-matched, but not assume every stochastic training event was paired.

Same step count does not necessarily mean same optimization state

If one representation makes conditioning easier to learn, comparing only at step 14k may hide the main difference.

Conversely, if one arm is simply slower, an early snapshot may exaggerate a transient gap.

Learning curves or several predefined checkpoints make this much easier to interpret.

Sampling seeds are not training seeds

Repeating inference over many noise seeds can show whether a checkpoint’s behavior is stable across samples.

It cannot show whether another training run would learn the same solution.

Post-hoc reparameterization is not from-scratch equivalence

If a trained model can be rewritten with another code system, that shows non-uniqueness of representation.

It does not establish equal:

  • convergence speed;
  • optimization stability;
  • data efficiency;
  • training-seed variance;
  • multi-class behavior.

Classifier consistency is not image quality

A classifier may recognize a low-quality or stereotyped image correctly. It can also inherit biases from its own training data.

Class consistency should therefore be reported alongside sample grids and, later, a distribution or perceptual-quality measure.

Overall accuracy can hide one-class collapse

A model that produces Dog-like images for both conditions may still look acceptable under an imbalanced or poorly summarized metric.

Always retain:

  • per-class accuracy;
  • confusion matrix;
  • balanced sampling;
  • paired Cat/Dog success.

FID/KID do not test HSL specificity

Even a clear distribution-metric improvement does not by itself show why it occurred.

The fixed-random code control and training-seed structure answer the attribution question. FID/KID answer a different question about generated distributions.

Sampler-specific timing should remain sampler-specific

The live demo and the inference-only checks use fast respaced DDIM, while the main comparison bench is based on the repository’s DDPM setup.

The released Space is useful as a qualitative HSL demo, but it should not be read as a live reproduction of all three bench arms.

A one-line note in the README or Space would make this boundary especially clear:

The Space is a fast qualitative HSL demo; the reported three-arm comparison uses the bench configuration.

Condition-off and CFG-off are not identical

Setting the condition vector to zero for part of sampling removes the conditional input.

Changing when CFG is amplified modifies the difference between conditional and unconditional predictions.

These are related interventions, but not the same. Diffusers exposes guidance start/stop fractions in its guider API, which is useful vocabulary for future timing experiments.

Early class determination does not imply late conditioning is useless

The species may be selected early while later conditional guidance still affects texture, local anatomy, diversity, or image quality.

A “class identity locks in early” observation should therefore remain narrower than “all useful conditioning happens early.”

Condition interpolation is out-of-distribution

The model was trained on the Cat and Dog endpoints, not necessarily on intermediate condition vectors.

A smooth, abrupt, or strange intermediate trajectory is interesting descriptively, but it should not automatically be treated as semantic evidence about the original HSL geometry.

The shared color tint is not enough to identify one root cause

Because the tint appears in all arms, it is unlikely to be an HSL-specific artifact.

The reported CFG/dynamic-threshold sweep also suggests it is not removed by those particular sampling changes.

However, that does not uniquely identify under-training. Possible contributors still include:

  • dataset color statistics;
  • preprocessing;
  • limited carrier capacity;
  • checkpoint selection;
  • EMA behavior;
  • the noise schedule;
  • the sampler;
  • ordinary under-training.

“Consistent with a carrier/training-side artifact” is safer than claiming a uniquely established cause.

Dataset provenance matters before quantitative evaluation

The original AFHQ release contains Cat, Dog, and Wild domains, with a held-out test subset per domain. The official StarGAN v2 repository also documents an updated AFHQ version using Lanczos resizing and the removal of some images.

This project uses the community zzsi/afhq512_16k mirror and reports filtered class counts that do not exactly match the simple “5,000 per domain” description.

That is not evidence of a problem, but later quantitative work would be easier to interpret if it records:

  • the exact dataset repository revision;
  • split provenance;
  • post-filter class counts;
  • duplicate hashes across train/evaluation splits;
  • resize and normalization settings.

Nearest-neighbor checks are useful but not proofs

With a relatively small dataset, generated-to-training nearest-neighbor panels can detect obvious copying.

Failure to find a close neighbor does not prove absence of memorization, and finding a similar animal face does not automatically prove copying. This is a secondary diagnostic, not the first HSL control.

“Zero-parameter” should retain its boundary

The frozen HSL substrate has zero learned parameters. The downstream readout is learned.

The clearest wording is therefore:

a zero-parameter frozen substrate with a learned conditioning readout

Shortening this to “zero-parameter conditioning” may be read as saying that the complete conditioning path is untrained.

Budget-matched is not necessarily exactly parameter-matched

The current paths meet at the same final condition width, but their internal input widths and learned components are not identical.

That does not invalidate the PoC, and the difference is small relative to the U-Net. Still, a future three-arm setup with one identical readout and only the codebook type changed would be much easier for readers to interpret.

A compute-aware default route

Given the stated hardware budget, I would not make the next milestone depend on a large benchmark.

Lowest-cost route

  • Keep the current claim as a proof of operation.
  • Publish a fixed evaluation-noise bank.
  • Add exact parameter counts for each condition module.
  • Clarify the Space/bench sampler boundary.
  • Pin dataset and repository revisions.

One additional training arm

Add:

fixed unrelated random 216-D codebook
→ same 216→128→128 readout
→ same carrier

Use the existing training recipe and compare at predefined checkpoints.

Several short runs

Run HSL, fixed random, and learned with two or three training seeds.

At each checkpoint, record:

  • loss;
  • paired Cat/Dog consistency;
  • per-class consistency;
  • a fixed qualitative grid.

If one arm clearly separates, extend only that comparison.

More compute later

Then consider:

  • several random codebook draws;
  • KID or precision/recall;
  • a larger number of classes;
  • tests of class relationships or compositional labels;
  • memorization diagnostics;
  • longer carrier training.

This keeps the first next experiment tightly connected to the current claim rather than turning a small conditioning PoC into a full image-generation benchmark.

Overall, I think the current result is useful precisely because it is narrow and reproducible enough to ask the next question.

The result already says:

A frozen HSL-derived path can function as the class-conditioning door in this small DDPM.

The fixed-random arm would make the next sentence much easier to choose:

  • either “this setup mainly needs any stable frozen class code,”
  • or “HSL shows an early-learning or stability advantage worth testing further.”

Both outcomes would be informative, and neither would erase the proof-of-operation result already shown.

Thank you, as always, for the thorough and generous feedback — reviews of this depth are rare,
and every round of it has made this small project measurably better.

The fixed-random arm is done — full protocol, per-seed JSONs, and caveats are in the repo
(SPECIFICITY.md): HoLo-FuSe/SPECIFICITY.md at main · Woojiggun/HoLo-FuSe · GitHub
Below is the summary, following your evaluation ladder.

Protocol. Three arms — frozen HSL LUT / same-shape frozen-random LUT (randn(256,27), a fresh
draw per training seed) / learned embedding — with correct Cat/Dog supervision everywhere. The two
frozen arms share an identical 216→128→128 readout. 3 training seeds per arm, evaluated at
predefined checkpoints (4k/8k/12k steps), paired class-consistency on a fixed sampling-noise bank
(seed 777, n=32 pairs), one shared classifier trained on real data (held-out val acc 0.878 —
modest; it bounds absolute numbers but is identical across arms). Hardware note: batch 8 on an
RTX 4070 (batch 16 spills VRAM on 12 GB), so this is a shorter/smaller protocol than the released
14k/batch-16 checkpoints. Runs are seed-matched, not fully paired, per your distinction.

Binding curve (mean consistency ± std over 3 training seeds):

steps hsl fixed-random learned
4,000 0.500 ± 0.000 0.500 ± 0.000 0.500 ± 0.000
8,000 0.724 ± 0.070 0.698 ± 0.024 0.750 ± 0.000
12,000 0.828 ± 0.016 0.818 ± 0.018 0.891 ± 0.027

(4k sits below this setup’s binding threshold — the classifier degenerates to one class on the
still-unconditioned samples, so 0.5 there means “not bound yet”, not chance-level steering.)

Paired spec at 12k (paired = same noise, both requested classes recognized):

arm Cat Dog paired
hsl 0.740 ± 0.018 0.917 ± 0.036 0.656 ± 0.031
fixed-random 0.688 ± 0.054 0.948 ± 0.018 0.635 ± 0.036
learned 0.833 ± 0.072 0.948 ± 0.018 0.781 ± 0.054

Confusion matrices are in the per-seed JSONs; the dominant error in all arms is Cat-conditioned
images read as Dog.

Reading, per your interpretation table:

  1. hsl ≈ fixed-random on every metric, including binding speed — your first row. At two labels
    the frozen-code content is not identified; any stable pair works. This also agrees with your
    reparameterization check on the released checkpoint (we reproduce your HSL Cat/Dog input cosine
    of 0.73 exactly).
  2. learned is modestly but consistently ahead of both frozen arms (all 3 seeds). This refines
    our earlier single-seed qualitative “hsl ≈ learned” impression — under this quantitative
    protocol, adaptivity buys a small edge at 2 classes. We’ve updated the README accordingly.
  3. No parameter-efficiency story at this scale either: with 2 classes the learned table is 256
    params, and the hsl arm’s wider readout actually trains more parameters (44,288 vs 33,280 —
    counts now published). The precise wording is now “a zero-parameter frozen substrate with a
    learned conditioning readout”; the structural arguments (O(1) codebook vs O(V·d), open-vocabulary
    labels, substrate sharing) only become testable with a larger label space.

Caveats we’d flag ourselves: the random codes were not norm-matched (≈1.4× larger norm than
HSL — since the larger-amplitude codes did not win, this doesn’t rescue a geometry claim either
way, but a matched draw would be cleaner); classifier acc bounds absolute values; dataset revision
is now pinned and a cross-split sha256 check found 0 duplicates; the Space/bench sampler boundary
note was added as you suggested.

So the next sentence you offered is chosen: “this setup mainly needs any stable frozen class
code.”
The geometry and the efficiency questions now both point at the same next experiment —
many-class / structured / free-form labels — which we’ll take up when compute allows.

This control cost about one GPU-day and did more for the claim’s precision than any benchmark
would have. And of course — if there is anything in your review I have failed to reflect, or
reflected incorrectly, please do point it out anytime. I’ll keep posting results here either way.

Hi. I think this looks quite good. A few small details:


This substantially resolves the main ambiguity I had in mind.

The same-shape frozen-random control, three training seeds, predefined checkpoints, fixed sampling-noise bank, paired class-consistency measure, parameter counts, and explicit “seed-matched, not fully paired” caveat make the follow-up much easier to interpret than the original single-seed qualitative comparison.

My conservative reading of the new result would be:

Under this two-class, short-run protocol, HSL was not distinguishable from the sampled same-shape frozen-random controls, while the learned-label arm scored modestly higher under the shared evaluator.

That seems well supported by the reported tables. It preserves the original proof-of-operation result — the HSL path can carry a usable class condition — while answering the specificity question much more narrowly.

I also agree that another large image-generation benchmark would probably add less information now than this control did.

The remaining points look mostly like wording and reproducibility packaging rather than reasons for another GPU run.

Three small wording adjustments

1. “Any stable pair works”

I would narrow this slightly.

The experiment tested three random LUT draws, one associated with each training seed, under one Cat/Dog carrier and evaluation protocol. That is strong evidence that the result was not specific to the HSL codebook used here, but it is not literally a test of every possible stable code pair.

Something like this would stay closer to the observation:

HSL was not distinguishable from the three sampled same-shape frozen-random LUT controls under this two-class protocol.

Or, more compactly:

This setup did not identify an HSL-specific contribution over sampled frozen-random codes.

With only three training runs per arm, I would treat hsl ≈ random as a descriptive “no visible separation in these runs,” rather than a formal statistical-equivalence claim.

2. “Adaptivity buys a small edge”

The learned arm clearly scored higher in the reported evaluation:

12k result HSL Random Learned
Mean consistency 0.828 0.818 0.891
Paired success 0.656 0.635 0.781

I would only avoid assigning the cause entirely to adaptivity yet.

The observed difference could involve some mixture of:

  • the learned codebook;
  • the different condition-module parameterization;
  • ordinary training-run variance;
  • the learned arm producing images that are easier for this particular classifier to recognize;
  • an actual optimization advantage of the adaptive condition path.

A slightly safer sentence would be:

The learned arm scored modestly higher under this evaluator and short-run protocol.

That still records the important correction to the original qualitative hsl ≈ learned impression without claiming that the causal mechanism has already been isolated.

3. “Classifier accuracy bounds the absolute values”

I would change “bounds” to something softer.

A real-validation accuracy of 0.878 does not provide a mathematical upper bound on accuracy over generated images, because the generated-image distribution is different from the real validation distribution.

It does mean that the absolute consistency values should be interpreted cautiously.

For example:

The evaluator’s held-out real-data accuracy is modest (0.878), so the absolute generated-image consistency values should be treated as approximate; the same evaluator is nevertheless useful for controlled arm-to-arm comparisons.

The conditional-generation evaluation literature is also a useful reminder that condition adherence and perceptual image quality are separate questions.

One small reproducibility detail I may have missed

I could not find the exact script or command that generates all of the published:

  • paired-success values;
  • per-seed confusion matrices;
  • 4k / 8k / 12k binding table.

The current eval_consistency.py appears to:

  • calculate Cat consistency, Dog consistency, and their mean;
  • load one checkpoint path per arm/seed;
  • train the evaluator when the script runs;
  • write an arm-level mean and standard deviation.

It does not appear to emit paired success or a confusion matrix, and I do not see a checkpoint-step argument that selects the 4k/8k/12k snapshots.

I may simply be missing a second script. If those numbers came from a temporary aggregation script or notebook, committing that exact file and command would make the specificity result bundle nearly self-reproducing.

I would consider that the most useful remaining change. It is not a request for a new experiment — just the final piece connecting the published JSONs and tables to one executable path.

A compact invocation could eventually look something like:

python eval_specificity.py \
  --arms hsl,random,learned \
  --training-seeds 0,1,2 \
  --checkpoint-steps 4000,8000,12000 \
  --noise-seed 777 \
  --n-pairs 32 \
  --classifier-checkpoint checkpoints/afhq_catdog_evaluator.pt

The exact interface does not matter; preserving the script actually used matters more.

Evaluator details that may help interpret the Cat→Dog asymmetry

The dominant generated-image error is reportedly Cat-conditioned images being classified as Dog in every arm.

That may be a genuine carrier-side asymmetry, but the evaluator’s own held-out confusion matrix would be useful context:

  • real Cat recall;
  • real Dog recall;
  • balanced accuracy;
  • 2×2 real-validation confusion matrix.

If the evaluator itself is noticeably more likely to label real cats as dogs, some of the generated-image asymmetry may come from the measurement instrument.

If its real Cat/Dog recalls are balanced, the generated asymmetry becomes more informative about the diffusion runs.

I would therefore save and publish the evaluator once, together with:

  • architecture;
  • training seed;
  • training command;
  • weight file or hash;
  • real-validation per-class metrics;
  • label order used in the confusion matrix.

The current evaluation script retrains the classifier when invoked. The fixed seed helps, but reusing one saved evaluator would make it mechanically clear that every arm and checkpoint was scored by exactly the same classifier.

A machine-readable evaluator record could be as small as:

{
  "classifier_file": "afhq_catdog_evaluator.pt",
  "sha256": "...",
  "training_seed": 0,
  "label_order": ["Cat", "Dog"],
  "real_val_accuracy": 0.878,
  "real_val_confusion": [
    [0, 0],
    [0, 0]
  ]
}

The zeros here are only schema placeholders.

Random-arm variance and what the three seeds currently mix

Using a fresh frozen-random LUT for each training seed is useful because the conclusion is not tied to one arbitrary random codebook.

It also means that random-arm variation combines two sources:

  1. training-seed variation;
  2. codebook-draw variation.

So I would add one sentence such as:

Random-arm variability combines training-run variability with random-codebook-draw variability.

That does not weaken the present conclusion. In fact, seeing similar results across three different draws is useful evidence for the broad null control.

It only matters if a later experiment tries to attribute variance specifically to training stability.

A more factorial future experiment would separate:

one fixed random codebook × several training seeds
several random codebooks × one or more training seeds

I would not consider that necessary for the current follow-up. It is simply the clean route if random-code sensitivity later becomes a question.

Small norm-number check

One numerical detail may also be worth rechecking.

From the current random-LUT construction, I get random Cat/Dog code norms extending to roughly 18.6 for one of the published seeds, rather than ending around 15.0.

So the range may be closer to:

random: approximately 13.7–18.6
HSL:    approximately 9.8–11.0

The conclusion is unchanged: the larger random-code amplitudes did not produce a visible advantage over HSL.

This looks like a minor range transcription issue, possibly from reporting only part of the draws.

The 4k value and the meaning of the learned-arm difference

The 0.5 floor at 4k

The explanation in SPECIFICITY.md is useful: the classifier collapsed to one predicted class because the condition had not bound yet.

I would retain the distinction:

Numerically 0.5, but mechanistically a one-class prediction floor rather than demonstrated chance-level Cat/Dog steering.

For balanced Cat/Dog requests, always predicting one class produces a mean of 0.5; that number alone does not show that the model was randomly responding to the condition.

What the learned-arm lead currently supports

The clean positive observation is:

  • the learned arm had higher mean class consistency;
  • it had higher paired success;
  • the direction was consistent across the three reported training seeds.

That is useful preliminary evidence that the learned path is easier for this carrier/protocol to optimize.

It does not yet separate:

  • faster condition binding;
  • better final condition adherence;
  • more recognizable images;
  • better perceptual quality;
  • greater diversity.

The existing 4k/8k/12k curve already suggests an optimization interpretation, but a classifier-consistency curve is still only one view of optimization.

I would therefore keep the conclusion narrow:

Under this protocol, the learned condition path binds somewhat more effectively by 12k steps.

That is a meaningful result even without attaching a stronger causal explanation.

Dataset pinning and result-file cleanup

The provenance section is a strong addition:

  • exact Hugging Face dataset revision;
  • post-filter counts;
  • resize method;
  • zero cross-split SHA-256 duplicates.

One implementation detail appears not to be synchronized yet.

SPECIFICITY.md records the exact dataset revision:

e0e5b1fc6d24fd5fa644e8886b55989c41382e81

But build_afhq128.py still uses:

REV = "refs/convert/parquet"

That is a moving reference rather than the recorded immutable commit.

Replacing it with the published hash would make the code match the provenance statement directly.

If the cross-split duplicate check was performed with a separate short script, committing that script would also let future readers reproduce the 0 duplicates statement rather than only trust the recorded result.

One normalized result schema

The result bundle would also be easier to consume if every arm/checkpoint/seed used one common JSON shape.

For example:

{
  "arm": "hsl",
  "training_seed": 0,
  "codebook_seed": null,
  "checkpoint_step": 12000,
  "noise_seed": 777,
  "n_pairs": 32,
  "classifier_sha256": "...",
  "cat_accuracy": 0.0,
  "dog_accuracy": 0.0,
  "mean_consistency": 0.0,
  "paired_success": 0.0,
  "confusion_matrix": [
    [0, 0],
    [0, 0]
  ]
}

Again, the zeros are only placeholders.

A flat set of records like this would make it easy to regenerate every table and check that the same evaluator/noise bank was used throughout.

Public artifact synchronization

The current README and specificity document already reflect the new result well.

A few public-facing surfaces may still preserve the original single-seed wording:

  • the GitHub repository description;
  • the existing v0.1.0 release;
  • possibly parts of the Hugging Face model card or Space description.

I would preserve v0.1.0 as the historical proof-of-operation release rather than rewriting it. If this follow-up is intended to be a durable result, a new tag such as a specificity-control release would keep the timeline clear:

v0.1.0 — initial proof of operation
v0.2.0 — fixed-random specificity follow-up

The new release could archive:

  • exact code revision;
  • evaluator;
  • aggregation script;
  • compact result JSONs;
  • protocol/configuration;
  • hashes for the dataset revision, evaluator, and checkpoints if retained.

The live Space / bench boundary note is especially useful and should remain: the Space is an HSL qualitative DDIM demo, not a live reproduction of the full three-arm comparison.

I would also keep the revised color-cast wording synchronized everywhere:

consistent with a carrier/training-side artifact; the root cause is not uniquely identified.

That is more precise than treating under-training as the uniquely established cause.

Overall, I think the main experimental question has now been answered well enough for the current scale:

The HSL door functions, but this two-class experiment does not identify an advantage of HSL code content over sampled frozen-random codebooks.

The learned arm’s higher score is also a useful correction to the earlier qualitative impression, provided it remains phrased as an observation under this evaluator and protocol.

I do not think another GPU-day is necessary to support that conclusion. The largest remaining gains look like:

  1. committing the exact evaluation/aggregation path;
  2. saving the evaluator and its real-data confusion matrix;
  3. pinning the dataset hash in the builder itself;
  4. making the two strongest conclusion sentences slightly narrower.

The follow-up makes the project stronger precisely because the claim is now narrower, more testable, and easier for someone else to reproduce.

Thank you again — round two of feedback this careful is more than I could ask for. Everything
you flagged has been applied; the repo now reflects all of it (commit “Review round 2”):

Wording — all three adopted, essentially verbatim:

  1. The conclusion now reads “HSL was not distinguishable from the three sampled same-shape
    frozen-random LUT controls under this two-class protocol,” explicitly marked as a descriptive
    no-visible-separation observation (n=3), not statistical equivalence — with a note that the
    random arm mixes two variance sources (codebook draw + training seed) that n=3 cannot separate.
  2. The learned-arm sentence is now “scored modestly higher under this evaluator and short-run
    protocol,” with the candidate causes listed (codebook adaptivity, different condition-module
    parameterization, run variance, classifier-friendliness) and none asserted.
  3. “Bounds” → “approximate,” with your exact reasoning (real-data accuracy is not a bound on
    generated-image accuracy; the shared evaluator remains useful for arm-to-arm comparison).

Reproducibility — you were right, the exact path was missing. The published
eval_consistency.py was not what produced the tables; the actual runners lived on the training
host. They are now committed as-used: specificity/runner_curve.py (hsl/random binding-curve
JSONs) and specificity/runner_paired_learned.py (paired/confusion re-evals + learned curves) —
the segment training (--resume to 4k/8k/12k), fixed bank (seed 777), and aggregation are all in
those files. I chose preserving-what-ran over a cleaner interface, per your note.

Evaluator artifacts — this one was worth it. The shared evaluator’s weights are now committed
(specificity_results/evaluator_cls.pt) along with its real-data confusion matrix: Cat recall
0.782 vs Dog recall 0.974 on held-out real images. So the Cat→Dog error asymmetry visible in every
generated arm is substantially attributable to the evaluator itself, not necessarily to
generation — exactly the interpretation trap you hinted at. This is now stated next to the tables.

Also done: the dataset parquet revision is pinned inside the builder (build_afhq128.py, rev
e0e5b1fc…), and the model card / Space were synchronized to the narrowed wording.

I agree with your bottom line: the question at this scale is answered, and no further GPU-day is
needed — the next real test (many-class / structured / free-form labels) is where both the
geometry and the efficiency questions live, and we’ll bring the same controls there from the start.

As always — if anything above still doesn’t match what you had in mind, or if I’ve reflected
something incorrectly, please say so anytime. This exchange has been the most valuable review this
project has had.

Nice! One tiny thing: I may be missing it, but specificity_results/evaluator_cls.pt does not seem to be included in the repo or the snapshot. Since *.pt is ignored, perhaps it was skipped by .gitignore?

Good catch — that’s exactly what happened: the *.pt ignore rule (meant for the training
checkpoints) silently excluded the evaluator weights, and git add on the directory skipped it
without a warning. Fixed with an explicit gitignore exception; specificity_results/evaluator_cls.pt
(≈1 MB) is now tracked and pushed. Thank you for checking the bundle at that level of detail!