Run a run_trajectory request (without a readout) and compare one published quantity with the caller's measurements, each at a landed step. The answer is the error in numbers (rms, mean signed, greatest absolute, model minus measurement, each with its exact hex), the model value at every compared step in decimals (model_values) and exact (model_values_hex), and a hash of the measurements, under one seal. Same bytes as POST /validate_series. There is no pass or fail and no threshold: the numbers are not a verdict. The seal has no key, so it does not show who measured or who computed. genesis_seal verify-validation rebuilds the seal and the statistics from the answer alone, of a run or of a plan of solves. In place of run, solves takes a plan of solves as run_dataset takes it (solver and plan, at most 64 solves): quantity is one number the solver publishes in its result, and each measurement is {"row": <the plan's row, from 0>, "value": }. The solves are sealed under one dataset_seal as run_dataset seals them, and the comparison is sealed by the same statistics, measurement hash and validation seal as a run's, with the dataset_seal in the place of the run seal and the row in the place of the step; a measured row whose solve did not converge is counted in not_reached. The same request sent again gives the same seal. On this open connection one address holds at most 1 physics permit at a time, and a solve, a dataset job and a run of more than 10000 steps are long work, of which 1 runs at a time: a call that finds no permit or no place is answered "Too many concurrent physics tasks." and is sent again; nothing waits. An answer is waited for 60 seconds.