TLAY · IoT Frontier Model

What if machines could learn from each other’s experience?

Industry models need industry data, and that data sits with companies that have no reason to hand it over. The IoT Frontier Model gives them one: data that is used but never seen, improvements proven where the model has never been, and a stake in what it goes on to earn.

Read the thesis Join the network Watch the film 2:25

01 / USABLE, NOT VISIBLEData trains the model and stays home

02 / PROVEN, NOT PROMISEDTested where the model has never been

03 / A STAKE, NOT A FEEContributors share the long-term value

00The film

The whole idea, in two and a half minutes.

Why a lesson learned at one battery site stays there, and what it takes to move it: data that is used but never seen, improvements that are proven, and a stake instead of a fee.

01The second summer

A lesson learned at one site, stranded there.

A battery storage site, third week of a heatwave. The dispatch software recommends selling into the afternoon price peak. But the operations team has watched the battery for days: under sustained heat, it delivers less usable energy than the software expects. They hold some power back — and when demand peaks again that evening, the site still has its reserve.

A year later, in another city, an operator running the same type of battery faces a similar decision. The first team learned something worth knowing. The second has no practical way to benefit from it.

Day 18 of a heatwave · battery state of energy Illustrative scenario

Software expectation Following software under heat Operator holds reserve Electricity price

Site A · Year 1

Learned the hard way

Under sustained heat, usable capacity falls below what the software expects. Holding reserve protects the evening peak.

✕ no reason to share it

Site B · Year 2 · another city

Starts from zero

Same battery type. Similar weather. Same decision — with none of what Site A already knows.

Nothing technical kept that lesson at the first site. The first team had no reason to send it — and no safe way to.

Read the full thesis

A company can buy more computing power. It cannot buy a second copy of a summer that only one fleet has lived through.

— The TLAY IoT Frontier Model thesis →

02Why

Industry models need industry data. That data has every reason to stay home.

General-purpose models became capable because there was an internet of text to learn from. There is no internet of machine experience. A dispatch model improves by seeing what was recommended, what was actually done and what the meter recorded — across many sites, climates and generations of equipment.

No one holds enough.

One operator sees a few sites, one climate, one generation of cells. A manufacturer knows how cells age, not how they were dispatched. A model team knows how to learn, and has too little to learn from.

Seen once, sold for good.

Data that has been seen can be copied. Sell it once and the buyer need never come back — and you no longer decide who uses it. Your bidding strategy and your customers’ contract terms go with it.

III

A fee makes you a supplier.

Even where data can be supplied safely, a one-time fee is all it earns. The model goes on to serve customer after customer, and none of that reaches the enterprise whose experience made it useful.

So the model needs the data — and the data has no reason to move.

Illustrative

In the dispatch record further down this page, the battery delivers 2.71 MWh where its rating implied 3.00 — about a tenth short, in the hour when energy is worth most. A site that knows this holds reserve. A site that doesn’t finds out on the day.

What’s on offer today

Approach	Data stays unseen	Proof that it helped	A lasting stake
Sell the data	Data stays unseenNo	Proof that it helpedNo	A lasting stakeNo — paid once
Join a vendor’s platform	Data stays unseenNo	Proof that it helpedThe vendor decides	A lasting stakeNo
Federated learning	Data stays unseenRaw data stays local	Proof that it helpedNot addressed	A lasting stakeNot addressed
Node networks	Data stays unseenNot addressed	Proof that it helpedNo	A lasting stakeOnly for running hardware
IoT Frontier Model	Data stays unseenYes	Proof that it helpedYes	A lasting stakeYes

Breaking the deadlock takes three things, together:

01Data that is used, never seen.

02Improvements that are proven, not promised.

03A stake in long-term value, not a one-time fee.

03What

A model built and owned by industry, on TLAY’s open trust protocol.

Operators and manufacturers contribute authorized operating data. Model teams contribute specialist capabilities. Members run the nodes that train and serve it.

TLAY is a protocol, not a platform. It does not hold members’ data, own the models they build, or set the terms between them. It provides open rules for identity, permission, verification and settlement — so that three guarantees hold.

Usable, not visible

Your data trains the model. No one sees it.

Each dataset and each model is authorized for a defined task. Both take part in training, and neither party sees the other’s raw records or weights. Confidential computing is one route today; TLAY continues to explore further cryptographic techniques toward the same guarantee. What may leave the environment is agreed too.

Data stops being something sold once. It becomes an asset licensed again, task by task.

Protocolidentity · permission records · verifiable environment

Proven, not promised

An improvement counts only where the model has never been.

Trusted records join what a model recommended to what was done and what was measured. Whether a version is better is settled at a site held out of training — not by parameter count or node count. Members can check which data was authorized, how each version was evaluated and how revenue was divided.

That is what “frontier” means here.

Protocoltrusted records · evaluation attestations · on-chain checks

A stake, not a fee

Contributors share the long-term value, not a one-time payment.

A contributor earns a share in each model it helped build, issued only when a version passes the held-out test, and a stake in the network itself. Both are earned by contributing and funded only by real customer revenue. No single party can rewrite them after the work is done.

From supplier to co-owner.

Protocolmodel shares · network stake · settlement

01Usable, not visible — what is used, and what is never seen

Used — by authorization, for a defined task

Selected heatwave records, for one forecasting task
A model capability, licensed for that task
What the model learns about batteries in heat

Never seen — stays with its owner

