The Intelligence Commons

Could people combine what their local models learn into capability everyone can use? This page explores open federated distillation, beyond the work described on the north star. I am interested in the possibility and uncertain that it can work.

Speculation. This is neither a plan nor a promise. The small measured results below retain their original limits. They do not establish the open federation described here.

The idea, stated at full size

What if every loop fed a commons?

An intelligence commons: a pool of learned capability that strangers build together, that everyone can draw from, and that nobody can enclose. The rest of this page is what that would take.

The near-term work is one private learning loop: use rented frontier AI to help train a model on hardware you control. The question here is whether many such loops could learn from one another.

In this design, each person would distill a model from their own frontier interactions. The raw record would stay on their machines. They could choose to exchange the learned weights, which are separate from that record but can still leak information about it. Two Macs have already fine-tuned on separate data, exchanged adapters, and merged to byte-identical models for three rounds. That demonstrates a small exchange path. It does not demonstrate a commons.

The proposed next steps would move from two machines under one owner, to a trusted group, and eventually to strangers. Each participant would decide which updates to accept and merge locally. The hoped-for result is a shared model that improves through those contributions and remains available independently of a frontier provider. Whether the quality improves across different tasks and contributors is an open question.

Reasons to investigate

What the existing pieces establish

• Open merging works at small scale. The exchange-and-merge path is measured at two machines. Model merging generally is a live, productive research area: people combine independently trained models today and get useful results. The open question is whether it survives scale, heterogeneity, and strangers.
• Federation without sharing data is the design already. The group version being built (pooling effort without handing over the work itself) is this exact shape at trusted-group scale. And because the Exchange Dial is a per-connection setting rather than a switch, solo, group, and commons stop being three different systems: they're settings on the same one, and each operator picks their own point on the dial for each link. The commons is the far end of a dial every operator already holds, with the trust boundary pushed outward, which is precisely where it gets hard.
• Every link has an acceptance side, and that's the whole design. The dial carries two settings per link: what you send, and what you accept: from whom, verified how. A commons is defined by the second one. There is no central merge to capture, because there is no single merge: each node decides what it will accept and runs its own gate, and a contribution that fails your gate simply never enters your model. That's also the answer to who's in charge: nobody by construction rather than nobody by promise.
• Contribution verification has an early result. An open federation is worthless if you can't tell an honest contribution from a poisoned one. Verifying a training contribution (as opposed to re-checking a single answer) is a mostly unsolved problem, and it's the leg the company's work targets: a verifier that re-executes a sparse sample of a committed update caught 82 percent of a defined corruption while sampling under half a percent of the bytes. One defined corruption, one setup. That result tests the gate in one setup; it does not establish protection against an adversary.
• Precedent exists in adjacent territory. Wikipedia is a knowledge commons strangers built. Linux is an infrastructure commons strangers maintain. BitTorrent moved distribution to the edges and never gave it back. And the closest precedent is about compute rather than content: SETI@home and Folding@home ran strangers' machines on shared computation for two decades, at planetary scale, with verification standing in for trust: the same gate-the-work-not-the-person shape this page needs. None of them are models, and models fail in ways text and code don't. But "strangers, openly federated, producing a thing nobody owns" has worked before. And the conditions under which commons survive are documented, not mystical: Ostrom's fieldwork found the same short list everywhere: contributions are monitored, verification is cheap, rules are set by members, sanctions are graduated. The verifier and the dial are two of those conditions implemented; the governance ones are still owed.

Why I only half-defend it

What could prevent it from working

These are the failure modes that most concern me, in order:

• Poisoning. An open federation is an attack surface. One measured verifier against one defined corruption is nowhere near an adversarially hardened gate. If contributions can't be cheaply verified against a motivated attacker, the commons is dead on arrival, or worse, alive and quietly wrong.
• Refusal laundering, at scale. A private loop distills what a frontier model was willing to teach one person, under that provider's observation and revocation. A commons redistributes distilled capability to strangers, with no monitoring, no rate limits, and no way to un-share what has merged. The ceiling is still what the teacher can be induced to emit (the commons creates no capability the frontier withheld), but it removes every control that came with renting, at a scale where nothing can be recalled. I discuss this objection in the disempowerment letter, and it bites hardest here.
• Slop collapse. Merge enough mediocre slices and you may get mediocrity, not capability. Nobody knows whether open federation converges to the best of its contributors or the average of them. The two-machine result is consistency, and consistency is the precondition. But consistency is not quality.
• Guardrail decay. Fine-tuning even on benign data is known to degrade refusal behavior, and merging strangers' models compounds the uncertainty. A commons model cannot be assumed to carry any teacher's guardrails, so safety at the pool has to be built and measured there rather than inherited, and nobody has done that yet, including us.
• Terms of service. The commons would reuse what frontier models teach individual loops, and provider terms restrict what outputs can train. A private loop (your own consented traffic, teaching a model that serves your own workload and is never resold as a competing service) is a narrow, defensible position. An open federation redistributing distilled capability to strangers is a much larger target, and this fight may arrive before the technology does.
• Incentives. Why push your slice instead of only pulling? Reputation, reciprocity, or useful defaults could help, but each needs testing. I do not yet have an answer that would make participation worthwhile.
• The gatekeeper trap, mirrored. Control can concentrate around whoever sets acceptance rules or signs releases, including me. Each operator must be able to choose a gate and leave with their model. The commitment against gatekeeping would need to hold under those pressures.

Open, distributed systems can be harder to capture. They still have dependencies and vulnerabilities; ownership does not make an operator untouchable.

The gates between here and there

What would need to be tested

The important question is whether learning can accumulate across operators and frontier releases. The next experiment is a trusted group; only the two-machine exchange has been measured. Beyond that come the problems above: verification under attack, merging across heterogeneous contributors, and incentives to contribute. Each result or failure would belong in the claim ledger.

The private learning loop can be useful even if the commons fails. It has its own acceptance test: your model handles a declared share of your work on your machines after you unplug.