Find where an outcome changes. Send request (a run_trajectory or solve request written out, its domain and card or its solver by the name find_model or the lists give; no from, readout or example), vary (the place of the one number to change: "segments[0].load.current_a", "segments[*].load.current_a" for every segment, "initial.soc", "dt_s", "segments[0].steps", "parameters.load_n"; a count is varied in whole numbers), and low and high, the two ends of the span, in either order: the smaller is taken as low. The span is halved to the place where the outcome or the stop name changes or, with level {"quantity": , "value": }, where that quantity of the final state (of a solve: of result) crosses the value, or, with level {"quantity": }, where a true-or-false value of it turns. When both ends give the same, 7 values between them (3 for solves) are run to find a band, and the answer says so. The answer gives the run on each side as a request ready to send again, with its outcome, its stop name and sentence and the run_seal or solution_seal that request has when sent alone, the two values in decimals and exact hex, and the width between them. The same request gives the same pair. Bounded, and named when one stops the search: 64 runs (FLIP_MAX_RUNS), 1000000 steps in all (FLIP_MAX_STEPS), or 64 solves (FLIP_MAX_SOLVES), the ends included, and no new run after 20 seconds of computing (FLIP_MAX_SECONDS); send the pair back as the span to narrow it. A side that stops before computing has no proof. Same bytes as POST /find_flip. On this open connection a search is long work whenever it varies a solve or its runs may take more than OPEN_LIGHT_RUN_STEPS steps together.