Daily Reading for 2026-09-22

Jev Decision Models

Two posts examine Jev, TypeSafe AI’s “System One”/decision model, which takes text in and returns typed probabilistic outputs — Bernoulli (yes/no) confidences, choice distributions and ordinal scores — priced on input only and far cheaper than token-based LLMs. Simon Willison sees a regression toward black-box ML: you get a float, never an explanation, so bias and evals matter more, though cheap experimentation helps. Daniel Miessler sharpens the taxonomy: choice and score both return probabilities, but score is an ordered ladder (nominal versus ordinal), so he renames them choice and scale.

Watch for:

• Classification, reranking and labeling workloads moving to cheap decision models
• Bias and eval tooling for models that return only numbers
• The choice-versus-score (nominal versus ordinal) distinction shaping API design
• Open-weight recreations (Kev) and JevBench-style benchmarks
• Unconventional uses such as jevchat, jev-leftpad and jev-2048

Wardley signals:

• Components: Jev; TypeSafe AI; Bernoulli/choice/score query types; decision models; open-weight recreations (Kev on Qwen 3.5); JevBench; BM25 search reranking; Jev chat, leftpad and 2048 demos.

• Evolution stage: Jev and decision models are Genesis/Custom (days old, poorly understood, differential); the LLM API pattern they mimic is Product; open-weight Qwen bases are Product/Commodity; benchmarks are emerging.

• Doctrine: “Bias towards data” and “Bias towards action” (cheap experimentation); “Challenge Assumptions” about black boxes; a miss on “Know your users” if used for hiring; “Focus on the outcome” (classification, not text).

• Climatic patterns: “Higher order systems create new sources of value”; “Capital flows to new areas of value”; “Efficiency enables innovation (Componentisation effect)”; “The less evolved something is the more uncertain it becomes”; Jevons paradox via cheap inference.

• Diffusion markers: Rapid community projects within a week, open-weight recreations, a new benchmark, Hacker News threads, and a shared vocabulary (nominal versus ordinal, choice versus scale).

• How to Think About the Difference Between Choice and Score in Jev

• Jev introduces a new shape of LLM - System One, aka Decision Models

wardley-beta
%% Q1 Who are the users? Application developers and data scientists adding classification and ranking to products.
%% Q2 What are their needs? Cheap, fast, typed probabilistic decisions over text.
%% Q3 What capabilities are required? A decision API, query types, evaluation, and open-weight alternatives.
%% Q4 What components are used? Jev API, decision models, choice/score queries, open-weight recreations, JevBench, BM25 reranking.
%% Q5 How mature are those components? Jev and decision models are Genesis/Custom; open-weight bases are Product; BM25 is Commodity.
%% Q6 Who manages them and how? TypeSafe AI runs Jev; the community is already recreating and benchmarking it.
anchor applicationDeveloper [0.93, 0.9]
component jevApi [0.35, 0.82]
component decisionModels [0.2, 0.7]
component choiceScoreQueries [0.45, 0.6]
component openWeightRecreations [0.3, 0.42]
component jevBench [0.5, 0.32]
component bm25Reranking [0.74, 0.52]
jevApi -> applicationDeveloper
choiceScoreQueries -> jevApi
decisionModels -> jevApi
openWeightRecreations -> decisionModels
jevBench -> openWeightRecreations
bm25Reranking -> applicationDeveloper

AI Overreliance Threat Modeling

The Pentagon reportedly came within hours of striking a Chinese ship based on an AI-generated intelligence report that misidentified its cargo — a “close call” Adam Shostack uses to illustrate over-reliance, the “O” in the PHANTOM-B threat-modeling framework. The lesson is not that the model lied, but that an analyst shipped its output without checking key facts. As LLMs are pushed into consequential decisions, unverified output becomes a systemic threat. PHANTOM-B offers a wallet-card checklist of human prompts to force those checkpoints before a recommendation is acted on.

Watch for:

• AI-generated analysis entering operational or military decision loops without human fact-checking
• Whether “have you checked the key facts?” checkpoints get embedded in deployment workflows
• Deployment pressure outpacing verification, exactly as PHANTOM-B warns

Wardley signals:

• Components: PHANTOM-B threat-modeling framework; LLM chatbots used for intelligence analysis; military AI decision-support systems; human-in-the-loop checkpoints.

