Zero-Trust Physics

Previous value: -"Optional: a sealed card run handed in through a coupling, as run_trajectory takes it."New value: +"Optional: a sealed card run handed in through a coupling, as run_trajectory takes it. Each handed value goes into parameters bit for bit, read from the run's frame_hex or a _hex value, not a decimal (CouplingLedgerBreach)."

Previous value: -"One of three forms. request and dataset_seal, the short form: the plan is run again and its seal compared. The three parts a full run_dataset answer carries (head, rows and frames_hex, all three required together, as they came), the long form: the rows, the root and the seal are recomputed from their exact values, then the head's plan is run again under the permits and the limits of run_dataset and the engine's full answer to it compared with the parts sent, value by value and then byte for byte, so a dataset that holds is every byte the engine's. dataset_seal alone: the stored dataset of that seal, its seals recomputed from its files and its plan run again into a folder of its own, the stored files compared with that run's byte for byte. The long form's answer carries holds, true when the answer sent is every byte the engine's, and values_hold beside it, true when every value of it is the engine's answer to its request computed again, whatever its spelling: each number by its 64-bit value, strings, flags and null exactly, keys and their order, the receipt string among them. A copy whose numbers a client wrote again in its own spelling (0.0001 for 1.0e-4, 12 for 12.0) has holds false and values_hold true, and differs_at names the first place its text differs. An answer the engine signed (signature, ML-DSA-87 over its receipt, with issued_at, expires_at and nonce) has its signature checked first, against public_key or else this engine's own key: one that does not hold is cause signature, named (SignatureDoesNotVerify, SignatureExpired, SignatureNonceReplayed, SignatureKeyMismatch, ReceiptDoesNotMatch, SignatureAbsent when public_key is given and there is none), and nothing is computed. The signature of a dataset follows its head's receipt."New value: +"One of three forms. request and dataset_seal, the short form: the plan is run again and its seal compared. The three parts a full run_dataset answer carries (head, rows and frames_hex, all three required together, as they came), the long form: the rows, the root and the seal are recomputed from their exact values, then the head's plan is run again under the permits and the limits of run_dataset and the engine's full answer to it compared with the parts sent, value by value and then byte for byte, so a dataset that holds is every byte the engine's. dataset_seal alone: the stored dataset of that seal, its seals recomputed from its files and its plan run again into a folder of its own, the stored files compared with that run's byte for byte. The long form's answer carries holds, true when the answer sent is every byte the engine's, and values_hold beside it, true when every value of it is the engine's answer to its request computed again, whatever its spelling: each number by its 64-bit value, strings, flags and null exactly, keys and their order, the receipt string among them. A copy whose numbers a client wrote again in its own spelling (0.0001 for 1.0e-4, 12 for 12.0) has holds false and values_hold true, and differs_at names the first place its text differs. An answer the engine signed (signature, ML-DSA-87 over its receipt, with issued_at, expires_at and nonce) has its signature verified first, against public_key or else this engine's own key: one that does not hold is cause signature, named (SignatureDoesNotVerify, SignatureExpired, SignatureNonceReplayed, SignatureKeyMismatch, ReceiptDoesNotMatch, SignatureAbsent when public_key is given and there is none), and nothing is computed. A signed answer a client wrote again in its own spacing or key order has its signature verified over the receipt it carries; where that receipt does not cover the bytes sent, signature names ReceiptDoesNotMatch with written_again, and the answer is computed again: holds, values_hold and differs_at say what changed. The signature of a dataset follows its head's receipt."

Previous value: -"The base64 of the ML-DSA-87 public key (2,592 bytes) to check the answer's signature with; without it, this engine's own."New value: +"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."

Previous value: -"The text of one response from compute_step, run_trajectory or solve, or the head of a dataset written as its JSON text. A signature after the receipt is checked against public_key or else this engine's own key, and reported under signature."New value: +"The text of one response from compute_step, run_trajectory or solve, or the head of a dataset written as its JSON text. A signature after the receipt is verified against public_key or else this engine's own key, and reported under signature."

Previous value: -"The base64 of the ML-DSA-87 public key (2,592 bytes) to check the answer's signature with; without it, this engine's own."New value: +"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."

Previous value: -"Either request and solution_seal alone, the short form: the request is solved again and its seal compared with solution_seal. Or the whole solve answer sent back as it came, without request, the long form: inputs, engine_version, outcome, iterations, reject, result, invariants, field_sha384, seal_parts and solution_seal are then all required. The solution seal is recomputed from its exact hex values and the part that fails is named; then its request is solved again under a physics permit and the limits of solve, and the engine's whole answer to it compared with the answer sent, value by value and then byte for byte, the receipt included, so an answer that holds is every byte the engine's. A seal has no key: an answer whose values were rewritten with its seal parts, seal and receipt worked out again holds every seal, and only the solve shows it is not the engine's (cause solution_seal). The long form's answer carries holds, true when the answer sent is every byte the engine's, and values_hold beside it, true when every value of it is the engine's answer to its request computed again, whatever its spelling: each number by its 64-bit value, strings, flags and null exactly, keys and their order, the receipt string among them. A copy whose numbers a client wrote again in its own spelling (0.0001 for 1.0e-4, 12 for 12.0) has holds false and values_hold true, and differs_at names the first place its text differs. An answer the engine signed (signature, ML-DSA-87 over its receipt, with issued_at, expires_at and nonce) has its signature checked first, against public_key or else this engine's own key: one that does not hold is cause signature, named (SignatureDoesNotVerify, SignatureExpired, SignatureNonceReplayed, SignatureKeyMismatch, ReceiptDoesNotMatch, SignatureAbsent when public_key is given and there is none), and nothing is computed."New value: +"Either request and solution_seal alone, the short form: the request is solved again and its seal compared with solution_seal. Or the whole solve answer sent back as it came, without request, the long form: inputs, engine_version, outcome, iterations, reject, result, invariants, field_sha384, seal_parts and solution_seal are then all required. The solution seal is recomputed from its exact hex values and the part that fails is named; then its request is solved again under a physics permit and the limits of solve, and the engine's whole answer to it compared with the answer sent, value by value and then byte for byte, the receipt included, so an answer that holds is every byte the engine's. A seal has no key: an answer whose values were rewritten with its seal parts, seal and receipt worked out again holds every seal, and only the solve shows it is not the engine's (cause solution_seal). The long form's answer carries holds, true when the answer sent is every byte the engine's, and values_hold beside it, true when every value of it is the engine's answer to its request computed again, whatever its spelling: each number by its 64-bit value, strings, flags and null exactly, keys and their order, the receipt string among them. A copy whose numbers a client wrote again in its own spelling (0.0001 for 1.0e-4, 12 for 12.0) has holds false and values_hold true, and differs_at names the first place its text differs. An answer the engine signed (signature, ML-DSA-87 over its receipt, with issued_at, expires_at and nonce) has its signature verified first, against public_key or else this engine's own key: one that does not hold is cause signature, named (SignatureDoesNotVerify, SignatureExpired, SignatureNonceReplayed, SignatureKeyMismatch, ReceiptDoesNotMatch, SignatureAbsent when public_key is given and there is none), and nothing is computed. A signed answer a client wrote again in its own spacing or key order has its signature verified over the receipt it carries; where that receipt does not cover the bytes sent, signature names ReceiptDoesNotMatch with written_again, and the answer is computed again: holds, values_hold and differs_at say what changed."

Previous value: -"The base64 of the ML-DSA-87 public key (2,592 bytes) to check the answer's signature with; without it, this engine's own."New value: +"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."

Previous value: -"Either request and run_seal alone, the short form: the run is computed again and its seal compared with run_seal. Or the whole run_trajectory answer sent back as it was returned, without request, the long form: inputs, frames, outcome, steps_landed, reject, run_seal, final_state, final_residual_conservation_error_hex, max_residual_conservation_error_hex and state_digest are then all required, along with the rest of the answer. The trajectory chain, the state digest and the run seal are recomputed from its exact hex values; then its request is computed again under a physics permit and the limits of run_trajectory, and the engine's whole answer to it compared with the answer sent, value by value and then byte for byte, the receipt included, so an answer that holds is every byte the engine's. A seal has no key: an answer whose values were rewritten with its seals worked out again holds every seal, and only the computation shows it is not the engine's. An answer that continues a sealed upstream run (its chain names upstream_run_seal) carries the upstream's seal and not its request, and its long form is refused (AnswerCarriesNoRequest): its chain's answers in order, as links, carry each request, and each link is computed again from the links before it. Or links alone: a chain's answers in order, held as the long form holds one. A design_run answer sent whole is designed again and held the same way. The long form's answer carries holds, true when the answer sent is every byte the engine's, and values_hold beside it, true when every value of it is the engine's answer to its request computed again, whatever its spelling: each number by its 64-bit value, strings, flags and null exactly, keys and their order, the receipt string among them. A copy whose numbers a client wrote again in its own spelling (0.0001 for 1.0e-4, 12 for 12.0) has holds false and values_hold true, and differs_at names the first place its text differs. An answer the engine signed (signature, ML-DSA-87 over its receipt, with issued_at, expires_at and nonce) has its signature checked first, against public_key or else this engine's own key: one that does not hold is cause signature, named (SignatureDoesNotVerify, SignatureExpired, SignatureNonceReplayed, SignatureKeyMismatch, ReceiptDoesNotMatch, SignatureAbsent when public_key is given and there is none), and nothing is computed."New value: +"Either request and run_seal alone, the short form: the run is computed again and its seal compared with run_seal. Or the whole run_trajectory answer sent back as it was returned, without request, the long form: inputs, frames, outcome, steps_landed, reject, run_seal, final_state, final_residual_conservation_error_hex, max_residual_conservation_error_hex and state_digest are then all required, along with the rest of the answer. The trajectory chain, the state digest and the run seal are recomputed from its exact hex values; then its request is computed again under a physics permit and the limits of run_trajectory, and the engine's whole answer to it compared with the answer sent, value by value and then byte for byte, the receipt included, so an answer that holds is every byte the engine's. A seal has no key: an answer whose values were rewritten with its seals worked out again holds every seal, and only the computation shows it is not the engine's. An answer that continues a sealed upstream run (its chain names upstream_run_seal) carries the upstream's seal and not its request, and its long form is refused (AnswerCarriesNoRequest): its chain's answers in order, as links, carry each request, and each link is computed again from the links before it. Or links alone: a chain's answers in order, held as the long form holds one. A design_run answer sent whole is designed again and held the same way. The long form's answer carries holds, true when the answer sent is every byte the engine's, and values_hold beside it, true when every value of it is the engine's answer to its request computed again, whatever its spelling: each number by its 64-bit value, strings, flags and null exactly, keys and their order, the receipt string among them. A copy whose numbers a client wrote again in its own spelling (0.0001 for 1.0e-4, 12 for 12.0) has holds false and values_hold true, and differs_at names the first place its text differs. An answer the engine signed (signature, ML-DSA-87 over its receipt, with issued_at, expires_at and nonce) has its signature verified first, against public_key or else this engine's own key: one that does not hold is cause signature, named (SignatureDoesNotVerify, SignatureExpired, SignatureNonceReplayed, SignatureKeyMismatch, ReceiptDoesNotMatch, SignatureAbsent when public_key is given and there is none), and nothing is computed. A signed answer a client wrote again in its own spacing or key order has its signature verified over the receipt it carries; where that receipt does not cover the bytes sent, signature names ReceiptDoesNotMatch with written_again, and the answer is computed again: holds, values_hold and differs_at say what changed."

