
User and problem: a machining plant's maintenance planner turns machine alarms into tickets by hand, late, and cannot later prove which system produced which advice. With AI writing tickets, the model must never decide whether a machine is at risk, and every piece of advice must trace back to the machine that produced it. SIMON (Sovereign Inference & Model Orchestration Network): your models, independent nodes, inference on demand. A peer-to-peer inference network (Rust, libp2p, MIT) for a company's own GPUs plus cloud GPUs. Every job returns an Ed25519-signed receipt bound to the exact output, verifiable offline, also in the browser (Rust verifier in WebAssembly). OpenAI-compatible API. Live product (/industry): rules from the AI4I 2020 milling-machine physics flag the risk and the failure mode; Gemma 4 26B-A4B drafts the ticket and picks inspection steps by ID from the plant's catalog, never writing one; every ticket is checked (fields, modes and urgency equal to the rules; no new numbers, links or role markers); any problem holds it for a person; the GPU node signs it (key pinned by the gateway). Predeclared sample: 14 of 15 published, 1 held (text raised the urgency), median 1.6 s, receipts all valid: 8 on the plant's RTX 3090, 7 on an AMD Instinct MI300X (vLLM, ROCm, AMD Developer Cloud; live on /network). Measured improvement: on our adversarial corpus the unsafe-draft escape rate fell from 7 of 12 (first, keyword-based validator) to 0 of 15 after the redesign. This is a software safety metric, not yet a measured plant outcome. MI300X benchmark (Qwen3.8-27B BF16, vLLM): 64 concurrent streams; SIMON added no measurable throughput cost (510/510 receipts verified). In our pre-registered cross-vendor test the audit flagged the same 5 of 32 prompts on the MI300X as on an RTX 3090 checked against itself: no penalty for the GPU vendor. Limits: a receipt proves who signed an output, not which model ran; AI4I is synthetic; a technician reviews every ticket.
18 Oct 2026
.png&w=828&q=75)
SIMON is a distributed habitat for open model weights. People with GPUs compute inference, receive a token for it, and the network verifies that they really did the work — without a single server anyone can switch off. Today a model is a file you download. A file has nowhere to live outside somebody else's API. SIMON is the place where weights reside: they run, they are used, they evolve, and access to them flows from the network rather than from one cloud. 2. Problem Three things at once: 2.1. Open weights have no infrastructure. A publicly released model sits on one server or waits to be downloaded. If the server disappears, the model disappears. There is no mechanism giving it a durable place to run. 2.2. Access to models is centralised. Even when weights are open, practical access runs through the APIs of a handful of companies. Whoever owns the API sets the price, the limits and the data-use terms. 2.3. Consumer hardware sits idle. Consumer graphics cards are idle most of the day. BOINC and Salad showed that people are willing to donate compute — but not for free, and not without verification of the work. What is missing: a mechanism that pays for work genuinely performed and verifiable on somebody else's hardware. 3. Thesis THINK for verified work; a burned fee as the condition of issuance. Three elements, inseparable: 1. Verification — the network must be able to check that a node actually computed, rather than merely claiming to. 2. Lottery — the client does not pick the node, so it cannot buy "its own". 3. Settlement — work pays, cheating loses the stake. Without verification the rest is pointless: a node that signs a fake result itself passes every check. This is the point where SIMON either stands or falls.
1 Dec 2026