↳ rebe.life/developerfour sections deep — then back to the shared story

06 · Developer

Build on hardware your users own.

SDK, flow runtime, capabilities, and alpha primitives for products that can run in the browser, on a node, and inside a Realm — with the customer relationship and Corpus staying with the boundary that owns them.

four sections deep · then back to the shared story

Section 1 of 4 · What it does

Three units. Every tier.

A capability is a unit of behaviour — a chunk of code that does one useful thing. A flow stitches capabilities together into a directed acyclic operation. An agent loops capabilities and flows against a corpus until a goal is satisfied. These three units compose every reBe application.

They should run the same way on cyos-browser, cyos-node, a cyos-cluster / Realm, and eventually a cyos-fabric or cyos-mesh. You write once, the substrate can place the work where it belongs. The customer relationship — and the Corpus — stays with whoever owns the boundary the work runs inside.

Section 2 of 4 · How it works

Browser to fabric — one identity, one substrate.

The SDK is moving toward the same surface in the browser, on cyos-node, and inside a cyos-realm. A capability you ship on a webpage today should be able to graduate into a customer's home realm without a re-port. The NATS substrate is the common ground; subjects and JWT-scoped permissions are the same everywhere.

Identity is one signed Thing across tiers. A user opens a tab and their browser becomes a Thing; the same Thing later operates from a node binary; later still, from a realm GPU. The capability talks to "this Thing" — wherever it currently runs.

Section 3 of 4 · The proof layer

State, lineage, and verifiable execution.

A capability should not be another black box. The developer surface is being shaped so flows declare the Corpus they request, the grants they need, the models or tools they invoke, and the Chronicle entries they produce.

That gives builders a better primitive than prompt text: an inspectable execution trace. Studio and identity work already carry owner, invite, grant, and result boundaries; the SDK path should make the same provenance native to every serious capability.

Section 4 of 4 · How you ship

From first capability to alpha design partner.

Start with the browser path: open the SDK, write a capability, and shape the subject and permission model under your Thing's namespace. The alpha goal is that a capability can run close to the user while their Corpus and identity stay with them, and your code operates only under the permissions they grant.

The commercial programme is not ready to sell as a package. During alpha, the useful path is to explore real capabilities, document what the SDK must expose, prove the browser-to-Realm shape, and turn the best examples into Studio pieces others can learn from.

End of segment

Done reading. Where to next?

Return to the main line to talk to reBe with this segment in context.