Previous value: -"The base64 of the ML-DSA-87 public key (2,592 bytes) to check the answer's signature with; without it, this engine's own."New value: +"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."

Previous value: -"^[0-9a-f]{64}$"New value: +"^[0-9a-f]{96}$"

Previous value: -"A plan of runs on one card (domain, card, plan, store and return, all required) or of solves of one solver (solver and plan). Rows <= 100000, steps in total <= 100000000, stored frames <= 16777216; inline: an answer counted from the plan <= 40000 characters, which a plan reaches first, a grid on one axis at about 140 summary rows and a list sooner, its head repeating each run's request (a plan of more than 1000 rows is refused before it is counted, as too large to return inline), and frames <= 10000; solves <= 64. With return \"file\" the answer is the head and the names of the files stored, on a connection started with a directory for them."New value: +"A plan of runs on one card (domain, card, plan, store and return, all required) or of solves of one solver (solver and plan). Rows <= 100000, steps in total <= 100000000, stored frames <= 16777216; inline: an answer counted from the plan <= 42500 characters, which a plan reaches first, a grid on one axis at about 150 summary rows and a list sooner, its head repeating each run's request (a plan of more than 1000 rows is refused before it is counted, as too large to return inline), and frames <= 10000; solves <= 64. With return \"file\" the answer is the head and the names of the files stored, on a connection started with a directory for them."

Previous value: -"Leave out, or \"summary\", for the head and one short summary row per row: the values it sets, outcome, steps landed, refusal name and seal; \"states\" adds each run's final state in decimals; \"full\" gives every row whole. With return \"file\" the answer is the head and the names of the files whatever this says. Not part of the sealed request. The head and the dataset_seal are the same in all three forms. A summary row holds row, set (the values a grid's or a sample's row sets), outcome, steps_landed, reject and run_seal; the quantities of one row are read by sending its request to run_trajectory with a readout. An ended row is a run that stopped at an end its card declares: it has a run seal, the end's reject name in reject and the sentence naming the end in reject_detail. A refused row is a run the card refused part way: it has a run seal, the refusal's name in reject and its sentence in reject_detail. An unadmitted row is a request turned away before computing: it has no run seal, and its sentence, with the refusal's name in round brackets when the sentence gives one, is its reject_detail; its summary row gives that name in reject. What a sentence that begins \"Physical Failure\" or \"Physical Violation\" means is in the description of run_trajectory. An inline answer is counted from the plan before anything runs, and one above 40000 characters is refused with what to change: a summary row counts 220 characters and the values it sets; with states, each number of the final state adds its name and 28 characters (84 for a 3-vector, 9 for a flag); a whole row counts its own request and 1900 characters, and for each number twice its name and 60 characters (150 for a 3-vector, 9 for a flag); store \"frames\" adds 128 characters for each recorded state to a full answer; the head repeats the request."New value: +"Leave out, or \"summary\", for the head and one short summary row per row: the values it sets, outcome, steps landed, refusal name and seal; \"states\" adds each run's final state in decimals; \"full\" gives every row whole. With return \"file\" the answer is the head and the names of the files whatever this says. Not part of the sealed request. The head and the dataset_seal are the same in all three forms. A summary row holds row, set (the values a grid's or a sample's row sets), outcome, steps_landed, reject and run_seal; the quantities of one row are read by sending its request to run_trajectory with a readout. An ended row is a run that stopped at an end its card declares: it has a run seal, the end's reject name in reject and the sentence naming the end in reject_detail. A refused row is a run the card refused part way: it has a run seal, the refusal's name in reject and its sentence in reject_detail. An unadmitted row is a request turned away before computing: it has no run seal, and its sentence, with the refusal's name in round brackets when the sentence gives one, is its reject_detail; its summary row gives that name in reject. What a sentence that begins \"Physical Failure\" or \"Physical Violation\" means is in the description of run_trajectory. An inline answer is counted from the plan before anything runs, and one above 42500 characters is refused with what to change: a summary row counts 220 characters and the values it sets; with states, each number of the final state adds its name and 28 characters (84 for a 3-vector, 9 for a flag); a whole row counts its own request and 1900 characters, and for each number twice its name and 60 characters (150 for a 3-vector, 9 for a flag); store \"frames\" adds 128 characters for each recorded state to a full answer; the head repeats the request."

Previous value: -"A plan of solves: the solver, in place of domain and card. It takes no store and no return. A plan of solves is answered inline: a list, {\"kind\":\"list\",\"solves\":[{\"parameters\":{...}}]}, or a grid, {\"kind\":\"grid\",\"base\":{\"parameters\":{...}},\"axes\":[{\"path\":\"parameters.<input>\",\"values\":[...]}]}, of at most 64 solves. Each row is a solve request, solved as solve solves it and carrying the solution_seal solve gives it; a request turned away without a seal, by the rules of a request or by the solver, is an unadmitted row. The rows are sealed under one dataset_seal by the rules of a plan of runs, with solution_seal in the leaf in the place of run_seal, and completed in the counts counts the solves that converged. A summary row has row, set, outcome, reject, solution_seal and every single number of the result in decimals; answer \"full\" gives every solution whole, and is refused when it comes to more than 40000 characters. verify_dataset verifies a plan of solves by its request and dataset_seal, and validate_series compares one number of its results with measurements. Worked plan of solves: {\"solver\":\"atom_dft\",\"plan\":{\"kind\":\"list\",\"solves\":[{\"parameters\":{\"atomic_number\":10}}]}}."New value: +"A plan of solves: the solver, in place of domain and card. It takes no store and no return. A plan of solves is answered inline: a list, {\"kind\":\"list\",\"solves\":[{\"parameters\":{...}}]}, or a grid, {\"kind\":\"grid\",\"base\":{\"parameters\":{...}},\"axes\":[{\"path\":\"parameters.<input>\",\"values\":[...]}]}, of at most 64 solves. Each row is a solve request, solved as solve solves it and carrying the solution_seal solve gives it; a request turned away without a seal, by the rules of a request or by the solver, is an unadmitted row. The rows are sealed under one dataset_seal by the rules of a plan of runs, with solution_seal in the leaf in the place of run_seal, and completed in the counts counts the solves that converged. A summary row has row, set, outcome, reject, solution_seal and every single number of the result in decimals; answer \"full\" gives every solution whole, and is refused when it comes to more than 42500 characters. verify_dataset verifies a plan of solves by its request and dataset_seal, and validate_series compares one number of its results with measurements. Worked plan of solves: {\"solver\":\"atom_dft\",\"plan\":{\"kind\":\"list\",\"solves\":[{\"parameters\":{\"atomic_number\":10}}]}}."

Previous value: -"^[0-9a-f]{64}$"New value: +"^[0-9a-f]{96}$"

Previous value: -"A state is recorded at each multiple of record_every and at the last landed step. The size of the answer follows from the request: about 230 characters for each recorded state, plus the request as it was sent, plus up to 8000 characters for the final state and the seals. So 10,000 steps with record_every 1 answer with about 2.3 million characters, and the same steps with record_every 10000 with one recorded state. What keeps it small: a larger record_every; the final state is returned in full whatever is recorded."New value: +"A state is recorded at each multiple of record_every and at the last landed step. The size of the answer follows from the request: about 262 characters for each recorded state, plus the request as it was sent, plus up to 8000 characters for the final state and the seals; a flagged state adds about 400 characters for each limit it is past (exceedances). So 10,000 steps with record_every 1 answer with about 2.3 million characters, and the same steps with record_every 10000 with one recorded state. What keeps it small: a larger record_every; the final state is returned in full whatever is recorded."

Previous value: -"^[0-9a-f]{64}$"New value: +"^[0-9a-f]{96}$"