• Evolution stage: PHANTOM-B — Custom (a bespoke, creative-commons framework spreading by word of mouth); LLM decision-support in defense — Genesis/Custom (poorly understood, high-uncertainty, dangerous); checklists/approval gates — emerging Product practice.

• Doctrine: Misses “Know your users” and “Focus on user needs” when models are trusted blindly; illustrates “Manage failure” and “Challenge Assumptions”; the call for checkpoints reflects “Use appropriate methods.”

• Climatic patterns: “Higher order systems create new sources of value” (AI layered onto analysis); “The less evolved something is the more uncertain it becomes”; “Future value is inversely proportional to the certainty we have over it.”

• Diffusion markers: PHANTOM-B shipped free as a wallet card via a partner; the framework reused across hiring, layoff and arrest examples; media amplification of the near-miss.

• The Pentagon, China, AI and PHANTOM-B

wardley-beta
%% Q1 Who are the users? Military analysts and commanders, and any organization making consequential decisions.
%% Q2 What are their needs? Decisions they can stand behind, grounded in verified facts rather than unchecked model output.
%% Q3 What capabilities are required? AI decision support, human verification checkpoints, threat modeling, and oversight.
%% Q4 What components are used? LLM decision support, AI-generated intelligence, human checkpoints, PHANTOM-B, threat-modeling practice, oversight governance.
%% Q5 How mature are those components? LLMs and generated analysis are Product; checkpoints and governance are Custom; PHANTOM-B is a novel Genesis/Custom framework.
%% Q6 Who manages them and how? Defense leadership and system designers; oversight is hoped-for rather than enforced.
anchor decisionMaker [0.95, 0.9]
component llmDecisionSupport [0.4, 0.82]
component aiGeneratedIntelligence [0.62, 0.72]
component humanCheckpoints [0.38, 0.62]
component phantomBFramework [0.22, 0.5]
component threatModelingPractice [0.5, 0.42]
component oversightGovernance [0.72, 0.34]
llmDecisionSupport -> decisionMaker
aiGeneratedIntelligence -> llmDecisionSupport
humanCheckpoints -> aiGeneratedIntelligence
phantomBFramework -> humanCheckpoints
threatModelingPractice -> phantomBFramework
oversightGovernance -> humanCheckpoints
%% note: signals named LLM decision-support as Genesis/Custom; the underlying models are Product, but their use in consequential command decisions is still poorly understood, so placement stays mid-left.

North Korean WaterPlum Campaign

A joint advisory from Japanese, US, Australian and German authorities attributes the WaterPlum campaign to North Korea: at least 30,000 infected devices across 100+ countries and $10.7M in stolen cryptocurrency. The group’s “Contagious Interview” playbook impersonates AI, crypto and NFT employers, luring developers through fake interviews and malicious coding assignments that deliver npm-based malware such as BeaverTail and InvisibleFerret. The advisory ties the operation to the DPRK’s 313 General Bureau and to fraudulent IT-worker schemes, warning firms to verify applicant identity and to sandbox all untrusted code.

Watch for:

• Fake-interview lures extending from crypto into AI/ML and NFT job markets
• Malicious npm packages, VS Code projects and “coding test” repositories
• Convergence of state espionage, crypto theft and fraudulent remote IT workers
• Reuse of stolen identity documents and AI face-swaps during interviews

Wardley signals:

• Components: WaterPlum / Contagious Interview campaign; BeaverTail, InvisibleFerret, OtterCookie, OtterCandy, StoatWaffle malware; the npm registry; fake interview/coding-test lures; DPRK 313 General Bureau; laptop farms; AI face-swapping.

• Evolution stage: The campaign and its malware families are Product (repeatable, tooled, industrialised criminal operations); npm as a distribution channel is Commodity; recruiting platforms are Commodity; face-swap tooling is Product/Commodity.

• Doctrine: For defenders, “Know your users” and “Use appropriate tools” (sandbox unknown code); attackers exploit a miss on verification and “Manage inertia.” “There is no core” fits defending a sprawling attack surface.

• Climatic patterns: “Everything evolves through supply and demand competition” (financially motivated attacks industrialising); “Higher order systems create new sources of value”; “Evolution consists of multiple waves of diffusion.”

