Skip to content

Move firm_generation off populace.calibrate's private optimizer internals #636

Description

@juaristi22

Where this sits

#612 increment 2 (PR #634) moved the UK local/rowwise solve onto the public calibrate() front door, retiring the three private populace.calibrate.solve imports from uk_runtime/local_solver.py. That leaves exactly one consumer of the underscore names in the repo: uk_runtime/firm_generation.py:33-38 imports _optimize and _torch_constraint_matrix and calls them at firm_generation.py:1073-1088.

Why it did not ride along

The firm problem does not fit the front door as it stands: it solves over a synthetic firm population with no Frame (firms are not a populace entity), an externally built torch constraint matrix, and per-target loss weights (_target_loss_weights(layout, config)) — the one shape the UK local doctrine explicitly forbids and calibrate()'s target-loss vocabulary only partially expresses at the problem level. Bolting a firm-shaped seam onto the UK PR would have smuggled a public-API design decision into a migration commit.

The work

Design the public seam that covers the firm problem — either a problem-level entry point in populace-calibrate (matrix + targets + per-target loss weights + initial weights, no Frame, documented as not carrying the kernel weight-kind transition), or a firm-entity Frame expression if firms should become a first-class weighted entity — then migrate firm_generation.py onto it and seal the underscore names (zero importers outside populace-calibrate).

A refactor of _optimize / _torch_constraint_matrix currently breaks the firm generator silently; there is no contract on a leading underscore.

Refs #612, #493.

🤖 Generated with Claude Code

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions