Compatibility¶

pyroid aims for the same output as the libraries it replaces, not output close to it. This page is the evidence: what each module is compared against, by which rule, and how many comparisons have been made. Every known difference is listed in the module's guide.

How parity is tested¶

Each module is tested differentially: the same input goes to pyroid and to the incumbent, and the results are compared exactly. For fastText, probabilities may also differ by 1e-6, though none do on Linux (on macOS they can differ more). The metrics are compared as the strings they print, with no tolerance. The inputs are:

• Pinned real documents: the first 10,000 FineWeb documents, 8 FineWeb-2 languages, and a seeded adversarial set of 3,232 documents (mojibake, near-duplicates, edge cases), all fixed by sha256. The metrics use pinned evaluation data instead: CNN/DailyMail, SummEval and the WMT21 system outputs. Trafilatura uses 7,192 pinned Common Crawl pages from 3 crawls, as datatrove's WARC reader and URL filter pass them on.
• The incumbent's own test corpus, where it has one. For ftfy that is its 161 golden cases, including its 10 known failures, which pyroid reproduces too. The test suites of json_repair and Trafilatura are replayed call by call.
• Property-based fuzzing with Hypothesis, with strategies that reach lone surrogates, every option value and every documented edge case. Hypothesis never generates surrogates by default; these strategies do.

For invalid input, the exception type must match too (messages may differ).

The suites run against the installed wheel, on regular and free-threaded CPython. Deliberately broken builds (for example ftfy without surrogate-pair joining) fail them.

Results¶

The counts below are from each module's test runs between 2026-11-05 and 2026-11-09, in a Docker/OrbStack VM on linux/aarch64 unless a row says otherwise. The native runs on AWS EC2 are under Platforms. CI runs the parity/ suites on Linux x86_64 and aarch64 on every pull request and push to main; their counts are in each job's summary and parity-report.json artifact, not on this page.

pyroid.ftfy¶

Reference: ftfy 6.3.1. Rule: byte-identical output, same exception type.

Source: the Rust oracle replay (crates/pyroid-core/tests/ftfy_oracle.rs) and python/tests/test_ftfy_parity.py, run on 2026-11-05.

pyroid.fasttext¶

