-
"Nothing is written into the repository."
check creates no swarm.toml and keeps its evidence outside the repository, but it briefly adds and removes its own falsification-bond fixtures, and the project's own commands write whatever they write. Say that.
-
That the basic command runs in a container when one is available
Locally it runs on the host under a built environment, a policy and not a sandbox; containers are the Action's default and --isolation asks for one. The 1.0.0 release note said otherwise and carries a correction.
-
That `regression: pass` means every check passed
A failure the base had, in the same tests the same way, is shown as inherited and not counted. Say "no check failed because of the change".
-
That a requirement contract, a challenge or a signature proves the work correct
A contract defines scope, its checks are evidence, a challenge asks whether a check could fail, and a signature says who produced a bundle.
-
That swarm-verify catches more wrong work than another tool, or is the only tool that does something
No completed comparison supports either; the advantage is an open hypothesis tracked in docs/verifier-first/README.md.
-
That fork testing establishes unrestricted safety
Real fork and Dependabot controls ran on published 1.1.0 and 1.2.0, including hostile code and stale-head refusal; see SV-16 in docs/verifier-first/README.md. Those observations apply to their tested container and workflow boundaries, not every runner or hostile program.
-
"Seven red-team laps."
The loop ledger records one completed lap. Six of the seven pass directories were human-driven work outside the driver, which redteam/loop/state/lap-accounting.jsonl sets out. Say "adversarial passes with closures locked as regression tests".
-
Any regulatory or standards date
No EU AI Act article, no prEN 18229-1, no ISO/IEC 24970, no compliance deadline, in the README, on any page, or in any release note. The build guide's own instruction is to re-verify all three before they appear anywhere, and they have not been re-verified.
-
"Fully secure", or any unbounded security claim
The honest naming is known-pattern scrubbing, not secret removal, and there is a four-character floor under it. Zero crashes at a given fuzz budget is evidence, not proof.
-
That a well-formed decomposition proves the user’s goal complete
The legacy graph run in docs/evidence/2026-08-24/swarm.md passed structural checks on an unusable decomposition. The adaptive controller now checks declared executable obligations on the exact integrated tree, with bounded revisions and independent acceptance (redesign-implementation-2026-09-13.md). That establishes the tested contract, not that the contract captures all user intent.
-
That redundancy picks the best solution
The legacy comparator selects discipline; goal selection first requires applicable executable obligations and integrated checks, then ranks under the sealed objective. Neither establishes semantic completeness beyond those checks, and missing human judgments remain unjudged.
-
That the oracle-reach check proves an oracle judged the change
It proves the oracle *executed* the lines, which is a necessary condition and not a sufficient one, and for every runner but node's own it reads a coverage report the workspace's own processes wrote. Nothing detects a forged one. That is safe only because the check can do nothing but refuse: a forged report buys reached, which is what an unmeasured oracle already gets. Say "refuses to certify on an oracle shown to have skipped part of the change".
-
That the oracle bond proves the oracle judged the task
It asks whether the oracle asserted anything about the lines the patch *added*, and it cannot ask what the patch left out. Measured rather than reasoned about: shown the oracle it would be judged by, a model writes a patch whose added lines that oracle tests, so the oracle refuses every mutant of them and the bond reads held on a patch a held-back oracle rejects. Say "asks whether running the oracle established anything about the change it did make".
-
That a `vacuous` verdict means the mutant changed behaviour, or that an `unshown` one means it did not
Two detectors are asked, the oracle's own coverage and the repository's own suite, and what each cannot see is written down: coverage misses a value changed on a path that runs either way, and a suite written before the patch existed misses anything the patch is adding. A mutant both miss is recorded as unwitnessed, which is an absence of evidence and not evidence of absence.
-
Any number the tool did not measure locally
No benchmark, no throughput figure carried over from a model card, and no comparison against another agent beyond the one exploratory trial in docs/evidence/2026-10-11/comparison/, which may be cited only with its denominators and only for what its README says it supports. The shortlist's size and memory figures are curated estimates and the select report says so itself.
-
Any suggestion the four judge-shaped residuals are closed
They are open, they ship as documented limitations, and each is a permanent case in the adversarial suite asserting the gap as it stands.
-
That the campaign ranks the models, or measures the tool as it ships
Its outcome is a judge over the tree, not a measure of a change's quality; the two arms ran under different backends with different failure shapes; and the corpus measures the CLI packed on 2026-09-02, before two defects it exposed were fixed. The non-node numbers are a floor for the fixed tool, not a measure of it, and the frontier arm has no measurement at all.