RANDBETWEEN.NV

PROBE ONLY (expected: null): A RANDOM DRAW HAS NO EXPECTED VALUE. The formula is LibreOffice's own published example, transcribed from the help's semicolon form: "=RANDBETWEEN.NV(20;30) ... returns a non-volatile integer between 20 and 30." (This corpus writes commas because the transport is .xlsx, whose formula grammar is comma-separated; the call is otherwise the documented one.) The help describes the function as "Returns an non-volatile integer random number in a specified range." -- Google that sentence and you will find the same grammatical slip, "an non-volatile", which is LibreOffice's, not a transcription error here. Each of the four pinned builds returned a different integer and all four are recorded; none is a claim about any other run. What the case establishes 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. NON-VOLATILITY IS OUTSIDE THIS TRANSPORT'S REACH, for the reason spelled out in RAND.NV's file: the help says the function IS recalculated "when opening the file", and opening the file is the only way this harness makes an engine compute anything. 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.RANDBETWEEN.NV evaluates on all four builds and the other eight are #NAME? on all four, the bare name included. Every build writes that same token back out, and the help's Technical information block agrees: "The name space is" ORG.LIBREOFFICE.RANDBETWEEN.NV, alongside "This function is available since LibreOffice 7.0." -- older than all four builds, so no version boundary is expected or found. Note the pair splits from CURRENT on namespace exactly as the help's own vintage rule predicts: CURRENT is OpenOffice.org-era and carries ORG.OPENOFFICE., while the two .NV functions are LibreOffice-era additions and carry ORG.LIBREOFFICE. The token recorded for this function in harness/xlfn_map.py is _xlfn.ORG.LIBREOFFICE.RANDBETWEEN.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 -- and here the documentation is explicit where RAND.NV's is not. The help states "Returns an non-volatile integer random number between integers Bottom and Top (both inclusive).", so a predicate written with >= and <= against 20 and 30 tests exactly what the page says, with no boundary invented by this corpus. Two independent draws are used, one per comparison, so the case covers the property rather than a single lucky number; what every build returned is recorded in this file's results entry. INTEGER-NESS IS LEFT TO THE RECORDED VALUES, not to a predicate: a formula comparing a draw against INT() of ANOTHER draw would fail whenever the two draws differ, which is most of the time, and would be a bug in the test rather than in the engine. The unwrapped case beside this one records the actual integer each build produced. 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. The formula is LibreOffice's own published example, transcribed from the help's semicolon form: "=RANDBETWEEN.NV(20;30) ... returns a non-volatile integer between 20 and 30." (This corpus writes commas because the transport is .xlsx, whose formula grammar is comma-separated; the call is otherwise the documented one.) The help describes the function as "Returns an non-volatile integer random number in a specified range." -- Google that sentence and you will find the same grammatical slip, "an non-volatile", which is LibreOffice's, not a transcription error here. Each of the four pinned builds returned a different integer and all four are recorded; none is a claim about any other run. What the case establishes 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. NON-VOLATILITY IS OUTSIDE THIS TRANSPORT'S REACH, for the reason spelled out in RAND.NV's file: the help says the function IS recalculated "when opening the file", and opening the file is the only way this harness makes an engine compute anything. 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.RANDBETWEEN.NV evaluates on all four builds and the other eight are #NAME? on all four, the bare name included. Every build writes that same token back out, and the help's Technical information block agrees: "The name space is" ORG.LIBREOFFICE.RANDBETWEEN.NV, alongside "This function is available since LibreOffice 7.0." -- older than all four builds, so no version boundary is expected or found. Note the pair splits from CURRENT on namespace exactly as the help's own vintage rule predicts: CURRENT is OpenOffice.org-era and carries ORG.OPENOFFICE., while the two .NV functions are LibreOffice-era additions and carry ORG.LIBREOFFICE. The token recorded for this function in harness/xlfn_map.py is _xlfn.ORG.LIBREOFFICE.RANDBETWEEN.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 -- and here the documentation is explicit where RAND.NV's is not. The help states "Returns an non-volatile integer random number between integers Bottom and Top (both inclusive).", so a predicate written with >= and <= against 20 and 30 tests exactly what the page says, with no boundary invented by this corpus. Two independent draws are used, one per comparison, so the case covers the property rather than a single lucky number; what every build returned is recorded in this file's results entry. INTEGER-NESS IS LEFT TO THE RECORDED VALUES, not to a predicate: a formula comparing a draw against INT() of ANOTHER draw would fail whenever the two draws differ, which is most of the time, and would be a bug in the test rather than in the engine. The unwrapped case beside this one records the actual integer each build produced. 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. The formula is LibreOffice's own published example, transcribed from the help's semicolon form: "=RANDBETWEEN.NV(20;30) ... returns a non-volatile integer between 20 and 30." (This corpus writes commas because the transport is .xlsx, whose formula grammar is comma-separated; the call is otherwise the documented one.) The help describes the function as "Returns an non-volatile integer random number in a specified range." -- Google that sentence and you will find the same grammatical slip, "an non-volatile", which is LibreOffice's, not a transcription error here. Each of the four pinned builds returned a different integer and all four are recorded; none is a claim about any other run. What the case establishes 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. NON-VOLATILITY IS OUTSIDE THIS TRANSPORT'S REACH, for the reason spelled out in RAND.NV's file: the help says the function IS recalculated "when opening the file", and opening the file is the only way this harness makes an engine compute anything. 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.RANDBETWEEN.NV evaluates on all four builds and the other eight are #NAME? on all four, the bare name included. Every build writes that same token back out, and the help's Technical information block agrees: "The name space is" ORG.LIBREOFFICE.RANDBETWEEN.NV, alongside "This function is available since LibreOffice 7.0." -- older than all four builds, so no version boundary is expected or found. Note the pair splits from CURRENT on namespace exactly as the help's own vintage rule predicts: CURRENT is OpenOffice.org-era and carries ORG.OPENOFFICE., while the two .NV functions are LibreOffice-era additions and carry ORG.LIBREOFFICE. The token recorded for this function in harness/xlfn_map.py is _xlfn.ORG.LIBREOFFICE.RANDBETWEEN.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 -- and here the documentation is explicit where RAND.NV's is not. The help states "Returns an non-volatile integer random number between integers Bottom and Top (both inclusive).", so a predicate written with >= and <= against 20 and 30 tests exactly what the page says, with no boundary invented by this corpus. Two independent draws are used, one per comparison, so the case covers the property rather than a single lucky number; what every build returned is recorded in this file's results entry. INTEGER-NESS IS LEFT TO THE RECORDED VALUES, not to a predicate: a formula comparing a draw against INT() of ANOTHER draw would fail whenever the two draws differ, which is most of the time, and would be a bug in the test rather than in the engine. The unwrapped case beside this one records the actual integer each build produced. 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.