Reference: fasttext-predict 0.9.2.4 (fastText's C++ predict path). Rule: same labels, probabilities within 1e-6 (measured: bit-identical).

Source: python/tests/test_fasttext_parity.py and the parity/ fastText suite, run on 2026-11-05.

pyroid.filters¶

Reference: datatrove 0.10.1 with spaCy 3.8.18 (and its other tokenizers: IndicNLP, whitespace, SudachiPy 0.7.0 with sudachidict-core 20261015, pyvi 0.1.1, PyThaiNLP 5.4.0 with python-crfsuite 0.9.12), tldextract 5.4.0, numpy 2.5.4. Rule: same keep/drop decision, same filter_reason, same rewritten text, same exception.

• Hypothesis against live datatrove: 92 tests x 300 examples over script-specific text in 22 native languages and the jieba, SudachiPy, pyvi and PyThaiNLP fallback paths (python_tokenizer=True).
• Japanese, native: 12 Hypothesis properties against live datatrove (python/tests/test_filters_japanese.py, 628 examples per run; 11 of them also at 300 examples each).
• Vietnamese and Thai, native: 80 tests against live datatrove (python/tests/test_filters_vithai.py: every filter, FineWeb-2's chains, words, sentence dedup and MinHash, on generated and FineWeb-2 text; 1,046 Hypothesis examples per run, 5,230 with the ci profile).
• The newer steps, input by input: PII on 13,232 documents x 4 configurations, C4 bad words x 5 (per-document languages, seeded keep_fraction), symbol lines x 3, the URL filter on 10,000 FineWeb URLs x 7 configurations and 9,695 URL-like strings, plus Hypothesis against the reference and live datatrove.

Source: the parity/ filters suite (after the last rebase, 2026-11-06; vie_Latn and tha_Thai 2026-11-09), crates/pyroid-core/tests/filters_tokenizer.rs, crates/pyroid-core/src/{sudachi,pyvi,pythainlp}/replay.rs and the multilingual replays, run on 2026-11-05, 2026-11-06 and 2026-11-09.

pyroid.dedup¶

Reference: datatrove 0.10.1 MinHash (FineWeb: sha1, 64-bit, 14 buckets x 8 hashes, 5-grams; FineWeb-2: xxhash, 64-bit) and sentence dedup. Rule: identical signatures, removed set, cluster ids and sizes; sentence dedup: byte-identical signature, duplicate and index files.

• datatrove's stages 1 to 3 re-run and compared from raw text: every bucket's pairs, the removed ids, cluster ids and sizes are identical for sha1/64 (445 removed) and xxhash/32 (439 removed, 3,146 pairs).
• Live-datatrove Hypothesis families (case, whitespace, punctuation, edits, swaps; 1-, 2- and 5-grams; 4 hash configurations) and a Python transcription of stages 1 to 3: identical.
• simplify_text: CRC digests over all 1,112,064 code points x 13 configurations x 5 Unicode versions identical.
• Sentence dedup: datatrove's three stages re-run on pyroid's files give the same documents and exclusion documents; Hypothesis 300 examples against the reference and 100 three-stage runs against live datatrove.

Source: the parity/ dedup suite (after the last rebase, 2026-11-06) and python/tests/test_dedup_parity.py, run on 2026-11-05 and 2026-11-06.

pyroid.translit¶

Reference: anyascii 0.3.3 (for anyascii()); Unidecode 1.4.0 as a black box (for unidecode()'s errors= semantics only). Rule: anyascii(): byte-identical; unidecode(): Unidecode's errors=, exceptions and warnings, on anyascii's data.

• The generated table matches the anyascii package on all 1,112,064 non-surrogate code points, and the kernel matches the any_ascii crate on every scalar in all 4 errors= modes.
• unidecode() vs Unidecode 1.4.0, black box: 194 tests over the alphabets both libraries map (every errors= mode, replace_str edge cases, invalid errors, messages, args, index, warning order, batches) pass. The transliterations themselves differ by design; see the translit guide.

Source: python/tests/test_translit_parity.py, test_translit_unidecode.py and the module's agreement run, 2026-11-05.

pyroid.metrics¶

Reference: rouge-score 0.1.2 (with NLTK 3.10.4's Porter stemmer) and sacrebleu 2.6.0. Rule: identical repr, str, format(), JSON and signature strings of every score: no tolerance.

• Data, pinned by sha256: CNN/DailyMail 3.0.0 test (11,490 lead-3 summaries and 2,000 whole articles against the highlights), SummEval (1,600 summaries from 16 systems x 11 references, score_multi), WMT21 newstest2021 (8 language pairs, 141 systems, 163,000 segments, up to 3 references). The reference file holds 694,757 results.
• The Porter stemmer matches NLTK on all 512,136 distinct tokens of FineWeb 100k; 28 rouge_types edge cases and 49 sacrebleu error cases match in exception type, message and order.

Source: the parity/ metrics suite, run on 2026-11-06 (the x86_64 rows: bench/results/aws-c7i.4xlarge/2026-11-06/parity).

pyroid.json_repair¶

Reference: json_repair 0.64.5. Rule: the same returned string or object, the same repair log, the same exception.

• Skipped by design: 4 calls whose result depends on the hash seed and 3 that depend on the recursion limit.
• The Rust kernel also replays 451 distinct upstream inputs x 4 option sets, and its Python-semantics tables are checked per interpreter (3.11 to 3.15t): str.isspace/isalpha/isdigit/isalnum on all 1,112,064 code points, json.loads 84k cases, json.dumps 45k, float.repr 145k.

Source: the parity/ json_repair suite, run on 2026-11-06.

pyroid.datasketch¶

Reference: datasketch 2.0.0 (live, with numpy 2.5.4 and scipy 1.18.1). Rule: identical hash values and dtypes, identical LeanMinHash bytes, identical (b, r), identical query result sets.

• The (b, r) search ports scipy 1.18.1's QUADPACK: all 715,040 LSH and 258,300 LSH Ensemble probabilities it evaluates are bitwise identical to scipy's on aarch64, and all 9,156 grid argmins and 126 ensemble constructions match.
• datasketch's own test suite (test_minhash, test_lean_minhash, test_minhash_schemes, test_lsh, test_lshforest, test_lshensemble) passes against pyroid's classes, with Hypothesis and seeded workloads compared against live datasketch: 1,020 tests on CPython 3.12, 3.14t, 3.15 and 3.15t.

Source: the parity/ datasketch suite (CPython 3.13, release wheel), run on 2026-11-07.

pyroid.jieba¶

Reference: jieba 0.42.1. Rule: the same words in the same order (empty strings included), the same offsets, FREQ values, total and exceptions.

• python/tests: Hypothesis properties against live jieba for every mode, add_word / del_word / suggest_freq / load_userdict sequences, broken and unusual dictionary files and every code point; 656 tests on CPython 3.13, 657 on 3.15t, also under pytest-run-parallel.
• The route takes math.log of integers: bit-identical on CPython 3.12 to 3.15t for every dictionary frequency, and jieba's recorded outputs are byte-identical on 3.12, 3.13, 3.14 and 3.15.

Source: the parity/ jieba suite, crates/pyroid-core/src/jieba/replay.rs and a 20,000-document replay, run on 2026-11-07.

pyroid.trafilatura¶

Reference: trafilatura 2.3.1 with lxml 6.1.3 (libxml2 2.14.6) and jusText 3.0.2; for compat="1.11.0", trafilatura 1.11.0 with the releases a fresh datatrove[processing]==0.10.1 install resolves (lxml 6.1.3, jusText 3.0.2, lxml-html-clean 0.4.6, charset-normalizer 3.5.2, courlan 1.4.0, htmldate 1.11.0). Rule: extract text byte for byte (None distinct from ""), bare_extraction field by field, the same exceptions (type and message) and warnings.

• The suite also checks every delegated option (trafilatura's result and exactly one FallbackWarning), trafilatura's exact signatures plus compat=, extract_batch against the loop, and pyroid.patch("trafilatura")'s signatures for the installed release: 109 tests passed for 2.3.1 and 111 for 1.11.0.
• The Rust core's own check, before the parity suite: 4,677 pages of the CC-MAIN-2026-39 development sample in 10 option sets, extract and bare_extraction, on CPython 3.13 (the dev split also on 3.12 and 3.15), and Unicode 14.0 to 17.0 vectors; 151 extra edge pages for 1.11.0, including a family with control characters. Identical in both modes.
• python/tests/test_trafilatura*.py: 544 tests against trafilatura 2.3.1, and 395 against trafilatura 1.11.0 in its own environment, including the datatrove Trafilatura step against datatrove's own step, statistics included.

Source: the parity/ trafilatura suite in both modes (CPython 3.13, run on 2026-11-09), and parity/pyroid_parity/trafilatura_scale.py on AWS EC2 c7i.4xlarge (bench/results/aws-c7i.4xlarge/2026-11-09-warc/scale).

pyroid.nltk¶

Reference: NLTK 3.10.4 (with regex 2026.9.29). Rule: the same sentences, tokens and offsets, str for str, and the same exceptions (type and message).

• python/tests: Hypothesis properties and NLTK's doctest examples against live NLTK for every ported function, every code point alone and in templates, batches (list, tuple, Arrow), parameters and their in-place edits, model loading with and without NLTK, fallbacks and pyroid.patch("nltk"); 1,088 tests on CPython 3.13 and 3.15t, also under pytest-run-parallel, with the GIL off on 3.15t.
• Character classes: regex 2026.9.29's \w, \d and \s and CPython 3.11 to 3.15's isupper / islower are dumped code point by code point; the rules hard-coded in Rust (regex's \s, both engines' (?i) letters) are checked on each interpreter.

Source: the parity/ nltk suite, crates/pyroid-core/src/nltk/testdata/ replays and their large uncommitted recordings, run on 2026-11-09.

pyroid.nemo and pyroid.integrations.nemo_curator¶

Reference: NeMo Curator 1.4.0 on CPython 3.12 (pandas 3.1.1, regex 2026.11.9, ftfy 6.3.1, jieba 0.42.1, fasttext 0.9.3 built with g++ 12). Rule: the same score (repr and type), the same exception type and the same modified text; for the stages, the same DataFrame (values, dtypes, index).

• NeMo's RepeatingTopNGramsFilter breaks ties between equally frequent n-grams in Python set order, which follows the process's string hash seed, so its own scores change from run to run unless PYTHONHASHSEED is fixed (the references use 0); pyroid makes the choice NeMo makes in the same process.
• The pinned checks also pass on CPython 3.14t and 3.15t with the GIL off; NeMo does not install there, so the live checks skip.
• python/tests: Hypothesis properties of every score function and modifier against NeMo's code (copied, so they run without NeMo) and against live NeMo; the stages on Arrow, string[pyarrow], str and object columns; the batch paths never call NeMo's per-row methods; pyroid.patch("nemo_curator") with hydra configs. 517 tests on CPython 3.12 with NeMo, 167 on 3.15t, also under pytest-run-parallel.
• Not ported: NeMo Curator 1.4.0's exact and fuzzy deduplication run on GPUs only (cuDF), and it has no CPU PII stage.

Source: the parity/ nemo suite (parity-report of 2026-11-10, linux/aarch64), parity/pyroid_parity/nemo_pipeline.py and bench/nemo_pipeline_bench.py.

Integrations: datatrove steps, pyroid clean, pyroid.patch()¶

Reference: datatrove 0.10.1's stock FineWeb pipeline (and the libraries pyroid.patch() stands in for). Rule: the same per-document digest of id, text, language, score, keep, reason and duplicate flag; for patch(), the same call-site output.

• Per-step tests against live datatrove (67 tests, 313 documents): every step's result, reason, rewritten text and metadata at several batch sizes and thread counts; MinhashDedupSignature's files are byte-identical, and datatrove's stages 2 to 4 on them remove the same documents.
• The FineWeb recipe in Python (recipes.FineWeb, whole corpus and 777-document batches) and hf.fineweb (also with num_proc=2) give digest ef314b8d... on FineWeb dev too.
• From WARC, without leaving any pages out: pyroid's steps in datatrove's executor and the native chain keep the same 23,505 documents at 8 and at 1 worker (digest d0e2ad48...). That is 2 more than stock datatrove at 8 workers, both pages stock datatrove gave up on, with 0 text differences. Stock datatrove stops extracting a page after 1 s and drops it, and which pages hit that limit changes between runs, so its own two runs kept different sets (23,503 and 23,501). pyroid has no timeout and gave the same documents in every run. The 5 pages on which trafilatura 1.11.0 itself raises are dropped by both (datatrove's child process dies on them; pyroid's step counts them as broken_process).
• Cross-shard MinHash files: pyroid's .minhash.sig, .dups, .remove, .clusters and .sizes files are byte-identical to datatrove 0.10.1's (4 configurations, empty ranks, spills, 1 and 2 workers per bucket), and datatrove's own stages 1 to 3 on the same cleaned 100k files write the same bytes.
• On AWS EC2 c7i.4xlarge, 4,188,430 FineWeb documents (sample/10BT, files 000 to 003) gave the same kept (3,547,373) and excluded documents in one process, with --workers 4, with 4 shards and the four stages, and when resumed after a Ctrl-C.
• The newer drop-ins (PIIFormatter, C4BadWordsFilter, SymbolLinesFormatter, URLFilter, sentence dedup) are counted under pyroid.filters and pyroid.dedup above.

Source: python/tests/test_integrations_*.py, test_cli.py, test_cli_scale.py, test_dedup_files.py and examples/datatrove/verify.py (2026-11-06 to 2026-11-09), and bench/fineweb_warc.py on AWS EC2 c7i.4xlarge (bench/results/aws-c7i.4xlarge/2026-11-09-warc, 2026-11-09).

pyroid.warc¶

Reference: warcio 1.8.2 and datatrove 0.10.1's WarcReader (with faust-cchardet 3.2.0, python-magic 0.4.27 and brotlicffi 1.2.1.0), live. Rule: event by event, the same records, headers, payloads, offsets, fh.read() and fh.tell() calls, digest results, stderr writes, log warnings and exceptions (type and message), and the same documents out of datatrove's reader; for pyroid.patch("warcio"), the same traces from warcio's own names and datatrove's own reader.

The parity/ warc suite (pytest -m warc --impl pyroid.warc --parity-limit 0) compares 31,291 record traces per implementation, under up to 29 iterator options, read plans and openers, over 34 Common Crawl slices of 16 crawls from 2013 to 2026 (WARC, WET, WAT and a 2012 ARC file; 86.9 MB), warcio's 16 test files, 1,085 seeded synthetic files in 13 families (framing, truncation, bit flips, lengths, headers, HTTP, chunked, encodings, record types, digests, ARC, charsets, big records), 120 variants of the slices and Hypothesis-generated WARC streams, plus datatrove's process_record, WarcReader and executor runs: no differences, in a Docker VM (aarch64, CPython 3.13, and 3.14t with the GIL off) and natively on AWS EC2 c7i.4xlarge (x86_64). On that machine, pyroid_parity.warc_scale compared every record and document of 15 whole files (8 CC-MAIN-2026-39 WARC files; WARC files of 2016-40 and 2019-35, WET files of 2013-20 and 2023-50, WAT files of 2018-30 and 2026-43, and the 2012 ARC file): 1,169,108 records and 366,199 documents in 74 jobs, all the same.

• CPython's gzip.GzipFile read path, as datatrove reads .warc.gz files, is emulated per interpreter: it gave CPython's bytes and errors on all 4,910 cases on CPython 3.11 to 3.15.
• The known differences are in the guide: digest algorithm names and damaged brotli streams (41 of 2,296 corruption cases).

Known differences¶

Each guide lists its module's deliberate differences. Most are edge cases (inputs on which the incumbent hangs, crashes or raises a different exception type); the rest are design choices, such as returning an unchanged string as the same object.

• Differences from ftfy
• Differences from fastText
• Differences from datatrove's filters
• Differences from datatrove's MinHash and sentence dedup
• Differences of the datatrove drop-in steps
• Differences from rouge-score and from sacrebleu
• Differences from json_repair
• Differences from datasketch
• Differences from jieba
• Differences from trafilatura
• Differences from warcio
• Differences from Unidecode. pyroid.translit.unidecode deliberately does not reproduce Unidecode's output; see how different it is.

Interpreters and Unicode versions¶

Results that depend on the Python version are matched per interpreter. That covers ftfy's and datatrove's use of \w, \d and isalpha, json_repair's str.isspace and friends, and Unicode normalization. pyroid carries Unicode tables for 14.0, 15.0, 15.1, 16.0 and 17.0 (CPython 3.11 to 3.15) and picks the one matching unicodedata.unidata_version.

The ftfy suites passed on CPython 3.11, 3.12, 3.13, 3.14, 3.14t, 3.15 and 3.15t. The other suites ran on 3.12 or 3.13 and on free-threaded 3.15t, as their rows say. A few references can't be loaded on a free-threaded build without re-enabling the GIL (sacrebleu imports lxml), so their live checks run on GIL builds only.

Languages¶

The filters and dedup suites cover English and 8 FineWeb-2 languages end to end, and the tokenizer replays cover every natively supported datatrove tokenizer: 4,013 of datatrove's 4,343 language codes, Chinese included (its parity is pyroid.jieba's) and Japanese (the SudachiPy and datatrove replays under pyroid.filters). The rest go through datatrove's own Python tokenizers (python_tokenizer=True), so they are datatrove's results by construction. See Languages.

Platforms¶

Every suite on this page ran on Linux aarch64, in a Docker/OrbStack VM on Apple Silicon. The Trafilatura scale runs and the WARC pipeline comparison ran on x86_64, on an AWS EC2 c7i.4xlarge, on 2026-11-09 (their rows under pyroid.trafilatura and Integrations).

Linux x86_64 and aarch64 on AWS EC2¶

On 2026-11-06 the parity suites ran natively, with no emulation, on two AWS EC2 instances running Amazon Linux 2023:

• x86_64: c7i.4xlarge, Intel Xeon Platinum 8488C (Sapphire Rapids), with AVX2 and FMA;
• aarch64: c8g.4xlarge, AWS Graviton4.

Each machine built its own release wheels and ran every suite on CPython 3.12 (the cp311-abi3 wheel, with the live oracles) and on free-threaded 3.15t (the abi3t wheel). Both machines gave the same counts, with 0 differences in every check that ran:

On 3.12, 6 live-oracle filter tests did not run: 4 for C4 bad words and 2 for the URL filter. datatrove's C4BadWordsFilter and URLFilter need optional dependencies that parity's lock file lacked at the time, so the tests failed on import before comparing anything. The lock file has them now. They have not been re-run on EC2, but CI's parity jobs run them on x86_64 and aarch64.

Both machines also regenerated the parity references. On the c8g, all 8 match the linux-aarch64 pins byte for byte. On the c7i, the fastText reference is byte-identical to the x86_64 pin made earlier under emulation. The metrics reference was not: 165 of its 694,757 results (all BLEU scores) differ by 1–2 ulps from the emulated pin. Regenerated on the c7i, the x86_64 metrics reference is identical to the aarch64 one, and it has been re-pinned.

Per-platform references¶

fastText's own output differs between architectures for the quantized lid.176.ftz: on 10,837 of 13,232 documents, by at most 5.96e-7, with the same labels. Its aarch64 build fuses multiply-adds that baseline x86-64 can't. pyroid reproduces each architecture's arithmetic, so the fastText reference is pinned per platform, and pyroid's x86_64 output is bit-identical to x86_64 fasttext-predict 0.9.2.4 on all 26,464 pinned predictions (max |Δp| = 0).

The C library matters as well. pyroid calls the platform's exp, expf and log, as fastText does, and glibc, musl, Apple's libm and Windows' UCRT round some of them differently: on GitHub's runners (2026-11-10), 39 of the 54 test-zoo models gave other digests on macOS arm64, 16 on macOS x86_64 and 14 on Windows x64, with the same model files. So the zoo digests are pinned per OS, C library and architecture; on each platform they were the same for every Python version and for the PGO release wheels. On Windows x64, pyroid matched fasttext-predict to the last bit over 316 (model, k) pairs. On macOS the largest difference was 1.91e-6, on a test model with weights scaled by 20, where fasttext-predict's clang build rounds its dot products differently.

The metrics reference is pinned per platform the same way, because sacrebleu's BLEU calls the C library's exp and log. Its difference came only from Rosetta 2's emulated CPU, which has SSE4.2, FMA and BMI2 but no AVX or AVX2, so glibc took other exp/log paths there. On the c7i, with AVX2 and FMA, the x86_64 and aarch64 files are the same. GitHub's x86_64 runners have AVX2 too, and CI's parity-data job regenerates the references on both architectures (when its cache misses) and checks them against their pins. pyroid and the reference share the C library, so they would agree with each other either way.

Earlier runs under emulation¶

Before the EC2 runs, Linux x86_64 was checked under emulation (OrbStack with Rosetta 2) on CPython 3.12 and 3.15t, with the release wheels:

• python/tests: 1,850 passed on 3.12 and 1,678 on 3.15t (GIL off), 0 failed.
• The ftfy, fastText, filters and dedup parity suites: 0 differences (filters: 66,160 decisions; dedup: 13,232 signatures and the removed set). The live datatrove oracle job: 44 passed.
• The metrics suite, against the x86_64 reference pinned under emulation: 1,307,887 checks, 0 differences.

macOS, Windows and musl¶

The parity/ suites, with the pinned FineWeb, Common Crawl and evaluation data, run on Linux only. On macOS (x86_64 and arm64), Windows (x64 and ARM64) and musl Linux (x86_64 and aarch64), the release workflow installs each wheel in a clean virtual environment and runs pyroid's test suite (python/tests) with it, on CPython 3.11, 3.14t, 3.15 and 3.15t, before the release is published. That suite compares pyroid against the installed ftfy, anyascii, fasttext-predict, rouge-score, NLTK, json_repair, datasketch, jieba and warcio, where each installs, and checks the fastText test-zoo digests pinned per platform (above; none are pinned for Windows ARM64).

pyroid fuses fastText's multiply-adds on every aarch64 target, as Linux builds of fastText do, and orders exact ties between labels as libstdc++ orders them. pyroid's x86 builds stay at baseline x86-64 (no -C target-cpu), as bit-identity with baseline fastText builds requires.

Hardening¶

Beyond parity, the native code was checked for crashes and undefined behaviour on 2026-11-06, in Docker:

• Fuzzing with cargo-fuzz: 7 targets (ftfy, filters, the tokenizer, translit, dedup, fastText model loading and inference, the Arrow importer), about 4.4 hours and 19.8 million executions, each target for at least 25 minutes. There were no crashes in pyroid's code. One resource bug was fixed: a tiny crafted fastText model could make every vector call allocate 8 GiB. pyroid now rejects it, where fastText loads it. The fuzzers' results over their final corpora also matched ftfy, datatrove, spaCy and anyascii.
• Miri (Stacked and Tree Borrows, strict provenance, symbolic alignment, 16 seeds on the thread tests) on the Arrow FFI code: no undefined behaviour. AddressSanitizer and LeakSanitizer: clean. The pure-Rust core forbids unsafe.
• MSRV: Rust 1.85, checked with a real 1.85 build.
• Supply chain: cargo deny advisories over the Rust dependencies, and pip-audit over the locked test, parity and benchmark dependency sets. No findings.