When Federation Meets Mary

The pipe is being built by people with years of cryptography behind them. The ledger is the part nobody's building.

I keep returning to a question I left open in Ambient Learning: what happens to federation once it stops being a research corner and turns into plain infrastructure, the way HTTPS and containers did? The project I learned the idea from was FATE. So this is a forecast built on it. If FATE, or whatever FATE grows into, goes mainstream, what shifts in the industry, and what is Rao ready to do about it on day one?

My answer has a name: Mary, the umbrella I've been building everything else under. That's why the title is what it is.

(Drafted with A.I. from my own repositories and from FATE's public README and papers, then edited by me. The projects and the bets are mine.)

What I read, what I built and what I'm betting are three different things, and I'll keep them apart.

What FATE is, in its own words

FATE, the Federated AI Technology Enabler, calls itself "the world's first industrial grade federated learning open source framework to enable enterprises and institutions to collaborate on data while protecting data security and privacy."¹ It's Apache-2.0 and hosted by the Linux Foundation, which announced in 2019 that it would host a project WeBank's AI Group had initiated.² The README says it "implements secure computation protocols based on homomorphic encryption and multi-party computation (MPC)", and it ships the parts a real deployment needs: FATE-Flow schedules tasks across parties, FATE-Board inspects models, FATE-Serving serves them, KubeFATE deploys it on Kubernetes.

FATE-LLM extends it to language models, large and small, with parameter-efficient training and a method it calls FedIPR to protect model IP.³ One of its methods, FedMKT (COLING 2025),⁴ moves knowledge both ways between small models on clients and a large model on a server.

WeBank's name runs through the research as well as the repository. The 2019 survey that set out horizontal, vertical and transfer federated learning had two of its four authors at WeBank.⁵ The 2021 JMLR paper calls FATE "the first production-oriented platform developed by Webank's AI Department."⁶ The FATE-LLM and FedMKT papers list WeBank among their authors' affiliations.⁴,⁷ I note it because origin is part of a project's receipt, and a receipt isn't a verdict. The affiliations are as printed on each paper's first page, not anyone's current employer.

The shape, in one line: the model travels to the data, and the data stays where it is.

I'm describing FATE from its README and papers, and I'm only saying what they say. The README names no adopters, so I won't either. "Mainstream" in this post is a premise, not a report.

What changes if that's ordinary

Seven bets. Each is a bet.

1. Data stops being bought and starts being joined. Today, access to data means getting a copy: license it, scrape it, buy it. A copy can't be un-copied. If training can happen across parties without the rows moving, the thing worth trading is a seat in a computation, not a file. Whoever sells copies loses a moat. Whoever owns data that can't be copied from them gains a bargaining position they never had.

2. "The data never left" becomes the baseline claim, then the claim everyone has to prove. Finance, health and the public sector are the obvious first movers, because their rules already say where data may live. Once everyone says it, it stops being a differentiator and auditors start asking for evidence. But a federated system is hard to check from outside: the whole design is that nobody sees the data, including the person checking. What's left to inspect is the receipt.

3. Small models and big models start collaborating instead of one swallowing the other. FedMKT is that shape: small models near the data, a large one on the server, knowledge moving in both directions. It's the bet I've made before, that decentralized intelligence centralizes growth for the whole, showing up in someone else's codebase.

4. Credit gets harder, not easier. This is the one I'd underline. Federated training blends many parties' contributions into one model, and secure computation is built to keep each contribution unreadable to the others. That's the point of it. It's also the opposite of what attribution needs: a legible account of who contributed what to which answer. I searched the README for attribution, royalties, credit, payouts and consent and found none of them. That isn't a criticism. It's a different job. But it means a federated world inherits Attribution Decay, and "we can't tell whose data did what" stops being an oversight and becomes a property of the design.

This is the point where everything I've built answers at once, and it answers at the foundation, through AII. The rule underneath is an order of operations: record who a thing belongs to before it can be blended with anything. Aggregation blends first and can't easily separate afterward. AII records first, so there's nothing to separate. In AII that's mechanical, not a policy:

• The lane comes from the secret. A record's lane is named by the secret of the app that wrote it, and a lane a client sends is ignored. A document's lane is fixed for life.
• Merging can't launder ownership. Entities merge across apps in one graph, but a graph edit is refused unless every document behind it is in the editor's lane.
• Every passage keeps its owner and its place. Retrieval carries the owner and the partition each result came from, and the person's own passages are framed apart from anyone else's.
• Every turn is priced. Sewn splits each answer across the documents it cited, against the turn's real token cost, and the share lands in a wallet.

Ambient, Craft and Veil all file into that same index (text, code, and images as records with their regions as partitions), so for all three the credit chain starts at the first write.

The model is the harder half, and that's what I'm researching in Braid, with a commons and independent Thread models. The commons is one pretrained Mamba2 that every party shares and nobody trains. Each Thread is its own model: trained on one body of writing, which can be an AII lane, and never blended into another Thread's weights. Federated training asks how to blend contributions without exposing them. Braid asks whether they ever have to be blended at all. The answer is mixed at inference instead, and for every token Braid reports how much each strand supplied, with shares that sum to 1, each cited to a place in its own Thread. The trade is exact credit in exchange for having no single set of merged weights. It's the same rule as AII, one layer up: don't blend what you'll need to credit. It's research, not a finished system. The proof so far is small, and Part 2 of the series, still to come, will ablate whether the commons-and-Thread split does the work on its own.

It's credit by construction for what my own stack produces. It says nothing yet about a model whose weights were averaged somewhere else, and that's the untested join in the diagram further down.

5. Audits move from the data to the model. A dataset that was never assembled in one place can't be inspected in one place. Much of today's governance conversation is about training sets: what's in them, whether anyone agreed. In a federated world that handle disappears, and what's left is what the model does: can it reproduce a protected likeness, does it memorize. That moves the checkpoint to the model, which is where Scorpion and Veil already work.

6. The person becomes a party. FATE's parties are "enterprises and institutions," and its 2021 paper names its target "cross-silo data applications."⁶ A bank joins the federation, and its customers are rows in the bank's silo. Federation at the institution level protects one institution's data from another. It doesn't ask the person. The next open question is whether a person gets a seat of their own, with their own rules. That's the personalization principle from Ambient Learning, and the question STTP circles from the device side.

7. Power moves to whoever runs the coordination. Any protocol between parties needs somewhere that rounds are scheduled and terms are set. Whoever runs that place holds a quiet kind of control: not the data, not the model, but the terms. Open source and neutral hosting help. They don't make the question go away.

Mary, under one umbrella

Everything I've built so far sits under one name. Mary is Mesh, Ambient, Realm, Yoke, and the four words are the design: a mesh of nodes with no center, ambient by default so it works without an interrogation, a realm for each person and each app (in code, a lane), and a yoke that joins them without merging them. The macOS client ships today as Ambient, from a private repository. The picture is the whole idea.

Mary as one umbrella over AII, Braid, Craft, Ambient and Veil, set beside FATE as two ways to federate. Dashed means not built yet, or not public yet.

Three things in it matter as much as the stack.

There is always a reason. Nothing under the umbrella is decoration. Every piece began as the answer to a because, and the because is printed on its card: help shouldn't need an interrogation, a likeness shouldn't be something to copy, your data should keep its owner, every word should know where it came from. I build from the reason outward, which is why the pieces fit. They were never separate products looking for a story.

Safety has been prioritized along the way. An umbrella is shelter, and that's the other reading of the image. The four things falling outside it (uncredited use, data that left, a likeness copied, agents no one could read) are what the pieces under it exist to keep off. Each safeguard is something that exists in the code: a lane sealed by a secret, a wire that refuses anything beyond loopback, a receipt on every token, a gate meant to run before a model ships. I wrote the longer version in A System for A.I. Safety.

MaryOS is the same thinking with nothing underneath it. MaryOS is the Linux variant I'm building. It isn't public yet, so it's drawn dashed. The Mary repository, now private, describes it as where the assistant stops being an app on someone else's desktop and becomes the desktop. For federation that matters in one way: a device built around the index from its first boot arrives already holding a lane, and a receipt for every write. It's my test of what a machine looks like when this thinking is there from the ground up instead of installed on top. It's a test, not a product.

The right side of the picture sets the two options for federation next to each other, and I mean options. FATE federates the computation between institutions, and it's the more mature, better-resourced way there. Mary federates from the device up, and keeps the credit attached because it never let go of it. They answer different questions, and the rest of this post is about how they compose.

The five pieces

Each one answers a shift above.

AII is the foundation, and the party's side of the table. The Ambient Intelligence Index gives every app on a Mac one index: a knowledge graph and vector search over the person's own data, on-device models that answer from it with citations, and a personal layer that turns conversations into memory. Anything federated starts with a boring question every party has to answer first: what is my data, in what shape, under whose rules? AII is that answer, built before the question was fashionable, and it's where the fourth bet's answer lives. It's GPL-3.0.

Braid is the ledger. Braid is a language model made of strands. The commons is a pretrained Mamba2 that every strand shares and nobody trains. Each Thread is one body of writing, trained into its own copy of the commons' first layers. For every token it writes, Braid reports how much each strand supplied. The shares sum to 1, each Thread's part is cited to the place in its own writing, and every session is logged so it can be checked afterwards. That's the credit layer federation doesn't carry, and the research behind the fourth bet above. The proof so far is small: on October 19, at 130 million parameters with Threads of 40 documents, a trained Thread told writing it had studied from writing it hadn't, every time, and its index found the source of its own writing every time. It's a toy next to a frontier model, and I'd rather say so first. The longer story is in the Braid series.

Craft is the guarded silo. Craft is a coding agent that never leaves your machine, and it credits the code its names came from. A company's source is among the most guarded datasets it owns, and "the model comes to the data" is already how Craft works with it. Craft doesn't do federated learning. It's the shape of what a party runs.

Ambient is the person's seat. Ambient reads along with you and answers from what you've read, underlining every borrowed phrase back to its source. It's where a person's own data gets gathered, on their own device, into their own lane. If the person is going to become a party, Ambient is the interface they'd sit in.

Veil is the gate at the model. Veil halts an image generator mid-run when it starts copying a protected photo, and names whose photo it was. Underneath, it asks whether a model is able to produce a likeness, trained on it or not, and builds the adapter that closes that route. When audits move from the data to the model, a check that never needed the training set is the kind that keeps working.

Text, code and visuals already run on one index: AII's README lists Ambient, Craft and Veil as built on it today, and Braid's demo holds one Thread for each. So the lane model isn't a diagram. It's three shipped apps.

Where the line falls

Federation answers one question well: can we compute together without exposing the data? It leaves a second one open: whose data made this answer, under whose rules, and what did the result do? Mary has been working on the second.

Diagram

Rendering diagram

Solid lines exist today. Dashed ones are joins I haven't built or tested. The grey box is someone else's work.

What I'd do first

If a federated stack landed tomorrow, I wouldn't rebuild its secure computation. That's years of cryptography and engineering FATE already carries. I'd sit beside it:

1. Prepare each party's data in an AII lane, locally, under that party's own rules.
2. Train a Thread on the lane, so the party's learning has a boundary around it.
3. Run Braid's accounting over whatever the federated layer produces, to find out whether credit survives.
4. Check the model that comes out with a Veil-style test, since nobody can check the data it came from.

The experiment I'd run first is a specific one. A Thread's head is already the private, per-party part of Braid, separate from the shared tail. Whether FATE-LLM's parameter-efficient machinery can carry that head through a federated round is something I haven't tested. I'd publish the result either way.

What isn't built

A post about receipts that hid its own gaps would be a joke.

• There's no secure computation in it. No homomorphic encryption, no multi-party computation, no secure aggregation, no differential privacy, anywhere in AII or Braid. That's FATE's strength, and the reason to sit beside it.
• Braid's cluster runs in one process. The node protocol is in-process in v1, with a wire "later." The protocol that spreads it across machines is Part 4 of the series, and it isn't shipped.
• AII is one Mac, over loopback. Connecting one person's index to another's is the design I wrote about in Ambient Learning, not a feature.
• MaryOS isn't public. I'm describing it as a test, not a release, and nothing else in this post depends on it.
• STTP is a proposal. It's a question I've been circling, not a protocol you can install.
• Nothing has been benchmarked against FATE. Every "can it ride a round?" above is a question, not a result.

Where it's headed: the protocol

Everything above is a railway. A lane at every party, a receipt at every token, a gate at every model: each is a rail somebody has to be able to lay down and trust. Today every rail is somebody's convention. aii-record/1 is mine, Braid's session log is mine, FATE has its own, and none of them speak to each other. Conventions get replaced. Railways only matter once they're permanent, and what makes them permanent is a protocol.

That's where all of this points: STTP, the Semantic Token Transfer Protocol. I wrote it up around text, because text is the easy case, but the idea was never about words. STTP is about communicating any form of data between parties. A sentence, a function, the RGB values of a photograph, a sensor reading: whatever a device creates or edits, it prepares as tokens at that moment, and those tokens travel peer to peer to whoever is meant to have them. The protocol doesn't care what the data was. It only cares that it arrives as something a model can learn from.

The second half is what separates it from a data pipeline. Today, data is collected, cleaned, shipped to a training run, and weeks later a model is a little better. In STTP, what arrives is digested as it arrives: turned into training material on the fly and folded into the models on the receiving side, so the very next inference already reflects it. A photo one party's device just captured can change what another party's model sees a moment later, and a fix committed in one codebase can change what another party's agent suggests. No batch, no data lake, no waiting for a release.

That's the same problem FATE solves, made continuous and indifferent to the kind of data. The open question is the one this post keeps circling: how do many machines contribute without any of them, or any server, seeing each other's raw values? The IETF's Privacy Preserving Measurement work is the closest thing I've found to an answer, and FATE answers it with cryptography. What Mary adds is the part neither carries: every token that travels keeps its lane and its receipt, so when it's digested into a model, the credit survives the digestion. The local half already exists in design. AII files text, code and images as one kind of record, with a picture's regions as partitions that have their own vectors, and the first part of the Braid series describes a person's Thread training itself as their data is collected. STTP is that same loop, between parties.

FATE and Mary are the two options I can name today. STTP is what would make choosing between them unnecessary: one gauge every machine agrees on, whatever the data is, so the pipe and the ledger ride the same track. MaryOS is where I'm testing what a device looks like when it's built with this thinking from its first boot, and it's the system whose design gave me the confidence to write STTP down.

A.I. was always going to be a supporting role. It's the part that answers, drafts and recognizes, the engine in the picture, and an engine isn't a market. The last time a network got laid, the railway itself wasn't what changed the economy. What changed it was what a common gauge and a common clock made possible: catalogs that shipped across a continent, commodity exchanges, meat that arrived cold, towns that existed because the line did. Few of those were on anyone's original map. Braid is built to the same shape: the commons is the shared base that nobody's writing trains, and the value sits in the Threads and the people behind them.

The real market is in connecting the dots, and in the markets that spawn once the dots can be connected and the connections can be trusted. A lane at every party, a receipt at every token and a protocol between them turn data from something that gets taken into something that gets joined, credited and paid for. Sewn already prices each document's share of an answer and keeps the earnings in a wallet, which is the smallest part of a market: a price, a payee and a record. What grows on top of that is the part I can't name yet, and that's the point. I'm laying track, not predicting the towns.

P.S.

FATE's details come from its README and the FATE-LLM repository on November 4, 2026, the Linux Foundation's announcement, and the first pages of the papers cited in the references above, and the repositories change often. Mary's details come from the AII, Braid and Veil repositories, the Mary repository (since made private) and the product pages on the same date, and MaryOS is described only as far as the Mary repository describes it. Everything under "What I'd do first" is a plan, not a feature, and so is STTP reaching past text to any kind of data: that's a direction, not a result.