Project Tapestry has moved from a sovereignty concept to a small technical demonstration. Its first milestone included two proofs of concept, each joining two geographically distributed training clusters so that organisations could fine-tune a model together while retaining local control of their underlying data and systems.[1][2]
The demonstrations establish that geographically separated clusters can collaborate under the tested conditions. A larger consortium introduces further engineering and governance questions: different accelerators, network speeds, software stacks, legal regimes and data licences. The next milestones need to show how the system behaves as that variation increases.
What Milestone Zero established—and what the roadmap still promises
| Measure | Value | Context |
|---|---|---|
| Milestone completion | 1 September 2026 | Milestone Zero covered consortium formation and initial technical work.Source 1 |
| Training demonstrations | Two proofs of concept | Each used two geographically distributed sovereign nodes.Source 1Source 2 |
| Additional M0 work | Cultural alignment, data governance and development policies | These workstreams began; they were not completed governance systems.Source 1 |
| Milestone One | September–November 2026 | Planned expansion of nodes, compute and heterogeneous hardware and software.Source 3 |
| Milestone Two | December 2026–February 2027 | Targets a production-quality distributed stack and preparation for training a base model from scratch.Source 3 |
| Initial architecture | Core plus sovereign layers | A shared base is enriched by local continued pretraining, alignment and adapters.Source 4 |
| Base-model strategy | Adopt open weights first; train a consortium base later | The phased plan aims to preserve sovereign work across a future base transition.Source 5 |
Sovereignty through interdependence is a real trade-off
A country or institution can keep its data and local adaptation while still depending on the shared base, training protocol, contribution rules and other participants. This may be preferable to dependence on one proprietary vendor, but it is not full independence. The governance question becomes which dependencies are visible, replaceable and jointly controlled.
The core-plus-sovereign design makes that explicit. Participants can adapt a common model to local language, law or domain expertise. If the base changes, the sovereign layer should remain portable. Portability is therefore not a slogan; it needs tests showing that adapters, data pipelines and evaluations survive migration.
The coordination problems that appear after the two-node proof
| Problem | Why it grows with the consortium | Evidence of a workable solution |
|---|---|---|
| Hardware heterogeneity | Nodes finish steps at different rates and numerical precision | Matched-quality runs across different accelerator and software stacksSource 3 |
| Network variance | Slow or intermittent links can stall synchronous training | Recovery tests, bounded staleness and measured communication overhead |
| Data governance | Every node brings different licences, privacy rules and documentation | Machine-readable contribution terms and audit of prohibited dataSource 1 |
| Model governance | A shared update can improve one language and harm another | Per-node evaluations, veto or rollback rules and transparent merge criteriaSource 4 |
| Contribution accounting | Compute, data and expertise are not comparable units | Published attribution and decision rights tied to contribution type |
| Exit and continuity | A member may leave or a base licence may change | Checkpoint custody, reproducible builds and tested replacement pathsSource 5 |
Federated does not mean raw data can never leak
Keeping source data at a node reduces one transfer risk. Model updates can still encode information, and logs, checkpoints or evaluation samples can reveal sensitive content. A sovereign node needs local privacy review, update inspection and the ability to refuse a contribution without losing its entire investment.
Consortium training also differs from ordinary federated learning. The participants may contribute compute, data, post-training, cultural alignment and governance rather than identical edge devices averaging gradients. That richness creates value and makes attribution and reproducibility more difficult.
The most important M1 result will be a failure map
A successful larger run should report more than final loss or benchmark score. It should show communication time, node dropouts, restarts, divergence, hardware-specific differences, privacy incidents, governance disputes and which local evaluations changed the merge decision. Those failures reveal whether distributed sovereignty is operational or ceremonial.
Project Tapestry is valuable because it treats open and sovereign AI as an engineering and institutional design problem rather than a national branding exercise. Its next milestones will show whether interdependence can be made inspectable: shared enough to build capability, local enough to preserve agency and modular enough that no participant is trapped by the collaboration meant to free it.
Sources & further reading
- Milestone Zero: Project Tapestry Project Tapestry / AI Alliance · 1 Sep 2026 · Accessed 11 Oct 2026
- Our First Milestone for Project Tapestry AI Alliance · 1 Sep 2026 · Accessed 11 Oct 2026
- Project Tapestry announcements and roadmap Project Tapestry / AI Alliance · Accessed 11 Oct 2026
- Core-plus-sovereign architecture decision Project Tapestry on GitHub · 7 May 2026 · Accessed 11 Oct 2026
- Phased base-model strategy Project Tapestry on GitHub · 7 May 2026 · Accessed 11 Oct 2026