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.”

See the demo Read the concept
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.
The Concept

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
04AuthorizeA notification goes to the operator's phone, and to the optional on-site console; a human approves or declines from either
05Execute + confirmThe authorized deterrent is dispatched — the robot dog plays an audio message from its onboard speaker and reports back that the track played. It holds position; it does not approach
06RecordA timestamped authorization record captures the whole chain, including the execution confirmation
✋

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 authorization record is the output

Every event produces a timestamped authorization record capturing what was detected, how it was verified, who authorized the response, and confirmation that the authorized action completed. The record shows the action happened, not just that it was ordered.

Live Demo

The governance loop, running

A single event, end to end — from the patrol noticing something to the authorization record being written.

The scenario: after hours at a distribution yard. The robot dog patroller is walking its route through the back lot — a stretch of fence line and unwired storage that no fixed camera covers — when it detects a person the cameras never would have seen. Watch the loop run once, end to end.

  1. 01 Detect The patroller — the only set of eyes on this blind spot — flags a person at the back fence
  2. 02 Cross-verify The patroller confirms from a second angle as it repositions — no fixed camera can see this ground
  3. 03 Hold Nothing happens next without a person
  4. 04 Authorize A notification reaches the operator's phone — and the on-site console, where one is installed. Either can approve or decline
  5. 05 Execute + confirm Only on approval does the robot dog play an audio deterrent from its onboard speaker — asking the person to leave the premises — and confirms the track played. It does not approach
  6. 06 Record A timestamped authorization record is written for the whole chain
Local WebRTC · on-site network
Perimeter Camera Fixed viewpoint · perception in
Robot Dog Mobile viewpoint · perception in, actuation out-of-band
Video in in-band · local WebRTC
Actuation (out-of-band) separate control path
Built-in Camera
AI agent with generated avatar
Authorization also pending here
Operator verified
🔊 Robot dog: person at back-lot fence
🔊 ⚠️Verified — auth to phone & console
📱 Authorized on phone — proceed
✓ Holding position — no approach
✓ Audio deterrent playing
✓ Track played — confirmed
🔊 Deterrent played. Record written.
RynnBrain
Operator Console (optional) On-site surface · not required for authorization
Edge-AI Box Central intelligence · perception, reasoning, governance
Entry written when the event completes
Authorization record saved
2026-08-03 22:41:07
Detected → cross-verified → held
Authorized by operator, on phone
Audio deterrent played · no approach
Timestamped record
STUN / TURN
Authorization request
Approve / decline
Outside the local network
RynnBrain
No pending authorization
Authorization required Person at back-lot fence · zone B
Decline Approve
✓ Approved 22:41:07
Operator's phone Primary path · remote, out-of-network authorization or the optional console inside the local network — either surface can approve or decline
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, and the artifact is the point. This is an example of the authorization record the loop above generates — the full chain of causation behind a single event, from what was perceived through to confirmation that the authorized action actually completed.

Example authorization record

Unexpected person detected · perimeter zone B

Zone
B — north back-lot fence line
Trace
RYNN-tr-4471
Opened
2026-08-03 22:41:03
Closed
2026-08-03 22:41:29
Authorized · execution confirmed
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 — no fixed camera covers this ground; detected by the robot-dog camera on patrol, confirmed over consecutive frames
Verified
Robot-dog camera observed from a second position after repositioning; both observations 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 authorized audio deterrent played (onboard speaker) execution confirmed No autonomous approach. The authorized response is a fixed, non-confrontational deterrent: the robot dog held its position and played a recorded message asking the person to leave the premises. It did not navigate toward the subject and has no authority to. The unit reported the track played, and that confirmation is part of this record.
Authorized by
Site Supervisor role: supervisor 2026-08-03 22:41:19 Authorization is attributed to a role, not just a person. A decline is recorded here exactly as an approval is.

Why the confirmation matters: the record shows the action was carried out, not merely ordered. A log bolted onto a robot after the fact can say a command was sent; it cannot show that a human authorized it first and that the authorized action then completed. That gap is the difference between an activity log and a defensible record.

Chain-of-custody trace · RYNN-tr-4471 (illustrative) Illustrative authorization record — representative of the artifact the loop produces, not output from a deployed system.
Hardware

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 authorization record 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 play an authorized audio deterrent from its onboard speaker. It holds no decision authority of its own — the intelligence stays on the fixed box, and the authorized response is a contained deterrent rather than pursuit.

Technology

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.

Tiered wake architecture

Cheap always-on perception gates expensive reasoning. The system watches continuously at low power and reasons hard only when something happens.

Tier 1 · always on Lightweight detector

A small detection model runs continuously on the low-power NPU integrated into the applications processor — a ~2.3 TOPS class part. It does one job: notice that something is worth looking at. Running this tier all night is cheap enough to be practical.

Tier 2 · on event Vision-language reasoning

The heavier vision-language model runs on a discrete high-performance NPU and is triggered by a detection rather than running continuously. It wakes, reasons about what the detector found, cross-verifies against the second viewpoint, classifies, and hands the result to the governance gate.

Continuous heavy inference would be the obvious way to build this and the wrong one: it costs power and silicon budget to spend most of the night describing an empty yard. Gating it behind an always-on detector is what makes continuous coverage viable on a box this size. This describes the intended target platform architecture.

