How the IoT Frontier Model works.

Industry models need industry data, and that data sits with companies that have no reason to hand it over. The IoT Frontier Model is an industry model that those companies build and own together, on an open protocol that gives them a reason.

The first project is in battery storage: one paid dispatch service, one site held out of training, one customer payment followed to every contributor. The same arrangement is meant to extend to other machines and other industries.

Where to start

• Operators and manufacturersRead §04 for what happens to your data, then §06 for what you receive.
• Model teamsRead release rules and model shares.
• Node operatorsRead three kinds of return and the first project.
• Anyone evaluating the ideaRead §02, then go straight to open questions.

The model needs the data, and the data has no reason to move.

Industry models need industry data

General-purpose models became capable because there was an internet of text to learn from. There is no internet of machine experience. A model that dispatches a battery improves by seeing three things together: what was recommended, what the local controller actually did, and what the meter recorded. It needs them across many sites, climates and generations of equipment.

No single enterprise holds enough of that. One operator sees a few sites and one climate. A manufacturer knows how cells age, but not how they were dispatched. A model team knows how to learn, and has too little to learn from.

Why the data stays home

The enterprises that hold this data keep it to themselves, and they are right to.

• Seen once, sold for good. Data that has been seen can be copied. Sell it once and the buyer need never come back; the seller no longer decides who uses it.
• More goes with it than the lesson. An operating history carries a bidding strategy and the terms of customer contracts. Handing it over may teach competitors.
• The platform problem. Handing it to a platform may give that platform an unrestricted right to sell what it learns.

A model developer meets the same problem from the other side. It wants the operating history, and cannot release its proprietary weights to get it.

Why a fee is not enough

Suppose the data could be supplied safely. A contributor that receives only a fee for it is a supplier. It is paid once for the summer it lived through. The model that learned from it goes on to serve one customer after another and grows more valuable with every site that joins. None of that reaches the enterprise whose experience made the model useful.

What is on offer today

Each existing approach solves part of the problem. Federated learning keeps raw data local but says nothing about who owns the result or who is paid. Node networks pay for hardware, not for the lesson that made the model better. The deadlock breaks only when all three columns are answered together.

What the IoT Frontier Model is

The IoT Frontier Model is TLAY’s long-term direction for building models that learn from machine states, operating conditions, actions and outcomes across enterprises. It is not one large model released at once. It is a set of shared models, each built for a defined task by the members who contribute to it, and each owned by those members.

The first shared model forecasts how much energy a battery can actually deliver under sustained heat, so that dispatch can be planned around it.

What “frontier” means here

The test of progress is practical: can experience from one set of machines improve a decision at a site the model has never seen? A model’s frontier is the set of conditions where it is still wrong. It moves when a new contribution makes the model right somewhere it was not, and that is shown at a held-out site. Parameter count and node count do not show it.

Who takes part

One enterprise can hold more than one role. An operator that contributes records can also run a node and be a customer of the resulting service.

TLAY is a protocol, not a platform

TLAY does not hold members’ data, own the models they build, or set the terms between them. It provides open rules for four things.

The TLAY AI Platform is a product name. It is the first service that runs on the protocol, and it is operated by TLAY under the same rules that apply to every other member.

Life of a contribution

Every contribution follows the same path, and each step leaves a record that members can check.

Your data trains the model. No one sees it.

This is the guarantee that turns data from something sold once into an asset that can be licensed again, task by task.

Authorization is per task

Nothing is contributed in general. Before any training, the parties record five things.

1. Which data.A selected set of records, for example heatwave operating records from named sites.
2. Which model.The model a team licenses for this task.
3. For which task.For example, forecasting usable capacity under sustained heat.
4. Used by whom.Who may use the model that results.
5. What may leave.Which outputs may leave the computing environment, and which may not.

A second task needs a second authorization. That is what lets the same records earn more than once without ever being handed over.

The computing environment Open

Protected data and proprietary weights are brought into an environment that both sides can verify. Both take part in training. Neither party sees the other’s asset.

Confidential computing is one route to this today. TLAY continues to explore further cryptographic techniques toward the same guarantee. The guarantee is fixed; the technique that delivers it is not.

