When a company should borrow from KyberFusion, and when not

Picture a translation agency with thirty people. Its KYBERIOS server in the back office handles the ordinary week without trouble: incoming jobs, terminology checks, invoices, the agents that sort and route the work. Once a quarter a large client sends a batch of technical manuals that has to be translated, checked for consistency against years of earlier work and delivered within days. On the office server, that job would take most of a week.

Two answers come up. Buy a server big enough for the quarterly peak, which will then sit mostly idle for the other eleven weeks. Or send the whole batch, with the translation memory and the client’s earlier documents, to a rented cloud that has the capacity, on terms nobody in the agency has read closely.

The agency is hypothetical, and KyberFusion is pre-launch: there is no network to borrow from yet. This is how we intend to help companies decide once there is.

The real cause: capacity decided once, for everything

Both answers make the same mistake. They treat capacity as one decision for all of the company’s work and all of its data, made once, usually when buying hardware. The real question is smaller and has to be asked per job: what does this job need, what does it touch, and when does it have to finish?

Where capacity decisions go wrong

Buying for the peak. A server sized for the busiest week is the wrong size for every other week, and it still has to be patched, powered and eventually replaced.

Sending everything because some of it needs to go. The batch needed more compute; the payroll, the client list and the contracts did not. They go anyway, because the decision was “move to the cloud”, not “move this job”.

One rule for all data. A newsletter list and a client’s unreleased product manual are treated the same, because nobody classified them.

Forgetting what leaks besides the content. Even encrypted work reveals something: who sent it, when, how much and how often. What a cloud node knows about you goes through the metadata.

Borrowing without a ceiling. An agent that can rent compute without a spending limit will eventually find a reason to.

Lock-in by convenience. Once the work and its history live somewhere else, leaving costs whatever the landlord decides.

A rule for borrowing

Classify the data first. Three classes are usually enough: never leaves the company’s ground, may leave with approval, may leave by default. Payroll is usually “never”. A product catalogue is usually “by default”. The client’s manuals are a question for the client’s contract.

Classify the job. Does it need an answer now, or by Friday? Work that can wait can be placed where and when capacity is free; interactive work should stay close. Where a swarm should run has the reasoning per task.

Size the server for the ordinary week. The office server should handle normal work with headroom, and nothing more. The peaks are what borrowing is for.

Write a ceiling. How much compute a job may borrow in a period, and who approves anything above it. The ceiling sits in the same policy as every other rule the agents work under, as writing a company’s rules for its agents describes.

The same system on both ends. A borrowed job runs on a KyberFusion node with the same KyberLinux and in its own KyberCell, so the rules written for the office server travel with it. KyberLinux as a KyberFusion node explains how. The network is designed to keep the job unlinked from the company that sent it; that is a goal it is being built for, not a claim about today.

Settled in tokens, and this is not an offer. Compute borrowed from KyberFusion is meant to be settled in tokens, a unit of settlement for compute between members, not an investment. Tokens are planned, and we are analysing them under EU law. They promise no return or price, nothing is for sale, and this is not an offer. Who pays for the cloud sets out how the network is meant to pay its way.

When not to borrow at all. When the job touches data marked “never”. When the deadline is not real and the office server can finish over a weekend. When the same peak comes every week, which means the server is the wrong size, not that the network is needed.

Deciding these rules with a company, and writing them where the agents enforce them, is part of what we intend to do in a deployment. Nothing is on offer yet; the KYBERTIS homepage keeps the honest state of the work.

A test you can run today

List the three heaviest jobs your company runs in a year: the month-end close, the annual report, the big tender, the quarterly batch. For each one, write down:

1. Which data does it touch?
2. Does it have to finish today, this week or this month?
3. What would it cost the company if the data in it leaked?

A job that touches nothing sensitive and can wait is a candidate for borrowing. A job that touches payroll belongs on your own ground, however long it takes. Everything in between needs a rule, and now you have the start of one.