Previous value: -"Optional: a commitment the measurements were locked with before this comparison, opened by this request. sha256 is the SHA-256 of these bytes: the line zero-trust-physics/measurement-commitment/v1 and a line break; the sealed form (the text a request's seal is taken over: keys sorted by their bytes, each number x and the 16 hex digits of its 64-bit float, no spaces) of {\"component\": <this request's component, or null>, \"measurements\": <this request's measurements>, \"quantity\": <this request's quantity>}; a line break; and the salt's bytes, its hex decoded. salt is 32 to 128 lowercase hex digits, 16 to 64 bytes, kept back until the comparison so that the data are not found from the sha256 by trying values. The engine makes the digest again from the request before computing: data that do not open it (a value, a step or a row changed, moved, added or dropped, another quantity or another salt) are refused as CommitmentDoesNotMatch, a salt shorter than 16 bytes as CommitmentSaltTooShort, a field of the wrong form as CommitmentMalformed, and sha256 or salt left out as InputMissing; nothing is computed and nothing is sealed. Opened, the comparison runs as it runs without one, validation_seal takes the commitment as a sixth part, and the answer says so in commitment_opened. A commitment shows that the data were not changed after it was made; when it was made is shown by where its sha256 was published before the comparison."New value: +"Optional: a commitment the measurements were locked with before this comparison, opened by this request. sha384 is the SHA-384 of these bytes: the line zero-trust-physics/measurement-commitment/v2 and a line break; the sealed form (the text a request's seal is taken over: keys sorted by their bytes, each number x and the 16 hex digits of its 64-bit float, no spaces) of {\"component\": <this request's component, or null>, \"measurements\": <this request's measurements>, \"quantity\": <this request's quantity>}; a line break; and the salt's bytes, its hex decoded. salt is 32 to 128 lowercase hex digits, 16 to 64 bytes, kept back until the comparison so that the data are not found from the sha384 by trying values. The engine makes the digest again from the request before computing: data that do not open it (a value, a step or a row changed, moved, added or dropped, another quantity or another salt) are refused as CommitmentDoesNotMatch, a salt shorter than 16 bytes as CommitmentSaltTooShort, a field of the wrong form as CommitmentMalformed, and sha384 or salt left out as InputMissing; nothing is computed and nothing is sealed. Opened, the comparison runs as it runs without one, validation_seal takes the commitment as a sixth part, and the answer says so in commitment_opened. A commitment shows that the data were not changed after it was made; when it was made is shown by where its sha384 was published before the comparison."

Previous value: -"The salt the sha256 was made with: 32 to 128 lowercase hex digits, 16 to 64 bytes."New value: +"The salt the sha384 was made with: 32 to 128 lowercase hex digits, 16 to 64 bytes."

Removed value: -{
-  "description": "The SHA-256 committed, 64 lowercase hex digits.",
-  "pattern": "^[0-9a-f]{64}$",
-  "type": "string"
-}

Added value: +{
+  "description": "The SHA-384 committed, 96 lowercase hex digits.",
+  "pattern": "^[0-9a-f]{96}$",
+  "type": "string"
+}

Previous value: -[
-  "sha256",
-  "salt"
-]New value: +[
+  "sha384",
+  "salt"
+]

Previous value: -"One of three forms. request and dataset_seal, the short form: the plan is run again and its seal compared. The three parts a full run_dataset answer carries (head, rows and frames_hex, all three required together, as they came), the long form: the rows, the root and the seal are recomputed from their exact values, then the head's plan is run again under the permits and the limits of run_dataset and the engine's full answer to it compared with the parts sent, value by value and then byte for byte, so a dataset that holds is every byte the engine's. dataset_seal alone: the stored dataset of that seal, its seals recomputed from its files and its plan run again into a folder of its own, the stored files compared with that run's byte for byte. The long form's answer carries holds, true when the answer sent is every byte the engine's, and values_hold beside it, true when every value of it is the engine's answer to its request computed again, whatever its spelling: each number by its 64-bit value, strings, flags and null exactly, keys and their order, the receipt string among them. A copy whose numbers a client wrote again in its own spelling (0.0001 for 1.0e-4, 12 for 12.0) has holds false and values_hold true, and differs_at names the first place its text differs."New value: +"One of three forms. request and dataset_seal, the short form: the plan is run again and its seal compared. The three parts a full run_dataset answer carries (head, rows and frames_hex, all three required together, as they came), the long form: the rows, the root and the seal are recomputed from their exact values, then the head's plan is run again under the permits and the limits of run_dataset and the engine's full answer to it compared with the parts sent, value by value and then byte for byte, so a dataset that holds is every byte the engine's. dataset_seal alone: the stored dataset of that seal, its seals recomputed from its files and its plan run again into a folder of its own, the stored files compared with that run's byte for byte. The long form's answer carries holds, true when the answer sent is every byte the engine's, and values_hold beside it, true when every value of it is the engine's answer to its request computed again, whatever its spelling: each number by its 64-bit value, strings, flags and null exactly, keys and their order, the receipt string among them. A copy whose numbers a client wrote again in its own spelling (0.0001 for 1.0e-4, 12 for 12.0) has holds false and values_hold true, and differs_at names the first place its text differs. An answer the engine signed (signature, ML-DSA-87 over its receipt, with issued_at, expires_at and nonce) has its signature checked first, against public_key or else this engine's own key: one that does not hold is cause signature, named (SignatureDoesNotVerify, SignatureExpired, SignatureNonceReplayed, SignatureKeyMismatch, ReceiptDoesNotMatch, SignatureAbsent when public_key is given and there is none), and nothing is computed. The signature of a dataset follows its head's receipt."

Previous value: -"^[0-9a-f]{64}$"New value: +"^[0-9a-f]{96}$"

Added value: +{
+  "description": "The base64 of the ML-DSA-87 public key (2,592 bytes) to check the answer's signature with; without it, this engine's own.",
+  "type": "string"
+}

Previous value: -"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, 64 lowercase hex digits>\"}."New value: +"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>\"}."

Added value: +{
+  "description": "Nonces of signatures already seen: one of them again is SignatureNonceReplayed.",
+  "items": {
+    "pattern": "^[0-9a-f]{64}$",
+    "type": "string"
+  },
+  "type": "array"
+}

Previous value: -"The text of one response from compute_step, run_trajectory or solve, or the head of a dataset written as its JSON text."New value: +"The text of one response from compute_step, run_trajectory or solve, or the head of a dataset written as its JSON text. A signature after the receipt is checked against public_key or else this engine's own key, and reported under signature."

Added value: +{
+  "description": "The base64 of the ML-DSA-87 public key (2,592 bytes) to check the answer's signature with; without it, this engine's own.",
+  "type": "string"
+}

Previous value: -"The exact text of a response as it was received, ending with the receipt."New value: +"The exact text of a response as it was received, ending with the receipt, and the engine's signature after it when it carries one."

Added value: +{
+  "description": "Nonces of signatures already seen: one of them again is SignatureNonceReplayed.",
+  "items": {
+    "pattern": "^[0-9a-f]{64}$",
+    "type": "string"
+  },
+  "type": "array"
+}

Previous value: -"Either request and solution_seal alone, the short form: the request is solved again and its seal compared with solution_seal. Or the whole solve answer sent back as it came, without request, the long form: inputs, engine_version, outcome, iterations, reject, result, invariants, field_sha256, seal_parts and solution_seal are then all required. The solution seal is recomputed from its exact hex values and the part that fails is named; then its request is solved again under a physics permit and the limits of solve, and the engine's whole answer to it compared with the answer sent, value by value and then byte for byte, the receipt included, so an answer that holds is every byte the engine's. A seal has no key: an answer whose values were rewritten with its seal parts, seal and receipt worked out again holds every seal, and only the solve shows it is not the engine's (cause solution_seal). The long form's answer carries holds, true when the answer sent is every byte the engine's, and values_hold beside it, true when every value of it is the engine's answer to its request computed again, whatever its spelling: each number by its 64-bit value, strings, flags and null exactly, keys and their order, the receipt string among them. A copy whose numbers a client wrote again in its own spelling (0.0001 for 1.0e-4, 12 for 12.0) has holds false and values_hold true, and differs_at names the first place its text differs."New value: +"Either request and solution_seal alone, the short form: the request is solved again and its seal compared with solution_seal. Or the whole solve answer sent back as it came, without request, the long form: inputs, engine_version, outcome, iterations, reject, result, invariants, field_sha384, seal_parts and solution_seal are then all required. The solution seal is recomputed from its exact hex values and the part that fails is named; then its request is solved again under a physics permit and the limits of solve, and the engine's whole answer to it compared with the answer sent, value by value and then byte for byte, the receipt included, so an answer that holds is every byte the engine's. A seal has no key: an answer whose values were rewritten with its seal parts, seal and receipt worked out again holds every seal, and only the solve shows it is not the engine's (cause solution_seal). The long form's answer carries holds, true when the answer sent is every byte the engine's, and values_hold beside it, true when every value of it is the engine's answer to its request computed again, whatever its spelling: each number by its 64-bit value, strings, flags and null exactly, keys and their order, the receipt string among them. A copy whose numbers a client wrote again in its own spelling (0.0001 for 1.0e-4, 12 for 12.0) has holds false and values_hold true, and differs_at names the first place its text differs. An answer the engine signed (signature, ML-DSA-87 over its receipt, with issued_at, expires_at and nonce) has its signature checked first, against public_key or else this engine's own key: one that does not hold is cause signature, named (SignatureDoesNotVerify, SignatureExpired, SignatureNonceReplayed, SignatureKeyMismatch, ReceiptDoesNotMatch, SignatureAbsent when public_key is given and there is none), and nothing is computed."

Removed value: -{
-  "type": [
-    "string",
-    "null"
-  ]
-}

Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}

Added value: +{
+  "description": "The base64 of the ML-DSA-87 public key (2,592 bytes) to check the answer's signature with; without it, this engine's own.",
+  "type": "string"
+}

