There is a particular interaction I want from a numerical notebook. I run a simulation, see a response curve, and move the part that settles too slowly. I pin the overshoot and the energy budget. The notebook returns a runnable change to the controller, together with the cases in which that change fails.

Drawing a nicer curve would be easy. Finding a permitted computation that produces it is the problem. The distinction matters because the system can often satisfy a visible request by making an unacceptable change somewhere upstream: smoothing the output, changing the input data, or quietly replacing the equation.

This is a developed research direction, not a workspace I have built. The interesting object is a persistent relationship among the displayed result, its computational provenance, and the constraints the owner has authorized.

Why the inverse is ambiguous

Write the forward computation as y = F(p, θ, x), where p is the program, θ its parameters, and x the experimental input. An edit describes a target region for y. There may be many pairs (p′, θ′) that reach it, or none.

Even the smooth local case is underdetermined. A requested change Δy gives an approximate equation JΔθ ≈ Δy. If J has a null space, several parameter changes can fit the gesture equally well. The cursor has not specified which one the user intended.

A least-change objective can choose among them, but “small” needs a scientific meaning. A tiny numerical edit to a coefficient may radically alter the interpretation of a model. A larger parameter change may be entirely acceptable. Parameter locks, units, equation constraints, and reference cases supply information the output alone does not contain.

The binding should survive the next run

A one-off inverse solve is useful. A stronger interface would save the target and invariants as an executable binding. When a new dataset arrives, the binding either still applies or becomes explicitly invalid. It should not silently attach itself to the wrong array because the notebook was refactored.

Repeated values make a small but revealing test. Two identical plotted numbers can come from different source locations. Moving one should not alter the other unless the source relationship actually requires it. Slices, reductions, cached intermediate results, and duplicated plots all create similar correspondence problems.

The system also needs a way to refuse. If the authorized gains cannot meet the desired settling time, it should report infeasibility under those degrees of freedom. A structural rewrite can be proposed separately. The user should be able to see that the system has moved from tuning the model to changing it.

An existing idea with a narrower open question

Output-directed programming has substantial prior art. Sketch-n-Sketch already connects manipulation of rendered output to changes in executable source. Numerical optimization already adjusts inputs to satisfy constraints. Neither graphical interaction nor source export is a novelty claim here.

The question I want to investigate is whether authorized output constraints can persist across repeated edits to an existing numerical program, compose across a supported set of operators, and reduce the owner’s attention after integration costs are counted.

Start with two numerical operator families and ordinary runnable notebooks. Trace the editable source, preview with local sensitivities, then rerun the actual computation before accepting a patch. For an opaque simulator, use an explicit parameter interface. Arbitrary Python inversion is far outside this initial contract.

What would make the idea unnecessary?

Give a strong coding agent the same notebook, solver, constraints, cached state, and runtime. Also give a human a well-designed slider-and-optimizer interface. Compare valid completed revisions and attention time over repeated use, including the time needed to establish the bindings.

If the advantage exists only during the first delightful gesture, it is an interaction demo. If the reusable binding saves work on the second notebook and survives the fifth input change, there may be a useful computational medium here. The distinction cannot be resolved by a screenshot of someone dragging a curve.

Reading and related work