Daily Reading for 2026-10-17

Enterprise Security Exploits

Two incident reports show the same pattern: attackers are living off the management plane of enterprise security products. In the Fortinet case, threat actors used CVE-2024-47575 (“FortiJump”) against FortiManager to register a rogue gateway, exfiltrate configuration and credential material for 500+ managed firewalls, then deploy PEERSTITCH, a memory-resident ARM64 implant that hides inside legitimate process traffic. The BeyondTrust case is a patched zero-day in Remote Support, exploited by a suspected PRC-nexus actor for root and stored credentials. Both show that centralised security infrastructure is a high-value intrusion target, and that detection must reach below the appliance boundary.

Watch for:

• Re-patching FortiManager/FortiOS and BeyondTrust Remote Support, and hunting rogue devices on management channels.
• Memory-only implants like PEERSTITCH that leave no binary and no listening port — a gap for conventional EDR/NDR.
• Configuration and credential material stolen from central management planes, enabling lateral trust abuse.

Wardley signals:

• Components: FortiManager/FortiOS appliances; FortiGate firewalls; BeyondTrust Remote Support; CVE-2024-47575 (FortiJump); CVE-2025-61624; PEERSTITCH memory-resident ARM64 implant; FMG-Access (TCP 541); EDR/NDR detection; patch management.

• Evolution stage: Firewalls and remote-support platforms are commodity infrastructure (widespread, standardised, cost of doing business). Management-plane exploits are custom/emerging. Memory-resident implants like PEERSTITCH sit at Genesis/custom — novel, poorly understood, few signatures. Patch distribution is product-stage.

• Doctrine hits/misses: Miss “Know the details” (defenders must know management-plane internals); miss “Manage failure” (one compromised appliance cascades to 500+ devices); hit “Use standards” (CVEs, YARA and advisories coordinate response).

• Climatic patterns: “Success breeds inertia” — centralised management creates a single point of failure; “Characteristics change as components evolve” — once-rare memory-resident tradecraft is diffusing; “Everything evolves through supply and demand competition” — attackers co-evolve with defences.

• Diffusion markers: Public CVE assignment, YARA rules, vendor advisories and joint FBI/Secret Service advisories; copy-cat “FortiBleed” activity against exposed systems.

• 🚩 PEERSTITCH Memory-Resident Implant Deployed After FortiManager Compromise Exposes 500+ Firewalls

• 🚩 BeyondTrust Patches Remote Support Zero-Day CVE-2026-102764, Exploited by a Suspected PRC-Nexus Actor to Gain Root and Target Stored Credentials.

wardley-beta
%% 1. Users: SOC analysts and network defenders at managed service providers
%% 2. Needs: detect and contain intrusions that pivot through enterprise security appliances
%% 3. Capabilities: management-plane monitoring, memory-implant detection, credential protection, patch response
%% 4. Components: fortiGateFirewalls, fortiManager, beyondTrustRmm, peerstitchImplant, memoryForensics, cveAdvisories
%% 5. Maturity: firewalls and advisories are Commodity; managers and remote support are Product; PEERSTITCH and memory forensics are Custom/Genesis
%% 6. Management: appliance vendors ship patches; defenders own detection and containment
anchor socAnalyst [0.95, 0.9]
anchor networkDefender [0.9, 0.82]
component fortiGateFirewalls [0.85, 0.3]
component fortiManager [0.68, 0.55]
component beyondTrustRmm [0.72, 0.6]
component peerstitchImplant [0.14, 0.45]
component memoryForensics [0.3, 0.5]
component cveAdvisories [0.9, 0.25]
fortiGateFirewalls -> fortiManager
fortiManager -> socAnalyst
beyondTrustRmm -> networkDefender
peerstitchImplant -> memoryForensics
memoryForensics -> socAnalyst
cveAdvisories -> networkDefender
evolve memoryForensics 0.42

Mercenary Spyware via Ad Targeting

