// SKIP TO CONTENT
NEICRONE
// VALIDATION ENGAGEMENTS

Find out how your system behaves in the physical world, before production does.

A validation engagement answers one specific question about a specific system under defined physical conditions. It runs on an agreed protocol, is measured against a separate ground truth, and ends in a Neicrone Evidence Record you can put in front of a reviewer.

Discuss a validation engagementSee the Evidence Record
Engagement-ledScoped individuallyFirst engagements being scopedNot sure where to test yet? Start with a site assessment
Validation Engagements
0105

From a question to measured evidence.

A high-touch engagement, scoped individually. You bring the system and the question. Neicrone brings the site, the protocol, the measurement, and the record.

// YOU BRING
System
The robot, vehicle, or platform under test
Model / software
The version you need evidence about
Task
What the system is meant to do, and where
Question
The decision the evidence has to support
// NEICRONE PROVIDES
01
Site selection
Suitability, constraints, and feasibility, starting in Andromeda
02
Test protocol
Runs, conditions, metrics, and acceptance criteria
03
Instrumentation
Sensors and telemetry capture for the agreed measurements
04
Ground truth
A stated reference method, measured separately from the system
05
Evaluation
Results against the predefined criteria, failures included
06
Evidence Record
The traceable deliverable, with its limitations stated
  1. 01Joint

    Define

    You identify the system, the task, the intended environment, and the question the evidence has to resolve.

  2. 02Neicrone

    Assess

    Site suitability, constraints, feasibility, and measurement requirements, starting in Andromeda.

  3. 03Joint

    Design

    Test protocol, instrumentation, metrics, and evidence requirements agreed before anything runs.

  4. 04Joint

    Execute

    Testing proceeds only where suitable equipment, site access, personnel, and safety arrangements are in place.

  5. 05Neicrone

    Evaluate

    Observations compared against the predefined criteria and the agreed ground-truth method.

  6. 06Neicrone

    Deliver

    A Neicrone Evidence Record documenting results, limitations, open issues, and the next decision.

Engagements are scoped individually. Execution depends on site access, equipment compatibility, operational readiness, and safety requirements. The output is evidence, not a certification — Neicrone is not a certification body.

Discuss a validation engagement
Neicrone Evidence Record
0205

A traceable record of physical-system behavior.

The Evidence Record documents how a specified system behaved under defined physical conditions, linking its configuration, environment, observations, interventions, and evaluation results.

Not “we collect data.” A record a reviewer can check: what was tested, how it was measured, where every number came from.

// WHAT IT IS
  • A defined deliverable of every validation engagement
  • Separately measured: ground truth does not come from the system under test
  • Traceable: every result points back to its source data and conditions
  • Honest about limits: failures, gaps, and open issues are part of the record
// WHAT IT IS NOT
  • A certification or a safety approval
  • An industry standard
  • A guarantee of performance elsewhere
Neicrone Evidence RecordNER-0000 · SPECIMEN
Illustrative · not a real engagement
01

System configuration

Hardware, model and software version, sensor setup, test configuration.

Platform
Customer AMR, unit S/N ref.
Software
nav-stack 2.4.1 · model 9c1e…a04
Sensors
Stereo ×2 · 3D LiDAR · IMU
Config
Speed cap 1.5 m/s
02

Test conditions

Site, task, environmental context, defined test parameters.

Site
Yard section B
Task
Gate-to-dock route, 420 m
Environment
Wet asphalt · dusk · 6–9 °C
Parameters
40 runs · 3 obstacle classes
03

Recorded observations

Telemetry, sensor observations, relevant events, operator interventions.

Telemetry
Pose, velocity, CAN · 50 Hz
Events
112 logged
Interventions
4 operator stops
Raw data
Retained, referenced by hash
04

Measurement & evaluation

Ground-truth method, metrics, deviations, observed failure cases.

Ground truth
RTK-GNSS + surveyed markers
Metrics
Path deviation · stop distance
Deviation p95
0.31 m
Failure cases
2 · reflective wet surface
05

Provenance

Timestamps, source references, transformation history, integrity checks where implemented.

Clock
UTC, synchronized
Sources
Each file referenced by content hash
Transforms
3 steps, each recorded
Integrity
Hash check on hand-off
06

Outcome

Results against stated criteria, limitations, unresolved issues, the next decision.

Criteria
3 of 4 met
Limitations
One site, one season
Open issue
Wet-surface perception
Next decision
Extend to night runs
Values show the structure of a record, not resultsRecord hash e41b…77c0
Provenance
0305

Chain of custody, by design.

The provenance layer behind every Evidence Record is being built so that sensor readings, operator decisions, and model outputs carry a verifiable record from capture to hand-off.

01

Signed at capture

Sensor Origin

Sensor readings are designed to be timestamped, located, and signed as they are ingested, so later changes can be detected.

02

Logged with context

Operator Intent

Human decisions are recorded alongside who made them, when, and why, including the reason for any override.

03

Append-only

System State

Model outputs and confidence scores are written to an append-only log, so a run can be traced back to the inputs behind it.

04

Built for review

Compliance Path

Evidence is structured to support safety assessment work such as ISO 26262 and IEC 61508. It supports a certification case; it is not a certification.

A sensor-equipped car and drone feed a record that passes through sensor origin, operator intent and system state cards into a hash-chained, append-only log, forming a verifiable audit trail

Hash-Chained Records

Each record is designed to reference a hash of the one before it, so an edit after the fact breaks the chain and shows up on verification.

Separate Logs

Sensor data, operator input, and model output are logged separately, so one record can be checked against the others.

Evidence at Capture

The record is built as events happen rather than reconstructed afterwards, so reviewers see what the system actually saw.

// STATUS: DESIGN SPECIFICATION · IN DEVELOPMENT
Trust / Safety / Compliance
Scope & Requirements
0405

What decides whether a first engagement is practical.

Four things have to be true before anything runs. The scoping call exists to check them, and to say so plainly if one is missing.

01

Site access

A suitable site, and the operator's agreement to test on it.

02

Equipment compatibility

Instrumentation that can be fitted to, or placed around, your system.

03

Operational readiness

A system stable enough that the test measures behavior, not set-up.

04

Safety arrangements

A safety case, exclusion zones, and an operator able to stop the system.

// WHAT AN ENGAGEMENT IS NOT
  • Not a certification, approval, or safety sign-off
  • Not a self-service platform: each engagement is scoped and run with you
  • Not a promise of results beyond the conditions actually tested

Initial focus: industrial, yard, and logistics environments, where sites are bounded, tasks are repeatable, and the cost of a failed rollout is real.

Engage
0505

Discuss a validation engagement.

Every assessment and engagement is scoped and quoted individually. Tell us the system, the site, and the question — the reply starts there.

ASite assessment

Where can this system be deployed or tested safely and economically? Candidate sites scored against your operational requirements in Andromeda, with the weights and constraints stated.

Output · Ranked shortlist · criteria · constraints

BValidation engagement

How does this system actually behave under these physical conditions? A scoped test with an agreed protocol, instrumentation, and ground-truth method.

Output · Neicrone Evidence Record

// WHAT HAPPENS NEXT
  1. 01The founder reads the request and replies within two business days.
  2. 02A short scoping call establishes feasibility: system, site, question, constraints.
  3. 03You receive a written scope and quote, or a plain answer that it is not a fit yet.

Prefer email? jersonboyd@neicrone.com

// FORM NCR-ENG-01FEASIBILITY INTAKE
I WANT TO DISCUSS
// REPLY WITHIN 2 BUSINESS DAYS