The cloud is a peer, not a parent: what actually crosses the site boundary

The question comes up in the first hour of every architecture session, usually in the same words: what leaves my site?

It is the right question, and the honest answer is longer than a yes or no. Kybernao is a local-first platform that can federate. That sentence is easy to write on a slide and hard to hold to, because the moment any decision depends on a service you do not run, the site has quietly acquired a dependency. This is how we keep that from happening, and how you can check it rather than take our word for it.

Two shapes, one runtime

There are two deployment shapes and they run identical software. That matters more than it sounds: the disconnected configuration is not a stripped-down build, it is the same runtime with federation switched off.

Kybernao Site puts NODE-R in the rack and NODE-I on the DIN rail. The terrain graph, the detection models, Red, Sentinel, Guardian and the local data lake all live there. Cloud sync is available and off by default.

Kybernao Edge puts NODE-S in a backpack and NODE-X in a vehicle, and assumes denied, degraded, intermittent and limited connectivity as the normal case. Some of these deployments have never had a link to anything, and never will.

What crosses the boundary

When sync is enabled, nine classes of data can leave, and each one is an independent switch. Four categories of data have no switch, because we do not build a path for them.

The distinction that matters is between a claim and its evidence. A finding digest says that a route exists, names the assets by their site-local identifiers, and carries a hash of the evidence package. The package itself, which contains the captures, the twin replay set and the retest log, stays on the node. If a fleet analyst wants it, they request it, the request lands in the site's own queue, and an operator approves the transfer. The default answer is that it stays.

The egress contract is a file, not a promise

The egress contract belongs in a file on the node, signed and readable by anyone who can open a terminal at the site, rather than in a setting buried in a vendor console. In outline it looks like this.

peer kybernao-cloud
  transport   tls1.3 mutual, pinned
  budget      16 kbps ceiling, 40 MB/day
  window      always | 02:00-04:00 | manual

  allow  finding.digest           on
  allow  containment.taken        on
  allow  retest.result            on
  allow  telemetry.rollup         on   aggregate only, 5 min buckets
  allow  intel.pull               on
  allow  model.pull               on
  allow  asset.inventory          off
  allow  graph.topology           off
  allow  evidence.package         off  per-request, operator approval

  deny   capture.raw
  deny   controller.project
  deny   tag.values
  deny   secrets.any

  ledger /var/kybernao/egress.log  signed, append only

Three things about that file are load bearing. The deny lines are not toggles, they are compiled into the federation service and there is no console switch that flips them. The budget is enforced at the node, so a chatty cloud cannot pull more than the site agreed to give. And the ledger records every object that left, with its class, size and hash, which means the question "what did you send last Tuesday" has an exact answer rather than a reassuring one.

Why the cloud is a peer

FedSpace, the layer that moves state between nodes, does not distinguish between a peer node at another site and Kybernao Cloud. Both are peers. Both receive signed claims with provenance attached. Neither receives authority.

That design decision has a practical consequence that shows up during a partition. When two nodes disagree about state, there is no merge that silently picks a winner. The receiving side sees that one node believed one thing at a given moment and another believed something else, and a human adjudicates. The cloud does not get to be right by virtue of being central, because in this model it is not central.

A federation that can overrule a site is a control plane wearing a federation costume. The test is simple: can the cloud make the node do something the node did not already agree to?

For Kybernao the answer is no. The node accepts model updates and intel that it verifies and applies under its own policy, and it accepts requests, which an operator answers. It does not accept commands.

What the cloud is actually worth

None of this is an argument against the cloud. It is an argument about where the decisions live. Once that is settled, a cloud peer earns its place at four jobs a single site genuinely cannot do for itself.

• Fleet view. Thirty substations each hold their own truth. Seeing that the same seven-hop shape exists at nine of them is a question only a peer with all nine digests can answer.
• Cross-site correlation. A technique observed at one site becomes a detection shipped to the rest, usually within a day, without either site exposing its topology to the other.
• Model and intel distribution. Detection models are large and improve often. Pulling them over a governed channel beats shipping a technician with a drive, when a channel exists.
• Long-horizon retention. A node holds months. Regulators and incident reviews sometimes want years, and the digest plus hash chain gives you a durable record without moving the evidence.

Notice that all four are reporting and improvement. None of them is detection, authorization, containment or triage, which is exactly the point.

When the cloud is gone, or wrong

This is the drill to run before handover, because a capability nobody has exercised is a claim rather than a capability.

A harder case is a cloud that is reachable and wrong, whether through compromise or plain error. The node's defences there are the same ones it uses on any peer. Model and intel objects are signature verified against keys the site holds, and an object that fails verification is rejected and logged rather than quarantined for later. Nothing arriving over federation can change the node's policy, its authorization rules or its containment posture. And a site can revoke the peer outright, which takes one command and no coordination with us.

Six questions for any cloud-optional claim

These are the questions we would ask about our own platform, and they are worth asking about anything else you are evaluating alongside it.

1. With the link cut, which decisions still happen on site, and which ones simply stop? Ask for the list, then pull the cable and check it.
2. Is the offline build the same software, or a reduced mode? A different mode means a different set of bugs, exercised less often.
3. Can you enumerate what left the site yesterday, by object and class, from a record the site itself holds?
4. Which egress categories have no switch at all, and is that enforced in code or in documentation?
5. Can the cloud instruct the site, in any circumstance? If yes, it is a control plane, and it should be threat modelled as one.
6. How does the system behave when the cloud returns after a long gap, and has anyone watched it do that under a real bandwidth ceiling?

Local-first is not a posture we adopted for marketing reasons. It came from sites where the link is genuinely unreliable and the consequence of a paused decision is physical. It turns out that the architecture those sites require is also the one that gives an ordinary enterprise a straight answer to the first question anyone asks.