Useful site characteristics
- A clearly defined observation problem or blind spot.
- One controlled zone or repeatable route.
- Available power and a secure gateway location.
- A farmer willing to record baseline and pilot outcomes.
Pilot design · non-lethal only
Prove the system on one controlled site.
A Scarecrow pilot is not a sales installation disguised as research. It is a written, measured and reversible trial designed to discover whether the technology is useful, safe, supportable and worth funding.
Who the first pilot needs
A representative problem, a willing site and honest measurement.
The first site should be technically manageable and operationally meaningful. Selection is based on learning value and safety, not fear-based selling.
People we need
- A named farm decision-maker and trained backup.
- A technical integrator and safety owner.
- A lawful response partner where services are involved.
- Workers and affected people briefed before testing.
Not suitable yet
- A live high-risk deployment with no lab evidence.
- Any request for autonomous or lethal force.
- A site that cannot protect private security information.
- A promise that the pilot will prevent attacks or lower premiums.
Six controlled stages
Every step creates a decision record.
Discover
Define the practical problem, current measures, users and limits without collecting exact security detail through the public site.
Baseline
Record current alert volume, response process, maintenance burden, outages and false alarms.
Design
Choose one zone, inputs, safe route, no-go areas, roles, notification path and test cases.
Commission
Install, harden, train, test emergency procedures and prove that failures become visible.
Measure
Run controlled scenarios, record all results and publish only evidence that survives review.
The pilot can stop. Safety concerns, uncontrolled data collection, unreliable hardware or a failed acceptance gate must pause or end the trial without pressure to continue.
Register interestPrivate site survey
Design around the farm—not a generic sales package.
The public form asks only for province, nearest town and the problem to solve. Exact addresses, maps, access routes, cameras, response contacts and security weaknesses belong in a restricted pilot record after suitability and confidentiality checks.
- Farm context
- Operation type, terrain, weather, livestock, work patterns and people who may encounter the system.
- Existing controls
- Alarms, cameras, gates, fences, lighting, communications and current response arrangements.
- Infrastructure
- Power, backup power, secure equipment space, network coverage and lawful mounting options.
- Safety map
- Permitted observation zone, no-go areas, public roads, worker housing, animals, water and terrain hazards.
- Data map
- What is captured, why it is needed, who can see it, where it stays and when it is deleted.
- Acceptance plan
- Named tests, expected results, evidence owner, stop criteria and unresolved decisions.
Test programme
Normal operation is not enough; failures must be rehearsed.
Detection and classification
Use controlled person, vehicle, animal and environmental scenarios. The system must not convert uncertainty into a confirmed threat automatically.
Local continuity
Disconnect the internet and prove local event intake, operator review, evidence storage and queued notification still work.
Device loss
Silence or disconnect a sensor and verify that coverage changes to degraded or offline within the agreed interval.
Power and restart
Test orderly shutdown, restart, committed-record recovery and the documented backup-power behaviour.
Mobile safety
Before any robot moves: prove physical emergency stop, speed limits, geofence/no-go behaviour and safe recovery.
Human workflow
Verify acknowledgement, classification, notes, escalation, handover and incident closure by trained named users.
Evidence package
What the pilot will actually measure.
No detection rate, response-time improvement, attack reduction, return or insurance benefit is claimed before comparable field data exists.
| Measure | Question answered | Required context |
|---|---|---|
| Gateway and device availability | Was the system present when expected? | Scheduled operating hours and maintenance windows |
| Alert counts by source and severity | Which devices create useful or noisy signals? | Test scenario, weather, animals and work activity |
| Benign, uncertain and threat classifications | What did humans conclude? | Reviewer, evidence and confidence—not identity assumptions |
| Event-to-screen and acknowledgement time | How quickly did information reach a person? | Local versus remote connection state |
| False-alert and missed-scenario observations | Where do thresholds or coverage fail? | Defined denominator and scenario design |
| Maintenance and recovery effort | Can a small team support the system? | Failure mode, parts, time and responsible role |
| Privacy, safety and near misses | Did the pilot create unacceptable new risk? | Written report and corrective action |
Shared responsibility
Robots do not remove human accountability.
JVR Software
Own the gateway, integration design, configuration record, evidence method, software defects and transparent status labels.
Pilot farm
Provide authorised access, local context, safe test windows, worker communication, a trained operator and honest feedback.
Technology suppliers
Provide authentic specifications, supported interfaces, maintenance limits, safe-state and emergency-stop information.
Security partner
Own monitoring and physical response duties under its registrations, contracts, SOPs and legal authority.
Professional reviewers
Challenge legal, privacy, cyber, occupational-safety, insurance and aviation assumptions before deployment.
Independent evidence
Where feasible, review test design and results so investor and farmer claims do not depend only on the builder’s opinion.