Work Log: 2026-04

Append-only work notes for research, engineering, projects, and job preparation.

Posted Apr 27, 2026

By EnderJones

11 min read

Work Log: 2026-04

This is an append-only work log.

Main purpose: help future me resume work quickly.

Public readability is useful, but this is not a polished monthly report. Short notes are enough.

Rules:

Keep entries date-stamped.
Record what changed, what was decided, what is risky, and what to do next.
Keep private life details, confidential job-process details, and unpublished-sensitive experiment details out.
If one section grows too large, split it into a standalone post later.

Resume Here

Current active thread:

Clean CCT-LSTM protocol after detecting a potential Stage1/Stage2 split mismatch risk.
Old Phase 1 results are now exploratory only.
Clean p128 queue is the current formal experiment path.
Stage1/Stage2 should share the same outer subject split.
New checkpoints should include split-provenance metadata.
Stage1 landmark for seed 333185252 is complete and preserved.
Stage1 rPPG is now running as a three-seed parallel nohup job.
training/STOP_p128_clean is intentionally present to keep the main queue from entering Stage2 too early.

Last updated: 2026-04-27 early morning.

Current Next Actions

Let the parallel Stage1 rPPG job finish.
Verify rPPG checkpoint split metadata before trusting new results.
Remove training/STOP_p128_clean only after rPPG Stage1 is complete.
Restart the main queue after rPPG completion so Stage2 P0/P3/P4 can run.
Keep old exploratory results clearly separated from clean-protocol results.
Write a short standalone note on BP4D++ label limitations for stress estimation.

Standalone Candidates

Topics to split out later:

BP4D++ label limitations for stress estimation
Single-seed instability in small affective-computing datasets
Split provenance in two-stage deep-learning pipelines
Auxiliary losses for multimodal fusion stability
EDA integration into a video-based stress-estimation pipeline
Research repo structure: README / TODO / run ledger
From exploratory reproduction runs to a clean evaluation protocol

2026-04-26 Late Night to 2026-04-27 Early Morning

Project

Clean queue monitoring / rPPG parallel pretraining / public worklog setup.

Done

Checked the p128_clean queue progress several times.
Confirmed seed 333185252 Stage1 landmark completed 7 folds and preserved those checkpoints.
Found that Stage1 rPPG was much slower than landmark and would delay the full clean queue.
Updated the main queue script so Stage1 completion and metadata checks are modality-aware.
Added a parallel Stage1 rPPG script for seeds 333185252, 424505892, and 928861001.
Added a safer nohup launcher with stop/reset options, pidfile, master log, unbuffered logging, and STOP-file handling.
Cleanly stopped the previous queue/rPPG jobs, reset only rPPG partial outputs/logs, and kept landmark outputs.
Started the three-seed parallel rPPG run under nohup.
Confirmed the parallel rPPG jobs began writing fold outputs, split metadata, and live logs.
Investigated local history locations for coding-assistant sessions.
Started converting recent research and engineering notes into this public worklog format.

Decision

Do not parallelize the full queue because Stage2/results CSV/run-id/partial-dir handling is riskier.
Parallelize only Stage1 rPPG by seed; this changes scheduling, not the YAML, split, seed, or model protocol.
Do not attempt fold-level rPPG parallelism unless the training entry point gains explicit fold-range support.
Use nohup/pidfile/master-log launch for long experiment jobs instead of relying on an interactive terminal.
Use this blog as a public-facing worklog and resume anchor.
Keep private or messy thoughts outside this page.
Use this page for work that is safe to publish and useful to resume later.

Risk

Stage2 has not started yet, and training/results_p128_clean.csv has not been generated. Do not remove the STOP file or restart the main queue until rPPG Stage1 is complete and metadata checks pass.

Note

The purpose of this page is not to create a polished monthly summary. It is mainly a visible trace of what changed, what I decided, what became risky, and what I should do next.

Let the parallel rPPG Stage1 run finish.
Verify all rPPG checkpoint split metadata.
Remove training/STOP_p128_clean and restart the main queue.
Continue into Stage2 P0/P3/P4 under the clean p128 protocol.
Continue appending short date-stamped entries.
Move larger topics into standalone posts when useful.
Keep private notes in a separate private capture system.

2026-04-26 Night

Project

Clean p128 experiment queue.

Done

Designed the clean p128 protocol.
Planned P0-P8 under the clean setting.
Set all relevant embeddings to 128 dimensions.
Started the first batch of clean p128 runs.