Citizen Lab documents “AdFection”, the first public confirmation of zero-click mercenary spyware delivered through targeted advertising. Israel-based Discover-Tech, posing as a legitimate ad company, used its MyDSP and Controlium platform plus “NOAS” ad servers to profile and deanonymise users and execute code during ad render — bridging ad exchanges such as Google, Yandex and Beeswax with spyware vendors including the rebranded Candiru. Victims extend well beyond Al Jazeera. The report shows that real-time bidding and third-party ad code are a ready-made attack pipeline, and that vendor certification lists were not a sufficient control.

Watch for:

• Ad exchanges tightening third-party creative and script review after Discover-Tech’s removal from Google and IAB Europe registries.
• More disclosure of spyware vendors using ad-auction data for targeting and deanonymisation.
• Regulatory attention on real-time bidding data flows and ad IDs as cross-context identifiers.

Wardley signals:

• Components: Real-Time Bidding (RTB); Demand-Side Platforms (DSP) and Supply-Side Platforms (SSP); ad exchanges (Google, Yandex, Vungle, Beeswax); mobile ad IDs and cookie IDs; Discover-Tech MyDSP and Controlium; NOAS/getAd servers; Candiru (Integrity Labs) spyware; IAB Europe and Google vendor registries.

• Evolution stage: RTB and DSP/SSP infrastructure is commodity (hundreds of billions of auctions a day, standardised); ad IDs are commodity data; spyware exploitation is custom/emerging; vendor certification is a product-stage control that failed.

• Doctrine hits/misses: Miss “Challenge assumptions” and “Understand what is being considered” — the industry assumed certified ad vendors were benign; miss “Manage failure” — no effective kill switch for malicious creatives; “Listen to your ecosystem” only after journalists and Google collaborated.

• Climatic patterns: “Higher order systems create new sources of value” — the ad ecosystem is repurposed as a spyware delivery channel; “Components can co-evolve” — spyware co-evolves with ad-tech; “Success breeds inertia” — scale and opacity resisted oversight.

• Diffusion markers: AdFection as a repeatable technique; multiple spyware vendors linked to one ad bridge; registry removals and platform terminations show ecosystem response; public technical disclosure spreads knowledge.

• 🚩 Israeli Ad-Tech Firm “Discover-Tech” Used Targeted Advertising to Deliver Zero-Click Mercenary Spyware, With Exposure Extending Far Beyond Confirmed Al Jazeera Victims.

wardley-beta
%% 1. Users: civil-society targets (journalists, activists) and platform trust-and-safety teams
%% 2. Needs: detect and stop zero-click spyware delivered through targeted ads
%% 3. Capabilities: ad delivery, targeting/deanonymisation, exploit delivery, spyware, vendor certification
%% 4. Components: realTimeBidding, adExchanges, discoverTechDsp, noasAdServer, candiruSpyware, vendorRegistry
%% 5. Maturity: RTB, exchanges and ad IDs are Commodity; Discover-Tech is Product/Custom; Candiru spyware and NOAS are Genesis/Custom; registries are a Product control
%% 6. Management: ad platforms and IAB maintain registries; Citizen Lab exposes the abuse
anchor civilSocietyTarget [0.95, 0.9]
anchor platformTrustTeam [0.82, 0.78]
component realTimeBidding [0.88, 0.25]
component adExchanges [0.78, 0.3]
component discoverTechDsp [0.45, 0.5]
component noasAdServer [0.28, 0.45]
component candiruSpyware [0.12, 0.55]
component vendorRegistry [0.6, 0.28]
realTimeBidding -> adExchanges
adExchanges -> discoverTechDsp
discoverTechDsp -> noasAdServer
noasAdServer -> candiruSpyware
candiruSpyware -> civilSocietyTarget
vendorRegistry -> platformTrustTeam
discoverTechDsp -> vendorRegistry
%% note: signals named spyware as Custom; sources show bespoke zero-click tooling still at Genesis
evolve noasAdServer 0.4

