NeuraFrame Studio Fleet

Curated round-trip sharing of reuse memory across a fleet of Studio devices and servers. One machine verifies an answer or takes a correction; you decide whether the fleet should learn it too.

Studio Fleet is the same round trip as Embodied Fleet, applied to reuse memory instead of robot behavior. A server or device resolves something once, verifies it, or takes a human correction. Instead of every machine in the fleet re-deriving the same work, you can collect that verified memory, approve it, and distribute it so the whole fleet benefits.

The round trip

1. Collect. Devices send only new, shareable verified memory since the last sync (deltas, not whole stores).
2. Curate. You review, clean, and approve what should spread across the fleet.
3. Distribute. Approved memory goes back, signed, and merges into each device.

Private stays home

Every memory has a scope. Device-private by default, so workload-specific or sensitive answers never leave the machine, or flagged shareable for verified work worth spreading. Only shareable memory is collected, and nothing is distributed without your review.

The merge law

• Non-destructive. If a device already has a verified answer for a request, a push does not overwrite it.
• Corrections override, with provenance. A push you approve as a correction changes future answers on purpose, and records who approved it and why.
• Safe by default. Reuse only ever serves verified memory or passes through to your model, so a bad or unlicensed push cannot make a device fabricate.

Ask the fleet

A device can ask the fleet whether a verified answer already exists before doing the work itself. If a peer resolved it, the device reuses it. If not, it does the work and can share the result back up.

You decide the sync

Set the cadence (real time, daily, weekly, monthly, manual, or off), the direction (collect only, distribute only, or both), the scope, and the budgets. Off is valid for an isolated or air-gapped device.

Security and provisioning

The Fleet server mints a fleet identity; every push is signed so a device only accepts memory from your fleet. On top of TLS, an optional passphrase vault keeps payloads ciphertext to everyone but you. The identity and passphrase are provisioned into your device fleet at deployment; rotating them requires re-provisioning, which is how you revoke.

Operating the fleet

On the Fleet server host, install the server package and run the installer as root. It mints your fleet identity, starts the service, and prints the identity to bake into your device package:

sudo bash install_fleet.sh          # install the server, start it, print your fleet identity
nf-fleet provision                  # reprint that identity at any time
nf-fleet status                     # queue, approved, and device counts

As devices report verified memory, curate it. The fleet only learns what you approve:

nf-fleet review                     # list learnings awaiting approval, with IDs
nf-fleet approve --all              # approve everything pending
nf-fleet approve 70e5 cfdd          # or approve specific learnings by ID
nf-fleet reject 9b21                # reject one you do not want to spread
nf-fleet policy set cadence daily   # set the fleet sync cadence

On each device the Studio package already contains the fleet client. Place your fleet's provisioning file (the JSON from nf-fleet provision) where the client reads it, and export NF_FLEET_PASSPHRASE if you set a vault passphrase. The client then collects shareable memory, asks the fleet before doing new work, and merges approved pushes on the cadence you set. Devices never run nf-fleet; that command is for the server only. Every command is in the CLI reference.

Get it

The fleet client ships in the Studio package, so devices can join a fleet. Run the Fleet server yourself: download the Fleet server. The same server also serves Embodied Fleet.