• Diffusion markers: Repeatable, copy-cat campaigns across 100+ countries; published joint advisories and shared IOCs; malware families reused and recombined; standardised TTPs.

• North Korean WaterPlum Campaign Targets IT Professionals with Fake Job Interviews, Malicious Coding Assignments, and Cryptocurrency Theft.

wardley-beta
%% Q1 Who are the users? Job-seeking developers (targets) and the security teams who must defend them.
%% Q2 What are their needs? Targets need legitimate work; defenders need to stop state-sponsored theft and intrusion.
%% Q3 What capabilities are required? Recruiting lures, code delivery, malware, exfiltration, and detection/advisory sharing.
%% Q4 What components are used? Fake recruiting lures, malicious npm packages, malware families, crypto-theft infrastructure, DPRK IT-worker operations, face-swap tooling, joint advisories.
%% Q5 How mature are those components? npm and recruiting platforms are Commodity; the malware families and lures are Product; IT-worker ops are Custom.
%% Q6 Who manages them and how? The DPRK's 313 General Bureau runs the campaign; a joint international advisory coordinates defenders.
anchor jobSeeker [0.93, 0.9]
anchor securityTeam [0.88, 0.55]
component fakeRecruitingLure [0.45, 0.82]
component maliciousNpmPackages [0.62, 0.62]
component malwareFamilies [0.72, 0.45]
component cryptoTheftInfra [0.82, 0.28]
component dprkItWorkerOps [0.28, 0.6]
component faceSwapTooling [0.5, 0.34]
fakeRecruitingLure -> jobSeeker
maliciousNpmPackages -> fakeRecruitingLure
malwareFamilies -> maliciousNpmPackages
cryptoTheftInfra -> malwareFamilies
dprkItWorkerOps -> fakeRecruitingLure
faceSwapTooling -> dprkItWorkerOps
malwareFamilies -> securityTeam

PAYLOAD Ransomware GPO Abuse

Kaspersky’s GERT describes an April 2026 intrusion in which attackers gained domain-admin-equivalent control and abused Active Directory Group Policy instead of deploying a ransomware binary. Two domain-root-linked GPOs — PAYLOAD and “win Firewall Off” — dropped ransom notes, hijacked wallpaper and lock screens, showed a logon banner and disabled the local administrator account across every domain-joined workstation, with no encryption, endpoint persistence or malicious process. The attack stayed dormant in the GPO cache for a day before detonating on reboot, exposing the limits of file- and process-based detection.

Watch for:

• Domain-root gPLink changes and unauthorized groupPolicyContainer creation
• SYSVOL file integrity changes and suspicious Group Policy extension (CSE) settings
• Encryptionless extortion that weaponizes trusted admin infrastructure
• Delayed policy detonation that severs cause from effect in timelines

Wardley signals:

• Components: Active Directory Group Policy (GPC/GPT); SYSVOL; Group Policy Preferences/CSEs; domain-root gPLink; FortiGate SSL VPN; ESXi; DS Access audit events 5136/5137/5141; EDR tooling.

• Evolution stage: AD, GPO and SYSVOL are Commodity (universal, standardised, essential); the abuse technique is Custom/emerging; encryptionless extortion as a model is evolving from Custom toward Product.

• Doctrine: Attackers exploit a defender miss on “Know the details” and “Manage failure” (detection assumed executables); the article’s remediation reflects “Use appropriate methods” and “Effectiveness over efficiency,” countering “Manage inertia.”

• Climatic patterns: “Everything evolves through supply and demand competition” (extortion-only incidents growing); “Success breeds inertia” (process-based detection); “No single method fits all”; “Characteristics change as components evolve.”

• Diffusion markers: Prior GPO abuse by Ryuk, LockBit and BlackCat/ALPHV; PAYLOAD as an instance of a spreading encryptionless-extortion pattern; published detection guidance and telemetry sources.

• 🚩 PAYLOAD Ransomware Abuses Active Directory Group Policy to Cause Domain-wide Disruption without Deploying Ransomware to Windows Endpoints.