Neural axis (reference model)
RynnBrain
no equivalent layer
Governance human authorizes · slowest on purpose
Cerebrum reasoning · ~10–20 W continuous
Edge box · VLM tier wakes on event, not continuous
Cerebellum coordination · ~1–2 W continuous
Detector tier · patrol route always on, cheap, gates the tier above
Spinal cord reflex · event-driven, ~1 µJ
Robot dog MCU · gait, IMU, servos never gated by the layers above
reference model RynnBrain equivalent the layer we add The three reference layers and their power figures are as presented in NXP CEO Rafael Sotomayor’s COMPUTEX 2026 keynote transcript; they describe that model, not measurements of anything here. The RynnBrain column describes intended architecture for the demonstration — no measured figures are claimed for it. The governance row is the layer the reference model has no equivalent for, and it is the one this project exists to add.
🧠
On-device inference

Both tiers run on the box. The reasoning tier is exposed over a standard chat-completions REST API, with open-weight vision-language models running locally and no internet connection in the decision path.

📹
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, whether that second viewpoint is another camera or the same camera observing again from a different position.

📡
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

Robot dog patroller

The mobile actuator that carries a camera into the gap and plays an authorized audio deterrent from a held position. The specifications below describe the intended actuator platform for the demonstration — a deliberately low-cost commodity unit that holds no decision authority of its own.

🦿
12-DOF articulation

Three joints per leg across four legs, driven through multi-link connecting rods with inverse kinematics for greater effective torque. Enough articulation to cross uneven ground and steps, and to keep the camera steady as a moving viewpoint.

⚙️
Actuation

Twelve serial-bus servos with real-time position, speed and voltage feedback — roughly 2.3 kg·cm nominal torque, up to about 5.2 kg·cm locked-rotor. Aluminium-alloy and cast-nylon structure running on 40 bearing joints.

🧭
Onboard sensing

A 9-axis IMU — accelerometer, gyroscope and magnetometer — drives self-balancing and gait stability. An onboard voltage and current monitor tracks power draw in real time.

📷
Camera

A 5-megapixel ultra-wide camera, roughly 160° field of view. This is the mobile viewpoint in the loop — the one whose report gets cross-verified against a fixed perimeter camera before anything escalates.

🧮
Onboard compute

A dual-core microcontroller runs the real-time loop for inverse kinematics and gait generation. An optional single-board Linux host can be added on top for on-unit vision work.

📡
Connectivity

Wi-Fi with a self-hosted browser control interface, plus a low-latency peer-to-peer wireless mode for host-to-unit control, and a serial link to any attached host. In this architecture the decision path stays on the edge-AI box — the unit receives authorized commands, it does not originate them.

🔋
Power and runtime

Two lithium-ion cells in series, around 7.4 V nominal and 5200 mAh, with over-charge, over-discharge, over-current and short-circuit protection. Roughly one to two hours of continuous operation, or twenty to thirty minutes under sustained high load. Operates while charging.

🐾
Mobility and gait

Gait generation runs on the controller with IMU-driven self-balancing. Movement sequences can be recorded and played back as task files, which is what makes a repeatable patrol route possible.

🔆
Status output and expansion

An onboard OLED status display, RGB indicators and an audible buzzer, plus a multi-function expansion port exposing spare I/O, serial lines and power for additional sensing.

12-DOF robot dog patroller
Operator console display

Operator console (optional)

Optional. An on-site surface where an event can be presented, held, and either authorized or declined. It is not required for the loop to function — authorization reaches the operator's phone regardless, which is what makes approval possible when nobody is on site. The console is a second surface for sites that want one, not a dependency.

✋
One of two authorization surfaces

An escalated event is pushed to the operator's phone and, where a console is installed, presented here too. Either surface can approve or decline; the loop waits for whichever answers first. 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.

Demonstration architecture The fixed perimeter camera and the mobile robot dog patroller both feed perception into a central edge-AI box, which runs vision-language reasoning and the governance logic. The edge-AI box dispatches actuation commands to the robot dog over an out-of-band control path. For any response it first requests authorization from a human — primarily as a notification to the operator's phone, which works remotely and out of network, and optionally through an on-site operator console. The approved or declined decision returns to the edge-AI box, which writes a timestamped authorization record. Perimeter Camera Fixed viewpoint Perception input Robot Dog Patroller Mobile viewpoint Perception input Commanded actuator Edge-AI Box Central intelligence · on site Perception Vision-language reasoning Governance & authorization Operator's Phone Primary authorization path Remote · out of network Approve or decline Operator Console (optional) On-site surface Authorization Record Timestamped record of the whole chain of causation video in actuation out-of-band authorization request approve / decline writes on completion
Demonstration architecture — the fixed perimeter camera and the mobile robot dog patroller are both perception inputs to the edge-AI box, which is where reasoning and governance run. Actuation commands reach the robot dog over an out-of-band control path. Authorization goes to a human before any response, primarily as a notification to the operator's phone, with the on-site console as an optional surface. This is the target architecture for the demonstration, not a deployed system.
Applicability

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.

FAQ

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 plays 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 authorized response is deliberately contained: an audio deterrent played from the unit's onboard speaker, asking the person to leave the premises, from wherever the unit already is. It does not navigate toward the subject, and it has no authority to. Speak, do not chase — the restraint is part of the design, not a limitation of it.

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. Where the event happens inside a fixed camera's coverage, that can be the fixed camera corroborating what the robot dog's camera reported, or the reverse. Where it happens in a blind spot — which is the case the patrol exists for — the second viewpoint is the robot dog itself, observing again from a different position as it repositions.

The intent either way 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.

Get in Touch

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
✓ localvlmtouch@gmail.com

Your information is kept private and never shared.