Problem
pred reduce exports a bundle {path, source, target} that is enough to let another pred invocation solve + lift (pred solve <bundle>), but it does not contain anything that an external tool (without problemreductions as a Rust dep) can use to map a target-space solution back to the source.
Typical use case that hits this:
pred reduce mis.json --to MaximumIndependentSet/KingsSubgraph/One -o bundle.json
# external solver (e.g. miso, a neutral-atom platform, a QAOA runtime)
# solves the KSG graph and returns a target-space config
# → no standard way to lift back to the source MIS without re-running pred
Why this matters
The whole point of pred reduce as a CLI is to let downstream solvers live outside Rust. Without an external lift path, every non-Rust consumer has to either (a) shell out back to pred solve (which re-solves from scratch with its own solver, defeating the purpose), or (b) reimplement the gadget-specific inverse map.
Possible directions
- Reserve a
lift field in the bundle JSON carrying gadget-level metadata sufficient to invert the map per reduction step (e.g. for MIS → KSG: per-atom "role + source-vertex id" so consumers can compute source config directly). Pros: self-contained, language-agnostic. Cons: schema is reduction-specific.
- Add a
pred lift <bundle> --config <target-config> subcommand that re-runs reduce_along_path internally and emits the source config. Pros: minimal schema change, works for all reductions for free. Cons: consumers still need pred installed.
- Both:
pred lift as the primary UX, plus optional lift field in JSON for pure-external consumers who don't want to shell out.
Ask
Agree this is a gap? If yes, which of the three directions is preferred? I lean toward (2) as the immediate fix (minimal surface, no schema churn) with (1) as a longer-term enhancement for fully offline consumers.
Problem
pred reduceexports a bundle{path, source, target}that is enough to let anotherpredinvocation solve + lift (pred solve <bundle>), but it does not contain anything that an external tool (withoutproblemreductionsas a Rust dep) can use to map a target-space solution back to the source.Typical use case that hits this:
Why this matters
The whole point of
pred reduceas a CLI is to let downstream solvers live outside Rust. Without an external lift path, every non-Rust consumer has to either (a) shell out back topred solve(which re-solves from scratch with its own solver, defeating the purpose), or (b) reimplement the gadget-specific inverse map.Possible directions
liftfield in the bundle JSON carrying gadget-level metadata sufficient to invert the map per reduction step (e.g. for MIS → KSG: per-atom "role + source-vertex id" so consumers can compute source config directly). Pros: self-contained, language-agnostic. Cons: schema is reduction-specific.pred lift <bundle> --config <target-config>subcommand that re-runsreduce_along_pathinternally and emits the source config. Pros: minimal schema change, works for all reductions for free. Cons: consumers still needpredinstalled.pred liftas the primary UX, plus optionalliftfield in JSON for pure-external consumers who don't want to shell out.Ask
Agree this is a gap? If yes, which of the three directions is preferred? I lean toward (2) as the immediate fix (minimal surface, no schema churn) with (1) as a longer-term enhancement for fully offline consumers.