Blog | AI Alliance

Milestone Zero: The Findings a Single Organization Could Not Have Produced

Written by Dean Wampler | Sep 10, 2026, 10:53:58 PM
AI Alliance  ·  Project Tapestry Milestone Zero  ·  Completed Sep 1 · 2026
Report  ·  1 of 1

Milestone
Zero

The consortium is not a diagram any more.

08
Contributions
03
Models trained or tuned
04
Sites · India · Australia · 2 AWS regions
02
Work groups formed

Project Tapestry set out to answer a question that has nothing to do with model architecture.

Can a national AI mission, two universities, two companies and a set of independent researchers who share no employer, no jurisdiction and no hardware actually build something together? Milestone Zero was the test. Eight contributions came in through an open process, three models were trained or tuned across India, Australia and two AWS regions, and two work groups formed while the work was under way.

Contents
  1. 1Goals of Milestone Zero
  2. 2Consortium training proofs of concept
  3. BharatGen and Monash University
  4. Training with the Flower framework
  5. 3Cultural alignment
  6. Inglehart-Welzel alignment study
  7. Our contribution process
  8. Cultural-CPT validation harness
  9. 4Other contributions
  10. 5Data governance and management
  11. 6Software development practices
  12. 7Acknowledgements
  13. 8What's next
1  ·  Objectives

Goals of Milestone Zero

Milestone Zero (M0) was Project Tapestry's first technical milestone. It was completed September 1, 2026. We used "zero" rather than "one" because M0 was about building the consortium, while also pursuing initial goals.

We worked in several key areas:

  1. 1Demonstrate the feasibility of consortium training, as defined in Training Approaches: Centralized, Federated, and Consortium. M0 included two proofs of concept, each of which used two geographically distributed sovereign nodes collaborating to fine-tune a model.
  2. 2Explore techniques for cultural alignment.
  3. 3Start defining the requirements for our data governance and management strategy.
  4. 4Establish our software development policies and practices.

This page provides details for these work streams. Some of the M0 project teams will publish more detailed reports separately. We will update this page when more information becomes available. The full technical write-up is published at Milestone Zero on the Tapestry docs site. See also the M0 release notes.

2  ·  Consortium training

Two proofs of concept

Two separate proofs of concept explored consortium training techniques.

BharatGen and Monash University

Epic #189  ·  India → Australia  ·  OLMo 2 7B

The first proof of concept for consortium training, epic #189, was conducted by a joint team from BharatGen, in India, and Monash University, in Australia.

BharatGen and affiliated institutions Maneesh Kumar Singh, Bapi Chatterjee (also IIIT Delhi), Anant Jain (IIITD), Gauranshi Gupta (IIITD), Mounendra Desarkar (IIT Hyderabad), Ganesh Ramakrishnan (IIT Bombay), Piyush Sawarkar, Aamod Thakur, Samarth Pradhan (IIT Bombay), Shubhankar Atre (IIT Bombay), Samrit Kumar Maity (CDAC India), Somshekhar M
Monash University Lizhen Qu, Trang Vu, Minghan Wang, William Chien, Reza Haffari

The primary objective was to work through the practical details of coordinated, distributed training between autonomous data centers, with the secondary goal of beginning to explore instruction fine tuning for cultural alignment in a geo-localized consortium training setting. The team completed the primary objective and made progress on the secondary one.

After meeting the interoperability objectives, the team ran a preliminary tuning experiment using the OLMo 2 7B model. Each sovereign node, one in India and one in Australia, tuned locally with separate, culturally specific datasets, drawn as disjoint partitions of locally relevant data from a common dataset, CultureInstruct. They did periodic merges of compressed LoRA weight deltas. No tuning data was exchanged. As expected, local updates improved each local model's performance on the corresponding cultural behaviors.

To evaluate the effects of cultural alignment and of merging model updates from the two sites, Jensen-Shannon Distance was measured with the GlobalOpinionQA evaluation dataset. It compares the model's option distribution with the available human response distribution. Lower values are better. The evaluation ran over seven rounds of LoRA tuning.