Open-Weight AI Risk Management

Microsoft and NVIDIA jointly published Risk Management for Open-Weight Models in Enterprise, arguing that weight openness alone does not determine AI risk — deployment context, permissions, data access, tools and operational controls do. The paper offers a shared five-part taxonomy (Cybersecurity, Data Protection, Content, Human-AI Interaction, Bias) mapped to evaluations as risk evidence, grounded in ISO standards and the NIST AI Risk Management Framework. It stresses that model access and deployment are separate choices, and that running open weights shifts safeguard responsibility onto the enterprise. For technical readers it is a vocabulary for connecting identified risks to concrete controls across model, runtime and application layers.

Watch for:

• The planned follow-on papers extending the taxonomy to runtime, harness and application layers.
• Whether the joint repository accumulates community-contributed evaluations or stalls as vendor marketing.
• How enterprises reconcile “open-weight” with managed-platform deployment when assigning safeguard ownership.

Wardley signals:

• Components: Open-weight models; Microsoft Foundry evaluations and content-safety controls; NIST AI RMF; ISO standards; the five-part risk taxonomy; automated red teaming; inference runtime; shared evaluation resources.

• Evolution stage: Open-weight models are product-stage and commoditising; NIST AI RMF and ISO are commodity/standard; enterprise AI risk evaluation is custom/emerging; content-safety controls are product-stage.

• Doctrine hits/misses: Hit “Use standards” (grounding in ISO/NIST); hit “Common Language” (taxonomy across engineering, security, legal and safety); hit “Focus on the outcome” (risk tied to deployment, not model label). A possible miss on “Know your users” if evaluations stay generic.

• Climatic patterns: “No single method fits all” — risk depends on deployment; “Everything evolves through supply and demand competition” — model openness competition; “Commoditisation <> Centralisation” — open weights decentralise capability while managed platforms recentralise control.

• Diffusion markers: Joint vendor publication, standards alignment and a planned community evaluation repository signal convergence on shared risk vocabulary; growing open-weight ubiquity is the adoption marker.

• Managing open-weight model risk in enterprise deployments

wardley-beta
%% 1. Users: enterprise AI, security and risk teams deploying models
%% 2. Needs: understand and control AI risk in their own deployment context
%% 3. Capabilities: risk taxonomy, evaluations, safety controls, standards alignment
%% 4. Components: openWeightModels, aiRiskTaxonomy, modelEvaluations, contentSafetyControls, nistAiRmf, msFoundry
%% 5. Maturity: open-weight models and Foundry controls are Product; taxonomy and evaluations are Custom/emerging; NIST/ISO standards are Commodity
%% 6. Management: Microsoft and NVIDIA publish shared guidance; enterprises own deployment safeguards
anchor enterpriseAiTeam [0.95, 0.9]
component openWeightModels [0.55, 0.55]
component aiRiskTaxonomy [0.24, 0.45]
component modelEvaluations [0.42, 0.6]
component contentSafetyControls [0.62, 0.42]
component nistAiRmf [0.85, 0.3]
component msFoundry [0.72, 0.65]
openWeightModels -> msFoundry
modelEvaluations -> msFoundry
contentSafetyControls -> msFoundry
aiRiskTaxonomy -> modelEvaluations
nistAiRmf -> aiRiskTaxonomy
msFoundry -> enterpriseAiTeam
evolve modelEvaluations 0.55

AI-Assisted Code Review

This short quote from the Claude Code team reframes code review around “what could go wrong, and which check — automated or human — catches it?” rather than “did a human read it?”. Review has shifted from an end-of-road PR gate to a continuous, spellcheck-like activity, with Claude reviewing and fixing most routine mistakes before a human looks. The practical effect is that scarce human attention moves to higher-level questions and scrutiny. It is a concise statement of how AI assistance changes the economics and timing of review, and why teams should re-examine what their review process is actually for.

Watch for:

• Teams replacing “human reviewed” gates with risk-based automated/human check routing.
• Defect escape-rate metrics as AI review becomes the first pass.
• Whether human reviewers retain deep scrutiny or rubber-stamp AI-approved changes.

Wardley signals:

• Components: Claude / Claude Code; code review process; pull-request gates; automated checks and linters; human reviewers; prompt-based review agents.

• Evolution stage: Human code review is a mature product/commodity practice; CI and linting are commodity; AI-assisted review is custom/emerging — rapidly improving but not yet standardised.

• Doctrine hits/misses: Hit “Focus on the outcome” (review aimed at risk, not process theatre); hit “Effectiveness over efficiency” (saving human attention for high-value scrutiny); hit “Bias towards action” (continuous review). A possible miss on “Use appropriate methods” if AI review is treated as a blanket replacement.

• Climatic patterns: “Efficiency enables innovation”; “Components can co-evolve” — practice co-evolves with AI capability; “Characteristics change as components evolve” — review’s purpose shifts once the first pass automates.

• Diffusion markers: Adoption inside the Claude Code team and spread via Simon Willison; “review runs continuously” emerging as a common pattern. Early, not yet standardised.

• Quoting Addy Osmani, Morgan Westlee Lunt, and Qing Wang

wardley-beta
%% 1. Users: software developers and review teams
%% 2. Needs: catch defects efficiently and spend scarce human attention on high-risk changes
%% 3. Capabilities: automated review, CI checks, PR gating, human scrutiny
%% 4. Components: claudeCode, aiReviewAgents, ciChecks, linters, pullRequestGates, humanReviewers
%% 5. Maturity: CI and linters are Commodity; Claude Code and PR gates are Product; AI review agents are Custom/emerging; human review is a mature practice
%% 6. Management: teams own their review policy; model vendors ship the assistant
anchor devTeam [0.95, 0.9]
anchor reviewer [0.72, 0.82]
component claudeCode [0.5, 0.58]
component aiReviewAgents [0.32, 0.6]
component ciChecks [0.85, 0.38]
component linters [0.88, 0.3]
component pullRequestGates [0.7, 0.52]
component humanReviewers [0.62, 0.78]
aiReviewAgents -> claudeCode
claudeCode -> pullRequestGates
ciChecks -> pullRequestGates
linters -> ciChecks
pullRequestGates -> humanReviewers
humanReviewers -> devTeam
pullRequestGates -> reviewer
evolve aiReviewAgents 0.45

Browser-Based LaTeX Tooling

Simon Willison built a browser LaTeX renderer where the whole document lives in the URL fragment, so every rendered equation or document is a bookmarkable, shareable link. Inspired by Tiny Little Office’s fragment-storage trick and its llms.txt file — which agents read to construct URLs — the tool uses MathJax, faster-latex, Pako and DOMPurify, with an iframe sandbox for XSS protection and Gist/URL loading. The article is a compact case study in agent-built, client-side tools: stateless, no backend, shareable by URL, and generated from a short sequence of prompts.

Watch for:

• More tools storing state in URL fragments and shipping llms.txt to guide agents.
• Security review of fragment-based apps: XSS, decompression bombs and sandbox escapes.
• Whether these agent-built utilities get maintained or remain one-off demos.

Wardley signals:

• Components: LaTeX; MathJax; faster-latex (WebAssembly); Pako compression; DOMPurify; iframe sandbox; URL-fragment state; llms.txt; GitHub Gist; Claude Code (Opus 5.5).

• Evolution stage: LaTeX and MathJax are commodity/mature; URL-fragment state is a well-known product technique; llms.txt is emerging/custom; agent-generated bespoke tools are Genesis/custom.

• Doctrine hits/misses: Hit “Use appropriate tools” (CDN libraries and WASM); hit “Think fast, inexpensive, restrained and elegant” (stateless, no backend); hit “A bias towards open” (shareable links, llms.txt). A possible miss on “Use standards” if bespoke URL schemes proliferate.

