Pre-launch · Technical demonstration

RynnBrain

A technical demonstration of governed, human-in-the-loop edge-AI perimeter patrol.

“Every autonomous security robot acts on its own. Ours holds and asks.”

Status: This page documents a concept and a working technical demonstration. It is not a product announcement. There are no deployments, no customers, and no field results behind anything shown here. The hardware described is the intended target platform, not a finished integrated system.

Governed patrol, not autonomous patrol

RynnBrain is a concept for continuous perimeter coverage at commercial sites, where the machine never takes an action on its own.

The coverage gap

Commercial sites have areas fixed cameras cannot reach — back lots, far fence lines, unwired outdoor storage, loading docks. Coverage is bounded by where cable runs. What cannot be wired is not watched, and what is not watched leaves no record.

The approach

Intelligence runs on a fixed edge-AI box on site. A low-cost robot dog patroller acts purely as an actuator, carrying a camera into the gap. Every event runs through the same loop, and the loop stops at a human before anything happens.

Why governed matters

An unsupervised machine making decisions on a property is an exposure, not a safeguard. Requiring human authorization before any response is the point of the design — it is what makes the resulting record meaningful, and what the value actually rests on.

01DetectThe robot dog patroller flags an event on its patrol
02Cross-verifyA second viewpoint confirms before escalating
03HoldThe system stops here and takes no action
04AuthorizeAn authorization notification goes to the operator's phone; a human approves or declines
05ExecuteThe robot dog carries out only the authorized response
06RecordA timestamped audit log entry is written for the event

Hold and ask

The system never acts autonomously. Detection escalates to a person; nothing executes without an explicit human decision.

🏠

Runs on site

Inference happens on the local edge box. No cloud dependency for the perception or decision path, and video need not leave the premises.

👤

Role-based authorization

Authorization reaches the operator wherever they are, as a notification on their phone. Who approved, in what role, and when are treated as part of the event itself — not as logging bolted on afterwards.

📋

The audit log is the output

Every event produces a timestamped audit log entry recording what was detected, how it was verified, and who authorized the response — a first-class artifact, not a by-product.

The governance loop, running

A single event, end to end — from the patrol noticing something to the audit log entry being written.

The scenario: after hours at a distribution yard. The robot dog patroller is walking its route along the back-lot fence — an area no fixed camera covers — when it sees something. Watch the loop below run once through, end to end.

  1. 01 Detect The patroller flags motion at the fence line
  2. 02 Cross-verify A fixed yard camera confirms it from a second angle
  3. 03 Hold Nothing happens next without a person
  4. 04 Authorize A notification reaches the operator's phone; they approve or decline
  5. 05 Execute Only now does the robot dog move, and only as authorized
  6. 06 Record A timestamped audit log entry is written for the whole chain
Local WebRTC
Built-in Camera
Operator verified
🔊 Robot dog: motion at back-lot fence
🔊 ⚠️Cross-verified — auth sent to phone
📱 Authorized on phone — proceed
Robot dog sent to fence
On station, streaming live
Authorization logged
🔊 Gate secured. Audit log written.
RynnBrain
Operator Console
RynnBrain
Authorization required Back-lot fence · gate open
Decline Approve
✓ Approved 22:41:07
Operator's phone
Audit log entry saved
2026-08-03 22:41:07
Detected → cross-verified → held
Authorized by operator, on phone
Response executed · area secured
Timestamped record
AI agent with generated avatar
Request to VLM
Response from VLM
Perimeter Camera
Edge-AI Box
Robot Dog
Illustrative perimeter scenario — detect → cross-verify → hold → human authorization → execute → timestamped record. Scenario content is representative, not a recording of a deployed system.

Step 06 produces an artifact. This is an example of the authorization record the loop above generates — the chain of causation behind a single held event.

Example authorization record

Unexpected person detected · perimeter zone B

Held — awaiting operator authorization
Loop sequence Segment widths show relative duration only — illustrative, not measured
Detect
Model reasoning
Cross-verify
Classify
Gate
Authorization request
Fast path Reasoning & verification Governance — the loop pauses here
Perceived
Person in restricted zone B, robot-dog camera, confirmed over consecutive frames
Verified
Robot-dog camera and fixed perimeter camera agree — ground truth confirmed
Classified
Unexpected person, not on the pre-registered list, perimeter breach
Governance
Explicit operator authorization required before any action
Action
Held — no autonomous response; authorization requested
Authorized by
[role] [timestamp] Filled on approval — a decline is recorded here just as an approval is

Intended target platform

These are the two components the demonstration is being built toward. They are a target platform for the concept — not a finished, integrated product, and not a system available to buy.

Edge-AI box
Fixed · The intelligence

Edge-AI box

An edge-AI box that enables real-time vision-language model execution on-site. It carries the perception and governance stack: on-device inference, camera ingestion, and the authorization workflow. This is where the reasoning happens and where the audit log entry is produced.

12-DOF robot dog patroller
Mobile · The actuator

12-DOF robot dog patroller

A deliberately low-cost commodity actuator. Its job is to patrol, to carry a camera into the places fixed cameras cannot reach, and to execute an authorized response. It holds no decision authority of its own — the intelligence stays on the fixed box.

What the demonstration runs on

The stack behind the demo above: on-device vision-language inference paired with a real-time operator surface, communicating over a local WebRTC link.

Edge-AI box

The on-site compute for perception and reasoning — running locally, with no cloud service in the decision path.

🧠
On-device inference