wardley-beta
%% Q1 Who are the users? Enterprise IT and security teams defending domain-joined Windows estates.
%% Q2 What are their needs? Keep the domain running and detect impact that never touches an endpoint binary.
%% Q3 What capabilities are required? Directory change auditing, SYSVOL monitoring, endpoint telemetry, and GPO governance.
%% Q4 What components are used? Group Policy Objects, domain-root gPLink, SYSVOL staging, DS Access auditing, endpoint EDR, encryptionless extortion.
%% Q5 How mature are those components? AD, GPO and SYSVOL are Commodity; EDR is Product; encryptionless extortion is Custom; directory auditing is under-used Product.
%% Q6 Who manages them and how? Domain administrators and SOC teams; attackers weaponise the trusted policy channel they already run.
anchor enterpriseDefender [0.92, 0.88]
component groupPolicyObjects [0.78, 0.7]
component sysvolStaging [0.72, 0.52]
component domainRootLink [0.62, 0.6]
component dsAccessAuditing [0.55, 0.36]
component endpointEdr [0.66, 0.26]
component encryptionlessExtortion [0.4, 0.46]
groupPolicyObjects -> enterpriseDefender
domainRootLink -> groupPolicyObjects
sysvolStaging -> groupPolicyObjects
dsAccessAuditing -> enterpriseDefender
endpointEdr -> enterpriseDefender
encryptionlessExtortion -> domainRootLink

TASK#STOMP PowerShell Backdoor

Securonix Threat Research dissects TASK#STOMP, a script-driven Windows backdoor that begins with a desktop VBScript and builds a redundant persistence framework under a folder masquerading as a Windows Defender service. It installs four XML-defined scheduled tasks, a Startup-folder launcher, backdates artifacts, launches two hidden PowerShell modules and compiles C# at runtime through the legitimate .NET compiler. The decoded payloads harvest and exfiltrate documents in real time, steal Wi-Fi passwords and clipboard contents, take screenshots and accept remote commands through two token-authenticated C2 servers. Its strength is combining familiar native tools into resilient, evasive espionage.

Watch for:

• VBScript/PowerShell chains abusing Task Scheduler and .NET runtime compilation
• Scheduled-task XML, Script Block Logging and AMSI telemetry as detection anchors
• Masquerading paths and timestomping that frustrate process-only detection
• Redundant C2 with failover and mutual monitoring between modules

Wardley signals:

• Components: Windows Script Host (wscript.exe/VBScript); PowerShell; Task Scheduler; the .NET C# compiler; Startup folder; AMSI; Script Block Logging; token-authenticated C2 servers; TLS validation bypass.

• Evolution stage: Windows-native tooling (WScript, PowerShell, Task Scheduler, .NET) is Commodity; the TASK#STOMP framework and loader are Custom (bespoke, per-campaign); C2 infrastructure is Product; runtime-compiled helpers are emerging.

• Doctrine: Attackers exploit a miss on “Know the details” and “Manage failure” (process telemetry alone misses compiled source and config); the detection chain reflects “Effectiveness over efficiency” and “Use appropriate methods”; “Challenge Assumptions” about native binaries.

• Climatic patterns: “Everything evolves through supply and demand competition” (living-off-the-land abuse); “Characteristics change as components evolve”; “Evolution consists of multiple waves of diffusion”; “Success breeds inertia” (signature-based detection).

• Diffusion markers: Repeated use of the same native-tool playbook across threat actors; published detection chains and telemetry recommendations; modular malware recombining PowerShell and C# components.

• 🚩 TASK#STOMP Backdoor Combines Windows-native Tooling with Persistent Document Theft, Surveillance, Credential Collection, and Remote Access.

wardley-beta
%% Q1 Who are the users? Incident responders and threat hunters investigating Windows intrusions.
%% Q2 What are their needs? Reconstruct a script-driven backdoor from native-tool telemetry alone.
%% Q3 What capabilities are required? Persistence detection, script logging, AMSI telemetry, and C2 identification.
%% Q4 What components are used? VBScript loader, scheduled tasks, PowerShell modules, .NET runtime compilation, AMSI telemetry, C2 servers.
%% Q5 How mature are those components? Windows native tooling is Commodity; the TASK#STOMP loader is Custom; C2 infrastructure is Product; runtime-compiled helpers are emerging.
%% Q6 Who manages them and how? Securonix Threat Research documents it; attackers operate bespoke, per-campaign tooling.
anchor incidentResponder [0.93, 0.88]
component vbscriptLoader [0.3, 0.78]
component scheduledTasks [0.5, 0.64]
component powershellModules [0.6, 0.74]
component dotnetRuntimeCompilation [0.42, 0.5]
component amsiTelemetry [0.68, 0.38]
component c2Servers [0.84, 0.28]
vbscriptLoader -> scheduledTasks
scheduledTasks -> powershellModules
powershellModules -> c2Servers
dotnetRuntimeCompilation -> powershellModules
amsiTelemetry -> incidentResponder
c2Servers -> incidentResponder