• Climatic patterns: “Efficiency enables innovation (Componentisation effect)” — commodity libraries let one person ship a tool in a prompt session; “Higher order systems create new sources of value” — llms.txt as an agent interface; “Increased stability of lower order systems increases agility”.

• Diffusion markers: The llms.txt convention spreading, agents reading it to build URLs, and copy-cat fragment-storage apps. Early-stage and driven by a small circle.

• LaTeX renderer

wardley-beta
%% 1. Users: technical writers and AI agents that construct shareable documents
%% 2. Needs: render and share LaTeX through a stable, bookmarkable URL
%% 3. Capabilities: typesetting, URL-fragment state, compression, XSS protection, agent-readable interface
%% 4. Components: latex, mathJax, fasterLatex, urlFragmentState, domPurify, llmsTxt
%% 5. Maturity: LaTeX, MathJax and DOMPurify are Commodity/Product; faster-latex is Product; fragment state is a known Product technique; llms.txt is Genesis/Custom
%% 6. Management: a single developer builds on CDN libraries and WASM; the llms.txt convention is community-driven
anchor technicalWriter [0.95, 0.9]
anchor aiAgent [0.22, 0.75]
component latex [0.85, 0.3]
component mathJax [0.8, 0.4]
component fasterLatex [0.45, 0.45]
component urlFragmentState [0.6, 0.55]
component domPurify [0.72, 0.35]
component llmsTxt [0.18, 0.28]
latex -> mathJax
mathJax -> urlFragmentState
fasterLatex -> urlFragmentState
domPurify -> urlFragmentState
urlFragmentState -> technicalWriter
llmsTxt -> aiAgent
evolve llmsTxt 0.32

LLM Inference Capacity & Proxying

Geoffrey Huntley treats the “cost of compute crisis” as an engineering problem: not enough GPUs, region-dependent inference capacity, and constant “model is at capacity” errors. His response is three composable proxies — Underclass, which pools many ChatGPT subscriptions and pins sessions to keep prompt caches warm; Preflight, which scrubs secrets from requests locally; and GeoClass, which routes requests to different inference regions over a Tailscale network. The piece is a field report on building personal infrastructure to route around provider scarcity and regional limits, and on the emerging pattern of local, composable LLM middleware.

Watch for:

• Whether pooling subscriptions violates provider terms and triggers enforcement.
• Regional inference routing becoming a standard resilience pattern for agent workloads.
• Local secret-scrubbing proxies becoming a default guardrail before requests leave the network.

Wardley signals:

• Components: ChatGPT subscriptions; OpenAI-compatible APIs; Underclass pooling proxy; prompt-cache keys; Preflight secret-scrubbing proxy; GeoClass regional router; Tailscale; regional inference capacity; GPU supply.

• Evolution stage: GPU/inference capacity is a scarce commodity; API access is product-stage; pooling and regional-routing proxies are custom/emerging experimental prototypes; secret scrubbing is emerging.

• Doctrine hits/misses: Hit “Bias towards action” and “Be pragmatic” (build composable tools rather than complain); hit “Think small teams” and “Use appropriate tools” (single-purpose proxies). A possible miss on “Use standards” — subscription pooling relies on fragile, provider-specific behaviour.

• Climatic patterns: “Everything evolves through supply and demand competition” — compute scarcity drives workarounds; “Efficiency does not mean a reduced spend (Jevon’s Paradox)” — cheaper access fuels more usage; “Commoditisation <> Centralisation” — local proxies decentralise control over inference.

• Diffusion markers: Open-source releases on GitHub, Nix packaging and composability with each other; the “compute crisis” meme circulating. Early adoption, not standardised.

• pooling OpenAI subscriptions and bypassing regional inference capacity limits