Previous value: -"With solution_seal alone: the solve request as it was sent (the answer's inputs). It is solved again, under a physics permit and the limits of solve, and its seal is compared with solution_seal. Its fields are solve's. Worked example of the short form, as the whole arguments: {\"request\":{\"solver\":\"atom_dft\",\"parameters\":{\"atomic_number\":10}},\"solution_seal\":\"<the solution_seal of its solve answer, 64 lowercase hex digits>\"}."New value: +"With solution_seal alone: the solve request as it was sent (the answer's inputs). It is solved again, under a physics permit and the limits of solve, and its seal is compared with solution_seal. Its fields are solve's. Worked example of the short form, as the whole arguments: {\"request\":{\"solver\":\"atom_dft\",\"parameters\":{\"atomic_number\":10}},\"solution_seal\":\"<the solution_seal of its solve answer, 96 lowercase hex digits>\"}."

Removed value: -{
-  "type": "string"
-}

Added value: +{
+  "type": "string"
+}

Previous value: -[
-  "inputs",
-  "engine_version",
-  "result",
-  "invariants",
-  "field_sha256",
-  "outcome"
-]New value: +[
+  "inputs",
+  "engine_version",
+  "result",
+  "invariants",
+  "field_sha384",
+  "outcome"
+]

Added value: +{
+  "description": "Nonces of signatures already seen: one of them again is SignatureNonceReplayed.",
+  "items": {
+    "pattern": "^[0-9a-f]{64}$",
+    "type": "string"
+  },
+  "type": "array"
+}

Previous value: -"^[0-9a-f]{64}$"New value: +"^[0-9a-f]{96}$"

Previous value: -"^[0-9a-f]{64}$"New value: +"^[0-9a-f]{96}$"

Previous value: -"Either request and run_seal alone, the short form: the run is computed again and its seal compared with run_seal. Or the whole run_trajectory answer sent back as it was returned, without request, the long form: inputs, frames, outcome, steps_landed, reject, run_seal, final_state, final_residual_conservation_error_hex, max_residual_conservation_error_hex and state_digest are then all required, along with the rest of the answer. The trajectory chain, the state digest and the run seal are recomputed from its exact hex values; then its request is computed again under a physics permit and the limits of run_trajectory, and the engine's whole answer to it compared with the answer sent, value by value and then byte for byte, the receipt included, so an answer that holds is every byte the engine's. A seal has no key: an answer whose values were rewritten with its seals worked out again holds every seal, and only the computation shows it is not the engine's. An answer that continues a sealed upstream run (its chain names upstream_run_seal) carries the upstream's seal and not its request, and its long form is refused (AnswerCarriesNoRequest): its chain's answers in order, as links, carry each request, and each link is computed again from the links before it. Or links alone: a chain's answers in order, held as the long form holds one. A design_run answer sent whole is designed again and held the same way. The long form's answer carries holds, true when the answer sent is every byte the engine's, and values_hold beside it, true when every value of it is the engine's answer to its request computed again, whatever its spelling: each number by its 64-bit value, strings, flags and null exactly, keys and their order, the receipt string among them. A copy whose numbers a client wrote again in its own spelling (0.0001 for 1.0e-4, 12 for 12.0) has holds false and values_hold true, and differs_at names the first place its text differs."New value: +"Either request and run_seal alone, the short form: the run is computed again and its seal compared with run_seal. Or the whole run_trajectory answer sent back as it was returned, without request, the long form: inputs, frames, outcome, steps_landed, reject, run_seal, final_state, final_residual_conservation_error_hex, max_residual_conservation_error_hex and state_digest are then all required, along with the rest of the answer. The trajectory chain, the state digest and the run seal are recomputed from its exact hex values; then its request is computed again under a physics permit and the limits of run_trajectory, and the engine's whole answer to it compared with the answer sent, value by value and then byte for byte, the receipt included, so an answer that holds is every byte the engine's. A seal has no key: an answer whose values were rewritten with its seals worked out again holds every seal, and only the computation shows it is not the engine's. An answer that continues a sealed upstream run (its chain names upstream_run_seal) carries the upstream's seal and not its request, and its long form is refused (AnswerCarriesNoRequest): its chain's answers in order, as links, carry each request, and each link is computed again from the links before it. Or links alone: a chain's answers in order, held as the long form holds one. A design_run answer sent whole is designed again and held the same way. The long form's answer carries holds, true when the answer sent is every byte the engine's, and values_hold beside it, true when every value of it is the engine's answer to its request computed again, whatever its spelling: each number by its 64-bit value, strings, flags and null exactly, keys and their order, the receipt string among them. A copy whose numbers a client wrote again in its own spelling (0.0001 for 1.0e-4, 12 for 12.0) has holds false and values_hold true, and differs_at names the first place its text differs. An answer the engine signed (signature, ML-DSA-87 over its receipt, with issued_at, expires_at and nonce) has its signature checked first, against public_key or else this engine's own key: one that does not hold is cause signature, named (SignatureDoesNotVerify, SignatureExpired, SignatureNonceReplayed, SignatureKeyMismatch, ReceiptDoesNotMatch, SignatureAbsent when public_key is given and there is none), and nothing is computed."

Previous value: -"^[0-9a-f]{64}$"New value: +"^[0-9a-f]{96}$"

Added value: +{
+  "description": "The base64 of the ML-DSA-87 public key (2,592 bytes) to check the answer's signature with; without it, this engine's own.",
+  "type": "string"
+}

Previous value: -"With run_seal alone: the run_trajectory request as it was sent, with its readout and its from when it had them (the answer's inputs holds neither; the upstream request in that from goes without a readout, as run_trajectory took it). It is run again, under a physics permit and the limits of run_trajectory, and its seal is compared with run_seal. Its fields are run_trajectory's. Worked example of the short form, as the whole arguments: {\"request\":{\"domain\":\"energy\",\"card\":\"thermal\",\"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},\"run_seal\":\"<the run_seal of its run_trajectory answer, 64 lowercase hex digits>\"}."New value: +"With run_seal alone: the run_trajectory request as it was sent, with its readout and its from when it had them (the answer's inputs holds neither; the upstream request in that from goes without a readout, as run_trajectory took it). It is run again, under a physics permit and the limits of run_trajectory, and its seal is compared with run_seal. Its fields are run_trajectory's. Worked example of the short form, as the whole arguments: {\"request\":{\"domain\":\"energy\",\"card\":\"thermal\",\"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},\"run_seal\":\"<the run_seal of its run_trajectory answer, 96 lowercase hex digits>\"}."

Previous value: -"^[0-9a-f]{64}$"New value: +"^[0-9a-f]{96}$"

Added value: +{
+  "description": "Nonces of signatures already seen: one of them again is SignatureNonceReplayed.",
+  "items": {
+    "pattern": "^[0-9a-f]{64}$",
+    "type": "string"
+  },
+  "type": "array"
+}

Added value: +{
+  "additionalProperties": false,
+  "description": "Optional: a sealed card run handed in through a coupling, as run_trajectory takes it.",
+  "properties": {
+    "coupling": {
+      "type": "string"
+    },
+    "request": {
+      "type": "object"
+    },
+    "run_seal": {
+      "pattern": "^[0-9a-f]{64}$",
+      "type": "string"
+    }
+  },
+  "required": [
+    "request",
+    "run_seal",
+    "coupling"
+  ],
+  "type": "object"
+}

Previous value: -"One run, or one plan of solves, and measurements of one quantity. The answer is the error in numbers, sealed with a hash of the measurements. It holds no verdict. A request holds run or solves, not both."New value: +"One run, or one plan of solves, and measurements of one quantity. The answer is the error in numbers, sealed with a hash of the measurements. It sets no threshold. A request holds run or solves, not both."

Added value: +{
+  "description": "Beside the whole answer of a chained solve: the from solve took (request, run_seal, coupling). The upstream run is computed again and held to its seal, each handed value to it, and the request solved again with it; the answer alone is refused (AnswerCarriesNoRequest).",
+  "type": "object"
+}

Previous value: -"A run_trajectory or solve request as that tool takes it."New value: +"A run_trajectory or solve request as that tool takes it. A search of solves makes no new solve once those made are counted at 20 s (FLIP_MAX_SECONDS), each at the time describe_solver states for one solve of its solver (open_connection), and always makes at least 3, both ends and one value between them: a count, not a clock, so the same request stops at the same solve on any machine. A search of runs is held by its steps (FLIP_MAX_STEPS)."

Previous value: -"A plan of runs on one card (domain, card, plan, store and return, all required) or of solves of one solver (solver and plan). Rows <= 100000, steps in total <= 100000000, stored frames <= 16777216; inline: rows <= 1000, frames <= 10000, an answer counted from the plan <= 40000 characters; solves <= 64. With return \"file\" the answer is the head and the names of the files stored, on a connection started with a directory for them."New value: +"A plan of runs on one card (domain, card, plan, store and return, all required) or of solves of one solver (solver and plan). Rows <= 100000, steps in total <= 100000000, stored frames <= 16777216; inline: an answer counted from the plan <= 40000 characters, which a plan reaches first, a grid on one axis at about 140 summary rows and a list sooner, its head repeating each run's request (a plan of more than 1000 rows is refused before it is counted, as too large to return inline), and frames <= 10000; solves <= 64. With return \"file\" the answer is the head and the names of the files stored, on a connection started with a directory for them."

Previous value: -"Optional: start from a sealed run. request: that run_trajectory request as sent (it may hold its own from); run_seal: its seal; coupling: absent to continue the same card (describe_card says how), or a coupling's name. The upstream is computed again; each carried value must equal its sealed value bit for bit, and a request whose upstream seal or carried value does not hold is refused by name. The run_seal is that of this request without from; chain.chain_seal commits it to the upstream."New value: +"Optional: start from a sealed run. request: that run_trajectory request as sent, less its readout if it had one: a readout is not part of a run's seal, and a request here that carries one is refused (it may hold its own from); run_seal: its seal; coupling: absent to continue the same card (describe_card says how), or a coupling's name. The upstream is computed again; each carried value must equal its sealed value bit for bit, and a request whose upstream seal or carried value does not hold is refused by name. The run_seal is that of this request without from; chain.chain_seal commits it to the upstream."