Entra ID Passkey Migration

SRA walks through Microsoft’s retirement of SMS and voice authentication in Entra ID on 1 February 2027, with passkeys becoming the default from September 2026. SMS and voice are phishable, SIM-swappable shared secrets, while passkeys are phishing-resistant FIDO2 key pairs that bind authentication to a device and the issuing domain. The post lays out the milestones, the device-bound versus synced passkey trade-off, recommended policy configuration and attestation, and a three-phase assessment, enablement and enforcement plan — warning that the timeline is aggressive and organizations should start now.

Watch for:

• Users registered only with SMS/voice being blocked after the February 2027 cutover
• Choosing device-bound versus synced passkeys against your threat model
• Conditional Access policies and service accounts that cannot use passkeys
• Third-party telecom providers via the Microsoft Security Store for stragglers

Wardley signals:

• Components: Microsoft Entra ID; SMS/voice authentication; FIDO2/passkeys; Microsoft Authenticator; Windows Hello; Conditional Access; FIDO Alliance Metadata Service; Microsoft Security Store telecom providers; the Entra SMS/voice usage analyzer.

• Evolution stage: SMS/voice authentication is late-Commodity and being retired; Entra ID is Commodity; passkeys/FIDO2 are moving from Custom/Product toward Commodity as platform defaults; attestation and policy tooling are Product.

• Doctrine: “Use standards” (FIDO2) and “Manage inertia” (migrating off legacy MFA); “Think fast, inexpensive, restrained and elegant” in phasing; a miss would be “Know your users” (frontline workers without devices).

• Climatic patterns: “Everything evolves through supply and demand competition”; “Characteristics change as components evolve” (shared secret to cryptographic); “Inertia can kill an organisation”; “No single method fits all” (device-bound versus synced).

• Diffusion markers: Platform defaults, published migration guides and timelines, standardised FIDO2/attestation, a vendor ecosystem (YubiKey, Bitwarden, LastPass), and a security-store marketplace.

• Changes to Entra ID’s SMS, Voice, and Passkey Authentication are Here: Are You Prepared?

wardley-beta
%% Q1 Who are the users? End users signing in and the identity administrators who run Entra ID.
%% Q2 What are their needs? Phishing-resistant sign-in that keeps working across devices.
%% Q3 What capabilities are required? Strong authentication, policy control, conditional access, and attestation.
%% Q4 What components are used? Passkeys/FIDO2, Entra ID, SMS/voice authentication, Conditional Access, the FIDO Metadata Service, third-party telecom providers.
%% Q5 How mature are those components? Entra ID and SMS/voice are Commodity (the latter retiring); passkeys are Product becoming default; attestation and telecom brokerage are Product/emerging.
%% Q6 Who manages them and how? Microsoft sets defaults and deadlines; organizations configure policy and phase the migration.
anchor endUser [0.93, 0.9]
component passkeys [0.55, 0.8]
component entraId [0.7, 0.62]
component smsVoiceAuth [0.82, 0.4]
component conditionalAccess [0.6, 0.5]
component fidoMetadataService [0.45, 0.34]
component telecomProviders [0.78, 0.22]
passkeys -> endUser
entraId -> endUser
conditionalAccess -> passkeys
fidoMetadataService -> passkeys
smsVoiceAuth -> entraId
telecomProviders -> smsVoiceAuth
evolve passkeys 0.72

MoE Inference Hardware

SemiAnalysis maps how Mixture-of-Experts models are served on inference hardware, arguing that the useful unit is not parameter count but the active flow of the model joined to memory, communication and timing hierarchies. It separates four operating regimes — prefill, midfill, decode attention and decode experts — each with different arithmetic intensity and batching behavior, then traces how KV state moves as immutable blobs through HBM, CPU DRAM and shared storage. It develops pipeline, tensor and expert parallelism, the KV-cache crossover that bounds pipeline depth, and the control loops that keep a disaggregated “token factory” in steady flow.

