Learnt Git Rebasing the hard way

Hello again! Weeks 9 and 10 covered the fourth estimator family, the first release that carries my work, and a git mess that taught me more than the code did. PR #1920 merged, and sbi 0.27 shipped First, the ratio estimator builder from my last post made it in, together with the whole base class hardening bundle. Right after that, sbi 0.27 was released and PRs 1 to 5 were ported over to main . So the typed builder API is now actually in a release, for NPE, NLE, MNPE, MNLE and all four NRE variants. That also means the free rename window is closed. The z_score_input and z_score_condition names we picked in week 7 are now the shipped names, which is exactly why we did that rename when we did. Writing the design before the code Under the new workflow I described last time, the vector field work started with a markdown file instead of a Python file. The vector field family is genuinely harder than the others. build_vector_field_estimator picks along what looks like three axes at the same time: whether you want flow matching or score matching, which SDE type you want if it is score matching, and which network architecture sits inside. And unlike every other family, there are no per-model build functions to hang a config class on. I wrote up the options with some open questions then my mentor, Jan reviewed it and we settled on one builder with a base class abstraction to cut the redundancy across builders. Doing this on paper first was clearly the right call. Some of the things I had assumed while writing the proposal turned out to be wrong, and finding that out in a review comment on a markdown file was a lot cheaper than finding it out in a review comment on 800 lines of code. PR #1921 : VectorFieldEstimatorBuilder With the design agreed, the implementation covers FMPE and NPSE. The builder takes the architecture as model , one of mlp , ada_mlp , transformer or transformer_cross_attn , plus estimator_type for flow versus score and sde_type for the noise schedule. One de