<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Thinking Machine — Notes</title>
    <link>https://thinkingmachine.uk/notes</link>
    <description>Cross-domain essays on engineering, integration, cost, and compliance.</description>
    <language>en-GB</language>
    <atom:link href="https://thinkingmachine.uk/rss.xml" rel="self" type="application/rss+xml" />
    <lastBuildDate>Thu, 14 May 2026 00:00:00 GMT</lastBuildDate>
    <item>
      <title>CRA Article 14 reporting clocks: what 24h, 72h, 14d, and 30d actually require</title>
      <link>https://thinkingmachine.uk/notes/cra-article-14-reporting-clocks</link>
      <guid isPermaLink="true">https://thinkingmachine.uk/notes/cra-article-14-reporting-clocks</guid>
      <pubDate>Thu, 14 May 2026 00:00:00 GMT</pubDate>
      <description>From 11 September 2026, every manufacturer placing a product with digital elements on the EU market is on the clock the moment an actively-exploited vulnerability or severe incident is identified. Four reporting clocks, four different deliverables, one single notification platform. Here is the operational reality, not the press-release version.</description>
      <category>CRA</category>
      <category>Cyber Resilience Act</category>
      <category>NIS2</category>
      <category>Compliance</category>
      <category>Runbook</category>
    </item>
    <item>
      <title>What energy-sector procurement NFR practice can teach SaaS vendors</title>
      <link>https://thinkingmachine.uk/notes/energy-procurement-nfr-saas</link>
      <guid isPermaLink="true">https://thinkingmachine.uk/notes/energy-procurement-nfr-saas</guid>
      <pubDate>Sat, 09 May 2026 00:00:00 GMT</pubDate>
      <description>The NFR catalogues that tier-1 energy operators send to vendors are intimidating, but they encode a discipline that SaaS vendors can copy: write the requirements you&apos;d want a vendor to meet, then meet your own. The result is a competitive moat in any regulated-customer deal.</description>
      <category>NFR</category>
      <category>Energy</category>
      <category>SaaS</category>
      <category>Procurement</category>
      <category>Cross-domain</category>
    </item>
    <item>
      <title>What healthcare lab integration taught me about IoT device onboarding</title>
      <link>https://thinkingmachine.uk/notes/healthcare-lab-to-iot-onboarding</link>
      <guid isPermaLink="true">https://thinkingmachine.uk/notes/healthcare-lab-to-iot-onboarding</guid>
      <pubDate>Sat, 09 May 2026 00:00:00 GMT</pubDate>
      <description>The diagnostic-instrument integration playbook from hospital IT translates almost line-for-line to multi-vendor IoT device onboarding. Same heterogeneous vendor landscape, same identity problem, same per-device commissioning friction — and the lab world has a thirty-year head start.</description>
      <category>IoT</category>
      <category>Healthcare IT</category>
      <category>Integration</category>
      <category>Cross-domain</category>
    </item>
    <item>
      <title>Why your healthcare-IT NFR matrix should look like an energy-sector one</title>
      <link>https://thinkingmachine.uk/notes/healthcare-nfr-from-energy</link>
      <guid isPermaLink="true">https://thinkingmachine.uk/notes/healthcare-nfr-from-energy</guid>
      <pubDate>Sat, 09 May 2026 00:00:00 GMT</pubDate>
      <description>Healthcare-IT vendors handed a hospital procurement NFR catalogue tend to react with the same mild horror SaaS vendors react to energy-sector matrices with. The fix is the same: copy the discipline the more scarred sector has already paid for. Five patterns that move.</description>
      <category>NFR</category>
      <category>Healthcare IT</category>
      <category>Energy</category>
      <category>Procurement</category>
      <category>Cross-domain</category>
    </item>
  </channel>
</rss>