Previous value: -"With run_seal alone: the run_trajectory request as it was sent, with its readout and its from when it had them (the answer's inputs holds neither). It is run again, under a physics permit and the limits of run_trajectory, and its seal is compared with run_seal. Its fields are run_trajectory's. Worked example of the short form, as the whole arguments: {\"request\":{\"domain\":\"energy\",\"card\":\"thermal\",\"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},\"run_seal\":\"<the run_seal of its run_trajectory answer, 64 lowercase hex digits>\"}."New value: +"With run_seal alone: the run_trajectory request as it was sent, with its readout and its from when it had them (the answer's inputs holds neither; the upstream request in that from goes without a readout, as run_trajectory took it). It is run again, under a physics permit and the limits of run_trajectory, and its seal is compared with run_seal. Its fields are run_trajectory's. Worked example of the short form, as the whole arguments: {\"request\":{\"domain\":\"energy\",\"card\":\"thermal\",\"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},\"run_seal\":\"<the run_seal of its run_trajectory answer, 64 lowercase hex digits>\"}."

Previous value: -"One anchored run. Total steps must be <= 1000000. Recorded frames must be <= 10000. The shape of initial and of each segment's load depends on the pair: describe_card gives it. A run can be refused in two ways, and they come back differently. A request turned away before computing is an error, not a result: its text is one sentence, nothing is sealed, and when the sentence gives the card's name for the refusal the name is in round brackets. A run that starts and is refused part way is a result: outcome is \"refused\", reject holds the name (null when the cause has none), reject_detail holds the sentence, which ends \"The run is sealed to step N. The state at step N+1 was refused and is not sealed.\", and the run is sealed up to that last landed step N: steps_landed is N, the count of steps that landed, so the step that was refused is steps_landed + 1. A run that reaches an end its card declares (the first maximum of power of a reactor burst, a capsule's flown parachute deployment, a mission's last day, the end of a record's clock or track) is not refused: outcome is \"ended\", reject holds the end's name, reject_detail a sentence beginning \"Ended\" that names the end, and the run is sealed up to its last landed step; describe_card lists a card's declared ends under declared_ends. A sentence that begins \"Physical Failure\" says the state asked for or reached is outside the card: past a published bound, a limit of the specimen, or the conservation ledger. A sentence that begins \"Physical Violation\" says the request, or a number in it or computed from it, is not one the engine takes: its shape, a missing or unknown key, the number rule, the step floor or ceiling, a load rule, a size limit, or a value that is not finite. A required key left out is named InputMissing, and a card the engine does not serve UnknownCard. A sentence with no name in round brackets is of a request that is not well formed (a key unknown, a value of the wrong type, a number the number rule refuses, a count or a size past the tool's own limit) or of a value that is not finite: no model stopped, and the request is what is corrected."New value: +"One anchored run. Total steps must be <= 1000000. Recorded frames must be <= 10000. The shape of initial and of each segment's load depends on the pair: describe_card gives it. A run can be refused in two ways, and they come back differently. A request turned away before computing is an error, not a result: its text is one sentence, nothing is sealed, and when the sentence gives the card's name for the refusal the name is in round brackets. A run that starts and is refused part way is a result: outcome is \"refused\", reject holds the name (null when the cause has none), reject_detail holds the sentence, which ends \"The run is sealed to step N. The state at step N+1 was refused and is not sealed.\", and the run is sealed up to that last landed step N: steps_landed is N, the count of steps that landed, so the step that was refused is steps_landed + 1. A run that reaches an end its card declares (the first maximum of power of a reactor burst, a capsule's flown parachute deployment, a crater that stops growing, a cell's runaway once every reactant is consumed) is not refused: outcome is \"ended\", reject holds the end's name, reject_detail a sentence beginning \"Ended\" that names the end, and the run is sealed up to its last landed step; describe_card lists a card's declared ends under declared_ends. A sentence that begins \"Physical Failure\" says the state asked for or reached is outside the card: past a published bound, a limit of the specimen, or the conservation ledger. A sentence that begins \"Physical Violation\" says the request, or a number in it or computed from it, is not one the engine takes: its shape, a missing or unknown key, the number rule, the step floor or ceiling, a load rule, a size limit, or a value that is not finite. A required key left out is named InputMissing, and a card the engine does not serve UnknownCard. A sentence with no name in round brackets is of a request that is not well formed (a key unknown, a value of the wrong type, a number the number rule refuses, a count or a size past the tool's own limit) or of a value that is not finite: no model stopped, and the request is what is corrected."

Added value: +{
+  "additionalProperties": false,
+  "description": "Optional: a commitment the measurements were locked with before this comparison, opened by this request. sha256 is the SHA-256 of these bytes: the line zero-trust-physics/measurement-commitment/v1 and a line break; the sealed form (the text a request's seal is taken over: keys sorted by their bytes, each number x and the 16 hex digits of its 64-bit float, no spaces) of {\"component\": <this request's component, or null>, \"measurements\": <this request's measurements>, \"quantity\": <this request's quantity>}; a line break; and the salt's bytes, its hex decoded. salt is 32 to 128 lowercase hex digits, 16 to 64 bytes, kept back until the comparison so that the data are not found from the sha256 by trying values. The engine makes the digest again from the request before computing: data that do not open it (a value, a step or a row changed, moved, added or dropped, another quantity or another salt) are refused as CommitmentDoesNotMatch, a salt shorter than 16 bytes as CommitmentSaltTooShort, a field of the wrong form as CommitmentMalformed, and sha256 or salt left out as InputMissing; nothing is computed and nothing is sealed. Opened, the comparison runs as it runs without one, validation_seal takes the commitment as a sixth part, and the answer says so in commitment_opened. A commitment shows that the data were not changed after it was made; when it was made is shown by where its sha256 was published before the comparison.",
+  "properties": {
+    "salt": {
+      "description": "The salt the sha256 was made with: 32 to 128 lowercase hex digits, 16 to 64 bytes.",
+      "type": "string"
+    },
+    "sha256": {
+      "description": "The SHA-256 committed, 64 lowercase hex digits.",
+      "pattern": "^[0-9a-f]{64}$",
+      "type": "string"
+    }
+  },
+  "required": [
+    "sha256",
+    "salt"
+  ],
+  "type": "object"
+}

Previous value: -"A plan of solves: the solver, in place of domain and card. It takes no store and no return. A plan of solves is answered inline: a list, {\"kind\":\"list\",\"solves\":[{\"parameters\":{...}}]}, or a grid, {\"kind\":\"grid\",\"base\":{\"parameters\":{...}},\"axes\":[{\"path\":\"parameters.<input>\",\"values\":[...]}]}, of at most 64 solves. Each row is a solve request, solved as solve solves it and carrying the solution_seal solve gives it; a request turned away without a seal, by the rules of a request or by the solver, is an unadmitted row. The rows are sealed under one dataset_seal by the rules of a plan of runs, with solution_seal in the leaf in the place of run_seal, and completed in the counts counts the solves that converged. A summary row has row, set, outcome, reject, solution_seal and every single number of the result in decimals; answer \"full\" gives every solution whole, and is refused when it comes to more than 40000 characters. verify_dataset checks a plan of solves by its request and dataset_seal, and validate_series compares one number of its results with measurements. Worked plan of solves: {\"solver\":\"atom_dft\",\"plan\":{\"kind\":\"list\",\"solves\":[{\"parameters\":{\"atomic_number\":10}}]}}."New value: +"A plan of solves: the solver, in place of domain and card. It takes no store and no return. A plan of solves is answered inline: a list, {\"kind\":\"list\",\"solves\":[{\"parameters\":{...}}]}, or a grid, {\"kind\":\"grid\",\"base\":{\"parameters\":{...}},\"axes\":[{\"path\":\"parameters.<input>\",\"values\":[...]}]}, of at most 64 solves. Each row is a solve request, solved as solve solves it and carrying the solution_seal solve gives it; a request turned away without a seal, by the rules of a request or by the solver, is an unadmitted row. The rows are sealed under one dataset_seal by the rules of a plan of runs, with solution_seal in the leaf in the place of run_seal, and completed in the counts counts the solves that converged. A summary row has row, set, outcome, reject, solution_seal and every single number of the result in decimals; answer \"full\" gives every solution whole, and is refused when it comes to more than 40000 characters. verify_dataset verifies a plan of solves by its request and dataset_seal, and validate_series compares one number of its results with measurements. Worked plan of solves: {\"solver\":\"atom_dft\",\"plan\":{\"kind\":\"list\",\"solves\":[{\"parameters\":{\"atomic_number\":10}}]}}."

