IMPORTDATA

NOT ASSERTABLE BY DESIGN, and deliberately recorded as a probe (expected: null) rather than a support claim -- the treatment batch B gave the CUBE* family and COPILOT, batch C gave DETECTLANGUAGE, and batch G gave RTD, STOCKHISTORY and TRANSLATE. GOOGLE DOCUMENTS THIS FUNCTION AS A FETCH: "Imports data at a given url in .csv (comma-separated value) or .tsv (tab-separated value) format.", with the single argument described as "The url from which to fetch the .csv or .tsv-formatted data, including protocol (e.g. `http://`)." The value is therefore whatever some other server serves at the moment of evaluation -- outside this corpus's control, and outside the engine's. Google's shared Import-functions page adds that "All three functions automatically check for updates every hour while the document is open, even if the formula and sheet don't change." (the three being IMPORTDATA, IMPORTHTML and IMPORTXML), so the value is not even stable within one open document. SYNTAX NOTE, CHECKED TWICE ON THE DAY: the live page publishes a ONE-argument `IMPORTDATA(url)`. Widely-copied secondary sources carry a three-argument `IMPORTDATA(url, delimiter, locale)`; that form is not on Google's page and is not used here. WHY THE URL IS example.com AND NOT GOOGLE'S OWN SAMPLE URL. Google's Sample Usage points at a live third-party document. Two harness facts rule that out: (a) an import that succeeds returns an ARRAY, and this corpus writes each case's formula at F1 with the per-sheet recalculation canary at Z1, so an unbounded spill would overwrite the canary and mark the whole run untrusted for a reason that has nothing to do with the engine; (b) a corpus that is re-executed on four builds per batch should not repeatedly fetch someone else's server. The call here is well formed and shaped exactly like Google's documented syntax; only the host is inert. Since no value is asserted either way, nothing is lost by it. LIBREOFFICE, MEASURED BEFORE THIS FILE WAS AUTHORED. All four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) were probed with NINE storage 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. -- and every one of those 36 combinations returned #NAME?. LibreOffice's own parser additionally wrote the name back into the converted file LOWER-CASED ('=importdata("https://example.com/data.csv")'), which is what it does with an identifier it does not recognise as a function at all rather than with a function it knows under a different storage token. A #NAME? under all nine storage forms on all four builds is therefore a genuine absence and not a storage-form artifact of this harness, which is why 'unsupported in LibreOffice' IS a verdict this file publishes even though the returned VALUE is not assertable in any engine. BATCH PROVENANCE (batch J, group B of sheets-lo-only-plan.md -- Google-documented, service- or context-bound; the final batch of the completeness push). This function has x == false in docs/data/compat.json: Microsoft does not document it at all, so this corpus makes no claim about Excel, nothing here is measured against Microsoft's documentation, and the Excel column on the published page reads 'n/a (not an Excel function)' rather than a verdict. The authority is Google's own function help, cited by full URL and by the date it was read (2026-08-31) -- Google publishes no version number for Sheets, so a bare URL dates nothing. GOOGLE SHEETS: this batch builds the Sheets chunk whose ingest will record what the service returns for this call. 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.) Google's IMPORTDATA help page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093335, and the Import-functions page at https://support.google.com/docs/answer/12188454, read the same day.