wardley-beta
%% 1. Users: AI developers running agent workloads
%% 2. Needs: reliable, affordable inference capacity despite regional limits
%% 3. Capabilities: subscription pooling, prompt caching, secret scrubbing, regional routing
%% 4. Components: chatGptSubscriptions, openAiApi, underclassProxy, promptCache, preflightScrubber, geoclassRouter
%% 5. Maturity: APIs and subscriptions are Product; prompt caching is Product; the proxies are Custom/emerging prototypes
%% 6. Management: a single open-source author composes the proxies; providers own the capacity
anchor aiDeveloper [0.95, 0.9]
component chatGptSubscriptions [0.6, 0.4]
component openAiApi [0.82, 0.5]
component underclassProxy [0.3, 0.55]
component promptCache [0.5, 0.34]
component preflightScrubber [0.26, 0.48]
component geoclassRouter [0.2, 0.56]
chatGptSubscriptions -> underclassProxy
promptCache -> underclassProxy
preflightScrubber -> underclassProxy
geoclassRouter -> underclassProxy
underclassProxy -> aiDeveloper
openAiApi -> aiDeveloper
%% note: signals placed regional routing at Custom; sources show an experimental prototype, so Genesis-adjusted
evolve geoclassRouter 0.34

State of Agentic Coding

Geoffrey Huntley’s write-up of State of Agentic Coding episode 11 argues that software developers are failing a “curiosity test”: displacement by AI is self-inflicted for those who stopped learning. With Armin Ronacher and Ben Vinegar he covers Ralph-loop economics, the boom/bust history of developer scarcity (Buffalo, Detroit), DHH’s change of mind, durable agents and deleting AGENTS.md, a live Lisp demo, code mode, and why the labs “can’t fail”. The throughline is that agentic coding is reshaping the profession faster than its institutions, and that curiosity and adaptability — not any single tool or lab — are the durable skills.

Watch for:

• Whether “loop engineering” and durable agents become standard practice or a passing technique.
• The profession’s response to commoditisation: retooling versus inertia.
• Lab dependencies, and the push toward open weights and self-hosting as a hedge.

Wardley signals:

• Components: Ralph loop / loop engineering; agentic coding; Claude/Opus, GLM and Kimi; AGENTS.md; Pi Durable; Lisp; code mode; open weights; subsidised tokens.

• Evolution stage: Agentic coding is custom/emerging, moving toward product; loop engineering is emerging practice; LLM APIs are product-stage and commoditising; the profession’s practices are in flux.

• Doctrine hits/misses: Hit “Bias towards the new” and “Listen to your ecosystem”; hit “Be humble” and “Embrace uncertainty” (Huntley admits not knowing); a miss on “Manage inertia” for developers who won’t retool; “There is no core” — no single language or tool identity survives.

• Climatic patterns: “Success breeds inertia” and “Inertia can kill an organisation” — the boom/bust cycle of developer scarcity; “Creative Destruction”; “You cannot measure evolution over time or adoption, you need to embrace uncertainty”; “Economy has cycles (peace, war and wonder)”.

• Diffusion markers: “Everyone’s talking about loop engineering”; Cursor, Anthropic and OpenAI adopting the technique; DHH changing position; copy-cat agent frameworks; a live Lisp demo as a novelty. Strong diffusion of practice, still unsettled standards.

• state of agentic coding #11: the curiosity test, lisp, and labs that can’t fail

wardley-beta
%% 1. Users: software developers facing AI-driven change
%% 2. Needs: stay effective and employable as agentic coding reshapes the profession
%% 3. Capabilities: agentic coding, loop engineering, durable agents, agent instructions, retooling
%% 4. Components: ralphLoop, agenticCoding, llmApis, openWeights, durableAgents, agentsMd
%% 5. Maturity: LLM APIs are Product/commoditising; agentic coding is emerging Product; loop engineering, durable agents and AGENTS.md are Custom/emerging
%% 6. Management: labs ship models; developers own their curiosity and practice
anchor softwareDeveloper [0.95, 0.9]
component ralphLoop [0.3, 0.55]
component agenticCoding [0.45, 0.68]
component llmApis [0.8, 0.5]
component openWeights [0.5, 0.4]
component durableAgents [0.24, 0.5]
component agentsMd [0.36, 0.38]
ralphLoop -> agenticCoding
durableAgents -> agenticCoding
agentsMd -> agenticCoding
llmApis -> agenticCoding
openWeights -> llmApis
agenticCoding -> softwareDeveloper
evolve agenticCoding 0.58

