The next machine won’t start from zero.

Every charge and discharge a battery goes through in the heat leaves a clue about how long it will last. The faint vibration a pump shows before it fails could tell another pump to shut down in time. The way a microgrid rations power through a week of rain is a lesson for the next community trying to keep the lights on.

That experience is created every day. And every day it stays locked inside devices, gateways and company systems.

Large language models have read what people wrote. The next generation must understand what machines live through.

Public text is finite. The physical experience machines record is private, and it grows every day. Whoever lets that experience take part in learning, without it ever leaving its owner’s control, opens the next frontier of AI.

We call this direction the IoT Frontier Model: frontier models trained on the experience of real devices, getting better at real industry tasks, and the trusted network that makes them possible.

TLAY is building the foundation of that network. TLAY Confidential Compute connects trusted data at the device with industry model training in the cloud. Machines that deliver energy, transport and production can also contribute approved data to the next generation of industry intelligence, and share in the value it creates.

Three locks: why machine experience has not become shared intelligence

A newly installed device starts with its own short history, the maker’s spec sheet and whatever model it shipped with. Meanwhile, machines like it may have run for years in other climates, loads and maintenance regimes, and already met every problem it is about to face. The experience exists. It just cannot get here. Three locks stand in the way.

Lock one: too sensitive to share. Operating records reveal a plant’s output, customer habits, asset health and commercial terms. A single meter reading can show when a home is empty. Even a company willing to train jointly must know who will use its data, for which task, and whether it can leak back out through the final model. “We anonymize it” is a promise no one can check.

Lock two: too messy to read. A field called “temperature” may come from sensors in different places with different precision. A stop may mean a fault, maintenance or a normal schedule. Without device identity, time order and operating context, more data just means more noise.

Lock three: not worth the cost. Contributing good data means paying for connectivity, upkeep, labeling and consent management. If the value all stays with whoever builds the model, device owners have no reason to stay in.

The IoT Frontier Model has to open all three: confidential computing and differential privacy make data safe to bring in, trusted provenance from the device makes it readable, and rewards tied to contribution keep the collaboration going.

Why now

Three things fell into place in 2026, and together they turn this from an idea into engineering.

One: federated learning with externally verifiable privacy now runs in production. In October 2026 Google Research published Toward provably private learning from federated data. Devices upload encrypted data, and only publicly logged, remotely attested programs may decrypt and train on it inside trusted execution environments (TEEs). The system already trains Gboard’s English and Japanese models. Its results show that stronger privacy and faster training can come together:

Source: Daly et al., arXiv:2609.31494. The A/B test ran about 3.5M devices per arm, with user metrics neutral.

Two: confidential computing is a cloud commodity. AMD SEV-SNP and Intel TDX machines can be rented on demand, and the hardware signs an attestation of exactly which program is running inside. You no longer need your own data center to get a compute environment where even the operator cannot see the data.

Three: machines already have identity, signatures and wallets. TLAY’s BoAT brings identity, signing, authorization and payment to the device, and HashAnchor gives machine events a verifiable integrity record. Where data comes from, which consent lets it into training and how contributors get paid now all have endpoints to connect.

The paper proved the architecture, the cloud supplies the hardware, and the trust base on the device already exists. What is missing is someone to connect them into one service.

What an industry frontier model will learn

An IoT Frontier Model is an industry foundation model. It learns what many devices in many operating conditions have in common, then carries that experience to new devices and new tasks. It answers one core question: what changed in a physical system, under which conditions, and can that experience help another machine make a better call?

It first learns how device state evolves from broad operating sequences, then adapts to specific tasks. Inputs can include time series, device events, maintenance records, images and, where needed, text. The task and the data decide the architecture.

“Frontier” is earned by capability, not parameter count. We hold it to three tests: does it still predict reliably on devices, sites and conditions it has never seen; does it adapt faster when labels are scarce; and does it know when it is outside what it was trained on?

Batteries, energy systems and industrial equipment will each grow their own industry models, sharing some representations and tools, then deepening on their own data. The large model serves from the cloud; specific skills are distilled and adapted down to the edge. A small device can contribute without ever running a large model itself.

One company’s learning boundary becomes the whole industry’s. A small operator no longer has to collect every failure on its own. A new device starts from the industry’s history and keeps adapting to its own site.

Learning moves to the server. Access never does.

