Verify dataset
verify_datasetVerifies the seal of a dataset. Short form: request is the run_dataset request as it was sent, and dataset_seal is the seal its answer gave. The plan is run again under run_dataset's permits and limits; the answer is holds, cause ("dataset_seal" when the seal given is not the seal the plan runs to), recomputed_dataset_seal when it holds (else no seal: run_dataset gives the true one), compared, and text_not_compared: no rows the agent holds are compared. A plan of solves is verified by this short form only. Long form: head, rows and frames_hex, the three parts a full answer carries (answer "full"), together, as they came. The rows, the root and the seal are recomputed, and row and fault name the first row changed, swapped, dropped or repeated; then the plan is run again under run_dataset's permits and limits and the engine's answer compared with it, value by value and byte for byte (cause answer_text, with differs_at and row): holds is true only when every byte is the engine's, values_hold when every value is. On this open connection a dataset is returned inline and holds at most 300 runs (OPEN_MAX_DATASET_ROWS), 1000000 steps in all (OPEN_MAX_DATASET_STEPS), 10000 frames and an answer counted from the plan at 4194304 bytes (OPEN_MAX_DATASET_ANSWER_BYTES) and 42500 characters, up to about 150 summary rows; a plan of solves holds the engine's own 64 and at most 15 s of them, or one, at each solver's measured time, which describe_solver states with the count (OPEN_PLAN_SECONDS). One address holds at most 1 physics permit at a time, and long work (a solve, a plan of runs or of solves, a run of more than 10000 steps, or a verification that computes one again) runs 1 at a time. A call that finds no permit or no place is answered "Too many concurrent physics tasks." and nothing waits: the same call sent later is answered once one is free. An answer is waited for 60 seconds, and long work is stopped there.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| head | No | With rows and frames_hex: the head a run_dataset answer carries. | |
| rows | No | With head and frames_hex: the rows a full run_dataset answer (answer "full") carries. | |
| request | No | With dataset_seal alone: the run_dataset request as it was sent (the head's request). The plan is run again, under the permits and the limits of run_dataset, and its seal is compared with dataset_seal. Nothing is stored or read from storage, so it works whatever the return mode and on every connection. Its fields are run_dataset's. Worked example of the short form, as the whole arguments: {"request":{"domain":"energy","card":"thermal","plan":{"kind":"list","runs":[{"initial":{"temperature_k":293.15},"dt_s":1.0,"segments":[{"steps":60,"load":{"heat_power_w":5.0,"ambient_k":293.15}}],"record_every":60}]},"store":"none","return":"inline"},"dataset_seal":"<the dataset_seal of its run_dataset answer, 96 lowercase hex digits>"}. | |
| frames_hex | No | With head and rows: the frames a run_dataset answer carries, or null. | |
| public_key | No | The base64 of the ML-DSA-87 public key (2,592 bytes) to verify the answer's signature with; without it, this engine's own. | |
| seen_nonces | No | Nonces of signatures already seen: one of them again is SignatureNonceReplayed. | |
| dataset_seal | No | With request: the dataset_seal of the run_dataset answer, compared with the seal the plan runs to. Alone: the seal of a dataset stored as files (return "file"), read from the connection's own folder of that name. A dataset returned in the answer is not stored: it is verified with its request, or by its head, rows and frames_hex. |