Telemetry, layouts, and shipment data stay on-site. Software agents and robots run on one in-perimeter stack, under one record.
Warehouses, ports, and distribution networks run software planners that command physical robots — and the operational telemetry, layouts, and customer shipment data they generate are competitive and contractual data that stays inside the facility, not on a vendor's cloud. The stitched alternative — software agents on a cloud platform, robots on vendor middleware with its own identity and logging — has no single answer to who did what across the boundary, and no one team keeping it all patched. Visca runs software and embodied actors on one stack — one identity model, one credential model, one runtime, one record — inside the facility, with its own operators maintaining it.
Why the data can't leave
Software agents run on one stack; robots run on robotics middleware with its own identity, logging, and deployment. There's no shared answer to who did what across the boundary.
A robot is a serial number plus whatever firmware-signing the vendor ships. A receiving system can't cryptographically verify that a command came from a specific physical machine in a specific configuration.
Geofences, force limits, and allowed-operation constraints are coded differently for every robot vendor — inconsistent, hard to audit, easy to drift.
One stack, not a stitched one
Each robot carries an attested identity bound at boot. A receiving system can verify which physical machine, in which configuration, issued a command — and which planner authorized it.
A move command executes on a scoped, time-bound credential — this robot, this operation, this window — not a standing connection from the planner to the fleet.
Software planners and embodied actors run on the same runtime, with behavioral safety envelopes — geofences, force limits, allowed operations — enforced uniformly across robot vendors.
Every planner decision, every actuation, every operator intervention lands in one chained record — replayable as a single timeline across software and hardware.
The stack's own operators deploy, upgrade, patch, rotate credentials, and answer incidents inside the facility — under the same identity and audit as the fleet they maintain.
What you get
Relevant frameworks
Visca Cloud has not yet completed formal certification against these frameworks; the stack is architected to meet them and audits are in progress. See the compliance roadmap.
In practice
A pallet is mis-routed. The investigation is a single query: the planner's decision, the credential that authorized the move command, the specific robot's attested identity, the actuation telemetry, and the operator override — one timeline, replayable. And when the fix is a patched planner, the patch ships through the resident operators and lands on the same record the investigation cites.
Account data, balances, and PII can't leave the bank. The stack that handles them runs inside it — and answers the examiner.
PHI can't be shipped to a model API. The scribe, the model, and the record all run in your tenancy — on a stack that maintains itself.
Classified and sensitive data never leaves the boundary. The whole stack runs inside it — air-gapped, and able to maintain itself there.
Pricing, sourcing, and customer data stay inside each company's walls — while their agents still work across the boundary.
Process recipes and plant telemetry stay on the floor — on one in-perimeter stack, not a console per vendor.
The Autonomy Stack for regulated industries
Identity, credentials, runtime, and audit — shipped as part of your product, run inside your customer's walls, operated by agents under the same ledger as everything else. Nothing leaves the perimeter. Nothing is off the record.