Classic federated learning trains on each device and aggregates on a server, which also adds the privacy noise; participants have to trust that it did. Google Research’s new architecture splits the work differently: learning moves to the server, but the server never sees the data. The path has five steps:

1. Devices upload encrypted data. Before uploading, a device checks that two things are recorded in a public transparency log (Rekor): the key management service’s software, and the access policy for this data. Then it encrypts the data and binds it to that policy.
2. The access policy is public. It names which programs, in which runtime environments, may process the data, and under which privacy limits. Outside auditors can see every server workload that could ever run.
3. Keys go only to programs that match the policy. The key management service itself runs on a cluster of TEEs, uses Raft consensus to keep rollback-protected state, and releases decryption keys only to workloads whose attested identity matches the policy.
4. Training runs in TEEs, with differential privacy. A root TEE runs the training program and hands parallel work to worker TEEs; they verify each other’s attestations and talk over encrypted channels. Programs are written in Federated Language, an open-source orchestration language. Differential privacy (MF-DP-FTRL) is applied to the outputs by the approved program itself; it does not come free with the TEE. Recovery checkpoints are signed and encrypted before they leave the TEE, so no one can re-release results by replaying a run.
5. Only an anonymized model is released. The only thing that leaves the TEE is noised model weights and metrics.

External verifiability ties the five steps into one chain anyone can check: the server code is open source with reproducible builds, the TEEs produce remote attestations, and the access policies sit in the transparency log. For the first time, the promise, the code and the environment actually running it can be matched up one to one.

Better privacy comes from better scheduling. Because data is encrypted and collected first, then scheduled into training by the server, the system can spread out each device’s participations. The same privacy target then needs less noise, and the model gets more accurate. That is where the drop from 7.38 to 5.16 in the table above comes from.

IoT is the most natural home for this architecture

The architecture was proven first on a phone keyboard. But the problem it solves is sharper in the Internet of Things.

Classic federated learning asks three things of a device: enough compute to train locally, staying online through round after round, and running the same training code as everyone else. Phones can just about manage. Most machines cannot: meters, gateways and sensors have little compute, connect intermittently, and come from countless makers and chips.

The new architecture removes all three requirements. A device only has to collect, sign and encrypt; once it has uploaded, it can go offline. Training happens in TEEs in the cloud, and the training code has nothing to do with device firmware. The bar for joining industry learning drops from “can train a model” to “can encrypt a record.”

That opens a new space: the smallest, cheapest and most numerous devices can take part in training frontier models just like large ones. The scale of machine data can finally become the scale of the model.

Trusted learning starts on the device

The cloud can protect the computation, but it cannot say on its own where the input came from. An industry model is worth relying on only if we know which device produced a record, how it was measuring, whether the events are in order, and whether the same record was submitted twice. Model, units, calibration and operating conditions must also be kept in a form a model can understand.

That is the value of an open device runtime: devices from different makers identify themselves, sign events, enforce consent and record provenance in one consistent way. An open implementation lets every participant inspect those rules, and lowers the bar for joining a shared learning network.

TLAY already has two foundation stones:

• BoAT brings identity, signing, authorization and payment to the machine, and will extend to encrypted upload and policy checks.
• HashAnchor gives machine events a verifiable integrity record, linking tasks, data commitments and result receipts.

Trust comes in tiers, and the tier is itself a training signal. Devices with secure boot, protected keys and remote attestation give stronger evidence about their runtime; constrained devices state their trust tier openly. Trainers use it to filter data, weight it, spot anomalies and trace problems to their source. A signature proves origin and integrity; whether the measurement is accurate still depends on sensor calibration, cross-checks and field management.

TLAY Confidential Compute: the first stretch already runs

TLAY Confidential Compute lets device owners, model developers and industry applications work together around one approved task. Developers submit the task, its input requirements and privacy limits; data owners decide whether to take part; the service runs the protected execution and delivers statistics or models that comply with the policy. Partners plug in, instead of each building a confidential computing stack of their own.

This is more than a blueprint. We have run the full path, from device upload to settlement, on Google Cloud Confidential Space (the pilot uses synthetic data and simulated payments):

