[Architecture #478] Decide native-solver strategy for liblinear/libsvm-class workloads

[godofecht]

Parent: #478. Related: #479 #480.

The architecture audit shows external-native-bound sklearn rows are the hardest class. Flow needs an explicit policy rather than accidentally comparing a simple in-house solver against decades-optimized liblinear/libsvm forever.

Evaluate three strategies per solver family: (A) optimize the pure Flow implementation to parity/lead, (B) bind the mature native library behind a Flow API with zero-copy buffers, or (C) maintain both with an evidence-backed size/target selector. Compare runtime, memory, binary/dependency footprint, portability, deterministic semantics and maintenance cost.

Acceptance: LinearSVC/SVC have a documented backend decision; benchmarks compare equivalent algorithmic contracts; no hidden Python dependency; native binding overhead is measured; pure Flow remains available where required by WASM/embedded/portability goals if that is part of supported scope.

[godofecht]

Worked through the architecture decision in OpenProjects and arrived at a source-dual / artifact-specialized policy.

Core result: keeping both pure-Flow and native solver implementations in the source tree does not imply shipping both in every artifact. For a deployment profile, first eliminate inadmissible backends (target support, semantic contract, footprint/dependency policy), then remove any backend Pareto-dominated on the workload region. If native has no higher fixed cost and a lower marginal cost, native-only strictly dominates a hybrid artifact for that profile. If native is unavailable/forbidden (WASM, embedded, dependency-constrained), pure Flow is the only admissible backend. A runtime hybrid is justified only when both are legal and measured costs show a real crossover.

Under affine calibrated costs

T_P(w)=F_P+r_P w
T_N(w)=F_N+r_N w

with r_N < r_P, the exact crossover is

w*=(F_N-F_P)/(r_P-r_N).

This gives the recommended policy for #500: strategy C at source level, but A-or-B specialization per build profile. Keep/improve the pure Flow LinearSVC and KernelSVC paths for portability and as semantic reference implementations; add optional direct LIBLINEAR/LIBSVM backends for native desktop profiles with no Python dependency; do not ship a dual runtime selector unless direct same-contract measurements prove a useful crossover region.

The native backend must satisfy the same work/semantic certificate before timing is considered: same objective/configuration, compatible stopping/work contract, and compatible learned-model state. For LinearSVC in particular, bind the LIBLINEAR mode matching the existing squared-hinge objective rather than whichever mode benchmarks fastest.

Full derivation: ml/profile-constrained-native-solver-strategy.md
Flow selector witness: ml/profile-constrained-native-solver-strategy.flow

The Flow experiment exercises four cases: portable pure-only, desktop native dominance, a genuine positive runtime crossover, and a footprint-constrained target. The equivalent selector model passed locally. No hosted CI/workflow was used.