Grounding report.

The step is not a bare packaging action: pyproject.toml's [tool.cibuildwheel] table sets build-frontend="build" and test-command="pytest {project}/tests --import-mode=append" with before-test="pip install pytest hypothesis", so for each of the 24 matrix cells cibuildwheel compiles src/*.rs into tiktoken._tiktoken (setup.py declares a RustExtension with Binding.PyO3) and then installs the resulting wheel and runs the repo's test suite against it. Both signals are exit codes emitted by toolchains — the Rust compiler and the CPython interpreter running pytest — executing over the committed source; an author cannot make a type-error in the Rust or a failing assertion report clean without changing the source or the pinned cibuildwheel/pyproject config. DOCUMENTED LIMIT (oracle axis): tests/test_*.py are authored by the same maintainers as src/, so execution independence holds while the specification lives inside the write boundary. Second limit: test-skip="*-macosx_arm64" means the arm64 macOS wheels are built but never exercised, so for those cells only the compile signal exists.

producer the cibuildwheel run: rustc/cargo compiling the PyO3 extension through setuptools-rust, then the pytest process exit code from `pytest {project}/tests` executed against the freshly built wheel in an isolated venv — actor can write to it: no

• .github/workflows/build_wheels.yml:25
• .github/workflows/build_wheels.yml:19-20 (matrix: 3 OS x 8 python versions)
• pyproject.toml:41 test-command = "pytest {project}/tests --import-mode=append"
• pyproject.toml:40 before-test = "pip install pytest hypothesis"
• pyproject.toml:38 test-skip = "*-macosx_arm64"
• setup.py:6-14 RustExtension("tiktoken._tiktoken", binding=Binding.PyO3)
• tests/test_encoding.py, tests/test_offsets.py, tests/test_pickle.py, tests/test_simple_public.py

decided by agent · confidence 0.85

