Remove internal notes from CAISI content

Author: davidahmann

docs/agent-action-bom/index.html

@@ -206,7 +206,6 @@ <h1>What Is an Agent Action BOM?</h1>
           rule, and proof coverage.
         </p>
         <p class="body">Last updated: May 7, 2026</p>
-        <!-- Source notes: this page avoids external statistics, recent events, and vendor capability claims. Verify any added factual or current claims before publishing. -->
       </section>
 
       <section class="section page-nav" aria-labelledby="page-nav-heading">

docs/approve-actions-not-prompts/index.html

@@ -212,7 +212,6 @@ <h1>Approve Actions, Not Prompts</h1>
           blocked.
         </p>
         <p class="body">Last updated: May 6, 2026</p>
-        <!-- Source notes: this page avoids external statistics, recent events, and vendor capability claims. Verify any added factual or current claims before publishing. -->
       </section>
 
       <section class="section page-nav" aria-labelledby="page-nav-heading">

docs/audit-evidence-ai-assisted-sdlc/index.html

@@ -213,7 +213,6 @@ <h1>Audit Evidence for AI-Assisted SDLC</h1>
           or release paths.
         </p>
         <p class="body">Last updated: May 7, 2026</p>
-        <!-- Source notes: this page avoids external statistics, recent events, and vendor capability claims. Verify any added factual or current claims before publishing. -->
       </section>
 
       <section class="section page-nav" aria-labelledby="page-nav-heading">

docs/blog/ai-coding-agents-from-suggestions-to-actions/index.html

@@ -223,7 +223,6 @@ <h1>AI Coding Agents Are Moving From Suggestions to Actions</h1>
           automatically rise with it.
         </p>
         <p class="body">Last updated: May 7, 2026</p>
-        <!-- Source notes: this field note avoids external statistics, recent events, and vendor capability claims. Verify any added factual or current claims before publishing. -->
       </section>
 
       <section class="section page-nav" aria-labelledby="page-nav-heading">

docs/blog/ai-engineering-maturity-model/index.html

@@ -315,11 +315,11 @@ <h2 id="the-better-system-pattern">The better pattern</h2>
           when the organization claims a higher level than its controls support.
         </p>
         <p>
-          Each level should also have an exit test. Do not claim repo-aware if
-          critical commands are still discovered by memory. Do not claim
-          governed delivery if non-allow outcomes can still execute. Do not
-          claim dark-factory capability if approvals, retries, and proof still
-          depend on manual reconstruction after the fact.
+          Each level should also have an exit test. A workflow is not
+          repo-aware if critical commands are still discovered by memory. It is
+          not governed delivery if non-allow outcomes can still execute. It is
+          not dark-factory capable if approvals, retries, and proof still depend
+          on manual reconstruction after the fact.
         </p>
       </section>
 
@@ -335,9 +335,9 @@ <h2 id="how-to-use-the-model-without-theater">How to use the model without theat
         </p>
         <p>
           Used properly, the model becomes a planning tool. It tells leaders
-          what to build next, what not to claim yet, and which classes of work
-          are safe to widen. That is much more useful than broad statements
-          about being "AI ready."
+          what to build next, which labels are premature, and which classes of
+          work are safe to widen. That is much more useful than broad
+          statements about being "AI ready."
         </p>
         <p>
           The practical pattern is to pair every maturity claim with three

docs/blog/authority-risk/from-ai-content-risk-to-ai-authority-risk/index.html

@@ -223,7 +223,6 @@ <h1>From AI Content Risk to AI Authority Risk</h1>
           OAuth access, and a downstream pivot into a workplace environment.
         </p>
         <p class="body">Last updated: May 6, 2026</p>
-        <!-- Source notes: Incident claims are limited to Vercel's public April 2026 bulletin and contemporaneous public reporting. Do not expand this article with unverified claims about source-code, CI/CD, npm, or cloud compromise. -->
       </section>
 
       <section class="section page-nav" aria-labelledby="page-nav-heading">

docs/blog/authority-risk/when-agent-social-engineering-becomes-action-hijacking/index.html

@@ -221,7 +221,6 @@ <h1>When Agent Social Engineering Becomes Action Hijacking</h1>
           infrastructure.
         </p>
         <p class="body">Last updated: May 7, 2026</p>