Customer contracts and relationships
Tariffs and bidding strategies
Proprietary model weights
Underlying raw records

03A stake, not a fee — three kinds of return

What one contribution earns over time Illustrative

Service fee

Node operators

Paid for each verified request served. Settled on the day.

Model shares

Data & model contributors

Issued when a version passes the held-out test, weighted by the improvement it added. Shares follow the model: when a later version builds on an earlier one, earlier contributors keep earning from every customer payment.

Network stake

Every verified contributor

A fixed part of every settlement goes to a common pool. Members earn their stake in it by contributing, so the operator behind the first battery model also benefits as the protocol serves other machines and other industries. It carries a vote on the network’s rules.

Read the rules for shares and stake in the docs

◇How the pieces stack

Members agree access, release criteria and revenue rules in advance, and no single party can change them afterwards. Responsibility for model quality and customer delivery stays with named teams. TLAY earns under the same rules as every member: fees for the services it operates, and a stake in the network it develops.

◎Proven, not promised

Can experience from one set of machines improve a decision at a site the model has never seen?

Parameter count Node count Measured improvement where it must work

04The foundation

All three rest on a record you can trust.

A manual gives rated capacity. A sensor gives temperature. A model recommends when to discharge. A trusted record joins them — and keeps going: what the operator changed, what the controller actually executed, and what the meter actually measured.

Without that record there is nothing to authorize, nothing to test and nothing to settle.

Dispatch record · Site A · 14:00 Record the override

ManualRated capacity5.00 MWh

SensorCell temperature41.6 °C

Dispatch modelRecommendationDischarge 80% · 14:00

OperatorOverrideHold 20% reserve

ControllerExecutedDischarge 60% · 14:10

MeterMeasured outcome2.71 MWh delivered

The part of the story that comes after the decision

Trusted record Corrupted lesson

The model learns that under sustained heat, usable capacity sits below rating — and that holding reserve protected the evening peak. Its recommendation was corrected, and the record says so.

Without the override, the recommendation appears to have worked. The model credits itself for an outcome it did not produce — and repeats the mistake next summer.

Traceable

Every observation can be traced back to its source.

Distinguishable

A proposed action is never mistaken for an actual one.

III

Testable

Every prediction can be tested against a measured result.

05How

Start with one paid service. Then prove each guarantee.

The first project is in battery storage, and it does not wait for a frontier model. This is how it is meant to run.

STEP 01 · BASELINE

Put a useful service into operation.

A storage operator connects a site to the TLAY AI Platform — the first service on the protocol — and plans dispatch with an existing forecasting model and optimizer. The operator sets the objective and the reserve requirement; the local controller keeps safety authority. The customer gets value from day one, and every later model has a baseline to beat.

STEP 02 · USABLE, NOT VISIBLE

Agree what may be learned before anything is trained.

The parties record which data and which model may be used, for which task, what may leave the computing environment, and who may use the result. Protected records and proprietary weights enter an environment both sides can verify, and neither hands its asset to the other. Release is agreed too: a common component may be open; a sensitive capability is served through a controlled API.

STEP 03 · PROVEN, NOT PROMISED

Hold one site back, and test there.

Three candidates: the existing service, a model built by one operator, and a model built by several. One entire site is kept out of training. Dispatch cost is measured there under the same reserve and battery-wear limits. Only an improvement that survives is released — and only then do that version’s contributors receive their shares in the model.

More nodes extend where the service can run. They do not show that the model is better — independent evaluation does.

STEP 04 · A STAKE, NOT A FEE

Follow one customer payment.

A subscription or a paid dispatch request creates revenue that can be reconciled. The node operator is paid a fee for verified work. A fixed part goes to the network’s common pool. The rest is divided among the model’s shares. The operator whose rare heatwave records helped the first version pass still earns from this payment and every later one — even if it runs no node, and even after the next version is released. Members check permissions, versions and settlements on-chain, without publishing raw telemetry or weights.

06One record, three uses

Trust, intelligence and commerce belong in the same architecture.

The record that teaches the model is one TLAY already needs for two other jobs. One real machine activity answers three different questions — each with its own boundary and its own permission.

Machine payments

Was the service delivered — and what should be settled?

The delivery record shows what service should be settled.

Machine finance

How does this asset perform over time?

With separate permission, a history of performance and cash flows helps a financing partner assess the asset.

Machine intelligence

Where did the forecast miss?

With authorization for learning, the gap between forecast and outcome becomes evidence for the IoT Frontier Model.

07The first milestone

The machine economy begins with one useful service.

Demand

One customer pays for better dispatch.

Proof

A site the model has never seen shows the learning transfers.

Stake

Every contributor can verify what it earned.

That is the first turn of the wheel. The next enterprise has a reason to bring the case the model still gets wrong, the model improves, more customers pay — and those who contributed earlier go on sharing in it.

08Back to the second site

A lesson that travelled.

The operator in the other city receives a forecast informed by performance under sustained heat. Its team tests the forecast against local conditions and chooses how much energy to retain.

It has never seen the first operator’s customer list or trading strategy. Yet a lesson from that first site has travelled. If the second site pays for the improved service, the first can verify its share — and goes on earning as later versions build on what it taught.

The next machine can begin where another left off — and the people who made the lesson possible keep a stake in what it becomes worth.

→Join the network

Bring the case the model still gets wrong.

Each addition can make a specific capability better, and each improvement is tested in the world where it must work. Tell us where you’d fit.

Start a conversation