Razer Basilisk Mouse Review

A hands-on review of the Razer Basilisk V3 Pro 35K in its translucent Phantom White edition, compared with the regular V3 Pro the author has used since 2024. The newer Focus Pro 35K sensor is practically indistinguishable day to day; the real draw is the transparent-shell aesthetics and longer rated battery life. The review’s technical substance is Linux compatibility: OpenRazer supports the mouse via its own dongle, but the Mouse Dock Pro still cannot expose DPI, polling rate or lighting on Linux, with open pull request #2817 adding pairing and 8000 Hz support. Verdict: only worth upgrading for the look.

Watch for:

• Whether OpenRazer PR #2817 merges and brings dock-based configuration to Linux.
• Vendor software lock-in (Synapse-only settings) on otherwise open platforms.
• The V4 Pro’s newer sensor and polling rate, and whether a Phantom edition follows.

Wardley signals:

• Components: Razer Basilisk V3 Pro / 35K; Focus Pro 35K and 30K sensors; Mouse Dock Pro; Razer Synapse; OpenRazer (open-source driver); OpenRGB; wireless dongle; translucent Phantom White shell; Linux.

• Evolution stage: Gaming mice and sensors are commodity/product-stage and feature-differentiated; Razer Synapse is product-stage proprietary software; OpenRazer is a custom/emerging community driver; dock configuration on Linux is Genesis (unresolved).

• Doctrine hits/misses: Hit “A bias towards open” (OpenRazer/OpenRGB community drivers); miss “Use standards” and “Remove bias and duplication” (proprietary Synapse-only settings force duplicated effort); “Focus on user needs” — the reviewer wants Linux parity the vendor does not provide.

• Climatic patterns: “Everything evolves through supply and demand competition” — iterative sensor updates as differentiation; “Higher order systems create new sources of value” — the dock ecosystem; “Characteristics change as components evolve” — sensors commoditise, so vendors compete on aesthetics and lighting.

• Diffusion markers: Open-source driver contributions (PR #2817), community reports and feature-parity requests; review culture and copy-cat translucent editions (the Phantom collection). Standardisation is weak — vendor-specific protocols.

• Razer Basilisk V3 Pro 35K Phantom White Edition

wardley-beta
%% 1. Users: Linux-using hardware enthusiasts
%% 2. Needs: configure a gaming mouse (DPI, polling, lighting) on Linux
%% 3. Capabilities: hardware, sensor, dock, configuration software, open-source drivers
%% 4. Components: basiliskMouse, focusProSensor, mouseDockPro, razerSynapse, openRazer, openRgb
%% 5. Maturity: mouse and sensor are Product/Commodity; Synapse is Product (Windows-only); OpenRazer and OpenRGB are Custom community drivers; dock support on Linux is Genesis
%% 6. Management: Razer ships proprietary software; the community maintains OpenRazer/OpenRGB
anchor linuxEnthusiast [0.95, 0.9]
component basiliskMouse [0.75, 0.7]
component focusProSensor [0.8, 0.5]
component mouseDockPro [0.65, 0.55]
component razerSynapse [0.6, 0.4]
component openRazer [0.28, 0.5]
component openRgb [0.44, 0.38]
focusProSensor -> basiliskMouse
basiliskMouse -> linuxEnthusiast
mouseDockPro -> basiliskMouse
razerSynapse -> mouseDockPro
openRazer -> mouseDockPro
openRgb -> openRazer
evolve openRazer 0.4