Watch for:

• Disaggregated prefill/midfill/decode pools and KV-blob movement through shared storage
• Pipeline, tensor and expert parallelism chosen per operation rather than uniformly
• HBM bandwidth versus capacity economics for interactive decode
• Scheduler feedback loops that oscillate under delayed admission control
• 3D and hybrid-bonded memory shifting the midfill/decode trade-off

Wardley signals:

• Components: MoE models; prefill/midfill/decode-attention/decode-expert workers; KV-cache blobs; NVIDIA Dynamo, Mooncake and vLLM; NVLink/NVL72; HBM, CPU DRAM and SSD tiers; expert routing and all-to-all; schedulers and ready buffers.

• Evolution stage: HBM, NVLink and GPU compute are Product heading toward Commodity; KV-cache orchestration and disaggregated serving are Custom/emerging Product; expert-parallel serving is emerging; inference schedulers are Custom.

• Doctrine: “Optimise flow” and “Do better with less” (stage-specific mapping); “Use appropriate methods” (different parallelism per regime); “Think small teams” and “Design for constant evolution” fit modular workers; a miss would be treating all four regimes as one workload.

• Climatic patterns: “Everything evolves through supply and demand competition”; “Efficiency enables innovation (Componentisation effect)”; “Commoditisation <> Centralisation”; “Efficiency does not mean a reduced spend (Jevons)”; “Change is not always linear.”

• Diffusion markers: Shared open references (Unified Radix Cache), standard orchestration stacks, simulated projections across B200/B300/GB200, and industry convergence on scale-up domains.

• Computation and Data Movement for Inference

wardley-beta
%% Q1 Who are the users? AI service operators running large inference clusters for interactive users.
%% Q2 What are their needs? High interactivity and high utilization at acceptable cost per token.
%% Q3 What capabilities are required? Model serving, KV-state movement, parallelism, memory, and scheduling.
%% Q4 What components are used? MoE models, prefill/decode workers, KV-cache blobs, scale-up fabric, HBM memory, the inference scheduler.
%% Q5 How mature are those components? GPU compute, HBM and NVLink are Product toward Commodity; disaggregated serving and schedulers are Custom/emerging.
%% Q6 Who manages them and how? Platform and infrastructure teams with orchestration stacks such as Dynamo, Mooncake or vLLM.
anchor serviceOperator [0.94, 0.9]
component moeModels [0.5, 0.82]
component kvCacheBlobs [0.6, 0.64]
component prefillDecodeWorkers [0.42, 0.7]
component scaleUpFabric [0.7, 0.42]
component inferenceScheduler [0.3, 0.5]
component hbmMemory [0.8, 0.28]
moeModels -> serviceOperator
prefillDecodeWorkers -> moeModels
kvCacheBlobs -> prefillDecodeWorkers
scaleUpFabric -> prefillDecodeWorkers
inferenceScheduler -> prefillDecodeWorkers
hbmMemory -> kvCacheBlobs

NuPhy Kick75 Keyboard

Marius reviews NuPhy’s Kick75, a hybrid-profile 75% mechanical keyboard that shares one PCB and chassis across NuPhy’s nano low-profile and Max high-profile switch families via a $30 swap kit. The $109–$129 board is all polycarbonate with five dampening layers, gasket mount, hot-swap switches, south-facing RGB and a divisive red volume knob; it types comfortably and sounds “thoccy” for the money. The catch is that switching profiles is a roughly hour-long full disassembly, so for most buyers it is effectively a one-way trip between low- and high-profile.

Watch for:

• Whether hybrid-profile boards deliver real flexibility or become one-way conversions
• Budget boards competing on engineering and acoustics rather than materials
• Switch and keycap ecosystem compatibility (nano versus Max, unified stabilizers)
• Firmware choice (NuPhyIO versus QMK/VIA) as a paid SKU
• The price-and-feel gap against entry aluminum 75% boards

Wardley signals:

• Components: NuPhy Kick75; nano (low-profile) and Max (high-profile) switch families; unified 5-pin layout and stabilizer geometry; the conversion kit; gasket mount; double-shot PBT nSA/mSA keycaps; NuPhyIO and QMK/VIA firmware; south-facing RGB.

