Project Scarecrowby JVR Software
Public working specification · v0.2

Buildable scope.
Visible boundaries.

This page separates what Project Scarecrow can demonstrate today from what still needs hardware, professional review and field evidence.

Updated 15 September 2026 · No weapons in v1 · No autonomous force · No performance claim before validation

Status at a glance

A real software start, not yet a finished farm-security product.

01

Implemented

Authenticated events and device health, local storage, private site configuration, incidents, operator decisions, notification queue, audit-chain verification, evidence export and rejection of autonomous-force actions.

02

Demonstrated

A browser-only simulator shows the patrol-to-review workflow using synthetic data. It is not evidence of robot or sensor performance.

03

Next to build

A real sensor adapter, external notification delivery, role-based identities, retention controls and a read-only robotics telemetry bridge for a controlled technical trial.

Reference architecture

Hardware can change without replacing the whole system.

The core gateway stays vendor-neutral. Each camera, alarm, robot or future aerial platform connects through a narrow adapter boundary.

  • Input layer: authenticated events from approved devices.
  • Decision layer: correlation, incident state and confidence handling.
  • Human layer: verify, dismiss, deter, escalate and record.
  • Evidence layer: time-stamped events, decisions and exportable records.
  • Safety layer: fail safe on uncertainty, lost connectivity or unhealthy devices.
Core requirements

The rules every implementation must preserve.

SYS-001 · Local first

Essential event handling and operator records continue locally when external connectivity is unavailable.

SYS-002 · Human authority

A person remains responsible for consequential deterrence and escalation decisions.

SYS-003 · Non-lethal v1

The first product and pilot exclude lethal weapons and autonomous force.

SYS-004 · Traceability

Security-relevant events and operator actions are time-stamped and auditable.

SYS-005 · Least data

Collect only what the security purpose requires, with defined access, retention and deletion rules.

SYS-006 · Safe failure

An unhealthy, disconnected or uncertain component must not silently continue a consequential action.

Development gates

Progress is earned with evidence.

v0.2 · Lab control plane

Authenticated events and heartbeats, private configuration, incidents, local notifications, evidence bundles, tamper detection, simulator and automated tests. Current software stage.

v0.3 · Controlled integration

One approved real input device, external notification delivery, roles, retention controls and supervised failure tests.

v1.0 · Pilot ready

Selected mobile platform, documented emergency stops, trained operators, privacy controls, partner response workflow and independent acceptance review.

Validated offering

Only measured pilot evidence may support performance, service, price or insurance claims.

Controlled-site acceptance

What must work before a farm pilot counts.

  • Authorised events are accepted; invalid or replayed events are rejected.
  • Every operator action produces a complete audit trail.
  • Connectivity, device-health and power failures move the system to a safe state.
  • Emergency-stop and manual-control procedures are physically tested.
  • Evidence can be exported with integrity information and a documented retention rule.
  • No exact address, route, access code or security layout is collected through the public website.

Want to help turn this specification into field evidence? We need pilot farmers, security partners, robotics and sensor suppliers, legal/privacy advisers, safety engineers and patient capital.

Start the right conversation