NPU-accelerated vision-language inference, exposed over a standard chat-completions REST API. Open-weight vision-language models run locally without an internet connection.

📹
Multi-camera ingestion

Several camera streams processed together — fixed perimeter cameras alongside the camera carried by the robot dog patroller. This is what makes cross-verification from a second viewpoint possible.

📡
Local WebRTC

Real-time video, audio, and data channels between the operator console, cameras, and robot dog patroller. Sub-second latency, carried on the local network.

🤖
Agent orchestration

Multi-agent workflows built on an agent framework, with the authorization step modelled as an explicit gate that the workflow cannot proceed past on its own.

🔧
MCP tool integration

Capabilities extended through Model Context Protocol tools, so site systems and data stores can be connected without changes to the core reasoning loop.

🎯
Domain fine-tuning

Open-source vision-language models can be fine-tuned on domain-specific data, so detection and description reflect what actually matters at a given kind of site.

🐳
Containerized deployment

Components ship as containers behind a gateway service, which keeps the demonstration environment reproducible.

🛡️
Model guardrails

Constraints on model output, kept separate from the authorization gate — guardrails shape what the system says, human authorization governs what it does.

Edge-AI box
Operator console display

Operator console

The human side of the loop — where an event is presented, held, and either authorized or declined. A thin client: responsive enough for real-time interaction, with no heavy processing of its own.

The authorization surface

Where hold-and-ask becomes visible. An escalated event is presented here and pushed to the operator's phone as an authorization notification, then waits — declining is as much a recorded outcome as approving.

👤
On-device operator verification

Face recognition running on the console itself establishes who is at the panel, so an authorization can be attributed to a person and a role. Processed on the device.

⏱️
RTOS foundation

A real-time operating system gives consistent, predictable response times — useful when the interface is the thing standing between a detection and an action.

🎥
Video capabilities

Hardware video encoding for WebRTC streaming, so camera feeds and the robot dog's view can be reviewed live before a decision is made.

Dual RISC-V MCU

Dual-core RISC-V running at up to 400 MHz, built for HMI workloads with rich I/O rather than general-purpose compute.

🔌
Expansion I/O

Available I/O for additional sensing — 60/77 GHz radar for 3D person sensing, additional cameras, or bus protocols such as RS-485.

System architecture: operator console and edge-AI box exchanging audio, video and text

Demonstration architecture — the operator console and the edge-AI box exchange audio, video and text over the local link, with the robot dog patroller as the mobile camera and actuator on that link.

Where this concept could apply

Site types with large outdoor footprints and coverage gaps fixed cameras cannot close. These are candidate environments for the concept — none of them are deployments.

🚚

Distribution & logistics yards

Large outdoor footprints with trailer parking, gates, and fence lines well beyond the reach of wired camera coverage.

🔐

Self-storage sites

Long drive aisles and outdoor unit rows where continuous coverage is difficult and after-hours activity typically goes unwitnessed.

🏗️

Equipment rental lots

High-value assets parked outdoors across an open lot, with perimeters longer than the camera runs that serve them.

🚗

Vehicle lots

Open lots where inventory sits outside overnight and the back rows are the least observed part of the site.

📦

Warehousing

Loading docks, side yards, and outdoor storage — the areas around a building rather than inside it.

Frequently asked questions

Common questions about the concept and the demonstration.

No. RynnBrain is pre-launch. What this page shows is a concept and a technical demonstration of the underlying loop. There is no shipping product, no deployment, no pilot programme, and no results to report. Anything on this page describing site types or hardware describes intent, not something already delivered.

No — that is the whole point of the design. The robot dog patroller is an actuator. It patrols, carries a camera, and executes a response that a person has already authorized. Detection and reasoning happen on the fixed edge-AI box, and the loop deliberately stops and waits while an authorization notification goes to the operator's phone.

The distinction matters because an unsupervised machine taking action on a commercial property creates exposure rather than removing it.

Before an event is escalated to a person, the system seeks confirmation from a second viewpoint — for example a fixed perimeter camera confirming what the robot dog's camera reported, or the reverse. The intent is to reduce the number of times an authorization notification lands on someone's phone for something that isn't real, so that an escalation carries weight.

The perception and decision path is designed to run on-premises. Inference happens on the local edge box, and the console, cameras, and box communicate over the local network — so video need not leave the site for the loop to function.

Connectivity would be optional and relevant to things like remote access or software updates, not to detection or authorization.

Three reasons. Continuous video against a cloud API means continuous per-query cost, which scales badly for something meant to watch a perimeter all night. Round-trip latency sits in a loop that may need to respond quickly. And continuous outdoor video from a commercial site is exactly the kind of data an operator has good reason to keep on their own premises.

Running the model on the edge box addresses all three at once.

They are optimized for different jobs. The console handles display, touch, camera, audio, and real-time interaction on an RTOS, where predictable sub-millisecond response matters. The edge box handles compute-intensive work — running vision-language models, reasoning over multiple camera streams — on ARM64 Linux with NPU acceleration.

Keeping heavy compute off the interface is what lets the interface stay responsive.

Yes, in principle. Open-source vision-language models can be fine-tuned on domain-specific data, and retrieval over site-specific context can shape how events are described. A vehicle lot and a self-storage site care about different things, and the descriptions attached to a record should reflect that.

Questions about the concept

If you work with commercial sites, build in this space, or just want to understand the approach, get in touch.

Pre-launch — this is a concept and a demonstration
Technical questions welcome

Your information is kept private and never shared.