What a Kyber deployment looks like, step by step

Picture a wholesaler of plumbing parts with twenty-five people, a counter, a warehouse and three vans. Invoices live in one program, the customer list in another, and stock in a spreadsheet the warehouse manager guards. The owner has read about an operating system for a small business and wants one. A contractor offers to do the whole thing over a long weekend: install everything on Friday, move the data on Saturday, switch the old programs off on Monday.

Monday goes the way these Mondays go. The stock figures disagree with the shelves, because nobody reconciled the spreadsheet first. Agents that were given write access on day one have drafted confirmations for orders that cannot ship. The configuration lives on the contractor’s laptop, and by Wednesday the contractor is on the next job. Nothing about the software was wrong. The deployment was.

The company is hypothetical. KYBERTIS has no clients yet and KYBERIOS itself is pre-launch; what follows is how we intend to run a deployment, written down so that it can be held to.

The real cause: an installation treated as an event

A deployment is usually planned as a single event: a weekend, a cut-over, a go-live. In reality it is a sequence of decisions, and most of them should stay reversible for a while after they are made. Squeeze them all into one event and every decision becomes irreversible at once, while ownership of the result is handed over at the very end, which is exactly when the people who know the most are leaving.

Where deployments go wrong

The big bang. The old programs are switched off on the day the new system starts. There is no period in which both run and disagree in a way someone can learn from.

Write access on day one. Agents are allowed to change records before anyone has watched them be right about those records. The first mistakes are made in production, in front of customers.

Configuration that lives with the installer. The settings, the scripts and the reasons behind them stay on someone else’s machine. The open licence is real; the ability to run the system without that person is not.

No definition of done. Nobody wrote down what the deployment was for, so nobody can say whether it worked. The project ends when the budget does.

The exit discovered at the end. What happens if you want to run it yourself, or move to someone else, gets negotiated after the relationship has soured, when you have no leverage left.

Seven steps, each one reversible

This is the shape we intend every Kyber deployment to take. Each step has an owner and a written result, and each one can be undone without undoing the ones before it.

1. The first call. What you run, what it costs you and what hurts. Sometimes the honest answer is that the Kyber stack is not right for you yet, and the call should be allowed to end there.

2. The audit. Every program, every data set, who uses what and who decides what, written down together with the arguments against changing anything. The report is yours whether or not you go ahead, because an audit that exists only to sell the next step is not an audit.

3. The server. KYBERIOS goes onto a server the company owns, on KyberLinux: immutable, verified at boot, updated atomically, with the company’s own keys enrolled. Often that is hardware already in the building, and KyberLinux on hardware you already own covers what that takes. Hardening belongs to this step, not to a later one; hardening is a service, not a checkbox explains why it never really ends.

4. Reading beside the old stack. KYBERIOS starts next to the programs you already run, reading, not writing. For a few weeks the two disagree, and every disagreement is information: a stock figure that was wrong in the spreadsheet, a customer recorded twice, a price nobody updated.

5. Rules before permissions. Before any agent writes anything, the company’s rules for its agents are written down with the people who hold them today: what may be suggested, what may be done up to which limit, and what waits for a person. Then write access is granted one process at a time, as processes run as swarms describes, with each agent in its own KyberCell. The detail is in writing a company’s rules for its agents.

6. Devices and identities. KyberDeck forms for the people who need them, one identity per person, spares on the shelf and a written answer to what happens when someone leaves. Rolling out KyberDeck to a team goes through it.

7. Handover, with the exit in force. The configuration has lived in the company’s repository since step 3, so handover is not a file transfer. It is the point at which your people run the routine and we are on call rather than in the room. Support continues under the SLA, and the exit clause, agreed before step 1 was finished, stays in force the whole time.

Notice what is missing: a go-live weekend. The old programs are switched off one at a time, each only after the new system has been right about that process for long enough to show it.

None of this is available yet. The KYBERTIS homepage follows one engagement end to end and keeps the honest state of the work.

A test you can run today

Pick the system your business could least afford to lose: the invoicing program, the stock records, the server in the cupboard. Answer three questions in writing.

1. If it died tonight, who could rebuild it, and from what written material?
2. Where does its configuration live, and who can read it without asking someone first?
3. If you wanted to move to a different supplier next month, what would you need from the current one, and does your contract say you get it?

If the answers are “one person, from memory”, “on their laptop” and “we would have to ask”, the last deployment never finished. It just stopped.