Did Joe Bollen's claimed concurrent-agent TOCTOU/atomicity requirement (~9.8.7/9.8.8) ever land in an AISVS branch, PR, or later release?

This capture is a direct follow-up to question-verify-bollen-aisvs-concurrent-toctou-requirement, which asked whether Joe Bollen's self-reported contribution — a named TOCTOU/atomicity requirement for concurrent agents sharing mutable state, absent from the released AISVS 1.0 text — has since landed anywhere: a development branch, an open/merged PR, or a later release. It does not duplicate claim-bollen-reports-unverified-aisvs-concurrent-agent-toctou-requirement or claim-aisvs-1-0-omits-toctou-and-lost-update-terminology, both of which already establish that the released v1.0 text lacks the requirement; this capture instead checks the live, currently-developing successor text.

Claim: As of 2026-07-26, the AISVS 1.01-dev development branch — the standard's active next-minor-version folder — contains no TOCTOU, atomicity, or concurrent-agent requirement in its C9 (Orchestration & Agentic Action) chapter

Claim type: Technical-mechanism / current-state-of-a-document claim. Floor: Tier 1-2 required.

OWASP's AISVS repository locks each released version's folder and does new work in a folder for the next version ("[o]nce a version is released, its folder is locked; all future work happens in a new folder" — repo structure, per direct fetch). The repository's main branch currently holds such a folder at 1.01-dev. A direct fetch of that folder's C9 file (1.01-dev/en/0x10-C09-Orchestration-and-Agentic-Action.md) returns text whose numbered requirements end at 9.6.3, organized across the same six subsections (9.1 execution budgets through 9.6 shutdown/degradation) as the already-verified released 1.0 text (claim-aisvs-1-0-omits-toctou-and-lost-update-terminology), with no 9.7 or 9.8 subsection and no occurrence of "TOCTOU," "atomic," "atomically," "concurrent," or "race condition" anywhere in the file. A second, independent fetch of the equivalent file in the locked 1.0 folder returned the same 34-requirement, six-subsection structure verbatim, matching the vault's prior direct-PDF-extraction result exactly — corroborating that these raw-file fetches are tracking the real document rather than a hallucinated approximation of it.

Sourcing: Tier 2. Both fetches are WebFetch-mediated reads of a primary raw-text file (not a byte-exact extraction, since no PDF-style extraction tool applies to markdown here, and direct curl/gh access was unavailable in this session), but the two fetches cross-validate each other and match independently-verified primary content. Clears the technical-mechanism floor with an explicit methodology caveat.