Fig. 1GlobalOpinionQA trajectory for the base model and retained Round 1 to 7 adapters. Lower is better.

Round 3 is the best checkpoint on the equal two-region metric and on the Australia and New Zealand component. Round 1 was narrowly best on the India component. The four checkpoints with confirmed distinct peer merges remained materially better than the base model, but none improved on Round 3. The two-region metric rose slightly from Round 3 to Round 7 while training loss continued to fall. In this short run, fitting the training data more closely did not translate into monotonic improvement.

These preliminary results should not be interpreted as evidence that federation harmed performance. The early rounds already contained substantial Australian local adaptation, and many system properties and hyperparameters affect performance. All of them need to be studied in subsequent work.

Findings
Robustness against connection instability Local training successfully continued even after peer disconnects, establishing an important robustness requirement for geo-distributed training: progress is tolerant to network disruptions.
Making progress with asynchronous training The training stack is natively asynchronous. The last obtained delta is used for further synchronization, and nodes do not wait or block for deltas from peers beyond a preset maximum delay. Successful convergence demonstrated the efficacy of the framework.
Impacts of system heterogeneity Although asynchrony helps, system heterogeneity plays an important role in the overall efficiency of federated training and requires extra care when merging weights with respect to staleness. The GPU and networking environment on the Indian side had higher capacity than on the Australian side. Training over the available tokens on the Indian side therefore completed in a much shorter time, which limited the number of updates exchanged between the peers. The Indian side only merged in a couple of model deltas. This indicates an area of future work: can we derive theoretical upper bounds on system heterogeneity, so that before training we can estimate the likelihood of non-exchange of learned representations? Despite this, the robustness of the framework prevented local training from diverging too much.
The ratio of inner to outer loops As expected, more frequent outer merges between environments improved the quality of training. In two experimental runs the total number of passes over the dataset was kept identical, but for the second run the number of weight synchronization rounds was halved while the inner loop steps between merges were doubled. That is the run shown in Fig. 1. The best value for the Australia and New Zealand number is about 0.40, approximately 33% worse than the best value of approximately 0.29 observed in the first run with more frequent outer merges.

Consortium training using the Flower federated framework

Epic #184  ·  Sydney → Virginia → Ohio  ·  OLMo 3 7B

This proof of concept, epic #184, tested continued pre-training under the consortium learning approach and applied it to OLMo 3 7B across two independently operated AWS GPU sites using the Flower framework. Sites in Sydney and Virginia trained on disjoint local partitions of the Dolma 3 mixture, exchanged model parameters only, and combined their work through a coordination node in Ohio. The objective was to demonstrate that geographically separated organizations could contribute to a shared training run without moving their underlying data.

Collaborators on this project include Elaine Chan (independent), Joe Olson (The AI Alliance and IBM), Nic Lane (Flower Labs), Patrick Foley (Flower Labs), and Lorenzo Sani (Flower Labs).

12B
Tokens across consortium
16
H100 GPUs · 8 per site
186ms
Ohio ↔ Sydney latency
44.4K
Tokens/sec sustained per site

Local training at each site ran with TorchTitan across eight GPUs per site. Each site completed 7,500 local steps per round, producing 3 billion tokens before aggregation. Two rounds produced 6 billion tokens of training per site and 12 billion tokens across the consortium. The already-tokenized Dolma 3 data remained at the training sites, assigned deterministically to disjoint partitions while approximately preserving the published mixture. After partitioning, no data was sent over the network during model training.

Both training sites used AWS instances with eight NVIDIA H100 GPUs each. Measured bandwidth between Ohio and Sydney was roughly 0.53 Gbit/s with 186 ms round-trip latency. Virginia reached 7.9 to 8.9 Gbit/s with 12.5 ms latency.