Release rules matter as much as the environment

A trained model can carry information about what it was trained on. So the rules for what leaves the environment are part of this guarantee, not an afterthought.

• A common component may be released openly.
• A commercially sensitive capability is delivered through a controlled API.
• Raw telemetry and proprietary weights do not leave.

What stays private, and what can be withdrawn

A contributor can withdraw an authorization. From then on its data is not used to train new versions. Shares it has already earned in versions that were built and are in service remain valid. Proposed

An improvement counts only where the model has never been.

The trusted record

A manual gives a battery’s rated capacity. A sensor gives its temperature. A dispatch model recommends when to discharge. A trusted record joins those and follows the story one step further: what the operator changed, what the controller executed, and what the meter measured.

A record is trusted when it has three properties.

• Traceable. Every observation can be traced to its source.
• Distinguishable. A proposed action is never mistaken for an actual one.
• Testable. Every prediction can be tested against a measured result.

Without such a record there is nothing to authorize, nothing to test and nothing to settle. All three guarantees rest on it.

The held-out site test

Whether a new version is better is settled the same way every time.

1. Hold a site back.One entire site is kept out of training.
2. Compare three candidates.The existing service, a model built by one operator alone, and the model built by several.
3. Use the same constraints.The same reserve requirement and the same battery-wear limits for all three.
4. Measure the outcome that matters.Dispatch cost at the held-out site.
5. Release only what survives.Only an improvement that holds at that site merits wider deployment.

Running more nodes extends where the service can operate. It does not show that the model is better. Independent evaluation does.

What members can check

On-chain records let each member check, without publishing raw telemetry or weights:

• which data and which model were authorized for a version;
• how that version was evaluated, and that it passed;
• which version served a given customer payment;
• how that payment was divided.

Because shares are issued on the result of the test, who runs it matters. See open questions.

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

The principle is settled: those whose experience makes a model useful should have a lasting say in its use and a stake in its success. The rules below are a proposed design for members to agree.

Three kinds of return

“A stake, not a fee” refers to the second and third.

Model shares: five rules

1. Issued only on proof.A version receives shares in proportion to how much it improved on the previous version at the held-out site. No improvement, no shares. A large volume of data that does not make the model better earns nothing; one rare case that corrects an error earns more.
2. Shares follow the lineage.When version 2 builds on version 1, version 1’s shares stay valid. Each version’s weight is the improvement it added. Early contributors are not wiped out. They are diluted only by new improvement that has itself been proven, by which time the model is worth more.
3. Within a version, the split is agreed in advance.How a version’s shares divide between data contributors and the model team, and among several data contributors, is agreed before training. With few members, a fixed ratio is enough. With more, the same test can be run with and without a contributor’s data to measure what it added.
4. Paid only from real revenue.Distributions come from customer payments. No payment, no distribution.
5. The data stays yours.Withdrawing an authorization stops future training on that data. It does not cancel shares earned in versions already in service.

Network stake

Model shares are tied to one model. Network stake lets a contributor share in the growth of the whole network.

• Where its value comes from. A fixed part of every settlement on the protocol goes into a common pool. This protocol fee is a published rule, not anyone’s discretion.
• How it is obtained. It is earned through verified contributions: data or a model that passes evaluation, node work that is verified, and development and operation of the protocol. It is not bought.
• What it carries. A pro-rata claim on the common pool, and a vote on protocol rules: the protocol fee rate, evaluation standards and member admission.

The operator that helped build the first battery model benefits when the protocol later serves vehicle fleets or factories, even though it contributed nothing to those models directly.

One payment, followed Illustrative

A customer pays 100 for dispatch service, served by model version 2. Version 1 improved on the baseline by 6 points at the held-out site. Version 2 added 2 more. The ratios are placeholders; members set the real ones.

Operator A contributed once, in the first year, and runs no node. It still receives 18 of every 100 that version 2 earns, and holds network stake besides.

When version 3 arrives. Suppose version 3 adds 2 more points. The weights become 6 : 2 : 2. Of the 60 that goes to model shares, version 1 now receives 36, version 2 receives 12 and version 3 receives 12. Operator A’s part of each payment falls from 18 to 14.4. It is diluted, by a proven improvement, in a model that now serves sites it could not serve before.