Previous value: -"One anchored run. Total steps must be <= 1000000. Recorded frames must be <= 10000. The shape of initial and of each segment's load depends on the pair: describe_card gives it. A run can be refused in two ways, and they come back differently. A request turned away before computing is an error, not a result: its text is one sentence, nothing is sealed, and when the sentence gives the card's name for the refusal the name is in round brackets. A run that starts and is refused part way is a result: outcome is \"refused\", reject holds the name (null when the cause has none), reject_detail holds the sentence, which ends \"The run is sealed to step N. The state at step N+1 was refused and is not sealed.\", and the run is sealed up to that last landed step N: steps_landed is N, the count of steps that landed, so the step that was refused is steps_landed + 1. A run that reaches an end its card declares (the first maximum of power of a reactor burst, a capsule's flown parachute deployment, a mission's last day, the end of a record's clock or track) is not refused: outcome is \"ended\", reject holds the end's name, reject_detail a sentence beginning \"Ended\" that names the end, and the run is sealed up to its last landed step; describe_card lists a card's declared ends under declared_ends. A sentence that begins \"Physical Failure\" says the state asked for or reached is outside the card: past a published bound, a limit of the specimen, or the conservation ledger. A sentence that begins \"Physical Violation\" says the request, or a number in it or computed from it, is not one the engine takes: its shape, a missing or unknown key, the number rule, the step floor or ceiling, a load rule, a size limit, or a value that is not finite. A sentence with no name in round brackets is of a request that is not well formed (a key missing or unknown, a value of the wrong type, a number the number rule refuses, a count or a size past the tool's own limit) or of a value that is not finite: no model stopped, and the request is what is corrected."New value: +"One anchored run. Total steps must be <= 1000000. Recorded frames must be <= 10000. The shape of initial and of each segment's load depends on the pair: describe_card gives it. A run can be refused in two ways, and they come back differently. A request turned away before computing is an error, not a result: its text is one sentence, nothing is sealed, and when the sentence gives the card's name for the refusal the name is in round brackets. A run that starts and is refused part way is a result: outcome is \"refused\", reject holds the name (null when the cause has none), reject_detail holds the sentence, which ends \"The run is sealed to step N. The state at step N+1 was refused and is not sealed.\", and the run is sealed up to that last landed step N: steps_landed is N, the count of steps that landed, so the step that was refused is steps_landed + 1. A run that reaches an end its card declares (the first maximum of power of a reactor burst, a capsule's flown parachute deployment, a mission's last day, the end of a record's clock or track) is not refused: outcome is \"ended\", reject holds the end's name, reject_detail a sentence beginning \"Ended\" that names the end, and the run is sealed up to its last landed step; describe_card lists a card's declared ends under declared_ends. A sentence that begins \"Physical Failure\" says the state asked for or reached is outside the card: past a published bound, a limit of the specimen, or the conservation ledger. A sentence that begins \"Physical Violation\" says the request, or a number in it or computed from it, is not one the engine takes: its shape, a missing or unknown key, the number rule, the step floor or ceiling, a load rule, a size limit, or a value that is not finite. A required key left out is named InputMissing, and a card the engine does not serve UnknownCard. A sentence with no name in round brackets is of a request that is not well formed (a key unknown, a value of the wrong type, a number the number rule refuses, a count or a size past the tool's own limit) or of a value that is not finite: no model stopped, and the request is what is corrected."

Previous value: -"The phase fields of the card at the start of the run, each a number (a vector field is an array of three numbers), and no other key. describe_card gives them, with each unit and bound."New value: +"The phase fields of the card at the start of the run, each a number (a vector field is an array of three numbers), and no other key but signed: an instrument's signature over the rest of initial, under the key \"initial\", by the rule of a segment's signed. describe_card gives the fields, with each unit and bound."

Added value: +"A segment may carry signed beside its load: an instrument's signature over the load. signed holds alg \"ed25519\"; key, the instrument's public key as 64 hex digits, its identity; instrument, the name it gives itself, a label of at most 200 characters; time, its clock, RFC 3339 in UTC ending in Z; seq, its reading counter, below 2^53; prev, the SHA-256 of its previous reading's signed text, or null; challenge, hex the relying party chose, or null; and sig, the signature as 128 hex digits. The instrument signs the bytes \"zero-trust-physics/signed-reading/v1\" and a line break, then the sealed form (the text a request's seal is taken over: keys sorted by their bytes, each number x and the 16 hex digits of its 64-bit float, no spaces) of the object of alg, key, instrument, time, seq, prev and challenge with the reading under its place's key: \"load\" for a segment's load, \"initial\", \"parameters\" or \"measurement\" for the object it sits in, without signed. Ed25519 as RFC 8032 section 5.1.7, strict: the key and R canonical points of more than small order, S below the group order, the cofactorless equation. It is verified before computing, every field required and none filled in: a signature that does not verify is refused as LoadSignatureDoesNotVerify, a field of the wrong form as LoadSignatureMalformed, an alg other than \"ed25519\" as LoadSignatureAlgorithmNotServed, and a plan or search that would set a signed value as SignedLoadReplaced. The seal covers the signature, since it covers the request. A signature shows that the holder of the key stated the reading; whether the key is a real instrument's is the verifier's list. Every run answer carries load_source: for a run with no signed load, the count of segments, none signed, and a sentence that each load is the number the request states; for a signed run, how many loads are signed, whether initial is, whether each key's readings form one unbroken stream (prev and seq), and for each key its fingerprint, the name it gives itself, its places, times, seq and challenges. It is outside the run seal, follows from inputs, which the seal covers, and is covered by the receipt."

Added value: +{
+  "additionalProperties": false,
+  "description": "An instrument's Ed25519 signature over this reading, by the rule run_trajectory's input schema gives at segments.",
+  "properties": {
+    "alg": {
+      "enum": [
+        "ed25519"
+      ],
+      "type": "string"
+    },
+    "challenge": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "instrument": {
+      "maxLength": 200,
+      "minLength": 1,
+      "type": "string"
+    },
+    "key": {
+      "pattern": "^[0-9a-f]{64}$",
+      "type": "string"
+    },
+    "prev": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "seq": {
+      "maximum": 9007199254740991,
+      "minimum": 0,
+      "type": "integer"
+    },
+    "sig": {
+      "pattern": "^[0-9a-f]{128}$",
+      "type": "string"
+    },
+    "time": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "alg",
+    "key",
+    "instrument",
+    "time",
+    "seq",
+    "prev",
+    "challenge",
+    "sig"
+  ],
+  "type": "object"
+}

Previous value: -"The inputs of the solver named in 'solver', each a number, a whole number, a word, a flag or an array as describe_solver gives it, and no other key. Every number of a solve request must be a finite, normal 64-bit number or zero, and a number written as non-zero must not read as zero. This rule is the one every card's request follows, and it stands beside each input's range and refuses some values inside it: a subnormal such as 5e-324 is refused wherever zero and larger numbers are accepted. A solution has no frame, so the card's rule that a number fit a 32-bit frame slot does not apply."New value: +"The inputs of the solver named in 'solver', each a number, a whole number, a word, a flag or an array as describe_solver gives it, and no other key but signed. Every number of a solve request must be a finite, normal 64-bit number or zero, and a number written as non-zero must not read as zero. This rule is the one every card's request follows, and it stands beside each input's range and refuses some values inside it: a subnormal such as 5e-324 is refused wherever zero and larger numbers are accepted. A solution has no frame, so the card's rule that a number fit a 32-bit frame slot does not apply. A required input left out is refused as InputMissing, and an input given with a choice it does not go with as InputNotWithChoice, each in a sentence that names the input, and a solver the engine does not serve as UnknownSolver; nothing is filled in. parameters may also carry signed, an instrument's signature over the other parameters under the key \"parameters\", by the rule run_trajectory's input schema gives at segments; it is verified before solving, the solver takes the other parameters, and the answer then carries load_source, naming the key. A solve answer without load_source holds no signed parameter."

Added value: +{
+  "additionalProperties": false,
+  "description": "An instrument's Ed25519 signature over this reading, by the rule run_trajectory's input schema gives at segments.",
+  "properties": {
+    "alg": {
+      "enum": [
+        "ed25519"
+      ],
+      "type": "string"
+    },
+    "challenge": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "instrument": {
+      "maxLength": 200,
+      "minLength": 1,
+      "type": "string"
+    },
+    "key": {
+      "pattern": "^[0-9a-f]{64}$",
+      "type": "string"
+    },
+    "prev": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "seq": {
+      "maximum": 9007199254740991,
+      "minimum": 0,
+      "type": "integer"
+    },
+    "sig": {
+      "pattern": "^[0-9a-f]{128}$",
+      "type": "string"
+    },
+    "time": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "alg",
+    "key",
+    "instrument",
+    "time",
+    "seq",
+    "prev",
+    "challenge",
+    "sig"
+  ],
+  "type": "object"
+}

Previous value: -"The phase fields of the card at the start of the run, each a number (a vector field is an array of three numbers), and no other key. describe_card gives them, with each unit and bound."New value: +"The phase fields of the card at the start of the run, each a number (a vector field is an array of three numbers), and no other key but signed: an instrument's signature over the rest of initial, under the key \"initial\", by the rule of a segment's signed. describe_card gives the fields, with each unit and bound."

Added value: +{
+  "additionalProperties": false,
+  "description": "An instrument's Ed25519 signature over this reading, by the rule run_trajectory's input schema gives at segments.",
+  "properties": {
+    "alg": {
+      "enum": [
+        "ed25519"
+      ],
+      "type": "string"
+    },
+    "challenge": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "instrument": {
+      "maxLength": 200,
+      "minLength": 1,
+      "type": "string"
+    },
+    "key": {
+      "pattern": "^[0-9a-f]{64}$",
+      "type": "string"
+    },
+    "prev": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "seq": {
+      "maximum": 9007199254740991,
+      "minimum": 0,
+      "type": "integer"
+    },
+    "sig": {
+      "pattern": "^[0-9a-f]{128}$",
+      "type": "string"
+    },
+    "time": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "alg",
+    "key",
+    "instrument",
+    "time",
+    "seq",
+    "prev",
+    "challenge",
+    "sig"
+  ],
+  "type": "object"
+}

Previous value: -"One of three forms. request and dataset_seal, the short form: the plan is run again and its seal compared. The three parts a run_dataset answer carries (head, rows and frames_hex, all three required together): the rows, the root and the seal are recomputed with no physics run. dataset_seal alone: the stored dataset of that seal is checked with no physics run."New value: +"One of three forms. request and dataset_seal, the short form: the plan is run again and its seal compared. The three parts a full run_dataset answer carries (head, rows and frames_hex, all three required together, as they came), the long form: the rows, the root and the seal are recomputed from their exact values, then the head's plan is run again under the permits and the limits of run_dataset and the engine's full answer to it compared with the parts sent, value by value and then byte for byte, so a dataset that holds is every byte the engine's. dataset_seal alone: the stored dataset of that seal, its seals recomputed from its files and its plan run again into a folder of its own, the stored files compared with that run's byte for byte. The long form's answer carries holds, true when the answer sent is every byte the engine's, and values_hold beside it, true when every value of it is the engine's answer to its request computed again, whatever its spelling: each number by its 64-bit value, strings, flags and null exactly, keys and their order, the receipt string among them. A copy whose numbers a client wrote again in its own spelling (0.0001 for 1.0e-4, 12 for 12.0) has holds false and values_hold true, and differs_at names the first place its text differs."