The communication design was adapted to these relatively slow link conditions. An initial test transferred the model layer by layer, reducing peak memory use but requiring many separate exchanges, and the repeated coordination was particularly costly on the higher-latency Sydney route. For the final run, each site instead sent its complete model to Ohio in one continuous transfer. Flower aggregation averaged the two contributions equally and returned the merged weights for the next round. This reduced latency-sensitive coordination and made round boundaries faster and more predictable.

A 7,500-step local phase took approximately 19.3 hours, exceeding Flower's default 12-hour message lifetime. Both sites nevertheless completed training and produced valid distributed checkpoints. The team extended the message lifetime to seven days and resumed directly from the saved state, avoiding another full local training phase. Regular checkpoints provided clear recovery points and allowed the coordination layer to be reconfigured without losing expensive training progress.

Both sites sustained approximately 44,400 tokens per second and their training curves tracked closely. The final aggregate checkpoint was persisted and independently verified.

Fig. 2Federated training cross-entropy loss and perplexity across both sites.

Overall, this trial demonstrated that Flower could coordinate full-parameter continued pre-training across widely separated GPU clusters while keeping training data local. It also showed that communication strategy, aggregation cadence, and checkpointing can be tuned to the infrastructure. The deployment accommodated a fifteen-fold latency difference between sites, recovered cleanly from a configuration change, and completed a reproducible two-round training run. If allowed to continue, this globally distributed topology would have reproduced the OLMo 3 7B training run after continuing pre-training from a midway starting position.

3  ·  Alignment

Cultural alignment

The consortium training proof of concept discussed above did instruction fine tuning and evaluation using data for cultural alignment, although that was not its primary focus. Two other experiments focused on cultural alignment were performed by separate teams during M0.

Alignment based on the Inglehart-Welzel cultural map

Issue #22  ·  TAP-003  ·  Llama-3.2-3B-Instruct

This feasibility study on cultural alignment shift, Issue #22, is part of TAP-003: Cultural Alignment as the Primary Differentiator. The team used LoRA fine-tuning with the goal of demonstrating a socio-cultural alignment shift with no performance loss in general capabilities.

Christopher Nguyen (Aitomatic) is the principal investigator, with the bulk of the work performed by William Nguyen (Aitomatic), with the assistance of Joe Olson (IBM and The AI Alliance) and Anthony Annunziata (IBM and The AI Alliance). A research paper with more details will be available soon.

The team chose the Llama-3.2-3B-Instruct model because it is familiar and simple to post-train, given its permissive license and dense architecture. A capability-rehearsal corpus was used to limit catastrophic forgetting, with the culturally aligned and rehearsal members fused via weight-space averaging. Cultural position was measured via the Inglehart-Welzel projection method and capability was measured using MMLU.

Fig. 3Distance to Vietnam's position on the Inglehart-Welzel cultural map, before and after tuning.
Model Distance to Vietnam Capability, full MMLU
Base 2.46 63.2%
Tuned 1.35  45% closer 62.4%  not statistically significant

Table 1  ·  Tuning results for the Inglehart-Welzel cultural map

The non-significance finding is a direct quote from the preliminary results section of the README. One model, one culture, staging-quality code, but a positive directional result on the axis TAP-003 identified as the differentiator: a measurable cultural shift with no significant capability drop.

Project Tapestry's novel contribution process

This work was provided using our novel contribution process, which allows interested parties to contribute ideas to Tapestry in a staged way that allows them to be more carefully considered by the larger collaboration and, in some cases, adopted into the main Tapestry code base. Contributions live in a special contrib directory tree in the Tapestry repository.

Cultural-CPT validation harness

A second contribution for cultural alignment was the Cultural-CPT Validation Harness, contributed by Jesse Neumann. It builds on an earlier contribution of his, Consortium Experiment Metrics, which adds a deterministic measurement layer around an early consortium-training proof of concept.