How TLAY earns

TLAY earns under the same rules as every other member.

• Service fees for the services it operates: the TLAY AI Platform, deployment, hosting and any nodes it runs.
• Network stake as the developer and operator of the protocol, in a proportion published in advance.

TLAY does not take a discretionary cut from what members are paid. Its return grows when the network grows. That is what “protocol, not platform” means commercially.

Form of the instrument Open

Model shares and network stake are recorded on-chain. Whether they can be transferred, and whether they take the form of a token, is not decided.

The proposal is to start the first project with one of the first two, and to decide on anything further once several models earn real revenue.

Rules are agreed before the work, and no single party can rewrite them after it.

Shared governance does not mean shared blame. A customer always has a named team answerable for the service it pays for.

Individual datasets, proprietary models and customer relationships stay under their owners’ control throughout. Governance covers what members build together, not what each brought.

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.

1. Step 01 · Baseline

   Put a useful service into operation.

   A storage operator connects a site to the TLAY AI Platform 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.

2. 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.

3. Step 03 · Proven, not promised

   Hold one site back, and test there.

   The existing service, a single-operator model and a multi-operator model are compared at a site kept out of training, 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.

4. 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. A fixed part goes to the network pool. The rest is divided among the model’s shares, and each member can verify its part on-chain.

The first milestone

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.

Numbers this project should produce

This document contains no measured results. The first project is meant to replace its illustrative figures with three real ones.

1. How much the shared model lowers dispatch cost at the held-out site, against the existing service.
2. How much better a multi-operator model is than a single-operator one. This is the evidence that collaboration earns its cost.
3. What a data contributor actually received from the first customer payment.

The record that teaches the model is one TLAY already needs for two other jobs.

Each use has its own boundary and needs its own permission. Authorizing a record for settlement does not authorize it for learning. This is why trust, intelligence and commerce belong in the same architecture: they draw on the same record, under separate permissions.

What is not settled, stated plainly.

1. Which technique delivers “usable, not visible”?

   Confidential computing is one route today. Other cryptographic techniques are being explored. The choice affects cost, performance and what each party has to trust.

2. How is contribution measured within a version?

   Measuring what one contributor’s data added means training with and without it. That is affordable with a few members and expensive with many. The proposal is to begin with agreed ratios and move to measurement later. When to switch, and to what method, is open.

3. Who runs the evaluation?

   Shares are issued on the result of the held-out test, so the party that runs it holds real power. The held-out sites and the evaluator need to be chosen by member governance and changed periodically. The exact arrangement is open.

4. What form do shares and stake take?

   Transferability and tokenization are undecided, and both depend on legal review. See form of the instrument.

5. What are the actual ratios?

   The split between service fee, protocol fee and model shares, the split within a version, and TLAY’s proportion of network stake are all for members to set. Every figure in this document is illustrative.

6. How far does lineage reach?

   Shares follow a model when a later version builds on an earlier one. If a later version is retrained without an earlier contributor’s data, whether and how that contributor’s shares continue needs a rule.

Baseline

The existing service a customer uses before any shared model. Every later version must beat it.

Held-out site

A site kept entirely out of training, used to test whether a version is better.

Lineage

The chain of versions a model is built from. Shares follow it.

Model shares

A contributor’s share in one shared model, issued when a version it contributed to passes the held-out test.

Model version

One released state of a shared model, tied to the authorizations it used and the evaluation it passed.

Network pool

The common pool that receives the protocol fee from every settlement.

Network stake

A contributor’s stake in the network as a whole: a pro-rata claim on the network pool and a vote on protocol rules.

Node

Member-operated capacity that trains or serves a model, close to customers or within an agreed boundary.

Protocol fee

A fixed, published part of every settlement that goes to the network pool.

Service fee

What a node operator is paid for a verified request it served.

Shared model

A model built for a defined task by several members and owned by them.

Trusted record

A record that joins recommendation, execution and measured outcome, and is traceable, distinguishable and testable.

Verifiable environment

A computing environment in which data and models are used without any party seeing another’s asset, and which the parties can verify.