• Keys are released only to programs whose hardware attestation and image digest match the policy, verified on both Intel TDX and AMD SEV.
• Every device has a privacy budget ledger: budget is reserved before anything is decrypted, never refunded on failure, and each day of data feeds one release only.
• A DP-SGD model was trained inside TDX on 1,000 devices × 8 days at ε = 2.0. On 5,000 held-out devices its mean absolute error was 111.43 minutes, against 118.06 for a 7-day-average baseline.
• Every release carries a signed receipt that can be verified offline; the transparency log is anchored in write-once storage.
• A daily job goes from schedule to settlement in about 70 seconds.

Measured against Google Research’s design, here is where we stand:

Google’s work gives us the architecture for confidential learning. Bringing in device identity, data provenance and machine settlement is the product TLAY adds for the Internet of Things. The user guide walks through the pilot role by role.

Sharing value with the machines that contribute

A learning network lasts only if contributors can see what they get from taking part.

Picture a developer of battery-health models who wants better predictions in hot regions. It publishes a learning task that states the purpose, the time limit and the data quality it needs. Qualifying device owners opt in, and their approved data enters protected training. When the task is done, contributors are paid as agreed, and the model is offered as a service to the operators who need it.

What changes hands is the right to use data for one specific task, plus the model service built on it, not an unlimited right to copy the data. Model ownership, scope of use and revenue rules are written down before anyone joins.

Pay for valid contributions, not for bytes, and never for what the data says. Paying by upload volume rewards duplicates and junk; paying by content leaks privacy. The TLAY pilot pays the same amount for every contribution that passes validation. Finer-grained valuation can grow from tasks for scarce scenarios and revenue sharing on model services.

Machine wallets and programmable settlement make this fine-grained collaboration enforceable: a device receives contribution income within the permissions its owner grants, and pays for forecasting, diagnostics and optimization services. Networks that span organizations can settle with composable options such as stablecoins.

The result is a flywheel: devices produce data as they work, approved data improves models, better models improve the devices, and service revenue flows back to contributors. What keeps it spinning is real utility: less downtime, longer asset life, better energy use.

Our commitments, and our limits

A big goal needs honest boundaries. These are our commitments to partners, and the things this approach cannot do today.

We commit to:

• Labeling every result by what was actually proven: synthetic data, simulated payments and hardware-attested compute are kept apart and never blurred.
• Stating, for every task, the unit of privacy protection (one sample, one device or one household) and the cumulative privacy budget; continued training and repeated releases all draw on the same ledger.
• Publishing which trust assumptions rest on hardware, on software and on each operating role.

This approach cannot:

• Make TEEs absolutely secure. Current-generation TEEs have known limitations, as Google’s paper also says; differential privacy is a second line of defense, not a side effect of the TEE.
• Make a released model forget. Withdrawing consent affects only later tasks.
• Turn a signature into an accurate measurement. It proves origin and integrity; sensor accuracy still depends on calibration and field management.
• Replace hardware attestation with an integrity record. HashAnchor proves a record was not altered, not that the training algorithm is correct.
• Skip the hard work of scale. The largest model the paper trained on this system has 10 million parameters; larger models need TEEs with accelerators such as GPUs. Aligning data semantics and distributions across companies is work model teams still have to do, one problem at a time.

Confidential computing creates the conditions for collaboration. Model capability can only be earned in independent field tests.

Roadmap: from one energy task to a network that learns together

Energy is where we start: its devices produce continuous, time-ordered data, and forecast quality can be tested on concrete tasks. The first stage is done; from here, every stage must pass its gate before we scale.

The next machine won’t start from zero

Picture an energy storage unit installed today. It has never lived through a full local rainy season, yet it already knows from the industry model how supply and demand shift through a week of rain. Every bit of experience it gathers from here on, within what its owner allows, helps the model serve more machines like it.

Every participant keeps its own business and consent boundaries, and gains learning capacity far beyond its own fleet. Operators that were once too small to train advanced models on their own can now help build, and use, industry frontier intelligence.

The IoT Frontier Model starts with one trusted record from one device. Its horizon is the experience of the world’s machines becoming a foundation the whole industry keeps learning from.

References

1. Google Research, Toward provably private learning from federated data, blog post, October 2, 2026.
2. Daly et al., Toward provably private learning from federated data, arXiv:2609.31494 v4, September 30, 2026; figures in this post come from its system design and evaluation sections.
3. TLAY, How TLAY Works; Product Status.
4. TLAY, Trust, Security and Privacy.
5. TLAY Confidential Compute pilot test report (September–October 2026, Google Cloud Confidential Space, synthetic data).