Previous value: -"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 checked with its request, or by its head, rows and frames_hex."New value: +"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."

Previous value: -"The text of one response from verify_step, run_trajectory or solve, or the head of a dataset written as its JSON text."New value: +"The text of one response from compute_step, run_trajectory or solve, or the head of a dataset written as its JSON text."

Previous value: -"Either request and solution_seal alone, the short form: the request is solved again and its seal compared with solution_seal. Or the whole solve answer sent back, without request: inputs, engine_version, outcome, iterations, reject, result, invariants, field_sha256, seal_parts and solution_seal are then all required, the solution seal is recomputed and the part that fails is named, with no physics run."New value: +"Either request and solution_seal alone, the short form: the request is solved again and its seal compared with solution_seal. Or the whole solve answer sent back as it came, without request, the long form: inputs, engine_version, outcome, iterations, reject, result, invariants, field_sha256, seal_parts and solution_seal are then all required. The solution seal is recomputed from its exact hex values and the part that fails is named; then its request is solved again under a physics permit and the limits of solve, and the engine's whole answer to it compared with the answer sent, value by value and then byte for byte, the receipt included, so an answer that holds is every byte the engine's. A seal has no key: an answer whose values were rewritten with its seal parts, seal and receipt worked out again holds every seal, and only the solve shows it is not the engine's (cause solution_seal). The long form's answer carries holds, true when the answer sent is every byte the engine's, and values_hold beside it, true when every value of it is the engine's answer to its request computed again, whatever its spelling: each number by its 64-bit value, strings, flags and null exactly, keys and their order, the receipt string among them. A copy whose numbers a client wrote again in its own spelling (0.0001 for 1.0e-4, 12 for 12.0) has holds false and values_hold true, and differs_at names the first place its text differs."

Previous value: -"The inputs of the solve answer, sent back as returned: the request that was solved. It is hashed, not solved."New value: +"The inputs of the solve answer, sent back as returned: the request that was solved. It is hashed, and solved again under a physics permit and the limits of solve."

Previous value: -"The step's inputs: the card's phase fields, its load fields and dt_s, each a number (a vector field is an array of three numbers), and no other key. describe_card gives the fields of the pair, with each unit and bound."New value: +"The step's inputs: the card's phase fields, its load fields and dt_s, each a number (a vector field is an array of three numbers), and no other key. describe_card gives the fields of the pair, with each unit and bound. A required field left out is refused as InputMissing, in a sentence that names the field, and a card the engine does not serve as UnknownCard; nothing is filled in."

Previous value: -"Either request and run_seal alone, the short form: the run is computed again and its seal compared with run_seal. Or the whole run_trajectory answer sent back as it was returned, without request: inputs, frames, outcome, steps_landed, reject, run_seal, final_state, final_residual_conservation_error_hex, max_residual_conservation_error_hex and state_digest are then all required, and the trajectory chain, the state digest and the run seal are recomputed with no physics run."New value: +"Either request and run_seal alone, the short form: the run is computed again and its seal compared with run_seal. Or the whole run_trajectory answer sent back as it was returned, without request, the long form: inputs, frames, outcome, steps_landed, reject, run_seal, final_state, final_residual_conservation_error_hex, max_residual_conservation_error_hex and state_digest are then all required, along with the rest of the answer. The trajectory chain, the state digest and the run seal are recomputed from its exact hex values; then its request is computed again under a physics permit and the limits of run_trajectory, and the engine's whole answer to it compared with the answer sent, value by value and then byte for byte, the receipt included, so an answer that holds is every byte the engine's. A seal has no key: an answer whose values were rewritten with its seals worked out again holds every seal, and only the computation shows it is not the engine's. An answer that continues a sealed upstream run (its chain names upstream_run_seal) carries the upstream's seal and not its request, and its long form is refused (AnswerCarriesNoRequest): its chain's answers in order, as links, carry each request, and each link is computed again from the links before it. Or links alone: a chain's answers in order, held as the long form holds one. A design_run answer sent whole is designed again and held the same way. The long form's answer carries holds, true when the answer sent is every byte the engine's, and values_hold beside it, true when every value of it is the engine's answer to its request computed again, whatever its spelling: each number by its 64-bit value, strings, flags and null exactly, keys and their order, the receipt string among them. A copy whose numbers a client wrote again in its own spelling (0.0001 for 1.0e-4, 12 for 12.0) has holds false and values_hold true, and differs_at names the first place its text differs."

Previous value: -"The inputs of the run_trajectory answer, sent back as returned: the request that was run. It is hashed, not run. A card's fields, units and bounds are in describe_card."New value: +"The inputs of the run_trajectory answer, sent back as returned: the request that was run. It is hashed, and run again, with the answer's readout when it has one, under a physics permit and the limits of run_trajectory. A card's fields, units and bounds are in describe_card."

Previous value: -"With card: a card, by the name find_model or list_cards gives. When find_model has given it, no list need be read."New value: +"With card: a card, by the name find_model or list_cards gives; the two give the same names."

Added value: +"Optional. {\"quantity\": <a published quantity>, \"value\": <number>}: the span is halved to where that quantity of the final state (of a solve: of result) crosses the value. {\"quantity\": <a flag>}: to where a true-or-false value of it turns."

Previous value: -"The place of the one number to vary."New value: +"The place of the one number to vary: \"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."

Previous value: -"A plan of runs on one card (domain, card, plan, store and return, all required) or of solves of one solver (solver and plan). Rows <= 100000, steps in total <= 100000000, stored frames <= 16777216; inline: rows <= 1000, frames <= 10000, an answer counted from the plan <= 40000 characters; solves <= 64. With return \"file\" the answer is the head and the names of the files the gateway stored, and the gateway must have been started with a directory for them."New value: +"A plan of runs on one card (domain, card, plan, store and return, all required) or of solves of one solver (solver and plan). Rows <= 100000, steps in total <= 100000000, stored frames <= 16777216; inline: rows <= 1000, frames <= 10000, an answer counted from the plan <= 40000 characters; solves <= 64. With return \"file\" the answer is the head and the names of the files stored, on a connection started with a directory for them."

Previous value: -"Leave out, or \"summary\", for the head and one short summary row per row: the values it sets, outcome, steps landed, refusal name and seal; \"states\" adds each run's final state in decimals; \"full\" gives every row whole. With return \"file\" the answer is the head and the names of the files whatever this says. Not part of the sealed request."New value: +"Leave out, or \"summary\", for the head and one short summary row per row: the values it sets, outcome, steps landed, refusal name and seal; \"states\" adds each run's final state in decimals; \"full\" gives every row whole. With return \"file\" the answer is the head and the names of the files whatever this says. Not part of the sealed request. The head and the dataset_seal are the same in all three forms. A summary row holds row, set (the values a grid's or a sample's row sets), outcome, steps_landed, reject and run_seal; the quantities of one row are read by sending its request to run_trajectory with a readout. An ended row is a run that stopped at an end its card declares: it has a run seal, the end's reject name in reject and the sentence naming the end in reject_detail. A refused row is a run the card refused part way: it has a run seal, the refusal's name in reject and its sentence in reject_detail. An unadmitted row is a request turned away before computing: it has no run seal, and its sentence, with the refusal's name in round brackets when the sentence gives one, is its reject_detail; its summary row gives that name in reject. What a sentence that begins \"Physical Failure\" or \"Physical Violation\" means is in the description of run_trajectory. An inline answer is counted from the plan before anything runs, and one above 40000 characters is refused with what to change: a summary row counts 220 characters and the values it sets; with states, each number of the final state adds its name and 28 characters (84 for a 3-vector, 9 for a flag); a whole row counts its own request and 1900 characters, and for each number twice its name and 60 characters (150 for a 3-vector, 9 for a flag); store \"frames\" adds 128 characters for each recorded state to a full answer; the head repeats the request."

Added value: +"A path names one number: initial.<field>, dt_s, or segments[0].load.<field>, with the segment's number in square brackets and [0], [1] or [2] after a 3-vector field for one of its components. steps and record_every are not paths and cannot vary: every row of a grid or a sample takes them from the base run. A value an axis or a draw sets replaces the base's value of that field, and the answer's base_replaced names each field replaced; a 3-vector the base sets whole is replaced only when the paths set all three of its components. Two paths may not set one number. Each row of a grid is held to the card's bounds alone, as each run of a list is: a value outside a bound makes that row unadmitted and the other rows run. A sample's interval or choice outside a bound refuses the plan. One worked plan of each kind, each a whole request: list: {\"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\"} grid: {\"domain\":\"energy\",\"card\":\"thermal\",\"plan\":{\"kind\":\"grid\",\"base\":{\"initial\":{},\"dt_s\":1.0,\"segments\":[{\"steps\":60,\"load\":{\"ambient_k\":293.15}}],\"record_every\":60},\"axes\":[{\"path\":\"initial.temperature_k\",\"values\":[283.15,293.15]},{\"path\":\"segments[0].load.heat_power_w\",\"values\":[0.0,5.0,10.0]}]},\"store\":\"none\",\"return\":\"inline\"} sample: {\"domain\":\"energy\",\"card\":\"thermal\",\"plan\":{\"kind\":\"sample\",\"base\":{\"initial\":{},\"dt_s\":1.0,\"segments\":[{\"steps\":60,\"load\":{\"ambient_k\":293.15}}],\"record_every\":60},\"rows\":4,\"generator\":\"splitmix64_counter_v1\",\"seed_hex\":\"0000000000000001\",\"draws\":[{\"path\":\"initial.temperature_k\",\"choice\":[283.15,293.15]},{\"path\":\"segments[0].load.heat_power_w\",\"uniform\":{\"low\":0.0,\"high\":10.0}}]},\"store\":\"none\",\"return\":\"inline\"}."