Identical mechanism to the x86 job, on native arm64 runners: CIBW_ARCHS=aarch64 with the shared [tool.cibuildwheel] config, so the step ends in a compile of src/*.rs plus `pytest {project}/tests` executed against the installed wheel. The pass/fail is an exit code produced by rustc and by CPython running the suite, neither of which an author can write to without changing the committed source or the pinned config. The macOS test-skip does not apply here, so every aarch64 cell that builds also runs the suite. DOCUMENTED LIMIT (oracle axis): the assertions in tests/ were authored alongside the implementation, so the runtime honestly decides pass/fail but the specification came from inside the write boundary.

producer the same cibuildwheel run on ubuntu-24.04-arm: cargo/rustc compiling the PyO3 extension for aarch64, then the pytest exit code from the configured test-command run against the built wheel — actor can write to it: no

• .github/workflows/build_wheels.yml:48-56
• .github/workflows/build_wheels.yml:42-43 (os: ubuntu-24.04-arm, 8 python versions)
• pyproject.toml:21-41 [tool.cibuildwheel] test-command/before-test
• setup.py:6-14

decided by agent · confidence 0.85

DELIBERATE RE-JUDGEMENT of a probe verdict — the `unfrozen-dependency-install` probe filed this not_a_check on the strength of the `pip install check-manifest` line, but that line is only the setup; the payload of the step is the second line, `check-manifest -v`, which builds an sdist from the checkout and diffs its contents against `git ls-files`, exiting non-zero when a tracked file is missing from the sdist or an untracked one appears. The two sides of the comparison are produced by two independent processes (setuptools packaging under MANIFEST.in, and git's index) and an author cannot make a stale MANIFEST.in report clean without changing MANIFEST.in or the tracked files themselves. LIMIT: check-manifest is installed unpinned from PyPI at run time, so the exact rule set is not frozen in the repo — the producer is still outside the write boundary (further outside, in fact), but the behaviour can drift between runs without a repo change.

producer the check-manifest process exit code, comparing the sdist that the build backend produces against the file list git reports as tracked — actor can write to it: no

• .github/workflows/build_wheels.yml:73-76
• MANIFEST.in:1-8
• pyproject.toml:17-19 build-backend = setuptools.build_meta

decided by agent · confidence 0.75

DELIBERATE RE-JUDGEMENT of a probe verdict — `unfrozen-dependency-install` claimed this as not_a_check because the raw contains `pip install --upgrade build`, but that is the setup line; the step's payload is `python -m build --sdist`, an executed packaging build. (The `packaging-build-invocation` probe, which would have called this anchored, correctly abstained on the same 'pip install' token, so the node was decided by the weaker of two matches.) The exit code is emitted by the interpreter resolving the build-system requires (setuptools>=62.4, wheel, setuptools-rust>=1.5.2) and running the backend against the checkout; malformed metadata or an unresolvable backend requirement fails the step and no author can talk it green. LIMIT, named because it is thin: an sdist build packages sources and does not compile the Rust extension, so this edge asserts that the packaging metadata is well-formed, not that the code works — the compile-and-test signal lives in the cibuildwheel jobs.

producer the `python -m build --sdist` exit code — CPython running the setuptools build backend in an isolated environment over the committed pyproject.toml/setup.py/MANIFEST.in — actor can write to it: no

• .github/workflows/build_wheels.yml:77-80
• pyproject.toml:17-19 requires = ["setuptools>=62.4", "wheel", "setuptools-rust>=1.5.2"]
• setup.py:1-19

decided by agent · confidence 0.65

The step's whole effect is to put files or a toolchain on the runner so later steps have something to act on. It reads nothing about the repository's correctness and emits no pass/fail verdict about the artefact — a failure here means the runner could not fetch or install, not that the code is wrong. The check in such a job is whatever executes afterwards, so this edge must not enter the ratio in either direction.

producer a GitHub Actions provisioning action (repository checkout, toolchain setup, or dependency cache restore) — actor can write to it: not established

• the step body is a bare `uses:` of a checkout/setup/cache action with no command of its own

decided by probe (ci-provisioning-action) · confidence 0.9

The step's whole effect is to move a file the pipeline itself produced from one job to another. Nothing about the repository is evaluated: with `if-no-files-found: error` the worst it can report is that an earlier step in the same run did not leave the file it claimed to leave, which is a fact about the plumbing, not about whether the code is correct. Whatever assertion exists in such a job is made by the step that produced the artifact or the step that consumes it, so this edge must not enter the ratio in either direction.

producer a GitHub Actions artifact transport action (upload-artifact / download-artifact) moving files between jobs — actor can write to it: not established

• the step body is a bare `uses:` of an artifact upload/download action with no command of its own

decided by probe (ci-artifact-transport) · confidence 0.7

The step's whole effect is to put files or a toolchain on the runner so later steps have something to act on. It reads nothing about the repository's correctness and emits no pass/fail verdict about the artefact — a failure here means the runner could not fetch or install, not that the code is wrong. The check in such a job is whatever executes afterwards, so this edge must not enter the ratio in either direction.

producer a GitHub Actions provisioning action (repository checkout, toolchain setup, or dependency cache restore) — actor can write to it: not established

• the step body is a bare `uses:` of a checkout/setup/cache action with no command of its own

decided by probe (ci-provisioning-action) · confidence 0.9

The step's whole effect is to move a file the pipeline itself produced from one job to another. Nothing about the repository is evaluated: with `if-no-files-found: error` the worst it can report is that an earlier step in the same run did not leave the file it claimed to leave, which is a fact about the plumbing, not about whether the code is correct. Whatever assertion exists in such a job is made by the step that produced the artifact or the step that consumes it, so this edge must not enter the ratio in either direction.

producer a GitHub Actions artifact transport action (upload-artifact / download-artifact) moving files between jobs — actor can write to it: not established

• the step body is a bare `uses:` of an artifact upload/download action with no command of its own

decided by probe (ci-artifact-transport) · confidence 0.7

The step's whole effect is to put files or a toolchain on the runner so later steps have something to act on. It reads nothing about the repository's correctness and emits no pass/fail verdict about the artefact — a failure here means the runner could not fetch or install, not that the code is wrong. The check in such a job is whatever executes afterwards, so this edge must not enter the ratio in either direction.

producer a GitHub Actions provisioning action (repository checkout, toolchain setup, or dependency cache restore) — actor can write to it: not established

• the step body is a bare `uses:` of a checkout/setup/cache action with no command of its own

decided by probe (ci-provisioning-action) · confidence 0.9

The step's whole effect is to put files or a toolchain on the runner so later steps have something to act on. It reads nothing about the repository's correctness and emits no pass/fail verdict about the artefact — a failure here means the runner could not fetch or install, not that the code is wrong. The check in such a job is whatever executes afterwards, so this edge must not enter the ratio in either direction.

producer a GitHub Actions provisioning action (repository checkout, toolchain setup, or dependency cache restore) — actor can write to it: not established

• the step body is a bare `uses:` of a checkout/setup/cache action with no command of its own

decided by probe (ci-provisioning-action) · confidence 0.9

The step's whole effect is to move a file the pipeline itself produced from one job to another. Nothing about the repository is evaluated: with `if-no-files-found: error` the worst it can report is that an earlier step in the same run did not leave the file it claimed to leave, which is a fact about the plumbing, not about whether the code is correct. Whatever assertion exists in such a job is made by the step that produced the artifact or the step that consumes it, so this edge must not enter the ratio in either direction.

producer a GitHub Actions artifact transport action (upload-artifact / download-artifact) moving files between jobs — actor can write to it: not established

• the step body is a bare `uses:` of an artifact upload/download action with no command of its own

decided by probe (ci-artifact-transport) · confidence 0.7

The step's entire body is a `uses:` of the artifact merge action with a name/pattern/delete-merged config. Its only effect is to fold the cibw-wheels-* bundles that earlier jobs uploaded into a single cibw-wheels bundle; it reads none of the repository's source and evaluates no property of it, so its failure modes are 'no artifact matched the pattern' or 'the artifact API errored' — facts about run plumbing, not about whether tiktoken is correct. The real gate in this job is the `needs: [build_wheels, build_wheels_aarch64, build_sdist]` edge, whose signal is produced by those jobs and is classified where it is emitted, not here. Filing this in the ratio in either direction would credit or penalize the score for a file copy.

producer actions/upload-artifact/merge, a GitHub Actions artifact aggregation action combining artifacts the same workflow run already uploaded — actor can write to it: not established

• .github/workflows/build_wheels.yml:91-96
• .github/workflows/build_wheels.yml:89 needs: [build_wheels, build_wheels_aarch64, build_sdist]

decided by agent · confidence 0.85