Decision

The clean p128 queue is the current formal path.
It should not be mixed with the old exploratory Phase 1 results.

Continue clean p128 queue.
Verify checkpoint provenance.
Compare clean results against old exploratory trends carefully.

2026-04-26 Evening

Project

Documentation / handoff.

Done

Updated README architecture documentation.
Updated TODO.
Updated project context files.
Wrote a cleaner handoff for the clean protocol.

Decision

Documentation should let future me resume the project without relying on chat history.
README should stay architecture-level.
Detailed run status should stay in TODO.md and run&conclusion.md.

Keep README stable.
Keep run status in the dashboard and run ledger.

2026-04-26 Afternoon

Project

Clean subject-split protocol.

Done

Implemented the clean subject-split protocol.
Required Stage1 and Stage2 to use the same outer split.
Added split-provenance metadata to checkpoints.
Added verification around saved split information.

Decision

Reproducibility requires data-split provenance, not just same code and same seed.
New formal runs should use the clean protocol.

Verify split metadata for new checkpoints.
Restart experiments under the clean protocol.

2026-04-25 Night to 2026-04-26 Morning

Project

Critical protocol issue.

Done

Found a potential Stage1/Stage2 split mismatch risk in the old Phase 1 protocol.
Stopped the old experiment path.
Downgraded old Phase 1 results to exploratory status.

Risk

A small split-protocol mismatch can invalidate a large amount of experimental work.

This is the kind of issue that is easy to miss when the project evolves over time.

Decision

Do not keep polishing the old result.
Rebuild the clean protocol.
Mark old Phase 1 results as exploratory.

Implement a clean subject-split protocol.
Make Stage1 and Stage2 share the same outer split.
Save split provenance with checkpoints.

2026-04-25

Project

Repository cleanup / documentation roles.

Done

Reorganized git, .gitignore, and resource directories.
Clarified the roles of several project files:
- README.md: public-facing project overview and architecture
- TODO.md: current work dashboard
- run&conclusion.md: experiment ledger and conclusions

Decision

README should explain the project to a future reader.
Temporary notes and current state should not be dumped into README.
Current state belongs in TODO.md.
Experiment history belongs in run&conclusion.md.

Keep README stable and readable.
Move temporary notes elsewhere.

2026-04-24 Evening

Project

Seed variance / methodology direction.

Done

Reconfirmed large seed-level variance.
Reconsidered the paper framing.

Decision

The paper should probably not be framed only as “we got a higher F1.”

A stronger framing may be:

reliable protocol design for remote stress estimation
small-data reproducibility
multimodal fusion stability
clean separation between exploratory runs and formal evaluation

Risk

If the paper depends too much on one best score, the claim is weak.

Design runs that can support a methodology-oriented claim.
Track variance, not only the best result.

2026-04-24

Project

Phase 0.5 / Phase 1 monitoring.

Done

Monitored Phase 0.5 / Phase 1 experiments.
Reviewed preliminary R0-style results.
Checked the effect of scheduler patience.
Continued evaluating whether 128-dimensional vs 256-dimensional embeddings should be compared under a cleaner protocol.

Observation

Training hyperparameters that look like minor engineering settings can meaningfully change conclusions in small-data deep-learning experiments.

Risk

One run is not decisive.

Continue comparing protocol variants under cleaner conditions.
Avoid over-interpreting any single result.

2026-04-23

Project

Project context system cleanup.

Done

Migrated and cleaned up the project context system.
Reduced overlap between memory files, paper notes, and temporary context.
Defined a simpler structure:
- CLAUDE.md: long-term project rules and stable context
- TODO.md: current dashboard
- run&conclusion.md: experiment result ledger
- references/: stable reference facts
- archive/: old memory and paper-context files

Decision

TODO.md should be the current dashboard.
run&conclusion.md should be the experiment ledger.
Long-term rules and stable project assumptions belong in CLAUDE.md.

Note

Research context is infrastructure. If project memory is scattered, future work becomes slower and less reliable.

Keep TODO.md short and current.
Keep run results out of chat memory and inside the run ledger.

2026-04-22 to 2026-04-23

Project

Formal experiment protocol alignment.

Done

Re-reviewed the roles of old run series.
Checked seed choices, embedding sizes, preprocessing choices, and protocol assumptions.
Reframed older runs as method-evolution evidence rather than final paper evidence.
Stopped chasing increasingly complex CCT tuning.
Shifted priority toward cleaner comparisons.

Decision