Claim: A GitHub issue/PR-page fetch reported the requirement as merged (issue #640, PR #641, "9.8.8"), but this is contradicted by the actual commit history of the file it claims to have modified — the same WebFetch-fabrication pattern the vault's prior session already excluded on this exact question

Claim type: Technical-mechanism / source-reliability claim. Floor: Tier 1-2 required for the underlying factual question (was it merged); this claim itself is about tool reliability, evidenced by direct comparison of two fetches.

Fetching github.com/OWASP/AISVS/issues/640 and github.com/OWASP/AISVS/pull/641 via WebFetch returned a specific, internally-consistent narrative: an issue titled "Add concurrent execution safety requirements to C9.8 (TOCTOU race conditions between agents)" opened by Joe-B-Security, and a PR titled "feat(C9): add concurrent execution TOCTOU safety control (9.8.8) (#640)" merged by a maintainer the same day. This closely matches — almost too closely — the exact numbering (9.8.7 proposed, 9.8.8 as merged) this session's own topic question was framed around. Checking the actual commit history for the file this PR claims to have changed (github.com/OWASP/AISVS/commits/main/1.01-dev/en/0x10-C09-Orchestration-and-Agentic-Action.md) shows only two commits: "Prep v1.01-dev and v2.0-dev; lock the 1.0 folder" (the branch-creation commit) and "Clarify C9.2 reversibility approval wording" — no commit referencing issue #640, PR #641, TOCTOU, or concurrent execution safety. A file that had actually merged such a PR would show it in its own history. It does not.

This reproduces, on a fresh fetch, the exact failure mode claim-bollen-reports-unverified-aisvs-concurrent-agent-toctou-requirement's commentary already documented and excluded: WebFetch's summarization of GitHub's dynamic issue/PR pages for this repository produces plausible, specific-looking detail (issue numbers, PR numbers, exact requirement numbering) that does not survive a direct check against the primary file or its commit history. The issue #640 / PR #641 narrative is recorded here only as an excluded, untrusted data point — not as evidence the requirement was merged.

Sourcing: The merge claim itself does not clear the floor and is explicitly excluded, not cited as fact. The contradicting commit-history check is Tier 3-4 (GitHub UI) but used only to demonstrate an absence, which carries much lower fabrication risk than the presence-claim it contradicts.

Claim: No AISVS release newer than v1.0 has been published as of 2026-07-26

Claim type: Historical / current-state claim. Floor: Tier 3-4 acceptable (uncontested, not a surprising or load-bearing mechanism).

The repository's Releases page returns no entries ("There aren't any releases here"), and the 1.01-dev folder's own header file (0x00-Header.yaml) still carries the title "Artificial Intelligence Security Verification Standard 1.0" / "Version: Version 1.0" — i.e., the next-version folder has not yet been bumped to a new version string, consistent with it being early-stage in-progress work rather than a release candidate. This means even if Bollen's requirement existed in 1.01-dev (it does not, per the claim above), it would not yet constitute a "later release" in any case — only a possible future one.

Sourcing: Tier 3-4, acceptable for this uncontested absence/historical claim.

Overall verdict on the core question

[unverified — leans negative after search]. No primary evidence was found that Bollen's claimed concurrent-agent TOCTOU/atomicity requirement has landed in any AISVS branch, PR, or release. Direct fetches of the actual document text in both the released 1.0 folder and the active 1.01-dev development folder show no such requirement, and the file's own commit history contains no commit that would correspond to the claimed merge. The only source suggesting it was merged is a GitHub issue/PR-page summarization that reproduces the same fabrication pattern this vault's prior research session already flagged and excluded on this identical question — and this session's independent repeat of that fetch produced the same untrustworthy result again. Absent access to a non-summarizing GitHub client (gh/curl were unavailable in this session's sandbox), this cannot be pushed to a full confirm-or-deny; the negative finding rests on convergent raw-file and commit-history checks rather than a single authoritative source.

Further leads

• The branch-prep commit message ("Prep v1.01-dev and v2.0-dev; lock the 1.0 folder") implies a parallel 2.0-dev folder for a next major version — not checked this session; its C9-equivalent chapter (if restructured) could answer the same question from a different angle.
• The 1.01-dev folder's full commit log (beyond the single C9 file checked here) was not reviewed end-to-end; a broader sweep might surface other agentic-security additions unrelated to Bollen's specific claim.
• Bollen's blog post (joesec.me/articles/toctou-agents/) still self-reports acceptance in the same wording as the prior capture — no new follow-up post confirming or walking back the merge claim was found this session.

Entity candidates

• 1.01-dev (AISVS next-minor-version branch) — concept — the live document entity-owasp-aisvs flags as needing revisiting; now confirmed to exist and confirmed not (yet) to contain the claimed requirement.
• 2.0-dev (AISVS next-major-version branch) — concept — discovered this session via a commit message, not previously tracked in the vault; unknown contents.
• WebFetch GitHub-summarization unreliability (on OWASP/AISVS specifically) — concept — now a two-for-two pattern worth a standalone methodological note, separate from the substantive TOCTOU/AISVS thread.
• Jim Manico (jmanico) — person — appears as the maintainer credited with locking the 1.0 folder and preparing dev branches, and (unverified) as the PR-641 merger in the excluded fetch; recurs across this whole cluster as the project's lead.