Keel
Grounding report.
Every verification edge in simonw-llm, classified by who produces the signal and whether the actor being verified can write to that producer.
| target | simonw-llm |
|---|---|
| revision | 0392226e6630746ef51ffd309c2bee6a5f72b58e |
| generated | 2026-07-25T03:00:47.827Z |
anchored / (anchored + self_referential + unknown) = 3 / 4
Coverage (judged)
| node kind | judged |
|---|---|
| ci_step | 21 |
| script | 2 |
| test_target | 2 |
ε-audit — not run
No verdict in this report carries a readable audit block, so nothing was re-decided and there is no agreement rate to report. This is not agreement, and it is not full agreement either: a rate over zero comparisons would state a measurement that was never taken. (“Readable” is load-bearing: a block can be present and state no comparison, and this state covers that too — see below if so.)
This run judged 25 of 38 gathered edges. Every number on this page describes that sample, not the whole surface — 13 gathered edges are absent from all of it. A cap is disclosed rather than smoothed: an undisclosed sample is how a ratio gets shopped.
Scope. Keel measures the shape of verification, not its quality. A repo can be 100% anchored with terrible tests. Anchoring says the signal comes from outside; it does not say the signal is sufficient.
Node graph — 25 node(s), in gather order
anchored — 3
The step invokes a language test runner directly, so the step's exit status IS the runtime's verdict on executing the committed test modules against the built artefact. A failing assertion, an uncaught exception, an import error or a crash cannot be persuaded to report green without changing the code or the tests. Documented limit, and it matters: the EXECUTION is anchored, the ORACLE is not — implementation and assertions are typically authored by the same people in the same repo, so a green run proves the code does what these tests say, not that the tests say the right thing. Whether the step blocks a merge additionally depends on the workflow's triggers, which this shape does not read.
producer the test runner process's exit code, produced by the language runtime executing the suite in the pipeline — actor can write to it: no
- the step's run command is a direct invocation of a language test runner, with no install/provisioning command and no failure-suppressing flag
decided by probe (direct-test-runner-invocation) · confidence 0.85
`python -m build` asks the backend named in pyproject.toml to produce an sdist and a wheel from the committed source; it exits non-zero if the metadata is malformed, a declared dependency specifier is invalid, the package layout does not resolve, or the source does not import at build time. The verdict is computed by that program from the tree, so an author cannot make an unbuildable package report success without changing the tree — and this step runs in a `deploy` job whose `needs: [test]` means it only executes after the pytest matrix passed. Documented limit: a successful build proves the artefact is packageable and installable, not that it behaves correctly; it says nothing about runtime semantics.
producer the PEP 517 build backend (setuptools, invoked by `python -m build`) executing against the checked-out tree, and its process exit code — actor can write to it: no
- .github/workflows/publish.yml:47-49
- .github/workflows/publish.yml:35 (`needs: [test]`)
- .github/workflows/test.yml:56-58 (the same command run as an explicit 'Check it builds' gate on every push)
decided by agent · confidence 0.82
The step invokes a language test runner directly, so the step's exit status IS the runtime's verdict on executing the committed test modules against the built artefact. A failing assertion, an uncaught exception, an import error or a crash cannot be persuaded to report green without changing the code or the tests. Documented limit, and it matters: the EXECUTION is anchored, the ORACLE is not — implementation and assertions are typically authored by the same people in the same repo, so a green run proves the code does what these tests say, not that the tests say the right thing. Whether the step blocks a merge additionally depends on the workflow's triggers, which this shape does not read.
producer the test runner process's exit code, produced by the language runtime executing the suite in the pipeline — actor can write to it: no
- the step's run command is a direct invocation of a language test runner, with no install/provisioning command and no failure-suppressing flag
decided by probe (direct-test-runner-invocation) · confidence 0.85
self_referential — 1
`cog --check` recomputes the doc blocks by running the embedded generators and fails if the committed text differs — so the expected value is authored by the very code the docs describe, never by an independent specification. The write path is closed explicitly: .github/workflows/cog.yml runs `cog -r` on every `opened`/`synchronize` pull_request event and, if the regeneration changed anything, commits and pushes the result back to the PR branch (cog.yml:29-49). By the time this step reads the branch, the pipeline has already written the value it is about to compare against, so the comparison can only ever catch a regeneration that the bot did not get to run — the same shape as running `--update-snapshots` and then asserting the snapshot. The cog process's exit code is honestly produced by the interpreter; the oracle it compares to is not.
producer cog re-executing the Python snippets embedded in docs/*.md and diffing its own regenerated output against the committed markdown — actor can write to it: yes
- .github/workflows/test.yml:38-43 (`cog --check ... docs/**/*.md docs/*.md`)
- .github/workflows/cog.yml:29-31 (`cog -r` regenerates in-place)
- .github/workflows/cog.yml:33-49 ('Check for changes' + 'Commit and push if changed' — the pipeline writes the expected value back to the branch)
- .github/workflows/cog.yml:7-9 (`permissions: contents: write`)
decided by agent · confidence 0.7
not_a_check — 21
The whole file is `asyncio_default_fixture_loop_scope = function` — it selects an event-loop scope for async fixtures and declares no suite, no strictness flag, no failure threshold and no addopts. Nothing here can exit non-zero or block a merge; the edge that actually gates is `python -m pytest -vv` at .github/workflows/test.yml:35-37, gathered separately and judged on its own. Counting this file as a check as well would double-count that one edge.
producer an ini file read by pytest at startup to set one asyncio fixture default — actor can write to it: not established
- pytest.ini:1-2
- .github/workflows/test.yml:35-37 (the pytest invocation that actually gates)
decided by agent · confidence 0.78
conftest.py contains only fixtures (`user_path`, `logs_db`, `collection`), mock model classes registered through pluggy, and canned httpx responses; the two `assert isinstance(messages, list)` lines are argument guards inside a test double's `enqueue`, not assertions about the product. It is loaded by, and cannot fail independently of, the `python -m pytest -vv` step at .github/workflows/test.yml:35-37 which is the edge that blocks the merge. Documented limit on THAT edge, recorded here because this file is what imposes it: every provider HTTP call in the suite is answered by hardcoded JSON written in this file (tests/conftest.py, `httpx_mock.add_response(... json={...})`), so the suite's oracle for third-party API behaviour is authored entirely inside the write boundary — execution is still honestly decided by the interpreter, the specification is not.
producer pytest fixture and plugin definitions loaded before any test runs — actor can write to it: not established
- tests/conftest.py:1-502
- tests/conftest.py:82 (assert inside MockModel.enqueue, a test double)
- .github/workflows/test.yml:35-37
decided by agent · confidence 0.72
The target body is `sphinx-build -M help` — it prints the list of available Sphinx builders. It reads no repository content for validity and produces no pass/fail claim; the only way it exits non-zero is if sphinx-build is not installed.
producer sphinx-build printing its own usage text to stdout — actor can write to it: not established
- docs/Makefile:12-13
decided by agent · confidence 0.95
`sphinx-autobuild -b html` starts a watching dev server for a human to preview docs in a browser; it never terminates on its own, so it has no terminal exit code any gate could read, and no CI job invokes it (nothing under .github/workflows/ references docs/Makefile).
producer sphinx-autobuild, a long-running local preview server — actor can write to it: not established
- docs/Makefile:22-23
- .github/workflows/ (no reference to docs/Makefile or livehtml)
decided by agent · confidence 0.93
The file is a single line, `line-length = 160`. Configuration is consumed by a checker; it is not itself a producer of any signal and can never exit non-zero. The edge that produces a verdict is `ruff check .` at .github/workflows/test.yml:52-55 (outside this run's 25-node sample). Recorded limit on that edge: this file is inside the authors' write boundary, so the *scope* of what ruff enforces is author-controlled even though ruff's exit code is not.
producer a TOML table read by ruff to set one formatting parameter — actor can write to it: not established
- ruff.toml:1
- .github/workflows/test.yml:52-55 (`ruff check .` — the edge that emits a verdict)
decided by agent · confidence 0.75
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 command installs declared dependencies so that later steps can run. Without a lockfile-freezing flag the resolver will refresh a stale lock rather than error, so the step cannot report a discrepancy between the manifest and the lock; its non-zero exits mean the network or the index failed, not that the repository is wrong. The assertion in such a job lives in whatever executes against the installed environment afterwards.
producer a package manager's dependency resolver populating an environment — actor can write to it: not established
- the run command is a bare dependency install with no --locked/--frozen equivalent
decided by probe (unfrozen-dependency-install) · confidence 0.8
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 command installs declared dependencies so that later steps can run. Without a lockfile-freezing flag the resolver will refresh a stale lock rather than error, so the step cannot report a discrepancy between the manifest and the lock; its non-zero exits mean the network or the index failed, not that the repository is wrong. The assertion in such a job lives in whatever executes against the installed environment afterwards.
producer a package manager's dependency resolver populating an environment — actor can write to it: not established
- the run command is a bare dependency install with no --locked/--frozen equivalent
decided by probe (unfrozen-dependency-install) · confidence 0.8
The step's entire effect is promotion: it takes the dist/ files the previous step produced and uploads them to the index. It evaluates nothing about the artefact — a failure here means the upload was rejected (duplicate version, bad token, registry outage), not that the code is wrong. The verification condition on this promotion is the job's `needs: [test]` at publish.yml:35, which is a different edge; this one asserts nothing, so it must not enter the ratio in either direction. Noted separately: the action is referenced by the mutable branch ref `@release/v1` rather than a pinned SHA, which would matter if this were being counted as a check.
producer pypa/gh-action-pypi-publish uploading the built distributions to PyPI over trusted publishing — actor can write to it: not established
- .github/workflows/publish.yml:50-51
- .github/workflows/publish.yml:35 (`needs: [test]` — the actual promotion condition)
- .github/workflows/publish.yml:47-49 (produces the artefact this step ships)
decided by agent · confidence 0.8
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
`git config --global user.email/user.name` sets the identity later commits in this job will carry. It reads nothing from the repository and evaluates nothing about it; the only way it exits non-zero is if the runner's HOME is unwritable. The assertions in this workflow, such as they are, live in the generate and diff steps that follow.
producer git writing two keys into the runner's global config file — actor can write to it: not established
- .github/workflows/update-model-settings.yml:44-48 (git config --global user.email / user.name)
- .github/workflows/update-model-settings.yml:114-125 ('Create branch and push as signed commit' — the consumer of that identity)
decided by probe (runner-git-identity-config) · confidence 0.93
The body probes whether an origin branch exists and, if not, creates it and seeds docs/ from the newest tag, then commits and pushes. Every operation mutates state; nothing compares the repository against an expectation, and the one operation that could fail on a no-op is neutralised with `|| echo "No changes"`. There is no assertion here to be grounded or ungrounded.
producer git creating a branch on the runner and pushing it to origin — actor can write to it: not established
- .github/workflows/stable-docs.yml:25-37
- .github/workflows/stable-docs.yml:35 (`git commit ... || echo "No changes"` — failure suppressed)
decided by agent · confidence 0.9
`git checkout stable && git reset --hard $TAG && git push --force` moves a documentation branch to point at the released commit. It reads nothing about correctness and cannot report anything about the code — it is a publish operation for the docs site, and its failure mode is a git or network error, not a defect signal.
producer git resetting the `stable` branch to a release tag and force-pushing it — actor can write to it: not established
- .github/workflows/stable-docs.yml:38-44
decided by agent · confidence 0.92
`git diff-tree --name-only` is used here to ENUMERATE which docs/ files changed so they can be checked out onto the stable branch and committed — the diff is an input to a copy, not an assertion, and the branch where nothing changed ends in an explicit `exit 0`. The step gates nothing: it runs only when the commit message contains `!stable-docs`, and its whole output is a push to a docs branch.
producer git copying changed docs/ files onto the `stable` branch and pushing them — actor can write to it: not established
- .github/workflows/stable-docs.yml:45-64
- .github/workflows/stable-docs.yml:63 (`exit 0` on the no-change path)
decided by agent · confidence 0.88
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 command installs declared dependencies so that later steps can run. Without a lockfile-freezing flag the resolver will refresh a stale lock rather than error, so the step cannot report a discrepancy between the manifest and the lock; its non-zero exits mean the network or the index failed, not that the repository is wrong. The assertion in such a job lives in whatever executes against the installed environment afterwards.
producer a package manager's dependency resolver populating an environment — actor can write to it: not established
- the run command is a bare dependency install with no --locked/--frozen equivalent
decided by probe (unfrozen-dependency-install) · confidence 0.8
The command installs declared dependencies so that later steps can run. Without a lockfile-freezing flag the resolver will refresh a stale lock rather than error, so the step cannot report a discrepancy between the manifest and the lock; its non-zero exits mean the network or the index failed, not that the repository is wrong. The assertion in such a job lives in whatever executes against the installed environment afterwards.
producer a package manager's dependency resolver populating an environment — actor can write to it: not established
- the run command is a bare dependency install with no --locked/--frozen equivalent
decided by probe (unfrozen-dependency-install) · confidence 0.8
Crystallization curve
Run economics