RAND.NV

PROBE ONLY (expected: null): A RANDOM DRAW HAS NO EXPECTED VALUE. LibreOffice's help says "Returns a non-volatile random number between 0 and 1." and its example is this exact formula: "=RAND.NV() ... returns a non-volatile random number between 0 and 1." The four pinned builds each returned a different number, as they should; those four values are recorded in the results files and none of them is a claim about any other run. What the case does establish is that the name resolves and the call evaluates without error on 24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3, which is the whole of the support question for a function like this. NON-VOLATILITY IS REAL BUT THIS TRANSPORT CANNOT SEE IT, AND THAT IS ITSELF A FINDING. The help defines the property as "This function produces a non-volatile random number on input. A non-volatile function is not recalculated at new input events. The function does not recalculate when pressing F9, except when the cursor is on the cell containing the function or using the Recalculate Hard command (Shift+Ctrl+F9). The function is recalculated when opening the file." -- and the last of those sentences is the obstacle: this harness's only way to make an engine compute anything is to OPEN the file (`soffice --headless --convert-to xlsx` over a workbook openpyxl wrote with no cached values). Every observation this corpus can make is therefore taken at exactly the moment the documentation says a recalculation happens, so a changed value between two runs would prove nothing and an unchanged one would prove less. The plan of record hoped to assert non-volatility here; the documentation itself rules the measurement out, and saying so is more useful than a test that could not fail. NONDETERMINISM CLASS, PER THE COPILOT PRECEDENT. The corpus records a probe (expected: null) whenever the documented behaviour depends on something the harness cannot fix: a service (COPILOT, DETECTLANGUAGE, TRANSLATE), a live market (STOCKHISTORY), an external server (RTD), a network fetch or an authorization (batch J's Google nine). The two .NV functions are the fourth class -- a pseudo-random draw -- and CURRENT is the fifth: a value defined by its own POSITION inside the formula that encloses it. In every class the note says which dependency makes the value unassertable, and the verdict is carried by whether the call evaluates at all. STORAGE FORM, ESTABLISHED EMPIRICALLY BEFORE THIS FILE WAS RUN. A LibreOffice-only function has no OOXML name of its own -- the .xlsx format was frozen on Excel's function set -- so LibreOffice invents one, and this harness must write exactly the token LibreOffice's own filter reads or a fully implemented function is recorded as #NAME? and published as unsupported. All NINE candidate spellings (plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE., _xlfn.ORG.OPENOFFICE., ORG.LIBREOFFICE., _xlfn.ORG.LIBREOFFICE., _xlfn.COM.MICROSOFT. and COM.SUN.STAR.SHEET.ADDIN.ANALYSIS.) were written into a workbook with openpyxl (which caches no value, so the engine must evaluate from scratch) and round-tripped through `soffice --headless --convert-to xlsx` on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3); the same round trip also reports the EXPORT direction, because the converted file carries whichever token LibreOffice itself chose to write. Exactly ONE spelling works: _xlfn.ORG.LIBREOFFICE.RAND.NV evaluates on all four builds and the other eight are #NAME? on all four, including the bare name -- so a workbook written with '=RAND.NV()' verbatim would have published a false 'unsupported' verdict. Every build writes the same token back out, and the help's Technical information block agrees: "The name space is" ORG.LIBREOFFICE.RAND.NV. The same block dates the function -- "This function is available since LibreOffice 7.0." -- which is older than all four builds the corpus runs, so no version boundary is expected or found here. The token recorded for this function in harness/xlfn_map.py is _xlfn.ORG.LIBREOFFICE.RAND.NV. BATCH PROVENANCE (batch J, group C3 of sheets-lo-only-plan.md -- LibreOffice-only and either nondeterministic or context-bound; the final batch of the completeness push). This function has x == false AND g == false in docs/data/compat.json: NEITHER Microsoft NOR Google documents it, so this corpus makes no claim about either of those engines, nothing here is measured against their documentation, and the Excel column on the published page reads 'n/a (not an Excel function)' rather than a verdict. The authority is LibreOffice's own help, cited by full URL, by the date it was read (2026-08-31), and by the help version the page serves -- the URLs in this file are pinned to /25.8/ rather than /latest/ so the citation still means this text after the help site rolls forward, and /25.8/ is the help for the newest of the four engine builds the corpus executes. GOOGLE SHEETS: this batch builds the Sheets chunk whose ingest will record presence or absence in that engine. Until that ingest lands the Sheets column on the published page reads 'Not yet' and nothing in this file claims anything about it. (Stated positively on purpose -- scripts/check_honesty.py bans the blanket negative shape of that sentence, and the guard is worth keeping blunt.) LibreOffice's Mathematical-functions help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060106.html.

THE STRUCTURAL PROPERTY, MEASURED RATHER THAN ASSERTED. The only thing LibreOffice's help fixes about the value is its range -- "Returns a non-volatile random number between 0 and 1." -- so that, and nothing else, is what this case exercises: two independent draws inside one formula, each tested against both ends. What every build returned is recorded in this file's results entry. A PRECISION THE PAGE DOES NOT GIVE, SO THIS FILE DOES NOT EITHER: the help says "between 0 and 1" with NO inclusive/exclusive qualifier anywhere on the page, and its keyword index repeats the same unqualified phrase. This case therefore uses the INCLUSIVE reading (>=0 and <=1), which is the weaker of the two and is entailed by either; a test written as <1 would be asserting a boundary the documentation never states. WHY expected IS null EVEN THOUGH THIS PARTICULAR FORMULA LOOKS DETERMINISTIC. Every case in batch J is a probe by construction: the batch's whole subject is calls whose VALUE no engine can be held to, and mixing asserted and unasserted cases inside one such function would let a reader take the function's pass/fail count as a statement about the random draw itself. The structural property is therefore stated here and measured on all four builds rather than encoded as an expected value; what the run recorded is in this file's results entry, and the case's published verdict is 'Ran OK' -- it evaluated, without error, on every build. LibreOffice's Mathematical-functions help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060106.html.

PROBE ONLY (expected: null): A RANDOM DRAW HAS NO EXPECTED VALUE. LibreOffice's help says "Returns a non-volatile random number between 0 and 1." and its example is this exact formula: "=RAND.NV() ... returns a non-volatile random number between 0 and 1." The four pinned builds each returned a different number, as they should; those four values are recorded in the results files and none of them is a claim about any other run. What the case does establish is that the name resolves and the call evaluates without error on 24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3, which is the whole of the support question for a function like this. NON-VOLATILITY IS REAL BUT THIS TRANSPORT CANNOT SEE IT, AND THAT IS ITSELF A FINDING. The help defines the property as "This function produces a non-volatile random number on input. A non-volatile function is not recalculated at new input events. The function does not recalculate when pressing F9, except when the cursor is on the cell containing the function or using the Recalculate Hard command (Shift+Ctrl+F9). The function is recalculated when opening the file." -- and the last of those sentences is the obstacle: this harness's only way to make an engine compute anything is to OPEN the file (`soffice --headless --convert-to xlsx` over a workbook openpyxl wrote with no cached values). Every observation this corpus can make is therefore taken at exactly the moment the documentation says a recalculation happens, so a changed value between two runs would prove nothing and an unchanged one would prove less. The plan of record hoped to assert non-volatility here; the documentation itself rules the measurement out, and saying so is more useful than a test that could not fail. NONDETERMINISM CLASS, PER THE COPILOT PRECEDENT. The corpus records a probe (expected: null) whenever the documented behaviour depends on something the harness cannot fix: a service (COPILOT, DETECTLANGUAGE, TRANSLATE), a live market (STOCKHISTORY), an external server (RTD), a network fetch or an authorization (batch J's Google nine). The two .NV functions are the fourth class -- a pseudo-random draw -- and CURRENT is the fifth: a value defined by its own POSITION inside the formula that encloses it. In every class the note says which dependency makes the value unassertable, and the verdict is carried by whether the call evaluates at all. STORAGE FORM, ESTABLISHED EMPIRICALLY BEFORE THIS FILE WAS RUN. A LibreOffice-only function has no OOXML name of its own -- the .xlsx format was frozen on Excel's function set -- so LibreOffice invents one, and this harness must write exactly the token LibreOffice's own filter reads or a fully implemented function is recorded as #NAME? and published as unsupported. All NINE candidate spellings (plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE., _xlfn.ORG.OPENOFFICE., ORG.LIBREOFFICE., _xlfn.ORG.LIBREOFFICE., _xlfn.COM.MICROSOFT. and COM.SUN.STAR.SHEET.ADDIN.ANALYSIS.) were written into a workbook with openpyxl (which caches no value, so the engine must evaluate from scratch) and round-tripped through `soffice --headless --convert-to xlsx` on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3); the same round trip also reports the EXPORT direction, because the converted file carries whichever token LibreOffice itself chose to write. Exactly ONE spelling works: _xlfn.ORG.LIBREOFFICE.RAND.NV evaluates on all four builds and the other eight are #NAME? on all four, including the bare name -- so a workbook written with '=RAND.NV()' verbatim would have published a false 'unsupported' verdict. Every build writes the same token back out, and the help's Technical information block agrees: "The name space is" ORG.LIBREOFFICE.RAND.NV. The same block dates the function -- "This function is available since LibreOffice 7.0." -- which is older than all four builds the corpus runs, so no version boundary is expected or found here. The token recorded for this function in harness/xlfn_map.py is _xlfn.ORG.LIBREOFFICE.RAND.NV. BATCH PROVENANCE (batch J, group C3 of sheets-lo-only-plan.md -- LibreOffice-only and either nondeterministic or context-bound; the final batch of the completeness push). This function has x == false AND g == false in docs/data/compat.json: NEITHER Microsoft NOR Google documents it, so this corpus makes no claim about either of those engines, nothing here is measured against their documentation, and the Excel column on the published page reads 'n/a (not an Excel function)' rather than a verdict. The authority is LibreOffice's own help, cited by full URL, by the date it was read (2026-08-31), and by the help version the page serves -- the URLs in this file are pinned to /25.8/ rather than /latest/ so the citation still means this text after the help site rolls forward, and /25.8/ is the help for the newest of the four engine builds the corpus executes. GOOGLE SHEETS: this batch builds the Sheets chunk whose ingest will record presence or absence in that engine. Until that ingest lands the Sheets column on the published page reads 'Not yet' and nothing in this file claims anything about it. (Stated positively on purpose -- scripts/check_honesty.py bans the blanket negative shape of that sentence, and the guard is worth keeping blunt.) LibreOffice's Mathematical-functions help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060106.html.

THE STRUCTURAL PROPERTY, MEASURED RATHER THAN ASSERTED. The only thing LibreOffice's help fixes about the value is its range -- "Returns a non-volatile random number between 0 and 1." -- so that, and nothing else, is what this case exercises: two independent draws inside one formula, each tested against both ends. What every build returned is recorded in this file's results entry. A PRECISION THE PAGE DOES NOT GIVE, SO THIS FILE DOES NOT EITHER: the help says "between 0 and 1" with NO inclusive/exclusive qualifier anywhere on the page, and its keyword index repeats the same unqualified phrase. This case therefore uses the INCLUSIVE reading (>=0 and <=1), which is the weaker of the two and is entailed by either; a test written as <1 would be asserting a boundary the documentation never states. WHY expected IS null EVEN THOUGH THIS PARTICULAR FORMULA LOOKS DETERMINISTIC. Every case in batch J is a probe by construction: the batch's whole subject is calls whose VALUE no engine can be held to, and mixing asserted and unasserted cases inside one such function would let a reader take the function's pass/fail count as a statement about the random draw itself. The structural property is therefore stated here and measured on all four builds rather than encoded as an expected value; what the run recorded is in this file's results entry, and the case's published verdict is 'Ran OK' -- it evaluated, without error, on every build. LibreOffice's Mathematical-functions help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060106.html.

PROBE ONLY (expected: null): A RANDOM DRAW HAS NO EXPECTED VALUE. LibreOffice's help says "Returns a non-volatile random number between 0 and 1." and its example is this exact formula: "=RAND.NV() ... returns a non-volatile random number between 0 and 1." The four pinned builds each returned a different number, as they should; those four values are recorded in the results files and none of them is a claim about any other run. What the case does establish is that the name resolves and the call evaluates without error on 24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3, which is the whole of the support question for a function like this. NON-VOLATILITY IS REAL BUT THIS TRANSPORT CANNOT SEE IT, AND THAT IS ITSELF A FINDING. The help defines the property as "This function produces a non-volatile random number on input. A non-volatile function is not recalculated at new input events. The function does not recalculate when pressing F9, except when the cursor is on the cell containing the function or using the Recalculate Hard command (Shift+Ctrl+F9). The function is recalculated when opening the file." -- and the last of those sentences is the obstacle: this harness's only way to make an engine compute anything is to OPEN the file (`soffice --headless --convert-to xlsx` over a workbook openpyxl wrote with no cached values). Every observation this corpus can make is therefore taken at exactly the moment the documentation says a recalculation happens, so a changed value between two runs would prove nothing and an unchanged one would prove less. The plan of record hoped to assert non-volatility here; the documentation itself rules the measurement out, and saying so is more useful than a test that could not fail. NONDETERMINISM CLASS, PER THE COPILOT PRECEDENT. The corpus records a probe (expected: null) whenever the documented behaviour depends on something the harness cannot fix: a service (COPILOT, DETECTLANGUAGE, TRANSLATE), a live market (STOCKHISTORY), an external server (RTD), a network fetch or an authorization (batch J's Google nine). The two .NV functions are the fourth class -- a pseudo-random draw -- and CURRENT is the fifth: a value defined by its own POSITION inside the formula that encloses it. In every class the note says which dependency makes the value unassertable, and the verdict is carried by whether the call evaluates at all. STORAGE FORM, ESTABLISHED EMPIRICALLY BEFORE THIS FILE WAS RUN. A LibreOffice-only function has no OOXML name of its own -- the .xlsx format was frozen on Excel's function set -- so LibreOffice invents one, and this harness must write exactly the token LibreOffice's own filter reads or a fully implemented function is recorded as #NAME? and published as unsupported. All NINE candidate spellings (plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE., _xlfn.ORG.OPENOFFICE., ORG.LIBREOFFICE., _xlfn.ORG.LIBREOFFICE., _xlfn.COM.MICROSOFT. and COM.SUN.STAR.SHEET.ADDIN.ANALYSIS.) were written into a workbook with openpyxl (which caches no value, so the engine must evaluate from scratch) and round-tripped through `soffice --headless --convert-to xlsx` on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3); the same round trip also reports the EXPORT direction, because the converted file carries whichever token LibreOffice itself chose to write. Exactly ONE spelling works: _xlfn.ORG.LIBREOFFICE.RAND.NV evaluates on all four builds and the other eight are #NAME? on all four, including the bare name -- so a workbook written with '=RAND.NV()' verbatim would have published a false 'unsupported' verdict. Every build writes the same token back out, and the help's Technical information block agrees: "The name space is" ORG.LIBREOFFICE.RAND.NV. The same block dates the function -- "This function is available since LibreOffice 7.0." -- which is older than all four builds the corpus runs, so no version boundary is expected or found here. The token recorded for this function in harness/xlfn_map.py is _xlfn.ORG.LIBREOFFICE.RAND.NV. BATCH PROVENANCE (batch J, group C3 of sheets-lo-only-plan.md -- LibreOffice-only and either nondeterministic or context-bound; the final batch of the completeness push). This function has x == false AND g == false in docs/data/compat.json: NEITHER Microsoft NOR Google documents it, so this corpus makes no claim about either of those engines, nothing here is measured against their documentation, and the Excel column on the published page reads 'n/a (not an Excel function)' rather than a verdict. The authority is LibreOffice's own help, cited by full URL, by the date it was read (2026-08-31), and by the help version the page serves -- the URLs in this file are pinned to /25.8/ rather than /latest/ so the citation still means this text after the help site rolls forward, and /25.8/ is the help for the newest of the four engine builds the corpus executes. GOOGLE SHEETS: this batch builds the Sheets chunk whose ingest will record presence or absence in that engine. Until that ingest lands the Sheets column on the published page reads 'Not yet' and nothing in this file claims anything about it. (Stated positively on purpose -- scripts/check_honesty.py bans the blanket negative shape of that sentence, and the guard is worth keeping blunt.) LibreOffice's Mathematical-functions help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060106.html.

THE STRUCTURAL PROPERTY, MEASURED RATHER THAN ASSERTED. The only thing LibreOffice's help fixes about the value is its range -- "Returns a non-volatile random number between 0 and 1." -- so that, and nothing else, is what this case exercises: two independent draws inside one formula, each tested against both ends. What every build returned is recorded in this file's results entry. A PRECISION THE PAGE DOES NOT GIVE, SO THIS FILE DOES NOT EITHER: the help says "between 0 and 1" with NO inclusive/exclusive qualifier anywhere on the page, and its keyword index repeats the same unqualified phrase. This case therefore uses the INCLUSIVE reading (>=0 and <=1), which is the weaker of the two and is entailed by either; a test written as <1 would be asserting a boundary the documentation never states. WHY expected IS null EVEN THOUGH THIS PARTICULAR FORMULA LOOKS DETERMINISTIC. Every case in batch J is a probe by construction: the batch's whole subject is calls whose VALUE no engine can be held to, and mixing asserted and unasserted cases inside one such function would let a reader take the function's pass/fail count as a statement about the random draw itself. The structural property is therefore stated here and measured on all four builds rather than encoded as an expected value; what the run recorded is in this file's results entry, and the case's published verdict is 'Ran OK' -- it evaluated, without error, on every build. LibreOffice's Mathematical-functions help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060106.html.