RAIN / Hardware

Built around a clear boundary.

Explore the architectural idea behind RAIN Node: observe equipment, compute locally, and make the operating record understandable.

Conceptual architecture

INTELLIGENCE BELONGS WHERE THE DATA LIVES.

01 / THE IDEA

A system of roles before a finished object.

The RAIN illustrations show how connectivity, computation, and storage fit together inside a facility. They are explanatory diagrams, not photographs of manufactured hardware. The physical enclosure and internal configuration remain open design decisions.

01

An observable connection

A defined read-only input establishes where site signals enter the system while leaving equipment control separate.

02

A visible learning loop

Inference, training, and evaluation belong to an understandable local process with recorded model changes.

03

A human point of review

The local console direction brings advisories and operating history to the people responsible for the site.

02 / IN PRACTICE

Put the thinking into practice.

Define the scope, preserve the boundary, and make the outcome something a person can inspect.

  1. 01

    Start at the boundary

    Understand which data enters the node and which systems retain control of the equipment.

  2. 02

    Trace the local process

    Follow a signal through storage, inference, and model evaluation to see the role each layer serves.

  3. 03

    Return to the operator

    Judge the architecture by whether a person can inspect the output and decide what it means for their work.

03 / A FEW DETAILS

Worth understanding.

Is the illustration the final hardware design?

No. It is a code-native diagram of system responsibilities. Form factor, internal components, and installation details are not finalized.

Why show the control boundary?

RAIN observes and advises. Showing the boundary makes clear that model output is not an actuation path into plant control or safety systems.

BUILD WITH RAIN

One site. One question.
A useful next step.

RAIN is preparing for its first field pilot. Start by defining the environment, the data boundary, and what success should look like.

Build your pilot brief