Receipts — the verification log
A finding is marked Confirmed only when it was checked against Anthropic's own page and the fetch was kept. This is that record. Each finding's inline (receipt R#) links here, so you can see exactly what was fetched, when, and — for the re-verified claims — the sentence that confirmed it, quoted exactly. Where a check turned up an absence rather than a sentence, that is recorded as a note in our own voice instead. A 404 row is kept too: a failed fetch is part of an honest log, not hidden.
What the banner counts
The currency banner at the top of every page counts established findings only — the claim cards inside the six modules. It does not count the How this connects card at the foot of each module: those six cards carry chips too, but they are navigational summaries rather than findings, and counting them twice would inflate the total. Nor does it count open questions, glossary entries or worked examples, none of which assert a verified fact.
So a reader who counts chips on screen will see more than the banner's total. Besides those six cards, the extras are the ✓ on each module's source note and the ⚠ links pointing at why a flagged claim is flagged — signposts reusing the same vocabulary, not additional findings. The rule, rather than a second total: a claim card inside a module is counted; a signpost is not. We would rather say that plainly than have you find it.
A note on the log's own vocabulary: each table below is one verification round — a dated sitting in which claims were checked against Anthropic's live pages. Rounds carry internal names like CG4 ("curriculum-grade", numbered), and each fetch in a round gets a receipt number (R1, R2, …) that the finding cards cite. Where a note references a rule like "§4.4", that is the project's own review charter — the discipline the log is kept under — not an Anthropic document.
Flagged right now — 2 claims at stale risk
These are the claims the currency banner counts as stale risk. A flag here is not a mistake we are hiding — it is the verification working. Each one is either sourced to something that turned out not to support it, or contradicted by the vendor's own documentation. Treat each as a question for your Anthropic contact, not as a fact.
How to read the chips
- Confirmed checked against Anthropic’s own page on the date shown, and the receipt kept.
- Documented not checked against an Anthropic page this round — either carried from the working group’s document, or this curriculum’s own practice recommendation. The source chip says which.
- Stale risk known-volatile, or the check found a discrepancy — treat as a question, not a fact.
- compliance a claim a patient-data decision could hang on — always confirm with your Anthropic contact first.
- our practice a practice recommendation — this curriculum’s or the working group’s — not an Anthropic product fact.
- Stale risk why flagged product fact compliance — confirm with your contact source: claude.com also: support.claude.comTwo Anthropic pages disagree on whether the Cowork OpenTelemetry export includes prompt content by default Anthropic's documentation and Anthropic's help centre currently say opposite things about whether the Cowork monitoring stream carries the actual words your staff typed. The docs say events are metadata only unless you switch content capture on. The help centre says prompt content is included by default. For a group whose prompts may carry patient detail, that is the difference between "your monitoring system is now a store of patient information you have to govern" and "it isn't" — different retention rules, different access controls, different answer when someone asks where patient data lives. Do not settle this by picking whichever page you found first. Turn the export on against a test collector, send a prompt containing a harmless marker word, and look at what actually arrives. Your own collector is the only trustworthy answer.
- Stale risk why flagged product fact compliance — confirm with your contact source: support.claude.com/provision-and-manage-skills- also: support.claude.com/what-are-skills also: platform.claude.comSkills CAN be provisioned org-wide on Team and Enterprise — and one Anthropic page still says otherwise On Team and Enterprise, an organization owner can push a Skill to everyone, and members can share Skills with colleagues, with groups, or submit them to an organization library. All of that is documented — and since this node was first written, Anthropic has added a review workflow: an owner-controlled Publishing policy that can require approval before anything a member submits is published. One Anthropic page — the platform Agent Skills overview — still says custom Skills "cannot be centrally managed by admins", and that sentence is out of date. If your IT lead reads that page and concludes org-wide Skills are impossible, they have the wrong answer.
Baseline receipts · fetched 2026-07-22
| # | Primary source | HTTP | Date | Used for |
|---|---|---|---|---|
| R1 | Use Claude Cowork safely | 200 | 2026-07-22 | Folder and desktop access findings — what Claude can reach, and what isolation does and does not limit. |
| R2 | How long do you store my data? (consumer) | 200 | 2026-07-22 | Consumer retention — partial; the training-toggle detail was re-fetched later as R19. |
| R3 | HIPAA-ready Enterprise plans | 200 | 2026-07-22 | HIPAA coverage findings — which plans are eligible, what a BAA covers, and what stays outside it. |
| R4 | What are skills? | 200 | 2026-07-22 | Skills findings — what a Skill is, how it is built, and how it is shared. |
| R5 | Models overview | 200 | 2026-07-22 | The model-availability worked example — how to check whether a named model is actually available to you. |
| R6 | ZDR agreement: which products? | 200 | 2026-07-22 | Zero-data-retention scope — which products a ZDR arrangement covers, and that it applies per organization. |
| R7 | API & data retention | 200 | 2026-07-22 | API retention windows, HIPAA coverage boundaries, and the model-availability example. |
| R8 | How long do you store my organization's data? | 200 | 2026-07-22 | Organization retention, the 30-day deletion figure, and the trust & safety retention exception. |
| R9 | Skills (docs path) | 404 | 2026-07-22 | Skills definition — attempted; the docs path had moved. Kept as a failed receipt, because an honest log records the fetches that did not work. Superseded by R22. |
Re-verification · fetched 2026-07-23
Re-verification for SC4 R1 (Operation Rutter): resolved the doc's '7-day API retention' claim (now 30-day / not-retained-by-default) and relocated the moved Skills docs path. These four rows were originally labelled R2′, R7′, R8′ and R9→. Prime and arrow labels cannot be addressed by an inline '(receipt R#)' citation, so every node citing them silently resolved to the baseline row each one superseded. CG4 reissued them as R19–R22 — at the end of the sequence rather than in date order, because ids already in print are never renumbered.
| # | Primary source | HTTP | Date | Confirming quote & what we checked |
|---|---|---|---|---|
| R20 supersedes R7 | API & data retention | 200 | 2026-07-23 | “Conversation content (your prompts and Claude's outputs) is not retained by default; the exception is Covered Models, which require 30-day retention. Flagged content retained up to 2 years; scores up to 7 years.” |
| R21 supersedes R8 | How long do you store my organization's data? | 200 | 2026-07-23 | “For Anthropic API users, we automatically delete inputs and outputs on our backend within 30 days of receipt or generation.” |
| R19 supersedes R2 | How long do you store my data? (consumer) | 200 | 2026-07-23 | “If you allow us to use your chats or coding sessions to improve Claude, we may retain your data in a de-identified format for up to 5 years in our model training pipelines.” What we checked: Checked for a distinct automatic retention window in the toggle-OFF state: none published. Recorded as an honest absence rather than inferred. |
| R22 supersedes R9 | Agent Skills overview (relocated path) | 200 | 2026-07-23 | “Every Skill requires a SKILL.md file with YAML frontmatter.” What we checked: Path relocated: the previously cited /agents-and-tools/skills URL was the 404 preserved as R9. This row records the fetch that superseded it. |
Patient-safety round · fetched 2026-07-25
SC5 / Operation Soundings, CG2 (Wave 1 — patient safety). Nine primary-source fetches backing the Wave-1 corrections, mirrored verbatim from the currency & provenance report's '## CG2 currency round' section. Numbered as integers R10–R18: seven were taken during the round itself, and R17 and R18 were added in the post-review correction pass, after an independent reviewer showed the round had wrongly downgraded the commercial no-training claim. Two of these receipts (R15 and R16) contradict each other on the same day — that pair is itself the evidence behind a Stale-risk finding, which is why both are kept.
| # | Primary source | HTTP | Date | Confirming quote & what we checked |
|---|---|---|---|---|
| R10 | Use Claude Cowork safely | 200 | 2026-07-25 | “Isolation limits where Claude's code runs. It doesn't limit what Claude reads or does. … any local files it opens through the desktop app, is processed on Anthropic's servers rather than staying on your computer. … computer use has no sandbox between Claude and what's on your screen. … When Claude uses your computer, it asks for your permission before accessing each application. … Claude always asks before permanently deleting files, in any mode.” |
| R11 | HIPAA-ready Enterprise plans | 200 | 2026-07-25 | “This feature is available for Enterprise plans only (both self-serve and sales-assisted). … Eligible Enterprise organizations can enable HIPAA-ready configuration directly from organization settings—no sales or legal cycle required. … This is a one-way decision. … If your organization signed a BAA for Claude API usage before December 2, 2025, that agreement only covers API usage. … Cowork is not yet covered under Anthropic's BAA.” |
| R12 | API and data retention | 200 | 2026-07-25 | “Claude Code: Claude Code is not covered under HIPAA readiness. … Partner-operated platforms: Amazon Bedrock and Google Cloud's Agent Platform. … Claude Platform on AWS and Microsoft Foundry: HIPAA readiness is not available on these platforms. … Retained data is never used for model training without your express permission. … Do not include PHI in JSON schema definitions. … Files retained until explicitly deleted.” |
| R13 | How long do you store my data? (consumer) | 200 | 2026-07-25 | “This article is about our consumer products such as Claude Free, Pro, Max and when accounts from those plans use Claude Code. For our commercial products such as Claude for Work and the Anthropic API, see here. … we retain data associated with that submission for 5 years.” |
| R14 | How long do you store my organization's data? (commercial) | 200 | 2026-07-25 | “Where you have provided feedback to us (e.g. by submitting feedback through our thumbs up/down button or sent bug reports), we retain data associated with that submission for 5 years.” What we checked: Full-text check of this article for model-training language: zero occurrences of the word "train" except as the anchor text of an outbound link to the separate training article (7996868). Recorded because an earlier draft of this round used that absence to argue no commercial no-training commitment is published — which is wrong: the commitment is in article 7996868 and in the Commercial Terms (R17, R18). The absence is a true fact about THIS article only. |
| R15 | Agent Skills overview | 200 | 2026-07-25 | “Upload your own Skills as zip files through Settings > Features. Available on Pro, Max, Team, and Enterprise plans with code execution enabled. Custom Skills are individual to each user. They are not shared organization-wide and cannot be centrally managed by admins. … Agent Skills is not covered by ZDR arrangements. … Use Skills only from trusted sources … Treat like installing software.” |
| R16 | What are skills? (Help Center) | 200 | 2026-07-25 | “For Team and Enterprise plans, organization Owners can provision skills for all users. … Centralized management for organizations: Team and Enterprise plan Owners can provision skills organization-wide, ensuring consistent workflows across teams without requiring individual setup from each user.” What we checked: Directly contradicts R15, fetched the same day. This pair is itself the evidence behind a Stale-risk finding. |
| R17 | Anthropic Commercial Terms of Service §B (Customer Content) | 200 | 2026-07-25 | “Anthropic may not train models on Customer Content from Services. “Inputs” means submissions to the Services by Customer or its Users and “Outputs” means responses generated by the Services to Inputs (Inputs and Outputs together are “Customer Content”).” What we checked: Fetched during the post-review correction pass, after an independent reviewer showed that this round had wrongly downgraded the commercial no-training claim on the strength of a partial search. |
| R18 | Is my data used for model training? (commercial scope) | 200 | 2026-07-25 | “By default, we will not use your inputs or outputs from our commercial products (e.g. Claude for Work, Anthropic API, Claude Gov, etc.) to train our models. If you explicitly report feedback or bugs to us (e.g. via our thumbs up/down feedback button), or otherwise choose to allow us to use your data, then we may use your chats and coding sessions to train our models. … When you provide us feedback via our thumbs up / down button, we will store the entire related conversation, including any content, custom styles, conversation preferences, or model settings, in our secured back-end for up to 5 years.” What we checked: The article this round should have checked first. It reconciles the API documentation's conditional phrasing (“without your express permission”) with the Commercial Terms' flat prohibition: the feedback button is how express permission is given. |
Credibility & provenance round · fetched 2026-07-27
SC5 / Operation Soundings, CG4 (Wave 2 — credibility, provenance, currency mechanism). Fetches taken to discharge charter §4.4 before any chip moved or any negative claim was made: a claim of the form “the source does not say X” may not stand until the document where X would live has actually been searched. Two of these fetches produced the round's blocking finding — a term this curriculum had been presenting in quotation marks as Anthropic's own is on neither primary source.
| # | Primary source | HTTP | Date | Confirming quote & what we checked |
|---|---|---|---|---|
| R23 | HIPAA-ready Enterprise plans (Help Center) | 200 | 2026-07-27 | “The HIPAA-ready Enterprise offering includes many of the features available on standard Enterprise plans—but enabling HIPAA doesn't bring every feature under your BAA. Features fall into three categories: covered by your BAA, available but not covered, and disabled. … PHI should only be processed through covered features, so it's important for administrators to know which features fall in which category and to configure their workspace accordingly. … The Implementation Guide for HIPAA Entities on the Anthropic Trust Center lists every feature's status and is the authoritative source. … Note: You'll need to request access to view the Implementation Guide. Requests from domains matching existing customer accounts are approved automatically. … Additionally, Cowork is not yet covered under Anthropic's BAA.” What we checked: Searched specifically for the phrase “Eligible Services”: NOT PRESENT on this page. This page's vocabulary is covered / available but not covered / disabled. Also searched for “beta” (absent), a feature table (absent — the page defers to the gated Implementation Guide), and any 400-error enforcement (absent; Enterprise is administrator-responsibility, not API-enforced). Freshness: the page displays the relative string “Updated this week” and no absolute date, so it is not citable as a dated source. Fidelity caveat recorded honestly: the first fetch returned a summary rather than the source and a second transcription-only pass was used; sentence-level wording was consistent across both passes, but capitalization of UI button labels is not guaranteed and is not quoted here. |
| R24 | API and data retention (Claude Docs) | 200 | 2026-07-27 | “The following table lists which Claude API features are eligible for ZDR and HIPAA readiness arrangements. … Each eligibility column uses three values: Yes: The feature is fully eligible under the arrangement. … Yes (qualified): Your prompts and Claude's outputs are not stored, but a bounded technical artifact (named in the Details column) is retained briefly for the feature to function. No: The feature is not eligible. … Beta features: Features in beta are generally not covered under the BAA unless explicitly listed as eligible in the feature eligibility table. … Your signed BAA is the official source of truth for which features are covered. The API also enforces these restrictions automatically. When a HIPAA-enabled organization sends a request that includes a non-eligible feature, the API returns a 400 error to prevent accidental use of features not covered by your BAA … Under HIPAA readiness, the API blocks requests that include a "No" feature and returns a 400 error. Under ZDR, the API does not block these features; using one is a choice to step outside your ZDR arrangement for that specific data … Claude Fable 5 and Claude Mythos 5 are designated Covered Models … and require 30-day data retention; ZDR is therefore not available for either model.” What we checked: Searched specifically for the phrase “Eligible Services”: NOT PRESENT on this page either. Combined with R23, that phrase is on NEITHER primary source, which is the basis for retitling est_hipaa_eligible_services. Three corrections to our own prior reading, recorded because they change what we may claim: (1) the eligibility table is THREE-valued (Yes / Yes (qualified) / No), not per-feature Yes/No as an earlier pass described it; (2) the table is PUBLIC — fetched anonymously, no login — so it, not the gated Implementation Guide, is the reader's first stop on the API path; (3) the 400 enforcement is HIPAA-only and the page says so explicitly — under ZDR the API does not block. Also: the beta-features sentence must not be truncated at “explicitly listed”; the qualifier “as eligible in the feature eligibility table” is part of it. Cowork does not appear on this page at all — the “not yet covered” statement is sourced to R23 only. |
| R25 | Statement on the US government directive to suspend access to Fable 5 and Mythos 5 (dated Jun 12, 2026) | 200 | 2026-07-27 | “The US government, citing national security authorities, has issued an export control directive to suspend all access to Fable 5 and Mythos 5 by any foreign national … we must abruptly disable Fable 5 and Mythos 5 for all our customers to ensure compliance … Our understanding is that the government believes it has become aware of a method of bypassing, or 'jailbreaking' Fable 5. … We believe this is a misunderstanding and are working to restore access as soon as possible.” What we checked: Fetched to receipt a node that had been asserting this episode from the working-group document alone. Two corrections follow from it. (1) The mechanism was stated wrongly: our node said access was suspended “under export-control review”, which describes a pending assessment; the source describes an issued export control DIRECTIVE that Anthropic complied with. (2) Searched this page — the document class where a restoration announcement would live — for a restoration date: NOT PRESENT. It says only “working to restore access as soon as possible”. Our node's “restored around July 1, 2026” is therefore unsourced as to date, though restoration itself is demonstrable from R26. |
| R26 | Models overview (Claude Docs) | 200 | 2026-07-27 | “Claude Fable 5 is generally available on the Claude API, Amazon Bedrock, Claude Platform on AWS, Google Cloud, and Microsoft Foundry beginning June 9, 2026. Claude Mythos 5 is not generally available: it is offered in limited availability to approved customers in Project Glasswing, beginning the same day. … Claude Mythos 5 and Claude Mythos Preview are offered separately for defensive cybersecurity workflows as part of Project Glasswing. Access is invitation-only and there is no self-serve sign-up.” What we checked: Searched for any trace of the June 2026 suspension: NONE (`suspend`, `export`, `directive`, `restor` — zero hits each). That absence is the node's own teaching point — a status page shows the present, not the history — and it is now demonstrated rather than asserted. Mythos 5's limited availability is Project Glasswing, invitation-only with no self-serve sign-up, and the page states its purpose in the same sentence: defensive cybersecurity workflows. CORRECTION TO THIS RECEIPT, made at the CG4 source-check leg: an earlier draft of this row asserted that the page does NOT describe Mythos 5 as being for defensive-cybersecurity work, and the node deleted that detail on the strength of it. The page says so plainly, in the sentence immediately preceding the clause quoted above. The Project Glasswing detail is an ADDITION to what the node already had right, not a correction of it. Recorded here rather than silently repaired because a receipt that once certified a false absence is exactly the artifact a reader should be able to audit. |
| R27 | What are skills? (Help Center) — displayed “Updated over 2 weeks ago” | 200 | 2026-07-27 | “For Team and Enterprise plans, organization Owners can provision skills for all users. Skills provisioned in this way appear automatically in every team member's skills list and can be set as enabled or disabled by default. This allows organizations to: Distribute approved workflows consistently across all employees / Ensure teams use standardized procedures and best practices / Deploy new capabilities without requiring individual uploads … Anthropic skills — These are skills created and maintained by Anthropic, such as enhanced document creation for Excel, Word, PowerPoint, and PDF files. … Skills vs. projects — Projects provide static background knowledge that's always loaded when you start chats within them. Skills provide specialized procedures that activate dynamically when needed and work everywhere across Claude. … The Skills Directory features professionally-built skills from partners like Notion, Figma, Atlassian, and others.” What we checked: Three enumerated searches, all negative and all load-bearing. (1) “skill-creator”: ZERO hits in any spelling — this page does not describe it as built-in or otherwise. (2) Security/trust language (security, untrusted, malicious, caution, third-part*): the only hit is an unrelated Related-Articles link title. This consumer-facing page introduces the third-party Skills Directory with NO caution, audit advice or trust language, while the platform documentation carries a strong warning — a documentation gap, not a contradiction. (3) “preferences”: absent; the page contrasts Skills with custom instructions, projects and MCP only. Method note: a first transcription pass silently dropped trailing clauses and an entire sub-list; these quotes come from raw HTML retrieval, which also preserved the clause “though you can attach executable scripts to custom skills for more advanced functionality” — this page's only acknowledgement that Skills execute code, presented as a feature. |
| R28 | Agent Skills overview (Claude Docs) | 200 | 2026-07-27 | “Custom Skills are individual to each user. They are not shared organization-wide and cannot be centrally managed by admins. … claude.ai does not support centralized admin management or org-wide distribution of custom Skills. … Custom Skills are shared workspace-wide: all workspace members can access them. … Claude API: Workspace-wide. All workspace members can access uploaded Skills. … Claude Code: Personal (~/.claude/skills/) or project-based (.claude/skills/). Can also be shared through Claude Code Plugins. … Agent Skills is not covered by ZDR arrangements. Skill definitions and execution data are retained according to Anthropic's standard data retention policy. … Use Skills only from trusted sources: those you created yourself or obtained from Anthropic. Skills give Claude new capabilities through instructions and code, which also means a malicious Skill can direct Claude to invoke tools or execute code in ways that don't match the Skill's stated purpose. … Anthropic also publishes open-source Skills in the skills repository” What we checked: This page is one half of the site's documented contradiction (see R27 for the other). Both were re-fetched the same day, 2026-07-27, and both still stand — the contradiction reproduces two days after CG2 first documented it. New this round: a freshness asymmetry. R27 displays “Updated over 2 weeks ago” and links to a dedicated article, “Provision and manage skills for your organization”; this page carries no freshness string. That is a reason to suspect THIS page is the stale one — but it is a suspicion, not a finding, and neither page is dated precisely enough to settle it. Second enumerated search: “skill-creator” — ZERO hits here too. Third: searched for distribution paths that DO exist, because our curriculum was telling readers to assume a Skill reaches only its author — three are documented (API workspace-wide, Claude Code Plugins, and the enterprise Skills API), so that instruction was wrong for every surface except claude.ai. |
| R29 | Skills for enterprise (Claude Docs) | 200 | 2026-07-27 | “The Skills API provides workspace-scoped distribution. Skills uploaded through the API are available to all workspace members. … Upload through the Skills API for workspace-wide access. … Document the Skill in your internal registry with purpose, owner, and version. … Custom Skills do not sync across surfaces. Skills uploaded to the API are not available on claude.ai or in Claude Code, and vice versa. Each surface requires separate uploads and management.” What we checked: Fetched to test whether an organization-level deployment path exists at all. It does, but only via the Skills API and only workspace-scoped; no claude.ai admin push is documented here. The cross-surface non-sync sentence is the one most likely to surprise this group: a Skill built in one place does not appear in the others. |
| R32 | Provision and manage skills for your organization (Help Center) — displayed “May 29, 2026”, tooltip “Updated over 2 months ago” | 200 | 2026-07-27 | “This article explains how organization owners can provision skills for everyone in their organization, and how to scope skills to specific groups using plugins. … When you upload a skill through organization settings, it becomes available to everyone in your organization in Customize > Skills. Individual members no longer need to upload the same skill themselves. … Organization-wide skill management is available to Team and Enterprise plans. … Skills appear for each member in Customize > Skills, organized into three sections: Personal skills: Skills the member has created or uploaded. Shared with you: Skills colleagues have shared directly with a member. … Organization skills: Skills an owner has provisioned and skills members have shared organization-wide. … Skill sharing: Members can share a skill with specific colleagues. … Share with organization: Members can publish a skill to the organization directory, where anyone can find and install it. Both toggles are off by default. … Note: Only owners can add or remove organization-wide skills. Individual users cannot delete provisioned skills, though they can toggle them off for their own use. … Important: There's no approval workflow for org-wide sharing. If you enable Share with organization, any member can publish a skill to the directory without review. … The audit log doesn't capture the contents of shared skills—only the share event itself. There's no admin dashboard to browse or inspect the contents of skills shared between members.” What we checked: THE DOCUMENT CG4 SHOULD HAVE FETCHED AND DID NOT. Our stale-risk node asserted that “neither page draws that distinction” while its own prose named this article — as a freshness signal — without anyone opening it. That is a §4.4 violation on the round that made §4.4 its banner, and it was caught by the adversarial leg, not by us. What the page settles: the apparent contradiction is largely a CATEGORY confusion. An owner-provisioned skill (uploaded via Organization settings) and a member's personal skill are different objects, and the clause “Individual members no longer need to upload the same skill themselves” presupposes exactly the per-user world the platform documentation describes. What the page does NOT do is rescue the platform sentence: it documents a member-driven path to organization-wide distribution (“Share with organization”), so “They are not shared organization-wide” is false as stated and true only of the DEFAULT posture — both toggles ship off. “Cannot be centrally managed by admins” half-survives: no admin dashboard inspects shared-skill CONTENTS, but owners control both sharing toggles and share events reach the audit log and Compliance API. Freshness ordering, which decides which page to believe: “What are skills?” = updated ~2 weeks ago; this admin article = May 29 2026 (~2 months); the platform overview carries no freshness string at all and is the laggard. |
| R30 | Use Claude Cowork safely (Help Center) — displayed “Updated over a week ago” | 200 | 2026-07-27 | “Local MCP servers bundled with plugins and desktop extensions run on your computer with the same permissions as any other program you run. … Desktop extensions (MCPs) and plugins expand what Claude can do, but each one introduces new ways for attacks to reach Claude. Plugins bundle together skills, connectors, and sub-agents into a single package, which means installing one can significantly expand Claude's scope of action. … Stick to verified extensions from the Claude Desktop directory, and carefully evaluate the permissions any extension or plugin requests before installing. … Important: Network egress permissions don't apply to the web fetch or web search tools or MCPs, including Claude in Chrome.” What we checked: Enumerated search for any statement that an MCP server accesses only what it has been granted and nothing more — the claim our glossary was making. Every sentence containing “grant*” or “only access” was read: six hits, none of which makes that claim about MCP servers. The page runs the OPPOSITE direction on both counts — local MCP servers run with the user's full permissions, and network-egress permissions explicitly do not apply to MCPs. The glossary claim was not merely unsourced; it was contradicted. |
| R31 | How long do you store my data? (consumer) — displayed “Updated over 3 weeks ago” | 200 | 2026-07-27 | “This article is about our consumer products such as Claude Free, Pro, Max and when accounts from those plans use Claude Code. For our commercial products such as Claude for Work and the Anthropic API, see here. … If you allow us to use your chats or coding sessions to improve Claude, we may retain your data in a de-identified format for up to 5 years in our model training pipelines. This retention period only applies to new or resumed chats after the model training setting has been enabled. … You control your chats with Claude and can delete your conversations at any time. When you delete a conversation it's: Removed from your chat history immediately / Deleted from our back-end storage systems within 30 days … If you decide to turn off the model improvement setting, we will not use your previous or new chats or coding sessions for future model training.” What we checked: Enumerated search for a published automatic retention window in the setting-OFF state, done two ways: every duration string on the page was collected (30 days deletion purge; 5 years training-on; 2 years usage-policy-violation content; 7 years classification scores; 5 years feedback) and NONE is tied to the setting being off; and the OFF paragraph was read in full — it makes a USE statement, not a RETENTION statement. So the honest claim is “no automatic retention window for the off state is published in this article”, NOT “data is not retained when the setting is off”. One structural finding, verified in raw HTML across three independent retrievals: the page carries an H2 heading “Standard Retention Timeframe” with NO body text under it — the section that would state a default window is present as a heading and empty. Recorded because it explains the absence without excusing it. |
Comprehension & craft round · fetched 2026-07-28
SC5 / Operation Soundings, CG5 (Wave 3 — comprehension & craft). Fetches taken before any graph text moved: the consumer training-toggle label, default and Claude Code scope (A1); the prebuilt-Skills surface qualifier (A2); and the multi-source chip adoption sweep (D1), where every URL added to a node's source list rests on a fetch from this round — adding one from memory is the defect the multi-source field exists to prevent. Negative claims in the checked notes state the search that grounds them (charter §4.4 as extended by amendment 5).
| # | Primary source | HTTP | Date | Confirming quote & what we checked |
|---|---|---|---|---|
| R33 | How do I change my model improvement privacy settings? (Privacy Center) — page dated “March 16, 2026” | 200 | 2026-07-28 | “Under Help Improve Claude, click the button to toggle it off/on … If you decide to turn off the model training setting, we will not use any new chats and coding sessions you have with Claude for future model training. … This article is about our consumer products such as Claude Free, Pro, Max and when accounts from those plans use Claude Code.” What we checked: The settings walkthrough names the toggle's printed label: “Help Improve Claude”, under Settings > Privacy (claude.ai/settings/data-privacy-controls). Searched the full article for “Improve Claude for everyone” — the phrase does not appear; the label this curriculum and the group's doc had been circulating is on neither this page nor the storage article (R34). Also searched this article for the toggle's default state (“default”, “by default”, “new account”) — the page gives set/unset instructions only and states no default. The off-state commitment and the article's scoping sentence both cover coding sessions from consumer accounts, which is the Claude Code scope the toggle node was missing. |
| R34 | How long do you store my data? (consumer) — displayed “Updated over 3 weeks ago” | 200 | 2026-07-28 | “This article is about our consumer products such as Claude Free, Pro, Max and when accounts from those plans use Claude Code. … This retention period only applies to new or resumed chats after the model training setting has been enabled. … Your Incognito chats are not used to improve Claude, even if you have enabled Model Improvement in your Privacy Settings.” What we checked: Re-fetch of the R31 page one day on, for the toggle node's label and default. The retention arithmetic is unchanged (30-day back-end deletion on delete; up to 5 years de-identified while training is on; 2-year / 7-year safety windows). This page's own names for the setting are “the model training setting”, “the model improvement setting” and “Model Improvement in your Privacy Settings” — searched the article for “Improve Claude for everyone”: not present. Searched for a stated default (“default”, “by default”, “new account”): none stated. The “Standard Retention Timeframe” heading still carries no body text (checked under that heading in the returned article). |
| R35 | Agent Skills overview (Claude platform docs) | 200 | 2026-07-28 | “Using Skills through the API requires the code execution tool, whose container Skills run in, and one beta header: skills-2025-10-02 - Enables Skills functionality. … Pre-built Agent Skills: These Skills are active when you create documents. Claude uses them with no setup required. … The pre-built document Skills (PowerPoint, Excel, Word, PDF) are not available in Claude Code … Agent Skills is not covered by ZDR arrangements. Skill definitions and execution data are retained according to Anthropic's standard data retention policy.” What we checked: Fetched for the prebuilt-Skills surface qualifier (A2) and the Skills-ZDR chip. The “no setup required” sentence sits in the claude.ai section — it is a claude.ai-surface statement, not a product-wide one. The API path has stated prerequisites (code execution tool + the skills-2025-10-02 beta header; plus files-api-2025-04-14 when files move in or out of the container). Claude Code does not carry the prebuilt document Skills at all. Pre-built Skills are also available on Claude Platform on AWS and Microsoft Foundry (on Foundry, only with a Hosted-on-Anthropic deployment). |
| R36 | API and data retention (Claude platform docs) | 200 | 2026-07-28 | “Retained data is never used for model training without your express permission. … There are two ways to set up HIPAA-ready API access. Most organizations can enable it directly in the Claude Console with Anthropic's standard BAA; organizations that require a negotiated BAA should work with their account team. … Do I still need ZDR if I have HIPAA readiness? No. … HIPAA readiness is enforced at the organization level. If you need both HIPAA-ready and general-purpose API access, use separate organizations for each. … Claude Code: Claude Code is not covered under HIPAA readiness.” What we checked: D1 adoption-sweep fetch — this is the named-but-unchipped document behind claims on four nodes (est_hipaa_code_zdr_cowork's API-path ruling; est_hipaa_two_baa_configs' self-serve Console path, ZDR-not-also-needed answer, and org-level enforcement; est_retention_commercial_no_training's express-permission sentence; est_retention_api_zdr already chips it). Every quoted passage above was re-verified verbatim on the live page before the URL was added to any node's source list. The Console mechanics sentence ('In Claude Console > Settings > Privacy, organization admins with the HIPAA management permission see a HIPAA compliance card') and the Enterprise-with-ZDR Claude Code exception both reproduce as the nodes state them. |
| R37 | HIPAA-ready Enterprise plans (Claude Help Center) — displayed “Updated this week” | 200 | 2026-07-28 | “Team plans and individual plans (Free, Pro, and Max) can't enable HIPAA. … Additionally, Cowork is not yet covered under Anthropic's BAA. … This feature is available for Enterprise plans only (both self-serve and sales-assisted). … Only the Primary Owner of the organization can accept the BAA and enable HIPAA.” What we checked: D1 adoption-sweep fetch — the named-but-unchipped document behind est_hipaa_never_covered's plan-eligibility and Cowork claims (the node chipped only the API docs while its title's plan claim lives here). The December 2, 2025 BAA-cutover sentences also reproduce verbatim, which re-verifies the claim behind open_hipaa_prior_baa_scope's framing. |
| R38 | How long do you store my organization's data? (Privacy Center) — displayed “Updated over 3 weeks ago” | 200 | 2026-07-28 | “Deleted from our back-end storage systems within 30 days … This article is about our commercial products such as Claude for Work and the Anthropic API. … Where you have provided feedback to us (e.g. by submitting feedback through our thumbs up/down button or sent bug reports), we retain data associated with that submission for 5 years.” What we checked: D1 adoption-sweep fetch — the Privacy Center article behind est_retention_api_zdr's 30-day deletion figure (the R21 quote's home page, previously cited in prose but unchipped) and one of est_retention_feedback_5yr's three sources. The node's claim that the 5-year feedback sentence is identical on the commercial and consumer articles was re-verified rather than assumed: the sentence above was fetched from BOTH pages this date (this row and the consumer article) and is byte-identical — the claim stands, so nothing was 'corrected'. |
| R39 | What are skills? (Claude Help Center) — displayed “Updated over 2 weeks ago” | 200 | 2026-07-28 | “Skills are folders of instructions, scripts, and resources that Claude loads dynamically to improve performance on specialized tasks. … These are skills created and maintained by Anthropic, such as enhanced document creation for Excel, Word, PowerPoint, and PDF files. … Anyone can create skills by writing instructions in Markdown—no coding required for simple skills, though you can attach executable scripts to custom skills for more advanced functionality.” What we checked: D1 adoption-sweep fetch — the Help Center companion est_skills_definition names in prose but did not chip. The article's own definition sentence corroborates the node's claim from the app-facing side; it does not mention SKILL.md — searched the full returned article for "SKILL.md" and the case variants "skill.md" / "Skill.md": 0 occurrences (that structural fact lives on the platform docs page, which the node already chips) — so each chip carries a distinct part of the claim. |
| R40 | Is my data used for model training? (Privacy Center, commercial) — page dated “March 16, 2026” | 200 | 2026-07-28 | “By default, we will not use your inputs or outputs from our commercial products (e.g. Claude for Work, Anthropic API, Claude Gov, etc.) to train our models. … If you explicitly report feedback or bugs to us (e.g. via our thumbs up/down feedback button), or otherwise choose to allow us to use your data, then we may use your chats and coding sessions to train our models. … When you provide us feedback via our thumbs up / down button, we will store the entire related conversation, including any content, custom styles, conversation preferences, or model settings, in our secured back-end for up to 5 years. … Feedback data does not include raw content from connectors (e.g. Google Drive), including remote and local MCP servers, though data may be included if it's directly copied into your conversation with Claude.” What we checked: D1 adoption-sweep fetch — the article carrying est_retention_feedback_5yr's entire-conversation scope, training permission, and connector limit (named in the node's prose, unchipped until now), and est_retention_commercial_no_training's policy statement + its feedback exception. All five claims re-verified verbatim on the live page before the URL joined either node's source list. |
Additions build-out round · fetched 2026-07-28
SC5 / Operation Soundings, CG6 (Wave 4 — additions build-out + convergence close), under the ratified RareAnthropic ADR-001 (audience falsifier (i) AND (ii) both hold). These fetches close the four NEEDS-REFETCH items standing since the CG1 triage. Every one is an ADDITION: a round-open grep established that the graph was SILENT on Cowork observability, on the M365 add-ins, and on Agent Skills openness — an earlier work-order draft had framed them as corrections, which was wrong and is recorded as such. The two enumerated negative searches (R47, R48) carry a method note that matters for every future §4.4 search on these hosts: search the .md source or extracted body, never the rendered HTML, which embeds the whole docs nav tree and produces false positives in both directions. Second batch (R49-R61) adds the additions-register facts: Anthropic's own user-responsibility clause, Claude for Nonprofits, the Agent Skills open-standard/no-SDK pair, and two retention facts a triage pass found genuinely missing (incognito chats are NOT private on Team/Enterprise; the per-workspace 30-day override). Three premises supplied to these legs were corrected BY the legs and the corrections are recorded in the checked fields: the 'companion' ToS sentence is D.3's own second sentence with a dropped 'must notify its Users' clause (R49); the anthropics/skills repo is not a stub (R57); and a triage pass returned 3 ALREADY-PRESENT of 7 candidate facts, preventing duplicate nodes (R60).
| # | Primary source | HTTP | Date | Confirming quote & what we checked |
|---|---|---|---|---|
| R41 | Claude Cowork | Claude by Anthropic — page carries date stamps 'Apr 9, 2026' and 'Feb 24, 2026' (neither attached to the quoted sentence) | 200 | 2026-07-28 | “Admin controls, usage analytics, Analytics API and OpenTelemetry observability available. … Activity streams to your SIEM through OpenTelemetry. … Cowork activity is not yet captured in audit logs or Compliance API.” What we checked: Verified the product page's Cowork-observability claims verbatim, including the roadmap-flagged word 'yet'. The sentence names exactly TWO surfaces — audit logs and Compliance API — and says nothing about data exports; the node was written to that scope rather than the broader one the work order had assumed. Backs est_folder_access_cowork_no_compliance_api; supplies the SIEM/OTel pointer used by est_folder_access_cowork_otel_export. |
| R42 | Monitoring — Claude Cowork docs; no date stamp on page | 200 | 2026-07-28 | “Cowork exports events via the OTel logs/events protocol, giving you visibility into user prompts, model responses, API requests, tool usage, and errors. … Monitoring is available for Team and Enterprise plans. OTel monitoring requires Claude desktop app version 1.1.4173 or later. … The OTel exporter runs inside the Cowork VM, so it is subject to the session's egress rules. … By default, events include metadata only. User prompt content, model response text, and tool details are included only when you enable them with the otlpContentCapture setting. … Events are only exported when an admin configures the OTLP endpoint … User prompt content is included only when you enable userPrompts in otlpContentCapture … user.email is always included in event attributes, so configure your telemetry backend to filter or redact it if this is a concern” What we checked: Verified all four export preconditions (Team/Enterprise · admin-configured OTLP endpoint · desktop >= 1.1.4173 · organization-run collector) and the DOCS side of the content-default question. Note for the contradiction node: the metadata-only default is stated TWICE on this page (§Events and §Security and privacy), so it is not a stray sentence — the page is internally consistent. Backs est_folder_access_cowork_otel_export and one half of est_folder_access_cowork_otel_content_default. |
| R43 | Monitor Claude Cowork activity with OpenTelemetry | Claude Help Center — stamped 'Updated over a week ago' (no absolute date shown) | 200 | 2026-07-28 | “OpenTelemetry monitoring for Claude Cowork is available on Team and Enterprise plans. It requires Claude Desktop version 1.1.4173 or later. … When you connect Claude Cowork to an OpenTelemetry collector, Cowork streams events covering: User prompts. The full text of prompts users submit to Cowork. … User prompt content is included in events by default. If your organization has policies against logging prompt content to your SIEM, configure filtering or redaction in your collector before routing events downstream. … Tool parameters may include sensitive values. … User email addresses are included in event attributes. … Events are only exported when an admin configures an OTLP endpoint. No data flows by default.” What we checked: Verified the HELP-CENTRE side of the content-default question — 'included in events by default', with the burden of filtering placed on the customer downstream. ENUMERATED SEARCH (§4.4): the strings 'otlpContentCapture' and 'metadata only' do not appear anywhere in this article. Together with R42 this establishes a live disagreement between two current Anthropic pages answering the SAME conditional (once an endpoint is configured, does prompt text flow?) — the help-centre's own fourth bullet handles the not-configured case separately, so the obvious reconciliation fails. Backs est_folder_access_cowork_otel_content_default (STALE-RISK). |
| R44 | Work across M365 apps — Claude Docs (no visible date stamp) | 200 | 2026-07-28 | “Open Settings in each add-in and turn on "Let Claude work across files". Pro and Max plans have this on by default; Team and Enterprise plans default to off. … Claude uses the Excel, PowerPoint, Word, and Outlook add-ins to read from and write to open files and email threads. … Context transfers between apps automatically, so you don't need to copy and paste information manually. … Inputs and outputs are deleted from Anthropic's backend within 30 days of receipt or generation, except in cases outlined in How long do you store my organization's data?. … The Claude for M365 add-ins do not inherit custom data retention settings your organization may have set, and activity is not included in Enterprise audit logs, the Compliance API, or data exports. Chat history is stored locally in your browser, not on Anthropic's servers, and can be cleared from Settings at any time. … Claude can only read from and write to files that are currently open in Excel, PowerPoint, or Word, and the email or event currently open in Outlook. … Claude cannot create, open, close, or switch files directly.” What we checked: Verified the plan-tier default asymmetry (Pro/Max on by default vs Team/Enterprise off), automatic cross-app context transfer, the 30-day backend deletion window, browser-local chat history, open-files-only scope, and the three-way exclusion from Enterprise audit logs / Compliance API / data exports. Backs est_cc_office_addin_data_flow; the exclusion sentence also backs est_cc_compliance_api_coverage_gap. |
| R45 | Use Claude for Excel — Claude Docs (no visible date stamp) | 200 | 2026-07-28 | “Data is cached for a number of hours after deletion so users can access context in recently closed workbooks. … Chat history is stored locally in your browser using IndexedDB. Conversations are not stored on Anthropic's servers, are not synced across devices, and can be cleared from Settings at any time. Reinstalling the add-in or switching between Claude add-ins does not remove it. … Claude for Excel does not inherit custom data retention settings your organization might have set. Activity is not included in Enterprise audit logs or the Compliance API. … Only use Claude for Excel with trusted spreadsheets. Files from external sources can contain hidden instructions that manipulate the add-in into extracting data, modifying records, or performing destructive actions. … Testing has identified scenarios where Claude for Excel can be manipulated to extract sensitive information, modify critical data, or perform destructive actions if allowed to act without verification. … Claude for Excel is not recommended for: Final client deliverables without human review. Audit-critical calculations without verification. Models containing highly sensitive or regulated data without proper controls.” What we checked: Verified Anthropic's own untrusted-spreadsheet warning and its self-reported red-team result, the IndexedDB local-history detail (survives reinstall, not synced), the unquantified post-deletion cache, non-inheritance of custom retention settings, the audit-log/Compliance-API exclusion, and the three not-recommended-for cases including regulated data. Backs est_cc_office_addin_data_flow and its cross-link to est_cc_prompt_injection. |
| R46 | Configure a custom OpenTelemetry collector for Office agents — Claude Help Center (page stamped May 15, 2026; filed under Team and Enterprise plans → Analytics and usage) | 200 | 2026-07-28 | “You can route full audit telemetry from Office agents to your own OpenTelemetry (OTEL) collector. … Custom OTEL collectors are available to Claude Enterprise organizations and to direct-provider deployments (Amazon Bedrock, Google Vertex AI, or a gateway). … Your collector receives all span attributes, including those carrying user-generated content (prompt text, tool inputs and outputs, document URLs, and filenames). No attributes are redacted or filtered. Assistant response text is not included in the emitted span data. Your organization owns this data. … When a custom endpoint is configured, telemetry goes exclusively to your collector. Spans aren't dual-sent to Anthropic. … user.message [content] The user's prompt (first 4000 characters) … document.url [content] URL of the open Office document … agent.surface sheet (Excel), doc (Word), slide (PowerPoint), mail (Outlook)” What we checked: Verified the decisive unredacted-export paragraph verbatim and in full, Enterprise-only availability, exclusive routing (no dual-send to Anthropic), and the [content]-tagged span attributes carrying prompt text, tool I/O, document URLs and user email. Article body extracted from raw HTML because the rendered navigation tree pollutes naive text search. Backs est_cc_office_addin_otel_unredacted. |
| R47 | Compliance API — Claude platform docs (no visible date stamp) | 200 | 2026-07-28 | “The Compliance API gives Claude Enterprise customers programmatic access to their organization's Activity Feed, the directory of users, roles, and groups across every linked organization, the effective settings in force for each organization, and, for claude.ai organizations, the underlying chats, files, and projects. … The content endpoints (chats, files, projects, and project attachments) serve claude.ai data only.” What we checked: ENUMERATED NEGATIVE SEARCH (§4.4). Fetched the page's own markdown source (compliance-api.md, 6,544 bytes) rather than the nav-polluted HTML. Terms searched: Cowork · Claude Code · Excel · Office · add-in · addin · M365 · Microsoft · PowerPoint · Outlook. Result: ZERO occurrences of all terms except 'Claude Code' (1 occurrence — a pointer to the Claude Code Analytics API, not a coverage statement). The page carries no limitations section and no list of excluded products. METHOD NOTE for future §4.4 searches: naive grep over these sites' raw HTML returns false positives everywhere (this page's HTML contains 3 'Cowork' and 77 'Claude Code' from the rendered docs nav tree) — search the .md source or extracted body, never the HTML. Backs est_cc_compliance_api_coverage_gap. |
| R48 | Access the Compliance API — Claude Help Center (stamped 'Updated over 3 weeks ago'; no absolute date shown) | 200 | 2026-07-28 | “The Compliance API lets your organization programmatically pull activity feed events, chat data, and file content across all your Claude deployments. … The Compliance API is available to Claude Enterprise plans, excluding Public Sector organizations, and Claude Platform customers. … The Compliance API now includes audit log events, giving you a full view across all your Claude deployments.” What we checked: ENUMERATED NEGATIVE SEARCH (§4.4). Article body isolated from HTML (54 body lines before the 'Related Articles' heading). Terms searched: Cowork · Claude Code · Excel · Office · add-in · addin · M365 · Microsoft · PowerPoint · Outlook. Result: ZERO occurrences in body prose. PRECISION NOTE, because a flat 'zero mentions' would be falsifiable by any reader with Ctrl-F: Cowork, Office and Claude Code DO each appear once, in the Related-Articles link list AFTER the article ends — two of them pointing at OpenTelemetry monitoring guides that do not frame themselves as compliance gaps. The nuance strengthens the finding rather than weakening it. Also captured the affirmative breadth claim 'a full view across all your Claude deployments', which sits directly opposite two documented product-side exclusions. Backs est_cc_compliance_api_coverage_gap. |
| R49 | Anthropic Commercial Terms of Service — page stamped "Effective June 17, 2025" | 200 | 2026-07-28 | “D.3. Limitations of Outputs; Notice to Users. It is Customer's responsibility to evaluate whether Outputs are appropriate for Customer's use case, including where human review is appropriate, before using or sharing Outputs. Customer acknowledges, and must notify its Users, that factual assertions in Outputs should not be relied upon without independently checking their accuracy, as they may be false, incomplete, misleading or not reflective of recent events or information. Customer further acknowledges that Outputs may contain content inconsistent with Anthropic's views.” What we checked: Section letter D.3 and heading verified verbatim on the live page; effective date read off the page header. CORRECTION TO AN EARLIER LEG: the 'factual assertions' sentence is not a separate companion statement — it is the SECOND SENTENCE of D.3, and the earlier transcription silently dropped its lead-in 'Customer acknowledges, AND MUST NOTIFY ITS USERS, that'. That clause is load-bearing: it makes staff notification a contractual obligation for Commercial customers, not merely good practice. Restored here in full. Backs est_cc_user_responsibility. NOTE: this quote carries a standing #needs-human rider — a human must verify it character-for-character against the live page before it is treated as quotable, because ToS section letters drift across revisions. |
| R50 | Anthropic Consumer Terms of Service — page stamped "Effective October 8, 2025" | 200 | 2026-07-28 | “You should not rely on any Outputs or Actions without independently confirming their accuracy.” What we checked: Located under section 4 'Inputs, Outputs, Actions, and Materials' -> sub-heading 'Reliance on Outputs and Actions', the third of five bulleted acknowledgements. Section number and effective date confirmed on page. The effective-date gap against R49 (2025-06-17 vs 2025-10-08) is why the node forbids blending the two instruments. Backs est_cc_user_responsibility. |
| R51 | Getting started with Claude for nonprofits — tutorial page; NO visible publication or updated date anywhere on the page | 200 | 2026-07-28 | “Team plan: $8/user/month Enterprise plan: $10/user/month … Both plans include access to the same models as our Team and Enterprise offerings, with a minimum of 2 seats for teams under 150. … Who is eligible? 501(c)(3) organizations, K–12 schools, and qualifying healthcare organizations. Who is not eligible? Government agencies, political campaigns, higher education institutions, and healthcare systems. … We partner with Goodstack for nonprofit verification.” What we checked: Prices, seat minimum and both eligibility lists verified verbatim from extracted body text (not raw HTML). Confirmed by date-probe that the page carries no publication or updated stamp — which is why the node says 'confirmed present on 2026-07-28' rather than 'confirmed current'. THE FINDING THAT MATTERS FOR THIS AUDIENCE: the page admits 'qualifying healthcare organizations' and excludes 'healthcare systems' while defining NEITHER term — the node quotes both and routes to Anthropic sales rather than asserting that a rare-disease clinical organization qualifies. New fact not previously held: verification runs through a third-party partner, Goodstack. Backs est_cc_nonprofit_pricing. |
| R52 | Claude for Nonprofits — Anthropic news post, dated "Dec 2, 2025" | 200 | 2026-07-28 | “Claude for Nonprofits includes three things: discounted access of up to 75% to Claude, connectors to new nonprofit tools—Blackbaud, Candid, and Benevity—and a free course, AI Fluency for Nonprofits, designed to help teams use AI more effectively. … Nonprofits are now eligible for a discount of up to 75% on Team and Enterprise plans. … In partnership with GivingTuesday, we've developed a free course, AI Fluency for Nonprofits.” What we checked: Date, the 75% framing, the three partner connectors and the GivingTuesday course verified verbatim. This page frames the offer as a PERCENTAGE while R51 gives ABSOLUTE per-seat prices — two live pages framing one offer two ways, which is the classic precursor to drift and the reason the node ships with a currency caution. Backs est_cc_nonprofit_pricing. |
| R53 | Agent Skills Overview — agentskills.io | 200 | 2026-07-28 | “The Agent Skills format was originally developed by Anthropic, released as an open standard, and has been adopted by a growing number of agent products. The standard is open to contributions from the broader ecosystem.” What we checked: Backs half (a) of est_skills_open_standard; the openness statement sits under a section headed 'Open development'. Adopter list re-confirmed live in the client carousel: OpenAI Codex, Gemini CLI, GitHub Copilot, VS Code, Cursor, Mistral AI Vibe, Junie (JetBrains), Databricks Genie Code, Snowflake Cortex Code, Goose (Block), Spring AI — all 11 stand, four under more specific product names than previously recorded, alongside ~34 further entries. Multi-vendor portability is therefore materially verified, not merely asserted. |
| R54 | Specification — agentskills.io (rendered page) | 200 | 2026-07-28 | “Use the skills-ref reference library to validate your skills: skills-ref validate ./my-skill” What we checked: Backs half (b) of est_skills_open_standard: the ONLY tooling the normative spec names is a validator, not an SDK. Also verified the follow-on 'This checks that your SKILL.md frontmatter is valid and follows all naming conventions', and that the optional per-skill license field reads 'License name or reference to a bundled license file'. The negative enumeration was run separately against the .md source endpoint — see R55. |
| R55 | Specification — agentskills.io (.md source endpoint, 7,986 bytes) | 200 | 2026-07-28 | “| `license` | No | License name or reference to a bundled license file.” What we checked: ENUMERATED SEARCH (charter 4.4) backing the negative claims in est_skills_open_standard. Run against the .md SOURCE endpoint, never rendered HTML, so site navigation cannot produce false positives in either direction. ZERO occurrences: 'open standard', 'open-standard', 'openness', 'open source', 'open-source', 'royalty', 'RFC', 'normative', 'versioning', 'v1', 'governance', 'steering', 'committee', 'working group', 'consortium', 'foundation', 'maintainer', 'contribut', 'copyright', 'trademark', 'patent', 'SDK', 'Anthropic', 'MIT', 'CC0'. Non-zero hits each context-checked: 'version' x2 and '1.0' x3 are ALL inside the optional per-skill metadata example — no spec version exists; 'license'/'LICENSE' x11 are ALL the optional per-skill frontmatter field — no spec licence exists; 'MUST' x8 / 'SHOULD' x5 are per-field constraints. CONFIRMS all four negatives: the normative spec carries no openness statement, no spec version, no governance body and no spec licence — the openness claim lives on the overview page and the engineering blog, not in the specification itself. |
| R56 | Equipping agents for the real world with Agent Skills — Anthropic Engineering, published Oct 16 2025; the open-standard line carries an update stamp of December 18, 2025 | 200 | 2026-07-28 | “We've published Agent Skills as an open standard for cross-platform portability.” What we checked: Backs half (a) from Anthropic's own side, and disambiguates half (b): the SDK sentence reads 'Agent Skills are supported today across Claude.ai, Claude Code, the Claude Agent SDK, and the Claude Developer Platform' — placing the Claude Agent SDK as a CONSUMER of the format alongside claude.ai and Claude Code, not as an SDK for the standard. No occurrence of 'skills-ref' on this page. |
| R57 | anthropics/skills — GitHub repository, described 'Public repository for Agent Skills' | 200 | 2026-07-28 | “This repository contains Anthropic's implementation of skills for Claude. For information about the Agent Skills standard, see agentskills.io.” What we checked: PARTIALLY DISCONFIRMS a premise supplied to this leg. The work order asserted the old Anthropic-org spec path 'is a stub pointing out'. It is NOT a stub: the repo is live and still hosts a ./spec folder, example Skills and a skill template. What IS true is the outward pointer quoted above. est_skills_open_standard states the hand-off accurately — of the STANDARD, not an evacuation of the repository. Recorded because an unverified premise supplied to a fetch leg already produced one defect earlier in this round. |
| R58 | agentskills/agentskills — GitHub organization repository | 200 | 2026-07-28 | What we checked: Existence/status verification only — NOTHING is quoted from this URL, and the quote field is deliberately empty rather than carrying an editorial note, because this file's fidelity rule reserves that field for published words alone. Confirms the neutral-home half of the hand-off claim in est_skills_open_standard: the org resolves live (HTTP 200) and the specification page's own validator link targets github.com/agentskills/agentskills/tree/main/skills-ref — the spec's tooling is hosted under the neutral org, not under anthropics/. |
| R59 | Use incognito chats — Claude Help Center, stamped 'Updated over a week ago' | 200 | 2026-07-28 | “While incognito chats aren't saved to your chat history, they are retained for either 30 days (default), or longer in accordance with your organization's custom data retention setting (available for Enterprise plans). … Incognito chats are included in organizational data exports available to account Owners. … Incognito chats are included in the Compliance API (available for Enterprise plans). … Incognito mode is currently only available for chats outside of projects … … Once closed, incognito chats cannot be reopened.” What we checked: Sole source for the new node est_retention_incognito_not_private. Read from extracted body text, not raw HTML, per the support.claude.com rule. THE POINT OF THE NODE: the feature's NAME teaches the wrong conclusion to exactly this audience — staff reach for the ghost icon before typing something sensitive, and on Team/Enterprise the chat is retained at least 30 days, appears in organizational data exports available to account Owners, and appears in the Compliance API. Also verified verbatim: 'Incognito chats are temporary conversations that aren't saved to your chat history or to Claude's memory'; 'Incognito chats are available to all Claude users'; 'Incognito chats are not used for training'. |
| R60 | API and data retention — Claude Docs (.md source endpoint, 47,607 bytes), sections on model-specific retention and enabling 30-day retention for a workspace | 200 | 2026-07-28 | “Organizations with a ZDR arrangement can make Claude Fable 5 and Claude Mythos 5 available in a specific workspace by enabling 30-day retention for that workspace only. Other workspaces in the organization keep zero data retention. … The 30-day data retention requirement applies wherever Covered Models are offered. … HIPAA readiness is enforced at the organization level. If you need both HIPAA-ready and general-purpose API access, use separate organizations for each.” What we checked: Primary source for the new node est_retention_workspace_30day_override. Fetched as .md source per the platform.claude.com rule. Turns an apparently org-wide all-or-nothing retention choice into a structural one — directly how a patient-data group should lay out workspaces — while carrying the trap symmetrically: the enabled workspace is no longer zero-retention and its data is machine-inspected. The final sentence independently RE-CONFIRMS triage item 3 (org-level HIPAA enforcement) as ALREADY-PRESENT in est_hipaa_two_baa_configs, so no duplicate node was built. |
| R61 | Covered Models — Claude Help Center, stamped 'Updated over 4 weeks ago' (reached via a 301 to the canonical slug) | 200 | 2026-07-28 | “Automated review by default. Retained data is assessed by automated safety systems designed to flag harmful content. … Prompts and model completions are retained for at least 30 days and then automatically deleted, unless they are subject to a safety investigation or we are legally required to maintain them. … zero data retention is not available in workspaces, Claude Enterprise organizations, or third-party platforms (e.g., Azure Subscriptions) where Covered Models can be accessed.” What we checked: Second chip on est_retention_workspace_30day_override — the retention floor and the automated-inspection consequence of enabling the override. Read from extracted body text after following a 301. Also resolves triage item 1 (Covered-Model review process) as GENUINELY-MISSING from the graph: an enumerated grep for 'automated review|automated safety|safety system|assessed by|flag harmful|capability threshold' returned nothing. Its key fact is used inside the workspace node where it does decision work rather than spent as a separate build; a standalone Covered-Model-review node remains the strongest candidate for a later round. |
Fix-leg re-verification round · fetched 2026-08-03
SC5 / Operation Soundings, CG7 fix leg. One node, both of its sources, every quoted passage — the mandated currency re-verify before touching a ⚑ compliance-critical claim (E1: the node's plain-language line and the HIPAA domain gloss had flattened the API-path hedge into 'no sales call needed', a permissive overreach — an organization that requires a negotiated BAA does need its account team). Both pages were fetched fresh per the CG6 method note (the docs page as .md source, the support article as extracted body). The finding: the hedge stands verbatim on the live page, and all thirteen quoted passages across the two sources stand unchanged — so the chip stays CONFIRMED, the node's retrieved date moves to 2026-08-03, and only the flattened summary wording changes (hedge restored at both ends). No claim moved; a summary was brought back into agreement with its source. F7 (Phase-4 repairs) extended this round with R64: the source-check leg's regression sweep found the Cowork OTel desktop-version floor had SPLIT on the help-centre page while the docs page still carries the un-split sentence — a live source-pair divergence on a ⚑ node, corrected on est_folder_access_cowork_otel_export the day it was found, stated per-source with the divergence recorded rather than explained (the R42/R43 divergence-node discipline).
| # | Primary source | HTTP | Date | Confirming quote & what we checked |
|---|---|---|---|---|
| R62 | API and data retention — Claude Docs (.md source) | 200 | 2026-08-03 | “There are two ways to set up HIPAA-ready API access. Most organizations can enable it directly in the Claude Console with Anthropic's standard BAA; organizations that require a negotiated BAA should work with their account team.” What we checked: E1 currency re-verify, API path. The hedge sentence stands verbatim — 'Most organizations', not 'all', with the negotiated-BAA carve-out routed to the account team — confirming the correction direction: the node's plain-language 'no sales call needed' was the permissive flattening, not a source change. Also re-verified verbatim on this fetch, completing the API-path passages quoted on est_hipaa_two_baa_configs: the Console mechanics ('In Claude Console > Settings > Privacy, organization admins with the HIPAA management permission see a HIPAA compliance card'), the ZDR FAQ ('Do I still need ZDR if I have HIPAA readiness?' → 'No.'), the broader-safeguards sentence ('applies a broader set of privacy and security safeguards than ZDR … rather than requiring immediate deletion'), and the org-level enforcement pair ('HIPAA readiness is enforced at the organization level. If you need both HIPAA-ready and general-purpose API access, use separate organizations for each.'). |
| R63 | HIPAA-ready Enterprise plans — Claude Help Center, stamped 'Updated over a week ago' | 200 | 2026-08-03 | “Eligible Enterprise organizations can enable HIPAA-ready configuration directly from organization settings—no sales or legal cycle required. The Business Associate Agreement (BAA) is included in the flow as click-to-accept, so there's no separate document to sign and return.” What we checked: E1 currency re-verify, Enterprise path. Read from extracted body text per the CG6 method note. The 'no sales or legal cycle required' sentence is source-verbatim but scoped to ELIGIBLE ENTERPRISE organizations — it cannot be generalized across both paths, which is exactly the over-generalization the flattened summary committed. All remaining Enterprise-path passages quoted on est_hipaa_two_baa_configs re-verified verbatim on this fetch: the eligibility banner ('Enterprise plans only (both self-serve and sales-assisted)'), the plan exclusions ('Team plans and individual plans (Free, Pro, and Max) can't enable HIPAA'), the Primary-Owner restriction ('Only the Primary Owner … Other Owners or Admins can't complete this flow on the org's behalf'), the settings reset ('Enabling HIPAA resets certain settings across your organization. Some configurations return to defaults as part of the transition to a HIPAA-ready state.'), the one-way pair ('This is a one-way decision. Once HIPAA is enabled and the BAA is accepted, the change can't be reversed from organization settings.' / 'irreversible organization transition'), the unmodifiable standard BAA ('a standard agreement and can't be modified'), and the December 2, 2025 cutover pair ('before December 2, 2025 … only covers API usage—it does not extend to the HIPAA-ready Enterprise plan' / 'BAAs signed after December 2, 2025 can cover both'). |
| R64 | Monitor Claude Cowork activity with OpenTelemetry — Claude Help Center, stamped 'Updated today' on the 2026-08-03 fetch | 200 | 2026-08-03 | “It covers Cowork sessions that run in the cloud (on desktop, web, and mobile) as well as local desktop sessions. Monitoring sessions in the cloud requires Claude Desktop version 1.22209.3 or later, and monitoring local desktop sessions requires Claude Desktop version 1.1.4173 or later.” What we checked: N3 (CG7 source-check APPLY): the help centre has SPLIT the desktop floor by session location; the R42 docs page (claude.com/docs/cowork/monitoring.md, also fetched fresh 2026-08-03, HTTP 200) still carries the un-split sentence 'OTel monitoring requires Claude desktop app version 1.1.4173 or later' and — enumerated — the string '1.22209' appears NOWHERE on the docs page (grep over the full .md source; the help page's earlier un-split sentence 'It requires Claude Desktop version 1.1.4173 or later' is GONE from the live article body). Direction: the node's previous un-split statement had become PERMISSIVE once the help centre moved — an org on a desktop build in [1.1.4173, 1.22209.3) would overstate its cloud-session monitoring coverage. Node updated to state both sources' current text with the divergence recorded, not explained, and the stricter reading recommended. Every other passage the node quotes re-verified on the same two fetches (23 spans; 22 exact, 1 identical save a terminal period at a list-item boundary — fidelity-ledger micro-class). The model-response 1.17377 floor stands on the docs page; it does not appear on the help page (enumerated: 0 hits). |
Terminal convergence fix-leg round · fetched 2026-08-03
SC5 / Operation Soundings, CG8 fix leg — the terminal round's four re-fetches, each framed as a question put to the live page. Two source-drift findings were confirmed and repaired: CG8-F1 (the Compliance API docs page now documents transcripts of Cowork sessions that run in Anthropic-managed cloud environments, while the Cowork product page still says verbatim that Cowork activity is not yet captured — a live three-way divergence across the docs page, the product page, and the still-Cowork-silent help-centre article; treated per the R42/R43 divergence discipline, chips re-adjudicated per node) and CG8-F2 (the consumer training toggle's printed label changed a second time, 'Help Improve Claude' → 'Help Improve our AI models'). Every quote field below is verbatim source text; everything of ours is in the checked field.
| # | Primary source | HTTP | Date | Confirming quote & what we checked |
|---|---|---|---|---|
| R65 | Compliance API — Claude Docs (.md source) | 200 | 2026-08-03 | “The content endpoints (chats, files, projects, project attachments, and remote sessions) serve claude.ai data only, including transcripts of Cowork sessions that run in Anthropic-managed cloud environments. … Read chat content, attachments, and remote Cowork session transcripts; delete chats, files, and projects on demand. Compliance Access Key required. … All /v1/compliance/* endpoints share a rate limit of 600 requests per minute per parent organization; the remote session endpoints carry an additional request budget on top.” What we checked: QUESTION put to the page: does R47's enumerated negative ('Cowork: absent from the article body') still hold, and does the content-endpoints sentence still name only chats/files/projects/attachments? ANSWER: no, twice. The page grew 6,544 → 6,792 bytes; 'Cowork' now occurs 2× in the body — both coverage-AFFIRMING (the extended content-endpoints sentence quoted here, and a nav card naming 'remote Cowork session transcripts') — and the overview paragraph now lists 'remote sessions' among what the API serves. Scope, read precisely: the new coverage names transcripts of Cowork sessions run in Anthropic-MANAGED CLOUD environments; no sentence on this page claims local desktop session coverage, and no sentence names Enterprise audit-log capture of Cowork activity. The rest of R47's enumeration still reproduces: Claude Code 1 hit (the analytics-API pointer, not a coverage statement); Excel/Office/add-in/addin/M365/Microsoft/PowerPoint/Outlook 0 hits each. The page still carries no limitations section and no list of excluded products. This fetch is the docs side of the three-way divergence recorded on est_folder_access_cowork_no_compliance_api and est_cc_compliance_api_coverage_gap. |
| R66 | Claude Cowork — product page | 200 | 2026-08-03 | “Cowork activity is not yet captured in audit logs or Compliance API. … Admin controls, usage analytics, Analytics API and OpenTelemetry observability available. … Activity streams to your SIEM through OpenTelemetry.” What we checked: QUESTION put to the page: does the R41 sentence — the single source behind the node titled 'Cowork activity is not yet captured in audit logs or the Compliance API' — still stand? ANSWER: yes, verbatim and unchanged (1 occurrence), as do both observability sentences. So as of this date the product page flatly denies Compliance API capture while the docs page (R65, fetched the same session) documents cloud-session Cowork transcripts in the Compliance API's content endpoints — the two pages disagree, and the graph records the disagreement rather than adjudicating it. The product-page side of the divergence. |
| R67 | Access the Compliance API — Claude Help Center | 200 | 2026-08-03 | “The Compliance API lets your organization programmatically pull activity feed events, chat data, and file content across all your Claude deployments. … The Compliance API now includes audit log events, giving you a full view across all your Claude deployments. … The Compliance API is available to Claude Enterprise plans, excluding Public Sector organizations, and Claude Platform customers.” What we checked: QUESTION put to the page: is the help-centre Compliance API article's body still Cowork-silent (R48's enumerated negative)? ANSWER: yes — 0 occurrences of 'Cowork' in the article body (1,610 chars of body text isolated from the raw HTML before the Related Articles list); the only 'Cowork' on the page remains the undescribed Related-Articles link to the OTel monitoring guide, exactly as R48 recorded. Both R48 anchor sentences re-verified verbatim. So the help-centre article is the third, silent corner of the divergence: it neither affirms nor denies Cowork coverage while its two sibling pages disagree. Negative-claim enumeration: terms searched in the body — Cowork 0 · 'across all your Claude deployments' 2 (both quoted here). |
| R68 | How do I change my model improvement privacy settings? — Anthropic Privacy Center, stamped 'Updated today' on this fetch | 200 | 2026-08-03 | “Under Help Improve our AI models, click the button to toggle it off/on … If you decide to turn off the model training setting, we will not use any new chats and coding sessions you have with Claude for future model training.” What we checked: QUESTION put to the page: does the toggle's printed label still read 'Help Improve Claude' (R33, 2026-07-28)? ANSWER: no — the page, stamped 'Updated today', now prints 'Help Improve our AI models' in both the desktop and mobile walkthroughs (2 occurrences); 'Help Improve Claude' 0 hits; the older 'Improve Claude for everyone' still 0 hits. SECOND label drift on this field (CG5 corrected 'Improve Claude for everyone' → 'Help Improve Claude'; today's fetch corrects it again). Everything substantive is UNCHANGED and re-verified: the navigational path (Settings > Privacy, both walkthroughs), the off-state use commitment quoted here, and the article's consumer-plans-plus-Claude-Code scoping. Default state still unstated (searched: 'default' 0 · 'by default' 0 · 'new account' 0). |
| R69 | Both sources of est_retention_consumer_training_toggle, re-fetched together at fix time — the settings walkthrough (quoted) and the storage article | 200 | 2026-08-10 | “Under Help Improve our AI models, click the button to toggle it off/on” What we checked: QUESTION at fix time, a week after R68 found the drift: does the page still print this label, or has it moved a third time before the correction could land — and does the node's OTHER source still hold, since a partial re-verify would make the retrieved: bump dishonest? ANSWER, settings page: still 'Help Improve our AI models' (6 hits, desktop + mobile); both superseded labels 0; path unchanged. Default absence re-enumerated: 'by default'/'new account'/'turned on'/'turned off'/'opt-in' all 0; bare 'default' 6 raw hits, each inspected, all site furniture, 0 in body (CG8-F6 rule, permissive direction). ANSWER, storage article (10023548): 5-year figure, 30-day deletion, off-state 'future model training' commitment, consumer-plus-Claude-Code scope, and the present-but-empty 'Standard Retention Timeframe' heading all still stand; BOTH labels 0 hits there — it names none, saying only 'the model improvement setting'. So the label is a SINGLE-SOURCE fact resting on the walkthrough alone, part of why it has moved twice. Backs retrieved: 2026-08-10; R68 remains the discovery receipt. |
Norrsken C1 — safety reconciliation · fetched 2026-09-16
Current-source checks of the inherited CG8 repairs. Historical receipts remain dated evidence; new source movement is recorded, not backdated. Human clinical/privacy review is still outstanding.
| # | Primary source | HTTP | Date | Confirming quote & what we checked |
|---|---|---|---|---|
| R70 supersedes R69 | Model-improvement settings | 200 | 2026-09-16 | “Help Improve our AI models” What we checked: QUESTION / RESULT: Does the label or scope differ? Settings > Privacy still uses this label for consumer accounts, including Max. Safety-classifier uses are expressly excepted. New-account default terms were enumerated separately; no default is inferred. |
| R71 supersedes R34 | Consumer retention | 200 | 2026-09-16 | “within 30 days” What we checked: QUESTION / RESULT: What do ON, OFF and deletion promise? De-identified training retention can reach five years; deletion has a 30-day backend statement with safety/legal exceptions. OFF is a training-use commitment, not a stated automatic deletion window. |
| R72 | Consumer training and feedback | 200 | 2026-09-16 | “flagged for safety review” What we checked: QUESTION / RESULT: What sits outside the general toggle? Safety review and explicit opt-in are listed; feedback has a separate section. This source does not support an unconditional no-training guarantee when the toggle is off. |
| R73 supersedes R40 | Commercial training and feedback | 200 | 2026-09-16 | “If you explicitly report feedback or bugs to us” What we checked: QUESTION / RESULT: Are feedback and bugs the only permission routes? The article also names other explicit permission. Commercial no-training is the default; feedback can retain the related conversation up to five years. No contract-waiver conclusion is inferred. |
| R74 supersedes R38 | Organization retention | 200 | 2026-09-16 | “retain data associated with that submission for 5 years” What we checked: QUESTION / RESULT: Does the feedback duration differ by scope? The article gives five years for data associated with feedback/bug submissions. This does not establish every organization's negotiated contract or an exhaustive list of training permissions. |
| R75 supersedes R17 | Commercial Terms | 200 | 2026-09-16 | “Anthropic may not train models on Customer Content from Services.” What we checked: QUESTION / RESULT: Does the public contract retain its prohibition? Section B does. The separate feedback clause and privacy policy do not justify this curriculum declaring a particular executed contract waived by a click. |
| R76 supersedes R36 | API retention | 200 | 2026-09-16 | “without your express permission” What we checked: QUESTION / RESULT: Does the API documentation still qualify training by express permission? Yes. This is a commercial/API statement, not a consumer Max default. |
| R77 supersedes R65 | Compliance API overview | 200 | 2026-09-16 | “The content endpoints” What we checked: QUESTION / RESULT: What changed since August? The overview now names local and remote sessions, plus Microsoft 365 and Science. It distinguishes audit-log export, telemetry and transcript retrieval; the cloud-only reading is superseded. |
| R78 supersedes R67 | Compliance API access and exclusions | 200 | 2026-09-16 | “Coverage also includes Cowork” What we checked: QUESTION / RESULT: Is the help article still Cowork-silent? No: Cowork and Claude Code are named, Microsoft 365 and Science are beta. Public Sector and other explicitly listed exclusions prevent an all-deployments inference. |
| R79 supersedes R66 | Cowork product page | 200 | 2026-09-16 | What we checked: QUESTION / RESULT: Does the old product-page denial survive? Search of the complete raw document and extracted main found zero occurrences of not yet captured and Compliance API. This is an enumerated absence, not positive evidence of coverage; the positive evidence comes from the API documents. |
| R80 | Session transcripts and limits | 200 | 2026-09-16 | “No local session data is captured” What we checked: QUESTION / RESULT: Which session classes and exclusions apply? Enterprise local Cowork/Claude Code and remote Cowork are documented; Microsoft 365 and Science are beta. Local HIPAA-readiness and ZDR sessions are excluded, as are the specified API-key/third-party and Code-web cases. API capture is distinct from local chat history and separate audit-log exports. |
| R81 supersedes R42 | Cowork monitoring documentation | 200 | 2026-09-16 | “By default, events include metadata only.” What we checked: QUESTION / RESULT: Does the content-default disagreement persist? Yes: docs describe opt-in content capture and the 1.1.4173 floor. Admin endpoint, collector and restart prerequisites remain. Do not infer the help page agrees. |
| R82 supersedes R64 | Cowork monitoring help | 200 | 2026-09-16 | “User prompt content is included in events by default.” What we checked: QUESTION / RESULT: Does help still disagree? Yes on prompt-content defaults and its split cloud/local desktop-version floors. It now also links Cowork to the Compliance API; a collector is not the only oversight route. |
| R83 supersedes R46 | Office agents custom collector | 200 | 2026-09-16 | “No attributes are redacted or filtered.” What we checked: QUESTION / RESULT: What is the separate collector exposure? Content-bearing traces remain unredacted; assistant response text is excluded. Collector routing, deployment scope and the truncated content fields were checked. API availability does not erase this separate data path. |
| R84 supersedes R44 | Work across Microsoft 365 apps | 200 | 2026-09-16 | “This coverage is in public beta” What we checked: QUESTION / RESULT: Does the old API exclusion still hold? No: Enterprise add-in sessions enter the Compliance API in public beta when enabled, while audit-log/data-export statements remain separate. Browser history and API capture cannot be equated. |
| R85 supersedes R45 | Claude for Excel | 200 | 2026-09-16 | “This coverage is in public beta” What we checked: QUESTION / RESULT: Does Excel agree? Yes: Enterprise API coverage is public beta and audit-log exclusion remains. The local-browser-history statement is not a guarantee that no server-side compliance transcript exists. |
Norrsken C2 — collaborator course entry refresh · fetched 2026-09-17
C2-entry re-fetch of the planning/13 primary-source list, asked as questions before the course build. No source flip found: toggle label, 30-day deletion window, five-year feedback retention and the non-exclusive permission language all hold vs the C1 round. Two sources (Max plan; sensitive-data access) receive their FIRST receipts here. Human clinical/privacy review remains outstanding (clinician-review-scheduled).
| # | Primary source | HTTP | Date | Confirming quote & what we checked |
|---|---|---|---|---|
| R86 | Max plan (consumer) | 200 | 2026-09-17 | “designed for users who collaborate with Claude frequently and need more usage” What we checked: QUESTION / RESULT: What does the Max page itself say about data/training? Nothing — the page describes tiers (5x/20x Pro usage), session-based five-hour and weekly usage limits, and features; it carries no data-privacy or training statement. Course consequence: Max data posture must be taught from the privacy articles (R89/R90), never inferred from the plan page. |
| R87 | Sensitive data / conversation access (consumer) | 200 | 2026-09-17 | “thoughtful about sharing highly sensitive personal details” What we checked: QUESTION / RESULT: Who can view conversations and what does the page advise? A small number of personnel involved in model training can review de-linked data; safety classifiers can flag conversations for trust-and-safety uses. The page's own caution list names financial information, health records or medical information, passwords, confidential documents. Scope stated on-page: Claude Free, Pro, Max (and Claude Code under those accounts). Supports the course's never-paste-PHI stance from the vendor's own advice. |
| R88 supersedes R73 | Commercial training and feedback | 200 | 2026-09-17 | “or otherwise choose to allow us to use your data” What we checked: QUESTION / RESULT: Are feedback and bugs the only permission routes? No — the article keeps the broader 'otherwise choose to allow' clause; commercial no-training remains the default; feedback stores the entire related conversation up to 5 years. The C1 non-exclusive rule stands unchanged. |
| R89 supersedes R71 | Consumer retention | 200 | 2026-09-17 | “within 30 days” What we checked: QUESTION / RESULT: ON vs OFF vs deletion? ON: de-identified retention up to 5 years for model training. OFF: no use of previous or new chats or coding sessions for future training (a training-use commitment, not an automatic deletion window). Deletion: back-end within 30 days. Exceptions: safety violations up to 2 years with classification scores up to 7; legal/dispute holds; feedback submissions 5 years. Unchanged vs R71. |
| R90 supersedes R70 | Model-improvement settings | 200 | 2026-09-17 | “Help Improve our AI models” What we checked: QUESTION / RESULT: Label, path, scope, exceptions? Settings > Privacy still carries this exact label; applies to Claude Free, Pro, Max and Claude Code under those plans; safety-classifier-flagged conversations remain excepted from the toggle. Unchanged vs R70. |
Norrsken C6 round 3 — skills-source movement (the STALE-RISK chips fired) · fetched 2026-09-19
The standing quality loop's round-3 accuracy leg re-fetched the five standing sources (R86-R90: all hold verbatim, receipts in the round record) and, for the first time, the skills/OTel STALE-RISK items' own source pages directly. The movement found is exactly where the chips pointed: the Skills org-management article replaced its governance model (a three-state Publishing policy with owner review superseded the 'no approval workflow' language two nodes quoted as current, and the sharing default flipped to on-by-default for Team plans, with two vendor defaults dated to flip again 2026-10-02), and the What-are-skills page now names a reference Python SDK for platform implementers against a formerly categorical negative. These rows carry the fix leg's own re-fetches backing the two re-grounded nodes; the OTel pair was re-verified unchanged (round record A3-3). Human clinical/privacy review remains outstanding (clinician-review-scheduled).
| # | Primary source | HTTP | Date | Confirming quote & what we checked |
|---|---|---|---|---|
| R91 supersedes R15 | Provision/manage skills for your organization | 200 | 2026-09-19 | “If you haven't chosen a setting, it switches to 'Requires review' on October 2, 2026.” What we checked: QUESTION / RESULT: Has the org-management model moved since 2026-07-27? YES, materially (round finding A3-1). The 'no approval workflow for org-wide sharing' sentence both skills nodes quoted is GONE, superseded by a three-state Publishing policy ('Requires review': an owner must approve each submission, every later version re-reviewed, no self-approval / 'Open': published without review / 'Off'). Sharing default reversed: 'The Skill sharing toggle is on by default for Team plans and for Enterprise plans that haven't set a skills preference'; HIPAA/regulated configs stay off by default. Three paths became four (adds 'Shared with a group'). New: a 'Turn off User-created skills' kill-switch; security scanning 'off by default until October 2, 2026. From that date it's on by default, where available, for Enterprise organizations' with 'Scanning isn't available for organizations using customer-managed encryption keys (CMEK), zero data retention (ZDR), or HIPAA configurations'. Survives lightly reworded: the audit log 'doesn't capture the contents of shared skills or plugins—only the share event itself'; sharing events logged as role_assignment in audit log + Compliance API; 'Organization-wide skill management is available to Team and Enterprise plans.' |
| R92 | What are skills? | 200 | 2026-09-19 | “A reference Python SDK is also available for developers implementing skills support in their own platforms.” What we checked: QUESTION / RESULT: Owner provisioning still documented, anything else moved? Owner provisioning holds ('For Team and Enterprise plans, organization Owners can provision skills for all users'). Two new items (round findings A3-2, A3-6): the reference-Python-SDK sentence quoted here — an implementer's kit, which contradicted the open-standard node's formerly categorical 'there is no Agent Skills SDK' and drove its ⛩-ruled narrowing to 'no SDK to install to WRITE one'; and 'Skills are available for users on Free, Pro, Max, Team, and Enterprise plans' (recorded, not yet taught). |
| R93 supersedes R29 | Agent Skills overview (platform docs) | 200 | 2026-09-19 | “They are not shared organization-wide and cannot be centrally managed by admins.” What we checked: QUESTION / RESULT: Is the stale sentence still live? YES, verbatim — and R91's movement makes it wronger than before (owners now control provisioning, sharing toggles, a Publishing review queue, a kill-switch, and from 2026-10-02 scanning). Also still live: 'Available on Pro, Max, Team, and Enterprise plans with code execution enabled' (grounds est_skills_upload_scoping, which holds). The contradiction the STALE-RISK chip marks persists. |
| R94 supersedes R53 | Agent Skills overview (agentskills.io) | 200 | 2026-09-19 | “The Agent Skills format was originally developed by Anthropic, released as an open standard, and has been adopted by a growing number of agent products.” What we checked: QUESTION / RESULT: Does the standard's own site name an SDK? NO — zero occurrences of 'SDK' in the page body (fetched to adjudicate A3-2; the open-standard node's spec-grounded negative holds against its own sources). The one-line definition also holds: 'Agent Skills are a lightweight, open format for extending AI agent capabilities with specialized knowledge and workflows.' Client showcase composition has shifted since 2026-07-28 (e.g. 'ChatGPT & Codex' as a combined entry; new entrants) — recorded, not re-enumerated this round. |
| R95 supersedes R55 | Agent Skills specification | 200 | 2026-09-19 | “Use the skills-ref reference library to validate your skills” What we checked: QUESTION / RESULT: Does the specification name an SDK, and is the validator still the only tooling? Zero occurrences of 'SDK'; skills-ref remains the sole named tool ('This checks that your SKILL.md frontmatter is valid and follows all naming conventions'); a Skill remains a directory with a SKILL.md. The per-skill license field remains optional and per-skill ('Specifies the license applied to the skill'). Supports the narrowed claim: nothing to install to write a Skill. |
Text in “quotation marks” is published by the cited source, word for word. Anything labelled What we checked is our own verification note, not the source's words — including the cases where what we found was an absence. This log is derived from the working group's currency & provenance report, which is canonical and is re-verified before each Anthropic contact call. Confirm current specifics with your Anthropic contact before relying on any of this for a compliance decision.