Old exploratory runs can remain useful, but they should not become headline paper results.
Cleaner protocol comparison is more important than more tuning.
Prioritize reproducibility before optimization.

Risk

If exploratory and formal runs are mixed together, the final paper story becomes hard to defend.

Keep old runs as exploratory evidence.
Run cleaner protocol comparisons.
Separate formal evaluation from method-development history.

2026-04-17 to 2026-04-18

Project

Debugging story / portfolio writing.

Done

Tried drafting a blog-style debugging story around a difficult fold-level issue.
Considered an audience of programmers, researchers, and potential interviewers.
Moved the draft out of the research repo and kept it ignored from git.

Decision

Do not publish the debugging story yet.
Wait until the experiment protocol and causal chain are cleaner.

Note

A debugging story is only useful if the causal chain is clear. Otherwise, it becomes a diary rather than a technical note.

Keep raw writing outside the research repo.
Turn debugging stories into posts only after the technical conclusion is stable.

2026-04-16 to 2026-04-17

Project

EDA branch integration.

Done

Started implementing the EDA branch.
Decided to represent EDA as window-level physiological features rather than forcing it into the same representation format as video-derived features.
Worked through environment issues around .venv, uv run, PyTorch, NeuroKit2, and dependency consistency.

Observation

The trimodal version with EDA produced a promising preliminary result.

Exact scores are intentionally omitted here.

Risk

Adding EDA is not only a model-design issue. The real risk is alignment:

EDA windows
video-derived windows
labels
config
preprocessing assumptions
fold split

If these are not aligned, the model result becomes hard to trust.

Decision

Treat modality alignment as a first-class engineering requirement.
Record modality-specific preprocessing assumptions.

Keep checking whether EDA windows are exactly aligned with video-derived windows.
Record EDA extraction and alignment rules in project documentation.

2026-04-15

Project

Configuration cleanup.

Done

Checked whether training parameters were actually controlled by YAML configuration.
Reviewed possible drift between YAML, CLI arguments, and code defaults.
Moved more important training settings into config.

Risk

If scheduler, patience, and other training parameters are scattered across YAML, CLI, and hard-coded defaults, experiment provenance becomes fragile.

Decision

Important training parameters should be visible in YAML.
Future runs should be reproducible from config files.

Keep config files aligned with actual training behavior.
Avoid hidden defaults when running formal experiments.

2026-04-04 to 2026-04-07

Project

Seed stability / small-data reproducibility.

Done

Re-ran several experiment variants with different seeds.
Observed large seed-level variance.
Compared the effect of patience settings in the scheduler.

Risk

Single-seed results are not reliable enough for paper-level claims in this project.

A single lucky run can make a method look stronger than it really is. A worse-looking but more stable protocol may be more useful than a high but unstable score.

Decision

Treat seed variance as part of the experimental problem.
Avoid cherry-picking the best seed as the main conclusion.
Consider multi-seed stability as part of the methodology.

Track variance, not only best F1.
Keep scheduler settings explicit in config and result records.

2026-04-03

Project

CCT-LSTM multimodal fusion.

Done

Implemented auxiliary losses for unimodal branches:
- landmark auxiliary head
- rPPG auxiliary head
- fusion classifier as the main head
Tested the idea that auxiliary supervision may help prevent fusion from suppressing useful unimodal signals.

Observation

The auxiliary-loss version looked more stable than the older baseline in preliminary runs.

Exact scores are intentionally omitted here. This page is a public work log, not the final experiment table.

Decision

Keep auxiliary loss as a serious candidate for the formal protocol.
Do not judge it from a single run.

Re-run with multiple seeds.
Check whether the improvement is stable across folds and seeds.

2026-04-02

Project

CCT-LSTM reproduction / protocol review.

Done

Reviewed the current state of the CCT-LSTM reproduction.
Re-checked the original paper’s likely training flow.
Noted that some previous experiments may not be strict faithful reproductions.
Started moving run results out of scattered memory/context files into a dedicated run ledger.

Decision

Treat faithful reproduction and method extension as separate tracks.
Keep experiment results in an explicit result ledger instead of assistant memory or temporary notes.

Note

The freeze vs no-freeze question matters because it changes both interpretation and compute cost. If the encoders are frozen after unimodal pretraining, the reproduction means something different from initializing them into the multimodal framework and continuing training.

Compare freeze vs no-freeze behavior.
Keep run conclusions in run&conclusion.md.

Worklog

This post is licensed under CC BY 4.0 by the author.