NOT ASSERTABLE BY DESIGN, and deliberately recorded as a probe (expected: null) rather than a support claim -- the treatment batch B gave the CUBE* family and COPILOT, batch C gave DETECTLANGUAGE, and batch G gave RTD, STOCKHISTORY and TRANSLATE. GOOGLE DOCUMENTS THIS FUNCTION AS A FETCH: "Imports data at a given url in .csv (comma-separated value) or .tsv (tab-separated value) format.", with the single argument described as "The url from which to fetch the .csv or .tsv-formatted data, including protocol (e.g. `http://`)." The value is therefore whatever some other server serves at the moment of evaluation -- outside this corpus's control, and outside the engine's. Google's shared Import-functions page adds that "All three functions automatically check for updates every hour while the document is open, even if the formula and sheet don't change." (the three being IMPORTDATA, IMPORTHTML and IMPORTXML), so the value is not even stable within one open document. SYNTAX NOTE, CHECKED TWICE ON THE DAY: the live page publishes a ONE-argument `IMPORTDATA(url)`. Widely-copied secondary sources carry a three-argument `IMPORTDATA(url, delimiter, locale)`; that form is not on Google's page and is not used here. WHY THE URL IS example.com AND NOT GOOGLE'S OWN SAMPLE URL. Google's Sample Usage points at a live third-party document. Two harness facts rule that out: (a) an import that succeeds returns an ARRAY, and this corpus writes each case's formula at F1 with the per-sheet recalculation canary at Z1, so an unbounded spill would overwrite the canary and mark the whole run untrusted for a reason that has nothing to do with the engine; (b) a corpus that is re-executed on four builds per batch should not repeatedly fetch someone else's server. The call here is well formed and shaped exactly like Google's documented syntax; only the host is inert. Since no value is asserted either way, nothing is lost by it. LIBREOFFICE, MEASURED BEFORE THIS FILE WAS AUTHORED. All four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) were probed with NINE storage 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. -- and every one of those 36 combinations returned #NAME?. LibreOffice's own parser additionally wrote the name back into the converted file LOWER-CASED ('=importdata("https://example.com/data.csv")'), which is what it does with an identifier it does not recognise as a function at all rather than with a function it knows under a different storage token. A #NAME? under all nine storage forms on all four builds is therefore a genuine absence and not a storage-form artifact of this harness, which is why 'unsupported in LibreOffice' IS a verdict this file publishes even though the returned VALUE is not assertable in any engine. BATCH PROVENANCE (batch J, group B of sheets-lo-only-plan.md -- Google-documented, service- or context-bound; the final batch of the completeness push). This function has x == false in docs/data/compat.json: Microsoft does not document it at all, so this corpus makes no claim about Excel, nothing here is measured against Microsoft's documentation, and the Excel column on the published page reads 'n/a (not an Excel function)' rather than a verdict. The authority is Google's own function help, cited by full URL and by the date it was read (2026-08-31) -- Google publishes no version number for Sheets, so a bare URL dates nothing. GOOGLE SHEETS: this batch builds the Sheets chunk whose ingest will record what the service returns for this call. 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.) Google's IMPORTDATA help page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093335, and the Import-functions page at https://support.google.com/docs/answer/12188454, read the same day.

NOT ASSERTABLE BY DESIGN, and deliberately recorded as a probe (expected: null) rather than a support claim -- the treatment batch B gave the CUBE* family and COPILOT, batch C gave DETECTLANGUAGE, and batch G gave RTD, STOCKHISTORY and TRANSLATE. GOOGLE DOCUMENTS THIS FUNCTION AS A FETCH: "Imports data at a given url in .csv (comma-separated value) or .tsv (tab-separated value) format.", with the single argument described as "The url from which to fetch the .csv or .tsv-formatted data, including protocol (e.g. `http://`)." The value is therefore whatever some other server serves at the moment of evaluation -- outside this corpus's control, and outside the engine's. Google's shared Import-functions page adds that "All three functions automatically check for updates every hour while the document is open, even if the formula and sheet don't change." (the three being IMPORTDATA, IMPORTHTML and IMPORTXML), so the value is not even stable within one open document. SYNTAX NOTE, CHECKED TWICE ON THE DAY: the live page publishes a ONE-argument `IMPORTDATA(url)`. Widely-copied secondary sources carry a three-argument `IMPORTDATA(url, delimiter, locale)`; that form is not on Google's page and is not used here. WHY THE URL IS example.com AND NOT GOOGLE'S OWN SAMPLE URL. Google's Sample Usage points at a live third-party document. Two harness facts rule that out: (a) an import that succeeds returns an ARRAY, and this corpus writes each case's formula at F1 with the per-sheet recalculation canary at Z1, so an unbounded spill would overwrite the canary and mark the whole run untrusted for a reason that has nothing to do with the engine; (b) a corpus that is re-executed on four builds per batch should not repeatedly fetch someone else's server. The call here is well formed and shaped exactly like Google's documented syntax; only the host is inert. Since no value is asserted either way, nothing is lost by it. LIBREOFFICE, MEASURED BEFORE THIS FILE WAS AUTHORED. All four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) were probed with NINE storage 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. -- and every one of those 36 combinations returned #NAME?. LibreOffice's own parser additionally wrote the name back into the converted file LOWER-CASED ('=importdata("https://example.com/data.csv")'), which is what it does with an identifier it does not recognise as a function at all rather than with a function it knows under a different storage token. A #NAME? under all nine storage forms on all four builds is therefore a genuine absence and not a storage-form artifact of this harness, which is why 'unsupported in LibreOffice' IS a verdict this file publishes even though the returned VALUE is not assertable in any engine. BATCH PROVENANCE (batch J, group B of sheets-lo-only-plan.md -- Google-documented, service- or context-bound; the final batch of the completeness push). This function has x == false in docs/data/compat.json: Microsoft does not document it at all, so this corpus makes no claim about Excel, nothing here is measured against Microsoft's documentation, and the Excel column on the published page reads 'n/a (not an Excel function)' rather than a verdict. The authority is Google's own function help, cited by full URL and by the date it was read (2026-08-31) -- Google publishes no version number for Sheets, so a bare URL dates nothing. GOOGLE SHEETS: this batch builds the Sheets chunk whose ingest will record what the service returns for this call. 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.) Google's IMPORTDATA help page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093335, and the Import-functions page at https://support.google.com/docs/answer/12188454, read the same day.