Previous value: -"A plan of solves: the solver, in place of domain and card. It takes no store and no return."New value: +"A plan of solves: the solver, in place of domain and card. It takes no store and no return. A plan of solves is answered inline: a list, {\"kind\":\"list\",\"solves\":[{\"parameters\":{...}}]}, or a grid, {\"kind\":\"grid\",\"base\":{\"parameters\":{...}},\"axes\":[{\"path\":\"parameters.<input>\",\"values\":[...]}]}, of at most 64 solves. Each row is a solve request, solved as solve solves it and carrying the solution_seal solve gives it; a request turned away without a seal, by the rules of a request or by the solver, is an unadmitted row. The rows are sealed under one dataset_seal by the rules of a plan of runs, with solution_seal in the leaf in the place of run_seal, and completed in the counts counts the solves that converged. A summary row has row, set, outcome, reject, solution_seal and every single number of the result in decimals; answer \"full\" gives every solution whole, and is refused when it comes to more than 40000 characters. verify_dataset checks a plan of solves by its request and dataset_seal, and validate_series compares one number of its results with measurements. Worked plan of solves: {\"solver\":\"atom_dft\",\"plan\":{\"kind\":\"list\",\"solves\":[{\"parameters\":{\"atomic_number\":10}}]}}."

Previous value: -"One anchored run. Total steps must be <= 1000000. Recorded frames must be <= 10000. The shape of initial and of each segment's load depends on the pair: read describe_card for it."New value: +"One anchored run. Total steps must be <= 1000000. Recorded frames must be <= 10000. The shape of initial and of each segment's load depends on the pair: describe_card gives it. A run can be refused in two ways, and they come back differently. A request turned away before computing is an error, not a result: its text is one sentence, nothing is sealed, and when the sentence gives the card's name for the refusal the name is in round brackets. A run that starts and is refused part way is a result: outcome is \"refused\", reject holds the name (null when the cause has none), reject_detail holds the sentence, which ends \"The run is sealed to step N. The state at step N+1 was refused and is not sealed.\", and the run is sealed up to that last landed step N: steps_landed is N, the count of steps that landed, so the step that was refused is steps_landed + 1. A run that reaches an end its card declares (the first maximum of power of a reactor burst, a capsule's flown parachute deployment, a mission's last day, the end of a record's clock or track) is not refused: outcome is \"ended\", reject holds the end's name, reject_detail a sentence beginning \"Ended\" that names the end, and the run is sealed up to its last landed step; describe_card lists a card's declared ends under declared_ends. A sentence that begins \"Physical Failure\" says the state asked for or reached is outside the card: past a published bound, a limit of the specimen, or the conservation ledger. A sentence that begins \"Physical Violation\" says the request, or a number in it or computed from it, is not one the engine takes: its shape, a missing or unknown key, the number rule, the step floor or ceiling, a load rule, a size limit, or a value that is not finite. A sentence with no name in round brackets is of a request that is not well formed (a key missing or unknown, a value of the wrong type, a number the number rule refuses, a count or a size past the tool's own limit) or of a value that is not finite: no model stopped, and the request is what is corrected."

Previous value: -"Optional: start from a sealed run. request: that run_trajectory request as sent (it may hold its own from); run_seal: its seal; coupling: absent to continue the same card (describe_card says how), or a coupling's name. The upstream is computed again; each carried value must equal its sealed value bit for bit. The run_seal is that of this request without from; chain.chain_seal commits it to the upstream."New value: +"Optional: start from a sealed run. request: that run_trajectory request as sent (it may hold its own from); run_seal: its seal; coupling: absent to continue the same card (describe_card says how), or a coupling's name. The upstream is computed again; each carried value must equal its sealed value bit for bit, and a request whose upstream seal or carried value does not hold is refused by name. The run_seal is that of this request without from; chain.chain_seal commits it to the upstream."

Previous value: -"Optional. The named quantities in decimals at the recorded steps, each one's minimum and maximum over every landed step with its step, its time and every other listed quantity at that step (at_minimum, at_maximum), and first_past when asked. Not part of the sealed request: the run_seal is that of the same run without it."New value: +"Optional. Reads quantities without the frames: {\"quantities\": [names the card publishes], \"first_past\": {\"quantity\": <one of them>, \"above\" or \"below\": <level>}}. The answer then holds the named quantities in decimals at the recorded steps, each one's minimum and maximum over every landed step with its step, its time (the step times dt_s) and every other listed quantity at that step (at_minimum, at_maximum), and first_past when asked. With record_every equal to the steps, one state is recorded and the readout gives the extremes of every step. Not part of the sealed request: the run_seal is that of the same run without it, and the receipt covers it."

Added value: +"A state is recorded at each multiple of record_every and at the last landed step. The size of the answer follows from the request: about 230 characters for each recorded state, plus the request as it was sent, plus up to 8000 characters for the final state and the seals. So 10,000 steps with record_every 1 answer with about 2.3 million characters, and the same steps with record_every 10000 with one recorded state. What keeps it small: a larger record_every; the final state is returned in full whatever is recorded."

Previous value: -"One sealed solution. The same request as POST /solve."New value: +"One sealed solution."

Previous value: -"One run, or one plan of solves, and measurements of one quantity. The answer is the error in numbers, sealed with a hash of the measurements. It holds no verdict. Send run, or solves, not both."New value: +"One run, or one plan of solves, and measurements of one quantity. The answer is the error in numbers, sealed with a hash of the measurements. It holds no verdict. A request holds run or solves, not both."

Previous value: -"At most 10000. A measurement is compared with the state after landed step k. There is no interpolation and no time matching: map your sample times to steps."New value: +"At most 10000. A measurement is compared with the state after landed step k. There is no interpolation and no time matching: a measurement is placed by its step, its time since the start divided by dt_s."

Previous value: -"One anchored run. Total steps must be <= 1000000. Recorded frames must be <= 10000. The shape of initial and of each segment's load depends on the pair: read describe_card for it."New value: +"One anchored run. Total steps must be <= 1000000. Recorded frames must be <= 10000. The shape of initial and of each segment's load depends on the pair: describe_card gives it."

Previous value: -"Send one of three forms. request and dataset_seal, the short form: the plan is run again and its seal compared. The three parts a run_dataset answer carries (head, rows and frames_hex, all three required together): the rows, the root and the seal are recomputed with no physics run. dataset_seal alone: the stored dataset of that seal is checked with no physics run."New value: +"One of three forms. request and dataset_seal, the short form: the plan is run again and its seal compared. The three parts a run_dataset answer carries (head, rows and frames_hex, all three required together): the rows, the root and the seal are recomputed with no physics run. dataset_seal alone: the stored dataset of that seal is checked with no physics run."

Previous value: -"With request: the dataset_seal of the run_dataset answer, compared with the seal the plan runs to. Alone: the seal of a dataset the gateway stored in files (return \"file\"); the gateway reads its own folder of that name. A dataset returned in the answer is not stored: send it with its request, or send its head, rows and frames_hex."New value: +"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 checked with its request, or by its head, rows and frames_hex."

Previous value: -"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."New value: +"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, 64 lowercase hex digits>\"}."

Previous value: -"With solution_seal alone: the solve request as it was sent (the answer's inputs). It is solved again, under a physics permit and the limits of solve, and its seal is compared with solution_seal. Its fields are solve's."New value: +"With solution_seal alone: the solve request as it was sent (the answer's inputs). It is solved again, under a physics permit and the limits of solve, and its seal is compared with solution_seal. Its fields are solve's. Worked example of the short form, as the whole arguments: {\"request\":{\"solver\":\"atom_dft\",\"parameters\":{\"atomic_number\":10}},\"solution_seal\":\"<the solution_seal of its solve answer, 64 lowercase hex digits>\"}."

Previous value: -"One anchored step. The same request as POST /verify_physics. The shape of parameters depends on the pair: read describe_card for it."New value: +"One anchored step. The shape of parameters depends on the pair: describe_card gives it."

Previous value: -"With run_seal alone: the run_trajectory request as it was sent, with its readout and its from when it had them (the answer's inputs holds neither). It is run again, under a physics permit and the limits of run_trajectory, and its seal is compared with run_seal. Its fields are run_trajectory's."New value: +"With run_seal alone: the run_trajectory request as it was sent, with its readout and its from when it had them (the answer's inputs holds neither). It is run again, under a physics permit and the limits of run_trajectory, and its seal is compared with run_seal. Its fields are run_trajectory's. Worked example of the short form, as the whole arguments: {\"request\":{\"domain\":\"energy\",\"card\":\"thermal\",\"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},\"run_seal\":\"<the run_seal of its run_trajectory answer, 64 lowercase hex digits>\"}."

Added value: +{
+  "description": "Leave this key out, or \"full\", for the whole description; \"short\" for a page that is enough to write a first request.",
+  "enum": [
+    "short",
+    "full"
+  ],
+  "type": "string"
+}

Added value: +{
+  "description": "Leave this key out, or \"full\", for the whole description; \"short\" for a page that is enough to write a first request.",
+  "enum": [
+    "short",
+    "full"
+  ],
+  "type": "string"
+}

Previous value: -"With run_seal alone: the run_trajectory request as it was sent (the answer's inputs). It is run again, under a physics permit and the limits of run_trajectory, and its seal is compared with run_seal. Its fields are run_trajectory's."New value: +"With run_seal alone: the run_trajectory request as it was sent, with its readout and its from when it had them (the answer's inputs holds neither). It is run again, under a physics permit and the limits of run_trajectory, and its seal is compared with run_seal. Its fields are run_trajectory's."