• Evolution stage: Mechanical keyboards and hot-swap/gasket designs are Product (maturing, feature-differentiated); QMK/VIA is a de facto standard approaching Commodity; PBT keycaps and switches are Product/Commodity; the hybrid-profile concept is Custom/emerging.

• Doctrine: “Focus on the outcome” and “Think fast, inexpensive, restrained and elegant” fit the value engineering; “Use standards” (QMK/VIA, shared pin layout); a miss on “Know your users” if the swap friction surprises buyers.

• Climatic patterns: “Everything evolves through supply and demand competition”; “Characteristics change as components evolve” (enthusiast features diffusing down-market); “No single method fits all”; commoditisation of enthusiast features.

• Diffusion markers: Enthusiast features (gasket mount, dampening, PBT) reaching $109 boards; a paid QMK/VIA SKU and conversion kit as ecosystem plays; community reviews and showroom presence.

• NuPhy Kick75

wardley-beta
%% Q1 Who are the users? Mechanical-keyboard enthusiasts and buyers of entry-level boards.
%% Q2 What are their needs? A good-sounding, comfortable board that offers flexibility at a fair price.
%% Q3 What capabilities are required? A chassis, mounting, switches, keycaps, firmware, and a conversion path.
%% Q4 What components are used? Kick75 board, hybrid-profile design, nano/Max switches, gasket mount, PBT keycaps, QMK/VIA firmware.
%% Q5 How mature are those components? Hot-swap, gasket mount, PBT and QMK/VIA are Product/Commodity; the hybrid-profile concept is Custom.
%% Q6 Who manages them and how? NuPhy designs and sells the board; the QMK/VIA ecosystem and community provide firmware and reviews.
anchor keyboardEnthusiast [0.93, 0.9]
component kick75Board [0.5, 0.82]
component hybridProfile [0.35, 0.68]
component nanoMaxSwitches [0.55, 0.58]
component gasketMount [0.65, 0.48]
component pbtKeycaps [0.76, 0.38]
component qmkViaFirmware [0.84, 0.28]
kick75Board -> keyboardEnthusiast
hybridProfile -> kick75Board
nanoMaxSwitches -> kick75Board
gasketMount -> kick75Board
pbtKeycaps -> nanoMaxSwitches
qmkViaFirmware -> kick75Board

Cloudflare Python Workers

Simon Willison notes that Cloudflare’s Python Workers are now generally available after a two-year preview, making Python “a first-class, fully supported language” on the Developer Platform. The trick is that Cloudflare compiles Python to WebAssembly via Pyodide inside its V8-based workerd runtime, which imposes documented limits — notably non-functional threading and multiprocessing. He highlights the local development story: pywrangler (packaged as workers-py) simulates the whole stack, running Pyodide, WASM and V8 in a 123MB workerd binary. The release is credited to Pyodide core maintainers, signalling Cloudflare’s investment in the Python ecosystem.

Watch for:

• WebAssembly/Pyodide limits (no threads or multiprocessing) shaping what fits
• The local dev story (pywrangler/workers-py, workerd binary) for production parity
• Cloudflare’s continued investment in the Python and Pyodide ecosystems
• Serverless edge runtimes standardising on WASM isolates

Wardley signals:

• Components: Cloudflare Python Workers; Pyodide; WebAssembly; the V8/workerd runtime; pywrangler / workers-py; the Cloudflare Developer Platform; serverless edge functions.

• Evolution stage: Serverless edge runtimes are Product maturing toward Commodity; WebAssembly sandboxing is Product; Pyodide is Product/emerging; Python-on-Workers is moving from Custom/Product into Commodity availability at GA.

• Doctrine: “Use standards” (Python, WASM, V8); “A bias towards open” (open-source Pyodide maintainers, published limitations); “Focus on the outcome”; a miss on “Know your users” if threading limits surprise migrators.

• Climatic patterns: “Everything evolves through supply and demand competition”; “Efficiency enables innovation (Componentisation effect)”; “Commoditisation <> Centralisation” (edge compute); “Evolution of communication mechanisms can increase the speed of evolution.”

• Diffusion markers: GA after a two-year preview, documented limitations, local tooling, Pyodide core maintainers credited, and first-class language status.