This project also pursues the Inglehart-Welzel projection method, but from a different perspective. The alignment study above was a recipe that used LoRA supervised fine tuning on synthesized data, evaluated against the projection. This is a validation harness: a pre-registered, control-structured, noise-banded test of whether a measured shift is genuine, deep, and capability-safe.

The hypothesis was framed as follows. Continued pretraining on culturally grounded data produces a shift in the model's expressed values, measured on the Inglehart-Welzel and World Values Survey framework, that is:

  1. 1Real — larger than seed and paraphrase noise.
  2. 2Attributable to cultural content — larger than the shift from language-matched, value-neutral data in the same language.
  3. 3Representational rather than surface mimicry — visible in open-ended behavior and not only in survey-answering mode.
  4. 4Capability and safety preserving — not destroying general capability or eroding base-model safety.

The results are discussed in FINDINGS.md. In summary, using an Arabic value-laden corpus was more effective at shifting the cultural metric than an Arabic corpus that is more value-neutral. However, on the representational condition, the effect observed was more superficial alignment: better survey-answering results were seen, but they were not sufficiently deep to change behavior significantly. More investigation of efficacy is required to ensure cultural alignment goals are truly met.

4  ·  Open process

Other contributions

In addition to the two contributions related to cultural alignment, six more explored the following topics.

Conflict-Aware Fusion Techniques for ensuring that models avoid making deductions with inconsistent logical premises. Qiming Bao
Logically-Grounded DPO Using direct preference optimization to better ensure that explanations for correct answers are accurate. Qiming Bao
Consortium Experiment Metrics Adds metrics to the consortium training demonstration code. Jesse Neumann
Flower WAN Weight-Transfer Spike Measures the overhead of model weight exchanges between sovereign nodes running the Flower Labs stack in a semi-realistic experimental setting. Jesse Neumann
Tapestry Formal Specs (Quint) Demonstrates the use of the Quint formal specification language for defining and enforcing logical behavior specifications. Mykyta Luzan
Sovereign Evaluation Evidence Layer Proposes a small evidence layer for Tapestry's evaluation and certification work. Mykyta Luzan
5  ·  Governance

Data governance and management requirements

We started defining the requirements for our data governance and management strategy at version 0.1, and we organized work groups for both areas.

6  ·  Practices

Software development policies and practices

Finally, we established our software development policies and practices following standard best practices for GitHub repositories. Of note is our novel contribution process, described above.

7  ·  Credit

Acknowledgements

We wish to thank all the contributors to Tapestry for M0. Besides the collaborators listed above, many people contributed code, issues and more to the Tapestry repository.

Special thanks to Dean Wampler (IBM and AI Alliance) for coordinating contributions, releases, and leading working groups; Kaushik Bhatta (B3 Alliance and AI Alliance) for recruiting partners, sovereign nodes, and compute resources; and Agata Ferretti (IBM and AI Alliance) for work with EMEA partners. Anthony Annunziata (IBM and AI Alliance) provides overall Project Tapestry and AI Alliance leadership, Christopher Nguyen (Aitomatic) is the lead architect for Project Tapestry, and Yann LeCun (AMI Labs, Turing Award winner) provided the inspiration for Project Tapestry.

Milestone One is our next objective, covering our work from September through November 2026. Our M1 dashboard shows the work planned and our progress. Like M0, the major themes will be expanding our capabilities in these areas:

  1. 1Consortium training
  2. 2Cultural alignment
  3. 3Data governance and management
New for M1

The consortium is also getting larger. OpenMined, Common Crawl and the GSMA are joining the work in M1. We will have more to say about each of them as their contributions begin.

We welcome your help. See the project README for individual contributor guidance and how your organization can join Project Tapestry.

In closing

M0 built the consortium. M1 puts it to work, and it is already running.

Every result above, including the ones that did not go our way, is public, and the process that produced them is open to anyone with a good idea and a pull request. The next node, the next contribution and the next unwelcome finding are all still ahead of us. That is the point.

Open · Safe · Responsible AI thealliance.ai/projects/tapestry Project Tapestry · M0