-        <!-- Source notes: Claims are limited to The Register's May 5, 2026 Hannah Fry/OpenClaw reporting, Zscaler ThreatLabz's DeepSeek-Claw malware writeup, and Bishop Fox's AIMap page. Do not quote marketplace-malware percentages without rechecking primary sources. Do not claim any specific product would have prevented these events. -->
       </section>
 
       <section class="section page-nav" aria-labelledby="page-nav-heading">
@@ -232,7 +231,7 @@ <h2 id="page-nav-heading">In this field note</h2>
           <a href="#authority-risk">Why this is authority risk</a>
           <a href="#map">What teams should map</a>
           <a href="#action-bom-row">Agent Action BOM row</a>
-          <a href="#do-not-claim">What not to claim</a>
+          <a href="#evidence">What the evidence supports</a>
         </div>
       </section>
 
@@ -247,10 +246,10 @@ <h2 id="what-happened">What happened</h2>
           through a social-engineering setup.
         </p>
         <p>
-          The important detail for CAISI is not the novelty of the demo. It is
-          the class of material reportedly exposed: API keys, usernames,
-          passwords, and operational context. That is authority-bearing material,
-          not only content.
+          The important detail is not the novelty of the demo. It is the class
+          of material reportedly exposed: API keys, usernames, passwords, and
+          operational context. That is authority-bearing material, not only
+          content.
         </p>
         <p>
           Zscaler ThreatLabz separately published a writeup on a deceptive
@@ -361,20 +360,19 @@ <h2 id="action-bom-row">Agent Action BOM row</h2>
       </section>
 
       <section class="section article-section">
-        <h2 id="do-not-claim">What not to claim</h2>
+        <h2 id="evidence">What the evidence supports</h2>
         <p>
-          This field note uses the incidents as category evidence, not as a
-          product claim. Do not claim that a specific control would have stopped
-          the Hannah Fry experiment, the Zscaler-observed campaign, or exposed
-          AI endpoints found by a scanner unless the claim is tested against the
-          exact conditions.
+          These incidents are best read as evidence of a control pattern, not
+          proof that one control would have prevented every reported outcome.
+          The pattern is narrower and more useful: once an AI-assisted workflow
+          can use tools, credentials, plugins, skills, or exposed endpoints, the
+          security question moves from content safety to action authority.
         </p>
         <p>
-          Also avoid quoting marketplace-malware percentages without rechecking
-          primary sources. The useful lesson does not depend on a percentage.
-          It depends on the control pattern: skills, MCP servers, agent configs,
-          exposed endpoints, and tool declarations become part of the action
-          graph when they can influence software delivery.
+          The practical lesson is the action graph: skills, MCP servers, agent
+          configs, exposed endpoints, and tool declarations become part of
+          software-delivery governance when they can influence repos, CI/CD,
+          packages, credentials, cloud paths, or release behavior.
         </p>
         <div class="link-row">
           <a href="/agent-action-bom/">What is an Agent Action BOM?</a>

docs/blog/control-benchmarks/measure-control-efficacy-for-ai-agents/index.html

@@ -286,10 +286,10 @@ <h2 id="what-control-efficacy-actually-means">What control efficacy actually mea
         </p>
         <p>
           The easiest way to remember the distinction is this: control presence
-          tells you what the product claims to have. Control efficacy tells you
-          what the runtime actually prevented, delayed, or required in a tested
-          scenario. Evaluators should care about the second much more than the
-          first.
+          tells you what is advertised or configured. Control efficacy tells
+          you what the runtime actually prevented, delayed, or required in a
+          tested scenario. Evaluators should care about the second much more
+          than the first.
         </p>
       </section>
 

docs/long-lived-credentials-ai-agent-workflows/index.html

@@ -211,7 +211,6 @@ <h1>Long-Lived Credentials in AI Agent Workflows</h1>
           CI/CD, packages, infrastructure, or release paths.
         </p>
         <p class="body">Last updated: May 6, 2026</p>
-        <!-- Source notes: this page avoids external statistics, recent events, and vendor capability claims. Verify any added factual or current claims before publishing. -->
       </section>
 
       <section class="section page-nav" aria-labelledby="page-nav-heading">

docs/mcp-tool-risk-ai-engineering-workflows/index.html

@@ -212,7 +212,6 @@ <h1>MCP Tool Risk in AI Engineering Workflows</h1>
           release paths.
         </p>
         <p class="body">Last updated: May 6, 2026</p>
-        <!-- Source notes: this page avoids external statistics, recent events, and vendor capability claims. Verify any added factual or current claims before publishing. -->
       </section>
 
       <section class="section page-nav" aria-labelledby="page-nav-heading">