deterministic localized transfer

Labnote 014: deterministic localized transfer🔗

Question🔗

Does deterministic, class-balanced full-batch multiple-instance training retain Hero generalization after adding varied Inventory-only position data?

Method🔗

• Private input: the same seven approved, structurally masked development

batches used by Labnote 013.

• Spent holdout: excluded and not read.
• Regions, backbone, threshold, and development gate: unchanged.
• Training change: replace order-sensitive per-sample optimizer steps with a

normalized smooth-maximum, class-balanced full-batch objective.

• Evaluation: seven leave-one-development-batch-out folds.
• Accelerator: RTX 4070 through a non-preemptive accelerator lease.
• Internal execution record retained; identifier withheld.

Result🔗

Aggregate exact accuracy was 50/54 (92.6%). Hero's aggregate error rate was 5.6%; Inventory's was 1.9%. The previously collapsing second fold improved from 44.4% to 77.8%, and all three new position folds retained complete Inventory recall. The frozen development gate passed.

The gate emitted content-addressed candidate bc155807a28aee1a2d7d10fb18a96b24d40b9fe300fc3e01650f70e5d61cc649, bound to development corpus 303b996aa1791eeb5f151bcc85a4df571046d9fec17e640b83955bdcf0f34796. The job completed on CUDA with exit code 0 and no stderr, and the compute broker released the accelerator lease normally.

Decision🔗

Accept the deterministic architecture as a successor candidate eligible for a different fresh holdout. Do not promote it to live use, and do not evaluate it against the spent Labnote 012 holdout.

Retire the registered Labnote 012 evaluator so an operator cannot accidentally rerun the spent holdout. A future holdout must receive a new digest-bound definition and explicit scientific record.