• Cloudflare Python Workers are now generally available

wardley-beta
%% Q1 Who are the users? Python developers deploying serverless functions at the edge.
%% Q2 What are their needs? Run Python on a managed edge platform without giving up local development.
%% Q3 What capabilities are required? A language runtime, sandboxing, an edge platform, and a local dev tool.
%% Q4 What components are used? Cloudflare Python Workers, Pyodide, WebAssembly, the workerd runtime, pywrangler, the edge platform.
%% Q5 How mature are those components? Edge/serverless and WebAssembly are Product; Pyodide is Product/emerging; Python-on-Workers just reached Commodity availability at GA.
%% Q6 Who manages them and how? Cloudflare runs the platform and credits Pyodide core maintainers; developers use pywrangler locally.
anchor pythonDeveloper [0.93, 0.9]
component pythonWorkers [0.5, 0.82]
component pyodide [0.34, 0.66]
component webassembly [0.45, 0.5]
component workerdRuntime [0.62, 0.56]
component pywrangler [0.28, 0.38]
component edgePlatform [0.8, 0.4]
pythonWorkers -> pythonDeveloper
pyodide -> pythonWorkers
webassembly -> pyodide
workerdRuntime -> pythonWorkers
pywrangler -> pythonWorkers
edgePlatform -> pythonWorkers

Model Context Protocol (MCP)

Simon Willison pushes back on the argument that MCP is pointless now that full coding agents can call APIs directly. He concedes there is little reason to use MCP with an unfettered, terminal-based agent, but argues that this misses its value: controlling exactly which external services an agent can reach, handling authentication without exposing API keys, giving users a sensible UI to connect services, and providing strong audit logging. For anyone building something less “YOLO” than a full-access agent, MCP makes all of that much easier, and dismissing it ignores the other products people want to build.

Watch for:

• Scoped access control and authentication without exposing API keys
• User-facing UIs for connecting and authorizing external services
• Audit logging and governance for agent tool use
• The MCP-versus-direct-API debate as agent architectures mature

Wardley signals:

• Components: Model Context Protocol (MCP); terminal/coding agents (Claude Code, Codex, Meta Muse, OpenClaw); direct API calls; authentication and credential brokering; audit logging; MCP server UIs.

• Evolution stage: Direct API integration is Commodity; full coding agents are Product/emerging; MCP itself is emerging Product (standardising but contested); MCP auth and audit tooling is Custom.

• Doctrine: “Use standards” (MCP as an interface standard); “Focus on user needs” and “Know your users” (governed access); “Manage failure” and “Effectiveness over efficiency” (audit, scoping); a miss on “Use appropriate methods” if you assume one agent fits all.

• Climatic patterns: “Everything evolves through supply and demand competition”; “No single method fits all”; “Evolution consists of multiple waves of diffusion”; “Higher order systems create new sources of value” (a governance layer atop agents).

• Diffusion markers: A contested standard, an ecosystem of MCP servers, mainstream coding agents adopting connectors, and ongoing public debate.

• MCP was always a bad idea?

wardley-beta
%% Q1 Who are the users? Agent builders and platform engineers wiring agents to external services.
%% Q2 What are their needs? Scoped access, safe authentication, user consent, and auditability for tool use.
%% Q3 What capabilities are required? A tool protocol, servers, credential brokering, audit logging, and client agents.
%% Q4 What components are used? MCP, MCP servers, authentication brokering, audit logging, coding agents, direct API calls.
%% Q5 How mature are those components? Direct API calls are Commodity; coding agents are Product; MCP is emerging Product; auth/audit tooling is Custom.
%% Q6 Who manages them and how? An open standard and ecosystem maintain MCP; agent vendors and platform teams adopt it selectively.
anchor agentBuilder [0.93, 0.9]
component mcpProtocol [0.45, 0.8]
component mcpServers [0.55, 0.62]
component authBrokering [0.36, 0.58]
component auditLogging [0.62, 0.44]
component codingAgents [0.78, 0.68]
component directApiCalls [0.86, 0.38]
mcpProtocol -> agentBuilder
mcpServers -> mcpProtocol
authBrokering -> mcpServers
auditLogging -> mcpServers
codingAgents -> agentBuilder
directApiCalls -> codingAgents